IPsec VPNをフルトンネルで利用すると、VPN接続前には表示されていた会社側のゲートウェイやISP網がtracerouteから見えなくなり、VPN終端側から先の経路だけが表示されることがあります。これはIPsecトンネルモードにおける「内側（Inner）のIPパケット」と「外側（Outer）のIPパケット」を分けて考えると理解しやすくなります。
結論からいうと、トンネル区間を運ばれている間、途中のルーターが通常転送しているのはVPN終端を宛先とするOuter IPパケットであり、その区間ではOuter IPヘッダのTTLがホップごとに減少します。一方、カプセル化されたInner IPヘッダは基本的にトンネル内部をそのまま運ばれます。
ただし「tracerouteは常にIPsecトンネル内だけを見る」と単純化すると少し不正確です。tracerouteがどの区間を表示するかは、プローブのTTL、IPsecのカプセル化・デカプセル化処理、ICMPの扱い、VPN方式や実装などによって決まります。ここではRFC 4301などの仕様を基に、フルトンネル時のパケットの動きを整理します。
- IPsecトンネルモードにはInner IPとOuter IPがある
- なぜVPN接続後のtracerouteに会社GWやISP網が出にくいのか
- Inner TTLはトンネルの物理ホップ数だけ減り続けるわけではない
- Outer IPのTTLは会社GWやISPを通るたびに減少する
- VPN終端手前のミラーポートではOuter IPヘッダを確認できる
- 各ホップでOuter TTLが減る様子を直接確認するには複数地点が必要
- L2ヘッダは各リンクごとに変わるという理解でよい
- Inner IP・Outer IP・L2を3層に分けると理解しやすい
- 「traceroute＝Innerの経路」と言い切る場合の注意点
- まとめ：IPsecではInner TTLとOuter TTLを分けて考える
IPsecトンネルモードにはInner IPとOuter IPがある
IPsecのトンネルモードでは、元のIPパケット全体を内側に収容し、その外側にトンネル通信用の新しいIPヘッダを付加します。RFC 4301では、Outer IPヘッダの送信元・宛先はトンネルのエンドポイントを示し、Inner IPヘッダの送信元・宛先は元の通信における送信元・最終宛先を示すと説明されています。[参照] RFC 4301 Security Architecture for IP
例えばスマートフォンからGoogleへ送るパケットを、自宅のVPNゲートウェイまでIPsecで運ぶ構成を単純化すると、論理的には次のように考えられます。
| ヘッダ | 送信元 | 宛先 | 役割 |
|---|---|---|---|
| Outer IP | VPNクライアント側 | 自宅VPN終端 | IPsecトンネルをインターネット上で運ぶ |
| ESPなど | － | － | IPsecによる保護 |
| Inner IP | スマートフォン側の論理アドレス | 本来送りたい通信 |
ESPトンネルモードで暗号化されていれば、会社GWやISP側の途中ルーターがGoogle宛てのInner IPヘッダを通常のルーティング対象として見るわけではありません。途中のネットワークが転送対象として扱うのは、VPN終端を宛先に持つOuter IPパケットです。
なぜVPN接続後のtracerouteに会社GWやISP網が出にくいのか
通常のIPv4 tracerouteは、TTLを小さい値から段階的に増加させたプローブを送り、途中のルーターから返されるICMP Time Exceededなどを利用して経路を調べます。IPv4ルーターは転送時にTTLを減少させ、TTLが尽きた場合には原則としてパケットを破棄し、ICMP Time Exceededを返します。[参照] RFC 1812 Requirements for IP Version 4 Routers
VPN接続前なら、Google宛てのプローブ自体が会社GW、ISP、インターネット上のルーターを直接通過します。そのため、TTL=1なら近いルーター、TTL=2ならその次というように、会社側からGoogleまでの経路が観測できます。
一方、フルトンネルVPNではGoogle宛てのプローブがIPsecに収容されます。会社GWやISP網を通過する際に転送されている外側のパケットの宛先はGoogleではなくVPN終端です。そのため、Inner側のtracerouteで設定したTTLが会社GWやISPの各ルーターを通るたびにそのまま1ずつ減る、という動作にはなりません。
Inner TTLはトンネルの物理ホップ数だけ減り続けるわけではない
ここがIPsecとtracerouteを理解するうえで重要です。例えば会社から自宅VPN終端まで、物理的には会社GW→ISPルーターA→ISPルーターB→自宅回線という複数のL3ホップが存在するとします。
トンネル区間では、途中の各ルーターがInner IPパケットを通常のGoogle宛てパケットとして転送しているわけではありません。Outer IPパケットを転送しています。したがって途中ルーターでホップごとに減少するのはOuter TTLです。
RFC 4301でも、Inner IPヘッダはトンネル出口までの配送中には原則として変更されず、TTLなどについてトンネル処理上の規則が定められています。つまり「物理的にISPルーターを5台通ったからInner TTLも5減る」という理解にはなりません。[参照] RFC 4301 Section 5.1.2
Outer IPのTTLは会社GWやISPを通るたびに減少する
Outer IPパケットはVPNだから特別な転送をされるわけではなく、IPネットワーク上では通常のIPパケットとしてVPN終端へルーティングされます。そのため、IPv4なら各L3ルーターでOuter IPヘッダのTTLが減少します。
例えばVPNクライアントが生成したOuter IPヘッダのTTLが64だったと仮定し、VPN終端までに5つのルーターを経由したなら、単純な例ではVPN終端付近で観測されるOuter TTLは59程度になります。ただし、初期TTLはOS・VPN実装・機器によって異なるため、受信時のTTLだけから正確なホップ数を断定することはできません。
また、Outer TTLが途中で尽きれば、そのOuter IPパケット自体がそこで破棄されます。つまりトンネルが途中のネットワークを「TTL的に無視して瞬間移動している」わけではありません。Inner側から途中の物理経路が見えにくいだけで、Outerパケットは通常のIPルーティングを受けています。
VPN終端手前のミラーポートではOuter IPヘッダを確認できる
自宅VPNルーターのWAN側手前など、まだIPsecがデカプセル化される前の適切な観測点でスイッチのSPAN・ポートミラーリングを行えば、VPN終端へ到着するOuter IPパケットをパケットキャプチャできます。
ESPを直接使用するIPsecなら、キャプチャ上ではOuter IPヘッダに続いてESPが確認できる構成があります。NAT Traversal（NAT-T）が使われている環境ではUDPでESPがカプセル化されるため、見え方は異なります。したがって「必ずIPヘッダの直後にESPがある」とは限りません。
Wiresharkなどで該当パケットのOuter IPv4ヘッダを開けばTTLフィールドを確認できます。ただし、その地点で1回キャプチャしただけでは「会社GWで64→63、ISPで63→62…」という各ホップでの変化を直接観測したことにはなりません。確認できるのはその観測地点に到着した時点のOuter TTLです。
各ホップでOuter TTLが減る様子を直接確認するには複数地点が必要
VPN終端直前でOuter TTLが59だったとしても、送信時のTTLを同時に観測していなければ、途中で何回減ったかを厳密には判断できません。初期TTLを推測してホップ数を概算することはできますが、実測とは区別する必要があります。
例えば会社側でカプセル化直後のOuter IPパケットをキャプチャしてTTL=64、自宅VPN終端直前で同じフローをキャプチャしてTTL=58だったなら、その差から途中のL3転送によってTTLが減少したことを実測しやすくなります。
一方、ISP内部の各ルーターでパケットキャプチャできるわけではないため、一般利用者が「Aルーターで63、Bルーターで62、Cルーターで61」と全区間をキャプチャすることは通常できません。Outer側の経路そのものを調べたい場合は、VPN終端アドレスに対するtracerouteなど、別の観測方法を組み合わせると理解しやすくなります。
L2ヘッダは各リンクごとに変わるという理解でよい
IPルーティングとEthernetの関係については、IPパケットを次のL3ホップへ転送するとき、同じEthernetフレームがインターネットの端から端まで維持されるわけではありません。ルーターは受信したL2フレームからIPパケットを処理し、次のリンクに適したL2フレームとして送出します。
例えばEthernet区間なら、あるLAN上では送信元MACが端末、宛先MACがデフォルトゲートウェイになります。ルーターを越えた次のEthernet区間では、その区間に対応する送信元・宛先のL2アドレスになります。
したがって、IPsecのOuter IPパケットも通常のL3転送を受ける以上、Ethernet区間ではL2ヘッダが各リンクに応じて作り直されるという基本理解で問題ありません。ただし、インターネット上のすべての区間がEthernetとは限りません。「各ルーターが必ずEthernetのMACアドレスを書き換える」というより、各出力リンクのL2方式に応じて再カプセル化されると表現するほうが正確です。
Inner IP・Outer IP・L2を3層に分けると理解しやすい
フルトンネル時の通信は、次の3つを分けて考えると整理できます。
| 見る対象 | 主な役割 | トンネル途中での変化 |
|---|---|---|
| Inner IP | スマホからGoogleなど本来の通信 | トンネル内部を保護された状態で運ばれる |
| Outer IP | IPsecトンネルのエンドポイント間を配送 | 途中のL3ルーターでTTLが減少 |
| L2ヘッダ | 現在のリンク上で次のノードへ配送 | リンク・ホップに応じて再構成される |
イメージとしては「Inner IPパケットを箱に入れ、その箱にVPN終端まで届けるOuter IPの宛名を付ける」と考えると分かりやすいでしょう。会社GWやISPは箱の中のGoogle宛てパケットを通常ルーティングするのではなく、外側の宛名を使ってVPN終端方向へ配送します。
そして各リンクで実際に運搬するためのL2フレームは、その区間ごとに用意されます。この3階層を混同しないことが、VPN時のtracerouteやパケットキャプチャを理解するポイントです。
「traceroute＝Innerの経路」と言い切る場合の注意点
実用上は「VPN接続後のGoogle向けtracerouteでは、VPN出口以降のInner側の経路が見える」と理解すると分かりやすいのですが、厳密にはtracerouteの結果はVPN実装やICMP処理などにも依存します。
途中のルーターがICMPを返さない、ファイアウォールが遮断する、MPLSなど別のネットワーク技術が使われる、NATが介在する、といった理由でもホップは非表示になります。そのため、tracerouteで会社GWやISPが表示されないという結果だけを根拠に、パケットの詳細な処理方式まで断定することは避けたほうがよいでしょう。
検証するなら、VPN接続前のGoogle向けtraceroute、VPN接続後のGoogle向けtraceroute、VPN終端のグローバルIP向けtraceroute、会社側でのキャプチャ、VPN終端WAN側でのキャプチャを比較すると、InnerとOuterの違いがかなり明確になります。
まとめ：IPsecではInner TTLとOuter TTLを分けて考える
IPsecフルトンネル時に会社GWやISP網がGoogle向けtracerouteから見えなくなる現象は、Inner IPとOuter IPを分けて考えることで説明できます。トンネルモードでは本来のGoogle宛てIPパケットがInner側となり、その外側にVPN終端を宛先とするOuter IPヘッダが構成されます。
会社GWやISP網を通過する際に各L3ルーターが転送し、ホップごとにTTLを減少させる対象はOuter IPパケットです。Inner IPパケットがISPの各ルーターをGoogle宛てとして直接ルーティングされているわけではありません。
また、VPN終端直前の適切なミラーポートでキャプチャすれば、デカプセル化前のOuter IPヘッダや到着時点のTTLを確認できます。ただし、その1地点だけでは途中の各ルーターでTTLが何から何へ変化したかを直接観測したことにはならない点に注意が必要です。
L2についても、Outer IPパケットが同じEthernetフレームのまま会社から自宅まで届くわけではありません。ルーターを越えるたびに次のリンクに適したL2カプセル化が行われます。したがって、IPsecを理解するときは「Inner IP＝本来の通信」「Outer IP＝トンネル区間の配送」「L2＝各リンク上での配送」という3段階に分けると、tracerouteとパケットキャプチャの結果を正しく読み解きやすくなります。
コメント