リモートシェルは応答し続け、小さなプローブにも答えが返る。ところがファイルコピーは這うように遅くなり、誰も指摘できないエラーも出ないまま止まる。より大きなペイロードの ping は即座に再現し、同じ転送はローカルネットワークからは通る。暗号化のどこも遅くはなく、特定のパケットが届いていないのだ。二つの異なる分割が同じ兆候を生み、それぞれ違う証拠を残す。

パケットを分割できる二つの場所

暗号化の前なら、ルーターが大きすぎる内側パケットを分割し、断片ごとに個別に保護できる。暗号化の後なら、分割されるのは完成した外側パケットであり、遠端は何かを復号する前にそれを再組み立てしなければならない。同じ症状でも、受信側の仕事と、こちらが回せるつまみは違う。

この区別が重要なのは、間違った側に向けた修正が、障害を動かさずに数値だけを変えてしまうからだ。インターフェースで拒否されたパケットは外側パケットにすらならないので、外側の設定では決して救えない。

サイズの判断は実際どこで下されるか

トンネルインターフェースは IP MTU を持ち、その値は IPsec の段階が見るよりはるかに早く、大きすぎる内側パケットを拒否しうる。外側ヘッダーのビットを立てても、その以前の判断は見直されない。パケットはすでに拒否されているからだ。だから内側の MTU を上げると、改善どころか悪化することがある。どちらを変える前に、インターフェースの値と外側の振る舞いを読むこと。安い方の変更が症状を説明する側であることが多い。

まずインターフェースの値を確認し、次に外側の振る舞いを見る。二つの数値、二つの段階であり、たいてい責任があるのは片方だけだ。

外側の予算は内側の予算ではない

カプセル化はどれもヘッダーにバイトを費やし、その量はトランスポート、アドレスファミリー、NAT トラバーサルの有無で変わる。ローカルリンクに収まる内側パケットでも、その先の経路に収まらない外側パケットになりうる。オーバーヘッドは仮定せずに測ること。任意のヘッダーはどれも請求に加わるからだ。NAT トラバーサル付きのトンネルは素のものより多く払い、その差は昨日まで動いていた転送を壊すのに十分だ。

外側パケットが分割禁止ビットを運ぶとき、転送できないホップはそれを破棄し、ICMP メッセージを返すべきだ。そのメッセージがどこかでフィルタされると、送信側は再試行を続け、利用者には説明のない停止が見える。この静かな破棄こそ、サイズの問題が速度の問題として報告される通常の理由だ。

IPv6 は選択肢の一つを消す

IPv6 のルーターは経路上で分割しないので、外側パケットは収まるか、Packet Too Big メッセージとともに消えるかのどちらかだ。そのメッセージが唯一のフィードバック経路になり、それを塞ぐと、以後の大きな転送すべてで経路探索が壊れる。IPv4 のルーターはビットが立っていなければ大きなパケットを分割でき、それが別の何かでビットが立つまで障害を隠す。

混在スタックでは同じトンネルが二つのファミリーで違う振る舞いをすることがあり、だから IPv4 での試験一つでは IPv6 の苦情は片付かない。片方のファミリーだけを試す確認は、答えの半分を測らないままにする。

TCP セグメントの方針は万能の答えではない

最大セグメントサイズの制限は TCP フローには効き、問題がそこに限られているなら正当な制御だ。UDP には効かない。DNS、一部の音声プロトコル、そして増え続けるウェブトラフィックの多くは UDP で運ばれている。

適用したうえで、失敗したワークロードを試すこと。UDP のケースがまだ失敗するなら、セグメントの方針は答えではなかったということになり、インターフェースの予算にまだ注意が要る。まず失敗したワークロードのプロトコルを特定し、それからそれに属する制御を選ぶ。

作業の順序

生き残る最大のペイロードを記録し、次にインターフェースの MTU、次に外側パケットが分割禁止ビットを運ぶか、最後に ICMP のフィードバックが送信側に届くかを記録する。この順序なら当て推量なしに障害を絞り込める。観測はどれも時刻と端点を添えて残すこと。経路が変われば四つの数値はすべて動く。

値を一つ変え、元の転送を再試験し、結果を残す。大きなプローブは通るのにアプリケーションで止まるトンネルは、別の問題に移ったのだ。それは書き留める価値のある前進だ。次の人は結論より数値を欲しがる。

関連記事