ポート443が応答するのにSSTPが失敗する：どの段階が壊れたのか

トンネルが構築されないままポート443へのTCPハンドシェイクが完了しても、証明できるのは一つのことだけで、それは小さなことです。そのアドレスで何かが待ち受けており、接続を受け入れる用意があるというだけです。サービス、提示される証明書、最初のバイトの後に何が起きるかは示しません。

そのハンドシェイクと動作するトンネルの間には四つの段階があり、それぞれが異なるエラーを生み出します。

開いたポートが示すのは一つの層だけ

TCP接続を受け入れるということは、あるプロセスがソケットを所有し、経路がハンドシェイクを許可しているという意味です。そのプロセスがSSTPサーバーなのか、プロファイルの名前に対して有効な証明書を持っているのか、アカウントを認可するのかは何も語りません。同じアドレスのウェブサーバーはハンドシェイクに完璧に応答し、その後にSSTPリクエストへHTTPエラーで応答します。そのハンドシェイクより上のすべては未検証のままです。

ポートテストは判定ではなく、可能な限り最も安いフィルターとして扱ってください。その価値は、失敗のカテゴリを一つ丸ごと排除できることにあり、その上のすべてを確認できることではありません。

この二つを混同すると、クライアントの実際の問題を一度も調べていないテストの後に、クライアントを再インストールしてしまうのです。

証拠で四つの段階を切り分ける

段階は、トランスポートの到達性、TLS検証、HTTPS上のSSTP交換、トンネル内のPPP認証です。最初を通り四番目で失敗する経路には資格情報の修正が必要です。二番目で失敗する経路には証明書か名前の修正が必要です。これらの修理に共通点はなく、間違った方を選べば障害対応を無駄にします。

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

三番目のコマンドは注意深く読む価値があります。通常のウェブページからの200はウェブサービスがあることを示すだけで、SSTPリクエストが理解されることは示しません。同じアドレスからの404もVPNについて同じくらい何も語りません。クライアントのログだけが、四つの段階のどこに到達したかを示します。

各コマンドがどの名前を使ったかに注目してください。証明書は送信する名前で選ばれるので、プロファイルとテストの不一致はあなた自身が持ち込んだ不一致です。その名前を結果の横に書いておけば、後での混乱を防げます。

部分的な成功を正しい方向に読む

中間装置は通常の閲覧を許可しながら後の交換を拒否することがあり、それがウェブサイトには機能するプロキシがトンネルでは失敗する理由です。同じパターンは、証明書がブラウザの名前には有効でもプロファイルに設定した名前には有効でないときに現れます。ブラウザは満足し、クライアントは満足せず、どちらも自分が確認した内容については正しいのです。

これを診断している間は、サーバー検証を有効のままにしてください。無効にすると証明書の不一致が成功したハンドシェイクに変わり、失敗を説明した唯一の証拠が隠れます。

同じプロファイルが別のネットワークから機能するなら、その違いは経路依存です。これで探索範囲は中間装置に絞られますが、どれかは分からないままで、それでも前進ですから、使用したネットワークを記録してください。それがなければ比較は無意味です。

次にセッションだけでなくアプリケーションを試す

セッションができたら、必要とするクライアントから、意図した経路、名前解決、サービス権限を確認してください。接続済みのトンネルでも、遠端での転送や、存在しなかった戻り経路が欠けていることがあり、待っている人にはそうした失敗がアプリケーションの問題とまったく同じに見えます。

すべての結論を、それを生み出した段階に結び付けておいてください。開いたポートを動作するVPNと呼ぶことが、五分の証明書確認を一日のソフトウェア再インストールに変える方法です。