20
OpenVPN Netzwerkfreigabe spinnt via DSL
Hi Leute.
Etwas kurioses Problem.
Habe zwei Standorte. An dem einen eine Fritzbox 7590 mit Vodafone DSL 16 Mbit. Dort läuft der OpenVPN Server. An dem anderen eine Fritzbox 7530 mit 1&1 DSL 50 Mbit. Dort der OpenVPN Client. Bis zum Wochenende lief alles einwandfrei bis jemand dachte es ist gut, da das Internet gesponnen hat, die FB7590 komplett zurück zu setzen.
Nun habe ich heute die FB wieder eingerichtet mit anderen IP Nummernkreis, DynDNS, Portfreigabe, WLAN etc.
Seit dem spinnt jedoch die Freigabe auf dem Server. Und zwar nur wenn ich mit dem DSL verbunden bin. Mache ich einen Hotspot am Handy auf funktioniert alles. Und das auch wenn ich wieder aufs normale DSL schalte.
Sieht wie folgt aus:
Wenn ich das Netzlaufwerk im Arbeitsplatz anklicke kommt das der lokale Gerätename bereits verwendet wird. Über den Hotspot jedoch kann man es normal öffnen.
Nutze ich einen UNC Pfad zum öffnen der Freigabe wird nach Benutzer und Passwort gefragt und dann geschrieben das man keine Berechtigung hat und mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource von demselben Benutzer unter Verwendung mehrerer Benutzernamen sind nicht zulässig. Trennen Sie alle früheren Verbindungen zu dem Server bzw. der freigegebenen Ressource, und versuchen Sie es erneut. Auch das nur mit DSL aber nicht mit dem Hotspot.
Mittels IP Adresse anstatt Rechnername ist es das selbe. Netzlaufwerk habe ich bereits gelöscht.
Wie gesagt das Problem besteht nur über das DSL. Über den Hotspot am Handy läuft es wie immer. Und wenn man den Hotspot ausschaltet und sich wieder mit dem DSL verbindet funktioniert alles normal weiter. Bis zum nächsten Neustart. Es sind zwei W10ProfX64 Rechner mit aktuellem Stand.
Jemand eine Idee dazu?
Etwas kurioses Problem.
Habe zwei Standorte. An dem einen eine Fritzbox 7590 mit Vodafone DSL 16 Mbit. Dort läuft der OpenVPN Server. An dem anderen eine Fritzbox 7530 mit 1&1 DSL 50 Mbit. Dort der OpenVPN Client. Bis zum Wochenende lief alles einwandfrei bis jemand dachte es ist gut, da das Internet gesponnen hat, die FB7590 komplett zurück zu setzen.
Nun habe ich heute die FB wieder eingerichtet mit anderen IP Nummernkreis, DynDNS, Portfreigabe, WLAN etc.
Seit dem spinnt jedoch die Freigabe auf dem Server. Und zwar nur wenn ich mit dem DSL verbunden bin. Mache ich einen Hotspot am Handy auf funktioniert alles. Und das auch wenn ich wieder aufs normale DSL schalte.
Sieht wie folgt aus:
Wenn ich das Netzlaufwerk im Arbeitsplatz anklicke kommt das der lokale Gerätename bereits verwendet wird. Über den Hotspot jedoch kann man es normal öffnen.
Nutze ich einen UNC Pfad zum öffnen der Freigabe wird nach Benutzer und Passwort gefragt und dann geschrieben das man keine Berechtigung hat und mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource von demselben Benutzer unter Verwendung mehrerer Benutzernamen sind nicht zulässig. Trennen Sie alle früheren Verbindungen zu dem Server bzw. der freigegebenen Ressource, und versuchen Sie es erneut. Auch das nur mit DSL aber nicht mit dem Hotspot.
Mittels IP Adresse anstatt Rechnername ist es das selbe. Netzlaufwerk habe ich bereits gelöscht.
Wie gesagt das Problem besteht nur über das DSL. Über den Hotspot am Handy läuft es wie immer. Und wenn man den Hotspot ausschaltet und sich wieder mit dem DSL verbindet funktioniert alles normal weiter. Bis zum nächsten Neustart. Es sind zwei W10ProfX64 Rechner mit aktuellem Stand.
Jemand eine Idee dazu?
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: 665437
Url: https://administrator.de/contentid/665437
Ausgedruckt am: 24.11.2024 um 14:11 Uhr
20 Kommentare
Neuester Kommentar
Die statischen IP Routen in den beiden FBs hast du auch wieder eingerichtet ??
Siehe dazu auch die Details im hiesigen OpenVPN Standort VPN Beispiel:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Grundlagen dazu (auch zu den statischen Routen auf der FB), wie immer, HIER.
Siehe dazu auch die Details im hiesigen OpenVPN Standort VPN Beispiel:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Grundlagen dazu (auch zu den statischen Routen auf der FB), wie immer, HIER.
Habe ich nie eingetragen. Auch nicht bei meinen anderen OpenVPN Installationen. Hat immer funktioniert wie es sollte. Ging auch wie gesagt vor dem Wochenende ohne Probleme. Die FB hatte ich erst vor vier Wochen neu dort verbaut. Und mit dem Hotspot funktioniert es ja auch. Ist also eher unwahrscheinlich das es daran liegt.
Das wäre dann technisch unmöglich wenn du externe OpenVPN Server bzw. Client betreibst die nicht auf den jeweiligen Routern integriert sind.
Ein OpenVPN Server ist ja quasi ein Router über den einzig und allein das remote IP Netz erreichbar ist. Wenn alle Endgeräte im netz aber die FritzBox als Default Gateway eingetragen haben, die aber selber keine statische Route die ihr sagt das remote Netz erreichst du über den VPN Server routet sie es zum Internet Provider und damit dann ins Nirwana. Wenn du uns hier weismachen willst das sowas auch ohne diese Route geht kann man das nur so sehen das du jedem Admin versuchst hier einen Bären aufzubinden.
Da die FritzBoxen kein OpenVPN supporten MUSS es ja zwangsweise mit externen Geräten im LAN realisiert sein und das erzwingt in jedem Falle statische Routen auf den jeweiligen FritzBoxen. Ohne diese Routen wäre eine Standort Kopplung technisch schlicht unmöglich.
Ausnahmen wären einzig nur:
Ein OpenVPN Server ist ja quasi ein Router über den einzig und allein das remote IP Netz erreichbar ist. Wenn alle Endgeräte im netz aber die FritzBox als Default Gateway eingetragen haben, die aber selber keine statische Route die ihr sagt das remote Netz erreichst du über den VPN Server routet sie es zum Internet Provider und damit dann ins Nirwana. Wenn du uns hier weismachen willst das sowas auch ohne diese Route geht kann man das nur so sehen das du jedem Admin versuchst hier einen Bären aufzubinden.
Da die FritzBoxen kein OpenVPN supporten MUSS es ja zwangsweise mit externen Geräten im LAN realisiert sein und das erzwingt in jedem Falle statische Routen auf den jeweiligen FritzBoxen. Ohne diese Routen wäre eine Standort Kopplung technisch schlicht unmöglich.
Ausnahmen wären einzig nur:
- Alle Enderäte im Netz haben statt der FB den OpenVPN Server als Default Gateway eingetragen (falsches IP Design)
- Alle Enderäte im Netz haben händisch eine statische Route ins remote Netz konfiguriert (...was netztechnisches Neandertal ist)
- Du verwechselst IPsec VPN mit OpenVPN und nutzt die FritzBox eigen onboard VPN Funktion.
- Du verar... uns hier allesamt und erzählst uns VPN Märchen mit Wunderrouten
Glaub du meinst etwas anderes. Habe noch nie beim OpenVPN irgend ne Route im Router eingetragen. Steht auch in keiner Anleitung. Port eintragen und fertig. Denke eher die routen werden auf den jeweiligen Rechnern beim starten des Servers hinterlegt. Zumindest startet, was man im log sieht, eine entsprechende exe. IPs gibt's mittels virtueller Netzwerkschnittstelle ja im selben Kreis für beide Rechner ebenfalls. Kenne mich damit aber nicht wirklich aus. Weiß nur das es immer funktionierte. Ohne Routen auf den Routern. Quasi so wie in den 0815 Anleitungen die überall zu finden sind. Hab's aber jetzt auch hinbekommen. Genau so kurios wie das Problem selbst. Habe auf den VPN Server zwei aktive Verbindungen gekappt. Läuft nun wieder wie es soll.
PS. Wenn du möchtest kannst du dich gerne morgen bei mir per Teamviewer verbinden und schauen das es ohne weiteres einwandfrei läuft.
PS. Wenn du möchtest kannst du dich gerne morgen bei mir per Teamviewer verbinden und schauen das es ohne weiteres einwandfrei läuft.
Die Frage ist ja: Welche IP-Adressen haben deine FritzBoxen und welche IP-Adressen werden per OpenVPN vergeben?
Richtig ! Vermutlich hat der TO eine völlig falsche IP Adressierung gemacht. Eins ist auf alle Fälle Fakt, das es ohne eine statische Route auf den jeweiligen Internet Routern niemals klappen kann in einem gerouteten OpenVPN Konzept. Wie auch ?
Eine Option fehlte oben allerdings noch...
Möglich das der TO mit einem gruseligen Layer 2 Bridging und gleichen lokalen LAN IP Adressen auf beiden Seiten arbeitet ?! Das wäre dann eine plausible Erklärung warum es ohne Routing geht.
Ein sehr krankes und kontraproduktives Konzept weil das Bridging durch die Broad- und Multicast Last beider IP Netze das VPN unnötig belastet und die VPN Performance damit auf Grasnarbeniveau geht. Sogar OpenVPN selber rät dringend von Bridging ab.
Bleibt also nur die Option das der TO hier ein übles Layer 2 Bridging macht zwischen den beiden Locations. Das erklärt dann die fehlenden statischen Routen.
So oder so dann ein dringender Grund das OpenVPN Konzept auf sinvolles Routing umzustellen.
Eine Option fehlte oben allerdings noch...
Möglich das der TO mit einem gruseligen Layer 2 Bridging und gleichen lokalen LAN IP Adressen auf beiden Seiten arbeitet ?! Das wäre dann eine plausible Erklärung warum es ohne Routing geht.
Ein sehr krankes und kontraproduktives Konzept weil das Bridging durch die Broad- und Multicast Last beider IP Netze das VPN unnötig belastet und die VPN Performance damit auf Grasnarbeniveau geht. Sogar OpenVPN selber rät dringend von Bridging ab.
Bleibt also nur die Option das der TO hier ein übles Layer 2 Bridging macht zwischen den beiden Locations. Das erklärt dann die fehlenden statischen Routen.
So oder so dann ein dringender Grund das OpenVPN Konzept auf sinvolles Routing umzustellen.
Gut möglich. Habe mich da nie groß drum gekümmert da es so läuft wie es gebraucht wird. Mache es so wie ich es einst in folgender Anleitung gefunden habe. Klagen gibts keine. Daher auch völlig ausreichend.
https://www.pcwelt.de/ratgeber/OpenVPN-mit-Windows-4984324.html
Was mich aber gerade mehr irritiert ist das man in einem anspruchsvollem Forum hier direkt als Lügner bezeichnet wird weil scheinbar der eigene Wissensstand zu niedrig ist, dieser aber ohne wenn und aber durchgesetzt werden will. Zumal ich höflich meinen Text zitiert habe und darauf bezogen freundlich drauf hingewiesen habe das der Lösungsvorschlag zum Problem keinen Sinn ergibt da es schon immer so lief und aktuell gestern auch über den Hotspot vom Handy funktionierte. Sehr schade.
https://www.pcwelt.de/ratgeber/OpenVPN-mit-Windows-4984324.html
Was mich aber gerade mehr irritiert ist das man in einem anspruchsvollem Forum hier direkt als Lügner bezeichnet wird weil scheinbar der eigene Wissensstand zu niedrig ist, dieser aber ohne wenn und aber durchgesetzt werden will. Zumal ich höflich meinen Text zitiert habe und darauf bezogen freundlich drauf hingewiesen habe das der Lösungsvorschlag zum Problem keinen Sinn ergibt da es schon immer so lief und aktuell gestern auch über den Hotspot vom Handy funktionierte. Sehr schade.
Das beantwortet noch nicht die Frage, welche internen IP-Adressen die FritzBoxen haben 
Denn das ist ja etwas, was du nach deiner Aussage an einer Seite geändert hast.
Und das ist jetzt der Punkt, der interessant und eventuell sogar die Ursache ist.
Also:
Welche IP-Adresse hat die FritzBox an Standort A im LAN?
Welche IP hat Box B?
Welche IP hat dein VPN-Client bekommen?
Auf welche IP greifst du durch den Tunnel zu?
Denn das ist ja etwas, was du nach deiner Aussage an einer Seite geändert hast.
Und das ist jetzt der Punkt, der interessant und eventuell sogar die Ursache ist.
Also:
Welche IP-Adresse hat die FritzBox an Standort A im LAN?
Welche IP hat Box B?
Welche IP hat dein VPN-Client bekommen?
Auf welche IP greifst du durch den Tunnel zu?
Danke LordGurke aber lass gut sein. Unterschiedliche IP Adresskreise waren wie davor gesetzt. Das VPN funktionierte ja nach wie vor. Anpingen der Rechnernamen etc alles möglich und Server wie Client grüner Status. Das war auch NIE meine Frage. Die Frage ging allein um die Netzwerkfreigabe wo es trotz korrekter Zugangsdaten keine Berechtigung bekam wie ich schrieb. Kurios dabei immer noch das es über den Handyhotspot ging. Via DSL vom Router nicht. Konnte mir wie gesagt selber helfen und nun geht es wieder. Mich hat die Meldung die ich hier postete mit den mehrfachen Verbindungen stutzig gemacht worauf hin ich beim Server die Sitzungen einfach trennte. Darauf funktionierten die Freigaben wieder wie gewohnt übers DSL. Aber das schrieb ich ja bereits alles. VG Maddoc
Belassen wir es dabei. Der TO hat ein Wunder VPN wie im IP Märchen.
Das es mit unterschiedlichen IP Netzen ohne Routing geht ist technisch vollkommen unmöglich. Mit einer einzigen Ausnahme unter Millionen...die beim TO. Aber egal...muss man ja nicht verstehen.
Sehr spannend wäre ja zum Schluss nochmal ein tracert -d <remote_FB-lan_ip> welche wundersamen Wege die IP Pakete des TOs gehen in seinem VPN.
Wundernetze zu troubleshooten erfordern aber einen (dunklen) Lord und keinen Netzwerk Admin !
Case closed...
Das es mit unterschiedlichen IP Netzen ohne Routing geht ist technisch vollkommen unmöglich. Mit einer einzigen Ausnahme unter Millionen...die beim TO. Aber egal...muss man ja nicht verstehen.
Sehr spannend wäre ja zum Schluss nochmal ein tracert -d <remote_FB-lan_ip> welche wundersamen Wege die IP Pakete des TOs gehen in seinem VPN.
Wundernetze zu troubleshooten erfordern aber einen (dunklen) Lord und keinen Netzwerk Admin !
Case closed...
Au weia. Lass gut sein. Entfernt deines Wissens funktioniert alles.
Ich möchte das Thema gern noch einmal aufgreifen. In zweifacher Hinsicht.
In zwischenmenschlicher Hinsicht kurz vorab. Die fachliche Kompetenz von @aqui im Netzwerkbereich ist herausragend und eine Zierde für dieses (jedes) Forum. Ich bedanke mich - auch hier und jetzt - für jeden seiner Beiträge. Praktisch jede technisch orientierte Zeile ist lesenswert. Wenn also @aqui etwas in fachlicher Hinsicht sagt, gibt es wenig in Frage zu stellen.
Ich verstehe auch, dass große fachliche Kompetenz zuweilen dazu führt, dass einen die Probleme/Ansichten des weniger kompetenten "Volkes" nerven, z.B. wenn sogenannte Administratoren DHCP mit AD verwechseln oder denken, Wireshark ist ein Tier aus dem Aquarium. In diesem Fall bleibt die Möglichkeit, sich rauszuhalten. Was leider auch bei dem Kollegen @aqui (selten, aber zunehmend (?)) anzutreffen ist, ist herablassendes, fast schon beleidigendes Abkanzeln auch ernstzunehmender und sorgfältig formulierter Anfragen. Klar, jeder hat mal einen schlechten Tag und nicht jeder Beitrag ist ein stilistisches Meisterwerk. Gerade dieser Thread zeigt aber ganz gut, was ich meine:
Kollege @maddoc hat sein Problem nachvollziehbar dargelegt und sogar selbst gelöst. Er wurde im Verlauf auf einem Nebengleis angegangen und blieb dennoch bemerkenswert ruhig und höflich. Dessen ungeachtet wird er mit zunehmend stärkerem Vokabular als Lügner oder Schwachkopf behandelt, z.B. "Du verar... uns hier allesamt und erzählst uns VPN Märchen mit Wunderrouten" oder "Mit einer einzigen Ausnahme unter Millionen...die beim TO. Aber egal...muss man ja nicht verstehen." statt sich mal ernsthaft mit der Aussage auseinander zu setzen, dass er als TO angibt, nach Standard-Anleitungen (belegt) vorgegangen zu sein, dass dies seit Jahren funktioniere und zig dieser Anleitungen im Netz existieren. Am Rande: Ich betreibe auch mehrere dieser "Wunder-VPNs", die vielleicht gar nicht so wundersam sind (dazu gleich im technischen Teil).
Ich wünsche mir mehr Kollegen, wie @maddoc, die ihr Problem hier darlegen und zum Nutzen anderer ihre selbst gefundene Lösung offen legen und die trotz der hier nicht selten erfolgenden Schienbeintritte einiger Kollegen sachlich bleiben. Meist sind es natürlich nicht die kompetenten Kollegen, die die schrägen Vibes reinbringen, oftmals wurde auch nur nicht richtig gelesen (häufige IT'ler-Krankheit) und/oder es gibt Missverständnisse. Wenn die eigentlich kompetenten Kollegen anfangen, einen Fragesteller zu dissen, ist das viel schwer wiegender - und gerade für den sachlichen Fragesteller alles andere als ermutigend. Also bitte den schlechten Tag einfach mal außen vor lassen und nett bleiben oder die Klappe halten. Überheblichkeit nimmt der Kompetenz ihre Würde.
Als positives Vorbild möchte ich in diesem Thread den Kollegen @LordGurke nennen, der sich - trotz hervorragender Kompetenzen im VOIP-Bereich - stets sachbezogen einbringt und immer im Bereich sozialkompetenter Grenzen bleibt, auch hier, obgleich er die Darstelltung des TO ebenfalls deutlich anzweifelt.
Man kann sich menschlich eben so oder so darstellen. Jeder hat es in der Hand. Schöner ist es für alle, wenn es nett bleibt.
In zwischenmenschlicher Hinsicht kurz vorab. Die fachliche Kompetenz von @aqui im Netzwerkbereich ist herausragend und eine Zierde für dieses (jedes) Forum. Ich bedanke mich - auch hier und jetzt - für jeden seiner Beiträge. Praktisch jede technisch orientierte Zeile ist lesenswert. Wenn also @aqui etwas in fachlicher Hinsicht sagt, gibt es wenig in Frage zu stellen.
Ich verstehe auch, dass große fachliche Kompetenz zuweilen dazu führt, dass einen die Probleme/Ansichten des weniger kompetenten "Volkes" nerven, z.B. wenn sogenannte Administratoren DHCP mit AD verwechseln oder denken, Wireshark ist ein Tier aus dem Aquarium. In diesem Fall bleibt die Möglichkeit, sich rauszuhalten. Was leider auch bei dem Kollegen @aqui (selten, aber zunehmend (?)) anzutreffen ist, ist herablassendes, fast schon beleidigendes Abkanzeln auch ernstzunehmender und sorgfältig formulierter Anfragen. Klar, jeder hat mal einen schlechten Tag und nicht jeder Beitrag ist ein stilistisches Meisterwerk. Gerade dieser Thread zeigt aber ganz gut, was ich meine:
Kollege @maddoc hat sein Problem nachvollziehbar dargelegt und sogar selbst gelöst. Er wurde im Verlauf auf einem Nebengleis angegangen und blieb dennoch bemerkenswert ruhig und höflich. Dessen ungeachtet wird er mit zunehmend stärkerem Vokabular als Lügner oder Schwachkopf behandelt, z.B. "Du verar... uns hier allesamt und erzählst uns VPN Märchen mit Wunderrouten" oder "Mit einer einzigen Ausnahme unter Millionen...die beim TO. Aber egal...muss man ja nicht verstehen." statt sich mal ernsthaft mit der Aussage auseinander zu setzen, dass er als TO angibt, nach Standard-Anleitungen (belegt) vorgegangen zu sein, dass dies seit Jahren funktioniere und zig dieser Anleitungen im Netz existieren. Am Rande: Ich betreibe auch mehrere dieser "Wunder-VPNs", die vielleicht gar nicht so wundersam sind (dazu gleich im technischen Teil).
Ich wünsche mir mehr Kollegen, wie @maddoc, die ihr Problem hier darlegen und zum Nutzen anderer ihre selbst gefundene Lösung offen legen und die trotz der hier nicht selten erfolgenden Schienbeintritte einiger Kollegen sachlich bleiben. Meist sind es natürlich nicht die kompetenten Kollegen, die die schrägen Vibes reinbringen, oftmals wurde auch nur nicht richtig gelesen (häufige IT'ler-Krankheit) und/oder es gibt Missverständnisse. Wenn die eigentlich kompetenten Kollegen anfangen, einen Fragesteller zu dissen, ist das viel schwer wiegender - und gerade für den sachlichen Fragesteller alles andere als ermutigend. Also bitte den schlechten Tag einfach mal außen vor lassen und nett bleiben oder die Klappe halten. Überheblichkeit nimmt der Kompetenz ihre Würde.
Als positives Vorbild möchte ich in diesem Thread den Kollegen @LordGurke nennen, der sich - trotz hervorragender Kompetenzen im VOIP-Bereich - stets sachbezogen einbringt und immer im Bereich sozialkompetenter Grenzen bleibt, auch hier, obgleich er die Darstelltung des TO ebenfalls deutlich anzweifelt.
Man kann sich menschlich eben so oder so darstellen. Jeder hat es in der Hand. Schöner ist es für alle, wenn es nett bleibt.
In technischer Hinsicht folgendes:
Ich habe mich anfangs gefragt, ob Ihr aneinander vorbei redet und @aqui das Site-to-Site-VPN meint, das Routing erfordert und @maddoc ein Client-to-Site-VPN einsetzt, wie ich das z.B. auch im Support gern mache. Ich habe schon vor vielen Jahren, damals noch völlig ahnungslos, Anleitungen zu OpenVPN "abgearbeitet" (ähnlich dieser oder dieser und nie eine statische Route im Router eingetragen. Vielleicht war/ist das total falsch, es ist aber das, was @maddoc beschreibt: Inhalt vieler im Netz verfügbarer Anleitungen. Mittlerweile verstehe ich vielleicht ein klein Wenig mehr. Und wenn @aqui schreibt, statisches Routing ist technisch notwendig, nehme ich das ernst. Also versuche ich, es nachzuvollziehen:
Konkret ereiche ich mit einem OpenVPN nach so einer Standard-Anleitung ohne statische Route jeden Computer im Netzwerk des OpenVPN-(Gateway-)Servers. Ich kann dort RDP, VNC, Http, SSH, was auch immer ansprechen, der angesprochene Computer antwortet. Ich kann auf ihm arbeiten, als ob ich vor Ort wäre. Wie kann das also ohne statische Route im Zielnetzwerk gehen? Eigentlich nicht. Woher weiß der Zielcomputer ohne diese, wohin er das Paket an den Client zurück senden soll?
Auch von OpenVPN veröffentlichte Hinweisegehen davon aus, dass die statische Route auf das Client-Netzwerk zum VPN-Gateway gesetzt wird. Dennoch geht es ohne. Lieber @aqui, ich bin mir sicher, Du kannst das erklären/aufklären. Ich persönlich vermute, dass bei der gewählten Konstellation das Standard-Gateway des Zielnetzes gar keine Rolle spielt (anders beim Site-to-Site-VPN):
Der VPN-Client (IP 192.168.10.X) verbindet sich auf den OpenVPN-Server (IP 192.168.20.X) und bekommt von diesem z.B. die IP 10.8.0.6 zugewiesen. Die Anfrage vom Client kommt also von 10.8.0.6 an den OpenVPN-Server. Wenn sie sich an einen Rechner im Netz des OpenVPN-Servers, also z.B. an 192.168.20.50 richtet, fungiert der OpenVPN-Server als Gateway und routet 10.8.0.6 auf 192.168.20.50. Ist das soweit richtig? Wenn ja, wie kommt das Paket dann von 192.168.20.50 zurück zu 10.8.0.6 (bzw. 192.168.10.x)?
Kann es sein, dass der OpenVPN-Server hier NAT verwendet und sich gegenüber 192.168.20.50 als Empfänger der Pakete (für 10.8.0.6) mit seiner IP 192.168.20.x ausweist und dann das Paket selbst zurück routet? Dies wäre mein Erklärungsansatz - und siehe da, kurz gegoogelt:
"NAT is used in Internet gateway routers but also internally in the OpenVPN Access Server" https://openvpn.net/vpn-server-resources/some-basic-networking-concepts- ... scheint das zu bestätigen. Ist es so? Dann wäre immerhin das Wunder entzaubert und ich hätte etwas mehr vom Networking verstanden. Wenn nicht, fänd ich es super, wenn es mir erklärt werden würde - ganz ohne mich runterzumachen, wenn möglich.
Wenn ich in etwa richtig liege bleibt aber noch die Frage, warum selbst die OpenVPN-Anleitung vom erforderlichen statischen Routing ausgeht, z.B. hier (letzter Satz): https://openvpn.net/community-resources/setting-up-routing/
Allgemein zum Verständnis fand ich die Ausführungen und Bilder auf https://openvpn.net/vpn-server-resources/site-to-site-routing-explained- ... sehr hilfreich. Es geht zwar um Site-to-Site-VPN, aber die grundsätzliche Beschreibung des Paketweges vom Client zum Zielcomputer (Bilder) gilt auch für das Client-to-Client-VPN und macht das Ganze sehr schön transparent.
Ganz lieben Gruß an alle Beteiligten. Peace!
Ich habe mich anfangs gefragt, ob Ihr aneinander vorbei redet und @aqui das Site-to-Site-VPN meint, das Routing erfordert und @maddoc ein Client-to-Site-VPN einsetzt, wie ich das z.B. auch im Support gern mache. Ich habe schon vor vielen Jahren, damals noch völlig ahnungslos, Anleitungen zu OpenVPN "abgearbeitet" (ähnlich dieser oder dieser und nie eine statische Route im Router eingetragen. Vielleicht war/ist das total falsch, es ist aber das, was @maddoc beschreibt: Inhalt vieler im Netz verfügbarer Anleitungen. Mittlerweile verstehe ich vielleicht ein klein Wenig mehr. Und wenn @aqui schreibt, statisches Routing ist technisch notwendig, nehme ich das ernst. Also versuche ich, es nachzuvollziehen:
Konkret ereiche ich mit einem OpenVPN nach so einer Standard-Anleitung ohne statische Route jeden Computer im Netzwerk des OpenVPN-(Gateway-)Servers. Ich kann dort RDP, VNC, Http, SSH, was auch immer ansprechen, der angesprochene Computer antwortet. Ich kann auf ihm arbeiten, als ob ich vor Ort wäre. Wie kann das also ohne statische Route im Zielnetzwerk gehen? Eigentlich nicht. Woher weiß der Zielcomputer ohne diese, wohin er das Paket an den Client zurück senden soll?
Auch von OpenVPN veröffentlichte Hinweisegehen davon aus, dass die statische Route auf das Client-Netzwerk zum VPN-Gateway gesetzt wird. Dennoch geht es ohne. Lieber @aqui, ich bin mir sicher, Du kannst das erklären/aufklären. Ich persönlich vermute, dass bei der gewählten Konstellation das Standard-Gateway des Zielnetzes gar keine Rolle spielt (anders beim Site-to-Site-VPN):
Der VPN-Client (IP 192.168.10.X) verbindet sich auf den OpenVPN-Server (IP 192.168.20.X) und bekommt von diesem z.B. die IP 10.8.0.6 zugewiesen. Die Anfrage vom Client kommt also von 10.8.0.6 an den OpenVPN-Server. Wenn sie sich an einen Rechner im Netz des OpenVPN-Servers, also z.B. an 192.168.20.50 richtet, fungiert der OpenVPN-Server als Gateway und routet 10.8.0.6 auf 192.168.20.50. Ist das soweit richtig? Wenn ja, wie kommt das Paket dann von 192.168.20.50 zurück zu 10.8.0.6 (bzw. 192.168.10.x)?
Kann es sein, dass der OpenVPN-Server hier NAT verwendet und sich gegenüber 192.168.20.50 als Empfänger der Pakete (für 10.8.0.6) mit seiner IP 192.168.20.x ausweist und dann das Paket selbst zurück routet? Dies wäre mein Erklärungsansatz - und siehe da, kurz gegoogelt:
"NAT is used in Internet gateway routers but also internally in the OpenVPN Access Server" https://openvpn.net/vpn-server-resources/some-basic-networking-concepts- ... scheint das zu bestätigen. Ist es so? Dann wäre immerhin das Wunder entzaubert und ich hätte etwas mehr vom Networking verstanden. Wenn nicht, fänd ich es super, wenn es mir erklärt werden würde - ganz ohne mich runterzumachen, wenn möglich.
Wenn ich in etwa richtig liege bleibt aber noch die Frage, warum selbst die OpenVPN-Anleitung vom erforderlichen statischen Routing ausgeht, z.B. hier (letzter Satz): https://openvpn.net/community-resources/setting-up-routing/
Allgemein zum Verständnis fand ich die Ausführungen und Bilder auf https://openvpn.net/vpn-server-resources/site-to-site-routing-explained- ... sehr hilfreich. Es geht zwar um Site-to-Site-VPN, aber die grundsätzliche Beschreibung des Paketweges vom Client zum Zielcomputer (Bilder) gilt auch für das Client-to-Client-VPN und macht das Ganze sehr schön transparent.
Ganz lieben Gruß an alle Beteiligten. Peace!
Du hast natürlich Recht.
Wenn der TO nur rein einen OpenVPN Client Login macht und mit dem VPN Client rein nur auf dem Server arbeitet der gleichzeitig auch OpenVPN Server ist, dann braucht es in der Tat kein Routing, das ist natürlich richtig.
Er kann dann vom Client einzig nur den Server erreichen aber keinerlei weitere Endgeräte im Server LAN wie NAS, Drucker usw. oder das Konfig GUI der FritzBox. Wenn er rein nur den Server braucht ist dem so, obwohl auf der OVPN Server Seite besser immer eine statische Route in das interne OpenVPN IP Netz auf dem Router konfiguriert sein sollte aber egal, vom Prinzip hast du Recht. Das mag (vermutlich) das OVPN Setup des TOs sein und das Routing freie Setup dann erklären.
Leider hat das der TO aber nicht explizit so erklärt und aus seiner Beschreibung mit den 2 FritzBoxen interpretiert jeder Netzwerker eine Site to Site Kopplung die immer Routing erzwingt. Auch sehr Grundlegendes wie z.B. nur einmal seine OVPN Server und Client Konfig fehlte was ein zielführendes Troubleshooting erleichtert hätte. An all solchen Standards hat es gehapert.
Aber so kanns gehen wenn auch trotz Nachfrage keine explizite Erklärung des Designs und Setups kommt. In einem Forum wo man nicht direkt kommunizieren kann ist das eben schwer Sachverhalte richtig rüberzubringen. Ein Indiz mehr wie wichtig eine klare und technisch einwandfreie verständliche Schilderung des Problems hier ist.
In sofern danke für den Hinweis der das "Wunder" dann letzlich wohl nun geklärt hat. 😉
Wenn der TO nur rein einen OpenVPN Client Login macht und mit dem VPN Client rein nur auf dem Server arbeitet der gleichzeitig auch OpenVPN Server ist, dann braucht es in der Tat kein Routing, das ist natürlich richtig.
Er kann dann vom Client einzig nur den Server erreichen aber keinerlei weitere Endgeräte im Server LAN wie NAS, Drucker usw. oder das Konfig GUI der FritzBox. Wenn er rein nur den Server braucht ist dem so, obwohl auf der OVPN Server Seite besser immer eine statische Route in das interne OpenVPN IP Netz auf dem Router konfiguriert sein sollte aber egal, vom Prinzip hast du Recht. Das mag (vermutlich) das OVPN Setup des TOs sein und das Routing freie Setup dann erklären.
Leider hat das der TO aber nicht explizit so erklärt und aus seiner Beschreibung mit den 2 FritzBoxen interpretiert jeder Netzwerker eine Site to Site Kopplung die immer Routing erzwingt. Auch sehr Grundlegendes wie z.B. nur einmal seine OVPN Server und Client Konfig fehlte was ein zielführendes Troubleshooting erleichtert hätte. An all solchen Standards hat es gehapert.
Aber so kanns gehen wenn auch trotz Nachfrage keine explizite Erklärung des Designs und Setups kommt. In einem Forum wo man nicht direkt kommunizieren kann ist das eben schwer Sachverhalte richtig rüberzubringen. Ein Indiz mehr wie wichtig eine klare und technisch einwandfreie verständliche Schilderung des Problems hier ist.
In sofern danke für den Hinweis der das "Wunder" dann letzlich wohl nun geklärt hat. 😉
Danke für die Rückmeldung 
Das Wunder ist mit Deiner Darstellung noch nicht ganz entzaubert, denn, das habe ich auch geschrieben: Deine folgende Annahme ist unzutreffend:
Ich erreiche mit der oben beschriebenen Konstellation von meinem Client (192.168.10.X) ohne jegliche statische Route den OpenVPN-Server, aber auch die GUI der Fritzbox und auch alle anderen Rechner im Netzwerk (192.168.20.X) mit den beschriebenen Protokollen (SSH, RDP, VNC) und natürlich auch den OpenVPN-Server. Das kann ich mir nur mit einem NAT seitens des OpenVPN-Servers erklären, der dann für die Verbindung als Gateway fungiert.
Tracert hatte ich bei dem vielen Text vergessen nachzureichen:
VPN-Client (192.168.10.100) auf PC im OpenVPN-Server-Netzwerk (192.168.20.50):
Routenverfolgung zu 192.168.20.50 über maximal 30 Hops
1 44 ms 43 ms 43 ms 10.8.0.1
2 43 ms 43 ms 43 ms 192.168.20.50
unspektakulär, hop 1 ist der OpenVPN-Server, hop 2 die Zieladresse.
Klarer wird es m.E., wenn der Zielhost nicht antwortet (hier die Fritzbox 192.168.20.254):
VPN-Client (192.168.10.100) auf Fritzbox im OpenVPN-Server-Netzwerk (192.168.20.254):
Routenverfolgung zu 192.168.20.254 über maximal 30 Hops
1 43 ms 43 ms 43 ms 10.8.0.1
2 192.168.20.11 meldet: Zielhost nicht erreichbar.
192.168.20.11 ist (ebenso wie 10.8.0.1) der OpenVPN-Server. Damit ist für mich klar, dass dieser mit der 192.168.20.254 über seine Netzwerkadresse 192.168.20.11 Kontakt aufzunehmen versucht. Die Rückinformation kann dann aber bis zu mir nur über das 10.8.0.0-Netz kommen, mithin erfolgt ein NAT.
Oder?
Das Wunder ist mit Deiner Darstellung noch nicht ganz entzaubert, denn, das habe ich auch geschrieben: Deine folgende Annahme ist unzutreffend:
Zitat von @aqui:
... Er kann dann vom Client einzig nur den Server erreichen aber keinerlei weitere Endgeräte im Server LAN wie NAS, Drucker usw. oder das Konfig GUI der FritzBox.
... Er kann dann vom Client einzig nur den Server erreichen aber keinerlei weitere Endgeräte im Server LAN wie NAS, Drucker usw. oder das Konfig GUI der FritzBox.
Ich erreiche mit der oben beschriebenen Konstellation von meinem Client (192.168.10.X) ohne jegliche statische Route den OpenVPN-Server, aber auch die GUI der Fritzbox und auch alle anderen Rechner im Netzwerk (192.168.20.X) mit den beschriebenen Protokollen (SSH, RDP, VNC) und natürlich auch den OpenVPN-Server. Das kann ich mir nur mit einem NAT seitens des OpenVPN-Servers erklären, der dann für die Verbindung als Gateway fungiert.
Tracert hatte ich bei dem vielen Text vergessen nachzureichen:
VPN-Client (192.168.10.100) auf PC im OpenVPN-Server-Netzwerk (192.168.20.50):
Routenverfolgung zu 192.168.20.50 über maximal 30 Hops
1 44 ms 43 ms 43 ms 10.8.0.1
2 43 ms 43 ms 43 ms 192.168.20.50
unspektakulär, hop 1 ist der OpenVPN-Server, hop 2 die Zieladresse.
Klarer wird es m.E., wenn der Zielhost nicht antwortet (hier die Fritzbox 192.168.20.254):
VPN-Client (192.168.10.100) auf Fritzbox im OpenVPN-Server-Netzwerk (192.168.20.254):
Routenverfolgung zu 192.168.20.254 über maximal 30 Hops
1 43 ms 43 ms 43 ms 10.8.0.1
2 192.168.20.11 meldet: Zielhost nicht erreichbar.
192.168.20.11 ist (ebenso wie 10.8.0.1) der OpenVPN-Server. Damit ist für mich klar, dass dieser mit der 192.168.20.254 über seine Netzwerkadresse 192.168.20.11 Kontakt aufzunehmen versucht. Die Rückinformation kann dann aber bis zu mir nur über das 10.8.0.0-Netz kommen, mithin erfolgt ein NAT.
Oder?
ohne jegliche statische Route den OpenVPN-Server, aber auch die GUI der Fritzbox
Das liegt daran das du fälschlicherweise NAT im Server machst. Dadurch setzt der Server das interne OpenVPN IP Netz (was der Client als Absender Adresse nutzt) auf seine lokale LAN IP um. Die FritzBox "denkt" dann das der Absender aus dem lokalen LAN kommt und sieht durch das NAT nicht das es eine andere Absender IP hat.Der große Nachteil ist das damit die Kommunikation einseitig wird da andersrum die NAT Firewall nicht überwunden werden kann.
Es ist deshalb immer kontraproduktiv und auch völlig überflüssig im eigenen internen Netzwerk NAT zu machen.
Leider sind viele OpenVPN Tutorials auf Leute aus die diese gruseligen öffentlichen VPN Dienstleister wie NordVPN u.a. nutzen um Geolocation Blockings usw. zu umgehen. Diese müssen dann NAT nutzen.
Für eine eigene VPN Vernetzung ist sowas deshalb immer unsinnig und überflüssig.
Ich glaube, dann haben wir es ganz gut herausgearbeitet: Der TO und Du habt von verschiedenen Varianten gesprochen.
Halten wir fest:
1. Ein OpenVPN funktioniert vom Client ins Netz des Servers (Zielnetzwerk) durchaus ohne statische Route und kann dort alle weiteren Geräte erreichen. Es handelt sich um kein Wunder-VPN sondern um eine spezifische Konfiguration.
2. Diese Konfiguration nutzt den OpenVPN-Server als NAT-Gateway, so erklärt sich technisch der Verzicht auf eine statische Route im Router des Zielnetzwerks. Realisiert wird das wohl über die Server.conf im Eintrag: push "redirect-gateway def1 bypass-dhcp"
D'accord soweit?
Dann bleibt jetzt noch die Frage, ob da fälschlicherweise NAT genutzt wird. Da teile ich Deine Auffassung nicht. Ich glaube, Du bist da auf gegenseitiges VPN (Site-to-Site) orientiert. Das ist aber gar nicht das Regel-Einsatzszenario. Du meinst, die aus dem NAT-ting folgende "einseitige" Kommunikation ist nachteilig. Ich meine, sie ist bewusst so designed, denn eine zweiseitige Kommunikation sehe ich
- im Homeoffice
- im Supportbetrieb
- im RoadWarrior-Betrieb
- im Medienkonsum-Betrieb (Geolocation)
nicht als sinnvoll oder gar notwendig an.
Im Gegenteil: Ich möchte nicht, dass ein Kunde, zu dem ich mich per VPN verbinde, sich in meinem Netzwerk tummelt. Ebensowenig möchte ich, wenn ich mich von der Arbeit ins Heimnetzwerk verbinde, dass meine Kids dann im Arbeitgebernetzwerk auftauchen....
Site-to-Site ist was für Firmen mit Zweigstellen, überregionalen Abteilungen u.ä. und da absolut sinnvoll oder gar notwendig. Aber für die große Masse der "Klein"Anwender im Homeoffice oder für den Zugriff auf das heimische Netzwerk sollte die Konfiguration aus den einschlägigen Tutorials genau richtig sein. Etwas technisch falsches kann ich da jedenfalls nicht finden.
Entscheidend ist wohl eher, wofür man das VPN nutzt. Möglich ist jedenfalls einiges und immerhin das Wunder ist geklärt
Zum guten Abschluss noch ein aktuelles Konfigurationsbeispiel, dass mir auf den ersten Blick gut gefällt (nicht geprüft), denn es ist gut erklärt und auch das NAT-ting wird dort immerhin erwähnt: ctaas.de/OpenVPN_Server_Ubuntu_howto.htm
Halten wir fest:
1. Ein OpenVPN funktioniert vom Client ins Netz des Servers (Zielnetzwerk) durchaus ohne statische Route und kann dort alle weiteren Geräte erreichen. Es handelt sich um kein Wunder-VPN sondern um eine spezifische Konfiguration.
2. Diese Konfiguration nutzt den OpenVPN-Server als NAT-Gateway, so erklärt sich technisch der Verzicht auf eine statische Route im Router des Zielnetzwerks. Realisiert wird das wohl über die Server.conf im Eintrag: push "redirect-gateway def1 bypass-dhcp"
D'accord soweit?
Dann bleibt jetzt noch die Frage, ob da fälschlicherweise NAT genutzt wird. Da teile ich Deine Auffassung nicht. Ich glaube, Du bist da auf gegenseitiges VPN (Site-to-Site) orientiert. Das ist aber gar nicht das Regel-Einsatzszenario. Du meinst, die aus dem NAT-ting folgende "einseitige" Kommunikation ist nachteilig. Ich meine, sie ist bewusst so designed, denn eine zweiseitige Kommunikation sehe ich
- im Homeoffice
- im Supportbetrieb
- im RoadWarrior-Betrieb
- im Medienkonsum-Betrieb (Geolocation)
nicht als sinnvoll oder gar notwendig an.
Im Gegenteil: Ich möchte nicht, dass ein Kunde, zu dem ich mich per VPN verbinde, sich in meinem Netzwerk tummelt. Ebensowenig möchte ich, wenn ich mich von der Arbeit ins Heimnetzwerk verbinde, dass meine Kids dann im Arbeitgebernetzwerk auftauchen....
Site-to-Site ist was für Firmen mit Zweigstellen, überregionalen Abteilungen u.ä. und da absolut sinnvoll oder gar notwendig. Aber für die große Masse der "Klein"Anwender im Homeoffice oder für den Zugriff auf das heimische Netzwerk sollte die Konfiguration aus den einschlägigen Tutorials genau richtig sein. Etwas technisch falsches kann ich da jedenfalls nicht finden.
Entscheidend ist wohl eher, wofür man das VPN nutzt. Möglich ist jedenfalls einiges und immerhin das Wunder ist geklärt
Zum guten Abschluss noch ein aktuelles Konfigurationsbeispiel, dass mir auf den ersten Blick gut gefällt (nicht geprüft), denn es ist gut erklärt und auch das NAT-ting wird dort immerhin erwähnt: ctaas.de/OpenVPN_Server_Ubuntu_howto.htm
Realisiert wird das wohl über die Server.conf im Eintrag: push "redirect-gateway def1 bypass-dhcp"
Nein, das ist leider komplett falsch.Dieser Eintrag bewirkt am Client einen Default Gateway Redirect. Sprich am Client wird dann bei aktivem Tunnel ALLES ins VPN geroutet. Der Redirect ersetzt dann das lokale Default Gateway mit dem Tunnel Interface.
Im VPN hat man immer 2 Optioen:
- Split Tunneling = Es wird nur Traffic der remoten Netze in den Tunnel geroutet. Resttraffic wird lokal ins Internet geroutet
- Gateway Redirect = Alles wird in den Tunnel geroutet.
Merkzettel: VPN Installation mit OpenVPN
Mit NAT (Adress Translation) hat das nichts zu tun !
Entscheidend ist wohl eher, wofür man das VPN nutzt.
Du hast Recht. Unter den von dir genannten Aspekten kann ein NAT sinnvoll sein. Man muss dann aber immer im Hinterkopf haben das der Zugriff eine reine Einbahnstrasse ist. Also immer nur Client ins remote Netz. Unter deinen o.a. Voraussetzungen ist das ja immer gegeben in so fern ist NAT dann natürlich nicht hinterlich.Ah, korrekt, da hab ich nicht nachgedacht. Das Routing macht der Netzwerk-Stack(?) des OpenVPN-Servers dann selbst, richtig? "redirect-gateway def1..." sorgt nur dafür, dass der Datenstrom eben allein über den Server läuft, hat also nur mittelbar damit zu tun.
Danke, dass Du immer auf so etwas aufpasst! Und dass Du geholfen hast, diesen Thread zu lösen.
Schönes Wochenende. case closed
Das Routing macht der Netzwerk-Stack(?) des OpenVPN-Servers dann selbst, richtig?
Jein.Er macht es nur wenn man das Routing vorher explizit aktiviert. Bitte auch da wieder das OpenVPN Tutorial lesen was das für Winblows und Linux auch wieder im Detail erklärt:
Merkzettel: VPN Installation mit OpenVPN
Im Default ist bei allen Betriebsystemen das Routing (IP Forwarding) immer deaktiviert !
Danke für dein Feedback was den Anstoß gab nochmal genau nachzudenken !! 😉
Case closed !
