lcer00
Goto Top

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. face-smile 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/


back-to-topAusgangslage

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:
back-to-topVerbindung 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.
back-to-topVerbindung 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.

back-to-topLö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.

back-to-topNeues 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!

back-to-topAlternative Lösungen
Das Problem der Namensauflösung kann man auch anders angehen:

Viele Spass damit!

lcer


EDIT (einige kleine Ergänzungen)

Content-ID: 392319

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

Ausgedruckt am: 21.11.2024 um 17:11 Uhr

lcer00
lcer00 12.11.2018 um 13:44:14 Uhr
Goto Top
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
lcer00
lcer00 09.05.2019 um 08:06:13 Uhr
Goto Top
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