3
Providerbindung bei VPN Standortkoppelungen über IPv6?
Wir sind ein mittelständiges Unternehmen und machen relativ viel mit Standortkoppelungen über VPN. Bisher ist das relativ einfach. Im einfachsten Fall routen zwei Router über VPN zwei verschiedene Netze. Wenn an einem der Standorte der Internetanschluss, bzw Provider gewechselt wird, muss nur an dem jeweiligen Router die Zugangsart oder Zugangsdaten geändert werden. Durch das Masquerading entsteht kein weiterer Aufwand.
Da wir uns langsam mit dem Thema IPv6 beschäftigen, folgende Überlegung, wieder für den einfachsten Fall. Zwei verschiedene Netze werden gekoppelt. Jedoch, wenn ich das richtig verstanden habe, kommunizieren die Rechner der jeweiligen Standorte direkt miteinander. Die Router können den Datenverkehr wahrscheinlich verschlüsseln. Vom Provider des Internetzuganges bekommt man einen 64er Block zugewiesen. Dieser Block wird für diesen Standort konfiguriert.
Was passiert jedoch bei einem Providerwechsel? Muss dann der ganze Standort neu konfiguriert werden? Daraus würde ein immenser Konfigurationsaufwand an allen anderen Standorten entstehen, DNS, IPsec, usw.
Wie wird so etwas in der Praxis gemacht?
Da wir uns langsam mit dem Thema IPv6 beschäftigen, folgende Überlegung, wieder für den einfachsten Fall. Zwei verschiedene Netze werden gekoppelt. Jedoch, wenn ich das richtig verstanden habe, kommunizieren die Rechner der jeweiligen Standorte direkt miteinander. Die Router können den Datenverkehr wahrscheinlich verschlüsseln. Vom Provider des Internetzuganges bekommt man einen 64er Block zugewiesen. Dieser Block wird für diesen Standort konfiguriert.
Was passiert jedoch bei einem Providerwechsel? Muss dann der ganze Standort neu konfiguriert werden? Daraus würde ein immenser Konfigurationsaufwand an allen anderen Standorten entstehen, DNS, IPsec, usw.
Wie wird so etwas in der Praxis gemacht?
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: 169943
Url: https://administrator.de/contentid/169943
Ausgedruckt am: 25.11.2024 um 13:11 Uhr
3 Kommentare
Neuester Kommentar
Nein, natürlich nicht. Was du beschreibst ist nur der öffentliche Anschluss nicht aber der lokale Anschluss.
Auch jetzt kommunizieren ja eure beiden lokalen Netze (vermutlich setzt du hier private RFC 1918 IP Adressen als 10.x.x.x, 172.16.x.x usw. ein !) auch über den VPN Tunnel. Der Tunnel emuliert dir also sowas wie eine Standverbindung in die remote Lokation.
Nicht anders ist das bei IPv6 auch. Nur statt einer einzelnen IP Adresse am Router bekommst du jetzt ein komplettes Subnetz.
An der Tatsache das weiter private IPv6 Adressen ( Unique_Local_Adressen oder was auch immer du nutzt bei v6) auch wieder direkt über den VPN Tunnel kommunizieren ändert sich also nix...da bleibt alles so wie es bei v4 auch ist !
Auch jetzt kommunizieren ja eure beiden lokalen Netze (vermutlich setzt du hier private RFC 1918 IP Adressen als 10.x.x.x, 172.16.x.x usw. ein !) auch über den VPN Tunnel. Der Tunnel emuliert dir also sowas wie eine Standverbindung in die remote Lokation.
Nicht anders ist das bei IPv6 auch. Nur statt einer einzelnen IP Adresse am Router bekommst du jetzt ein komplettes Subnetz.
An der Tatsache das weiter private IPv6 Adressen ( Unique_Local_Adressen oder was auch immer du nutzt bei v6) auch wieder direkt über den VPN Tunnel kommunizieren ändert sich also nix...da bleibt alles so wie es bei v4 auch ist !
Ach so! Jetzt wird es klar. Die Unique Local Unicast hatte ich übersehen. Vielen Dank für die Antwort!
Hallo,
du kannst auch dein Internes Netz auf IPv4 belassen und öffentlich mit IPv6 arbeiten.
Funktioniert natürlich auch.
brammer
du kannst auch dein Internes Netz auf IPv4 belassen und öffentlich mit IPv6 arbeiten.
Funktioniert natürlich auch.
brammer
