ポート転送なしで NAT 背後のワークステーションに到達する

キャリア NAT とロックダウンされたオフィスルーターの背後にある二つの端点には、転送できる受信ポートがなく、それでも反射的にポートを要求してしまいます。より良い問いは、どちらの側が外へ発信でき、どの到達可能なサービスがトラフィックを運ぶことを許されているかです。四つの設計はこの問いに異なる答えを出し、経路が塞がれたときには異なる仕方で失敗します。それらを選ぶことは、プロトコル名ではなく保証の比較です。

四つの設計、四つの異なる約束

下の表は短い版です。中央の列を検証できる約束として、右の列を誰もしていない約束として読んでください。

どの行が当てはまるかは好みではなく作業内容で決まります。 リモートデスクトップのセッション一つ、管理用シェル一つ、そしてプライベートサブネット全体へのアクセス は、たまたま同じマシンに関わるとしても、同じ入口を必要としない三つの要件です。

ハブが変えるのは誰が外へ発信するかであり、何が許可されるかではない

ルーティングされたハブの設計では、遠隔のノート PC とワークステーション、あるいはその手前の拠点ゲートウェイが、双方が到達できるサービスへ向けた外向きトンネルをそれぞれ開きます。ワークステーションのルーターで求められていない接続を受け付けるものは何もなく、まさにそのためこの設計は NAT を越えて存続し、拠点に固定アドレスがなくても機能します。その後ハブは、自らのポリシーに従って二つの内部アドレス間でトラフィックをルーティングします。

コストは、ハブが存在し、両側から到達でき、誰かが運用しなければならないことです。外向きフィルタリングがそのトランスポートを許可する必要があり、それを遮断するネットワークは、ポート転送が不要だったとしてもこの設計を打ち負かします。

微妙な点は、到達性と認可が別々の場所で下される別々の決定だということです。あるプレフィックスへの経路は、その ID がワークステーションのどのサービスを使えるかを何も語らず、トンネルを許可するファイアウォール規則も、そのアカウントがログインできるかどうかを何も語りません。両方を設定し、両方を試し、認可の決定はルーティングテーブルではなくリソースを所有するシステムの側に置いてください。

トラバーサルは両方のスタックが実装しているときだけ機能する

ピア間トラバーサルは特定システムの能力であり、VPN を改善する設定ではありません。Interactive Connectivity Establishment は、ローカルインターフェース上のホスト候補、NAT が明かすものから作られるサーバー反射候補、リレー上に割り当てられるリレー候補という複数の候補アドレスを集め、一つが機能するまで組を試します。プライベートアドレスだけでは、相手側がそこへルーティングできないため経路になりません。

リレーの場合は、切り捨てる前に理解する価値があります。 RFC 8656 は TURN を、クライアントがサーバーにリレーされたトランスポートアドレスを求め、サーバーがそのクライアントとそのピアの間でトラフィックを転送するプロトコルとして説明しています。したがってデータを運ぶのはリレーであり、端点同士の出会いを助けるだけのディレクトリとは本質的に異なります。リレーアドレスを相手と交換することは、アプリケーションが行うべき調整の段階です。

約束できないのは直接経路であり、対称 NAT や一部の企業ファイアウォールはホールパンチングを打ち負かし、そうなるとシステムはリレーに退くか失敗するかです。また、翻訳された二つの端点が決して話せないとは結論できません。リレーのフォールバックを備えた対応スタックが存在するのは、しばしば話せるからです。可用性と直接性のどちらが重要かを決め、好ましい場合を仮定するのではなく、配備が実際にどの経路を選んだかを検証してください。

ブローカーはネットワークより狭い

要件が一つのアプリケーションである場合、アプリブローカーやワークステーションが開始する逆方向接続が最小の答えになり得ます。ワークステーションはブローカーへ外向きに発信し、ブローカーは遠隔ユーザーを認証し、運ばれるのはそのアプリケーションセッションだけです。ワークステーションのサブネットへの経路は作られないため、遠隔セッションが侵害されても隣接するすべての機器への経路を引き継ぐことはありません。

その狭さには、追加のアプリケーションごとに独自の統合が必要であり、アプリケーションがローカルネットワークについて前提とするもの、たとえば近くのサーバーで開くファイル共有が到達できないかもしれないという代償があります。ブローカーはポリシーとログも一か所に集約しますが、それはその場所が障害になるまでの利点です。

信頼の境界を比較し、それから経路を試す

トンネルを終端するハブは、ルーティングするトラフィックを読めます。アプリケーションが端から端まで暗号化する場合、リレーは独立に保護された交換を運べ、ブローカーは通常、提示するセッションを終端します。両方が暗号化されているからといって二つの設計が等価だと決める前に、保護が実際にどこで終わるのかを確定してください。

上のどの設計もそれに依存するため、次にワークステーションが外向きに実際どこまで届くかを確認してください。使用する予定のホスト名に置き換えて、ワークステーション上でこれを実行してください。

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

設計を受け入れるのは、許可された ID の下で意図した遠隔操作が成功し、承認されていない ID が拒否され、直接経路またはリレー経路が利用できないときの挙動が既知で文書化されていることを確認してからにしてください。オフィスで LAN 経由で始まったセッションは遠隔アクセスが依存する何も検証しないため、再接続とワークステーションの通常の起動コンテキストも含めてください。