VPNクライアントが本当にSSTPに対応しているか確認する方法

製品をVPNクライアントと呼んでも、それがSSTPを話せるかどうかは分かりません。アドレスにポート443があることは、さらに何も証明しません。SSTPはTCP 443上でTLSを動かし、次にSSTPの制御交換、次にリンク自体のためのPPPを実行し、その上に証明書の検証とPPP認証方式が乗ります。クライアントがこのプロトコルに対応していると言えるのは、名前を特定した実装が、インストール済みのバージョンで、サーバーの要件に対してそれらすべての層を完了したときだけです。以下の確認を順番に行い、最初に失敗した項目で止めてください。解く価値があるのはそこです。

実装、バージョン、プラットフォームを突き合わせる

プラットフォーム、アプリケーション、インストール済みのビルドから始めます。ベンダー名が一つでも、まったく異なる二つの実装を指すことがあるからです。組み込みのVPN種別とサードパーティ製クライアントは同じものではなく、プラグインが下位のプロトコルを表さないアダプター名を表示することもあります。現行リリースのドキュメントは、目の前のマシンで動いているビルドを説明していません。バージョン固有のページを読み、クライアント自身の申告内容と比べてください。

Windowsではトンネルの種類はGUIではなくプラットフォームから決まるため、プラットフォームに問い合わせます。ネイティブクライアントがこのプロトコルを試す場合、Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddressはSstpを表示し、接続の種類のリファレンスにも組み込みのトンネルの種類として記載されています。LinuxにはネイティブのSSTPクライアントが存在しないため、sstp-clientパッケージのsstpcのような別実装が導入され、最新であるかが問いになります。

ラベルの前にプロファイル形式を読む

プロファイルは互換ではなく、渡されたファイルは通常、どんな機能一覧よりも早く答えを出します。OpenVPNのディレクティブ、WireGuardのピア鍵、SSTPの接続設定は互いに関係のない三つのプロトコルを表し、インポートのダイアログが一方を他方に変えることはありません。TCPポート443の共有は何も変換しません。SSTP、TLS上のOpenVPN、通常のHTTPSサービスが同じポートを使え、その上に共通点はないからです。

ファイルが.ovpnやWireGuardの設定であれば、答えはすでに出ています。そのクライアントにSSTPを話させる話ではありません。SSTP専用のクライアントに読み込むとプロファイルの段階で失敗し、プロトコルの交渉が始まるはるか前に止まります。

TLSが導入について証明しないこと

完了したTLSハンドシェイクは、サーバーが証明書を持っていることを証明しますが、クライアントが発行チェーンを信頼しているか、その中の名前が一致しているかは何も証明しません。検証は想定したサーバーに対して成功しなければならず、組織が運用する非公開CAも含まれます。証明書エラーを飛ばす提案をするクライアントは、プロトコル対応を得たのではなく検証を取り除いただけです。チェーンの検証と名前の一致は別々のテストであり、片方を通過したスタックがもう片方で失敗することもあります。どちらも受け入れ基準に入れるべきで、トラブルシューティングの付録に置くものではありません。

次にPPP認証方式を確認します。EAP-TLSを使う導入ではPPPの中で証明書を提示できるクライアントが必要であり、パスワード方式ではその交換への対応が必要です。サーバーアドレスとパスワードは、組織の実際の要件を表しません。特に手前に第二要素や端末チェックがある場合はそうです。クライアントが満たせると仮定する前に、サーバーがどの方式を強制しているかを尋ねてください。

四つの段階でセッションを追う

接続が四つの境界を越える様子を見ます。サーバーへのTCPとTLS、SSTPの制御交換、PPPの交渉、そして実際に必要なリソースです。TLSの後で止まるログとPPPの中で止まるログは異なる障害を表し、それぞれ別の担当者に届きます。ブラウザーでホストのウェブページが開くことは、443で何かが応答したことしか証明せず、この分野で最も多い誤検知です。そのページが開くのにクライアントが失敗し続けるなら、問題はTLSより上にあり、ウェブサーバーは容疑者ではありません。

最後に実際の非公開リソースと名前解決で締めます。接続が確立しても何も運ばないセッションは、ほとんどの状態表示では動作中のものと同じに見えるからです。必要なリソースへの一度の成功した要求が、アイコンには答えられない問いを決めます。

対応がない場合は計画を変える

クライアントがSSTPを話せないなら、承認済みの代替を入手するか、サーバーの所有者に両端が対応するプロトコルを求めてください。インポートが通るまで未知のオプションを削除すると、どこにも接続しないプロファイルができあがり、同じ行き止まりへの遅い道になります。万能の互換性をうたう出所不明のインストーラーは、マシンに未承認の信頼経路を追加し、多くの場合プラットフォームのクライアントを組織が更新できないものに置き換えます。どちらも修正ではなく、どちらも元の問題より戻すのが難しくなります。

互換性の問いは、性能や接続先の選択とは切り離して扱ってください。クライアントがそのプロトコルを話せないなら、近いサーバーは役に立ちません。遅延の調整は、決して完了しない段階を直しません。