私は質問と同じ状況にありますIPSec VPN: トラフィックが正しくルーティングされない(ただし、そのユーザーに直接連絡することも、その質問にコメントすることもできないようです。また、誰も回答していません)。
私も Windows 2008 R2 サーバーを所有しており、IPSec VPN はサーバーで直接終了しています。
サーバーには単一のネットワーク インターフェイスがあり、そこにはパブリック IP アドレス (たとえば、203.10.10.10 と呼びます) が割り当てられています。
リモートのプライベートネットワーク（10.16.0.0/255.254.0.0）上のコンピュータが、IPSecトンネルの終端にあるプライベートIPアドレスでそのWindowsサーバーに接続できるようにしたい。でそのサーバー（サーバーの前のルーターではありません）。
同様に重要なのは (そしてこれが問題点になるかもしれませんが)、サーバーがリモート (10.16.0.0) ネットワーク上のデバイスへの TCP 接続を開始できることです (たとえば、HTTP 経由でイメージをダウンロードするため)。
それは次のようになります:
サーバーに選択したプライベート IP は 192.168.70.1/255.255.255.0 であり、リモート プライベート ネットワークへのトンネルを確立する IPSec フィルターは、送信元/送信先が 192.168.70.0/24 および 10.16.0.0/15 用です。
Windows サーバーからソース引数を設定してリモート ネットワーク上のアドレスに ping を実行すると、トンネルを確立でき、ping が機能します (つまりping -S 192.168.70.1 10.16.0.1)。
ただし、10.16.xx アドレスに送信される「通常の」トラフィック (送信元アドレスが 192.168.70.1 に強制されていない ping を含む) は、デフォルト ルート経由でインターネットに問題なく送信され、トンネルを開始したりトンネルに入ったりすることはありません。
質問
このような設定は可能でしょうか? それとも、VPN エンドポイント自体が、そのプライベート アドレスの 1 つからデータをトンネル経由で送信することはできないのでしょうか? (VPN エンドポイントは、トンネル経由でデータを送信するデバイスとは別のルーター上に常に存在する必要がありますか?)
10.16.0.0 ネットワークとのすべての通信がプライベート IP アドレスから発信されるように Windows Server を設定するにはどうすればよいでしょうか。
プライベートアドレスは持っている192.168.70.1 になります - 必要に応じて別のサブネットを選択できます (他の条件が同じであれば、Windows Vista 以降では宛先に最も近い発信元 IP が使用されると読んだため、サーバーのプライベート アドレスに 10.XXX IP を使用すると役立つかもしれません)。
ただし、この VPN トンネルのもう一方の端は私の管理下にないため、これを簡単にテストすることはできません。また、192.168.70.1 アドレスを変更する場合は、もう一方の端のネットワーク エンジニアに構成の変更を依頼する必要があります。
追加情報: これまで試したこと
パケットを正しくルーティングするために、Windowsサーバー上でプライベートIPアドレスを設定する2つの方法を試しました。そしてトンネルを確立する IPSec ルールを満たします。
メインインターフェース上のプライベートアドレス
メイン ネットワーク インターフェイスに 192.168.70.1 アドレス (パブリック IP に加えて) が追加されているため、Windows が 192.168.70.1 を送信元アドレスとして使用するような 10.16.0.0 へのルートを定義することは不可能と思われます。デフォルト ゲートウェイ宛てのトラフィックはすべて、送信元としてパブリック IP を使用します。
Windows 上でルートに関して私が知らない魔法が使えるなら、ぜひ教えてください。ただし、コマンド:
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
次のようにルートが追加されます (ソース/オンリンク ゲートウェイとして使用するために、同じインターフェイス上のパブリック IP が選択されます)。
10.16.0.0 255.254.0.0 On-link 203.10.10.10 11 10.17.255.255 255.255.255.255 On-link 203.10.10.10 266
2番目の仮想アダプタ上のプライベートアドレス
最初に Microsoft Loopback Adapter デバイスを使用して、仮想ネットワーク アダプターをサーバーに追加しようとしました。ループバック デバイスは、ネットワーク接続のリストに「メディアが切断されています」と表示されました。仮想 NIC に接続がないことがわかったため、Windows は、とにかくデフォルト ルート (パブリック ソース アドレスを使用) 経由でトラフィックを送信するようになりました。
次に、別の仮想デバイス ドライバー (OpenVPN に付属の TAP 仮想アダプター ドライバー) を試しました。このドライバーを使用すると、強制的に「常時接続」状態にすることができます。ただし、最初の ping の後、Windows は再びそのアダプターに接続がないと判断し、メイン (パブリック) インターフェイスのデフォルト ゲートウェイ経由でトラフィックを送信する状態に戻るようです。
ということで、以上です...何かアイデアはありますか?
答え1
これを実行しようとすると、ソース IP アドレスの選択の自然な傾向に逆らうことになります。それでは、より自然な流れになるように、デザインを少し変更してみてはいかがでしょうか。
問題は、トラフィックをトンネルにプッシュする決定の前に、送信元 IP アドレスの選択が行われることです。つまり、トンネル経由で発信されるすべてのトラフィックの送信元 IP として「パブリック」IP アドレスを使用することが選択されることになります。
一部の OS では、ホストから発信されたトラフィックのルート上の送信元アドレスを指定して、ルーティングで面白いことができます。ただし、Windows ではそのようなものは見つかりません。
ただし、ネットワーク設計を考慮すると、この問題を解決する最も簡単な方法は、サーバー側で RFC1918 アドレスと格闘するのをやめて、パブリック IP 203.10.10.10 とプライベート IP アドレス 10.16.0.0/15 の間に SA を使用してトンネルを設定することだと思います。
そうすると、クライアントはサーバーのアドレスを 192.168.70.1 ではなく 203.10.10.10 として指定するようになり、他のすべてが魔法のようにうまくいくはずです。こうすることで、ソース IP 選択によって、機能する適切なアドレスがすでに選択されます。
移行期間中は古い ipsec ポリシーを維持して、DNS キャッシュの有効期限が切れる間、クライアントが古い RFC1918 アドレスまたは新しいパブリック アドレスのいずれかを使用してサーバーをアドレス指定できるようにすることができます (このために DNS を使用していると仮定します。そうでない場合は、DNS を使用することをお勧めします)。移行期間が経過すると、アドレス 192.168.70.1 は機能しなくなります。
もう 1 つのオプションは、サーバーから接続を開始するときに送信元 IP アドレスを明示的に選択することです。これは、自分で作成したカスタム ソフトウェアの場合は可能かもしれませんが、少し面倒です。
最後に、ループバック アダプタのアイデアは有望ですが、「メディアが切断されました」と表示されるのは奇妙です。ただし、これはアイデアの問題ではなく、ループバック アダプタ自体の問題のように思えます。