設定できないNATの内側にあるVPN：それでも機能するもの

すべてのトンネル端点には、相手側が到達できるアドレスとポートが必要であり、自分が管理していないルーターがその要件を満たせない通常の理由である。興味深いのは抜け道が存在することではなく、どの抜け道もクライアントからは見えないマッピングテーブルの性質に依存していることだ。そのうち二つの性質がほぼすべてを決める。マッピングがどう作られるか、そして内側が一度も接続したことのないアドレスからのパケットを受け入れるかどうかである。環境をこれらの性質で分類すれば、回避策はもはや伝承ではない。

マッピングテーブルがすべてを決める

ネットワークアドレス変換は、内部のアドレスとポートを外部のアドレスとポートに対応づけて記録するテーブルを保持する。記録と一致する応答は逆変換され、一致する記録のない外部からのパケットには行き先がまったくない。この一つの挙動が、ルーターの内側のリスナーがインターネットから到達できない理由を説明する。また、各方向の最初のパケットが内側から始まらなければならない理由も説明する。

ルーター側からテーブルを見れば、回避策は明らかになる。何かが恒久的なエントリを作るか、一時的なエントリを作って新鮮に保つか、あるいはトラフィックがその経路をまったく通らないかである。この記事の残りは、その三つの場合を順に扱う。ここで何も、テーブルが記録する以上のベンダー機能に依存しない。

ランデブーサービスにできることとできないこと

UDPホールパンチングは、フィルターを打ち破るのではなく、外向きの記録を一時的な開口部として使う。両方のピアがランデブーサービスに接続し、サービスは各ピアの公開端点を学習して、相手側の端点を返す。その後、両方が互いに向けて送信し、各外向きパケットが応答を内側に入れる記録を作成または更新する。順序が機能させる鍵であり、順序が脆さの理由でもある。相手側が記録を作る前に送信したピアは単に破棄され、少し後の再試行は成功する。サービス自体はVPNトラフィックを運ばないため、その唯一の影響力は調整するタイミングである。

マッピングの挙動が残りを決め、RFC 4787 は三つの形を挙げる。端点非依存、アドレス依存、アドレスとポート依存である。最後の形では、ピアが狙うポートが宛先ごとに変わるため、予測は信頼できなくなる。ここでこの手法は行き止まりに達する。キャリアグレードNATと厳格な企業ファイアウォールはどちらも方式が必要とする予測可能性を奪い、どれだけ再試行しても戻らない。

Keepalive、再起動、そして移動する端点

穿孔された経路はリスナーではなくフローであるため、その上で動くものは変化に耐えなければならない。定期的なトラフィックでマッピングを生かし続け、公開端点が移動したことに気づき、ルーターの再起動やアドレスの再割り当ての後に再確立する必要がある。メッシュVPN製品はその論理を自前の制御プレーンに置くが、素のサーバーはそれをあなたに任せる。Keepaliveは同じマッピングが生きている間だけ役立ち、モバイルクライアントではバッテリーを消費するため、攻撃的な間隔は無料ではない。

一時間スリープしたノートPCは通常、別の公開端点で戻ってくる。経路を再確立するものは再び内側から実行されなければならず、同じ要件がクライアントに戻る。

欠けた転送を回避する三つの方法

第一の方法は、機能が存在して有効であれば、UPnP IGD、NAT-PMP、PCPを通じてルーター自身にエントリを作らせる。第二は、公開アドレスを持つリレーにトラフィックを渡す方法で、常に機能し、常に帯域幅と別の信頼境界を犠牲にする。第三は方向を逆転させる。内部ホストが公開サーバーへの外向きトンネルを開き、それ以外はすべてその中を通る。

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

リレー端点はその取引をクライアント設定の中で可視化する。端点がピア自身のアドレスではなくリレーになっている。永続的Keepaliveがマッピングを温め、許可されたプレフィックスがクライアントの送信可能範囲を決める。 内部ホストからの逆トンネル は所有者が違うだけで同じ発想であり、NATの変更は一切不要だ。三つのどれも、内部から始まるトラフィックを送るため、設計上望まないトラフィックを遮断するファイアウォールを破ることなく、受信要件を取り除く。

回避策をルーターの所有者に合わせる

ルーターを管理しているなら、静的UDP転送はどの穿孔方式よりも監査が容易で、目に見える形で失敗する。管理していないなら、ベンダーがリレーやホスト型制御プレーンを提供しているか、ポリシーがその利用を許すかを確認する。どちらもなければ、残る選択肢は逆トンネルか、端点が外部から到達できないことを受け入れるかである。どちらを使ったかを記録することは見た目以上に重要だ。選択肢は、誰がトラフィックを観察できるか、第三者が何かを変えたときに何が起きるかで異なる。

最終的に得た経路が直接かリレー経由かを記録しておく。その一つの事実が遅延と障害時の挙動の両方を予測する。RFC 4787はそのすべての下にあるマッピング挙動の参照であり続け、そのマッピングの節を読むほうが三つの回避策を順に試すより速い。テーブルはどの選択肢を選んだかを気にしない。次のパケットに何が許されるかだけを記録する。