172.28.128.1 – wo kommt das elende Ding her?

Hallo Büro! Ist ja schon zwei, drei Wochen her ... Computer, aufwachen! Ah, Windows. Und herzlich Willkommen WireGuard. Servus Heimnetz ..., öhm, Heimnetz? Internet? Nun, dann halt hallo Laptop und Ubuntu? WireGuard, ja. Heimnetz, nein. Dafür aber eine 171.28.128.1. Aaaargh ...

Ich bin kein Fan von Büros, aber da hier seit März 2024 saniert wird, muss ich ausweichen. Und da brauche ich Zugriff aufs Heimnetz, auf Dateien, Shares, Server-Dienste, Medien. Okay, Medien sind optional, das geht ja heute auch anders 😉

Und faul wie ich bin, habe ich, trotz Bedenken bezüglich der Sicherheit, auf das fancy neue WireGuard gesetzt. Bis September hat das gut geklappt, völlig problemlos. Windows-Tower geht online, Linux-Laptop ebenfalls, Maus und Tastatur können Dank Input Leap für beide Geräte genutzt werden. Meine Arbeitsdateien sind da und vor allem: Mein Server mit, unter anderem, Checkmk.

Und bevor nun alle aussteigen, die mein persönliches Gejammer gar nicht juckt: Die Verbindung ins Heimnetz geht nicht meht - und die Lösung kommt noch. Es ging nicht mit WireGuard, nicht mit VPN, gar nicht. Eine Reise beginnt ... Nun, zunächst eine wörtliche, ich durfte nach Hause fahren.

Nicht weiter drum gekümmert, ein paar Tage später wieder im Büro - und nein, Problem hat sich nicht erledigt. Nicht so wild, diesmal geht's auch so. Aber nun war klar: Das Problem bleibt, und muss weg.

172.28.128.1 WtF?

Daheim erstmal das Übliche: Fritzbox-Einstellungen prüfen, check. Fritzbox neustarten, check. WireGuard-Verbindung neu erstellen, check. Nope.

Dann habe ich in Checkmk einen Parent-Scan durchlaufen lassen: Der Scan durchsucht das Netzwerk und schaut, welche Hosts hinter anderen Hosts liegen. Warum ist jetzt egal. Wenn es nun Hosts in Checkmk gibt, die keine IP haben, sucht das Ding über den Router/die Fritzbox und findet dahinter in der Regel das Gateway des ISPs (Internet Service Provider), sowas wie ip-core-maw2-ae30.netcologne.de (81.173.192.77).

Bei mir wurde aber 172.28.128.1 (172.28.128.1) gefunden. Nun ist der 172er-Adressbereich für private Netzwerke vorgesehen. Wo kütt dat her? Und hat das was mit dem Problem zu tun?

Gedanke 1: Virtualisierung

Der Gedanke lag nahe, dass irgendein virtuelles Netzwerkgerät dahinter steckt. Und irgendeine obskure Routing-Einstellung. Und hier laufen einige echte Rechner, einige VMs, einige Container, teils Container in VMs auf vergessenen Raspis ...

Nach langer Suche: Nüschts. Zwar habe ich durchaus allerlei virtuelle Netzwerkschnittstellen gefunden, aber alle inaktiv oder mit anderen Adressbereichen. Schade. Übrigens: ChatGPT hielt das für eine plausible Idee.

Gedanke 2: Doch nicht der Switch, oder?

Ich habe hier einen Cisco-Switch laufen, der ein wenig mehr kann, als nur eine LAN-Buchse zu multiplizieren. Vielleicht habe ich da irgendwelche Routen eingetragen? Zumal noch ein zweiter privater Netzwerkbereich läuft, den ich mal für diesen Artikel eingerichtet habe.

Zumindest keine große Zeitverschwendung: Auch wenn die Cisco-Dinger verdammt komplex sind, war nach fünf Minuten klar, dass das Problem auch hier nicht zu finden ist.

Gedanke 3: Die Fritze kann es nicht sein ...

Die Fritzbox wurde ewig nicht verändert. Sie wurde neu gestartet. Alle Einstellungen überprüft. Vielleicht irgendwas Internes? Fand ChatGPT wieder mal plausibel (überhaupt findet es so ziemlich alles toll, was ich frage ...) - konnte am Ende aber selbst mit der KI-typischen Fantasy nichts Plausibles erfinden.

Aber der dumme Mensch (aka Ich) entsann sich ... da war doch was ... genau, die verdammte fritz.box/support-Seite. Warum ist das Tool nicht über die GUI erreichbar? Was für ein Quatsch. Jedenfalls ließ sich dort der detaillierte Log herunterladen.

115.839 Zeilen ist das Teil lang. Was würde ich nur ohne ChatGPT tun 😉 Das ist doch die Stärke der KI, ein überschaubarer Text mit standardisierten Informationen zu einem gut dokumentierten technischen Thema.

Aber ich musste kitzeln und kitzeln ... Erst kam viel Bockmist, immerhin aber ein Vorkommen der 172.28.128.1. Internes Routing? Fritz-eigenes Warum-auch-immer-Pseudonetz? Nope.

Dann kam etwas Plausibles, ein weiterer Gedanke ... Okay, nicht ganz so fix. Zwischenzeitlich habe ich einen Menschen mit tiefergehenden Netzwerkkenntnissen befragt, der zumindest ein paar weitere Stichworte liefern konnte. Das reicht meist.

Gedanke 4: DS-Lite und CG-NAT

Puh, Netzwerktechnik ... Ich mache es kurz: Wir haben heute im Internet IPv4- und IPv6-Adressen. Und der Krempel, der dafür sorgt, dass das mit beiden funzt, schimpft sich Dual Stack. Echte IPv4, echte IPv6, alles gut.

Aber IPv6 gibt es, weil IPv4-Adressen knapp werden - und was knapp ist, kostet. Also stellen einige ISPs auf Dual Stack Lite um. Da bekommt man, standardmäßig, keine echte IPv4-Adresse mehr. Stattdessen wird Euer Anschluss eher wie ein Rechner innerhalb eines privaten (Heim-)Netzwerks verwaltet: NAT (Network Address Translation) sorgt dann dafür, dass Aufrufe von etwa Webseiten aus dem Heimnetz ohne echte IPv4-Adresse funktionieren - so wie das auch bei virtuellen Maschinen, manchen Routern etc. erledigt wird.

Und da das Ganze beim Anbieter läuft, nennt sich das Carrier-grade NAT (CG-NAT).

Das würde Probleme wie IPs erklären. Lösungsansatz: WireGuard über IPv6. Yada Yada Yada ... Lösungsansatzauflösung: Nope.

Fun Fact: An diesem Punkt habe ich aus lauter Verzweiflung eine alte IPsec-VPN-Verbindung vom Handy aus probiert - und das verdammte Ding funktioniert ... Glücklich? Mitnichten! Denn eigentlich sollte WireGuard via IPv6 funktionieren, IPsec-VPN via IPv6 jedoch nicht - aber es ist umgekehrt ...

Ist aber auch alles egal, denn: Der erstaunlich gute Support von NetCologne hatte dann binnen eines Tages auf meine Anfrage geantwortet: Nein, echter Dual Stack, kein Lite, kein CG-NAT.

Naja, immerhin was gelernt.

Die beste Quelle blieben aber Fritzbox-Logs: Daten-Messies sind die Größten!

Gedanke 5: Früher war alles besser ...

Ja, schwachsinniger Gedanke, so allgemein. Aber hier: Mein messiemäßiger Download-Ordner hatte noch eine alte Log-Datei intus, aus rosigen Zeiten, als die VPNs noch gülden schienen.

Also die Dateien in Notepad++ verglichen, ChatGPT gefüttert - und wieder kamen im wahrsten Sinne des Wortes fantastische Erklärungen aus der KI gepurzelt. So meinte das Ding zum Beispiel, die Log-Dateien würden zahlreiche Verbindungsabbrüche und obskure Einstellungen zeigen - klarer Hinweis auf DS-Lite oder verkorksten Dual Stack ... Natürlich alles Quark. Es waren nur zwei Abbrüche und für die Obskuritäten hatte ich selbst gesorgt.

Auch wenn das früher tatsächlich besser war, geholfen hat's auch nicht. Aber man muss kein Daten-Messie sein, um zu vergleichen ...

Aber vorher, ein Einschub:

Interlude: Problem? Weg.

Nachdem klar war, dass es sich nicht um ein DS-Lite-Problem handelt, habe ich nochmal die Fritzbox bemüht: Eigentlich macht das Ding automatisch Updates, aber wer weiß ... Und ja, ein manueller Update-Anstoß hat von Version 8.03 auf Version 8.20 aktualisiert.

Und dann das verdammte Wunder: WireGuard läuft wieder. Auf der Fritzbox hat sich also nichts verändert, aber ein Update hat geholfen. Bei NetCologne gibt es eine echte IPv4-Adresse, wie immer. Problem weg, Verwirrung umso größer.

Zurück zu den (Nicht-)Messies.

Gedanke 6: Fu*;:ng Glasfaserkram?

Nun gut, der Vergleich eines alten Logs aus guten Zeiten mit dem aktuellen Log aus miesen Zeiten half nicht. Aber da nun wieder alles lief: Den Log aus miesen Zeiten mit dem aktuellen aus Wieder-Gut-Zeiten vergleichen.

Also nochmal ChatGPT gefüttert und die beiden Logs durch das Vergleichswerkzeug von Notepad++ gejagt, Reddit durchforstet, Netzwerkwissenslücken mit Stackoverflow gestopft, bis ...,

... ja bis dann endlich eine weitere Option den Weg ins Licht fand: Cable Modem Termination System (CMTS). Heure ..., vielleicht zu früh.

Ein CMTS ist der Verteilerkasten, der das (TV-)Kabelnetz ans Internet anschließt. Und das würde Sinn ergeben: Der Verteilerkasten schließt zigtausend Haushalte ans Netz - im Grunde ein (Netzwerker werden mich jetzt vielleicht steinigen wollen) Router in Stadtviertelgröße, aus dessen Sicht die Haushalte ein privates Heimnetzwerk sind und das Internet das ISP-Gateway.

Und der traceroute-Auszug passt auch dazu (hätte wohl aber auch auf das DS-Lite-Szenario gepasst):

traceroute tutonaut.de
traceroute to tutonaut.de (37.221.194.125), 30 hops max, 60 byte packets
 1  _gateway (192.168.178.1)  0.857 ms  2.481 ms  2.730 ms
 2  172.28.128.1 (172.28.128.1)  13.917 ms  15.603 ms  17.091 ms
 3  ip-core-maw2-ae30.netcologne.de (81.173.192.77)  18.754 ms  23.035 ms  24.744 ms
 ...

Erst kommt das Gateway meines Heimnetzwerks, also die Fritzbox mit ihrer Standardadresse. Dann folgt das CMTS mit 172.28.128.1. Dann kommt dessen Gateway, also der NetCologne-Zugangspunkt.

Aber es wäre nicht die erste passende, aber nicht zutreffende Erklärung ...

Finale mit NetCologne

Also nochmal NetCologne-Support gefragt. Und ich muss dazu sagen: Sie hatten schon ziemlich fix auf eine ziemlich technische Frage ziemlich kurz und korrekt geantwortet - Danke dafür. Also habe ich zurück geschrieben, erklärt, dass ein Firmware-Update Erlösung gebracht hat, ich aber dennoch neugierig sei: Könnte die 172.28.128.1 zum privaten Adressbereich des CMTS gehören? Immerhin wird bei uns saniert, in den nächsten Wochen kommt Glasfaser in die Wohnungen ...

Und wieder: Umgehende Antwort, samt Bestätigung - ja, es ist das elende CMTS und ja, es liegt an Fibre-To-The-Home-Arbeiten (und übrigens, HIER sind unsere tollen Tarife ...).

Und somit: Mein Problem ist durch die Kombination von (neuem) CMTS und Router-Firmware und/oder -Konfiguration entstanden.

CMTS, DS-Lite, CG-NAT ...

Und damit am Ende auch noch was kompakt Nützliches steht, hier ein paar Learnings, wie man so schön sagt (Lehren zu ziehen reicht wohl nicht mehr, learnte ich).

Wenn VPN-Verbindungen plötzlich, ohne neue Konfigurationen Eurerseits, nicht mehr funktionieren,

• lohnt sich ein Router-Update,
• bietet sich ein traceroute an,
• könnte es an DS-Lite liegen,
• könnte es an IPv6-/IPv4-Konfigurationen des Routers liegen,
• könnte es an einem CMTS/dem Glasfaserausbau liegen,
• solltet Ihr Log-Dateien des Routers ausgraben und
• im Zweifel ChatGPT damit füttern,
• zunächst Euren ISP fragen und dann
• gegebenenfalls nach Router-Bugs suchen,
• alternative Fernzugänge probieren und natürlich
• immer wieder ChatGPT mit neuen Stichworten füttern - und die Antworten bestenfalls als Assoziationen aus dem digitalen Bauch verstehen ...

Und noch ein kleines Gelerntes (na, dann doch lieber Learning ...): Menschen mit Netzwerkfachwissen wissen oft gerade deshalb nicht viel über popelige Consumer-Endgeräte wie die Fritzbox 😉

Und wenn dann Mensch wie KI meinen, man solle doch mal stundenlang ARP-Caches, Routing-Tabellen und dergleichen durchforsten ... dann wünscht man sich irgendwie das Piiiieep-Piep-Pieeeeeeeep-Bssssssssss-Stttttt-Bieeeep eines guten alten US-Robotics-56k-Einwahlmodems zurück. Früher war alles besser, am Popo.

Wer bis hierhin wehleidiges Netzwerkgesülze ertragen hat, verdient etwas Entspannung - ommmmmm

Quelle: Hintergrund des Einstiegsbilds.