ページは開くのにVPNでアップロードが止まる：原因はどれか
サイズ依存の停止は経路MTUの障害に当てはまり、DNS、アプリ側の制限、不安定なトンネルにも当てはまる。四つの観察でどれかを決める。
ページは開き、VPNは接続済みと表示し、ファイルのアップロードは毎回同じ地点で固まる。この説明には、パケットサイズの問題、名前解決の問題、アプリケーションの制限、そして繰り返しリセットされるトンネルという四つの原因が当てはまる。どれも異なる観察で肯定も否定もできるので、判断は原因を推測することではなく、正しい試験を選ぶことになる。
四つの候補と一つの形
ツールを開く前に候補の大半を消せるので、まず失敗の形から見る。一定のサイズで起きる停止は反証されるまでサイズの問題である。ランダムな地点で起きる停止は損失か安定性の問題だ。接続が開く前の失敗は名前の問題である。
四つ目の候補はアプリケーションだ。アップロード制限、リクエストのタイムアウト、プロキシのボディサイズ上限は、ブラウザから見るとネットワーク障害のような失敗を生み、ふつうは停止ではなく拒否として現れる。
何かを試す前に、観察した形を書き留める。「毎回ほぼ同じバイト数で、トンネルを上げたまま止まる」は「アップロードが動かない」よりはるかに強い出発点だ。
そのうえで試験中は経路を固定する。出口、プロトコル、サーバーを同時に変えると、どれにも帰属できない結果になる。一回の実行につき変数は一つ、そして書き留める。
ポリシーに触れる前にサイズを二分する
最も安い識別法は一つの数値を変える試験だ。分割禁止のpingを徐々に大きなサイズで宛先へ送り、自分が管理するファイルを同じサービスへアップロードし、それぞれがどこで止まるかを比べる。
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/upload最初のコマンドは、フルサイズのパケットが経路をそもそも通るかを報告する。MTUが1500バイトなら、分割されないICMPペイロードの最大は1472バイトで、トンネルは内側のパケットが始まる前にその予算からさらに多くを取る。二つ目はアプリケーション層の転送についてサイズと所要時間を与え、実際に重要なのはこの数値だ。
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
二つを合わせて読む。しきい値を超えると失敗する試験と、同じしきい値の近くで止まるアップロードは筋の通った話になる。試験がすべて成功するのに、経路が明らかに運べるバイト数でアップロードが止まるなら、原因はアプリケーションかサーバーであり、MTUをどういじっても変わらない。この否定的な結果は肯定的な結果と同じ価値がある。調査の最も高くつく枝を切り落とすからだ。
次に転送中の安定性を確認する。大きなアップロードの途中で鍵を更新するトンネルはサイズ依存に見えてそうではない失敗を生むので、稼働時間の値がそれを確かめる最も安い方法だ。
修理と回避策のどちらかを選ぶ
証拠がサイズを指すなら、正直な答えが二つと不正直な答えが一つある。正直なのは、必要なICMPフィードバックを許可して経路MTU探索を復活させること、または告知するセグメントサイズを絞って相手に小さいセグメントを送らせることだ。不正直なのは、フォーラムからコピーした値までインターフェースMTUを下げ、何が変わったかを一切確かめないことだ。
選択は自分が何を制御しているかで決まる。自分が運用するネットワークなら、あらゆるプロトコルで仕組みが働き続けるためICMPメッセージを許可するのがよりきれいな修正だ。制御していない経路なら、絞り込みが現実的な選択であり、サーバー全体ではなく狭く適用すべきだ。
証拠がアプリケーションを指すなら、アプリケーションかそのプロキシ設定を直す。413応答とぶら下がった接続は別の失敗であり、後者はたいてい独自の上限を持つプロキシを含む連鎖のどこかでのタイムアウトだ。
いずれにせよ、元の値を保存し、戻したうえで再試験する。うまくいった転送と同時に起きた変更はそれが原因だという証拠にはならず、取り消せることこそが診断と偶然を分ける。
次の障害でも使えるように判断を記録する
四つの事実、つまり観察した失敗の形、試験の結果、行った変更、再試験の結果で足りる。これがあれば、次の人は同じ問題か、同じ症状をまとった新しい問題かを判断できる。
MTUの知見は特定のリンクに固有なので、経路の文脈も記す。自宅では動きホテルで失敗するノートPCには二つの経路があり、片方に施した修正はもう片方については何も語らない。
最後に、「VPNがアップロードを壊した」という要約に抗う。トンネルは動いた場合にも失敗した場合にも存在し、変わったのは経路が運ぶべきパケットのサイズか、転送を止めた地点だった。実際の仕組みを名指しすることが、この記録を役立つものにする。