TLS を検査するプロキシの背後にある SSTP：セッションが切れる場所

ブラウザは社内イントラネットを読み込め、プロキシの証明書も信頼されているのに、SSTP クライアントは接続の終わり近くで切れます。このパターンは、パスワードの誤りではなく、ウェブ要求とトンネルされたセッションの違いを示しています。TCP から上へ接続をたどり、最初に失敗する段階を書き留めてください。原因がプロキシかどうかを教えるのは、エラーコードではなくその段階です。

クライアントが止まる場所から始める

クライアントは決まった順序を通ります。ポート 443 への TCP 接続、TLS ハンドシェイク、証明書の検証、SSTP の HTTP 交換、PPP のネゴシエーションと認証、そして IP 設定です。各段階の失敗は異なる痕跡を残し、それらを混同すると誤った設定ページに導かれます。

TCP の失敗は、TLS のバイトが現れる前のタイムアウトかリセットです。TLS の失敗はアラートかハンドシェイクのタイムアウトです。証明書の失敗はチェーンか名前に関する警告を出します。HTTP の失敗はハンドシェイク成功後に起こり、多くの場合ステータスコードか即時の切断です。PPP の失敗はトンネルが技術的に確立した後に起こるため、認証の問題のように見えます。

最初のエラー行ではなく、最後に成功した段階をクライアントのログで読んでください。エラー行は通常、結果を報告するもので、段階の境界は拒否したコンポーネントを示します。

SSTP がネットワークに運ぶことを求めるもの

SSTP は TCP 443 上の TLS で動作し、次に SSTP 仕様で定義された SSTP_DUPLEX_POST という HTTP 要求を /sra_{GUID}/ という形式のパスへ送ります。この要求は事実上無制限のコンテンツ長を宣言し、セッションの間ずっとストリームを双方向に開いたままにします。PPP フレームはそのストリームの中を流れます。

だからこそ、通常の閲覧を扱うプロキシでも失敗します。有限のボディを持つ GET や POST はバッファリングし、検査し、転送できますが、決して終わらないボディを持つ双方向ストリームはできません。ボディの完了を待つプロキシは永遠に待ち、クライアントは最終的にタイムアウトします。

メソッドのフィルタリングと認証は、独自の失敗モードを加えます。プロキシが要求に資格情報を求める場合、ブラウザなら答える場面でも VPN クライアントは答えないことがあります。メソッドを削除したり書き換えたりすると、ゲートウェイは PPP が始まる前に要求を拒否します。

検査が識別情報を変える理由

TLS を検査するプロキシはクライアントの TLS 接続を終端し、ゲートウェイへの別の接続を開きます。そのためクライアントはゲートウェイの証明書ではなくプロキシの証明書を検証し、ゲートウェイはプロキシを相手と見なします。組織が独自のルートを配布している場合、ブラウザも VPN クライアントもそのチェーンを受け入れられ、ハンドシェイクは成功して問題は次の段階へ移ります。

検証の成功は、プロキシがセッションを運べることを意味しません。プロキシは依然として無制限の双方向 POST をバッファリングなしで中継し、両方の接続を何時間も維持する必要があります。多くの検査製品は要求と応答のトラフィック向けに作られており、このケースは苦手か、まったく扱えません。

だからこそ、未知のルートを追加したり検証を無効にしたりするのは誤った修理です。クライアントが受け入れる証明書を変えるだけで、実際にセッションを壊したストリーム処理には何もしていません。

設定を変える前に発行者を特定する

エンドポイントに、どの証明書を提示し、誰が署名したのかを尋ねてください。次のコマンドは VPN セッションを開始せずにチェーンと発行者を表示します。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

発行者が公的な CA なら、このホストの接続はおそらく傍受されておらず、失敗は別の場所にあります。発行者が組織自身の CA なら検査が有効で、ゲートウェイにはプロキシ経由で到達しています。名前だけで結論を出す前に、指紋をネットワークチームが期待するものと比較してください。

同じホストへのブラウザテストが証明するのは、プロキシが GET を受け入れることだけです。SSTP のメソッド、要求 URI、ボディの寿命については何も言わないので、動くイントラネットのページをトンネル経路がサポートされている証拠にしないでください。

サポートされた経路を選ぶ

ネットワークの所有者に具体的な質問を一つしてください。そのプロキシは、このゲートウェイへのポート 443 のバッファリングなしの双方向 POST を許可していますか。はいならプロキシの例外か、VPN ホスト向けの文書化された迂回になります。いいえなら検査された経路は SSTP を運べず、サポートされた修正はクライアントの調整ではなく別の経路かプロトコルです。

選択肢には通常、VPN ゲートウェイ用の検査されない出口、社内トラフィックだけをプロキシ経由で送るスプリットトンネルの設計、または組織が別のポートでサポートする代替プロトコルが含まれます。どれもネットワーク設計に属し、比較が経路を分離できるよう、同じデバイスと同じプロファイルで試すべきです。

結果を記録してください。発行者、失敗した段階、プロキシのルール、選んだ経路です。同じ 98 パーセントの停滞を見た次の人は、手順全体を繰り返す代わりに一つの事実を確認できます。