ポートフォワーディングとポートトリガーは、ほとんどの家庭用ルーターで同じメニューに並んでいる。だから二つは一つの仕事をこなす二通りの方法として扱われがちだ。フォワーディングは静的ルールである:WAN ポートへの内向き接続は、他に何が起きていようと関係なく、固定の内部アドレスとポートへ変換される。トリガーは条件付きだ:ルーターは外向き通信を監視し、一致する接続が出てから初めて内向きマッピングを開く。VPN サーバーは相手が先に接続してくるのを待つ。つまりその条件こそ、決して満たせない唯一のものだ。

寿命の違う二つのルール

IPv4 の NAT はステートフルだ。内部のホストがパケットを外へ送ると、ルーターは返信が戻ってこられるようマッピングを作る。どのマッピングにも一致しない内向きパケットは破棄され、この挙動が更新されていないデスクトップをインターネットから遠ざけている。フォワーディングは手作業で追加する恒久的な変換エントリだ。トリガーは通信パターンに見張られた一時的な穴である。

実際の違いは時間だ。フォワーディングは保存した瞬間から、誰かが削除するまで存在する。トリガーされたマッピングはトリガーが発火してから存在し、アイドルタイマーで閉じる。家庭用機器では分単位で測られ、再起動では即座に閉じる。

抽象的な意味でどちらが安全ということはない。フォワーディングは一つのポートを常時露出し、トリガーは特定の外向き通信の後でだけ露出する。見知らぬ相手からの最初のパケットを受け入れなければならないサービスには、二つのうち片方しか当てはまらない。

トリガーがサーバーを公開できない理由

VPN サーバーは設計上受け身だ。カフェのノート PC でもモバイルデータのスマートフォンでも、相手が最初のパケットを送るが、ルーターにはそれに対応するマッピングがない。内部からトリガーポートへ通信を始めたものは何もないので、ルールは決して発火せず、ハンドシェイクが始まる前に接続は死ぬ。

トリガーが機能しているように見える場所では、トリガーポートに別の何かが通信を生んでいる:LAN 上のクライアント、監視プローブ、あるいはサーバー自身の外向きチェックだ。するとマッピングはその一つのホストにだけ開き、通信が止まれば閉じる。次の外部の相手はまた失敗し、最初の成功だけがログに残って証拠のように見える。

トリガーは通常、単一ホスト向けでもある。多くの実装は一度に一つの内部機器しかマッピングを保持できない。複数の相手に応答すべきサーバーには、まさに不適切だ。この機能は、外向きに制御接続を開き、二つ目のポートで内向きデータを期待するアプリケーション向けに作られたもので、今もその形に合っている。

フォワーディングが実際にマッピングするもの

フォワーディングは一つの変換エントリだ:WAN ポートとプロトコルを、内部アドレスとポートへ対応させる。反対側ですでに動いているリスナーが必要であり、内部アドレスがその場に留まることも必要だ。別のマシンへ移った DHCP リースは、すべてのトンネルを黙って誤ったホストへ送るので、ルールの前に予約を作る。

RuleOpens whenCloses whenFits a VPN listener
Port forwardSaved, at bootYou delete itYes
Port triggerMatching outbound trafficIdle timeout or rebootNo

プロトコルはフォームの見た目以上に重要だ。UDP 上の OpenVPN には UDP のフォワーディングが要り、WireGuard にも UDP が要る。IPsec のデータは ESP、IP プロトコル 50 として届き、ポートをまったく持たない。TCP か UDP しか受け付けないフォワーディングのフォームではそれを表現できず、IPsec にはポートルールの代わりにパススルーか静的な一対一マッピングが必要になる。

ルーターの上の層

フォワーディングが制御できるのは、自分が持つ変換だけだ。WAN アドレスが自分のものではない場合、加入者が 100.64.0.0/10 を共有するキャリアグレード NAT の背後がそうで、RFC 6598 に記述されているとおりだが、プロバイダーが先に変換しているため内向き接続は自分のルーターに届かない。自分の機器のルールではその順序を直せない。

二重 NAT は同じ問題の縮図だ。自分のルーターは ISP のルーターへ転送するが、そちらに一致するルールはなく、パケットは破棄される。外側の機器にルールを足すか、外側の機器をブリッジモードにして自分の機器が公開アドレスを持つようにするかだ。

だからテストは外から来なければならない。公開アドレス経由で同じ LAN から行うテストはヘアピン NAT の対応に左右され、ルールとは無関係な理由で成功したり失敗したりする。モバイルデータのスマートフォンや別ネットワークの知人のほうが、より確実な確認だ。

ルールを絞り、それから両方の半分を検証する

一つのポートを一つのアドレスへ転送する。最初の試行が失敗したからと範囲を足すのが、管理インターフェースをインターネットにさらす道であり、VPN のリスナーは隣にルーターの管理画面を公開する必要はない。

そのリスナーをすでに守っていたものは残す:証明書や鍵による識別、ホストのファイアウォール、最新のパッケージ版数だ。フォワーディングはパケットを通すだけであり、認証がそのパケットをトンネルにするかを決める。何かがうまくいかないとき、この二つは別々の失敗である。

検証には二つの半分がある。ハンドシェイクが外部ネットワークから完了すること、そしてサーバーの背後のプライベートなリソースがトンネル越しに応答することだ。フォワーディングはトンネルの接続を通すだけで、それ以上ではない。10.8.0.0/24 のルーティングと認可は、別画面の別設定だ。

三つの質問で決める

三つの質問は、どんな比較表よりも速く選択を決める。

  • 外から最初のパケットとして接続してくるものはあるか。あるならフォワーディングかリレーを使う。決して存在しない外向き通信なしに、トリガーは開けない。
  • 穴はアイドル時間より長く生き残る必要があるか。あるならフォワーディングを使う。トリガーされたマッピングは自分のスケジュールで閉じる。
  • WAN アドレスは公開してよい自分のものか。そうでないなら、どのルールを編集する前に対処する。

三つすべての答えが否なら、商用プロバイダーへ自分から発信するノート PC がそうだが、どちらのルールも要らない。NAT 背後のクライアントは、ステートフルなマッピングを自分で作るから動く。真夜中にポートフォワーディングのページを読む人の大半は、そこに当てはまる。

関連記事