NAT 背後の SoftEther: 直接トラバーサルか VPN Azure リレーか

ダイナミック DNS、NAT トラバーサル、VPN Azure はそれぞれ別の仕事をします。ユーザーを編集する前に経路を選び、セッションが実際にどのトランスポートを使っているかを確認してください。

SoftEther サーバーが変更できないプロバイダーのルーターの背後にあり、それでもクライアントが接続できるので、リレーがすべてを運んでいると仮定していませんか。それが正しいかどうかは、DNS 名、協調された UDP 経路、リレーへの外向きトンネルのどれが仕事をしたかによって決まります。三つとも接続済みのクライアントを生み出せますが、失敗する条件は異なります。ユーザーやハブに触れる前に、どの経路を買うのかを決めてください。

三つの仕組み、三つの異なる約束

ダイナミック DNS は名付けです。変わるアドレスにホスト名を向けておくことで、人が番号を追いかけるのをやめさせるだけで、それ以外は何もしません。ネイティブの NAT トラバーサルは調整です：二つの SoftEther エンドポイントが情報を交換し、その間の変換装置を通る使える UDP 経路を開こうとします。VPN Azure はリレーです：サーバーがサービスへ外向きに接続し、クライアントはリレーのインフラ上のホスト名を通って到着します。

三つは一つの機能の版ではなく、互いに補完します。導入が名付けを使いながら、実際の接続はトラバーサルやリレーに依存することがあります。

クライアントとネットワークから決める

選択はクライアントから始まります：トラバーサルはネイティブの SoftEther 接続方式にしか存在しないからです。同じサーバー上の OpenVPN、L2TP/IPsec、SSTP リスナーはホストを共有していても、それを継承しません。ユーザーが何を実行するか、次にネットワークが何を許すかを見てください。TCP 443 だけを許す社内ネットワークはそのポートのリレーへと押しやり、トラバーサルに必要な UDP ポートを通すネットワークは直接経路を試せます；どちらも実際の外向きポリシーに対して確認してください。

手動で到達できるリスナーは、管理者が公開できるなら依然として正当な設計ですが、独自のアドレス指定とファイアウォール作業を伴う別プロジェクトです。

セッションが選んだトランスポートを確認する

使用中の経路について正直な情報源は接続状態だけです。サーバーでそれを読み、クライアントが受け取ったホスト名を解決してください。

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList はどのセッションが接続されているかを示し、その一つに対する SessionGet は、セッションがリレー経由で到着したかどうかを含めて接続種別を報告します。リレーのインフラに解決されるレコードは、セッションが第三者を通っていることを示し、テストでその経路を遮断すれば確認できます。ネイティブクライアントでは UDP アクセラレーションがデータ経路を制御経路から動かすことがあるため、一回の観測ではセッション全体を説明できません。アドレス変更後に古くなったダイナミック DNS 名と、バックエンド経路が欠けているのに応答するリレーは、別々に試す価値のある二つの障害モードです。設計が意図したことではなく、実際に測ったことを記録してください。

選んだ経路が何に依存するかを計画する

どの経路にも依存関係があります。直接トラバーサルはネットワーク移行や新しい変換装置の後で変わることがあり、リレーセッションはサービスやその到達可能なポートが失敗すると失敗します。別のネットワークから再接続し、クライアントが検証したサーバー ID を確認し、以前機能していた経路を同じテストに残してください。次に、認可、ハブのメンバーシップ、アドレス割り当て、戻り経路がどちらにせよあなたの責任だから、VPN 背後のプライベートリソースを試してください。

ホスト名、プロトコル、機能の設定、観測したトランスポートを書き留めてください。その四部分の記録が、次の人が動作する接続を再現できるようにします。

関連記事