着信トンネルはどの RRAS サイト インターフェイスを選ぶのか
RRAS は着信するサイト インターフェイスをピア アドレス、ユーザー名、証明書のサブジェクトで選ぶため、そのキーは有効状態や接続状態とは分けて読む必要があります。
複数のサイト間インターフェイスを持つ Windows サーバーでは、コンソールのラベルは人間向けのメモにすぎません。RRAS は着信接続の特定のフィールドを使ってどの論理インターフェイスが応答するかを決めており、そのフィールドは認証方法によって変わります。キーを間違えると、何かが偶然つながるまでインターフェイスの名前を変え続けることになります。選択規則、管理状態、セッション状態は三つの別々の事実であり、名前に関するのはそのうち一つだけです。
俗説: 名前を変えたインターフェイスは何にでも一致する
拠点がつながらないときに魅力的な修正は、呼び出し元に似せるまでサイト インターフェイスを作成したり名前を変えたりすることです。それは一つの認証方法では機能し、他の方法では静かに失敗するため、同じ手順が矛盾した結果とともに広まります。サイト インターフェイスは、独自の宛先、保護されたプレフィックス、状態を持つ論理接続オブジェクトです。暗号化されたパケットを運ぶ物理アダプターではないので、ネットワーク アダプターを見てもどのサイト オブジェクトが選ばれたかは分かりません。
選択は通常のリモート アクセス ユーザーとも関係ありません。従業員の VPN クライアントがダイヤルする場合、彼らは別の役割であり、そのユーザー名がこのマッピングに参加することはありません。見慣れた名前に何かを読み込む前に、呼び出し元がどの役割に属するかを確認してください。
三つの認証形態、三つの選択キー
事前共有キーでは、インターフェイスの構成済み宛先アドレスが着信ピアのアドレスと照合されます。ラベルは何でもかまいません。判断を運ぶのはアドレスだからです。ユーザー名ベースの認証では、インターフェイス名が呼び出し元の提示するユーザー名と照合されます。ここではラベルがキーそのものであり、名前の変更が一つのサイトを直し別のサイトを壊すように見えるのはまさにこのためです。
証明書では、インターフェイス名が提示された証明書のサブジェクト名と照合されます。名前はそのサブジェクトに対応している必要があり、運用者が考えただけの美しいラベルでは通用しません。
そこから二つの帰結が生じます。事前共有キーの構成では、特定の宛先に対して有効にできるインターフェイスは一つだけなので、観測された一つのパブリック アドレスを共有する二つの拠点を、重複したエントリで両方とも扱うことはできません。そして、コンソールが何を示唆しても、実際に構成した方法が優先します。
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
有効は接続済みではない
管理状態は論理インターフェイスが動作を許されているかを示します。接続状態は今セッションがあるかを示します。セッションのない有効なインターフェイスは要求時ダイヤル接続の正常な休止状態であり、それを障害として報告すると存在しない停止を追いかけさせます。
名前指定の検索か、文書化されたルーティング ドメインの検索を使ってください。ただし両方のパラメーターを同時に使わず、想定されたサーバー コンテキストで実行します。期待したインターフェイスが最初の一覧にない場合、問題は状態より上流にあります。何も選択されていないのです。
この組は個別ではなく一緒に読んでください。確立したままであるべきなのに切断と表示されるリンクは調査に値し、要求に応じてつながる休止中のダイヤル接続は設計どおりに動作しています。一方、管理上無効化されたインターフェイスは、相手側がルーターを何度再起動しても暗いままです。
どちらの値も、認証が成功したこと、ネゴシエートされた保護が一致すること、ルートがインストールされたこと、プライベート アプリケーションが許可されていることを証明しません。それらは四つの異なる問いと四つの異なる答えです。
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionState何かを有効にする前に ID のトランザクションを読む
着信した呼び出し元が想定外のインターフェイスにマッピングされたとき、有用な証拠は提示された ID であり、無効化されたインターフェイスの一覧ではありません。最近のリモート アクセス イベントを取り出し、呼び出し元のアドレス、認証の結果、選択されたインターフェイス名を読みます。無効化されたインターフェイスは、意図的に廃止されたサイトや禁止されたパートナーの可能性があります。ログイン エラーが一つ消えるかを見るために有効化するのは、ルーティングとアクセスに影響する構成変更なので、そのサイト関係の所有者を通して判断してください。宛先、保護されたプレフィックス、ポリシーも一緒にです。
マッピングが本当に誤っているなら、症状ではなくキーを直してください。証明書のサブジェクト、またはユーザー名の場合はインターフェイス名を、事前共有キーの場合は宛先を修正します。その後一度再接続し、同じ呼び出し元が今度は意図したオブジェクトを選ぶことを確認します。
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }許可された操作でループを閉じる
緑の状態は受け入れではありません。正しいインターフェイスが選ばれたら、設計が許すトラフィックを、一方の保護されたプレフィックスのホストから他方のホストへ生成し、応答が同じ経路で戻ることを確認します。拒否されるべきホストからも同じ試行を行い、次のコマンドを使って Test-NetConnection -ComputerName 10.44.2.10 -Port 445 設計が除外するサービスに対して実行し、リモート アクセス イベントをもう一度読みます。意図したプレフィックス以上を運ぶサイト リンク、またはポリシーが除外するサービスに応答するサイト リンクは、どんな状態確認でも明らかにならないルーティングの誤りです。
認証方法、選択キー、許可されたプレフィックスをサイトの運用書にまとめて記録してください。次のエンジニアは同じ三値の表に出会います。その文脈が書かれて初めて、命名規則は意味を持ちます。