SSTPはHTTPS上のPPPであり、ポート443のウェブページではない

SSTPはPPPをHTTPS接続の内側で運ぶため、途中のあらゆるものにはウェブトラフィックに見えます。TLSとHTTPが外側のチャネルを確立し、次にSSTPの制御メッセージがトンネルを準備し、PPPがセッションの振る舞いを提供します。同じアドレスでページを読み込むブラウザは最初の段階の一部を終えたにすぎません。それをVPNのテストとみなすと、動作しているプロキシがプロトコルの不一致のせいにされます。

四つの段階を順にたどれば、目にしている障害はどれか一つに当てはまります。

段階1：TCPとTLS

クライアントはポート443へTCP接続を開き、TLSハンドシェイクを行います。証明書チェーンは、クライアントが設定されたホスト名と一致しなければなりません。ここで名前が一致しないと、SSTPメッセージが交わされる前に障害となり、SSTPの仕様はこの外側のHTTPSチャネルがすでに存在することを前提にしています。後の段階でここの信頼の失敗を埋め合わせることはできません。

一般的なウェブサーバーはこの段階を完璧に終えても、次の段階で失敗することがあります。TLSの成功は証明書についての証拠であり、その背後のプロトコルについての証拠ではありません。

段階2：HTTPSリクエスト

SSTPは固有のメソッドSSTP_DUPLEX_POSTでリクエストを行い、文書を返す代わりにやり取りを開いたままにします。通常のページリクエスト向けに設定されたサーバーやプロキシは、接続を受け入れてからメソッドを拒否することがあります。その拒否こそが、人々がふつうポート443が遮断されていると表現する互換性の問題です。

サーバーログで応答コードとメソッドを確認してください。この段階での拒否はTCPタイムアウトとは別の問題で、それぞれ異なる修正につながります。

段階3：制御メッセージ

リクエストが受け入れられると、SSTPはトンネルを交渉して準備する制御メッセージを交換します。これはHTTPリクエストではなくHTTPS本体の内側のプロトコルメッセージなので、本体を検査して書き換えるプロキシは、ページリクエストをそのままにしたままこれらを壊すことがあります。

ここで深層検査を行うミドルボックスが評判を得ます。ページは読み込めるのにVPNが失敗するなら、ポートが開いているかではなく、本体が書き換えられていないかを確認してください。

段階4：PPPが引き継ぐ

次にPPPがセッションの振る舞いを提供します。リンクの交渉、認証、そしてそれに続くネットワーク層の設定です。PPPの認証は、クライアントがすでに通過したTLSの検査とは別です。クライアントが受け入れるサーバー証明書は、利用者の資格情報が有効か、アカウントが許可されているかについては何も語りません。

受け入れられた証明書と拒否されたログインは矛盾しません。独立した結果を持つ連続した段階です。

認証には複数の役割がある

クライアントはTLSサーバーの身元を、自身の信頼ストアと設定された名前に対して検証します。次にPPPが、配備に応じて利用者またはマシンを認証します。サーバーは誰が接続でき何に到達できるかについて独自のポリシーを追加できます。ホスト名は証明書の身元と一致させてください。生のアドレスに置き換えると、動作する設定が名前検査の失敗に変わります。

どの段階が障害を報告したかを書き留めてください。証明書、メソッド、制御メッセージ、PPP認証、そしてルート。五つの箇所、五つの修正です。

ブラウザでの確認で示せること、示せないこと

そのアドレスでページを読み込めることは、DNS解決、TCPの到達性、HTTPを話す何かが待ち受けていることを証明します。メソッドが受け入れられること、制御のやり取りが生き残ること、PPP認証が設定されていることは証明しません。ポートを変えて別のプロファイルを変換するのではなく、SSTPを実装したクライアントを使ってください。

セッションが確立した後も、利用者が何に到達できるかはルート、DNS、サーバー側の転送が決めます。トンネルは経路であり、許可ではありません。