SoftEther VPN Azure：中継経路であり、開放ポートではない

あなたのサーバーは設定できないルーターの背後にあり、ポートを転送するという明白な策は使えません。VPN Azure はまさにその状況のために存在し、最初の接続の向きを逆にすることで解決します。サーバーが外へリレーに接続し、クライアントはサーバーではなくリレーに到達します。この反転を理解すれば、このサービスが何を解決するのか、そして後でぶつかるあらゆる制約が説明できます。

経路で何が変わるか

従来のリスナーでは、クライアントは公開アドレスへ TCP 接続を開き、ルーターがそれをサーバーへ転送します。リレーの場合、サーバーはリレー基盤への外向き接続を維持し、リレーがクライアントの接続を受け付けてそのペイロードを待機中のサーバーへ渡します。内向きのポートは開かれず、固定アドレスも不要で、ルーターはそのままです。ファイアウォールから見ればサーバーは普通の外向きクライアントであり、だからこそ制限の厳しいネットワークでも通ります。

リレーはそのサーバーに自身のドメイン上の名前を割り当て、クライアントはそこへ接続するよう設定されます。

その名前はリレーサービスに属し、Microsoft Azure VPN Gateway ではありません。どちらも Azure 何とかと呼ばれていてもです。両者を互換可能とみなすと、動作し得ない設定になります。

どのプロトコルがリレーを通過するか

リレーは SoftEther プロトコルを運び、プロジェクトは SSTP をクライアントの選択肢として文書化しています。Windows に SSTP クライアントが同梱されているため有用です。ただしホスト上のあらゆるリスナーの汎用キャリアになるわけではありません。OpenVPN リスナー、IPsec レスポンダー、L2TP サービスはそれぞれ到達可能な端点を必要とし、SoftEther サーバーが接続されているからといってリレー経由で運ばれるわけではありません。

したがってクライアントプロファイルはサーバーアドレスではなくリレー名を指し、直接接続用に作られた既存プロファイルはそのままでは動作しません。リレーが運ばないプロトコルを前提に設計する前に、使用中のバージョンでサポートされるクライアント一覧を確認してください。

リレーがあなたの代わりにしないこと

リレーは転送路です。ユーザー、仮想ハブ、アクセスポリシー、ルートを作成せず、サーバーの背後のプライベートネットワークについて何も知りません。リモートのクライアントが LAN サブネットへ到達する必要があるなら、サーバーにはブリッジまたはルーティングの設定、戻り経路、それを成立させるファイアウォールポリシーが依然として必要です。両端でアドレス計画が重複する問題もリレーには見えず、あなたが解くべき課題として残ります。

サポートされるセキュリティ設定も自分で選ぶものです。プロジェクトの文書には古いプラットフォームの例があり、古いスクリーンショットから旧式の暗号や証明書の設定をコピーするのは、誰も監査できないトンネルを作る良い方法です。使用中のバージョンの最新の指針に従ってください。

証明書の検証とユーザー認証はサーバーの責任のままであり、リレーがそのどちらかを代替することは決してありません。

依存関係として運用する

可用性には第三者が加わりました。リレーに到達できないとき、サーバーがどれほど健全でもクライアントは接続できず、外から見るとクライアント側の問題に見えます。リレー経路はサーバー自身の健全性とは別に監視し、いざという日のために別アドレスの直接リスナーといった文書化された代替手段を用意しておいてください。

遅延は利用者の近さではなくリレーの地理に従うため、それを前提にインタラクティブな性能を約束する前に測定する価値があります。

まずサーバーの身元を確認し、次に実際のアプリケーション経路を確認します。接続成功のバナーだけでは不十分です。必要なリソースがリレーの運ぶアドレスファミリーで到達できるかも確認してください。リレー名、使用したプロトコル、代替手段を記録しておけば、このリンクに関する今後の疑問の大半に答えられます。