Windows 内蔵 VPN がベンダーの SSL ゲートウェイに到達できない理由

Windows に同梱されるトンネルは四種類だけで、ベンダーのゲートウェイはそのどれでもありません。それでも内蔵プロファイルをそうしたゲートウェイに向けると、資格情報の入力を求められる前に接続が失敗し、たいていはローカル システムによって接続が終了されたというメッセージが出ます。この文言は不一致の合図であって、診断ではありません。プロファイルの種類と、そのプロトコルを実装するクライアントが一致している必要があり、どちらかが欠けています。

四つの種類と一つのダイアログ

保存されたプロファイルはどれもトンネルの種類を持ちます。内蔵クライアントが受け付けるのは PPTP、L2TP、IKEv2、SSTP に、順番に試す自動モードを加えたものです。汎用の SSL VPN 項目はなく、ダイアログから追加する方法もありません。ベンダーのゲートウェイは TLS の上で独自のアプリケーション プロトコルを話し、それを実装しているのはそのベンダーのクライアントだけです。

一覧はコマンド一つで出せますから、他のトラブルシューティングより先に実行する価値があるのは、一秒で終わり、誤った前提をまとめて排除できるからです：

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

プロファイルが SSTP と名乗り、ゲートウェイが RRAS サーバーでないなら、不一致はすでに確定しています。証明書やファイアウォールをどういじっても変わりません。

SSTP とベンダーの TLS はポート 443 で同じに見えます

SSTP は PPP セッションを TLS の中に包み、TCP 443 上を走ります。Microsoft のスタックでは RRAS がそれを終端し、クライアントが検証するサーバー証明書を提示します。Fortinet、Citrix、Pulse のアプライアンスも 443 で TLS を終端し、そのポータルはどのブラウザーでも警告なしに開きます。

そのブラウザー確認が示すのは到達性であり、互換性ではありません。ポータルの後ろのセッション プロトコルはベンダーのもので、内蔵クライアントにはその実装がありません。ベンダーが自社クライアントを提供しているかどうかで、不一致のどちら半分を扱っているかが分かります。

逆の混同も起こります。SSTP として構成したプロファイルを正規の RRAS サーバーに向けると、ポータルは正常なのに証明書の検証で失敗することがあり、これは証明書の問題であってプロトコルの問題ではありません。

トンネルができる前に現れるエラー

800 番台のコードはどのトンネルも確立する前に報告されるため、ファイアウォールの規則で動くことはほとんどありません。エラー 812 はクライアントが提示した認証方式を拒否するサーバー側のポリシーです。同じ範囲の他のコードはネットワークではなく、ローカルの接続マネージャーから出ます。

何かを組み直す前にトレースを有効にしてください。トレースは失敗した段階を名指しし、段階の名前はダイアログの文言より価値があります：

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

トレースは tracing ディレクトリに残り、消すまでそこにありますので、何週間も走らせたままにせず、あとで無効にしてください。

接続できたプロファイルでもすべてを壊せます

接続はできるのにブラウジング、ローカル共有、コンテナー エンジンが壊れるプロファイルは、トンネルではなくルーティングの問題です。既定ゲートウェイがトンネルに移ったため、すべての宛先がそれをルーティングしない可能性のあるピアを通ります。

これを決める設定は二つです。一つはプロファイルの split tunneling プロパティです。もう一つはリモート ネットワークの既定ゲートウェイを使うアダプターごとのオプションで、IPv4 の詳細設定にあります。

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

ルートを追加せずに split tunneling を有効にすると、接続はするが何にも届かないトンネルになります。DNS を確認せずに無効にすると、アダプター自身のサフィックスとサーバーが使われないため、内部名が公開の応答に解決されます。

まず配管を確認し、それから種類を確認します

この順序で作業し、すべてを一度に調整するのではなく、手順が失敗したら止まってください：

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

最初のコマンドは到達性とプロトコルを切り分けます。二つ目はプロファイルが名乗る内容を確認します。ルート テーブルはトンネルが既定ルートを奪ったかどうかを示します。ダイヤル コマンドは接続マネージャー自身のエラーを報告し、これはダイアログより明確なことが多いです。

チケットにトンネルの種類、ゲートウェイの製品、正確なエラーを記録してください。そうすれば次の人は一分で、プロトコルの不一致か、証明書の失敗か、ルーティングの判断かを知ることができ、「VPN が動かない」から始めずに済みます。