Was ist meine IP?
Zeigt die für diese Verbindung beobachtete Adresse, IP-Version, Forwarded-Kontext und Request-Metadaten.
NetzwerkÖffentliche IP, NAT und Dual Stack: Welche Adresse gehört dir?
Sobald Router, Provider-NAT, Proxies und zwei IP-Familien im Pfad stehen, gibt es nicht mehr die eine Internetadresse deines Rechners. Ein Dienst sieht die Quelle einer konkreten Verbindung an einem konkreten Netzpunkt — einen Befund über den Weg, keine dauerhafte Identität.
Eine öffentliche IP gehört zum Pfad
Ein entfernter Dienst kann genau eine Sache belegen: die Quelladresse des Pakets, das ihn erreicht hat. Die Seite Was ist meine IP? zeigt diese Adresse, ihre IP-Version und den Request-Kontext, der an diesem Endpoint ankommt. Sie schaut nicht in deinen Laptop, Heimrouter, VPN-Client oder Mobilfunkanschluss. Kam der Browser über 2001:db8::42, sieht ein IPv6-fähiger Dienst diese Adresse. Ging ein anderer Request übersetztes IPv4-seitig als 198.51.100.27 hinaus, meldet der zweite Dienst IPv4. Beide Aussagen können gleichzeitig stimmen.
Lokale Adressen beantworten eine andere Frage. Eine RFC-1918-Adresse wie 192.168.1.34 oder 10.20.4.8 bezeichnet ein Interface innerhalb eines privaten Routingbereichs; eine IPv6-Link-Local-Adresse mit fe80:: reicht nur bis zum lokalen Link. Selbst global geroutetes IPv6 kann pro Gerät mehrere temporäre Quelladressen liefern. Die Interface-Liste einer Anwendung sagt daher nicht voraus, was ein Server sieht. Route, Adressauswahl, Tunnelzustand und Übersetzer legen das erst beim Verbindungsaufbau fest.
NAT schreibt die Verbindung um, nicht den Rechner
In Heim- und Büronetzen ist IPv4 meist übersetzt, weil private Adressen im öffentlichen Internet nicht geroutet werden. Das Gateway ordnet interne Quelladresse und Port einer öffentlichen Adresse samt neuem Port zu, merkt sich diese Abbildung und dreht sie für Antwortpakete um. Tausende parallele Verbindungen können sich deshalb eine öffentliche IPv4-Adresse teilen. Sie bezeichnet genauer den übersetzenden Netzausgang als das Gerät dahinter. Für Diagnose und grobe Policy ist sie nützlich; als Personen- oder Gerätekennung ist sie schwach.
Damit erklärt sich auch, warum Surfen funktioniert, aber neue Verbindungen von außen scheitern. Dem Gateway fehlt eine bestehende Zuordnung zu einem internen Ziel. Port-Forwarding legt sie absichtlich an; UPnP bisweilen weniger absichtlich. Übersetzung ist trotzdem keine Firewall-Garantie: Stateful Filtering und NAT sind verwandte, aber verschiedene Funktionen. Umgekehrt braucht IPv6 gewöhnlich keine Adressübersetzung, gehört aber weiterhin hinter eine Firewall mit bewusst gesetzter Inbound-Policy. „Kein NAT“ bedeutet mögliche Ende-zu-Ende-Adressierung, nicht offene Sockets.
Bei CGNAT sitzt der Übersetzer beim Provider
Carrier-Grade NAT fügt außerhalb deines Anschlusses eine weitere Übersetzungsgrenze ein. Dein Router erhält womöglich eine Adresse aus 100.64.0.0/10 oder einem anderen nicht öffentlichen Bereich, während viele Kunden über einen kleineren Pool öffentlicher IPv4-Adressen ins Netz gehen. Ein Port-Forward am eigenen Router endet am Provider-NAT und macht keinen Dienst erreichbar. Auch Dynamic DNS repariert das nicht: Es veröffentlicht die beobachtete Adresse korrekt, schafft aber keine eingehende Zuordnung. Abhilfe bringen eine echte öffentliche Adresse, natives IPv6 mit passender Firewall oder ein Reverse-Tunnel zu einem kontrollierten Endpoint.
CGNAT macht zudem Reputationsregeln unscharf. Verursacht ein Teilnehmer Missbrauch, kann die gemeinsame Egress-Adresse für alle schlecht bewertet werden. Ein nur nach Quell-IP zählendes Rate Limit fasst fremde Haushalte oder Mobilgeräte zusammen. Logs mit bloßer öffentlicher Adresse unterscheiden Teilnehmer ohne zeitgenaue Port-Zuordnungen des Providers nicht. Vergleiche bei der Diagnose die WAN-Adresse des Routers mit der extern beobachteten Adresse und ordne beide über den CIDR/Subnetz-Rechner ein. Eine Abweichung hinter CGNAT, VPN oder einem weiteren Übersetzer ist ein Hinweis, noch kein Defekt.
Dual Stack liefert regelmäßig zwei richtige Antworten
Ein Dual-Stack-Client kann IPv4 und IPv6 verwenden. DNS liefert möglicherweise A- und AAAA-Records; anschließend wählt der Client einen funktionierenden Pfad, meist mit IPv6-Präferenz und einem zügigen Ausweichen, falls dieser Weg klemmt. Die Wahl gilt pro Ziel, nicht als globaler Schalter. Eine IPv6-fähige Website sieht deine IPv6-Adresse, während eine ältere API, ein IPv4-only-Monitor oder ein unvollständig konfiguriertes VPN Sekunden später IPv4 sieht. Unterschiedliche Browser-Tabs können daher unterschiedliche öffentliche Adressen melden, ohne dass einer davon lügt.
Leite die benutzte Familie nicht allein aus DNS ab. Ein vorhandener AAAA-Record beweist weder Route noch Firewallfreigabe oder Listener; ohne AAAA bleibt selbst ein hervorragend angebundener IPv6-Client bei IPv4. Teste den exakten Hostnamen und das konkrete Protokoll aus dem betroffenen Netz. Besondere Aufmerksamkeit verdienen Split-Tunnel: Ein VPN transportiert vielleicht IPv4 über den Firmenausgang, lässt IPv6 aber beim lokalen Provider — oder umgekehrt. Das überrascht bei der Fehlersuche und wird zum Policy-Leck, wenn die Organisation glaubte, sämtlicher Verkehr übernehme eine gemeinsame Egress-Identität.
Forwarded-Header sind Behauptungen mit Vertrauensgrenze
Hinter Reverse Proxy oder CDN ist der TCP-Peer des Origins der Proxy. Damit der Client-Kontext erhalten bleibt, ergänzen Zwischenstationen Felder wie Forwarded, X-Forwarded-For oder anbieterspezifische Connecting-IP-Header. Das sind Zeichenketten in einem HTTP-Request, keine kryptografischen Beweise. Ein direkter Client kann selbst X-Forwarded-For senden; jeder nicht vertrauenswürdige Hop kann Werte voranstellen oder ersetzen. Der Origin darf ein Feld erst dann verwenden, wenn sein unmittelbarer Peer ein bekannter Proxy ist, der eingehende Kopien verwirft und den maßgeblichen Wert selbst schreibt.
Auch die Reihenfolge ist Teil der Policy. Eine X-Forwarded-For-Kette kann mehrere Adressen enthalten; pauschal den ersten oder letzten Eintrag zu nehmen ist ohne Kenntnis der beteiligten Proxies unsicher. Konfiguriere im Framework die exakte Hop-Zahl oder vertrauenswürdige CIDRs und bewahre die Socket-Gegenstelle separat auf. Der HTTP-Header-Analyzer ordnet eingefügte oder öffentlich abrufbare Response-Header und markiert widersprüchliche oder doppelte Felder. Aus einer weitergereichten Client-Behauptung macht er keine verifizierte Identität — diese Grenze bleibt Sache deiner Proxy-Konfiguration.
Allowlists und Geografie brauchen eine Betriebspolitik
Eine IP-Allowlist ist nur dann belastbar, wenn der erlaubte Ausgang bewusst betrieben wird und stabil bleibt. Firmen-NAT und verwaltete VPN-Ausgänge können diesen Vertrag erfüllen; Privatanschlüsse, Mobilfunk, Privacy-Relays, temporäre IPv6-Adressen und automatisch skalierende Cloud-Systeme meist nicht. Dual Stack verdoppelt die Policy-Fläche: Ist nur die Büro-IPv4 erlaubt, das IPv6-Präfix aber vergessen, hängt der Zugriff von der gewonnenen Adressauswahl ab. Nutze für Menschen besser identitätsbasierte Anmeldung und reserviere IP-Regeln für kontrollierte Netzgrenzen. Dokumentiere bei jeder Ausnahme Besitzer, Präfix, IP-Familie, Quelle, Ablaufdatum und Notzugang.
Geo-IP ist noch weichere Evidenz. Datenbanken ordnen Allokationen und Routingbeobachtungen einem ungefähren Ort zu; VPNs, Carrier-Ausgänge, Anycast, Firmen-Backhaul und veraltete Zuweisungen entfernen die Adresse von der Person. Geografie taugt für Voreinstellungen oder als Risikosignal, nicht als alleiniger Nachweis von Wohnort oder Berechtigung. Logge die vertrauenswürdig ermittelte Client-Adresse, den unmittelbaren Peer, Zeitstempel und IP-Familie, damit sich der Weg später rekonstruieren lässt. Die präzise Frage lautet nie bloß „Welche IP hat der Nutzer?“, sondern: „Welche Adresse sah dieser Dienst bei dieser Verbindung, über welche vertrauenswürdigen Zwischenstationen — und welche Entscheidung trägt dieser Befund wirklich?“