10.11.2018, aktualisiert am 12.11.2018

10186

IPv6 Konfiguration von Site-Site-VPN ohne feste IP

Hallo zusammen,

vor einiger Zeit hatte ich hier eine Frage zu dem Thema gepostet: Statische IPv6 im internen Netz ohne feste IP am ISP Da war noch etwas offen. Seitdem ist einige Zeit vergangen und ich glaube, ich habe so langsam die Sache mit der IPv6 Address-Selection verstanden.

Daher habe ich meine bisherigen Erkenntnisse mal zusammengefasst.

Diese Anleitung bezieht sich zum Teil nur auf Windows Systeme. Ich setzte voraus, dass dir Grundlagen zur Konfiguration eines Site-Site-VPNs bekannt sind sowie die Grundlagen zu IPv6. Natürlich ist diese Anleitung nur nützlich, wenn man Standorte, an denen IPv6 verwendet wird, verbinden will.

Ansonsten lese man den Beitrag von @aqui : VPNs einrichten mit PPTP
sowie https://de.wikipedia.org/wiki/IPv6 und ggf. https://danrl.com/projects/ipv6-workshop/

Inhaltsverzeichnis

Ausgangslage

Verbindung von Standorten mit festen (Internet)-IPs

Verbindung von Standorten mit wechselnden (Internet)-IPs

Lösung: Unique-Local-Address

Neues Problem - die Namensauflösung: Prefixpolicies

Alternative Lösungen

Ausgangslage

Auch im IPv6-Zeitalter kann es sehr sinnvoll sein, Standorte über ein VPN zu verbinden. Das ist aber eine andere Diskussion. Ich gehe davon aus, dass ein VPN zwischen den Standorten besteht. Hierdurch wird der inter-Site Datenverkehr gekapselt, verschlüsselt und somit abgesichert. Allerdings können hier Probleme auftauchen, wenn einer (oder beide) Standorte keine feste IP-Adresse besitzen. Um das zu erklären, stelle ich zunächst die Situation bei festen ISP-IPs dar:

Verbindung von Standorten mit festen (Internet)-IPs

Beide Standorte bekommen vom ISP durch Übergabe eines IPv6-Präfixes einen festen IPv6-Bereich zugewiesen. Mit diesem Präfix können im LAN Global-Unicast Adressen erzeugt werden. Beide Standorte werden über ein VPN verbunden. Das VPN verbindet als Site-Site-VPN die IPv6-Bereiche der beiden Standorte miteinander. Natürlich kann die Link-Lokal-Adresse (fe80:: ) nicht geroutet werden, geroutet werde die Global-Unicast-Adressen.

Die Situation stellt sich dann wie folgt dar:

Site-A: ServerA1

C:\Windows\system32>ipconfig /all

Ethernet-Adapter Ethernet:

   IPv6-Adresse. . . . . . . . . . . : 2003:1:1:1:1:1:1:1(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80:1:1:1:1:1(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0

Site-B: ServerB1

C:\Windows\system32>ipconfig /all

Ethernet-Adapter Ethernet:

   IPv6-Adresse. . . . . . . . . . . : 2003:2:1:1:1:1:1:1(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80:2:1:1:1:1(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.2.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0

Die VPN-Router routen den Datenverkehr zwischen den Standorten:

VPN-Router am Standort A routet das Ziel 2003:2:1:1::::/64 über das VPN.
VPN-Router am Standort B routet das Ziel 2003:1:1:1::::/64 über das VPN.

Soweit wie erwartet.

Verbindung von Standorten mit wechselnden (Internet)-IPs

Was passiert nun, wenn einer oder beide Standorte über keine feste IP verfügen?

Site-A: ServerA1

C:\Windows\system32>ipconfig /all

Ethernet-Adapter Ethernet:

   IPv6-Adresse. . . . . . . . . . . : 2003:1:1:1:1:1:1:1(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80:1:1:1:1:1(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0

Site-B: ServerB1

C:\Windows\system32>ipconfig /all

Ethernet-Adapter Ethernet:

   IPv6-Adresse. . . . . . . . . . . : 2003:2:1:1:1:1:1:1(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80:2:1:1:1:1(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.2.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0

Die VPN-Router müssten eigentlich genau so, bei festen IPs arbeiten. Also:

VPN-Router am Standort A routet das Ziel 2003:2:1:1::::/64 über das VPN.
VPN-Router am Standort B routet das Ziel 2003:1:1:1::::/64 über das VPN.

Allerdings ändern sich die Präfixe bei jeder Einwahl. Nach der nächsten Einwahl müssten die Routing-Regeln geändert werden, je nach zugewiesenem Präfix, also z.B.:

VPN-Router am Standort A routet das Ziel 2003:2a:34:1::::/64 über das VPN.
VPN-Router am Standort B routet das Ziel 2003:a74:24:1::::/64 über das VPN.

Das Problem könnte ja unter Umständen über noch über aktivierte Routingprotokolle gelöst werden (siehe zum Beispiel RIPng). Mein Router beispielsweise kann das nicht, die über VPN verbundenen Subnetze müssen fest benannt werden.

Das zweite Problem haben die DNS-Server der Standorte. Korrekt konfiguriert erhalten die DNS-Server natürlich umgehend die jeweils aktuelle IPv6 Adresse der Rechner des Standortes. Allerdings kann der DNS-Server von Standort A nicht auf einen DNS-Server am Standort B zugreifen, da er dessen neue Global-Unicast-Adresse nicht kennt.

Damit sind selbst eine Kommunikation zwischen den Standorten über IPv6 nicht mehr möglich.

Lösung: Unique-Local-Address

Zunächst müssen für die Standorte feste Unique-Local-Adressen vergeben werden.

https://tools.ietf.org/html/rfc4193

6.  Advantages and Disadvantages

6.1.  Advantages

   This approach has the following advantages:

        ...

      - Provides Local IPv6 prefixes that can be used independently of
        any provider-based IPv6 unicast address allocations.  This is
        useful for sites not always connected to the Internet or sites
        that wish to have a distinct prefix that can be used to localize
        traffic inside of the site.

      - Sites can change their provider-based IPv6 unicast address
        without disrupting any communication that uses Local IPv6
        addresses.

        ...

      - Can be used for inter-site VPNs.

Super! Genau das ist ja das Anwendungsszenario!

Es sei darauf hingewiesen, dass diese eigentlich nur für spezielle Situationen gedacht sind.

Insbesondere soll ein Routing ins Internet ausgeschlossen sein.
Auch sollte man den Erzeugungsalgorithmus beachten, der durch zufällige Generierung der Adresse die Wahrscheinlichkeit für Adresskollisionen minimieren soll. Man sollte nicht Präfixe wie fd00:1:: wählen!
Der zu verwendende Bereich ist hier fd00::/8 also fd00:: bis fdff:: (der Bereich fc00:: bis fcff:: fällt ebenfalls unter Unique-Local-Address, ist aber undefiniert)

Die Sache würde dann z.B. so aussehen:

Site-A: ServerA1

C:\Windows\system32>ipconfig /all

Ethernet-Adapter Ethernet:

   IPv6-Adresse. . . . . . . . . . . : 2003:1:1:1:1:1:1:1(Bevorzugt)
   IPv6-Adresse. . . . . . . . . . . : fd65:1:1:1:192:168:1:10(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80:1:1:1:1:1(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0

Site-B: ServerB1

C:\Windows\system32>ipconfig /all

Ethernet-Adapter Ethernet:

   IPv6-Adresse. . . . . . . . . . . : 2003:2:1:1:1:1:1:1(Bevorzugt)
   IPv6-Adresse. . . . . . . . . . . : fd65:2:1:1:192:168:2:10(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80:2:1:1:1:1(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.2.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0

Die VPN-Router routen den Datenverkehr zwischen den Standorten:

VPN-Router am Standort A routet das Ziel fd65:2:1:1::::/64 über das VPN.
VPN-Router am Standort B routet das Ziel fd65:1:1:1::::/64 über das VPN.

Neues Problem - die Namensauflösung: Prefixpolicies

Jetzt können IP-Adressen unabhängig vom ISP-Präfix zugewiesen werden, das VPN steht auch nach einer Adressänderung durch den ISP.

Von Standort A funktioniert jetzt ein ping -6 fd65:2:1:1:192:168:2:10.

Der Versuch des Pings auf den Hostnamen zeigt aber, dass der leider nicht die Unique-Local-Address verwendet wird, sondern die Global-Unicast-Address. Warum?

Windows-Clients registrieren alle IPv6-Addresen eines Interfaces beim DNS-Server, wenn dies für das Interface eingestellt ist (Häkchen bei Adressen dieser Verbindung in DNS registrieren). Meines Wissens kann man das nicht auf einzelne IPv6-Präfixe oder Scopes beschränken! Dies gilt auch, wenn es keine Reverse-Lookupzone gibt. Daher erhält der anfragende Client mehrer IPvs-Adressen ausgeliefert:

C:\Windows\system32>nslookup
Standardserver:  dns-server1.lokaletestdomain.de
Address:  192.168.0.10

> anderer-server1
Server:  dns-server1.lokaletestdomain.de
Address:  192.168.0.10

Name:    anderer-server1.lokaletestdomain.de
Addresses:  fd65:5:5:1:2:3:4
          fd65:1:1:1:192:168:1:10
          2003::5:5:1:2:3:4
          192.168.1.10

Das Problem liegt im Default-Address-Selection Algorithmus des IPv6 Gerätes: http://www.ietf.org/rfc/rfc3484.txt
Letztlich werden alle erhaltenen IPv6 Adressen nach den Vorgaben einer nach Vorrang sortierte Präfix-Liste sortiert. Die Adresse mit dem höchsten Vorrang wird dann ausgewählt (Existieren mehrere Adressen mit dem gleichen Prefix, treten hier noch andere Sortierregeln hinzu, siehe rfc, aber das ist an dieser Stelle nicht relevant!).

Diese sogenannten Prefixpolicies können über netsh oder powershell (Get-NetPrefixPolicy) abgefragt werden.

C:\Windows\system32>netsh interface ipv6 show prefixpolicies
Der aktive Status wird abgefragt...

Vorgänger   Label  Präfix
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

Hier scheint Microsoft etwas unglücklich übersetzt zu haben. Vorgänger statt Precedence - Vorrang wäre viel besser. Die zutreffende Zeile mit der höchsten Precedence wird verwendet, um festzulegen, welche IPv6 Adresse als Zieladresse festgelegt wird. Davon wird dann auch die Quelladresse abgeleitet. Man kann sich die prefixpolicies-Tabelle analog zu einer Routingtabelle vorstellen. (Predescence entspricht hier der Metrik, allerdings umgekehrt gewichtet).

In der oben gezeigten Tabelle haben alle Unique-Local-Addressen fc00::/7 eine viel niedrigere Predecence (nämlich 3) als normale IPv6-Addressen ::/0 Damit verlieren unsere Unique-Local-Adressen und die Global-Unicast-Adresse wird ihnen vorgezogen.

Zum Glück kann man die Prefixpolicies ändern (Linux: siehe man gai.conf ).

C:\Windows\system32>netsh int ipv6 add prefixpolicy fd65:1:1::/48 45 20
OK.

Im Hinblick auf den Default-Address-Selection Algorithmus kann en nicht schaden, an allen Standorten das gleiche Label (hier: 20) zu verwenden. Zunächst ist aber die erhöhte Predescence wichtig.

Hilfe dazu siehe auch netsh interface ipv6 add prefixpolicy ?

C:\Windows\system32>netsh interface ipv6 show prefixpolicies
Der aktive Status wird abgefragt...

Vorgänger   Label  Präfix
----------  -----  --------------------------------
        50      0  ::1/128
        45     20  fd65:1:1:1:/48
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

Jetzt wird, wenn der DNS-Server bei der Namensauflösung mehrere IPv6-Adressen ausspuckt, die Unique-Local-Address des Ziels ausgesucht und die entsprechende eigene Unique-Local-Address als Quelladresse verwendet.

Achtung: Die Predescence muss bei allen Clients geändert werden, die den Hostnamen eines Hosts über einen DNS-Server auflösen, der die sich ändernden Global-Unicast-Adressen kennt!

Alternative Lösungen

Das Problem der Namensauflösung kann man auch anders angehen:

das Verwenden der Unique-Local-Adresse statt des Hostnamens
das umgehen der DNS-Auflösung über andere Mechanismen (möglicherweise /drivers/etc/hosts ? von mir nicht getestet)
Das manuelle Eintragen der Server-IPv6-Adressen und das Abschalten der automatischen Registrierung. Damit sind dem DNS-Server die Global-Unicast-Adressen unbekannt. Dies wiederspricht allerdings den Windows Best-Practies: DNS: Schnittstelle Ethernet des DNS-Servers sollte so konfiguriert sein, dass die IP-Adressen in DNS registriert werden
Bevorzugen von IPv6 gegenüber IPv4: https://support.microsoft.com/de-de/help/929852/guidance-for-configuring ... per Windows-Registry. Hier wird als Übergangslösung wieder eine Mischtechnologie implementiert (LAN IPv4, sonst IPv6).

Viele Spass damit!

lcer

EDIT (einige kleine Ergänzungen)

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 392319

Url: https://administrator.de/contentid/392319

Ausgedruckt am: 13.11.2024 um 11:11 Uhr

2 Kommentare

Neuester Kommentar

Stand der Dinge:

momentan sieht meine Konfiguration wie folgt aus:

ich habe an den Standorten ULAs konfiguriert
bei den Windows-Rechnern ist per Registry Bevorzugen von IPv6 gegenüber IPv4 eingestellt

Die Priorisierung der ULAs per Erhöhung der Predescense bringt hat einige Probleme mit sich: Der Algoritmus der Source Address Selection kommt zum falschen Ergebnis, wenn der Scope des der Global-Unicast-Adresse des LAN Native-IPv6 und der Scope des Ziels eine Übergangstechnologie-IPv6 Adresse darstellt. Hier passt dann der Scope nicht (Rule 2 des Algoritmus). Dann wird unter Umständen die ULA wegen der erhöhten Predescence als Source-Adresse ausgewählt (zumindest war das bei mir so).

Obwohl die Einstellung Bevorzugen von IPv6 gegenüber IPv4 auch nichts anderes tut, als die Predescence zu ändern (kann man schön über netsh interface ipv6 show prefixpolicies verfolgen) gibt es einen entscheidenden Unterschied: Zu den vom DNS-Server zurückgelieferten IPv4-Adressen können immer gültige Quelladressen gefunden werden, da immer eine verwendbare IPv4-Adresse ausgewählt wird.
Der Client hat da nämlich nur die eine, die dann in der Regel über NAT umgesetzt als Quelladresse fungieren kann. Wird hingegen für das LAN verlassende Zieleadressen die ULA als Quelladresse ausgewählt, fehlt dann die Rückroute vom Provider zum LAN.

Grüße

lcer

momentaner Status: IPv6 wieder deaktiviert. Es gab immer wieder Probleme mit der Erreichbarkeit.

Ich denke, die richtige Lösung wäre ein passendes Routing-Protokoll für die VPN-Router, die leider keins beherrschen. NDP reicht nicht aus.

Grüße

lcer

Anleitung Netzwerke Protokolle VPN

Mehr von lcer00

Ereignisweiterleitung: Benötigt ein quellinitiiertes Abonnement WinRM eingehend am Quellcomputer?lcer00 - 2 Kommentare

Kann man sich in Teams benachrichtigen lassen, wenn eine neue Email in einem freigegebenen Postfach eintrifft?lcer00 - 2 Kommentare

Was hat einen Salesforce ODBC Treiber installiert?lcer00 - 2 Kommentare

FortiGate 40F, 60E, 60F, 80E, oder 90E kann ab FortiOS 7.2.6 nicht mehr Fabric Root seinlcer00 - 2 Kommentare

Heiß diskutiert