VPN が遅いのはなぜ？四つの区間に分けて試す

通話が途切れ、ダウンロードが這うように遅く、アップロードが途中で止まる——これは一つのラベルの下にある三つの別の不満だ。何かを測る前にどれを追っているかを決めれば、調査の残りが省ける。その後は経路の一区間だけを一度に変え、同じ作業を後でもう一度行う。

以下の順序が作業から外側へ進むのは、トンネルがその下で欠けている帯域を補えないからだ。

測る前に「遅い」の意味を決める

低く安定した速度、鋭い跳ねを伴う高い遅延、決まったサイズで完全に止まる転送は、一つの障害の変形ではない。それぞれ別の区間、つまりスループット、経路そのもの、あるいはパケットサイズの上限を指している。実際に困っている作業を選び、それを基準にするのは、速度テストが一括転送を測るもので、ビデオ通話とはまったく違う振る舞いをすることがあるからだ。エンドポイント、プロトコル、時間帯、そして自分にとって重要な数値を書き留めておく。

その記録がなければ、後の比較はすべて印象論の言い争いになる。

まずアクセス網を確認する

自分の大きな転送を止めてから、トンネルが関わる前にローカル回線を測る。無害な作業と比べ、複数の保護を一度に切るのではなくクライアントの kill switch 手順に従い、両方の実行で同じ宛先を保つ。速度テストの提供元は、見える位置が変わると別の測定サーバーを割り当てることがあり、比較は二つの別のサーバーのテストになってしまう。

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

基準がすでに悪ければ、仕事は Wi-Fi、ルーターの負荷、あるいはアクセスサービスの側にある。有線でのテストやアクセスポイントの近くでの固定位置は、弱い無線リンクと混雑した上り回線を切り分ける。トンネルが何をしても、アクセス回線が届けていない容量は増えない。

出口を変え、次に転送方式を変える

デバイス、ネットワーク、プロトコルを固定して、二つ目のエンドポイントを試す。位置リストから妥当な都市を選ぶが、最も近いラベルが最良の経路を意味すると決めつけない。一つの出口が遅く他が問題なければそのホストか経路を調べる価値があり、一つのデバイスで全出口が遅いのに別のデバイスが問題ないなら、クライアントの方が疑わしい。

サービスが両方のプロファイルを提供している場合は、UDP 上の OpenVPN と TCP 上の OpenVPN を比べる。対話的な作業では UDP が通常の出発点であり、TCP は UDP の通信をまったく通さないアクセス網では助けになる。TCP トンネルはストリーム内で再送して損失を回復するため、パケットを落とす回線では遅く感じることがあり、OpenVPN のパフォーマンス トラブルシューティングのメモにも、ほかの設定をいじる前に読むべき同じトレードオフが書かれている。プロファイルの「udp」という語を「tcp」に書き換えても、サーバーが一度も開いていないリスナーは作れない。

次を試す前に、役に立ったプロファイルを保存する。そうしないと後で調子が悪くなったとき、どの編集が改善をもたらしたのか分からなくなる。

デバイスと症状を一緒に読む

転送の後にではなく転送中にプロセッサの負荷を見るのは、暗号化のコストが通信量に比例し、家庭を支える小さなルーターが自分のクライアントを動かすノート PC とは別の機械だからだ。別の VPN、仮想マシン、ネットワークフィルターが同じ経路に座って通信の一部を奪うこともある。ベンチマークを良く見せようとして認証の確認や kill switch を外さずに、ソフトウェアを最新に保つ。小さな要求は成功するのに大きなアップロードが一定のサイズで止まるなら、次は MTU の確認だ。

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

トンネルが繰り返しリセットされるなら、再接続するトンネルは経路ではなくハンドシェイクを測っているのだから、どんなスループットの数値を解釈する前に切断を直すべきだ。変更のたびに元の作業を繰り返し、結果を残す。それでも通話が壊れるなら、速くなった速度テストは最初の不満を解決していない。