GRE over IPsec

この記事は約10分で読めます。

GRE over IPsecの検証を行う。WANはOSPFを使用し、1.1.1.1⇒3.3.3.3宛の通信を暗号化する。

構成図

検証にはCisco CMLを使用。R1～R3のVersionは15.9(3)M4。

コンフィグ

R1ダウンロード
R2ダウンロード
R3ダウンロード

GRE over IPsecのポイント

GRE over IPsecでは暗号化トラフィックをアクセスリストで指定する際、GREでカプセル化済みのパケットを指定する必要がある。送信元IPはTunnel Source、宛先IPはTunnel Destinationとなる。

access-list 100 permit gre host 10.0.10.1 host 10.0.20.1

int tun0
ip address 192.168.1.1 255.255.255.0
tunnel source gi0/0
tunnel destination 10.0.20.1
tunnel mode gre ip
no shut

OSPFを使用する場合はTunnel IFと拠点内IFでOSPFを有効化する。WAN側IFでは有効化しない。

router ospf 51
router-id 1.1.1.1
network 192.168.1.1 0.0.0.0 area 0     <---Tunnel IF
network 1.1.1.1 0.0.0.0 area 1         <---拠点内IF

Tunnel IFのDestinationへのIP到達性が無いとTunnel IFはUpしないため、Tunnel Destination宛のスタティックルーティングを作成する。

ip route 10.0.20.1 255.255.255.255 gi0/0 10.0.10.254

IKEv1を使用したIPsecではフェーズ1とフェーズ2に分けてIPsecを確立する。フェーズ1はメインモードとアグレッシブモードがあるが、アグレッシブモードはインターネットVPNにおいてグローバルIPアドレスを固定化できない場合に使用する。

“Main Mode” for phase 1 provides identity protection. When identity protection is not needed, “Aggressive Mode” can be used to reduce round trips even further.

フェーズ1の「メインモード」はID保護を提供します。 ID保護が必要ない場合は、「アグレッシブモード」を使用して、ラウンドトリップをさらに減らすことができます。

https://tex2e.github.io/rfc-translater/html/rfc2409.html

今回は固定プライベートIPアドレスを使用するため、メインモードを使用する。メインモードでPre-Shared key認証を使用する場合、IDはIPアドレスとなる。

メインモードに関する設定は以下の通り。SAパラメータ(暗号化アルゴリズム、ハッシュアルゴリズム)の交換、共通鍵の素の交換(Diffie-Hellman鍵共有)、対向認証の順で1本のISAKMP SA(暗号化トンネル)を構築する。

対向認証はPre-Shared keyを使用する場合、必ずIPアドレスとなる。

crypto isakmp policy 1
encr aes 256
hash sha512
group 24
authentication pre-share

crypto isakmp key cisco address 10.0.20.1
crypto isakmp keepalive 10 periodic

フェーズ2ではメインモードで構築したISAKMP SAを使用してIPsec SAのための情報を交換する。IPsec SAでは初めにセキュリティプロトコルとカプセル化モードを選択する。

セキュリティプロトコルはESP(Encapsulating Security Payload)とAH(Authenticated Header)の2つがあるが、AHは暗号化機能が無いため、現場ではESP一択となる。カプセル化モードはtunnelモードとtransportモードの2つがある。tunnelモードはIP/ESPでカプセル化を行うモードで、transportモードはESPヘッダを差し込むだけのモードである。

IPヘッダの二重カプセル化を防ぐため、GREトンネルを使用する場合は必ずtransportモードを使用する。

crypto ipsec transform-set TS1 esp-gcm 256
mode transport

crypto map CMAP 1 ipsec-isakmp
set peer 10.0.20.1
match address 100
set transform-set TS1
exit

int gi0/0
crypto map CMAP

動作確認

OSPF⇒IPsecの順に動作確認を行う。

R1#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -        00:00:37    192.168.1.2     Tunnel0
R1#show ip route ospf | begin Gateway
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/1001] via 192.168.1.2, 01:59:20, Tunnel0

IKEv1によるIPsecは、show crypto engine connection activeが最強コマンド。このコマンドのみでフェーズ1、フェーズ2の成功有無を確認できる。正常時はIKE(ISAKMP)SAが1本、IPsec SAが2本の計3本存在すれば問題ない。

R1#show crypto engine connection active
Crypto Engine Connections

   ID  Type    Algorithm           Encrypt  Decrypt LastSeqN IP-Address
    5  IPsec   GCM256                    0      126      126 10.0.10.1
    6  IPsec   GCM256                  125        0        0 10.0.10.1
 1001  IKE     SHA512+AES256             0        0        0 10.0.10.1

教科書的にはフェーズ1の動作確認はshow crypto isakmp sa、フェーズ2の動作確認はshow crypto ipsec saを使用する。

R1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.0.20.1       10.0.10.1       QM_IDLE           1001 ACTIVE     ----->QM_IDLEであればOK

IPv6 Crypto ISAKMP SA

R1#
R1#show crypto ipsec sa

interface: GigabitEthernet0/0
    Crypto map tag: CMAP, local addr 10.0.10.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.10.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (10.0.20.1/255.255.255.255/47/0)
   current_peer 10.0.20.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 832, #pkts encrypt: 832, #pkts digest: 832 --->通信を発生させてカウントアップするか確認
    #pkts decaps: 832, #pkts decrypt: 832, #pkts verify: 832 --->同上
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 10.0.10.1, remote crypto endpt.: 10.0.20.1
     plaintext mtu 1466, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
     current outbound spi: 0xACDAF9A2(2900031906)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x29DBAD45(702262597)     ----->inbound用のSPI(32ビット)が表示されればOK
        transform: esp-gcm 256 ,
        in use settings ={Transport, }
        conn id: 5, flow_id: SW:5, sibling_flags 80004000, crypto map: CMAP
        sa timing: remaining key lifetime (k/sec): (4306762/2143)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xACDAF9A2(2900031906)     ----->outbound用のSPI(32ビット)が表示されればOK
        transform: esp-gcm 256 ,
        in use settings ={Transport, }
        conn id: 6, flow_id: SW:6, sibling_flags 80004000, crypto map: CMAP
        sa timing: remaining key lifetime (k/sec): (4306762/2143)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

パケットキャプチャ

R1(1.1.1.1)⇒R3(3.3.3.3)へ通信を発生させた際のパケットキャプチャは以下の通り。IPヘッダはGREがカプセル化した際に付与し、オリジナルパケットはESPにより暗号化されており、見えなくなっていることが確認できる。

以上

コメント

タイトルとURLをコピーしました