ネストした VPN トンネル：大きなパケットで内側が止まる理由

DNS は解決し、SSH セッションは維持されたまま、大きなアップロードだけが固まり、同じホストへの ping は今も応答する。この切り分けが示すのは壊れたトンネルではなく、パケットサイズだ。ネストしたトンネルでは、どちらか一方だけでは決して達しないサイズでそれが起きる。内側のセッションは正常で、収まらないパケットを渡されているだけだ。

経路の MTU は実際どこへ消えるのか

カプセル化のたびに、次の層が順番を得る前にバイトを消費する。Ethernet の経路は外側のパケットに 1500 バイトを提供し、外側のトンネルはその内側の何かにアドレスを付ける前に自分の分を取る。推測したオーバーヘッド値は、問題になる分だけ正確にずれる。

層を順に並べる：アクセス経路、外側のトランスポート、外側のトンネル、内側のトランスポート、内側のトンネル、アプリケーション。各ヘッダーは一度だけ数え、UDP はトンネル自身のヘッダーとタグから切り離しておく。

WireGuard の二層を一度だけ数える

IPv4 のアクセス経路に、WireGuard トンネルを一つ入れ子にする。外側の層は IPv4 の 20 バイト、UDP の 8 バイト、そして WireGuard のデータヘッダーと認証タグの 32 バイトを消費する。その内側で、内側のトンネルは自身の 20 バイトの IPv4 ヘッダーと 8 バイトの UDP ヘッダーを、二度目の 32 バイトの WireGuard オーバーヘッドの前に必要とする。残りには IPv4 ヘッダー、TCP ヘッダー、データが収まる。外側が IPv6 の経路なら 20 ではなく 40 を消費し、1320 が残る。

計算は 1340 バイトに落ち着く。同じ規則で一層だけなら TCP ペイロードに 1400 が残り、これは 1500 から 20、8、32、20、20 を引いたもので、60 バイトの差は二つ目のトンネルが加える内側のカプセル化そのものだ。

1400 をネストした経路に当てはめると、内側のトンネルは 60 バイト足りなくなり、それが必要になるほどパケットが大きくならない限り見えない。パディングやプロトコル自身のフラグメンテーションオプションでも数字は動くので、表を信頼してほしい。

MTU、MSS、フラグメンテーションは別々の場所で働く

インターフェースの MTU はインターフェースが送出するものを制限し、TCP の MSS クランプは TCP の相手が送ろうとするものを変える。 クランプは TCP セッションを直す が、大きな UDP データグラムには何もしないままで、だからあるアプリケーションでは修正が成功したように見え、次のものでは静かに外れる。プロトコル自身のフラグメンテーションオプションは、独自の失敗を伴う第三のレバーだ。インターフェースの MTU はよく使われる最初の一手で、最も大雑把なものだ。

ブリッジ型とルーティング型のトンネルは異なるフレームを運ぶので、別の構成の数値はほとんど当てはまらない。経路 MTU 探索は、 RFC 8201で説明されているとおり、それが依存する ICMP メッセージが通過を許される間だけ役に立つ。

足りない層を見つける

要件が比較を許すなら、ネストする前に各トンネルを単独で検証せよ：固定サイズのプローブがそれを決める。 ping -M do -s 1472 -c 3 10.8.0.1 その層の内側で 1500 バイトの IPv4 パケットを丸ごと送る。二層目を加えて同じプローブを繰り返せば、失敗は既知の変更に帰属する。

転送が止まったら、文書化されたパラメーターを一度に一つだけ変え、失敗するサイズを記録する。ネストした経路の再帰はパケットサイズの問題を午後一つ分の労力で済むほど精巧に模倣しうるので、戻り経路も確認すること。フィルターされた ICMP 応答は本当の上限を隠すので、推論よりもプローブが重要だ。

次の人が見つけられる場所に予算を書く

層ごとに一行の表は、経験則より長持ちする。トンネル図のそばに置いて、圧力の下で誰も計算をやり直さないようにする。

トンネルが増えれば依存も増えるので、ロールバック計画は予算のそばに置く価値がある。数字がまだ合わないなら、また推測するのではなく経路を測る。目指すのは記憶する数字ではなく、説明できる数字だ。