SSTP と OpenVPN：同じポート 443、違うプロトコル

どちらも TCP 443 の背後に置けますが、だからといって互換性のある端点というわけではありません。 SSTP サーバーは HTTPS の中で PPP を話し、OpenVPN サーバーは TLS の上や生の UDP ストリームで独自のプロトコルを話します。一方のクライアントを他方のポートに向けても、ログイン画面に決して到達しない接続になるだけです。選択の基準は どのクライアントとトランスポートを支えられるかであり、番号ではありません。

共有ポートは共有プロトコルではない

TLS ハンドシェイクが完了しても、その後に何を話すかでクライアントとサーバーが一致しないため、どこにも進みません。パケットキャプチャでは、きれいなハンドシェイクの後に、相手が拒否または無視するアプリケーションデータが続くのが見えます。このパターンはプロトコルの不一致の兆候であり、ファイアウォールによる遮断ではありません。

名前を変えたプロファイルも、別のメニュー項目も、一方を他方に変えることはありません。SSTP 接続は Windows の VPN 設定でサーバーアドレスと運営者の認証情報から作成され、OpenVPN 接続にはクライアントと対応する構成ファイルが必要です。 Microsoft の SSTP 仕様 は前者を説明しており、OpenVPN のハンドシェイクは説明していません。

ポート 443 はポリシー上の便宜です。ほとんど何も通さないネットワークを通過でき、それは実際の利点ですが、その後ろでどのプロトコルが動いているかは何も教えてくれません。

SSTP は PPP を HTTPS の中でトンネルします

名前が示すのは構造です。HTTPS セッションの中で運ばれる PPP フレーム、つまり下に TLS があり、クライアントが検証できる証明書があります。Windows はこれをネイティブの VPN 種類として含むため、管理されたノート PC は運営者が提供するプロファイル以外に追加ソフトなしで接続できることがよくあります。

他のプラットフォームは別の話です。Linux や macOS のクライアントには保守された実装が必要で、何をサポートし、エラーをどう報告するかは実装ごとに異なります。実際に使う予定のクライアントを確認し、Windows の内蔵機能がそのまま移ると仮定しないでください。また、プロファイルのサーバー名がサーバーが提示する証明書と一致することを確認してください。

SSTP は通常 TCP のみです。その単一のトランスポートは、損失のある回線での挙動に影響します。再送がトンネルの中でも下でも起きるからです。

OpenVPN は独自のクライアントとトランスポートの選択を持ち込む

OpenVPN は独自のクライアントとプロファイルを提供するため、Windows の標準ダイアログでは見えない診断情報が得られます。サーバーは UDP または TCP で待ち受けでき、どちらを使うかは運営者の構成で決まります。間違ったトランスポートに向けたプロファイルは認証の前に失敗します。

認証も同じく構成次第です。配備は証明書のみ、証明書にユーザー名とパスワード、さらに第二要素を要求することがあり、クライアントはその構成に正確に一致する必要があります。接続が TLS 段階に達しても、次にどの資格情報を求めるかは分かりません。

UDP が通常の既定値なのは、信頼できるストリームを別の信頼できるストリームの中に入れ子にしないで済むからです。TCP モードは UDP を遮断するネットワーク向けに存在し、動作しますが、大きな損失があると置き換えた UDP 経路より悪く感じることがあります。必要なときに TCP を選び、より信頼できるように聞こえるから選ぶのではありません。

クライアント、トランスポート、サポートで選ぶ

三つの問いでほとんどの判断が決まります。すべてのクライアント端末に追加ソフトなしで動く接続が必要ですか。依存するネットワークは UDP を許可していますか、それとも TCP 443 が唯一の出口ですか。そしてプロファイルが切れたとき、クライアントとその更新、復旧を誰が支えますか。

両者を比較するときは、同じ端末と同じアクセスネットワークで試してください。SSTP の端点と OpenVPN の端点が別のサーバーや別の拠点なら、結果にはプロトコルを切り分ける代わりにそれらの経路とマシンが含まれます。こうした比較が自信ありげで間違った答えを出す最も一般的な理由です。

そのうえで、他の何かをデバッグする前に、実際にどちらを確立したかを確認してください：

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

いずれにせよ、トンネルの状態で成功を宣言するのではなく、必要なリソースと DNS を試して終えてください。どちらのプロトコルも選択したプライベートトラフィックだけを運ぶように構成でき、名前解決が機能しないまま接続したトンネルは、実際にはスプリットトンネルや DNS の設計なのに壊れた VPN のように見えます。

管理された端末群では、プロファイルの配布と更新のサポートが、どのトランスポート測定よりもずっと早くこの問いを決めます。