FTTH mit IPv6 (DG)

Seit 15.7.2020 habe ich einen Glasfaser-Anschluss, der technisch ein paar Anforderungen mitbringt. Es ist ein "Consumer"-Anschluss ohne statische IPv4-Adresse, was natürlich neue Herausforderungen an mein Home-Lab mitbringt. Ich habe zwar eine IPv6-Adresse aber keine öffentliche IPv4-Adresse. Die könnte ich durch den Wechsel auf einen "Business"-Anschluss natürlich bekommen aber ich nutze diese Change die Möglichkeiten mit dynamische Adressen auszuloten. Die IPv4-Knappheit betrifft ja auch andere Firmen und vielleicht ist IPv6 ja schon ein vollwertiger Ersatz.

Fritz!Box mit IPv6 und CGN

Die "Besonderheit" des Anschlusses sehen Sie schon im Übersichtsbild der Fritz!Box: Das Bild wurde am 24.7 aufgenommen, d.h. die Verbindung steht schon mal über 24h und wurde nicht abgebaut. Interessanter sind aber die IP-Adressen:

  • IPv4 aus 100.64.0.0/10 (100.64.0.0 bis 100.127.255.255 = 4.194.304 Adressen)
    Entgegen dem ersten Anschein sind das keine öffentlich routbaren Adressen, sondern besondere "Private Adresse" des Providers, der damit seinen Kunden eine im Internet nie genutzte "shared" IP-Adresse geben und per NAT umsetzen kann. Im Umkehrschluss bedeutet das aber, dass meine Fritz!Box und damit auch dahinter veröffentlichte Dienste nicht aus dem Internet erreichbar sind.
  • IPv6 Adresse und 56er Präfix
    Bei IPv6 gib es nicht die Knappheit, so dass der Provider einen großen IPv6-Adressbereich bekommen kann und jeden Kunde nicht nur eine Adresse sondern gleich einen kompletten Bereich zuweisen kann.
    Ich habe also 8 Bit (= 256 Subnetzes).

Hinweis:
Die IP-Adressen sind nicht auf immer statisch dem Kunden zugewiesen. Ab und an ändern sich die IPv6-Adressen. Sie können Sie also nicht für eingehende Verbindungen ohne dynamische DNS-Einträge nutzen.

Fernzugriff auf Heimnetz über IPv6
https://www.new.de/fileadmin/user_upload/new.de/Dokumente/Glasfaser/Fernzugriff_mittels_IPv6_ueber_DG_Router.pdf

Auf der anderen Seite ist so eine statische Zuordnung natürlich auch wieder kritisch zu sehen, da ihr Client dann im Internet recht gut identifizierbar ist. die früher zumindest alle 24h geänderte öffentliche IP-Adresse ist so plötzlich ein eindeutiges Kriterium.

IPv4 und IPv6

Ich habe also eine IPv4-Adresse mit 100.75/16, die nicht aus dem Internet erreichbar ist und eine IPv6-Adresse und ein IPv6 Subnetz, von denen aber nicht sicher ist, dass sie mir auf Dauer erhalten bleiben. Also gibt es einige Werge zur Veröffentlichung eigener Dienste, die mit einem Internet-Anschluss der "Deutschen Glasfaser" nicht funktionieren.

Client DG IP 100.75.x.x oder IPv6 Backend Server Status Beschreibung

IPv4Only

IPv4

IPv4

Die 100.75.x.x Adresse aus dem "Provider Shared Space" ist nicht aus dem Internet erreichbar

IPv4Only

IPv6

IPv4

Ein IPv4Only Client kann nicht die offizielle IPv6 Adresse erreichen

IPv4Only

IPv4

IPv6

 Wenn die Fritz!Box oder ein anderer Proxy oder Service den Zugriff auf die IPv4-Addresse auf eine IPv6-Adresse des internen Service umsetzen kann (Siehe PortProxy - ReverseNAT mit Windows), dann ist die Erreichbarkeit möglich.

IPv4Only

IPv6

IPv6

Ein IPv4Only Client kann nicht die offizielle IPv6 Adresse erreichen

IPv6 Client

IPv4

IPv4

 Ein IPv6Only Client kann eine offizielle IPv4 Adresse nur erreichen, wenn der Provider mithilft und die Namensauflösung (DNS64) und Routing über NAT64 umsetzt. Diese Technik nutzt z.B. auch Direct Access mit DA Namensauflösung. besser ist es IPv6 direkt zu nutzen

IPv6 Client

IPv4

IPv6

Auch hier ist NAT64/DNS64 erforderlich und zusätzlich müssen Sie noch IPV4 auf IPv6 per Proxy umsetzen. Ja, es sollte gehen aber mir sind es zu viele Komponenten

IPv6 Client

IPv6

IPv4

Diese Fall beschreibt einen Service, der selbst nicht per IPv6 erreichbar ist. Der Client kann die öffentlichen IPv6-Addresse nutzen aber sie brauchen dennoch eine aktive Komponente, die Verbindung auf eine IPv4-Adresse umsetzen, z.B. PortProxy oder NAT64.

IPv6 Client

IPv6

IPv6

Der Fall ist natürlich einfach, da nur IPv6 zum Einsatz kommt.

Veröffentlichen

Die vorige Tabelle hat gut gezeigt, dass einige Varianten ausscheiden, die reine IPv6-Option ideal wäre aber für die Koexistenz mi IPv4-Systemen doch noch ein Weg bereitgestellt werden sollte. Ob ihr eigener IP-Anschluss komplett IPv6-tauglich ist, können Sie z.B. mit folgender Webseite mal schnell testen:

Eine 10/10 ist der ideale Fall. Aber leiden haben nicht alle Anbindungen hier eine "10" und daher habe ich mir Gedanken gemacht, wie ich z.B. meinen eigenen PRTG-Server von extern erreichbar machen kann, damit ich auch zukünftig mit im meinem Smartphone den Status meiner Dienste sehen kann. Es gibt durchaus Optionen: 

Option IPv4only Client IPV6 Client

Direkte IP-Veröffentlichung

Ich kann über meinen DSL-Router natürlich den internen Service oder Host nach extern veröffentlichen. Jeder, der damit an die öffentlichen IP-Adresse des Routers kommt, kann den Dienst erreichen. Mit dem DG-Anschluss bedeutet das aber

  • IPv4: 100.75.x.x
    Diese Adresse ist nicht aus dem Internet aber anscheinend von anderen DG-Kunden erreichbar. Zumindest konnte ich andere Adressen in diesem Bereich per PING erreichen. Aber das ist natürlich keine Lösung.
  • IPv6: 2A00:6020:1000:3/64
    Diese öffentliche IP-Adresse kann ich aus dem Internet erreichen. Wenn Sie statisch ist, kann ich die Adressen in meinem externen DNS fest hinterlegen. Ansonsten könnte ich dynamische DNS-Einträge über einen klassischer DynDNS-Dienstleister, Azure-DNS, AVM's MyFritz oder Synology.me u.a. nutzen

Sie sehen selbst, dass diese Option nur möglich ist, wenn der Client eine IPv6-Adresse auflösen und erreichen kann. Aber der Backend-Service selbst muss auch IPv6 annehmen, denn die Fritz!Box macht kein NAT zwischen IPV4 und IPv6

 Nein Ja

Cloud Proxy

Auf der Seite Azure AD Application Proxy habe ich ausführlich beschrieben, wie Microsoft Azure mir eine öffentlichen HTTP-Adressen bereitstellt und alle Zugriff über einen intern installierten AppProxy an einen lokalen Server weiter gibt. Das funktioniert wunderbar aber erfordert natürlich ein Lizenz ($)

 Ja Ja

IPv6-VPN

Wenn der Zugriff nur für mich und meine bekannten Geräte gefordert ist, dann könne ich natürlich auch ein VPN vom Client zu einem Server per IPv6 aufbauen und dann mich in in meinem privaten Netzwerk tummeln. Das geht dann sogar mit IPv4. Allerdings muss das VPN natürlich über IPv6 aufgebaut werden, da nur die IPv6-Adresse eine öffentliche Adresse ist. Über das VPN gewinne ich natürlich zusätzliche Sicherheit durch Verschlüsselung aber vor allem auch durch die Authentifizierung der Client z.B.: per Zertifikate o.ä.

 Ja Ja

IPv6 zu IPv4 Proxy

Ohne öffentlich erreichbare IPv4-Adresse kann ich aber Clients immer noch auf eine IPv6-Addresse lenken. Ich muss dann intern aber reine IPv4-Dienste mit etwas Hilfestellung erreichbar machen. Voraussetzung ist nur, dass der Client die IPv6-Adresse erreichen kann. Die Umsetzung von IPv6 auf IPv4 kann eine Firewall, ein HTTP-Proxy oder auch der Windows PortProxy übernehmen. Eine Fritz!Box kann das leider nicht mit Bordmitteln.

 Ja Ja

IPv6 Analyse

Es war damit mal an der Zeit die IP-Adressen genauer zu untersuchen. Meine Fritz!Box hat mir im "Online-Monitor" ja solche Daten geliefert:

verbunden seit 22.07.2020, 13:28 Uhr,
IPv6-Adresse: 2a00:6020:1000:3:67:5a0b:1ee1:d90c, Gültigkeit: 3482/2132s,
IPv6-Präfix:  2a00:6020:13fa:d300::/56, Gültigkeit: 3482/2132s

Das scheint eine "öffentliche IPv6-Adresse" in einem /56er Subnetz zu sein. Auch meinen Client habe ich dann per IPCONFIG /ALL meine IPv6-Adressen kontrolliert:

PS C:\> ipconfig /ALL

Windows-IP-Konfiguration

Ethernet-Adapter vEthernet (Extern):

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physische Adresse . . . . . . . . : F2-20-7A-B3-66-42
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2a00:6020:13fa:d300:e569:f4df:70eb:442e(Bevorzugt)
   Temporäre IPv6-Adresse. . . . . . : 2a00:6020:13fa:d300:d062:a007:3e65:45f2(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80::e569:f4df:70eb:442e%99(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.91(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Sonntag, 21. Juni 2020 22:52:14
   Lease läuft ab. . . . . . . . . . : Freitag, 7. August 2020 11:51:38
   Standardgateway . . . . . . . . . : fe80::cece:1eff:fe34:3d04%99
                                       192.168.178.1
   DHCP-Server . . . . . . . . . . . : 192.168.178.1
   DHCPv6-IAID . . . . . . . . . . . : 1676812410
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-22-75-DA-8C-8C-16-45-70-A0-EF
   DNS-Server  . . . . . . . . . . . : fd00::cece:1eff:fe34:3d04
                                       192.168.178.1
                                       fd00::cece:1eff:fe34:3d04
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Mein Client hat eine normale und eine "temporäre" IPv6-Adresse. Über die statische Adresse können andere Systeme meinen Client ansprechen, während mein Client ausgehende Verbindung über die temporäre Adresse aufbaut. Sie können dies z.B. mit Wireshark kontrollieren. Diese zweite Adresse kann der Client immer wieder ändern und damit in Grenzen eine Zuordnung erschweren.

Das betrifft aber nur den individuellen Client. Die Gegenseite sieht aber auch nach dem Wechsel immer noch das "Subnetz" des Client und bei NAT64 die IP-Adresse des FTTH-Anschlusses.

Über test-ipv6.com können Sie sehr einfach ihre IPv6-Adresse ermitteln, Wie sie von der Gegenseite gesehen wird.

Ist es ein Risiko, wenn ich die Adresse hier veröffentliche?
Aus meiner Sicht nicht, denn sie ist nur temporär und ändert sich. Es ist sehr aufwändig 2^64 Adressen pro 256 Subnetze, die ich auch noch habe, durchzuprobieren und dann noch drauf zu hoffen, dass die Fritz!Box eingehende Verbindungen zulässt UND mein Client diese auch noch durchlässt.

Interessant ist hier auch die IPv4-Adresse (Im Beispiel 94.31.84.48). Diese Adresse habe ich weder an meinem PC noch meiner Fritz!Box sondern diese ist das NAT-System für IPv4-Zugriffe. Die Kette der Systeme ist für IPv4 undIPv6 unterschiedlich.

Ausgehend sehen Sie, dass IPv6 sehr direkt dort hin geht während IPv4-Ziele durch das NAT des eigenen Routers als auch durch das NAT des Providers laufen. Das sehen Sie auch beim TraceRoute.

Traceroute Traceroute -6 outlook.office365.com Traceroute -4 outlook.office365.com
Stationen 
  1     1 ms     1 ms     1 ms  fritz.box 
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4    15 ms    15 ms    16 ms  2001:7f8:1::a500:8075:1
  5    15 ms    15 ms    15 ms  ae21-0.icr01.ams21.ntwk.msn.net 
  6    16 ms    15 ms    16 ms  2603:10a0:30f:9101::6
  7    14 ms    16 ms    16 ms  2603:10a0:30f:9001::6
  8    14 ms    13 ms    13 ms  2603:10a0:30f:9300::f6
  9    15 ms    16 ms    15 ms  2603:10a0:304:c::fa
 10    26 ms    27 ms    18 ms  2603:10a0:304:80a6::
 11    15 ms    15 ms    14 ms  2603:1026:204::2
 
  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     6 ms     9 ms     5 ms  100.68.0.1
  3     9 ms    10 ms    10 ms  100.127.1.13
  4     9 ms    11 ms     9 ms  185.22.46.72
  5     *        *       14 ms  ams-ix-1.microsoft.com [80.249.209.20]
  6    16 ms    18 ms    13 ms  ae21-0.icr01.ams21.ntwk.msn.net [104.44.232.164]
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12    14 ms    13 ms    13 ms  52.97.170.34

Der Weg über IPv4 enthält einen weiteren Hop, der beim IPv6 entfällt.

IPv6 und DNS64/NAT64

Anscheinend hat Deutsche Glasfaser kein DNS64/NAT64 implementiert. Wenn ich meinem Client die IPv4-Adresse weg nehmen, dann kann ich keine IPv4-Gegenstellen mehr erreichen. Für ein richtiges IPv6Only-Deployment wäre aber das natürlich eine Voraussetzung.

  1. Mein Client frage per DNSv6 einen Namen ab.
    Er hat in dem Beispiel ja keine eigene IPv4-Adresse mehr und kann keinen IPv4-DNS-Server abfragen
  2. Der DNS-Resolver "erkennt", dass die Gegenstelle kein IPv6 liefert
    In dem Fall liefert der DNS-Server dann eine IPv6-"NAT"-Adresse die auf die IPv4-Adresse verweist. Die beginnen übrigens alle mit dem Prefix "64:ff9b::" gefolgt von der IPv4-Adresse. Es sind natürlich auch andere Adressen denkbar. Das liegt im Verantwortungsbereich des Providers.
  3. Der Client verbindet sich zur IPv6-NAT-Adresse
    Per Routing laufen die Pakete zu einem System von DG, welches anhand der IPv6-Zieladresse die reale IPv4-Adresse ermitteln und umsetzen kann

Technisch ist das alles schon lange spezifiziert aber ich muss natürlich den DNS64-Server des Providers fragen.

  • Tunnelkomponenten
  • NAT64
    https://de.wikipedia.org/wiki/NAT64
  • RFC 6146 - „Stateful NAT64“. Beschreibt den eigentlichen NAT64-Mechanismus
  • RFC 6147 - „DNS64“. Beschreibt den für den Betrieb von NAT64 wichtigen Mechanismus DNS64
  • RFC 6052 -  IPv6 Addressing of IPv4/IPv6 Translators
  • RFC 8215 - Local-Use IPv4/IPv6 Translation Prefix

IPv6 per DNS/DDNS

Sie wissen nun, dass IPv4 von extern ohne Hilfe nicht erreichbar ist aber die IPv6-Adresse durchaus genutzt werden kann. Wenn die IPv6-Adresse statisch ist, dann kann ich diese in einem externen DNS-Server natürlich fest hinterlegen. Sollte sich die IPv6-Adresse eines Service dennoch mal ändern, dann muss ich dann natürlich nachsteuern. In meinem Fall habe ich eine Fritz!Box, bei der ich aber die internen Systeme explizit freigeben muss:

 

Sie sehen hier drei Freigaben, die aber alle nicht "offen" sind. Den Port 25 leite ich auf einen Notebook, der als Spamtrap und Honeypot fungiert. Mich interessiert ja schon, welche unterschiedlichen Angriffe auf Endkunden-Anschlüsse gefahren werden. Der zweite Eintrag ist eine Gegenstelle meines End2End-UDP3478-Skripte, welches ich nur bei Bedarf starte. Der dritte Eintrag ist aber ein PRTG-Server der so über IPv6 aus dem Internet erreichbar sein könnte.

Interessant ist in dem Zuge, dass die Fritz!Box selbst ja einen "DynDNS"-Dienst (MyFritz) enthält. Die Box registriert sich damit mit meinem Konto beim DNS-Server von AVM und erlaubt mit den Zugriff über einen "langen" Namen. Der Hostname sind 16 Stellen mit Buchstaben und zahlen, also ca. 36^16 Kombinationen und registriert sowohl die IPv4- als auch IPv6-Adresse, wie sie der Fritz!Box bekannt sind. Ein NSLOOKUP zeigt dies:

C:\>nslookup 1234567890abcdef.myfritz.net
Server:  fritz.box
Address:  fd00::cece:1eff:fe34:3d04

Nicht autorisierende Antwort:
Name:    1234567890abcdef.myfritz.net
Addresses:  2a00:6020:1000:3:67:5a0b:1ee1:d9c0
          100.75.251.69

Die IPv6-Addresse verweist auf die richtige Box und erlaubt mir von extern die Steuerung, wenn ich dies zulassen. Allerdings setzt die Fritz!Box keine Ports auf interne System um und daher ist diese Information nicht weiter hilfreich. Die IPv4-Adresse zeigt aber auf die "Carrier grade NAT"-Adresse ist und ist so gar nicht nutzbar.

Insofern sind beide Adressen nicht für weitere Dienste geeignet.

Auch meine Synology kann einen DDNS-Dienste nutzen. Hier sehen wir eine andere IPv6-Addresse, die so tatsächlich erreichbar wäre, wenn Sie denn in der Fritz!Box auch zugelassen wäre.

Auf der anderen Seite ist aber die ebenfalls registrierte IPv4-Adresse natürlich wertlos, da sie auf den NAT-Service des Zugangsproviders verweist und der sicher keine Zugriffe auf Port 443 genau auf meine Box weiter leitet. Der MyFritz!-Service nutzt also die von der Fritz!Box selbst lokal ermittelte IP-Adresse während Synology sich die Adresse nimmt, die als Quell-IP im Internet sichtbar ist.

Aktuell sieht es so aus, als ob ich meine 265 IPv6-Subnetze statisch behalte und daher kein DDNS brauche. Ich geben einfach die gewünschten Systeme mit den Ports in der Fritz!Box frei und addiere im Internet einen statischen AAAA-Eintrag bei meinem Webhosting-Provider

Wer IPv6-Dienste direkte registrieren will, sollte das direkt auf dem Sever machen, wie es z.B. die Synology vormacht. Eine Freischaltung auf der Fritz!Box ist natürlich zusätzlich erforderlich.

Deutsche Glasfaser - Freigaben ins Internet IPv6
https://www.youtube.com/watch?v=bGXi52UjdvA

PortProxy für IPv4

Nun ist der Weg aus dem Internet zu jeder IPv6-Adresse möglich aber leider gibt es immer noch Dienste, die selbst kein IPv6 sprechen. Dazu gehörte im Juni 2020 auch noch der PRTG-Server.

Ich muss mir also etwas überlegen, wie ich eine Anfrage auf eine IPv6-Adresse auf die IPv4-Adresse umsetze. Sicher kann ich dazu nun einen Loadbalancer, ReverseProxy o.ä. aufbauen und konfigurieren. Das muss ich aber gar nicht, denn das Bordmittel "PortProxy" von Microsoft Windows enthält diese grundlegende Funktion. Es wird leider nur per Kommandozeile konfiguriert aber kann zwischen IP-Adressen umsetzen.

Die Online-Hilfe zeigt die Möglichkeiten sehr gut auf:

C:\>netsh interface portproxy show

Folgende Befehle sind verfügbar:

show all       - Zeigt alle Portproxyparameter an.
show v4tov4    - Zeigt Parameter für Proxyvorgang von IPv4-Verbindungen mit anderem IPv4-Port an.
show v4tov6    - Zeigt Parameter für Proxyvorgang von IPv4-Verbindungen mit IPv6 an.
show v6tov4    - Zeigt Parameter für Proxyvorgang von IPv6-Verbindungen mit IPv4 an.
show v6tov6    - Zeigt Parameter für Proxyvorgang von IPv6-Verbindungen mit anderem IPv6-Port an.


C:\>netsh interface portproxy add v6tov4

Mindestens ein erforderlicher Parameter wurde nicht angegeben.
Überprüfen Sie die erforderlichen Parameter und geben Sie sie erneut ein.
Ungültige Syntax. Weitere Informationen finden Sie in der Hilfe des Befehls.

Syntax: add v6tov4 [listenport=]<Ganze Zahl>|<Dienstname>
              [connectaddress=]<IPv4-Adresse>|<Hostname>
              [[connectport=]<Ganze Zahl>|<Dienstname>]
              [[listenaddress=]<IPv6-Adresse>|<Hostname>]
              [[protocol=]tcp]

Parameter:
       Tag              Wert
       listenport     - IPv6-Port, der abgehört werden soll.
       connectaddress - IPv4-Adresse, mit der eine Verbindung hergestellt werden soll.
       connectport    - IPv4-Port, mit dem eine Verbindung hergestellt werden soll.
       listenaddress  - IPv6-Adresse, die abgehört werden soll.
       protocol       - Zu verwendendes Protokoll. Derzeit wird nur TCP unterstützt.

Anmerkungen: Fügt einen Eintrag für das Abhören von IPv6 und Proxy-verbindungen, die mit IPv4 hergestellt werden, hinzu.

Hier interessiert mich die Funktion "v6tov4" mit der ich Zugriffe auf einen Port einer IPv6-Adresse auf eine andere IP-Adresse und Port weiterleiten kann.

Ich habe auf dem PRTG-Server einfach folgenden Befehl gestartet:

netsh interface portproxy add v6tov4 -listenport=443 -connectaddress=127.0.0.1 -connectport=443 -protocol=tcp

Sofort war die Weboberfläche von PRTG auch per IPv6 erreichbar. Diese Funktion ist mit jedem Dienst nutzbar, der keine IPv6-Bindung anbietet und statische Ports nutzt.

Mit PRTG funktioniert dies aber nur, wenn ich per DNS-Allerdings nur, wenn ich einen DNS-Namen verwende und nicht die IPv6-Adresse. Das ist eine Besonderheit von PRTG, der den ersten Zugriff per "302 Moved" zu einer anderen URL umleitet und dabei den "Hostheader" auswertet. Wenn ich per IPv6-Adresse komme, dann kommt dieser Mechanismus wohl aus dem Tritt und liefert eine ungültige Location-Adresse, wie hier im Debugger des Browsers zu sehen ist.

Also sollten Sie einen DNS-Eintrag anlegen, der auf die IPv6-Adresse verweist, damit PRTG einfach eine URL bekommt, die er versteht.

Für die Erreichbarkeit aus dem Internet musste ich natürlich auf der Fritz!Box noch eine Freigabe einrichten.

Auch wenn ein Client eine öffentliche IPv6-Addresse hat, sorgt zumindest die Fritz!Box dafür, dass diese nicht aus dem Internet erreichbar ist. Die Freigabe ist hier aber kein "Reverse NAT", denn Umzusetzen gibt es hier nichts. Es ist eine Portfreischaltung.

IPv4 durch Dienstleister

Die Umsetzung eines externen Zugriffs auf einen internen Service oder ihren Router muss nicht in ihrem Haus erfolgen. Es gibt mehrere Dienstleister, öffentliche Adressen auf ihre Adresse umzusetzen. Das sind natürlich kommerzielle Angebote.

IPv4 mit AzureAD Proxy

Wer schon Cloud-Dienste von Microsoft nutzt, sollte in Azure prüfen, ob die Funktion "AzureAD App Proxy" vielleicht schon enthalten ist oder günstig dazu lizenziert werden kann. Es ist eine einfache und sichere Funktion, um interne Services über eine Azure-Komponente frei zu geben. Dazu ist mindestens ein "App Proxy Agent" im LAN erforderlich, der eine ausgehende Verbindung zu Azure aufbaut und offen hält. In Azure definieren Sie dann einen ProxyService, der die Anfragen aus dem Internet annimmt und nach optionaler Anmeldung über den etablierten Kanal zum Agent weiter zum eigentlichen Service leitet. 

Hier sehen Sie eine Beispielkonfiguration eines App Proxy, der aus dem Internet über die "External URL:443" per HTTPS erreichbar ist und die Zugriffe ohne weitere Authentifizierung über den internen Proxy an die interne Webseite "https://prtg.fritz.box:844" weiter gibt.

Die Einrichtung ist auf Azure AD Application Proxy ausführlich beschrieben und in der Regel in wenigen Minuten erledigt. Für den Client sieht dieser Zugriff aus, als wen der Service in Azure läuft und unterliegt auch den Schutzfunktionen von Microsoft. Ich kann sogar eine Pre-Authentication und Conditional Access umsetzen oder den Zugriff einfach wie hier anonym (Passthrough) durchlassen.

VPN als Tunnel

Nicht unterschlagen möchte ich natürlich die Funktion eines VPN. Der FTTH-Anschluss hat natürlich keine IPv4-Addresse, die von extern erreichbar ist aber ich kann natürlich die IPv6-Adresse als Gegenstelle für einen VPN-Client nutzen. Es gibt von AVm einige gute Beschreibungen zum Einrichten eines VPN mit der Fritz!Box, allerdings funktioniert das aktuell angeblich nur mit öffentlichen IPv4-Adressen


Quelle: https://avm.de/service/vpn/tipps-tricks/vpn-verbindung-zur-fritzbox-unter-apple-ios-zb-iphone-einrichten/

Dann helfen mir die Ratgeber und Anleitungen hier aktuell noch nicht weiter.

Und weil es nicht schon genug ist, scheinen viele VPN-Clients selbst auch noch nicht mit IPv6 arbeiten zu können. Allerdings muss ich mich natürlich schon fragen, wozu man mit IPv6 noch mal ein VPN aufbauen will, den IPv6 enthält schon den Code um die Verbindungen zu verschlüsseln und die Endstellen zu signieren (IPSEC). Insofern ist es wirklich eine kleine Nische, dass jemand IPv6 im WAN hat aber im LAN dann noch mit IPv4 Only herum hampelt.

Da aber auch interne Systeme ja offizielle IPv6-Adressen haben, hindert sie ja niemand daran, einen anderen VPN-Server, Proxy-Server o.ä. in ihrem LAN zu installieren, die mit dem passenden VPN-Client eine Verbindung aufbauen.

Ich habe diesen Weg nicht weiterverfolgt, da ich lieber meine System sauber per IPv6 erreichbar mache oder mit dem Azure App Proxy einen sicheren Weg habe. Wer mag, kann auch auch andere Dienstleister nutzen, die solche Wege bereitstellen.

Office 365/Microsoft 365

Ich bin ziemlich sicher, dass Firmen zumindest eine Internet-Anbindung mit einer öffentlichen IPv4-Adresse haben und nicht über Carrier-grade-NAT auf IPv4-Dienste zugreifen müssen. Aber IPv6 wird immer wichtiger und so ist es für mich schon interessant zu sehen, wie meine Test/Demo-Umgebung auch mit IPv6-Only oder eingeschränkter IPv4-Connectivity funktioniert.

Mit Ausnahme von On-Premises ADFS und etwas Hybrid (Exchange, SfB, SharePoint Search) und Azure-VPN alle anderen Dienste entweder komplett in der Cloud ohne lokale Komponenten laufen oder die Verbindung nur in Richtung Cloud (ADSync, AzureAD-Proxy) aufgebaut werden, habe ich bislang noch keine Einschränkungen feststellen können.

Allerdings habe ich keine Informationen über das NAT-Sizing bei DG zur Umsetzung der IPv4-Adressen von 100.16.x.x -100.127.x.x auf weniger öffentliche IP-Adressen. Ein normaler "Privat-Surfer" hat wenige Verbindungen auf und wer z.B. YouTube, NetFlix und Co schaut oder Internet-Radio hört, kommt mit einem Stream und damit einem IP-Port aus. Aktive Schüler oder Arbeitnehmer im Homeoffice können mit Office 365, Konferenzen, OfficeWebApp, OneDrive, Teams, SharePoint etc. schon deutlich mehr parallele Verbindungen belegen. Leider gibt es meines wissens keine öffentlich zugänglichen Informationen über die Auslegung.

Aber auf der anderen Seite sind meines Wissens alle Office 365-Dienste auch per IPv6 erreichbar. Damit sollten die Clients durchweg IPv6 nutzen. Das sollten Sie z.B. über den Ressourcenmonitor oder per PowerShell einfach mal kontrollieren.

PS C:\> Get-NetTCPConnection | group RemoteAddress -NoElement

Count Name
----- ----
   41 ::
   57 0.0.0.0
    2 107.23.193.11
    2 107.23.240.123
    9 127.0.0.1
    3 13.107.136.9
    1 13.227.223.63
    3 13.69.65.22
    1 192.168.178.10
    1 192.168.178.86
    1 2600:1901:0:bae2::
    4 2603:1026:200:51::2
    4 2603:1026:200:79::2
   15 2603:1026:200:8b::2
    1 2603:1026:206:4::2
    1 2603:1026:207:11d::2
    3 2603:1026:207:131::2
    5 2603:1026:207:14::2
    2 2603:1026:207:14f::2
    1 2603:1026:207:50::2
   21 2603:1026:207:a5::2
    1 2603:1026:207:a6::2
   13 2603:1026:207:a7::2
    7 2603:1026:207:b9::2
    1 2a00:1450:4001:821::200e
    4 2a00:1450:400c:c09::bc
    1 2a01:111:f100:a004::bfeb…
    1 2a02:26f0:c6:2a9::57
    1 40.77.226.250
    1 50.16.34.158
    4 51.105.249.239
    1 52.112.64.17
    2 52.114.128.72
    3 54.173.95.250

Hier sehen Sie tatsächlich einige IPv4-Verbindungen zu Office 365, obwohl es auch IPv6-Adressen gibt. Outlook nutzt aber durchweg IPv6 ausser den Zugriff auf ein Postfach bei Net at Work. Auch Teams nutzt IPv6 aber Skype for Business ist wohl noch IPv4

Insofern sehe ich da keine Gefahr einer "Out of Ports"-Situation beim Carrier Grade NAT.

Nachbarschaft in 100.64.x.x-100.127.x.x

Natürlich habe ich mir auch den IP-Adressbereich von 100.64.0.0 bis 100.127.255.255 genauer angeschaut, Diese Adressen sind ja quasi das private Netz des Providers, welches nie im Internet aber auch nicht in einem lokalen LAN einer Firma genutzt werden sollte. Nur so ist das IP-Routing eindeutig. Das hindert mich natürlich nicht, einmal meine Nachbarn zu betrachten. Es sind aber etwas über 4 Milliarden Adressen (4.194.304 abzüglich Systemadressen).

Wenn ein Nachbar auf seiner Fritz!Box eine IPv4-Veröffentlichung als Fehlkonfiguration betreibt, dann kann sie zwar nicht aus dem Internet aber vielleicht allen anderen Kunden des gleichen Providers abgerufen werden. Meine Fritz!Box hat die 100.75.251.69 und ich habe mit NMAP einfach mein direktes Class-C-Subnetz per PING abgeprüft. Ich habe also keinen "Intense Scan" gestartet sondern nur einen "Quick Scan" über 1024 Hosts. Theoretisch könnte der Provider solche "Querverbindungen" unterbinden und per Access Rule nur den Zugriff auf IP-Adressen im Internet über das Carrier Grade NAT-Device zulassen. Dennoch habe mutmaßlich einige Router gefunden, die per SIP (5060/TCP) über das Glasfaser erreichbar sind.

Da juckt es vielleicht schon mal in den Fingern, diesen Systemen genauer auf die Port zu schauen. Einen "Full Scan" durch alle möglichen IP-Adressen oder einen umfangreichen NMAP-Scan habe ich aber nicht gestartet. Der VoIP-Server der DG lauscht übrigens auf dem Namen dg.voip.dg-w.de, der bei mir auf die Adresse 185.22.44.186 auflöst. Er steht also nicht im 100.64.0.0/15er Netzwerk.

Zwischenstand

Natürlich bringt der Wegfall der öffentlichen IPv4-Adressen durch den Wechsel von Telekom-DSL auf FTTH auch Veränderungen an meiner Umgebung mit sich. Der "normale" Privatanwender wird davon aber gar nichts merken, da er beim Zugriff auf IPv4only-Systeme dann eben zweimal per NAT umgesetzt wird und IPv6 zumindest bei mir funktioniert. Wer seinen Router selbst einrichtet, sollte aber kontrollieren, dass Pv6 wirklich bis zum Client durchgehend konfiguriert ist.

Einschränkungen werden vielleicht die Torrent, eMule, und P2P-Sharingdienste bekommen, sofern sie nur über IPv4 arbeiten. Das doppelte NAT dürfte einige Wege verbauen aber solche Programme sollten auch mit IPv6 arbeiten können.

Wer aber eigene Dienste in seinem "Heimat-LAN" veröffentlichen möchte, z.B. eine Webcam, das eigene NAS (NextCloud/OwnCloud) u.a., und nicht über Programme wie Teamviewer gehen möchte, muss sich etwas mit IPv6 beschäftigen oder einen Port Forwarder oder Proxy-Service nutzen.

Mein Tipp: Beschäftigen Sie sich mit IPv6 im Netzwerk

Ich habe bislang leider noch keine Aussage gefunden, wie statisch der /56er IPv6-Subnetz mir zugeordnet bleibt.

Weitere Links