4-8 Site-to-Site VPN — VTI で暗号トンネルを「線」として持つ

1. 前節の振り返りと本節の内容

前節 4-7 IPsec VPN 基礎 では、通信の中身を暗号で守る IPsec の土台を扱いました。鍵を安全に配る IKE と、方向別・寿命別の暗号契約である SA の関係、IKEv1 (main mode 6 + quick mode 3 = 9 メッセージ) と IKEv2 (IKE_SA_INIT + IKE_AUTH = 4 メッセージ) の対比、そして経路に NAT を挟んだときの NAT-T を、csr1000v の show 出力で確認しました。前節は IKE と SA の仕組み に徹し、トンネルを 1 本張って観察することに集中しました。

第 4 章はここまで、4-1 ACL の in/out、4-5 ZBF の zone-pair、4-6 NAT の inside/outside、4-7 IPsec の initiator/responder と、通信を制御する 向き と 状態 の考え方で貫いてきました。本節 Site-to-Site VPN は、第 4 章の締めとして、その IPsec を 実運用のトンネルにどう載せるか を扱います。

本節で扱うのは次の 4 点です。第一に、前節の crypto map 方式 とは異なる、より新しい VTI (Virtual Tunnel Interface) 方式でトンネルを構築します。第二に、この 2 つの方式 = policy-based と route-based の運用上の違いを実機の show 出力で比較します。第三に、鍵を定期的に作り直して過去の通信を守る PFS (Perfect Forward Secrecy) を有効化し、その効果を観察します。第四に、複数拠点を結ぶときのトポロジ (ハブ&スポーク) を概念として扱い、次章以降への布石とします。前節が「IKE と SA の仕組み」という土台なら、本節はその上に実運用の VPN を組み立てる建物にあたります。

2. route-based VPN とは — トンネルを「線」として持つ

前節の crypto map 方式では、暗号化する通信を crypto ACL で選びました。permit ip 192.168.10.0 ... 192.168.20.0 ... という ACL に一致したパケットだけが ESP でカプセル化され、相手ゲートウェイへ送られます。この「暗号化の対象を ACL で選別する」やり方を policy-based VPN と呼びます。ポリシー (ACL) が暗号化するかどうかを決める方式です。

本節で扱う VTI (Virtual Tunnel Interface) は、考え方が異なります。VTI は Tunnel0 という仮想的なインタフェース を作り、そのインタフェースへ ルーティングされた 通信を丸ごと暗号化します。相手内部網への経路を ip route 192.168.20.0/24 Tunnel0 のように Tunnel0 へ向けておけば、その宛先への通信は Tunnel0 を通り、tunnel protection で自動的に ESP カプセル化されます。暗号化の対象を ACL ではなく ルーティング (送り先) で決めるこのやり方を route-based VPN と呼びます。

この違いを一言で表すと、crypto map は「この ACL に一致した平文を暗号化する」(policy)、VTI は「Tunnel0 へ routing された平文を暗号化する」(route) となります。守る対象の指定を ACL からルーティングテーブルへ移した のが VTI です。

ルーティングで暗号化対象を決められることには、大きな利点があります。Tunnel0 は普通のインタフェースとして扱えるため、そこに 動的ルーティングプロトコル (OSPF など) を流せます。crypto map ではできなかったこの point を §6 で扱います。また、show interface Tunnel0 や show ip route でトンネルの状態や経路が見えるため、運用・監視も素直になります。以降、この VTI を実機で構築し、crypto map と比較していきます。

3. 本ラボのトポロジ

本節の検証で使うトポロジを示します。前節 4-7 の構成を流用し、csr1000v 3 台を直列につなぎます。両端の R1・R3 を VPN ゲートウェイ、中央の R2 を経路上の中間ルータとします。前節との違いは、VTI では NAT-T を扱わないため、R2 が NAT を持たない純粋な中継ルータ になっている点です。

トポロジの構成は以下のとおりです。

• R1 (左 VPN ゲートウェイ・initiator) — Loopback10 に 192.168.10.1/24 を持ち、これが左の内部ホストです。R2 への Gi2 に 10.12.0.1/30 を持ち、VTI ではこの Gi2 を tunnel source として Tunnel0 (172.31.12.1/30) を張ります。
• R2 (中間ルータ・純 transit) — R1 への Gi2 に 10.12.0.2/30、R3 への Gi3 に 10.23.0.1/30 を持ちます。crypto も NAT も持たず、GW 間のパケットを転送するだけの経路上の第三者です。VTI は GW 間の outside 到達性さえあれば張れるため、間にこうした中継ルータがあっても成立します。
• R3 (右 VPN ゲートウェイ・responder) — Loopback20 に 192.168.20.1/24 を持ち、これが右の内部ホストです。R2 への Gi2 に 10.23.0.2/30 を持ち、Tunnel0 (172.31.12.2/30) の端点になります。

crypto (crypto map / tunnel protection) は データ IF の Gi2 と論理 IF の Tunnel0 のみ に適用します。管理用の Gi1 (Mgmt) には決して当てません。GW 間のリンク (10.12.0.0/30・10.23.0.0/30) と各 Loopback0 は OSPF で相互に広告し、GW 同士が外側アドレスで到達できる土台を作ります。一方、暗号化して守りたい内部網 (192.168.10.0/24 と 192.168.20.0/24) は、前節と同じく 意図的に OSPF で広告しません。相手内部網への到達は、トンネル経由でのみ成立させます。

4. static VTI トンネルの構築

VTI を構築します。前節 4-7 で使った IKEv2 の部品 (proposal・policy・keyring・profile・transform-set) は そのまま再利用 します。変えるのは出口だけです。crypto map の代わりに crypto ipsec profile を作り、それを interface Tunnel0 の tunnel protection に紐づけます。R1 の設定は次のとおりです (R3 は tunnel destination と経路を鏡像にします)。

! --- IKEv2 部品は 4-7 と同一（再利用）---
crypto ikev2 proposal PROP-V2
 encryption aes-cbc-256
 integrity sha256
 group 14
crypto ikev2 policy POL-V2
 proposal PROP-V2
crypto ikev2 keyring KR
 peer P
  address 10.23.0.2
  pre-shared-key CISCO123
crypto ikev2 profile PROF-V2
 match identity remote address 10.23.0.2 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR
crypto ipsec transform-set TS-V2 esp-aes 256 esp-sha256-hmac
 mode tunnel
!
! ★crypto map との分岐点 = ipsec profile
crypto ipsec profile PROF-IPSEC
 set transform-set TS-V2
 set ikev2-profile PROF-V2
!
interface Tunnel0
 ip address 172.31.12.1 255.255.255.252
 tunnel source GigabitEthernet2
 tunnel destination 10.23.0.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROF-IPSEC
!
ip route 192.168.20.0 255.255.255.0 Tunnel0

crypto map との対応を整理すると、set peer 10.23.0.2 が tunnel destination 10.23.0.2 に、crypto map CMAP を Gi2 に当てる操作が tunnel protection ipsec profile を Tunnel0 に紐づける操作に置き換わっています。set transform-set と set ikev2-profile は ipsec profile の中でそのまま使います。crypto ACL は書きません。代わりに ip route 192.168.20.0 255.255.255.0 Tunnel0 で、相手内部網宛を Tunnel0 へ向けます。tunnel mode ipsec ipv4 は、この Tunnel0 が GRE ではなく IPsec (sVTI) のトンネルであることを指定します。この指定を省くと既定の GRE トンネルになりますが、tunnel protection ipsec profile が残っていれば平文の生 GRE ではなく GRE over IPsec (GRE を IPsec で保護する別方式) になり、暗号化自体は効きます。ただし sVTI の any-any proxy identity や sVTI としての挙動ではなくなるため、本節では sVTI に統一するべく tunnel mode ipsec ipv4 を明示します。

構築したら、§3 と同じ ping を撃ちます。

ping 192.168.20.1 source Loopback10 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

!!!!! で成功率 100 パーセントです。VTI で同じ 2 拠点が結ばれました。crypto map のときは初弾が SA 確立で落ちて .!!!! でしたが、VTI では初弾から通っています。これは、Tunnel0 が tunnel source と tunnel destination の到達性さえあれば常時 up になる ためで、後述する VTI の性質の 1 つです。

暗号化が起きていることを show crypto ipsec sa で確認します。

show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 10.12.0.1
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 10.23.0.2 port 500
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

#pkts encaps: 5 / #pkts decaps: 5 で、実際に暗号化・復号が起きています。ここで local ident と remote ident がともに 0.0.0.0/0.0.0.0 になっています。crypto map では (4-7 の §5)、この ident は crypto ACL の網 (192.168.10.0/24 ↔ 192.168.20.0/24) でした。VTI では暗号化対象を ACL で絞らないため、ident が any-any になります。この違いが policy-based と route-based を分ける指紋です。この暗号化の流れを図で示します。

5. crypto map と VTI の運用比較

crypto map (4-7) と VTI (本節) を、実機の show 出力で比較します。両者は同じ IKEv2 部品・同じ transform-set を使い、同じ 2 拠点を結びます。違いは「暗号化する通信をどう決めるか」と、それに伴う運用上の性質です。

まず、相手内部網への経路の載り方 が違います。crypto map では、暗号化対象を crypto ACL で決め、相手内部網へは next-hop を IP で指定した static route を書きました。VTI では、ip route 192.168.20.0/24 Tunnel0 のように Tunnel0 (インタフェース) 宛 に書きます。このときの経路を見ると、VTI では宛先が Tunnel0 に「直結」として現れます。

show ip route 192.168.20.0
Routing entry for 192.168.20.0/24
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0

directly connected, via Tunnel0 です。Tunnel0 が点対点の論理インタフェースなので、その先の網が直結扱いになります。show ip cef でも出力インタフェースが Tunnel0 になります。

ここで、4-7 で扱った落とし穴を思い出します。crypto map では、相手内部網への static route を インタフェース指定 (... GigabitEthernet2) にすると通らず、next-hop を IP で指定する必要がありました (宛先を直結と誤認して ARP 解決に失敗するため)。VTI ではこの制約が 反転する かに見えますが、実機で確かめると、そう単純ではありません。VTI で相手内部網への経路を next-hop の IP 指定 (ip route 192.168.20.0/24 172.31.12.2) に書き換えても、通信は問題なく通ります。

ping 192.168.20.1 source Loopback10 repeat 5
!!!!!
Success rate is 100 percent (5/5)
show ip route 192.168.20.0
  * 172.31.12.2

VTI では インタフェース指定でも、トンネル内 next-hop の IP 指定でも、どちらでも通ります。crypto map の「インタフェース指定だと確実に落ちる」という強い制約とは非対称で、VTI では「インタフェース指定が慣用だが、IP 指定も動く」という違いにとどまります。理由は、Tunnel0 が点対点の論理インタフェースで ARP を使わない ため、crypto map の物理インタフェースで起きた「直結誤認による ARP 解決の失敗」が VTI では原理的に起きないからです。方式の違いが、落とし穴の形まで変える一例です。

次に、SA の proxy identity の粒度 が違います。§4 で見たとおり、VTI の show crypto ipsec sa の ident は 0.0.0.0/0.0.0.0 (any-any) でした。crypto map では crypto ACL の網がそのまま ident になり、192.168.10.0/24 ↔ 192.168.20.0/24 という特定網でした。VTI が any-any になるのは、暗号化対象を ACL で絞らず「Tunnel0 に載ったものすべて」を暗号化するためです。この違いを図で対比します。

さらに、トンネルの見え方と up/down の条件 が違います。crypto map は物理インタフェースに当てるため、トンネルそのものはインタフェースとしては見えず、show crypto session で状態を追いました。また、interesting traffic が来て初めて SA が立つため、無通信のときは session が DOWN で、初弾が SA 確立で落ちました。VTI では Tunnel0 が独立したインタフェースとして見え、show interfaces Tunnel0 で状態を追えます。そして tunnel source と tunnel destination が到達可能なら、SA の有無に関係なく Tunnel0 は up/up になります。

show interfaces Tunnel0
Tunnel0 is up, line protocol is up 
  Tunnel source 10.12.0.1 (GigabitEthernet2), destination 10.23.0.2
  Tunnel protection via IPSec (profile "PROF-IPSEC")

この「Tunnel0 が up でも SA は死んでいることがある」性質には注意が要ります (§9 で補足します)。両者の違いを表にまとめます。

6. VTI over OSPF — 動的ルーティングを暗号越しに

VTI の最大の利点は、Tunnel0 が普通のインタフェースとして扱えるため、そこに動的ルーティングプロトコルを流せる ことです。crypto map では、暗号化対象を crypto ACL のユニキャストで絞るため、OSPF の Hello (マルチキャスト) が暗号区間に載らず、トンネル越しに OSPF 隣接を張れませんでした。VTI では Tunnel0 を OSPF エリアに入れれば、Hello が Tunnel0 を通って相手 GW と直接隣接できます。

Tunnel0 を area 0 に入れ、内部網 (Lo10/Lo20) だけを OSPF で広告します。相手内部網への static route は削除し、到達性を OSPF に委ねます。設定後、隣接を確認します。

show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.3.1          0   FULL/  -        00:00:39    172.31.12.2     Tunnel0
10.0.2.1          1   FULL/DR         00:00:31    10.12.0.2       GigabitEthernet2

R3 (10.0.3.1) と Tunnel0 越しに FULL で隣接できました。crypto map では原理的にできなかったことです。中間の R2 (10.0.2.1) とも物理 Gi2 で隣接しています。

コスト設計を誤ると内部網が物理経路を平文で流れる

ところが、ここに route-based ならではの落とし穴 があります。隣接が張れても、内部網 192.168.20.1 への経路を見ると、期待に反して物理経路が選ばれています。

show ip route 192.168.20.1
Routing entry for 192.168.20.1/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Routing Descriptor Blocks:
  * 10.12.0.2, from 10.0.3.1, via GigabitEthernet2
show ip cef 192.168.20.1
192.168.20.1/32
  nexthop 10.12.0.2 GigabitEthernet2

via GigabitEthernet2 = 物理経路です。つまり、暗号化して守りたい内部網宛の通信が、Tunnel0 を通らず、暗号化されずに物理経路を平文で流れています。トンネルは張れているのに、肝心の通信がトンネルを通らないという silent failure です。原因は OSPF のコストにあります。

show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Tu0          1     0               172.31.12.1/30     1000  P2P   1/1
Gi2          1     0               10.12.0.1/30       1     BDR   1/1

Tunnel0 の既定コストが 1000 と非常に高くなっています。これは Tunnel0 の既定帯域が低い (100kbps) ため、そこから算出されるコストが大きいからです。一方、物理経路 (R1→R2→R3 の 3 ホップ) は各リンクのコストが 1 で、内部網までの合計 metric が 3 です。Tunnel0 経由 (コスト 1000) より物理経路 (metric 3) が圧倒的に低いため、物理経路が選ばれてしまう のです。

対処は、Tunnel0 の OSPF コストを物理経路より低くすることです。ただし、この調整はシビアです。ip ospf cost 2 にすると、Tunnel0 経由の metric は 2 + 1 (相手の Lo20) = 3 となり、物理経路の metric 3 と 等コストになって ECMP (等コストマルチパス) で負荷分散 され、通信の半分が暗号化・半分が平文という中途半端な状態になります。物理経路より確実に低くするには、ip ospf cost 1 が必要です。

interface Tunnel0
 ip ospf cost 1

これで Tunnel0 経由の metric は 1 + 1 = 2 となり、物理経路の 3 より低くなります。経路を再確認します。

show ip route 192.168.20.1
  * 172.31.12.2, from 10.0.3.1, via Tunnel0
show ip cef 192.168.20.1
192.168.20.1/32
  nexthop 172.31.12.2 Tunnel0

今度は via Tunnel0 の一択になりました。内部網宛の通信が Tunnel0 を通り、暗号化されて流れます。VTI over OSPF は、トンネルを張るだけでなく、コスト設計まで含めて初めて意図どおりに動く という点が、route-based を運用する上での要注意点です。動的ルーティングを暗号越しに流せるのは crypto map にない強力な利点ですが、この利点は正しいコスト設計と引き換えに得られます。

7. PFS — 鍵を作り直して過去を守る

最後に PFS (Perfect Forward Secrecy、完全前方秘匿性) を扱います。PFS は、暗号化に使う鍵を定期的に 新しい DH 鍵交換 で作り直す仕組みです。これにより、ある時点のセッション鍵が万一漏れても、その鍵から過去や未来のセッション鍵を導出できなくなります。前節 4-7 では、PFS を入れると鍵交換のメッセージ観察がぶれるため意図的に扱いませんでした。本節で回収します。

PFS は ipsec profile に設定します。両端に set pfs group14 を追加します。DH グループは両端で揃える必要があります (揃わないと SA ネゴが失敗します)。

crypto ipsec profile PROF-IPSEC
 set pfs group14

ここで注意すべきなのが、PFS がいつ効くか です。設定を入れて SA を張り直した直後に show crypto ipsec sa を見ると、PFS はまだ無効に見えます。

show crypto ipsec sa
     PFS (Y/N): N, DH group: none

PFS (Y/N): N です。これは設定ミスではありません。IKEv2 では、最初の IPsec SA (Child SA) は IKE SA を確立したときの DH 鍵材料を流用する ため、最初の SA には新しい DH 交換が入らないのです。PFS の新しい DH 交換は、SA の lifetime が来て rekey (SA の作り直し) が起きたときに初めて現れます。

lifetime を短く設定して rekey を待ち、そのときの debug crypto ikev2 を見ると、新しい DH 交換が確認できます。

IKEv2:(SESSION ID = 4,SA ID = 2):Beginning IPSec Rekey as Initiator
IKEv2:(SESSION ID = 4,SA ID = 2):Checking for PFS configuration
IKEv2:(SESSION ID = 4,SA ID = 2):PFS configured, DH group 14
IKEv2:(SESSION ID = 4,SA ID = 2):[IKEv2 -> Crypto Engine] Computing DH public key, DH Group 14
IKEv2:(SESSION ID = 4,SA ID = 2):Generating CREATE_CHILD_SA exchange

PFS configured, DH group 14 を確認し、Computing DH public key, DH Group 14 で新しい DH 公開値を計算し、Generating CREATE_CHILD_SA exchange でそれを載せた交換を生成しています。rekey で新しい DH 交換が入ったことが読み取れます。rekey 後の SA を確認します。

show crypto ipsec sa
     PFS (Y/N): Y, DH group: group14

今度は PFS (Y/N): Y, DH group: group14 です。rekey を経て PFS が有効になりました。この流れを図で示します。

PFS の効果は、この「鍵の作り直しごとに独立した新しい DH を使う」点にあります。DH 鍵交換は、交換のたびに前とは無関係な新しい鍵材料を生みます。したがって、ある時点の鍵が漏れても、それ以前や以降の鍵は別の DH から作られているため導出できません。これが前方秘匿性であり、長時間張りっぱなしになる拠点間トンネルの安全性を高めます。「最初の SA では効かず rekey から効く」という挙動を知らないと、設定直後の PFS (Y/N): N を見て「効いていない」と誤診しやすいので注意します (§9 で補足します)。

8. 複数拠点への拡張 — ハブ&スポークの概念

ここまでは 2 拠点を 1 本のトンネルで結ぶ最小形を扱いました。実運用では、複数の拠点を結ぶことがよくあります。static VTI は 1 対向 1 のトンネル なので、拠点が増えるとトンネルの本数が問題になります。

拠点をすべて相互に直結する フルメッシュ では、N 拠点のときトンネル本数は N(N-1)/2 本になります。4 拠点なら 6 本、10 拠点なら 45 本と、拠点数の 2 乗に比例して急増します。各ゲートウェイに張るトンネル数も増え、設定と管理が煩雑になります。

これを緩和するのが ハブ&スポーク です。中央に ハブ を置き、各拠点 (スポーク) はハブとだけトンネルを張ります。N 拠点なら N-1 本で済み、4 拠点なら 3 本です。ただし、スポーク間の通信は必ずハブを経由する (2 ホップになる) という代償があります。

static VTI のこの「1 対向 1」というスケール限界は、より高度な VPN 技術の動機になります。スポーク間の通信をハブ経由にせず、必要なときだけ動的にスポーク同士のトンネルを張る DMVPN (Dynamic Multipoint VPN) は、この課題への回答の 1 つです。DMVPN は mGRE (multipoint GRE) と NHRP を組み合わせて、1 つのトンネルインタフェースで多数の拠点を収容します。DMVPN は本指南書の第 6 章 WAN/モダン編で扱います。本節では、static VTI が 2 拠点の確実なトンネルを提供する基本形であること、そして拠点数が増えるとオーバーレイ技術が必要になること、を押さえておきます。

9. 落とし穴・補足

VTI と PFS は、crypto map と違う挙動をいくつも持ちます。本ラボの実機検証で実際に踏んだものを含め、押さえておきたい点をまとめます。

VTI over OSPF はコスト設計を誤ると暗号化されずに漏れる (最重要)。 §6 で見たとおり、Tunnel0 の既定 OSPF コストは 1000 と高く、物理経路 (metric 3) より不利です。内部網を tunnel 越し OSPF で広告しても、コストを物理より低くしないと物理経路が選ばれ、暗号化されるべき通信が平文で流れます。ip ospf cost で物理経路より確実に低い値にします。中途半端な値だと等コストの ECMP になって半分だけ漏れるため、物理経路の metric を把握した上で確実に下回る値にします。トンネルが張れていることと、通信がトンネルを通ることは別問題です。

VTI は SA が死んでいても Tunnel0 が up/up。 §5 で見たとおり、Tunnel0 は tunnel source と tunnel destination が到達可能なら、IPsec SA が確立していなくても up/up になります。インタフェースが up であることを疎通の証拠にせず、show crypto ipsec sa の #pkts encaps/#pkts decaps カウンタが増えているか、show crypto session が UP-ACTIVE かで確認します。crypto map は interesting traffic が無ければ session が DOWN で分かりやすかったのに対し、VTI では IF が up でも中身の暗号化が死んでいることがあります。

PFS は最初の SA では効かず、rekey から効く。 §7 で見たとおり、IKEv2 では最初の Child SA が IKE SA の DH を流用するため、set pfs group14 を入れても最初の SA は PFS (Y/N): N です。設定直後にこれを見て「効いていない」と誤診しないようにします。lifetime を待つか、rekey させて PFS (Y/N): Y を確認します。

相手内部網への static は Tunnel0 指定が慣用。 §5 で見たとおり、VTI では ip route ... Tunnel0 (インタフェース指定) が素直です。4-7 の crypto map では、インタフェース指定が ARP 詰まりで確実に落ちたため next-hop の IP 指定が必須でしたが、VTI の Tunnel0 は点対点で ARP を使わないため、この制約は当てはまりません (IP 指定も動きます)。

tunnel mode ipsec ipv4 を忘れると sVTI にならない。 Tunnel0 の既定のトンネルモードは GRE です。tunnel mode ipsec ipv4 を指定しないと、Tunnel0 は sVTI ではなく GRE トンネルになります。ただし tunnel protection ipsec profile を紐づけていれば、それは平文の生 GRE ではなく GRE over IPsec (GRE を IPsec で保護する構成・DMVPN も同系統) になり、暗号化自体は効きます。この場合、sVTI の any-any proxy identity ではなくなる・オーバーヘッドが増える等、sVTI とは挙動が変わるため、sVTI を意図するなら必ずこのモードを指定します。逆に、tunnel protection も付けずにモード指定を忘れると、本当に平文の生 GRE になり暗号化されません。

PFS の DH グループは両端で揃える。 set pfs group14 を片側だけにする、あるいは両端で違うグループを指定すると、rekey 時の SA ネゴが失敗します。両端を同じグループにします。

crypto は Gi2 / Tunnel0 のみに当て、Mgmt (Gi1) には当てない。 4-7 と同じく、管理用インタフェースを暗号化対象に巻き込むと管理接続が壊れます。tunnel source はデータ IF (Gi2) を指定します。

10. 第 4 章のまとめと次章の内容

本節では、IPsec トンネルを実運用に載せる 2 つの方式を比較しました。crypto map (policy-based) が crypto ACL で暗号化対象を選ぶのに対し、VTI (route-based) は Tunnel0 へ routing された通信を暗号化し、動的ルーティングや監視が素直になること、PFS で鍵を定期的に作り直して過去の通信を守れること、そして複数拠点ではトンネル本数がトポロジ設計の論点になることを扱いました。ここで第 4 章 セキュリティ編を振り返ります。

第 4 章は、ネットワーク機器でトラフィックを守る仕組みを 8 節にわたって扱ってきました。全体を貫いていたのは、2 つの軸です。

1 つ目の軸は、第 4 章を通じて繰り返し現れた 「向き」と「状態」 です。4-1 ACL の in/out、4-5 ZBF の zone-pair、4-6 NAT の inside/outside、そして 4-7・4-8 の IPsec の initiator/responder と方向別 SA。第 4 章のセキュリティ機能は、いずれも「どの向きの通信を、どう扱うか」を指定し、通した通信の状態を覚える (ステートフルに動く) という共通の骨格を持っていました。

2 つ目の軸は、扱う対象の階層 です。第 4 章の機能は、守る対象によって 3 つに分けられます。4-1 ACL・4-5 ZBF・4-6 NAT は パケットのヘッダ (アドレス・ポート) を見て、通す・遮断する・書き換えるものでした。4-2 AAA・4-3 802.1X は 通信の主体 (誰が使うか) を認証するものでした。4-4 L2 セキュリティ は足元の L2 での詐称を防ぎ、そして 4-7 IPsec・4-8 Site-to-Site VPN は パケットの中身 を暗号で守るものでした。フィルタ → 認証 → 変換 → 暗号と、守り方の対象が階層を上がっていく構成になっていました。

次章 第 5 章 QoS 編 では、視点が変わります。第 4 章は通信を「通すか・守るか」で制御しました。しかし、帯域が有限なとき、通すと決めた通信の どれを先に通すか は別の問題です。音声やビデオ会議のような遅延に敏感な通信を、大量のファイル転送に埋もれさせないためには、通信に優先順位をつける仕組みが要ります。それを扱うのが QoS (Quality of Service) です。第 5 章では、通信に印をつける マーキング (DSCP)、印に応じて優先的に送り出す キューイング (LLQ)、帯域を超えた通信を抑える ポリシング・シェーピング を、CML 実機で扱っていきます。関連概念を統合しながら QoS を掘り下げていく第 5 章へ続きます。