NAS -> Internet -> NAS - Mit VPN
- Ersteller MickH74
- Erstellt am
Die Vermutung bestätigt sich leider.
Die OpenVPN-Verbindung zwischen den beiden NAS steht, aber sobald ich ein Backup mache und Daten fließen, friert meine FritzBox ein. Dann lassen sich weder Webseiten aufrufen noch das Interface der FritzBox erreichen. Irgendwann trennt die FritzBox dann die Internetverbindung und wählt sich neu ein, worauf das VPN wieder neu aufgebaut wird und der ganze Prozess von vorne beginnt.
Eine Frage dazu: beim VPN zwischen zwei Fritzboxen müssen die dahinter liegenden Netze unterschiedliche IP-Adressbereiche haben. Ist das bei OpenVPN auch Voraussetzung? Könnte das die Ursache sein?
Nun habe ich versucht, ein VPN direkt zwischen den Fritzboxen zu etablieren. Hab also einen IP-Bereich auf 192.168.1.x gesetzt, während die andere FB im Bereich 192.168.0.x arbeitet. Obwohl - wahrscheinlich noch aufgrund von Konfigurationsfehlern an denen ich gerade arbeite - keine Verbindung zustande kommt, ist meine FritzBox nach einer Weile nicht mehr erreichbar, und trennt die Internetverbindung.
Woran liegt das? Hat jemand einen Tipp?
Danke und Gruß,
Mick
Die OpenVPN-Verbindung zwischen den beiden NAS steht, aber sobald ich ein Backup mache und Daten fließen, friert meine FritzBox ein. Dann lassen sich weder Webseiten aufrufen noch das Interface der FritzBox erreichen. Irgendwann trennt die FritzBox dann die Internetverbindung und wählt sich neu ein, worauf das VPN wieder neu aufgebaut wird und der ganze Prozess von vorne beginnt.
Eine Frage dazu: beim VPN zwischen zwei Fritzboxen müssen die dahinter liegenden Netze unterschiedliche IP-Adressbereiche haben. Ist das bei OpenVPN auch Voraussetzung? Könnte das die Ursache sein?
Nun habe ich versucht, ein VPN direkt zwischen den Fritzboxen zu etablieren. Hab also einen IP-Bereich auf 192.168.1.x gesetzt, während die andere FB im Bereich 192.168.0.x arbeitet. Obwohl - wahrscheinlich noch aufgrund von Konfigurationsfehlern an denen ich gerade arbeite - keine Verbindung zustande kommt, ist meine FritzBox nach einer Weile nicht mehr erreichbar, und trennt die Internetverbindung.
Woran liegt das? Hat jemand einen Tipp?
Danke und Gruß,
Mick
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 18.285
Ja. Sobald bei einer VPN-Verbindung mehrere identische Subnetze beteiligt sind, gibt es Probleme. Deswegen ist es essentiell, bei der Verbindung zweier Netzwerke via VPN die Subnetze eindeutig zu wählen. Bei statischen Verbindungen (zB Wohnung 1 <-> Wohnung 2) könnte man sich theoretisch auf 192.168.0.x bzw. 1.x beschränken, aber insbesondere dann, wenn eine Seite nicht statisch ist - zB wenn man von unterwegs aus dem Hotel, vom Flughafen, beim Kumpel, etc. auf das heimische Netzwerk zugreifen will - ist es äußerst riskant, solche Standard-Subnetze zu verwenden. Generell sollte man bei VPN jedweder Art stets "ungewöhnliche" Subnetze verwenden, um potentiellen Konflikten von vornherein aus dem Weg zu gehen. Schließlich kann es auch sein, dass man zwar Anfangs nur Backups zwischen W1 und W2 hin- und herschieben wollte, aber später eben doch gerne von unterwegs via VPN ins Heimnetzwerk möchte --> Nun rächt es sich unter Umständen, dass man 08/15 Subnetze verwendet hat.MickH74 schrieb:
192.168.0.0 - 192.168.255.255
172.16.0.0 - 172.31.255.255
10.0.0.0 - 10.255.255.255
Das sind die IP-Bereiche, die für private Netzwerke reserviert sind. 99,99999% aller Heimnetzwerke sind auf 192.168.0.x ; 192.168.1.x ; 192.168.2.x ; 192.168.178.x eingestellt, weil das einfach ab Werk schon im Router voreingestellt ist. Nutzt man eines dieser Subnetze in Kombination mit einem VPN, ist es nur eine Frage der Zeit bis man dumm aus der Wäsche guckt, weil der Router in der Ferienwohnung dummerweise auch ne Fritzbox mit Standard-Einstellungen ist.................
Sei kreativ, der Adressbereich ist dermaßen groß, dass es völliger Unsinn ist, sich auf diese 4 Standard-Subnetze zu beschränken. Ich persönlich wähle meine Subnetze zB nach Geburtstagen. 172.23.4.x für den 23.4. zum Beispiel.
Es kann durchaus sein, dass deine Probleme genau daher kommen. Wenn W1 = 192.168.0.x und W2 = 192.168.0.x, dann weiß dein PC nicht mehr ob 192.168.0.1 nun lokal oder hinter dem VPN zu finden ist. Besser gesagt: Standardmäßig wird der PC immer lokal suchen und diese IP-Adresse niemals hinter dem VPN vermuten. Hätte W2 nun 172.23.4.x, dann wäre der dortige Router ja normalerweise die 172.23.4.1 und da ist es für den PC dann klar, dass das nicht lokal ist, da er lokal ja im 192.168.0.x Subnetz ist.
Aber: Für die Fritzbox ist eine OpenVPN-Verbindung, die durch sie hindurch geht, im Prinzip nichts anderes als zB eine http-Verbindung. Auch bedeutet OpenVPN für die Fritzbox keinen erhöhten Arbeitsaufwand, da sie die VPN-Pakete wie gesagt einfach nur ungesehen durchreicht, wie beim Surfen, Download, etc.. Wenn die Fritzbox allerdings tatsächlich die Internetverbindung abbricht, also eine vollständige Neueinwahl beim Provider, etc. dann liegt ein anderer Fehler vor, der mit dem VPN an sich eigentlich nichts zu tun haben kann. IP- bzw. Routing-Konflikte wie identische Subnetze bei VPNs, hätten höchstens zur Folge, dass man lokal/entfernt eben keine Geräte erreichen kann, weil der Datenverkehr ins jeweils andere Netzwerk eben nicht über das VPN getunnelt wird. Mit der Verbindung des Fritzbox-Modems hat das jedoch nichts zu tun!
*Anmerkung: Streng genommen ist 192.168.0.x keine korrekte Angabe für ein Subnetz. Richtig wäre 192.168.0.0/24, aber da ich nicht auch noch Subnetzmasken erklären wollte, habe ich mich mal an deine Schreibweise angepasst
Ja, sorry für mein Halbwissen was IP-Adressen und Subnetze angeht.
Kann es denn daran liegen, dass auf der einen Seite eine IPv6-Anbindung mit DualStack besteht? Das würde zumindest erklären, warum es weder mit den beiden NAS über OpenVPN noch mit einer direkten Verbindung der beiden Fritzboxen funktioniert.
Kann es denn daran liegen, dass auf der einen Seite eine IPv6-Anbindung mit DualStack besteht? Das würde zumindest erklären, warum es weder mit den beiden NAS über OpenVPN noch mit einer direkten Verbindung der beiden Fritzboxen funktioniert.
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 18.285
DualStack ist kein Problem. DS-Lite wäre eines.
Bei echtem DualStack hat man sowohl eine öffentliche IPv4 als auch eine öffentliche IPv6. Bei DS-Lite hat man hingegen nur eine öffentliche IPv6, da man sich die IPv4 mit anderen Kunden teilt. Das nennt sich dann CGN - Carrier Grade NAT - und ist im Prinzip nichts anderes als ein großer Router beim Provider, der alle Kunden-Router dahinter mittels NAT kaschiert - ganz ähnlich wie der heimische Router eben den PC, die Xbox, den TV, etc. hinter NAT versteckt, eben nur eine Ebene höher, beim Provider.
Hinter einem Anschluss mit DS-Lite kann man daher nur einen Server via IPv6 betreiben, nicht jedoch via IPv4. VPN via IPv6 ist nicht ohne und funktioniert nicht wirklich mit 08/15 Heimequipment. Deswegen muss der VPN-Server dann an einem herkömmlichen Anschluss betrieben werden, der noch via IPv4 erreichbar ist. Der Anschluss mit DS-Lite kann aber problemlos als VPN-Client fungieren.
VPN-Client (IPv4) --xxx--> (DS-Lite IPv4) VPN-Server => Nicht OK
VPN-Client (DS-Lite) -------> (IPv4) VPN-Server => OK
VPN-Client (IPv6) -------> (DS-Lite IPv6) VPN-Server => OK, aber IPv6-VPN erforderlich
Bei echtem DualStack hat man sowohl eine öffentliche IPv4 als auch eine öffentliche IPv6. Bei DS-Lite hat man hingegen nur eine öffentliche IPv6, da man sich die IPv4 mit anderen Kunden teilt. Das nennt sich dann CGN - Carrier Grade NAT - und ist im Prinzip nichts anderes als ein großer Router beim Provider, der alle Kunden-Router dahinter mittels NAT kaschiert - ganz ähnlich wie der heimische Router eben den PC, die Xbox, den TV, etc. hinter NAT versteckt, eben nur eine Ebene höher, beim Provider.
Hinter einem Anschluss mit DS-Lite kann man daher nur einen Server via IPv6 betreiben, nicht jedoch via IPv4. VPN via IPv6 ist nicht ohne und funktioniert nicht wirklich mit 08/15 Heimequipment. Deswegen muss der VPN-Server dann an einem herkömmlichen Anschluss betrieben werden, der noch via IPv4 erreichbar ist. Der Anschluss mit DS-Lite kann aber problemlos als VPN-Client fungieren.
VPN-Client (IPv4) --xxx--> (DS-Lite IPv4) VPN-Server => Nicht OK
VPN-Client (DS-Lite) -------> (IPv4) VPN-Server => OK
VPN-Client (IPv6) -------> (DS-Lite IPv6) VPN-Server => OK, aber IPv6-VPN erforderlich
Der andere Anschluß ist natürlich DS-Lite :-)
Seit einer Woche läuft aber nun das Backup ohne Probleme.
Geändert habe ich den Port von dem selbst gewählten 9595 hin zum Standardport 1194 und ich habe von UDP auf TCP gewechselt. Die Verbindung von Diskstation B zu A wird über IPv4 gemacht.
Die VPN-Verbindung von Fritzbox zu Fritzbox über IPv6 habe ich - trotz des vermeintlich einfacheren Setups - nicht zum Laufen gebracht.
Ich vermute, das Problem mit der Fritzbox, die sich komplett weghängt lag an den beiden identischen Subnetzen.
Noch einmal danke für die Hilfe :-)
Seit einer Woche läuft aber nun das Backup ohne Probleme.
Geändert habe ich den Port von dem selbst gewählten 9595 hin zum Standardport 1194 und ich habe von UDP auf TCP gewechselt. Die Verbindung von Diskstation B zu A wird über IPv4 gemacht.
Die VPN-Verbindung von Fritzbox zu Fritzbox über IPv6 habe ich - trotz des vermeintlich einfacheren Setups - nicht zum Laufen gebracht.
Ich vermute, das Problem mit der Fritzbox, die sich komplett weghängt lag an den beiden identischen Subnetzen.
Noch einmal danke für die Hilfe :-)
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 18.285
Ganz miese Idee. Wenn das VPN auf TCP läuft, werden TCP-Verbindungen doppelt mit TCP Handshakes versehen, was einen gehörigen Oberhead bedeutet und somit die Performance stark beeinträchtigen kann. Es ist dringend empfohlen, bei UDP zu bleiben.MickH74 schrieb:
Hm... gerade auf UDP umgestellt und VPN verbunden. Schon konnte ich keine Webseite mehr aufrufen und die Fritzbox war auch nicht mehr erreichbar. Musste die FB vom Strom trennen und neu starten. Nun weiß ich wenigstens woran es lag 
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 18.285
Das muss aber andere Gründe haben. Ich erläutere das TCP-VPN-Problem mal näher:
Hauptbestandteil von TCP sind Handshakes. Jedes eingehende Paket wird bestätigt, quasi wie bei einem Einschreiben. Kommt die Quittung zu spät, wird das Paket nochmal geschickt, weil TCP mit den Handshakes dafür sorgt, dass alle Pakete ihr Ziel erreichen. Man spricht bei TCP von "verbindungsorientiert".
- A schickt Paket P1 an Z
- Z quittiert P1 an A
- A schickt P2 an Z
- Z quittiert P2 an A
--> 4 Pakete
UDP wiederum ist "verbindungslos". Es gibt keine Quittierung und somit auch keinen Mechanismus, um sicherzustellen, dass alle Pakete ankommen. Kurz: UDP ist es egal ob Pakete verloren gehen.
- A schickt Paket P1 an Z
- A schickt P2 an Z
--> 2 Pakete
Bei einem VPN mit TCP werden alle Pakete inkl. etwaiger Quittungen nochmal in TCP gekapselt und jeweils ebenfalls quittiert. Aus 4 Paketen werden dann 8. Durch diese Verdoppelung sinkt die Übertragungsrate, weil quasu jede Quittierung nochmals quittiert wird - doppelt gemoppelt. Im Falle von UDP ist die Quittierung sogar komplett überflüssig.
Dieser Effekt verstärkt sich noch, wenn wirklich mal Pakete unterwegs verloren gehen. Dann werden nämlich auch die Neusendungen verdoppelt...
Bei einem UDP-VPN quittiert das VPN selbst überhaupt nix. Es wird also der gekapselten Verbindung selbst überlassen ob sie TCP Handshakes braucht oder sich mit UDP begnügt. Das VPN schickt also genauso viele Pakete über die Leitung wie ohne VPN und somit geht auch keine Bandbreite verloren (abgesehen vom Overhead der Verschlüsselung)
Wie gesagt, wenn UDP-VPN nicht funktioniert, dann ist entweder die Portweiterleitung falsch oder die lokale Firewall am VPN-Endpunkt blockt die Pakete. Auf jeden Fall rate ich davon ab, OpenVPN mit TCP zu betreiben. Das solltte wirklich nur der allerletzte Ausweg sein, wenn alle Stricke reißen.
Hauptbestandteil von TCP sind Handshakes. Jedes eingehende Paket wird bestätigt, quasi wie bei einem Einschreiben. Kommt die Quittung zu spät, wird das Paket nochmal geschickt, weil TCP mit den Handshakes dafür sorgt, dass alle Pakete ihr Ziel erreichen. Man spricht bei TCP von "verbindungsorientiert".
- A schickt Paket P1 an Z
- Z quittiert P1 an A
- A schickt P2 an Z
- Z quittiert P2 an A
--> 4 Pakete
UDP wiederum ist "verbindungslos". Es gibt keine Quittierung und somit auch keinen Mechanismus, um sicherzustellen, dass alle Pakete ankommen. Kurz: UDP ist es egal ob Pakete verloren gehen.
- A schickt Paket P1 an Z
- A schickt P2 an Z
--> 2 Pakete
Bei einem VPN mit TCP werden alle Pakete inkl. etwaiger Quittungen nochmal in TCP gekapselt und jeweils ebenfalls quittiert. Aus 4 Paketen werden dann 8. Durch diese Verdoppelung sinkt die Übertragungsrate, weil quasu jede Quittierung nochmals quittiert wird - doppelt gemoppelt. Im Falle von UDP ist die Quittierung sogar komplett überflüssig.
Dieser Effekt verstärkt sich noch, wenn wirklich mal Pakete unterwegs verloren gehen. Dann werden nämlich auch die Neusendungen verdoppelt...
Bei einem UDP-VPN quittiert das VPN selbst überhaupt nix. Es wird also der gekapselten Verbindung selbst überlassen ob sie TCP Handshakes braucht oder sich mit UDP begnügt. Das VPN schickt also genauso viele Pakete über die Leitung wie ohne VPN und somit geht auch keine Bandbreite verloren (abgesehen vom Overhead der Verschlüsselung)
Wie gesagt, wenn UDP-VPN nicht funktioniert, dann ist entweder die Portweiterleitung falsch oder die lokale Firewall am VPN-Endpunkt blockt die Pakete. Auf jeden Fall rate ich davon ab, OpenVPN mit TCP zu betreiben. Das solltte wirklich nur der allerletzte Ausweg sein, wenn alle Stricke reißen.
Zuletzt bearbeitet:
W
Willnochreisen
Gast
-
Zuletzt bearbeitet von einem Moderator:
