ブラウザのHTTPSが成功するのにSSTPが失敗する理由
SSTPはポート443のTLS内で動作しますが、Webリクエストではありません。TCP、TLSの身元、SSTPの交換、PPP認証を別々の段階として検証します。
ブラウザはVPNホスト名をHTTPSで問題なく開くのに、SSTPクライアントは接続を拒否したままです。この組み合わせに矛盾はありません。SSTPはTLSを外側のトランスポートとして使い、その接続の中で独自のリクエストとPPPペイロードを実行するため、ページの読み込み成功が証明するのはごく限られたこと、つまりホストがポート443でGETに応答するという一点だけです。クライアントは別の問いを投げかけており、サーバーがそれにまずく答えることがあります。
ページは読み込まれるのにトンネルは通らない
ブラウザテストは手軽なので使われますが、その結果はサーバーが到達可能で設定済みだという証明として扱われがちです。しかしそれはアドレスバーが開いたパスへのGETについての証明にすぎません。VPNの会話は同じTLSハンドシェイクの後に始まりますが、送るのはウェブページが決して使わないメソッドとパスです。したがってブラウザへの200という応答は、SSTPエンドポイントが存在するかどうかを何も語りません。
二つの観察を切り離せば、調査は短くなります。トランスポートと証明書チェーンは機能しており、その上のプロトコル交換のどこかが機能していません。これは壊れたポートや期限切れの証明書とは別の調査であり、別の証拠が必要です。
SSTPクライアントが実際に送るもの
クライアントはSSTP_DUPLEX_POSTメソッドで/sra_{GUID}/パスへHTTPリクエストを送り、その後も接続本体をPPPフレームを運ぶ双方向ストリームとして開いたままにします。準拠したサーバーはHTTP/1.1 200と応答し、ウェブサーバーのような振る舞いをやめます。それ以外はすべて署名で、405や404はエンドポイントが無いこと、301や302は何かがリクエストをリダイレクトしていること、即時のFINはプロキシかサーバーがストリームを閉じたことを意味します。
だから標的は、TLS証明書を後付けしたウェブサーバーではなくSSTPサーバーでなければなりません。メソッド、パス、長寿命の本体はプロトコルの要件なので、リバースプロキシは設定だけでそれらを追加できません。通常のHTTPSを完璧に転送するプロキシでも、認識しないメソッドは拒否し得ます。
プロキシやウェブサーバーがストリームを壊す場所
仲介者は何かを転送する前にHTTPリクエスト行を検査するため、変わったパスを持つ独自メソッドはその規則で失敗することがあります。通常のページを配信しながらトンネルを拒否したり中断したりする機器もあり、その場合クライアントはきれいな拒否ではなく、始まってすぐ死ぬ接続を報告します。リクエストを受け入れてから、PPPのキープアライブが耐えられない本体やアイドルのタイムアウトを適用する機器もあります。どちらもクライアント側からは同じに見えるので、どの段階が失敗したかがエラーテキストより重要です。
ウェブサイトとSSTPの間でポート443を共有するのはルーティングの選択であり、すべてのホップが両方の会話を同じように扱うという約束ではありません。経路上にロードバランサー、ファイアウォール、TLSターミネーターがあるなら、VPN設定に触れる前に容疑者リストへ加えてください。
段階を分けて検証する
各段階は異なる層を排除するので、チェックは順番に実行し、最初の失敗で止めてください。下のTLSプローブは証明書の身元をSSTPの挙動から切り離します。ホスト名を自分のエンドポイントに置き換え、出力されるsubjectとチェーンを読みます。
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com次に、クライアントのエラーから推測するのではなく、残りの証拠を段階に当てはめます。下の表はチケットに引用するチェックリストで、ある失敗を次から切り分ける署名を示します。
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
「接続できない」と書く代わりに、最後に成功した段階をチケットに記録してください。MS-SSTP仕様は、TLSハンドシェイクに続くリクエストとPPP交換を文書化しており、ブラウザテストがどちらも代われない理由の拠り所です。
まず身元、次にPPP
TLSの身元とPPP認証は順序であり選択肢ではないため、混同すると人は誤ったサーバー設定へ向かいます。クライアントはまずサーバー証明書とその意図された用途を検証し、次にPPPが自身の状態を交渉し、チャレンジ応答方式かEAPでユーザーを認証します。証明書の問題は拒否されたパスワードとは別のエラーを生み、どちらのエラーも他方が扱う段階を説明しません。
ホスト名をアドレスに置き換えたり、証明書の警告をクリックして越えたりすると、失敗している段階を特定できたはずの検査を、修正する代わりに取り除くことになります。警告は残して読んでください。HTTP交換がSSTPの挙動に一度も達していないのに資格情報が一度も求められていないからPPPパスワードをリセットしないでください。