Häufige DDNS-Subdomains können zu einer Drosselung des Telekom-Breitbanddienstes führen

Tags:
Categories:

IPv6-Verbindungsabbruch und Tunnel-Fehlschläge haben mich drei Monate lang gequält, endlich habe ich die Ursache gefunden und teile sie mit euch.

Erster Beitrag zur IPv6-Verbindungsabbruch-Problematik

IPv6 war bisher immer normal erreichbar, ohne jegliche Konfigurationsänderungen, und alle Geräte verfügten über eine eigenständige IPv6-Adresse, aber IPv6-Netzwerke waren nicht erreichbar.

curl 6.ipw.cn lieferte keine Rückmeldung, ping6 und traceroute6 2400:3200::1 brachen ab.

Der Modem im Bridge-Modus, der Router kann die IPv6-Adresse des Routers abrufen, das ist die Adresse für den Zugriff auf IPv6.

Man erhält das /56 Präfix, die Geräte hinter dem Router erhalten alle eine zugewiesene IPv6-Adresse 240e:36f:15c3:3200::/56, können jedoch keine Verbindung zu IPv6-Websites herstellen.

Vermutung: Der Betreiber hat die Route für 240e:36f:15c3:3200:: nicht eingerichtet, kann jedoch nicht bestätigt werden.

Ein Nutzer vermutete, dass es durch zu viel Upload-Traffic für PCDN verursacht wurde, aber der Upload-Traffic ist gering und PCDN ist nicht aktiviert.

Es könnte auch durch Cloudflare- und Aliyun-ESA-Reverse-Proxy verursacht sein.

Zweiter Beitrag zur Bestätigung der direkten Ursache

Bestätigt, dass Telekom-Betreiber in bestimmten Regionen bei vielen eingehenden IPv6-HTTP/HTTPS-Verbindungen den Service drosseln, was sich äußert in:

  • Falsches IPv6: IPv6 kann das /56 Präfix erhalten, die IPv6-Zuweisung aller Geräte ist normal, aber tracert fehlt an Routen, wodurch IPv6 tatsächlich nicht ins Internet gelangen kann.
  • Falsches Tunneling: Tailscale-Verbindungstest zeigt Direktverbindung an, aber Latenz extrem hoch, tatsächliche Geschwindigkeit extrem langsam.

Cloudflare/Aliyun-ESA-Reverse-Proxy deaktivieren, nach mehreren Router-Neustarts kann IPv6 und echte Direktverbindung wiederhergestellt werden.

Trotz Deaktivierung des Reverse-Proxys weiterhin Verbindungsabbruch

Auch nach Deaktivierung des Reverse-Proxys, Deaktivierung von Cloudflare und Aliyun-ESA-Back-to-Origin tritt gelegentlich ein Verbindungsabbruch auf, der längere Zeit andauert.

Möglicherweise gibt es eine Domain-Leckage oder jemand nutzt häufige Subdomains zum Scannen, was zu anhaltenden HTTP-Angriffen führt.

Deaktivierung der DDNS-Domain-Auflösung, nach einiger Zeit normalisiert sich IPv6 wieder, Tailscale-Tunnel-Direktverbindung ist ebenfalls normal.

Seitdem gab es keine weiteren Verbindungsabbrüche.

Endgültige Lösung

Daher empfehle ich, keine häufig verwendeten DDNS-Subdomains zu verwenden, wie:

  • home.example.com
  • nas.example.com
  • router.example.com
  • ddns.example.com
  • cloud.example.com
  • dev.example.com
  • test.example.com
  • webdav.example.com

Einige davon habe ich bisher ständig genutzt, möglicherweise wurde ständig gescannt, was zu einer Drosselung des Telekom-Breitbanddienstes führt, sodass öffentliches IPv6 nicht normal genutzt werden kann und Tunnel-Direktverbindungen ständig fehlschlagen.

Jeder weiß, wie wichtig das Verbergen der IP im Bereich der Netzwerksicherheit ist. Hier zusätzlich der Schutz der für DDNS verwendeten Domain empfohlen, da sie im Grunde ebenfalls die IP preisgibt.

Aber was tun, wenn man dennoch den Zugriff auf Dienste benötigt?

Hier sind zwei praktische Lösungen:

  • Back-to-Origin-Lösung, eine Art Relay-Service, bei dem die Anfrage zuerst zum VPS und dann zum Home-Server weitergeleitet wird. Aufgrund der Umleitung beeinflusst dies Latenz und Bandbreite.
  • DDNS-Lösung, eine Direktverbindungslösung, die ein viel besseres Verbindungserlebnis bietet, empfohlen. Bei privater Nutzung überschreitet man normalerweise nicht das Verbindungsanzahl-Limit, aber wenn die Domain öffentlich gemacht wird, können Bots die Verbindungsanzahl in kürzester Zeit hochtreiben.

Back-to-Origin-Lösung (Reverse-Proxy)

Cloudflare Tunnel

Verwenden Sie Cloudflare Tunnel, damit nicht wie bei normalem Back-to-Origin Dutzende bis Hunderte von IPs den Zugriff ausführen.

Tailscale oder ZeroTier

Einrichten eines privaten VPN mit einem VPS davor, Zugriff auf interne Netzwerkdienste über VPN, wodurch zu hohe gleichzeitige Verbindungen vermieden werden.

DDNS-Lösung (Direktverbindung)

Öffentliche Auflösung

Generieren Sie zufällige Zeichenfolgen wie GUID für die DDNS-Domain. Obwohl sie kaum zu merken sind, hat dies bei persönlicher Nutzung kaum Auswirkungen, kann jedoch individuell bewertet werden.

Private Auflösung

Verwendung eines persönlichen DNS-Dienstes wie:

Für DDNS-Auflösung.

So können nur Personen, die mit dem persönlichen DNS-Server verbunden sind, die benutzerdefinierte IP-Auflösung für die angegebene Domain abrufen.

Bei dieser Lösung können häufig verwendete DDNS-Domains genutzt werden, aber die eigene DNS-Server-Adresse sollte nicht preisgegeben werden.

Zusatz

Es kursieren Gerüchte, dass die Verwendung von speedtest als Subdomain eine mysteriöse Beschleunigung bewirkt.