RRAS の VPN クライアントには専用の IPv4 プールと戻り経路が必要

VPN クライアントは接続してアドレスを受け取りますが、必要とする LAN のホストは依然として応答できません。Windows Routing and Remote Access では、VPN クライアントの内部アドレスはサーバーの LAN アダプターとは別に構成されたプールから取得され、LAN 側にはそのプールへの戻りルートが必要です。変更は二つであり、一つではなく、それぞれ異なる形で失敗します。古い範囲を廃止する前にアドレス計画と戻り経路を証明できるよう、順番に進めてください。

コンソールを開く前に範囲を予約する

LAN、他の VPN 範囲、サイトへルーティングされるもののいずれとも重複しないプレフィックスを選びます。テストには /24 が扱いやすい大きさで、最初の使用可能な部分をクライアントに渡し、残りは成長のために空けておけます。コンソールに入力する前に、目的と所有者とともに記録してください。後で分割しても再番号付けを強いられないよう、ブロックの両端に余裕を残します。

コンソールの中だけに存在するアドレス計画は、作り直し一回分で衝突に近づきます。また増えがちで、後から誰かが二つ目の範囲を追加し、最初の範囲を誰も確認しません。計画はチャットのスレッドではなく、サーバーの文書の隣に置いてください。

サーバーの LAN アダプターはこのプールを定義しません。公開リスナーを変更したり LAN にアダプターを追加したりしても、まったく別のことを行います。そのためクライアントは接続できても、誤った場所からアドレスを受け取ることがあります。プールはサーバーの IPv4 プロパティにあり、アダプター一覧にはありません。

方式の切り替えは範囲の追加ではない

RRAS には割り当て方式と範囲の集合があります。DHCP から静的プールへの移行は方式の変更です。静的プールがすでに有効な状態で別のブロックを追加するのは範囲の変更です。

どちらかを実行する前に両方の操作をプレビューし、どちらがサーバーの現在の状態に合うかを確認します：

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

サーバーがまだ DHCP 割り当ての場合、二つ目の cmdlet は失敗するか使えないプールを作ります。一つ目は既存のプールを拡張するのではなく方式を置き換えます。どちらのプレビューも何も適用しないので、合う方を実行し、その結果のプールをコンソールで確認します。サーバーがどの状態か分からない場合は、IPv4 プロパティのページで割り当て方式を確認し、構成済みの範囲を一覧します：

Get-VpnIPAddressRange

範囲一覧が空の DHCP 方式なら、一つ目のプレビューが該当します。既存の範囲がある静的アドレスプールなら、二つ目が該当します。

設定に必要なサービス再起動を見込み、接続中のクライアントがすぐに再番号付けされるとは考えないでください。再接続するまで古いアドレスを保持するクライアントは正常な動作です。再接続が許容できる時間帯に変更を計画します。

LAN には戻りルートが必要

LAN が 10.60.0.0/24 で、RRAS サーバーがその上の 10.60.0.10 だとします。その LAN のホストが 10.250.50.0/24 のクライアントに応答するには、RRAS サーバー経由でプールへの経路が必要です。その経路がなければ要求は届いても応答は消えます。

ホストのデフォルトゲートウェイが別のルーターなら、そのルーターに VPN プレフィックスの戻りルートが必要です。RRAS サーバーの静的ルートはここでは役に立たず、戻り経路は LAN ゲートウェイを持つ機器に存在する必要があるため、サイトが使う方式に応じてルーティングテーブルか動的ルーティングのプロセスに追加します。

ホストのファイアウォールとネットワークアクセスの規則も新しい送信元範囲に対して確認します。古いクライアント範囲向けに書かれた規則は、割り当てが成功しても新しい範囲を拒否します。クライアントの LAN 向きルートと DNS 解決は別々の要件で、トンネルが正常に見えても両方が失敗することがあります。それぞれ個別に確認してください。

古いプールを廃止する前に、一つの機器で新しいプールを証明する

自分が管理する認可を一つ選び、再接続してクライアントが受け取ったプールのアドレスを確認します。その一つの数字が割り当てとルーティングを切り分けます。次に特定のアプリケーションを動かし、戻りの通信を観察し、拒否されたままであるべき宛先を試します。三つの観察、三つの異なる失敗の形です。

名前解決には独自の確認が必要です：IP でのアクセスが動いていても、クライアントの DNS が到達できないリゾルバーを指していることがあります。LAN の DNS サーバーに到達できるのは、クライアントにそこへのルートがあり、サーバーが新しい範囲からの問い合わせを受け入れる場合だけです。プールを移すときのよくある見落としです。

古い範囲とその例外は、アクティブなセッションと保守の手順を考慮した後にだけ廃止します。新しいアドレスで接続したクライアントが証明するのは割り当てであり、アクセス方針ではありません。それを使った最後のセッションが切れるまで、古い範囲を文書化しておきます。

三つの観察で結果を確認する

受け入れには三つの事実が必要です：クライアントが新しいプールのアドレスを持つこと、LAN のホストが到達して応答を得られること、拒否された宛先が依然として拒否されることです。それぞれに確認方法があるので、失敗は割り当て、ルーティング、方針のどれかを指します。この順で実行してください。

クライアントから、アドレスと一つの LAN ホストへのルートを確認します：

ipconfig | findstr /i "IPv4"
route print -4

LAN のホストから、戻り経路と方針を一度に確認します。ping は失敗してもアプリケーションが動くなら、欠けているのはルートではなく ICMP の規則である可能性が高いです。両方失敗する場合は、VPN を編集する前にホストのルートを確認してください。三つの結果を変更チケットに記録し、次の担当者が証拠から始められるようにします。