TCP 443 は本当に役立つのか。サーバーがそこで待ち受けている場合に限る

TCP 443 は前提条件つきの代替手段であり、どんなフィルタもすり抜ける偽装ではない。事業者がすでにそのポートで TCP の待ち受けを公開しており、経路が数時間開いたままの接続を許容するときに役立つ。どちらかが欠ければ、たいていはタイムアウトとして失敗し、タイムアウトはどちらが欠けたかをほとんど語らない。切り替えるべきかは三つの問いで決まり、そのうちポート番号に関するのは一つだけだ。

ポート番号はトランスポートの約束ではない

ポートは端点に名前を与え、TCP はそれを順序づけられたバイト列に変え、OpenVPN がその列の中で何が流れるかを決める。同じ番号のウェブサーバーはまったく別のアプリケーション構成を使うので、443 番ポートを共有してもフィルタから見て似るだけで、それ以上ではない。番号はフィルタが読む手がかりであり、パケットの中身を変える性質ではない。ポートを共有しているから同じものと見なすのが、ここでの混乱のほとんど背後にある誤りだ。

中間装置がポートについて単純な許可か拒否かを決めることはほとんどない。多くは先頭のバイトを検査し、いくつかは宛先を固定し、長く開きすぎた接続をリセットするものもある。だから同じプロファイルが一方のネットワークでは動き、別のネットワークではタイムアウトするのだから、代替手段は約束として信じるのではなく、サポートされた選択肢として試す価値がある。フィルタが通信を調べるとき、ポート番号は最初に見るものにすぎない。

プロファイルに触れる前に待ち受けを確認する

サーバーはそのポートで TCP 用に設定されていなければならず、クライアントのプロファイルも同じトランスポートを要求しなければならない。UDP プロファイルを書き換えて TCP を要求しても待ち受けは生まれず、結果のタイムアウトはポートを落とすファイアウォールと区別できない。事業者自身の TCP プロファイルがあれば、トランスポートごとに別の端点と別の ID 設定を公開するサービスもあるので、それをダウンロードしよう。手作業の編集は統制された試験には向くが、提供者が意図した構成を当てる方法としては悪い。

その一致の両側は設定に現れ、OpenVPN プロジェクトのリンクオプションが両方の形を文書化している。最小の組はこうなる:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

三つの条件が代替手段の価値を決める

第一の条件は、事業者がそのトランスポートをそもそも提供していることで、それがなければ他は意味を持たない。第二は、経路が長寿命のセッションを保つことで、一部のネットワークはポートを丸ごと遮断する代わりに、開いたままの接続をリセットするからだ。第三は、その代替手段が意図された例外なのか、直していない不具合を隠す場当たり的な回避なのかという点だ。

どの条件にも安価な確認がある。どれかで失敗すれば、クライアント側からは同じに見える:

トランスポートを比べる前に、キャプティブポータルのサインインを済ませよう。端末をまだ受け入れていないネットワークは両方のトランスポートを遮断し、その場合の比較はトンネルではなくポータルを測ってしまう。サインインし、通常の閲覧が動くことを確かめ、それから試験を始めよう。

受け入れるコスト: TCP の中の TCP

TCP は失われたセグメントを再送し、その順序を保つ。TCP を使うアプリケーションが TCP トンネルの中で動くと、二つの回復層が同じ損失に反応し、その相互作用が損失のある経路でトンネルを遅く感じさせる。症状はきれいな失敗ではなく遅延と揺らぎであり、遠い側のせいにしやすくなる。結論を出す前に、クライアント側から両方のトランスポートで測ろう。

UDP はこの入れ子を避けるので、事業者は UDP を好み、TCP をあくまで代替として提供する。安定した TCP 接続は到達できない UDP 接続よりはるかに有用であり、比較は良し悪しではなく二つの実際のコストの間で行うものだ。比べている間は端末と接続網を据え置かないと、結果は誤った変数を語ることになる。

クライアントの機能には一方のトランスポートでしか文書化されていないものがあり、代替プロファイルは頼っていた挙動を静かに落とすことがある。TCP プロファイルを単純な差し替えと見なす前に、そのオプションのトランスポート要件を読もう。

別のトランスポートが触れない不具合

期限切れの証明書には依然として時計の確認か更新が要り、拒否されたアカウントには依然として正しい認証情報が要る。見慣れたポート番号は誰も認証しないので、事業者が用意したサーバー ID の確認は残しておこう。応答するポートは、何かが待ち受けていることだけを告げる。

トンネルが上がっても宛先が失敗し続けるなら、残る問題は接続後のルーティングか名前解決であり、トランスポートではない。ポートを巡って午後を消すのではなく、その経路をたどろう。プロファイルはどのトランスポートを試すかを教えるが、UDP の経路がなぜ失敗したかは決して教えない。