8
Win Server 2003 - Routing von 2 LANs über VPN
LAN A <--> Win Server 2003 <---VPN-Tunnel---> Win Server 2003 <--> LAN B
Ich möchte die simple Aufgabe lösen zwei LAN's über VPN miteinander zu verbinden. Ich bekomm es aber beim besten Willen nicht hin und ich versteh' nicht warum es nicht funktioniert.
Die VPN-Kopplung von Server A nach Server B steht! Eingerichtet nach der, auch von Microsoft beschrieben, Weise über "Wählen bei Bedarf" in Verbindung mit statischen Routen.
Bei Verbindungswunsch des Servers A in LAN B und Server B in LAN A wird die bidirektionale VPN-Verbindung auch wunderbar aufgebaut!
Selbst ein Ping von Server A auf Server B und auch LAN B und umgekehrt funktioniert - allerdings jeweils nur direkt vom Server!!
Also hab ich überlegt:
Wenn die Client-Rechner in LAN B nicht Server B als Gateway eingetragen haben, dürfte auch keine Antwort aus LAN B nach Server A zurückkommen.
Nun ist es ja aber so, dass Server A auch eine IP aus LAN B besitzt und Server B agiert offensichtlich als ARP-Proxy und leitet dementsprechend die Pakete an Server A. Toll... ich will aber das IP-Routing funktioniert! Wo kann man eigentlich die ARP-Proxy-Funktion beeinflussen??
Also trag' ich in Rechner aus LAN A tatsächlich Server A als Standardgateway ein und dementsprechend auch auf den Rechnern in LAN B, Server B als Std-GW.
Nur es tut nicht!
Was mach ich falsch?
IP-Routing ist auf beiden Servern aktiviert, die statischen Routen passen auch...
Kann mir jemand einen Tipp geben?
Nebenbei: Was zum Geier bewirkt überhaupt das Setzen des Kontrollkästchens "RAS-Server" in den Eigenschaften des Routingdienstes? Ich kann doch bei den WAN-Ports auch von Hand einstellen, dass er zum Einwählen für Clients freigegeben wird; dann erscheint dort "Routing/RAS". Und es funktioniert auch ohne das Häkchen!!
Ich möchte die simple Aufgabe lösen zwei LAN's über VPN miteinander zu verbinden. Ich bekomm es aber beim besten Willen nicht hin und ich versteh' nicht warum es nicht funktioniert.
Die VPN-Kopplung von Server A nach Server B steht! Eingerichtet nach der, auch von Microsoft beschrieben, Weise über "Wählen bei Bedarf" in Verbindung mit statischen Routen.
Bei Verbindungswunsch des Servers A in LAN B und Server B in LAN A wird die bidirektionale VPN-Verbindung auch wunderbar aufgebaut!
Selbst ein Ping von Server A auf Server B und auch LAN B und umgekehrt funktioniert - allerdings jeweils nur direkt vom Server!!
Also hab ich überlegt:
Wenn die Client-Rechner in LAN B nicht Server B als Gateway eingetragen haben, dürfte auch keine Antwort aus LAN B nach Server A zurückkommen.
Nun ist es ja aber so, dass Server A auch eine IP aus LAN B besitzt und Server B agiert offensichtlich als ARP-Proxy und leitet dementsprechend die Pakete an Server A. Toll... ich will aber das IP-Routing funktioniert! Wo kann man eigentlich die ARP-Proxy-Funktion beeinflussen??
Also trag' ich in Rechner aus LAN A tatsächlich Server A als Standardgateway ein und dementsprechend auch auf den Rechnern in LAN B, Server B als Std-GW.
Nur es tut nicht!
- Kein Ping in das jeweils andere LAN geht durch.
- "tracert" hört nach dem ersten Hop zum Gateway auf!
Was mach ich falsch?
IP-Routing ist auf beiden Servern aktiviert, die statischen Routen passen auch...
Kann mir jemand einen Tipp geben?
Nebenbei: Was zum Geier bewirkt überhaupt das Setzen des Kontrollkästchens "RAS-Server" in den Eigenschaften des Routingdienstes? Ich kann doch bei den WAN-Ports auch von Hand einstellen, dass er zum Einwählen für Clients freigegeben wird; dann erscheint dort "Routing/RAS". Und es funktioniert auch ohne das Häkchen!!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72568
Url: https://administrator.de/contentid/72568
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
8 Kommentare
Neuester Kommentar
Ich möchte die simple Aufgabe lösen
zwei LAN's über VPN miteinander zu
verbinden.
zwei LAN's über VPN miteinander zu
verbinden.
Simple Aufgabe? Selten so gelacht. In aller Regel funktioniert das nicht (gleich), weil immer irgendwas anders ist als es sein soll. Davon leben wir Admins schliesslich auch.
Als Test würde ich die beiden Server erst mal in das selbe Subnet stellen (ggf. musst Du die DHCP-Einstellungen auf einem Server ändern) und dann gucken ob's geht (tut es meistens), um sicherzustellen dass Du ein Routing-Problem hast. Dann kannst Du weiter forschen.
Als Test würde ich die beiden Server
erst mal in das selbe Subnet stellen
erst mal in das selbe Subnet stellen
So wie ich das verstanden habe müssen Server A & Server B doch in unterschiedlichen Subnetzen stehen.
Wie soll sonst das "Wählen bei Bedarf" funktionieren? Das wird ja im Prinzip durch die statische Route ins andere Subnetz erst gestartet.
Oder gibt's noch einen anderen Weg?
Hallo: ganz simpel geht das mit den Routern von Lancom, die bieten sogar ein 1-KlickVPN an. Da hat man im Handumdrehen zwei Netzwerke per VPN verbunden.
Das ist die Aussage von Lancom. Ich habe das bis heute nicht geschafft, das ist der letzte Mist. Das Lancom-Forum ist leider auch nicht der Hit.
Was ich damit sagen wollte? Also mit den entsprechenden Hardware-Routern lässt sich so ein VPN besser aufbauen als mit Windowsbordmitteln, denn, was macht man, wenn einer der Server ausfällt?
Gruß,
Arch Stanton
Das ist die Aussage von Lancom. Ich habe das bis heute nicht geschafft, das ist der letzte Mist. Das Lancom-Forum ist leider auch nicht der Hit.
Was ich damit sagen wollte? Also mit den entsprechenden Hardware-Routern lässt sich so ein VPN besser aufbauen als mit Windowsbordmitteln, denn, was macht man, wenn einer der Server ausfällt?
Gruß,
Arch Stanton
Wäre ja mal interessant gewesen wenn du diese Routen mal gepostet hättest, denn meist ist es doch ein Routing Problem.
Fakt ist, das sofern die Server IP Adressen in beiden LANs A und B auf die Default Adressen der Clients sind, in den Servern folgende statische Routen stehen müssten:
(Annahme LAN A: 172.16.1.0/24 und LAN B: 172.16.2.0/24)
Server LAN A:
route add -p 172.16.2.0 mask 255.255.255.0 <ip_addr_VPN_server-b> metric 1
Analog dann bei Server LAN B:
route add -p 172.16.1.0 mask 255.255.255.0 <ip_addr_VPN_server-a> metric 1
Damit sollte es eigentlich funktionieren
Fakt ist, das sofern die Server IP Adressen in beiden LANs A und B auf die Default Adressen der Clients sind, in den Servern folgende statische Routen stehen müssten:
(Annahme LAN A: 172.16.1.0/24 und LAN B: 172.16.2.0/24)
Server LAN A:
route add -p 172.16.2.0 mask 255.255.255.0 <ip_addr_VPN_server-b> metric 1
Analog dann bei Server LAN B:
route add -p 172.16.1.0 mask 255.255.255.0 <ip_addr_VPN_server-a> metric 1
Damit sollte es eigentlich funktionieren
Problem ist schon mal, dass man im Routingdienst bei "Statische Routen" für das Interface für "Wählen bei Bedarf" kein Gateway angeben kann (Feld wird ausgegraut).
Ich vermute, dass hängt damit zusammen, das Win Server 2003 beim Aufbau des VPN-Tunnels irgendwelche virtuellen Schnittstellen erzeugt, die eine vorher nicht bestimmbare IP erhält.
In meinem Fall bekommt Server A eine virtuelle Schnittstelle 192.168.99.30 aus Bereich B und Server B eine virtuelle Schnittstelle 192.168.99.34.
Und wie ich das verstehe, stellt das die beiden Endpunkte für den VPN-Tunnel in eine Richtung dar. Es werden automatisch einige Einträge in der Routingtabelle vorgenommen.
Ich werd echt verrückt mit diesem virtuellen Mist!
So hier mal die relevanten Einträge von LAN A (192.168.1.0) nach LAN B (192.168.99.0)
Ich probier das jetz noch mal mit der Route...
Ich vermute, dass hängt damit zusammen, das Win Server 2003 beim Aufbau des VPN-Tunnels irgendwelche virtuellen Schnittstellen erzeugt, die eine vorher nicht bestimmbare IP erhält.
In meinem Fall bekommt Server A eine virtuelle Schnittstelle 192.168.99.30 aus Bereich B und Server B eine virtuelle Schnittstelle 192.168.99.34.
Und wie ich das verstehe, stellt das die beiden Endpunkte für den VPN-Tunnel in eine Richtung dar. Es werden automatisch einige Einträge in der Routingtabelle vorgenommen.
Ich werd echt verrückt mit diesem virtuellen Mist!
So hier mal die relevanten Einträge von LAN A (192.168.1.0) nach LAN B (192.168.99.0)
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
192.168.99.0 255.255.255.0 0.0.0.0 192.168.99.30 2
192.168.99.0 255.255.255.0 192.168.99.34 192.168.99.30 2
192.168.99.30 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.99.34 255.255.255.255 192.168.99.30 192.168.99.30 1
192.168.99.255 255.255.255.255 192.168.99.30 192.168.99.30 50
Ja, wie vermutet dort stehen die Zielnetze gar nicht in der Routing Table...kein Wunder das es nicht klappt.
Besser ist sowas immer mit einem VPN fähigen Router zu lösen. Entweder was fertiges von z.B. Draytek oder
Das erspart einen eine Menge grauer Haare und ist zudem erheblich sicherer und auch noch einfacherer Aufzusetzen.
Besser ist sowas immer mit einem VPN fähigen Router zu lösen. Entweder was fertiges von z.B. Draytek oder
Das erspart einen eine Menge grauer Haare und ist zudem erheblich sicherer und auch noch einfacherer Aufzusetzen.
Ich hab's - es funktioniert!!
Und ich hab keine weiteren Routingeinträge vorgenommen. Wenn man es richtig macht geht's auch!
Folgt man der Anleitung http://www.stefan-korn.de/website/computer/winroutingtut.html muss man Kapitel 3.2 unbedingt beachten!!
Warum nun Win Server 2003 das nun so will ist mir zwar schleierhaft (was hat das Routing mit der Authentifizierung zu tun??) aber gut...
Da ich wohl "nur" zwei RAS-Verbindungen hatte, kann ich mir ein wenig erklären warum des Pingen ins andere Netz vom Server jeweils ging: es war eben ARP Proxy aktiv.
Irgendwie wird das mit dem Routing dann wohl anders verbogen...
Ich werde allerdings nochmal einen genauen Blick auf die jetzigen (teils automatisch erstellten) Routingtabellen werfen...
P.S.: beim neu Erstellen der Verbindungen und anschließendem Verbinden kam es übrigens zunächst zu folgendem Fehler: "Es können keine weiteren Verbindungen zu dem Remotecomputer hergestellt werden, da zu diesem Computer die maximale Anzahl von Clients verbunden ist."
Ein mehrmaliges Neustarten des Servers half nicht!!
Ich bin mir nicht ganz sicher, aber nachdem ich die Konfiguration der Ports im Routingdienst verändert habe und danach auf den Soll-Zustand zurückgesetzt, lief es plötzlich!
Und ich hab keine weiteren Routingeinträge vorgenommen. Wenn man es richtig macht geht's auch!
Folgt man der Anleitung http://www.stefan-korn.de/website/computer/winroutingtut.html muss man Kapitel 3.2 unbedingt beachten!!
Wählt sich der fremde Router mit einem anderen Konto an, welches nicht den Namen der Routingschnittstelle trägt, wird er nicht als Router erkannt.
Es besteht dann nur eine RAS-Verbindung zwischen den beiden Servern, und Routing zu anderen Rechnern im Netzwerk ist nicht möglich.
Das hatte ich nicht gemacht.Es besteht dann nur eine RAS-Verbindung zwischen den beiden Servern, und Routing zu anderen Rechnern im Netzwerk ist nicht möglich.
Warum nun Win Server 2003 das nun so will ist mir zwar schleierhaft (was hat das Routing mit der Authentifizierung zu tun??) aber gut...
Da ich wohl "nur" zwei RAS-Verbindungen hatte, kann ich mir ein wenig erklären warum des Pingen ins andere Netz vom Server jeweils ging: es war eben ARP Proxy aktiv.
Irgendwie wird das mit dem Routing dann wohl anders verbogen...
Ich werde allerdings nochmal einen genauen Blick auf die jetzigen (teils automatisch erstellten) Routingtabellen werfen...
P.S.: beim neu Erstellen der Verbindungen und anschließendem Verbinden kam es übrigens zunächst zu folgendem Fehler: "Es können keine weiteren Verbindungen zu dem Remotecomputer hergestellt werden, da zu diesem Computer die maximale Anzahl von Clients verbunden ist."
Ein mehrmaliges Neustarten des Servers half nicht!!
Ich bin mir nicht ganz sicher, aber nachdem ich die Konfiguration der Ports im Routingdienst verändert habe und danach auf den Soll-Zustand zurückgesetzt, lief es plötzlich!
Es ist und bleibt aber etwas eine Frickelei unter Win. Technisch, wie gesagt, ist es immer besser man erledigt so eine Standortvernetzung mit VPN Routern sofern man bei der Planung dann weiter denkt und die VPN Option bei den Routern miterwirbt.
Aber klasse wenns jetzt auch so klappt.
Aber klasse wenns jetzt auch so klappt.
