12
VPN Verbindung klappt - kann jedoch nicht über den entfernten Ziel-PC in ein anderes Netz zugreifen?
Hi ihr.
Ich versuche nun schon seit langem via VPN Verbindung von PC3 den PC6 zu erreichen, siehe wiefolgt:
EDIT am 16.04.2009 11:35:
PING von PC3 NIC1 zu PC5 NIC1 - erfolgreich
PING von PC3 NIC1 zu PC5 NIC2 - erfolgreich !!!!!
PING von PC3 NIC1 zu PC6 NIC1 - NICHT erfolgreich ?!?!?
Warum funktioniert der Ping von PC3 NIC1 ins fremde Netz zu PC5 NIC2, aber der Ping zu PC6 NIC1, welcher sich im selben Netz befindet wie PC5 NIC2 nicht???
Gruß Markus
Ich versuche nun schon seit langem via VPN Verbindung von PC3 den PC6 zu erreichen, siehe wiefolgt:
EDIT am 16.04.2009 11:35:
PING von PC3 NIC1 zu PC5 NIC1 - erfolgreich
PING von PC3 NIC1 zu PC5 NIC2 - erfolgreich !!!!!
PING von PC3 NIC1 zu PC6 NIC1 - NICHT erfolgreich ?!?!?
Warum funktioniert der Ping von PC3 NIC1 ins fremde Netz zu PC5 NIC2, aber der Ping zu PC6 NIC1, welcher sich im selben Netz befindet wie PC5 NIC2 nicht???
Gruß Markus
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: 113865
Url: https://administrator.de/forum/vpn-verbindung-klappt-kann-jedoch-nicht-ueber-den-entfernten-ziel-pc-in-ein-anderes-netz-zugreifen-113865.html
Ausgedruckt am: 23.12.2024 um 08:12 Uhr
12 Kommentare
Neuester Kommentar
hi,
ich weis nicht ob das jetzt 100 Pro stimmt, aber ich glaube du musst erstmal eine Netzwerkbrücke machen zwischen der VPN Schnittstelle und der Netzwerkkarte deines Rechners, dann müsste es gehen, wenn das auch noch nicht geht, dann muss noch nen Routing eingetragen werden.
ich weis nicht ob das jetzt 100 Pro stimmt, aber ich glaube du musst erstmal eine Netzwerkbrücke machen zwischen der VPN Schnittstelle und der Netzwerkkarte deines Rechners, dann müsste es gehen, wenn das auch noch nicht geht, dann muss noch nen Routing eingetragen werden.
ne netzwerkbrücke kann nur zwischen gleichen Netzen errichtet werden, ansonsten ist sie sinnlos.
Siehe Wikipedia > Funktion einer Bridge
NIC1 ist 8.x.x.x mit subnet 255.0.0.0
NIC2 ist 192.168.17.x mit subnet 255.255.255.0
Siehe Wikipedia > Funktion einer Bridge
NIC1 ist 8.x.x.x mit subnet 255.0.0.0
NIC2 ist 192.168.17.x mit subnet 255.255.255.0
Hast du an PC 5 das Routing aktiviert über die Registry ???
Wie das geht kannst du hier nachlesen:
Dort erfährst du acuh ein paar Details zum Routing selber.
Denk dran an PC 3 und PC 6 die Firewall entsprechend zu customizen, da diese normalerweise Zugriffe aus Fremdnetzen blocken !!
Testweise kannst du sie deaktivieren !!
Wie das geht kannst du hier nachlesen:
Dort erfährst du acuh ein paar Details zum Routing selber.
Denk dran an PC 3 und PC 6 die Firewall entsprechend zu customizen, da diese normalerweise Zugriffe aus Fremdnetzen blocken !!
Testweise kannst du sie deaktivieren !!
Habe Post geupdatet (siehe oben)!!!
Der VPN Tunnel, wird der zwischen den Firewalls aufgebaut oder zwischen den beiden Endgeräten PC-3 und PC-5 ???
Und....ist die Firewall in PC-6 entsprechend angepasst, das sie Pakete aus dem IP Netz 192.168.13.0 /24 durchlässt ??
Im Zweifelsfall klemmst du einen Sniffer mit Wireshark oder dem MS NetMonitor zwischen PC-5 und PC-6 und checkst mal ob Pakete aus dem 13er Netz da überhaupt ankommen !!
Zur Not installierst du den Sniffer direkt auf PC-5 und checkst das dort !!
Und....ist die Firewall in PC-6 entsprechend angepasst, das sie Pakete aus dem IP Netz 192.168.13.0 /24 durchlässt ??
Im Zweifelsfall klemmst du einen Sniffer mit Wireshark oder dem MS NetMonitor zwischen PC-5 und PC-6 und checkst mal ob Pakete aus dem 13er Netz da überhaupt ankommen !!
Zur Not installierst du den Sniffer direkt auf PC-5 und checkst das dort !!
habe nun die lösung für das problem!
bei Interesse kann ich es auch posten.
Gruß Markus
bei Interesse kann ich es auch posten.
Gruß Markus
Na tolle Antwort !!!
Also, spann uns hier nicht auf die Folter und poste es !!!
(Oder ist es dir peinlich ??)
Zum Schluss dann bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !!
Also, spann uns hier nicht auf die Folter und poste es !!!
(Oder ist es dir peinlich ??)
Zum Schluss dann bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !!
na dann leg ich mal los...
Punkt 1) Der Ping von PC3 NIC1 zu PC 5 NIC2 war erfolgreich.
PC3 schickt eine Message an einen Host im Netzwerk 192.168.17.0; Da PC3 dieses Netz NICHT kennt, schickt er die Message an das Standardgateway, also an PC5 NIC1. PC5 NIC1 bekommt die Message, und sieht dass sie an einen Host im 192.168.17.0 Netz adressiert ist; PC5 NIC1 KENNT das 192.168.17.0 Netz und leitet die Message an die NIC2 weiter. PC5 NIC2 bekommt die Message (Pinganfrage), findet sich selbst als Adressat und schickt eine Bestätigung (Pingantwort) an den UREIGENEN ABSENDER, also 8.29.34.8. Da PC5 NIC2 das 8.0.0.0 Netz kennt, leitet sie die Message an PC5 NIC1 weiter und so gelangt die Pingantwort zurück an PC3 NIC1.
Punkt 2) WARUM DER PING VON PC3 NIC1 zu PC6 NIC1 NICHT ERFOLGREICH WAR:
Man nehme den selben Fall wie oben unter Punkt 1), Absender sei PC3 NIC1, Empfänger für den Ping sei diesmal aber PC6 NIC1, also 192.168.17.60.
Der Weg zu PC5 NIC2 ist derselbe wie unter Punkt 1) beschrieben, sobald PC5 NIC2 die Message bekommt sieht sie, dass der Empfänger 192.168.17.60 ist, und weiß dass die Message an den verbunden Host PC6 NIC1 geschickt werden muss. PC6 NIC1 HAT ALSO IMMER SCHON DIE PINGANFRAGE BEKOMMEN!!!
Interessant wird es jetzt:
PC6 NIC1 erhält die Message, und sieht sich selbst als Empfänger. PC6 NIC1 will also eine Pingantwort an den UREIGENEN ABSENDER (PC3 NIC1) schicken, also eine Message zurück in das 8.0.0.0er Netz.
Da PC6 nicht unmittelbar mit dem 8.0.0.0er Netz verbunden war, KEIN Standardgateway definiert war, also nicht wusste wohin er die Message schicken sollte verwarf er sie einfach.
2 LÖSUNGEN, damit die Antwort von PC6 zurück an den Absender (PC3 NIC1) gelangt:
1. Lösung: PC6 NIC1 muss als Standardgateway die NIC2 von PC5 definiert haben. Somit schickt er Nachrichten an ihm unbekannte Netzwerke standardmäßig an das Standardgateway.
2. (bessere) Lösung: Man muss PC6 per "route add"-Befehl sagen, wie er in das 8.0.0.0er Netz findet, und zwar so:
"route add 8.0.0.0 mask 255.0.0.0 192.168.17.40"
in Worten >> Der Weg ins Netz 8.0.0.0 erfolgt über die NIC2 von PC5, also über die IP 192.168.17.40; Somit weiß PC6, dass er Pakete, die an eine 8.0.0.0er Adresse gerichtet sind, über seine NIC1 raus zur NIC2 von PC5 schicken muss. PC5 sieht die Nachricht an, und leitet sie weiter an die NIC1, welche sich im 8.0.0.0er Netz befindet.
Vorteil von Lösung 2: Sollte bereits ein anderes Standardgateway definiert sein oder will man die Konfiguration an der LAN-Schnittstelle NICHT VERÄNDERN, so bietet sich das Eintragen der Route dafür an. Die Route ist bei einem Reboot wieder weg; sie kann aber auch explizit als STATISCHE Route angelegt werden, sodass sie auch nach einem Neustart immer definiert ist.
Tadadada...
Das Tolle daran:
Trotz aktiver Firewalls an Client- und Serverseite kann man via VPN-Tools (TeamViewer, Hamachi, etc.) einen Tunnel aufbauen, OHNE sich an einen Netzwerkadministrator wenden zu müssen, was meist viiiel Zeit, viiiel Geduld und viiiel Aufwand bedeutet. Mit entsprechender Konfiguration kann man in nur wenigen Minuten auf jeden Rechner im fernen Netz zugreifen! Na wenn das nicht toll ist, ....
THREAD SOLVED
Gruß Markus
Punkt 1) Der Ping von PC3 NIC1 zu PC 5 NIC2 war erfolgreich.
PC3 schickt eine Message an einen Host im Netzwerk 192.168.17.0; Da PC3 dieses Netz NICHT kennt, schickt er die Message an das Standardgateway, also an PC5 NIC1. PC5 NIC1 bekommt die Message, und sieht dass sie an einen Host im 192.168.17.0 Netz adressiert ist; PC5 NIC1 KENNT das 192.168.17.0 Netz und leitet die Message an die NIC2 weiter. PC5 NIC2 bekommt die Message (Pinganfrage), findet sich selbst als Adressat und schickt eine Bestätigung (Pingantwort) an den UREIGENEN ABSENDER, also 8.29.34.8. Da PC5 NIC2 das 8.0.0.0 Netz kennt, leitet sie die Message an PC5 NIC1 weiter und so gelangt die Pingantwort zurück an PC3 NIC1.
Punkt 2) WARUM DER PING VON PC3 NIC1 zu PC6 NIC1 NICHT ERFOLGREICH WAR:
Man nehme den selben Fall wie oben unter Punkt 1), Absender sei PC3 NIC1, Empfänger für den Ping sei diesmal aber PC6 NIC1, also 192.168.17.60.
Der Weg zu PC5 NIC2 ist derselbe wie unter Punkt 1) beschrieben, sobald PC5 NIC2 die Message bekommt sieht sie, dass der Empfänger 192.168.17.60 ist, und weiß dass die Message an den verbunden Host PC6 NIC1 geschickt werden muss. PC6 NIC1 HAT ALSO IMMER SCHON DIE PINGANFRAGE BEKOMMEN!!!
Interessant wird es jetzt:
PC6 NIC1 erhält die Message, und sieht sich selbst als Empfänger. PC6 NIC1 will also eine Pingantwort an den UREIGENEN ABSENDER (PC3 NIC1) schicken, also eine Message zurück in das 8.0.0.0er Netz.
Da PC6 nicht unmittelbar mit dem 8.0.0.0er Netz verbunden war, KEIN Standardgateway definiert war, also nicht wusste wohin er die Message schicken sollte verwarf er sie einfach.
2 LÖSUNGEN, damit die Antwort von PC6 zurück an den Absender (PC3 NIC1) gelangt:
1. Lösung: PC6 NIC1 muss als Standardgateway die NIC2 von PC5 definiert haben. Somit schickt er Nachrichten an ihm unbekannte Netzwerke standardmäßig an das Standardgateway.
2. (bessere) Lösung: Man muss PC6 per "route add"-Befehl sagen, wie er in das 8.0.0.0er Netz findet, und zwar so:
"route add 8.0.0.0 mask 255.0.0.0 192.168.17.40"
in Worten >> Der Weg ins Netz 8.0.0.0 erfolgt über die NIC2 von PC5, also über die IP 192.168.17.40; Somit weiß PC6, dass er Pakete, die an eine 8.0.0.0er Adresse gerichtet sind, über seine NIC1 raus zur NIC2 von PC5 schicken muss. PC5 sieht die Nachricht an, und leitet sie weiter an die NIC1, welche sich im 8.0.0.0er Netz befindet.
Vorteil von Lösung 2: Sollte bereits ein anderes Standardgateway definiert sein oder will man die Konfiguration an der LAN-Schnittstelle NICHT VERÄNDERN, so bietet sich das Eintragen der Route dafür an. Die Route ist bei einem Reboot wieder weg; sie kann aber auch explizit als STATISCHE Route angelegt werden, sodass sie auch nach einem Neustart immer definiert ist.
Tadadada...
Das Tolle daran:
Trotz aktiver Firewalls an Client- und Serverseite kann man via VPN-Tools (TeamViewer, Hamachi, etc.) einen Tunnel aufbauen, OHNE sich an einen Netzwerkadministrator wenden zu müssen, was meist viiiel Zeit, viiiel Geduld und viiiel Aufwand bedeutet. Mit entsprechender Konfiguration kann man in nur wenigen Minuten auf jeden Rechner im fernen Netz zugreifen! Na wenn das nicht toll ist, ....
THREAD SOLVED
Gruß Markus
Mmmmhhh, das es an solcher Banalität gescheitert ist hat hier vermutlich keiner gedacht, denn das das Gateway von PC6 logischerweise die NIC von PC5 sein muss hätte dir jeder IP Anfänger sagen können, das ist natürlich sträflich und in deinem falle tödlich für den Ping.
Wenn du das o.a. Tutorial mit den 2 NICs wirklich gelesen hättest hätte dir sofort ein Licht aufgehen müssen !!!
Naja...Schwamm drüber....
Du hast übrigens noch einen gravierenden denkfehler in deiner Beschreibung von oben !
Die statische Route für das 8er netz ist vollkommen überflüssig, denn für PC6 ist das vollkommen irrelevant !
Dieser sieht ja nur die ursprüngliche IP Adresse von PC3 nämlich 192.168.13.167.
Das 8er netzwerk spielt keine Rolle, das ist ja nur ein VPN Tunnel zw. PC3 und PC5.
Das komplette Paket mit Absender 192.168.13.167 und Empfänger 192.168.17.60 wird in ein IP Paket mit 8er Adressen eingepackt.
Der tiefere Sinn eines VPN !!!
Der VPN Tunnelendpunkt an PC5 schneidet aber den 8er Adressheader wieder komplett ab und schickt das Originalpaket weiter.
In der Beziehung ist also das 8er Netz vollkommen irrelevant für PC6 und logischerweise benötigt der auch keine Route dahin.
Ist ja so oder vollkommen überflüssig, denn sein Standardgateway (da wo er alles hinschickt was er nicht kennt und auch das 8er Netz !!) zeigt ja sowieso auf die NIC 2 von PC5
Fazit: Die statische Route an PC6 ist sinnlos und überflüssig.
Dein Kardinalsfehler war nur die vergesslichkeit (oder Unwissenheit) das Standardgateway zu definieren, was in einem gerouetet Umfeld niemals passieren darf.
Zur VPN Funktion solltest du ggf. nochmal einen Wiki Artikel lesen um zu verstehen wie ein VPN Tunnel richtig funktioniert !!!
Aber gut wenn nun alles klappt !
Wenn du das o.a. Tutorial mit den 2 NICs wirklich gelesen hättest hätte dir sofort ein Licht aufgehen müssen !!!
Naja...Schwamm drüber....
Du hast übrigens noch einen gravierenden denkfehler in deiner Beschreibung von oben !
Die statische Route für das 8er netz ist vollkommen überflüssig, denn für PC6 ist das vollkommen irrelevant !
Dieser sieht ja nur die ursprüngliche IP Adresse von PC3 nämlich 192.168.13.167.
Das 8er netzwerk spielt keine Rolle, das ist ja nur ein VPN Tunnel zw. PC3 und PC5.
Das komplette Paket mit Absender 192.168.13.167 und Empfänger 192.168.17.60 wird in ein IP Paket mit 8er Adressen eingepackt.
Der tiefere Sinn eines VPN !!!
Der VPN Tunnelendpunkt an PC5 schneidet aber den 8er Adressheader wieder komplett ab und schickt das Originalpaket weiter.
In der Beziehung ist also das 8er Netz vollkommen irrelevant für PC6 und logischerweise benötigt der auch keine Route dahin.
Ist ja so oder vollkommen überflüssig, denn sein Standardgateway (da wo er alles hinschickt was er nicht kennt und auch das 8er Netz !!) zeigt ja sowieso auf die NIC 2 von PC5
Fazit: Die statische Route an PC6 ist sinnlos und überflüssig.
Dein Kardinalsfehler war nur die vergesslichkeit (oder Unwissenheit) das Standardgateway zu definieren, was in einem gerouetet Umfeld niemals passieren darf.
Zur VPN Funktion solltest du ggf. nochmal einen Wiki Artikel lesen um zu verstehen wie ein VPN Tunnel richtig funktioniert !!!
Aber gut wenn nun alles klappt !
@aqui:
Kurze Frage:
Wenn PC3 einen Ping an PC5 od. PC6 sendet (also einen Host, erreichbar über die 8.0.0.0er NIC), welche Absender IP-Adresse ist dann im Frame-Header als Source-Adresse wohl verpackt?
Da glaube ich nicht, dass 192.168.13.167 drinne steht, sondern eher wohl die 8er Adresse
Nix für ungut, aber ich glaube da hast du den Denkfehler *gg*
Gruß Markus
Kurze Frage:
Wenn PC3 einen Ping an PC5 od. PC6 sendet (also einen Host, erreichbar über die 8.0.0.0er NIC), welche Absender IP-Adresse ist dann im Frame-Header als Source-Adresse wohl verpackt?
Da glaube ich nicht, dass 192.168.13.167 drinne steht, sondern eher wohl die 8er Adresse
Nix für ungut, aber ich glaube da hast du den Denkfehler *gg*
Gruß Markus
Nein, den Denkfehler machst DU !!!
Sorry aber lies dir mal die Grundlagen von VPN Netzwerken durch und dann kommt dir sicher die Erleuchtung !!
Hier mal ein Ping Weg von PC-3 auf PC-6
...und der Rest ist bekannt.
Das DU hier den Denkfehler machst kannst du dir selber ganz einfach beweisen indem du auf PC-6 einmal einen Wireshark laufen lässt und dir die eingehenden ICMP (Ping) Pakete von PC-3 einmal ansiehst.
Speziell Absender und Empfänger IP Adressen !!!
Danach wirst du vermutlich nicht mehr so vehement rechthaben wollen hier !!!
Sorry aber lies dir mal die Grundlagen von VPN Netzwerken durch und dann kommt dir sicher die Erleuchtung !!
Hier mal ein Ping Weg von PC-3 auf PC-6
- PC-3 erzeugt ein ICMP Echo request Paket (Ping) mit der Quell IP 192.168.13.167 und der Ziel IP 192.168.17.60
- Ein Lookup in der Routing Tabelle sagt ihm das das Zielnetz über seinen VPN Adapter 8.29.34.8 erreichbar ist mit dem Gateway 8.29.76.7.
- Teamviewer bzw. Hamaichi nutzen IPsec im ESP Modus für den VPN Tunnel. Die Abkürzung ESP sagt selber schon was sie macht: Encapsulation Security Payload !!! Der gesamte Ursprungsframe mit der Quell IP 192.168.13.167 und der Ziel IP 192.168.17.60 wird nun komplett in einen IPsec Paket mit der Quell IP 8.29.34.8 und der Ziel IP 8.29.76.7 quasi in einen Huckepack Container über das öffentliche Netzwerk transportiert !!!
- Angekommen beim VPN Server 8.29.76.7 packt dieser das Ursprungspaket wieder aus indem er den Container abschneidet und wegschmeisst und übrig bleibt wieder das originale Paket mit der Quell IP 192.168.13.167 und der Ziel IP 192.168.17.60 !
- Nun sieht PC-5 in seine Routingtabelle und sieht das das 192.168.17er netz direkt an ihm dran ist und forwardet dann das Paket an den Client 192.168.17.60
- Dieser sieht nun die Echo Anforderung und erzeugt ein ICMP Echo Reply Paket (Ping reply) mit der Quell IP 192.168.17.60 und der Ziel IP 192.168.13.167 indem er Quell und Source IP einfach umdreht.
- Default Gate bei ihm zeigt auf PC-5 an den er das Paket schickt (Das was DU vergessen hast !!!)
- PC-5 siehts und kennt das Zielnetz über seinen VPN Tunnel, packt es wieder in den IPsec Container an PC-3
...und der Rest ist bekannt.
Das DU hier den Denkfehler machst kannst du dir selber ganz einfach beweisen indem du auf PC-6 einmal einen Wireshark laufen lässt und dir die eingehenden ICMP (Ping) Pakete von PC-3 einmal ansiehst.
Speziell Absender und Empfänger IP Adressen !!!
Danach wirst du vermutlich nicht mehr so vehement rechthaben wollen hier !!!
nunja... i verstehe schon wie du das mit dem VPN meinst.
Ich weiß nur soviel, dass ich an PC6 zwei Varianten getestet(!) habe:
1. das Default-Gate ist PC5 OHNE hinzufügen einer Route
2. "Route add" für das 8er Netz, erreichbar über die NIC2 von PC5 OHNE Definition des Default-Gates
Variante 2 hat auch funktioniert, laut deiner Theorie dürfte das mit der 8er Route dann gar nicht funktionieren ohne Default-Gate?!?
Gruß Markus
Ich weiß nur soviel, dass ich an PC6 zwei Varianten getestet(!) habe:
1. das Default-Gate ist PC5 OHNE hinzufügen einer Route
2. "Route add" für das 8er Netz, erreichbar über die NIC2 von PC5 OHNE Definition des Default-Gates
Variante 2 hat auch funktioniert, laut deiner Theorie dürfte das mit der 8er Route dann gar nicht funktionieren ohne Default-Gate?!?
Gruß Markus
