Was ist CGNAT? Warum Port Forwarding fehlschlägt und wie man es umgeht

Wenn eine korrekte Portweiterleitung trotzdem nirgendwo hinführt

Ihr NAS öffnet sich normalerweise zu Hause. Der Service läuft, und die Portweiterleitung zeigt auf die richtige lokale Adresse. Dann schalten Sie Ihr Telefon auf Mobilfunkdaten um, versuchen es erneut und erhalten ein Timeout. Das gleiche Muster kann einen Home-Game-Server, VPN-Server, CCTV-Feed oder selbstgehostete App beeinflussen.

Die schnelle Antwort ist, dass die Regel zwar korrekt sein kann, aber hinter einer anderen Grenze liegt. Bei Carrier-Grade NAT (CGNAT) teilt der ISP öffentliche IPv4-Adressen und trifft die erste eingehende Entscheidung upstream. Sie kontrollieren die Regel auf Ihrem Home-Router, aber eine neue Internetverbindung erreicht ihn nie, es sei denn, der Übersetzer des Providers weiß, wohin er sie senden soll.

Das beweist nicht, dass CGNAT verantwortlich ist; lokale Probleme können identisch aussehen. Der Service kann nur auf localhost lauschen, oder eine Host-Firewall kann ihn blockieren. Eine Router-Regel kann das falsche TCP/UDP-Protokoll verwenden oder eine veraltete Zieladresse haben, während ein zweiter lokaler Router eine weitere Grenze hinzufügen kann. Identifizieren Sie zuerst die Grenze, unterscheiden Sie CGNAT von gewöhnlichem und doppeltem NAT, und wählen Sie dann einen Workaround für den Zugriff, den Sie benötigen.

Quick Keywords: What CGNAT Is and Why ISPs Use It

Diese Begriffe reichen aus, um zu verfolgen, wo die fehlende Verbindung unterbrochen wird.

RFC 6888 definiert ein Carrier-Grade NAT (CGN)—auch Large-Scale NAT (LSN) genannt—als eine Provider-seitige Funktion, die mehreren Abonnenten ermöglicht, eine IPv4-Adresse zu teilen. Abonnenten verwalten es nicht. „Carrier-grade” beschreibt Platzierung und Skalierung, nicht höhere Qualität.

Die Eigentumsgrenze sieht so aus:

YOU CONTROL                         ISP CONTROLS
device → home router / NAT → ISP CGNAT → shared public IPv4 → internet

Der Home-Router steuert das lokale Netzwerk des Kunden. Das CGN des ISP ordnet Abonnentenverbindungen seiner gemeinsamen öffentlichen Adresse zu. Normales Surfen funktioniert immer noch, weil ein Gerät das Gespräch startet und beide Übersetzungsebenen die Antwort verfolgen können.

Stellen Sie sich die öffentliche IPv4-Adresse als Straßeneingang eines Gebäudes vor und einen Port als Türklingel. Ihr Router ist der innere Empfangstresen. CGNAT fügt einen äußeren Tresen hinzu, der von vielen Kunden geteilt und vom ISP betrieben wird. Ports helfen diesem äußeren Tresen, aktive Gespräche zu verfolgen; sie geben jedem Kunden keine permanente Kontrolle über jede Türklingel auf der gemeinsamen Adresse.

ISPs verwenden dieses Design, weil global routbarer IPv4-Raum begrenzt ist und der IPv6-Übergang unvollständig bleibt. Regionale freie Pools sind praktisch erschöpft, obwohl bestehende Adressen immer noch übertragen und wiederverwendet werden können. CGNAT bewahrt IPv4-Kompatibilität durch Teilen knapper Adressen. IPv6 bietet den größeren langfristigen Adressraum, ist aber nicht überall Ende-zu-Ende verfügbar.

NAT vs Double NAT vs CGNAT

Die entscheidenden Fragen sind nicht „Wie viele Boxen sehe ich?” sondern „Wo findet die Übersetzung statt und wer kann sie ändern?”

📝 Hinweis: CGNAT führt oft zu zwei IPv4 NAT-Ebenen, wenn ein Home-Router vorhanden ist, aber „CGNAT” benennt die vom ISP betriebene Funktion, während „Double NAT” nur die Topologie beschreibt.

Diese Eigentumsunterscheidung ändert, was Sie beheben können. Mit zwei lokalen Gateways können Sie möglicherweise den Bridge/AP-Modus verwenden oder beide Ebenen konfigurieren. Ein Provider-Translator liegt außerhalb dieser Kontrollen, und einige CGNAT-Designs beinhalten überhaupt keinen zweiten vom Kunden betriebenen Translator.

Konsolenbeschriftungen wie „offen”, „moderat” oder „striktes NAT” sind separat. Sie fassen das Konnektivitätsverhalten für diese Plattform zusammen; sie identifizieren nicht, wer die Translator besitzt, oder beweisen, dass CGNAT vorhanden ist.

Warum Port Forwarding hinter CGNAT fehlschlägt

Ausgehender Datenverkehr funktioniert, weil jeder Translator State erstellt: einen temporären Datensatz, der einen internen Flow mit einer externen Adresse und einem Port verknüpft. Wenn Ihr Gerät eine Anfrage startet, zeichnen der Home-Router und das ISP-CGN diese auf, sodass entsprechende Antworten zurückkehren können.

Eine neue eingehende Verbindung hat keinen solchen State. Sie erreicht zuerst die gemeinsame öffentliche IPv4 des ISP, wo das CGN keine abonnentspezifische Zuordnung hat:

OUTBOUND WORKS
device → home NAT [state created] → ISP CGN [state created] → internet
device ← home NAT [state match]   ← ISP CGN [state match]   ← reply

NEW INBOUND CONNECTION STOPS
outside user → shared public IPv4 → ISP CGN
                                      X — no subscriber mapping
                                      home router is never reached

Deshalb schlägt CGNAT Port Forwarding fehl. Ihre Home-Router-Regel mag gültig sein, aber sie gehört zum inneren Empfangstresen. Das Ändern der Besucherliste dieses Tresens kann dem gemeinsamen äußeren Tresen des ISP nicht mitteilen, welcher Abonnent einen unerwarteten Besucher erhalten sollte. Das Paket erreicht Ihre Regel nie.

Ein Reverse Proxy auf der unerreichbaren Home-Seite ändert daran nichts. Er kann Anfragen organisieren, nachdem sie ankommen, aber er kann die fehlende Route nicht erstellen. Ein Reverse Tunnel – oder ein Proxy oder Relay an einem erreichbaren Edge – ist anders, weil die private Seite zuerst einen ausgehenden Pfad etabliert.

So erkennen Sie, ob Sie hinter CGNAT sind

Verwenden Sie die Hinweise in dieser Reihenfolge:

1. Deaktivieren Sie VPNs und Proxys. Schalten Sie alles aus, das die öffentliche Adresse ändert, von der aus Ihr Datenverkehr zu stammen scheint.
2. Identifizieren Sie das ISP-seitige Gateway. Verwenden Sie den Router oder das Modem, das direkt mit dem Anbieter verbunden ist, nicht einen zweiten Router weiter in Ihrem Netzwerk.
3. Vergleichen Sie die beiden Adressen. Notieren Sie sich die WAN– oder Internet-IPv4-Adresse dieses Gateways und verwenden Sie gleichzeitig einen externen Dienst, um Ihre öffentliche IPv4 anzuzeigen.

❗ Wichtig: Eine Nichtübereinstimmung zwischen der WAN- und der öffentlichen Adresse beweist, dass eine Upstream-Übersetzungsgrenze vorhanden ist, nicht automatisch, dass es sich um CGNAT handelt. Treffen Sie diese Schlussfolgerung nur vom Gateway, das direkt mit dem ISP verbunden ist.

4. Interpretieren Sie das Ergebnis. Verwenden Sie diese Signale zusammen:
   • Eine WAN-Adresse in 100.64.0.0/10—100.64.0.0 bis 100.127.255.255—ist ein starkes CGNAT-Indiz. RFC 6598 reserviert diesen nicht global routbaren Shared Address Space für die Nutzung durch Anbieter; es ist kein RFC 1918 privater Adressraum.
   • Eine Adresse in 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 zeigt auch eine nicht öffentliche WAN an, kann aber zu einem anderen lokalen Router gehören.
   • Unterschiedliche WAN- und öffentliche Adressen deuten auf Upstream-Übersetzung hin. Übereinstimmende global routbare Adressen machen gewöhnliches IPv4 CGNAT auf diesem Pfad viel weniger wahrscheinlich.
5. Schließen Sie lokale Ursachen aus. Bevor Sie es als CGNAT bezeichnen, überprüfen Sie, dass:
   • Der Dienst auf seiner LAN-Adresse lauscht, nicht nur auf localhost.
   • Die Host-Firewall den beabsichtigten Port und das Protokoll zulässt.
   • Die Router-Regel auf die aktuelle interne Adresse und die richtige TCP/UDP-Wahl abzielt.
   • Ein zweiter lokaler Router keine weitere Übersetzungsebene hinzufügt.
   • Der Test von mobilen Daten oder einem anderen wirklich externen Netzwerk stammt.
6. Bestätigen Sie mit dem ISP. Traceroute kann die Diagnose unterstützen, wenn gemeinsame oder private Hops über das Home-Gateway hinaus erscheinen, aber verborgene Hops machen es unklar. Fragen Sie den Anbieter, ob die Leitung CGNAT verwendet und ob eine dynamische oder statische öffentliche IPv4 verfügbar ist.

Was CGNAT beeinflusst – und was normalerweise nicht

Diese Aufteilung zwischen ausgehend und eingehend bestimmt, was Benutzer bemerken. Browsing, Streaming, Downloads und die meisten App-Clients funktionieren normalerweise einwandfrei. Probleme entstehen, wenn ein externes System eine neue Verbindung zu etwas hinter der Carrier-Grenze starten muss.

Direktes IPv4-Hosting und Fernzugriff benötigen daher einen anderen erreichbaren Pfad. In einem privaten Netzwerk betrifft dies den Zugriff auf ein NAS, ein CCTV-System oder ein internes Dashboard. Öffentliche Websites, Webhook-Empfänger und Game-Server haben die gleiche Anforderung für eingehenden Datenverkehr. Ein VPN-Client funktioniert normalerweise, weil er sich nach außen verbindet. Ein Home-VPN-Server ist anders, weil Remote-Benutzer die Verbindung starten, daher benötigt er erreichbaren eingehenden Datenverkehr, kompatibles IPv6 oder einen Endpunkt auf einem Relay oder öffentlichen Host.

Peer-to-Peer-Gaming, Voice und Dateifreigabe sind weniger vorhersehbar. Einige Anwendungen finden eine direkte Route, während andere ein Relay durch einen erreichbaren Vermittler nutzen. Ein Relay kann die Konnektivität auf Kosten erhöhter Latenz bewahren. Wenn die Traversierung fehlschlägt, kann die Anwendung restriktives NAT melden oder die Verbindung ablehnen. RFC 7021 dokumentiert diese Druckpunkte, ohne universelles Versagen zu implizieren.

Die gemeinsame Nutzung einer IPv4-Adresse kann unabhängige Abonnenten in einem Ruf zusammenführen. Das Verhalten eines Benutzers kann dazu führen, dass andere Abonnenten mehr CAPTCHAs oder Ratenlimits sehen. Die gemeinsame Adresse kann auch auf Blocklisten landen, Beschränkungen für gleichzeitige Anmeldungen auslösen oder grobe Geolokalisierung erzeugen. Ein gemeinsamer oder sich ändernder Residential-Exit erschwert Business-Allowlists weiter, die einen stabilen Endpunkt erwarten.

📝 Hinweis: Das standardmäßige Blockieren von unerwünschtem eingehenden IPv4-Datenverkehr kann versehentliche Exposition reduzieren, aber CGNAT ist keine Firewall und ersetzt nicht Authentifizierung, Updates, TLS oder Zugriffspolitik.

CGNAT stoppt keinen böswilligen ausgehenden Datenverkehr. Es sichert keine Anwendungen, die über einen anderen Pfad verfügbar gemacht werden, und kontrolliert nicht, wer sich anmelden kann. Ein Tunnel, eine öffentliche IP oder eine IPv6-Route erfordert immer noch bewusste Sicherheitskontrollen.

Fünf Wege, um CGNAT zu umgehen

Die fünf Optionen lösen verschiedene Zugriffsprobleme. Private Meshes, verwaltete Tunnel und VPS-Relays teilen ein nützliches Muster: Die private Seite verbindet sich zuerst nach außen.

private service → outbound mesh / tunnel link → reachable edge ← outside user

In der Gebäudeanalogie erhalten Sie entweder einen nutzbaren Straßeneingang oder halten eine Verbindung zu einem Eingang anderswo.

📝 Hinweis: „Umgehen” ist eine Kurzform. Diese Ansätze deaktivieren das Carrier NAT nicht; sie erhalten einen anderen öffentlichen Edge, nutzen End-to-End IPv6 oder etablieren einen nach außen erstellten Pfad.

Beginnen Sie mit der Tabelle und nutzen Sie dann die Details unten für die Kompromisse, die für Ihr Setup wichtig sind.

1. Fragen Sie den ISP nach einer öffentlichen IPv4

Für allgemeinen eingehenden IPv4-Verkehr ist dies normalerweise die einfachste Option, wenn der ISP sie anbietet. Eine dynamische öffentliche IPv4 funktioniert mit aktualisiertem DNS. Wählen Sie eine statische öffentliche IPv4 für stabile Allowlists, Einträge oder VPN-Endpunkte. Überprüfen Sie Verfügbarkeit und Kosten und sichern Sie alle direkt exponierten Dienste.

2. Verwenden Sie native IPv6

IPv6-Verkehr vermeidet IPv4 CGNAT. Der direkte Zugriff erfordert ein globales Präfix, einen IPv6-Listener, geeignete Firewall-Regeln, korrektes DNS wo nötig und IPv6 auf der Remote-Seite. Es hilft nicht IPv4-only Clients oder exponiert einen Dienst automatisch.

3. Erstellen Sie ein privates Mesh

Ein Mesh VPN wie Tailscale eignet sich für vertrauenswürdige Benutzer und Geräte, die authentifizierte Client-Software ausführen können. Es versucht direkte Verbindungen, kann dann aber auf einen Peer oder DERP-Relay mit einigen Leistungskosten zurückfallen. Es ist nicht für anonyme Besucher oder öffentliche Webhooks gedacht.

4. Veröffentlichen Sie über einen verwalteten ausgehenden Tunnel

Ein Dienst wie Cloudflare Tunnel verbindet den Origin nach außen mit einem Provider-Edge. Dies funktioniert gut für Web-Apps, APIs, Demos und kontrollierten privaten Zugriff. Öffentliche HTTP-Besucher benötigen möglicherweise keinen Client, während private oder nicht-Web-Modi möglicherweise Provider-Software erfordern. Protokollunterstützung, Identität, Limits und Edge-Verfügbarkeit bleiben Provider-Abhängigkeiten.

5. Verwenden Sie einen VPS als öffentlichen Edge – oder verschieben Sie den Workload

Ein VPS kann Verkehr durch einen ausgehenden Tunnel von zu Hause relayieren oder die Anwendung direkt hosten, wenn sie keine Home-LAN-Daten oder Hardware benötigt. Dies bietet einen stabilen Endpunkt und breite TCP/UDP-Kontrolle. Sie sind verantwortlich für Sicherheit, Überwachung, Tunnel-Zuverlässigkeit, Bandbreite, Missbrauchsbehandlung und zusätzliche Latenz. Ein angemessen ausgewählter AlexHost VPS kann diese Rolle erfüllen, vorbehaltlich seiner öffentlichen Adressierung und Netzwerkrichtlinie.

Welche Option passt zu Ihrem Use Case?

Wählen Sie die Architektur, indem Sie vier Fragen der Reihe nach stellen:

1. Ist der Zugriff auf vertrauenswürdige Personen und Geräte beschränkt oder öffentlich zugänglich?
2. Kann jedes verbindende Gerät Client-Software installieren und sich authentifizieren?
3. Ist der Service webbasiert oder erfordert er beliebiges TCP/UDP-Verhalten?
4. Bevorzugen Sie verwaltete Bequemlichkeit oder Kontrolle über das öffentliche Gateway?

Für vertrauenswürdige NAS, CCTV oder Admin-Zugriff verwenden Sie ein Mesh VPN, wenn Benutzer Client-Software installieren können. Für öffentliche Web-Endpunkte und Webhooks verwenden Sie einen verwalteten Tunnel oder öffentliches Hosting. Verschieben Sie die Workload, wenn sie das Heim-LAN nicht benötigt.

Für öffentliches TCP/UDP verwenden Sie eine öffentliche IPv4 vom ISP, einen VPS Edge oder IPv6, wenn alle Clients dies unterstützen. Game-Hosting ist titelspezifisch: Überprüfen Sie sein Server-Modell, Traversal-Unterstützung und Protokolle. Ein generischer Tunnel kann kein besseres Console-NAT-Label garantieren.

Ein öffentlicher VPN-Endpunkt benötigt öffentliche IPv4, funktionierendes IPv6 oder einen VPS-Host. Für geschäftliche Ingress oder Partner-Allowlists wählen Sie stattdessen eine statische Adresse oder ein kontrolliertes Gateway anstelle eines gemeinsamen Residential-Exit.

Häufig gestellte Fragen und Missverständnisse zu CGNAT

Ist CGNAT dasselbe wie Double NAT? Nein. CGNAT bezeichnet ein von einem ISP betriebenes, Multi-Subscriber-NAT. Double NAT bedeutet nur, dass der Datenverkehr zwei Übersetzer durchläuft.

Verlangsamt CGNAT das Internet immer? Nein. Die Leistung hängt mehr vom Provider, der Anwendung und davon ab, ob ein Relay beteiligt ist.

Kann Dynamic DNS CGNAT beheben? Nein. Es verfolgt eine sich ändernde Adresse, kann aber keine Upstream-Zuordnung erstellen. Es hilft, sobald Sie eine erreichbare dynamische öffentliche Adresse haben.

Umgeht ein normales VPN CGNAT? Normalerweise nicht. Es funktioniert nur, wenn der VPN-Dienst Inbound-Forwarding, ein privates Overlay oder einen anderen erreichbaren Einstiegspunkt bietet.

Kann IPv6 es lösen? Ja, wenn beide Seiten IPv6 haben und die Firewall und DNS es zulassen. Es hilft IPv4-only-Clients nicht.

Ist 100.64.0.0/10 privater Adressraum? Es ist spezieller Adressraum, nicht global routbar, Shared Address Space. Es unterscheidet sich von den RFC 1918 privaten Bereichen, die in gewöhnlichen lokalen Netzwerken verwendet werden.

Ist CGNAT eine Sicherheitsfunktion? Nein. Sein Inbound-Verhalten ist keine Sicherheitsrichtlinie. Sie benötigen immer noch Firewall-Regeln, Authentifizierung, Patching, Verschlüsselung und sorgfältige Exposition.

Die Quintessenz: Beheben Sie die fehlende öffentliche Edge, nicht nur den Router

Der öffnende NAS oder Game-Server kann eine korrekte lokale Regel haben und trotzdem ein Timeout auftreten, weil die Verbindung an der ISP-Grenze stoppt. Weitere Router-Änderungen werden einen Pfad nicht beheben, den der Router nie erhält. Beginnen Sie mit dem Publikum: Verwenden Sie ein Mesh für vertrauenswürdigen privaten Zugriff, während öffentlicher Zugriff öffentliche IPv4, funktionierendes IPv6, einen verwalteten Tunnel oder einen kontrollierten Host benötigt. Überprüfen Sie zuerst die Optionen des ISP, und erwägen Sie dann einen AlexHost VPS nur, wenn eine gehostete Workload oder ein Relay zum Design passt.