VPNエンドポイント自体がリモートネットワークに接続できる必要があるIPSecVPNのルートを設定する方法
IPSec VPN：トラフィックが正しくルーティングされていません の質問と同じ状況があります（ただし、そのユーザーに直接連絡できないようです。また、その質問にコメントを付けることもできません-そして誰も答えたことがない）。
私もWindows2008 R2サーバーを持っており、IPSecVPNはサーバーで直接終了しています。
サーバーには単一のネットワークインターフェイスがあり、パブリック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.x.xアドレスに送信された「通常の」トラフィック（送信元アドレスが192.168.70.1に強制されていないpingを含む）は、デフォルトルートを介してインターネットに陽気に送信され、トンネルを開始したりトンネルに入ったりすることはありません。
[〜＃〜]質問[〜＃〜]
このような設定も可能ですか？または、VPNエンドポイント自体がそのプライベートアドレスの1つから発信されたデータをトンネルに送信することはできませんか？ （VPNエンドポイントは、トンネルを介してデータを送信するデバイスとは別のルーター上にある必要がありますか？）
10.16.0.0ネットワークとのすべての通信がプライベートIPアドレスから発信されるようにWindowsServerを設定するにはどうすればよいですか。
プライベートアドレスはが192.168.70.1である必要はありません必要に応じて別のサブネットを選択できます（これを読んだので、他のすべての条件が同じであれば、Windows Vista以降では、宛先に最も近い発信元IPが使用されます。したがって、サーバーのプライベートアドレスに10.XXX IPを使用すると役立つでしょうか？）
ただし、このVPNトンネルのもう一方の端が自分の制御下にないため、簡単にテストすることはできません。192.168.70.1アドレスを変更する場合は、もう一方の端のネットワークエンジニアに構成を変更してもらう必要があります。 。
追加情報：私が試したことSO FAR
パケットを正しくルーティングし、トンネルを確立するIPSecルールを満たすために、プライベートIPアドレスを（Windowsサーバー上で）設定する2つの方法を試しました。
メインインターフェイスのプライベートアドレス
（パブリックIPに加えて）メインネットワークインターフェイスに192.168.70.1アドレスが追加されているため、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 LoopbackAdapterデバイスを使用しました。ループバックデバイスは、ネットワーク接続のリストに「メディアが切断されている」と表示されました。仮想NICに接続がなかったので、Windowsは、とにかく（パブリック送信元アドレスを使用して）デフォルトルートを介してトラフィックを送信するようにフォールバックしました。
次に、別の仮想デバイスドライバー（OpenVPNに付属のTAP仮想アダプタードライバー）を試してみました。そのドライバを使用すると、強制的に「常に接続された」状態にすることができます。ただし、最初のpingの後、Windowsはそのアダプターに接続がないことを再度認識し、メイン（パブリック）インターフェイスのデフォルトゲートウェイを介してトラフィックを送信するように戻ります。
だから、それはそれです...何かアイデアはありますか？
これを行おうとすると、送信元IPアドレスの選択がどのように機能するかという自然な傾向と戦っています。では、デザインを少し変更して、より自然に流れるようにしてみませんか？
問題は、トラフィックをトンネルにプッシュする決定の前に送信元IPアドレスの選択が行われることです。つまり、トンネルを介して発信されるトラフィックの送信元IPとして「パブリック」IPアドレスを使用することを選択します。
一部のOS：esでは、ホストから発信されたトラフィックのルート上の送信元アドレスを指定して、ルーティングを使用して楽しいことを行うことができます。しかし、Windowsではそのようなものは見つかりません。
ただし、ネットワーク設計を考えると、この問題を解決する最も簡単な方法は、サーバー側でRFC1918アドレスとの戦いをやめ、パブリックIP203.10.10.10とプライベートIPの間にSAを使用してトンネルを設定することだと思います。アドレス10.16.0.0/15。
クライアントはサーバーを192.168.70.1ではなく203.10.10.10としてアドレス指定し、他のすべては魔法のように適切に配置されることを願っています。そうすれば、送信元IPの選択により、機能する適切なアドレスがすでに選択されます。
移行期間中は古いipsecポリシーを維持できるため、DNSキャッシュの有効期限が切れている間、クライアントは古いRFC1918アドレスまたは新しいパブリックアドレスのいずれかでサーバーをアドレス指定できます（これにDNSを使用していると仮定します-そうでない場合は、それは良い考えです）。移行期間が過ぎると、アドレス192.168.70.1は機能しなくなります。
もう1つのオプションは、サーバーから接続を開始するときに送信元IPアドレスを明示的に選択することです。これは、自分で作成したカスタムソフトウェアの場合は可能かもしれませんが、それはちょっと厄介です。
最後に、そのループバックアダプタのアイデアは有望ですが、「メディアが切断された」と表示されるのは奇妙です。しかし、それはアイデアではなく、ループバックアダプタ自体の問題のように聞こえます。