Ich habe eine identische Situation wie die Frage beiIPSec VPN: Der Datenverkehr wird nicht richtig weitergeleitet(Allerdings scheint es mir nicht möglich zu sein, diesen Benutzer direkt zu kontaktieren, noch kann ich einen Kommentar zu dieser Frage hinterlassen – und niemand hat je geantwortet).
Ich habe auch einen Windows 2008 R2-Server mit einem IPSec-VPN, das direkt am Server endet.
Der Server verfügt über eine einzelne Netzwerkschnittstelle mit einer öffentlichen IP-Adresse (nennen wir sie beispielsweise 203.10.10.10).
Ich möchte, dass Computer in einem entfernten, privaten Netzwerk (10.16.0.0/255.254.0.0) eine Verbindung zu diesem Windows-Server über eine private IP-Adresse am Ende eines IPSec-Tunnels herstellen können, der endetbeidiesem Server (nicht an einem Router vor dem Server).
Genauso wichtig (und das könnte der Knackpunkt sein) ist, dass der Server in der Lage sein muss, eine TCP-Verbindung zu Geräten im Remote-Netzwerk (10.16.0.0) herzustellen (z. B. um ein Bild über HTTP herunterzuladen).
So sieht es aus:
Die private IP, die ich für den Server gewählt habe, ist 192.168.70.1/255.255.255.0 und die IPSec-Filter, die den Tunnel zum Remote-Privatnetzwerk herstellen, sind für Quelle/Ziel 192.168.70.0/24 und 10.16.0.0/15.
Wenn ich vom Windows-Server aus eine Adresse im Remote-Netzwerk anpinge und dabei das Quellargument festgelegt habe, kann ich den Tunnel einrichten und die Pings funktionieren (d. h. ping -S 192.168.70.1 10.16.0.1).
Jeglicher „normaler“ Datenverkehr an eine 10.16.xx-Adresse (einschließlich Pings ohne die erzwungene Quelladresse 192.168.70.1) wird jedoch problemlos über die Standardroute ins Internet gesendet und startet oder betritt den Tunnel nicht.
FRAGE
Ist ein solches Setup überhaupt möglich? Oder ist es nicht möglich, dass der VPN-Endpunkt selbst Daten durch den Tunnel sendet, die von einer seiner privaten Adressen stammen? (Muss sich der VPN-Endpunkt immer auf einem anderen Router befinden als die Geräte, die Daten durch den Tunnel senden?)
Wie kann ich den Windows-Server einrichten, um sicherzustellen, dass die gesamte Kommunikation mit dem Netzwerk 10.16.0.0 von seiner privaten IP-Adresse ausgeht?
Die Privatadressehabenauf 192.168.70.1 - bei Bedarf kann ein anderes Subnetz gewählt werden (ich sage das, weil ich gelesen habe, dass unter Windows Vista und höher bei sonst gleichen Bedingungen die Ursprungs-IP verwendet wird, die am ehesten mit der Ziel-IP übereinstimmt - also wäre es vielleicht hilfreich, eine 10.XXX-IP für die private Adresse des Servers zu verwenden?)
Ich kann das jedoch nicht so einfach testen, da das andere Ende dieses VPN-Tunnels nicht unter meiner Kontrolle steht – und ich müsste die Netzwerktechniker am anderen Ende Konfigurationsänderungen vornehmen lassen, wenn ich die Adresse 192.168.70.1 ändern möchte.
ZUSÄTZLICHE INFOS: WAS ICH BISHER VERSUCHT HABE
Ich habe zwei Methoden ausprobiert, um diese private IP-Adresse einzurichten (auf dem Windows-Server), um zu versuchen, die Pakete richtig weiterzuleitenUnderfüllen die IPSec-Regeln, die den Tunnel aufbauen.
Private Adresse auf der Hauptschnittstelle
Mit der zur Hauptnetzwerkschnittstelle hinzugefügten Adresse 192.168.70.1 (zusätzlich zur öffentlichen IP) scheint es nicht möglich zu sein, Routen zu 10.16.0.0 zu definieren, die dazu führen würden, dass Windows 192.168.70.1 als Quelladresse verwendet. Jeglicher Datenverkehr, der für das Standard-Gateway bestimmt ist, endet mit der öffentlichen IP als Quelle.
Wenn es in Windows irgendeinen magischen Weg gibt, den ich noch nicht kenne, würde ich gerne davon erfahren! Der Befehl:
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
führt dazu, dass Routen wie folgt hinzugefügt werden (es ruft die öffentliche IP auf derselben Schnittstelle ab, um sie als Quell-/On-Link-Gateway zu verwenden).
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
Private Adresse auf einem zweiten virtuellen Adapter
Ich habe versucht, dem Server einen virtuellen Netzwerkadapter hinzuzufügen – zunächst mit dem Microsoft Loopback Adapter-Gerät. Das Loopback-Gerät wurde in der Liste der Netzwerkverbindungen mit der Meldung „Medien getrennt“ angezeigt. Als Windows sah, dass die virtuelle Netzwerkkarte keine Verbindung hatte, griff es einfach darauf zurück, den Datenverkehr trotzdem über die Standardroute zu senden (mit der öffentlichen Quelladresse).
Ich habe es dann mit einem anderen virtuellen Gerätetreiber versucht – dem TAP Virtual Adapter-Treiber, der mit OpenVPN geliefert wird. Mit diesem Treiber können Sie ihn in einen „immer verbundenen“ Zustand zwingen. Es scheint jedoch, dass Windows nach dem ersten Ping erneut feststellt, dass auf diesem Adapter keine Verbindung besteht, und den Datenverkehr wieder über das Standard-Gateway auf der Hauptschnittstelle (öffentlich) sendet.
So, das ist es ... irgendwelche Ideen?
Antwort1
Wenn Sie dies versuchen, kämpfen Sie gewissermaßen gegen die natürlichen Tendenzen der Auswahl der Quell-IP-Adresse. Warum ändern Sie Ihr Design also nicht einfach ein wenig, damit es natürlicher fließt?
Das Problem besteht darin, dass die Auswahl der Quell-IP-Adresse vor der Entscheidung erfolgt, den Verkehr durch den Tunnel zu leiten. Das bedeutet, dass die „öffentliche“ IP-Adresse als Quell-IP für jeglichen Verkehr verwendet wird, der durch den Tunnel kommt.
Auf einigen Betriebssystemen kann man mit Routing lustige Dinge anstellen, indem man Quelladressen auf einer Route für vom Host stammenden Datenverkehr angibt. Unter Windows kann ich so etwas allerdings nicht finden.
Angesichts Ihres Netzwerkdesigns denke ich jedoch, dass die einfachste Lösung dieses Problems darin besteht, nicht mehr serverseitig mit RFC1918-Adressen zu kämpfen, sondern einfach einen Tunnel mit SAs zwischen Ihrer öffentlichen IP 203.10.10.10 und den privaten IP-Adressen 10.16.0.0/15 einzurichten.
Die Clients würden den Server dann als 203.10.10.10 statt als 192.168.70.1 ansprechen und alles andere würde sich hoffentlich wie von Zauberhand ergeben. Auf diese Weise wird bei der Quell-IP-Auswahl bereits eine geeignete Adresse ausgewählt, die funktioniert.
Sie können die alte IPSec-Richtlinie während einer Übergangsphase beibehalten, sodass Ihre Clients den Server entweder mit der alten RFC1918-Adresse oder mit der neuen öffentlichen Adresse ansprechen können, während Ihr DNS-Cache abläuft (vorausgesetzt, Sie verwenden hierfür DNS – wenn nicht, ist das eine gute Idee). Nach einer Übergangsphase hat die Adresse 192.168.70.1 keine Funktion mehr.
Die andere Möglichkeit besteht darin, beim Initiieren von Verbindungen von Ihrem Server aus explizit die Quell-IP-Adresse auszuwählen. Dies ist möglicherweise möglich, wenn es sich um eine von Ihnen selbst geschriebene benutzerdefinierte Software handelt, aber das ist ziemlich haarig.
Schließlich ist die Idee mit dem Loopback-Adapter vielversprechend, es ist allerdings seltsam, dass er als „Medien getrennt“ angezeigt wird. Das klingt allerdings eher nach einem Problem mit dem Loopback-Adapter selbst als mit der Idee.