VPN 経由の ping：エコー応答の規則が戻り経路を取り逃す理由

VPN 越しにホストへ ping を送ると、要求はある ICMP タイプで出て別のタイプで戻り、これだけで、ポートで書かれたあらゆる規則が混乱する。エコー交換には戻り規則へコピーできる宛先サービスポートが存在せず、対称性を期待するフィルターは、要求が素通りする間に応答を落とす。修正は、パケットを実際の姿のまま読み、経路のどの境界が判断しているかを見極めることから始まる。通常は二つの層が働き、三つ目が黙って応答を捨てている。以下の節では、パケットが出会う順にそれらを分ける。

変わるのはポートではなくタイプ

エコー要求は ICMP タイプ 8、コード 0 で、識別子とシーケンス番号を運ぶ。応答はタイプ 0、コード 0 で、識別子とシーケンスは同じまま、IP の端点が入れ替わる。これらのフィールドを定義するのは RFC 792 であり、送信者が応答を自分の要求と照合できるのは識別子のおかげである。

欠けているものも同じくらい重要で、TCP も UDP もヘッダーがないため許可すべきポートは存在しない。エコー応答にポートを指定する規則は、決して存在しないパケットを記述している。これは VPN の ping チケットで最も多い誤りだ。規則は具体的に見え、何にも適用されず、障害を元の場所にそのまま残す。

三つの文脈がパケットを決める

ping が遠隔 LAN のホストを狙うなら、要求はゲートウェイが転送しなければならない。ゲートウェイ自身に属するアドレスを狙うなら、ローカルの入力経路で終わる。ゲートウェイ自身が ping を始めるなら、パケットは自分の出力経路から始まり、転送の判断をまったく通らない。

これら三つの文脈は規則の連鎖もカウンターも異なり、それらを一つとして扱うことが、「ファイアウォールは ICMP を許可している」のに ping が失敗する理由である。外側のトンネルは四つ目の文脈であり、VPN リスナーを許可しても、カプセル化を解いた内側の要求が自動的に許可されるわけではなく、内側の許可は外側のトンネルが上がっているかについて何も語らない。

ステートフルとステートレスのフィルターは応答を別に扱う

要求が出ていくのを見たステートフルなファイアウォールは、応答をそのフローに対応づけ、二つ目の規則なしで通すことができる。 ステートレスなフィルターにはそのような記憶がないため、戻り方向には独自の明示的な許可が必要で、送信元と宛先を入れ替える。

何かを書く前に、その製品が実際にどちらのモデルを実装しているかを確認する。エコー要求の規則が必ずエコー応答を覆うわけではなく、ICMP クエリを追跡する製品でも、別のインターフェースに届く応答には別のポリシーを適用することがある。

許可する範囲を限定する。どこからでもすべてのエコー応答を許可することは、ステートフルな関連づけを完了することと同じではないし、タイプ番号は送信者を認証しない。

変換は識別子も変える

送信元変換が意図的なものなら、遠端のタプルはクライアントが送ったものと一致しない。NAT はアドレスとともに ICMP クエリの識別子も変換できるため、両側で同じ番号が見えるべきだと主張すると、偽の不一致を生む。

代わりに、変換器が報告するマッピングで対応づける。識別子を書き換える変換器は、クライアントが記録した番号を保たないので、番号ではなくマッピングを同一性として扱い、そのうえで識別できる要求を一つ経路に沿って追う。期待した送信元で宛先に届くことを確認し、宛先が応答を出したことを確認し、その応答の戻り経路を追い、ゲートウェイのカウンターが増えるのを見るだけでなく、クライアントが実際に受け取ったことを確認する。

ICMP のエラーをエコーのポリシーに折り込まない

経路 MTU 探索が使う「フラグメンテーションが必要」のメッセージはエコー応答ではなく、そのペイロードは引き金となったパケットを引用している。エコーだけを許可する規則がこうしたエラーを黙って捨てると、サイズの問題がぶら下がった接続に変わり、これは役立つどころか逆である。

同じ注意はアドレスファミリーにも当てはまる。ICMPv6 は異なるメッセージタイプを使い、IPv4 にはない必須の機能を運ぶため、これらの番号を IPv6 の規則にコピーするのは単純に誤りである。

エコー交換が動いたら、実際のアプリケーションを別に試す。ping の成功は、一つのプロトコルが一つのサイズで一つの宛先へ往復できることを示すだけで、HTTPS や SMB、その他のフローが許可されているとみなす免許ではない。