Windows VPN のアドレス欄では SSTP だけがポートを指定できる

VPN サーバーは TCP 10443 で応答し、Windows 内蔵クライアントの資格情報も正しいのに、DNS のタイムアウトに見える間ののち接続が切れます。原因はたいていアドレス欄で、vpn.example.com:10443 を「サーバー名またはアドレス」欄に入力すると Windows は文字列全体をホスト名として読み取ります。この欄は一般的な host:port 入力ではないため、ポートをそこに書けるかどうかはプロファイルのトンネルの種類で決まり、四種類のうち一種類だけが値を解釈できる形で扱います。

アドレス欄が host:port の欄ではない理由

この欄の背後にあるプロファイルのプロパティは ServerAddress で、トンネルの種類ごとに文字列の扱いが決まります。三種類には記入するポートのパラメーターがなく、コロンと数字は解決されない名前の中の文字にすぎません。四種類目は HTTPS 上で動作し、ポートは URL の一部なので、URL として解釈される形式で値を書く必要があります。

そのため 障害は接続拒否ではなく名前解決のように見えます。報告すべき間違ったポートはなく、存在しないホスト名があるだけであり、エラーはリゾルバーが諦めたあとに届きます。サーバーに触る前に、プロファイルがどのトンネルの種類を使うとしているかを確認してください。

ポートが固定の三種類

PPTP は TCP 1723 に接続し、その後トンネルを GRE、IP プロトコル 47 で運びます。L2TP/IPsec はトンネルに UDP 1701、IPsec に UDP 500 と 4500 を使い、4500 は NAT 通過用のポートです。IKEv2 も UDP 500 と 4500 を使います。これらのプロファイルはどれも画面のどこにもポート欄を出さず、非標準のポートを交渉することもありません。

したがって独自のポートで待ち受けるサーバーは、アドレスをどう書いてもこれらのプロファイルからは到達できません。実務的な答えは限られ、標準ポートをサーバー側で公開するか、手前のルーターで標準ポートを独自ポートに変換することです。どちらもクライアントのプロファイルをそのままにでき、プロファイルを手入力ではなくポリシーで配布する場合に大きな価値があります。

SSTP には名前ではなく URL が必要

SSTP は TLS セッションの中で動くため例外です。この欄は URL として解釈される必要があり、最初に https:// のスキーム、次にホスト、そのあとにコロンとポートが続きます。スキームがないと Windows は値をただの名前として扱い続け、TLS のやり取りが始まる前に接続が失敗します。

これが驚かれるのは、既定のポートならホスト名だけでも受け付けられるからです。独自ポートが一度も要らなかったプロファイルはこの規則を教えてくれず、最初に追加した人が失敗して初めて知るので、保存したあとはダイアログを信じず、保存された値を読み返してください。

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress は保存された内容をそのまま示します。コロンを含む裸のホスト名として読めるなら、そのプロファイルは URL を受け取っておらず、何度やり直しても直りません。

同じ欄に貼り付けられるベンダー構文

一部のゲートウェイはこの欄向けの追加の慣習を文書化しており、ポートのあとに付ける realm や、証明書の扱いを変えるクエリパラメーターなどがあります。それらはそのベンダーのサーバーと、一部のビルドでは自社クライアントが理解します。Windows のプロファイル形式の一部ではないため、組み込みプロファイルに貼り付けるとたいてい同じ静かな名前の失敗になります。

証明書の検証を無効にするパラメーターは、修正ではなく警告として扱ってください。そのパラメーターでしか接続できないなら、証明書が使っている名前と一致していないのであり、正しい修理はクライアントではなくゲートウェイ側です。ポートのあとの realm も同じ性質で、相手側のサーバーが期待するときだけ意味を持ちます。

ポートを証明し、失敗している段階を読む

プロファイルを疑う前に、クライアントのネットワークからそのポートで TCP を受け付けるものがあるか確認してください：

Test-NetConnection vpn.example.com -Port 10443

成功は待ち受けの存在を証明するだけで、SSTP を証明しません。Web サーバーやリバースプロキシ、ロードバランサーは TCP のハンドシェイクを完了しても SSTP を話さないことがあり、テストが成功しても VPN が失敗するのは現実的な組み合わせです。証明書のサブジェクトをプロファイルの名前と比較し、同梱されているビルドでは、一般的なタイムアウトではなく失敗した段階が記録される RasClient のログを確認してください。

そのうえで、問題を文書化するのではなく取り除く選択肢として、外部の TCP 443 を VPN サーバーの 10443 に転送する方法を検討してください。そうすればクライアントはポートを一切使わない既定のプロファイルを使い、管理された端末群ではたいてい最もすっきりした構成になり、独自ポートは内部の詳細として残ります。