VPN ポート要件：比較の前に書く三行

VPN サービスのポート一覧は、それが重要かどうかを決める細部、つまり接続を始めるのは誰かという点を欠いたまま比較ページ間でコピーされる。外向きの TCP 443 を許可する規則は、別のホストがあなたのマシン上の待ち受けに到達できるかについては何も語らない。単一のプランを比較する前に、三つの要件を別々に書き、あなたの作業に本当に必要なものを印で示そう。その用紙があれば、ほとんどの比較は一つの短い問いに収まる。

どのポート一覧を読む前にも、要件を分けておく

三行でほぼすべての場合は覆える、つまりトンネルの外の宛先に到達すること、他の誰かが内側に接続できるように何かを公開すること、トンネル自体を運ぶことだ。各行はそれぞれ別の理由で破綻し、一つを満たす提供者の方針が残り二つをそのままにしておくこともある。作業を正しい行に振り分けるのに五分かかり、後での口論を省ける。

マーケティングの文言は三行をわざと曖昧にする。P2P の許可は宛先の方針を述べ、専用アドレスはアドレスを述べ、ポート制限がないという主張はたいてい、プランがそれらを列挙していないという意味だ。これらの言い回しはどれも他の行には答えていない。

具体的な流れを一つ選び、開始側、転送、ポート、アドレスファミリー、方向という文として書く。夜間のバックアップクライアントが遠隔のホストへアップロードするのは外向きだけである。机の上のゲームサーバーに友人が参加するのは内向きだ。両方を一つのトンネルに通すなら、用紙には二行とも必要で、その間の妥協ではない。

外向きのアクセスはトンネルではなく宛先方針で失敗する

翻訳するゲートウェイを通る外向きの通信は状態を作り、内部のアドレスとポートからの最初のパケットが変換エントリを作って応答がそれに一致する。これが RFC 3022 に記述された対応付けの挙動である。この仕組みがあるからこそ、ブラウザのタブはポート要求を一切出さずに動くのが普通なのだ。

それでも二つのことが破綻を招く。出口ノードが乱用可能と見なす宛先やポート番号を濾過することがあり、アプリケーションが出口方針の想定しなかったポートで待ち受けていることもある。内向きの規則ではなく宛先の組について尋ね、TCP と UDP では別の答えを期待しよう。

論じる前に測る。トンネルの後ろに置くマシンで、トンネルを切った状態と入れた状態で一度ずつ実行する：

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com

同じコマンド、同じ宛先、二つのトンネル状態は、運用者に 行動に移せる前後の比較 を与える。文書用アドレスを実際に必要なホストに置き換えよう、大事なのは比較が繰り返されることで、どれかの数値が見栄えよく見えることではない。

内向きの公開には対応付け、アドレス、寿命が要る

外側の何かが公開側で配送先を知らない限り、あなたの待ち受けに接続を始めることはできない。運用者が保持する固定ポート予約、クライアントが UPnP、NAT-PMP、PCP を通じて要求する対応付け、経路付けされた公開アドレスは、三つの異なる製品であり、三つの異なる限界を持つ。

どれについても、どのプロトコルか、どの外部ポートか、外部ポートはローカルのものと違ってよいか、どのアドレスファミリーを覆うか、対応付けは再接続の後どれだけ残るかを尋ねる。運用者に結び付いた予約は、そのセッションが終われば消え、プランのページが何を言っていても関係ない。

まずローカル側の半分を確かめる理由は、死んだ待ち受けと遮断された内向き経路が外からは同じに見えるからだ：

ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ローカルの要求が 200 を返し、あなたが制御しないネットワークからの要求がまだ時間切れになるなら、隙間は公開側にある。アプリを名前で説明する代わりに、運用者にプロトコルと外部ポートを伝えるべき瞬間だ。

トンネル自身の搬送は別の問いだ

搬送ポートは問題の最小部分であり、最も調べやすい。既定値はプロトコルごとに異なり、クライアントが交渉できることはどのプラン記述よりも重要だ。

外向きの UDP を捨てるネットワークは TCP 443 のトンネルを受け入れ、UDP のトンネルを拒むので、退避モードは要件の用紙に属する。搬送を変えてもトンネル内のアプリケーションのポートは動かず、宛先方針も広がらず、それらはそれぞれの行に残る。

断片化は、そこにいる間に一度試す価値がある、接続した後に大きな転送で止まるトンネルはたいてい閉じたポートではなく誤った MTU を持つからだ：

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

Windows では同じ検査は ping -f -l 1400 203.0.113.10 だ。通過する最大サイズより下にトンネルの MTU を設定し、失敗した転送をもう一度試す。

プランに払う前に三行を検証する

三つの行を一枚のページに置き、各セルを約束ではなく測定結果で埋める。そのページのローカル側の半分は、これらのコマンドで一分ほどで作れる：

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10

出力をチェックリストとして読む。トンネルが上がっている状態で宛先が応答すれば、外向きは機能している。内向きは、あなたのネットワークの外のホストが外部ポートの待ち受けに到達したときにだけ機能する。搬送は、あなたのアクセスネットワークが許すプロトコルでハンドシェイクが完了したときに機能する。

二つの習慣が用紙を正直に保つ。各結果の横に日付とクライアントの版を記録する、提供者の方針もクライアントの既定値も動くからだ。次に、その流れに資する最も狭い対応付けを求める、すべてを開く要求はたいてい技術的な答えではなく拒否や追加販売を招くからだ。