OpenVPN は自宅ではつながるのに、あるネットワークではつながらない：UDP か TCP か

同じプロファイルが自宅では接続でき、ホテル、キャンパス、支店のネットワークでは停止する。認証情報は変わっていないので、注目すべき変数は経路、つまりOpenVPNがパケットを読む前に何が起きているかだ。四つの候補原因を、試験できる順序で比較するほうが、証明書を推測するより優れている。それぞれが異なる痕跡を残し、その痕跡が原因を切り分ける。

どの段階で失敗したかが、どの比較が重要かを決める

クライアントのログには、どこまで進んだかがすでに記録されている。TLS 鍵のネゴシエーションがタイムアウト内に発生しなかった、という行は、最初のパケットが出たが使える応答が戻らなかったことを意味し、経路を示唆する。証明書の拒否はまったく違って見える。応答が届き、その後に特定の検証エラーが理由を示す。再試行ループの直前の最後の行を記録しておくこと。それがネットワーク間で比較する値になる。

後からではなく、再試行しながら取得する。クライアント側では tcpdump -ni any udp port 1194 が、応答がそもそも返ってくるかどうかを示す。自分が管理するサーバーの WAN インターフェースで同じことを繰り返すと、そのパケットがそもそも遠端に届くかがわかる。

片方向のトラフィックは、ここで得られる最も有用な結果だ。断続的な不満を調査すべき方向へ変えてくれる。キャプチャファイルは保存しておくこと。同じ問題の次の報告は、説明より証拠のほうが早く閉じられる。

UDP フィルタリングと閉じたポートの比較

多くのアクセスネットワークは持続的な UDP を疑わしいとみなし、一部の ISP も同調する。閉じたポートはクライアント側から同じ沈黙を生む。違いは選択性だ。フィルタはどの宛先やポートを落とすかにうるさく、閉じたポートはそのポート宛てのすべてを拒否する。

ポート 443 の TCP プロファイルが通常の回避策だ。普通の HTTPS フローに似ており、ほとんどのキャプティブポータルや出口フィルタを通る。二つの条件が必要だ。サーバーは proto tcp-server で待ち受け、クライアントは proto tcp-client で一致し、運用者がその代替エンドポイントを公開していること。動作する UDP プロファイルを書き換えて TCP 443 と名乗っても、反対側で何も待ち受けていなければ何も得られない。

閉じたポートは検閲の問題ではなく設定の問題だ。家庭用ルーターの後ろにあるサーバーは UDP ポートの転送が必要で、ルーターのファイアウォールがそれを許可しなければならない。ポートが一度も許可されていなければ、認証情報に関係なくすべてのクライアントがネゴシエーションで失敗し、障害はネットワークではなくサーバーについていく。

古いプロトコルはこの軸では不利だ。PPTP は TCP 1723 に加えて GRE を必要とし、GRE はポートではなく IP プロトコル 47 なので、通常のポート転送では表現できない。

スイッチがパケットを落としている場合

管理スイッチは意図的にトンネルを落とすことがある。一部の HPE および Aruba モデルは、詳細セキュリティ設定に UDP フラッド保護コントロールを公開しており、Prevent UDP Blat Attack と表示されることもある。それが有効になると、スイッチの後ろのサーバーは何も応答せず、すべてのクライアントが同じようにタイムアウトする。それを解除して実行中の設定を保存するだけで修理は完了するが、スイッチが実際に経路上にあると確認してからだ。

反証が、スイッチによるドロップとプロバイダーによるブロックを分ける。ISP にチケットを切る前に、インターフェースカウンターとフラッド保護ログを読む。DoS やフラッド保護を備えたコンシューマールーターも同じ形で失敗し、UDP アイドルタイムアウトが短いミドルボックスも同様だ。決して完了しないハンドシェイクはドロップを示し、数分の静寂の後に死ぬトンネルはタイムアウトを示す。

プロファイルを変更する前に、クライアントとサーバーの間のすべての機器を書き出す。間違った層に適用した修正は、次のネットワークまで正しく見える。その一覧は、次の技術者が調査全体を繰り返さずにどこを見るべきかも教えてくれる。

DNS 障害に見えるアドレスの重複

10.0.0.0/8 の内側で番号付けされたアクセスネットワークはトンネルプールと重複することがあり、リゾルバーは通常そのプールの内側にある。ノート PC が Wi-Fi で 10.184.178.50 のようなアドレスと /8 マスクを受け取ると、すべての 10.x 宛先は定義上ローカルになる。10.4.0.1 宛てのパケットは LAN へ行き、トンネルは上がったままで、名前解決が失敗する。

ip addr は重複を一目で示し、ip route get 10.4.0.1 はパケットが実際にどこへ配信されるかを示す。目に見える症状がリゾルバーの失敗であるため、これは何度も DNS 変更を繰り返しても生き残ることが多い。

プールに番号を振り直すか、そのアクセスネットワークを対象外に保つ。クライアント側の設定では重複から回復できない。

TCP フォールバックと経路の修正のどちらを選ぶか

経路を制御できず、ユーザーが今日作業する必要があるなら TCP フォールバックを選び、そのコストを受け入れる。TCP の中の TCP は損失のあるリンクでひどく振る舞い、フォールバックには自分が運用するリスナーが必要だ。ブロックが自分の所有するインフラ上にあるなら経路の修正を選ぶ。ファイアウォール規則のほうが二つ目のリスナーより安い。いずれにせよ、層を順にたどる。リンク、外側のトランスポート、ネゴシエーション、内部ルーティング。そのネットワークで失敗した段階だけが重要な事実だ。

結果はユーザー単位ではなくネットワーク単位で記録する。同じ障害の次の報告は、証明書の理論ではなく既知の段階から始まる。その記録は、必要になったときの恒久的な二つ目のリスナーを正当化するものでもある。