5
Windows 2003 Server - 2 Netzwerkkarten, Remote Access via VPN (RAS)
Client X in Netz A <--> WIN 2003 Server <--> Netz B mit VPN-Client
Ich betreibe ein Win 2003 Server, in welchem 2 Netzwerkkarten eingebaut sind, eine in ein lokales Netz A, die andere in ein lokales Netz B.
Nun stelle ich aus Netz B eine RAS-Verbindung (mittels VPN-Client) mit dem Server her und bekomme automatisch eine IP aus Netz A.
Ein Ping auf die Server-IP aus Netz A funktioniert - nur alle anderen Teilnehmer aus Netz A lassen sich nicht erreichen!
Besitzt der Server nur eine Netzwerkkarte (Netz A) und wird die VPN-Verbindung z.B. über ein Portforwarding über einen NAT-Router aus dem Internet hergestellt, lassen sich auch alle Clients in Netz A erreichen.
Wenn ich RAS richtig verstanden habe, kann es sich dabei nicht um ein Routingproblem handeln, denn der RAS-Dienst sorgt dafür, das der VPN-Server automatisch der Stellvertreter jedes Clients auf OSI-Ebene 2 wird (ARP-Proxy).
D.h. der Server nimmt stellvertretend Pakete, die für die Macadresse eines Clients bestimmt sind an und leitet sie weiter, ganz so, als wäre der Client an einem lokalen Switch angeschlossen.
Das bestätigt sich auch dadurch, das wenn man den RAS-Server betreibt, der entfernte VPN-Client eine lokale IP bekommt, wo wiederum ein lokaler Rechner die Pakete für den VPN-Client nicht an ein Gateway schicken wird um diesen zu erreichen, da er den VPN-Client ja im gleichen Netzsegment "sieht".
Die Netzkonfiguration (Routingtabellen und STD-Gateways müssen nicht verändert werden).
Ist das richtig? Warum funktioniert das dann nicht wenn 2 Netzwerkkarten aktiv sind?
Kann mir jemand einen Tipp geben?
Wer sich dafür interessiert warum eine solche Konfiguration Sinn macht:
Stellt euch einfach vor, Netz B ist unsicher (das könnte ein unverschlüsseltes WLAN sein). Deswegen möchte ich eine sichere Verbindung in Netz A und von dort weiter ins Internet.
Alles klar?
Ein sehr ähnliches Problem hier: Windows 2003 Server: 2 Netzwerkkarten, Probleme beim VPN-Routing
Nun stelle ich aus Netz B eine RAS-Verbindung (mittels VPN-Client) mit dem Server her und bekomme automatisch eine IP aus Netz A.
Besitzt der Server nur eine Netzwerkkarte (Netz A) und wird die VPN-Verbindung z.B. über ein Portforwarding über einen NAT-Router aus dem Internet hergestellt, lassen sich auch alle Clients in Netz A erreichen.
Wenn ich RAS richtig verstanden habe, kann es sich dabei nicht um ein Routingproblem handeln, denn der RAS-Dienst sorgt dafür, das der VPN-Server automatisch der Stellvertreter jedes Clients auf OSI-Ebene 2 wird (ARP-Proxy).
D.h. der Server nimmt stellvertretend Pakete, die für die Macadresse eines Clients bestimmt sind an und leitet sie weiter, ganz so, als wäre der Client an einem lokalen Switch angeschlossen.
Das bestätigt sich auch dadurch, das wenn man den RAS-Server betreibt, der entfernte VPN-Client eine lokale IP bekommt, wo wiederum ein lokaler Rechner die Pakete für den VPN-Client nicht an ein Gateway schicken wird um diesen zu erreichen, da er den VPN-Client ja im gleichen Netzsegment "sieht".
Die Netzkonfiguration (Routingtabellen und STD-Gateways müssen nicht verändert werden).
Ist das richtig? Warum funktioniert das dann nicht wenn 2 Netzwerkkarten aktiv sind?
Kann mir jemand einen Tipp geben?
Wer sich dafür interessiert warum eine solche Konfiguration Sinn macht:
Stellt euch einfach vor, Netz B ist unsicher (das könnte ein unverschlüsseltes WLAN sein). Deswegen möchte ich eine sichere Verbindung in Netz A und von dort weiter ins Internet.
Alles klar?
Ein sehr ähnliches Problem hier: Windows 2003 Server: 2 Netzwerkkarten, Probleme beim VPN-Routing
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 73127
Url: https://administrator.de/contentid/73127
Printed on: April 16, 2024 at 23:04 o'clock
5 Comments
Latest comment
Abend yasdfgr,
also eine Frage brennt mir vorweg auf der Zunge. Du hast 2 Netze, sowei komm ich mit. Aber warum baust aus Netz B eine VPN-Verbindung zu einem Server auf, der in beiden Netzen hängt. Macht doch keinen Sinn!
Fakt: Ich verstehe nicht so ganz deine Netzwerkinfrastuktur und dein Problem. Lese mal nochmal drüber, dann wirst du verstehen was ich meine. Was ist Netz A und B. Beides das LAN oder aber eines zum Roouter, das andere LAN - etc......
Du kannst gerne auch einen Netzplan hochladen. Jedoch bitte, IP-Adresse und Namen schwärzen!
Grüße
Dani
also eine Frage brennt mir vorweg auf der Zunge. Du hast 2 Netze, sowei komm ich mit. Aber warum baust aus Netz B eine VPN-Verbindung zu einem Server auf, der in beiden Netzen hängt. Macht doch keinen Sinn!
Fakt: Ich verstehe nicht so ganz deine Netzwerkinfrastuktur und dein Problem. Lese mal nochmal drüber, dann wirst du verstehen was ich meine. Was ist Netz A und B. Beides das LAN oder aber eines zum Roouter, das andere LAN - etc......
Du kannst gerne auch einen Netzplan hochladen. Jedoch bitte, IP-Adresse und Namen schwärzen!
Grüße
Dani
Hallo Dani,
erst mal danke, dass du dich mit meinem Problem beschäftigst!
Ich hoffe der hochgeladene Netzplan wird dir helfen... (ist ein weing zu groß, ich weiß)
Dann mein Problem noch mal in Kurzform:
In beiden Fällen werden keine Routen konfiguriert! Der Remote-Client wird einfach in LAN A integriert..., so als sei er lokal im Netz, aber nur in einem Fall klappt das!
Warum?
erst mal danke, dass du dich mit meinem Problem beschäftigst!
Ich hoffe der hochgeladene Netzplan wird dir helfen... (ist ein weing zu groß, ich weiß
)Dann mein Problem noch mal in Kurzform:
- beide Netzwerkkarten aktiv
- VPN-Verbindung zum Server aus LAN B - OK
- Ping auf Server durch den Tunnel - OK
- Ping auf das dahinter liegende "sichere" Netz A durch den Tunnel- FEHLER
- eine Netzwerkkarte aktiv
- VPN-Verbindung zum Server aus Internet - OK
- Ping auf Server durch den Tunnel - OK
- Ping auf das "dazwischen" liegende "sichere" Netz A durch den Tunnel - OK
In beiden Fällen werden keine Routen konfiguriert! Der Remote-Client wird einfach in LAN A integriert..., so als sei er lokal im Netz, aber nur in einem Fall klappt das!
Warum?
Hallo,
also da muss ich erstmal passen... Ich würde aber das Problem darin suchen, dass du eigentlich im LAN bleibst. Mit welcher IP-Adresse wählst du den Server an. Die von Adapter A oder B??
Dürfte theoretisch nicht ausmachen, aber bei M$ ist das immer so ne Sache.
Ansonsten würde ich mich mal einwählen und schauen, was ein tracert auf einen Client im Netz A pssiert.
Grüße
Dani
also da muss ich erstmal passen... Ich würde aber das Problem darin suchen, dass du eigentlich im LAN bleibst. Mit welcher IP-Adresse wählst du den Server an. Die von Adapter A oder B??
Dürfte theoretisch nicht ausmachen, aber bei M$ ist das immer so ne Sache.
Ansonsten würde ich mich mal einwählen und schauen, was ein tracert auf einen Client im Netz A pssiert.
Grüße
Dani
Also den Server kontaktiere ich aus dem Internet logischerweise auf NIC A (Portforwarding von der öffentlichen IP des Routers) - aus dem LAN B entsprechend auf NIC B.
tracert mach ich nochmal, aber diese Standard-Diagnose verwende ich normalerweise immer... und ich bin damit nicht weiter gekommen.
Wie gesagt, das Problem sollte, meinem Verständnis nach, eigentlich nicht mit Routing zusammenhängen.
Wenn der VPN-Client eine IP aus Netz A bekommt, wird ja auch kein Rechner aus Netz A seine Pakete für diesen VPN-Client an ein Gateway leiten, sollte er denn eine Ping-Anfrage oder sonst ein Paket bekommen!
Netz-Adresse und Subnetzmaske sagen ihm ja:
*-> lokales Netz
*-> ist direkt erreichbar, also nimm das adress resolution protocol (ARP) und frag mal welche MAC zu dieser IP passt
*schick' das Paket direkt an diese MAC-Adresse
Folglich muss es im Windows 2003 Server folgenden Mechanismus geben:
*ARP-Paket kommt: "Welche MAC gehört zu <IP des VPN-Client>?"
*Server antwortet stellvertretend für alle IP's der registrierten und eingewählten Clients mit seiner eigenen MAC. (ARP-Proxy)
*Rechner aus Netz A schickt also das Paket an diese MAC
*Server leitet das Paket über den entsprechenden Tunnel an den passenden VPN-Client
Irgendwo auf diesem Weg muss der Fehler liegen... vielleicht "blickt" der Server auch nicht richtig wie er die Pakete verteilen soll?!
tracert mach ich nochmal, aber diese Standard-Diagnose verwende ich normalerweise immer... und ich bin damit nicht weiter gekommen.
Wie gesagt, das Problem sollte, meinem Verständnis nach, eigentlich nicht mit Routing zusammenhängen.
Wenn der VPN-Client eine IP aus Netz A bekommt, wird ja auch kein Rechner aus Netz A seine Pakete für diesen VPN-Client an ein Gateway leiten, sollte er denn eine Ping-Anfrage oder sonst ein Paket bekommen!
Netz-Adresse und Subnetzmaske sagen ihm ja:
*-> lokales Netz
*-> ist direkt erreichbar, also nimm das adress resolution protocol (ARP) und frag mal welche MAC zu dieser IP passt
*schick' das Paket direkt an diese MAC-Adresse
Folglich muss es im Windows 2003 Server folgenden Mechanismus geben:
*ARP-Paket kommt: "Welche MAC gehört zu <IP des VPN-Client>?"
*Server antwortet stellvertretend für alle IP's der registrierten und eingewählten Clients mit seiner eigenen MAC. (ARP-Proxy)
*Rechner aus Netz A schickt also das Paket an diese MAC
*Server leitet das Paket über den entsprechenden Tunnel an den passenden VPN-Client
Irgendwo auf diesem Weg muss der Fehler liegen... vielleicht "blickt" der Server auch nicht richtig wie er die Pakete verteilen soll?!
Das Problem ist gelöst!
Ich weiß die Hintergründe noch nicht genau, aber es hat mit der IP-Vergabe des RAS-Dienstes zu tun!
Auffällig ist daran, dass die, bei Verbindungsaufbau erzeugte, PPP-Schnittstelle auf beiden Seiten (also sowohl beim Server, als auch beim Client) die selbe! IP bekommt - in meinem Fall 192.168.0.15.
Bei einer ordentlich funktionierenden Verbindung unterscheidet sich die IP jedoch Server- und Clientseitig - und das muss sie auch!
Im Routing und RAS-Dienst war die Vergabe per DHCP aktiviert und als zu verwendende Schnittstelle NIC A. Folglich sollte der RAS-Dienst bei VPN-Verbindung mindestens zwei IP's vom lokalen DHCP-Server aus Netz A anfordern.
Ich weiß nicht warum mein Server hartnäckig 192.168.0.15 auf beiden Seiten verwendet! Spinnt da der DHCP-Relay??
Nun habe ich jedenfalls einen aus dem DHCP-Server ausgeschlossenen IP-Bereich als statischen Pool im RAS-Dienst angelegt - und siehe da, es funktioniert!!
Ping's auf alle Clients im Netz A, wunderbar - warum nicht gleich so?!
Es hatte also nichts mit den zwei NIC's zu tun.
Aber verstehen muss man das nicht, oder?
Ich weiß die Hintergründe noch nicht genau, aber es hat mit der IP-Vergabe des RAS-Dienstes zu tun!
Auffällig ist daran, dass die, bei Verbindungsaufbau erzeugte, PPP-Schnittstelle auf beiden Seiten (also sowohl beim Server, als auch beim Client) die selbe! IP bekommt - in meinem Fall 192.168.0.15.
Bei einer ordentlich funktionierenden Verbindung unterscheidet sich die IP jedoch Server- und Clientseitig - und das muss sie auch!
Im Routing und RAS-Dienst war die Vergabe per DHCP aktiviert und als zu verwendende Schnittstelle NIC A. Folglich sollte der RAS-Dienst bei VPN-Verbindung mindestens zwei IP's vom lokalen DHCP-Server aus Netz A anfordern.
Ich weiß nicht warum mein Server hartnäckig 192.168.0.15 auf beiden Seiten verwendet! Spinnt da der DHCP-Relay??
Nun habe ich jedenfalls einen aus dem DHCP-Server ausgeschlossenen IP-Bereich als statischen Pool im RAS-Dienst angelegt - und siehe da, es funktioniert!!
Ping's auf alle Clients im Netz A, wunderbar - warum nicht gleich so?!
Es hatte also nichts mit den zwei NIC's zu tun.
Aber verstehen muss man das nicht, oder?