Windows VPN と Cisco Secure Client、どちらが正しい
ブランドはプロトコル名ではありません。Windows は複数のネイティブ方式を備え、Cisco のクライアントは複数モードのプロファイルを保持します。プロファイルを読んでください。
同じゲートウェイに対して二つの指示が届きます。Windows VPN で接続するか、Cisco クライアントを導入するかです。どちらもゲートウェイが期待する交換を名指ししていません。Windows は複数のネイティブ接続方式を公開し、ベンダーのクライアントは複数モードのプロファイルを保持するため、どちらの呼び名もソフトウェアを指す一方で、ゲートウェイはプロトコル、認証、ポリシーを交渉し、答えはプロファイルにあり、接続しなくても読めます。
呼び名が示すのはソフトウェアで、交換ではない
ブランドとオペレーティングシステムは別の事実であり、どちらも回線上の形式を選びません。Windows はネイティブ方式の一式を提供し、Cisco クライアントは SSL または IPsec/IKEv2 を動かせるプロファイルエンジンを提供します。両者を混同すると、交換ではなく企業を比較する表ができあがります。
下の表は製品の問いを三つの読み取り箇所とそれぞれが保持する項目に置き換えるので、その項目を記録すれば曖昧さは消えます。
| Where to read it | Field name to record | What a mismatch looks like |
|---|---|---|
| Native Windows profile | TunnelType and AuthenticationMethod from Get-VpnConnection | The client offers IKEv2 while the gateway answers only on an SSL port |
| Vendor client profile | SSL or IPsec/IKEv2 mode, plus the client and headend version pair | The imported profile negotiates a mode this headend does not serve |
| Gateway configuration | Protocol, authentication policy and the certificate the headend presents | The client authenticates and then drops, because policy expects another method |
Microsoft が公開する Windows VPN の種類のリファレンス は、ネイティブ方式として IKEv2 と SSTP を挙げており、ネイティブプロファイルが PPTP を意味するという考えは成り立ちません。Cisco のプロファイル文書は、ヘッドエンド側のポリシーに対応する SSL モードと IPsec/IKEv2 モードの両方を説明しています。どのベンダーも複数の選択肢を出すため、どちらの名も一つのプロトコルを指しません。
ネイティブ方式が回線上に置くもの
IKEv2 は UDP 上でセキュリティアソシエーションを交渉し、IPsec の内側で通信を運ぶため、Microsoft 固有の設計ではなく他の IKEv2 実装と対等です。SSTP は PPP を HTTPS セッションの中に包むので、IKEv2 が通れないプロキシを通過し、回線上は TLS のように見えますが TLS VPN プロトコルではありません。この二つの事実が、あるネットワークではトンネルが動き別のネットワークでは失敗するというチケットの大半を説明します。
IPsec 付き L2TP と旧来の PPTP の項目は同じドロップダウンに並びますが、そこにあることはサーバー側の対応を何も語りません。ドロップダウンは OS が試せるものの一覧であり、ゲートウェイの能力宣言ではありません。それを対応一覧として読むことが、二時間の資格情報探しの始まりです。
ネイティブプロファイルで重要な項目は、接続の種類、認証方法、サーバーの識別情報です。誤った種類は誤ったパスワードとは別の段階で失敗し、その違いこそ追う価値のある手がかりです。
ベンダーのクライアントが加えるものはプロファイルであり、プロトコルではありません
Cisco クライアントはプロファイルの入れ物です。SSL モードと IPsec/IKEv2 モードは交換、ポートの期待値、エラー文言が異なり、取り込んだプロファイルがどちらかを選びます。したがってクライアントの導入は到達性を何も証明しません。
バージョンが対になっているのには理由があります。機能、認証フロー、ポスチャ検査はクライアントとヘッドエンドの間で交渉されるため、古いクライアントと新しいヘッドエンドの組み合わせはネットワーク障害のように失敗しえます。その対はアップグレードの覚え書きではなく、接続定義に属します。
別の組織から書き出したプロファイルがローカルのヘッドエンドと一致することはまれで、取り込むとクライアントがゲートウェイの提供しないモードを提示しかねません。まずプロファイルからモードを読み、次にゲートウェイに設定されたプロトコルと認証ポリシーと比べます。両者が一致して初めてネットワークが容疑者になります。この順序なら、誤ったサービスに向いた健全な TLS セッションを示すだけのパケットキャプチャを省けます。
何かを変える前にローカルのプロファイルを読む
Windows ではネイティブ構成をダイヤルせずに読め、出力は種類と認証方法を直接示します。その値を、ゲートウェイの所有者がヘッドエンドの受け入れ条件として語る内容と比べます。種類がチケットと食い違うなら、決して間違っていなかったクライアントを入れ直すよりチケットを先に直すほうが安く済みます。
この四つのコマンドはプロファイル、そのルート、接続の試行、ポートの到達性を扱うので、プロファイルが既に導入された機械でこの順に実行してください。
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443過大に読まれるのはポート試験です。ログインページを配る TCP 443 の待ち受けと IKEv2 を終端する待ち受けは外から見れば同じで、ポートは場所であってプロトコルではありません。
結果はクライアント、モード、ゲートウェイの三項目として書き、チケットのそばに置きます。それより短いと、次の人が同じ曖昧さを発見し直すことになります。