SSTPのタイムアウトか証明書エラーか——両者をどう見分けるか

SSTP 接続の失敗には、利用者の席から見ると同じに見える二つの型があり、それぞれの修理は別の層にあります。タイムアウトは必要なやり取りが最後まで終わらなかったことを意味し、証明書エラーは身元の材料が届いたうえで拒否されたことを意味します。二つ目を一つ目として扱うと、もともと問題ではなかったファイアウォールやパスワードへ向かうことになります。見分けるための証拠はクライアント自身のログにあり、何かを変える前に読めば分かります。

二つの失敗、二つの異なるやり取り

SSTP は HTTPS の形をしたセッションの中にトンネルを通すため、443 以外を許さないネットワークでも生き残ります。クライアントは TLS ハンドシェイクを完了し、プロトコル固有のメソッドで HTTP リクエストを送り、そのストリームの中でトンネルが走ります。どの段階で失敗しても接続は止まり、資格情報が関わるのは後の段階だけです。

この順序が診断そのものです。TLS ハンドシェイクが完了しなければ資格情報は送られていないので、パスワードの再設定では解決しません。ハンドシェイクが完了してから止まるなら、身元は受け入れられ、リクエストの経路の何かが拒否しています。ハンドシェイクが検証メッセージで失敗するなら、サーバーは応答し、クライアントが聞いた内容を拒んだということです。三つの結果、三つの層です。

ログの行は、三つのどれにいるかをたいてい示します。だからこそ最初の変更の前に書き留める価値があります。

タイムアウトは段階が終わらなかったことを意味する

まず名前解決と TCP の到達性から始めます。そこでのタイムアウトは後段のタイムアウトとまったく同じに見えるからです。443 が開いていると報告するポートチェッカーが証明するのは、待ち受け側が接続を受け入れたことだけで、それ以上ではありません。

次の容疑者はホストではなく経路です。プロキシやアプリケーションを意識するファイアウォールは、SSTP が使うリクエストメソッドを拒否したり、何時間も開いたままのストリームを落としたりし、どちらの振る舞いもクライアント側からはタイムアウトに見えます。同じホストが配信する普通の HTTPS ページは完璧に読み込まれるのにトンネルのメソッドは拒否されるので、エンドポイントを閲覧しても分かることはごくわずかです。この二つの場合を切り分けるには、プロキシのないネットワークから試してください。

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

相手からの応答が一切ない段階のタイムアウトはアカウントについて何も語らず、その時点でパスワードを変えても変数を一つ増やすだけです。

証明書エラーは身元が拒否されたことを意味する

ここではサーバーが実際に応答しているので、ネットワークは機能しており、問いは身元へ移ります。クライアントが発信する名前と、証明書が実際に主張する名前を比べ、次に有効期間と発行の連鎖を確認します。

クライアントが信頼しないプライベート CA は、期限切れの証明書と同じ種類のエラーを生みます。数時間ずれた時計も同じです。生のアドレスで発信すると新たな不一致が生まれます。証明書が主張するのは名前であり、アドレスではないからです。管理された配備では、エラーページが差し出す代替ルートを受け入れるのではなく、管理者から意図された信頼設定を受け取ってください。原因を直している間も検証は有効のままにします。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

成功した TLS の段階は通過したあと手を付けずに残してください。後から巻き戻すと、どの変更が実際にトンネルを直したのか分からなくなるからです。

二つが混同される場所

どちらの失敗も接続が上がらない形で現れ、どちらも利用者が無関係な何かを変えたあとにやってきます。その偶然が、誤った修理をしばらくもっともらしく見せます。

二つの習慣が両者を切り離します。設定に触る前にクライアントのログを記録し、最初の状態を残します。試行ごとに層を一つだけ変え、次の結果が既知の変数に属するようにします。ポートチェッカーもブラウザーも部分的な観測であり完全な順序ではなく、どちらもクライアント自身の報告の代わりにはなりません。どちらの習慣も費用はかからず、両方とも調査を短くします。

証明書の問いと到達性の問いが別々に文書化されているのには理由があります。

実際のクライアントで再試験し、それから内側へ進む

具体的な修正が入ったら、ブラウザーのタブではなく、実際の SSTP クライアントと本物のプロファイルで再試行します。

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

セッションが接続してもリソースが失敗するなら、トンネルはもう容疑者ではありません。ルーティング、DNS、サービスへの到達へ移ります。それは別の証拠を持つ別の調査です。動作している TLS と認証の段階を保てば、最初の調査の繰り返しにはなりません。失敗した段階をチケットに書いてください。そうしないと次担当者がまた上から始めます。