Prüfe IPv4 und IPv6, wenn du dein VPN kontrollierst

Eine Seite zur öffentlichen Adresse kann nach dem VPN-Start eine andere IPv4-Adresse zeigen und trotzdem eine wichtige Frage offenlassen: Was passiert, wenn eine Anwendung IPv6 nutzt? Viele alltägliche Verbindungen können mehrere Adressfamilien verwenden, manche Netzwerke bieten nur eine. Eine sinnvolle Prüfung erfasst verfügbare Möglichkeiten und das beabsichtigte Verhalten der Konfiguration. Es geht weder darum, IPv6 überall zu erzwingen, noch es überall abzuschalten. Entscheidend ist, eine erfolgreiche Anfrage nicht für eine vollständige Beschreibung aller möglichen Wege auf dem Gerät zu halten.

Beginne IPv6-Prüfungen mit einem erwarteten Ergebnis

Kläre, ob Client und Konfiguration IPv6 transportieren, außerhalb des Tunnels sperren oder eine andere dokumentierte Lösung verwenden sollen. Das sind unterschiedliche Richtlinien. Ein fehlendes IPv6-Ergebnis kann in einem Aufbau erwartet und in einem anderen fehlerhaft sein. Ohne vorgesehenes Verhalten lässt sich der Test schwer deuten.

Die Adresse des Endpunkts und der Verkehr im Tunnel sind ebenfalls verschiedene Begriffe. Eine Verbindung zum VPN-Server über IPv4 legt allein nicht fest, welche Adressfamilien der Tunnel transportieren kann. Ebenso beweist ein IPv6-Endpunkt nicht, dass anschließend jede App IPv6 nutzt. Die Fähigkeit hängt von der vollständigen Konfiguration und dem umgebenden Netzwerk ab.

Lies die Hinweise zu Protokoll und Client, bevor du etwas änderst. Der Vergleich zwischen VLESS und WireGuard hilft, deinen Aufbau einzuordnen, doch ein Protokollname ist noch keine Routingrichtlinie. Notiere Anwendung, Version, gewählte Konfiguration sowie aktiviertes Split-Tunneling oder lokale Ausnahmen.

Ermittle, was das normale Netzwerk bereitstellt

Wenn ein unkritischer Vergleich ohne VPN angemessen ist, prüfe, ob das zugrunde liegende Netz funktionierendes IPv4, IPv6 oder beides bereitstellt. Trenne keinen vorgeschriebenen Arbeitstunnel und lege keine vertraulichen Aktivitäten offen, nur um einen Ausgangswert zu bekommen. Verbietet die Richtlinie den Vergleich, dokumentiere die Grenze und frage die Administration nach einer erlaubten Methode.

Nutze eine Diagnose, die beide Adressfamilien getrennt meldet. Eine Seite mit nur einer Adresse kann einfach den zuerst funktionierenden Weg gewählt haben. Die IETF-Spezifikation Happy Eyeballs beschreibt, wie Apps alternative Adressen oder Familien ausprobieren, um Verbindungsverzögerungen zu verringern. Das verbessert die Benutzbarkeit, bedeutet aber auch: Eine ladende Seite belegt nicht unbedingt beide Wege.

Beziehe die Beobachtung auf das tatsächliche Netzwerk. Heimisches WLAN beschreibt keinen Mobilfunkzugang, und ein Laptop am Hotspot ist nicht zwangsläufig gleichbedeutend mit dem bereitstellenden Telefon. Halte Zugangsart und Zeitpunkt fest. Meldet der Test kein IPv6, erfinde keine Adresse und bezeichne das Fehlen nicht als Leck, nur um die Tabelle zu füllen.

Wiederhole die Beobachtung mit aktivem Tunnel

Verbinde die vorgesehene Konfiguration und stelle neue Anfragen mit demselben Gerät und derselben Anwendung. Notiere IPv4 und, falls verfügbar, IPv6 getrennt. Erfasse Fehlschläge als solche, statt sie wegzulassen, weil eine andere Seite geladen hat. Ändere während des Vergleichs nicht den gewählten Endpunkt.

Ein Browsertest misst Browseranfragen. Ist eine andere App wichtig, nutze eine passende Diagnose oder bitte den Support darum. Ausnahmen, Systemproxys und anwendungsspezifische Netzwerknutzung können den Umfang verändern. Der Leitfaden zum VPN-Status erklärt, warum die Verbindungsanzeige ein Ausgangspunkt und kein Beweis für jede folgende Verbindung ist.

Scheint ein Ergebnis die normale Provideradresse zu zeigen, obwohl du einen geschützten Weg erwartest, verwende diesen Aufbau bis zur Prüfung der Richtlinie nicht für vertrauliche Aufgaben. Bewahre die Beobachtung privat auf und beschreibe sie genau. Veröffentliche keine vollständige Konfiguration oder Schlüssel neben dem Adresstest. Der Support benötigt normalerweise zuerst Client und erwartetes Verhalten, nicht geheime Zugangsdaten.

Interpretiere Adressen sorgfältiger als Länderetiketten

Eine Adressabfrage kann der beobachteten Adresse eine Organisation oder ein Land zuweisen. Solche Angaben sind nützlicher Kontext, aber keine eindeutige Messung des physischen Standorts. Datenbanken können abweichen und IPv4 sowie IPv6 desselben Dienstes unterschiedlich einordnen.

Vergleiche zur Routingprüfung die beobachteten Adressen mit der Erwartung des Anbieters für diese Konfiguration. Behandle Standortverhalten als gesonderte Frage. Der Beitrag zu VPN-Land und Website-Sprache erklärt, warum die Sprachwahl einer Seite allein keine Antwort liefert. Eine russische Oberfläche oder englische Suchseite ersetzt keine Prüfung der Adressfamilien.

Führe vier einfache Einträge: normales IPv4, normales IPv6, IPv4 im Tunnel und IPv6 im Tunnel. Kennzeichne nicht verfügbare oder ungeprüfte Felder ausdrücklich. Ergänze darunter die gewünschte Richtlinie. So lassen sich eine nicht unterstützte Familie, eine unerwartete direkte Route und ein abweichendes Geolabel unterscheiden, ohne alles zu „Das VPN ist kaputt“ zusammenzufassen.

Repariere keine Route durch Raten an Konfigurationsfeldern

Füge umfassende Routen nicht bloß hinzu oder entferne sie, weil ein Forumsbeispiel das zeigt. Die Android-VPN-Dokumentation beschreibt etwa getrennte Routen für alle Ziele bei IPv4 und IPv6. Diese Einstellungen beeinflussen, welche Ziele die virtuelle Schnittstelle erreichen. Sie sind keine dekorativen Zeilen, die man ohne Verständnis des übrigen Aufbaus kopiert.

Dasselbe gilt für manuell importierte Dateien. Eine Routingänderung kann DNS-Erreichbarkeit, lokale Dienste und erneutes Verbinden beeinträchtigen. Sichere die ursprünglich funktionierende Datei geschützt und verwende die vom Anbieter unterstützte Konfiguration für deinen Client. Veröffentliche niemals eine Konfiguration, um nach der Richtigkeit einer einzelnen Zeile zu fragen.

Sperrt die unterstützte Lösung absichtlich eine nicht verfügbare Adressfamilie, prüfe dies über dokumentierte Clientfunktionen. IPv6 pauschal im Betriebssystem oder Router abzuschalten kann andere Apps und Nutzer betreffen. Nimm eine solche Änderung nur aus klarem Grund und mit entsprechender Befugnis vor, nicht als Universalreparatur für einen unerklärten Einzeltest.

Prüfe bei einem Wechsel des Zugangsnetzes erneut

Das Ergebnis von gestern im WLAN garantiert nicht dasselbe Verhalten heute im Mobilfunk. Wiederhole die kleine Beobachtung nach einem größeren Clientupdate, Konfigurationswechsel oder einer Änderung des wichtigen Zugangswegs. Ein unveränderter Aufbau braucht keine endlosen Tests. Konzentriere dich auf Übergänge, die verfügbare Wege beeinflussen können.

Bleibt ein Fall offen, sende der Lumeraya-Hilfe Clientversion, Netzwerktyp, erwartete Richtlinie und getrennte Ergebnisse beider Familien. Sage dazu, ob eine Ausgangsmessung möglich war. Lass private Schlüssel weg und behaupte keinen allgemeinen Ausfall, wenn nur eine Anwendung getestet wurde.

Eine klare Dual-Stack-Prüfung endet mit einer begrenzten Aussage: Der beobachtete IPv4-Weg verhielt sich erwartungsgemäß; IPv6 ebenfalls oder war absichtlich nicht verfügbar; verbleibende Unsicherheit ist benannt. Das ist nützlicher als eine einzelne beruhigende Adresse, weil es das Ergebnis mit der tatsächlichen Konfiguration und dem zu schützenden Verkehr verbindet.