Wenn Sie auch nach dem Einschalten des VPN eines der folgenden Symptome bemerken, vermuten Sie ein DNS-Leck oder ein WebRTC-Leck. Ein Leck liegt vor, wenn Informationen, die über den VPN-Pfad übertragen werden sollen, diesen Pfad verlassen (auch Exfiltration genannt).
- Die VPN-Server-IP wird auf der IP-Verifizierungsseite angezeigt, im DNS-Test wird jedoch der DNS-Server des Telekommunikationsunternehmens oder Routers angezeigt.
- Die IPv4-Adresse hat sich geändert, aber die IPv6-Adresse ist dieselbe wie vor dem Ausschalten des VPN.
- Auf der WebRTC-Testseite wird die öffentliche IP so angezeigt, wie sie vor dem Ausschalten des VPN war.
- Die ursprüngliche IP ist erst unmittelbar nach dem Wechsel von WLAN auf mobile Daten oder dem Aufwachen aus dem Schlafmodus sichtbar.
- Ich habe StageVPN für Chrome aktiviert, aber andere Browser und PC-Programme verbinden sich über die ursprüngliche IP.
- Selbst wenn das VPN aktiviert ist, zeigt die Website die Sprache und den Inhalt basierend auf der ursprünglichen Region an (dies kann an den Konto-/Cookie-Einstellungen liegen).
DNS-Leckage ist ein Phänomen, bei dem die Webkommunikation bei aktiviertem VPN durch den Tunnel läuft, aber nur DNS-Anfragen den Tunnel verlassen und der Domänenname für den DNS-Server des Telekommunikationsunternehmens oder für Wi-Fi sichtbar ist. Beim WebRTC-Leckagevorgang handelt es sich um ein Phänomen, bei dem das WebRTC des Browsers eine STUN-Anfrage direkt aus dem VPN/Proxy sendet, wodurch die Webseite die tatsächliche öffentliche IP ermitteln kann. Keines dieser Phänomene bedeutet, dass Seiteninhalte durchsickern. Es zeigt jedoch, wer wo zugreift. Dieser Artikel beginnt mit den Symptomen und durchläuft sechs Phasen der Diagnose, der Lösung nach Ursache und der erneuten Untersuchung.
Diagnose: So überprüfen Sie in 6 Schritten, ob ein Leck vorliegt
Das Prinzip der Leckprüfung besteht darin, die Werte bei ausgeschaltetem und eingeschaltetem VPN zu vergleichen. Vergleichen Sie die auf der Site angezeigte IP, den Server, der die DNS-Abfrage erhalten hat, und die WebRTC-Kandidatenadresse. Wenn auch nach dem Einschalten des VPN die Originalwerte sichtbar sind, handelt es sich um ein Leck. Tests sind nur auf Geräten und Browsern sinnvoll, die Sie tatsächlich nutzen. Auch wenn Sie keine bestimmte Testseite haben, können Sie die meisten Dinge einfach mit einem Browser überprüfen. Die IP-Verifizierungsseite ist eine Webseite, die die öffentliche IP-Adresse der verbundenen Person auf dem Bildschirm anzeigt. Sie finden es in einer Suchmaschine unter „IP prüfen“. Suchen Sie auf die gleiche Weise nach der DNS-Leak-Testseite und der WebRTC-Testseite. Das Prinzip ist unabhängig davon, welche Seite Sie verwenden, dasselbe, Sie müssen sich also nicht auf eine bestimmte Website verlassen.
- Schalten Sie das VPN aus und notieren Sie Ihre IP. Öffnen Sie die Seite zur IP-Verifizierung und notieren Sie die öffentliche IPv4-Adresse und, falls vorhanden, die IPv6-Adresse. Dieser Wert ist die Grundlage für alle nachfolgenden Vergleiche.
- Schalten Sie Ihr VPN ein und vergleichen Sie IPs. Nachdem Sie die Verbindungsabschlussanzeige in der StageVPN-App oder die grüne EIN-Anzeige auf dem StageVPN für Chrome-Symbol überprüft haben, öffnen Sie dieselbe Seite erneut. IPv4 sollte durch Ihre VPN-Serveradresse ersetzt werden.
- Überprüfen Sie Ihren DNS-Server. Öffnen Sie die Seite „DNS-Lecktests“. Diese Seiten fragen zufällige Subdomains ab und zeigen dann den DNS-Server an, der die Anfrage gesendet hat. Wenn Sie die Server Ihres Mobilfunkanbieters oder Routers sehen können, handelt es sich um ein DNS-Leck.
- Öffnen Sie chrome://webrtc-internals. Wenn Sie diese Adresse in die Chrome-Adressleiste eingeben, werden laufende WebRTC-Verbindungen und Kandidatenadressen angezeigt. Das Element wird angezeigt, wenn Sie die WebRTC-Testseite oder Videoanrufseite in einer anderen Registerkarte geöffnet haben.
- Überprüfen Sie die IP des Kandidaten. Wenn die Adresse des srflx-Kandidaten (Server Reflection) mit der ursprünglichen öffentlichen IP aus Schritt 1 übereinstimmt, handelt es sich um ein WebRTC-Leck. Wenn es sich um die VPN-Server-IP handelt oder nur der .local-Name und die private IP sichtbar sind, wird die öffentliche IP nicht angezeigt.
- Überprüfen Sie IPv6. Wenn Sie in Schritt 1 eine IPv6-Adresse hatten, schalten Sie das VPN ein und prüfen Sie, ob diese Adresse verschwunden ist oder sich geändert hat. In diesem Fall verlässt IPv6 den Tunnel. Wechseln Sie zwischen WLAN und mobilen Daten und wiederholen Sie den Vorgang, um zu sehen, ob die Ergebnisse nach dem Neustart des Browsers dieselben sind.
| Beobachtungsergebnisse | Bedeutung | Nächste Ursache |
|---|---|---|
| VPN-Server-IP vor Ort sichtbar | Die Webkommunikation erfolgt über den VPN-Pfad | Normal, nächster Schritt |
| IPv4 hat sich geändert, aber IPv6 ist die ursprüngliche Adresse | IPv6 verlässt den Tunnel | Ursache 2 |
| Der DNS-Server stammt vom Telekommunikationsunternehmen oder Router. | DNS-Leck | Ursachen 1, 3, 4, 5 |
| Der DNS-Server ist ein öffentlicher DNS-Anbieter | DNS in Ihrer VPN-Konfiguration oder ein sicheres DNS, das Sie selbst festlegen. | Gehen Sie nicht nur aufgrund des Firmennamens davon aus, dass es sich um ein Leck handelt, sondern prüfen Sie Ursache 4 |
| Die ursprüngliche öffentliche IP ist in WebRTC sichtbar | WebRTC-Leck | Ursachen 6 und 7 |
| In WebRTC sind nur lokale Namen oder private IPs sichtbar | Öffentliche IP wird nicht offengelegt | im Allgemeinen normal |
| Ursprüngliche IP erst unmittelbar nach Netzwerkwechsel | Lücke im Moment des Übergangs | Ursache 8 |
Die Ergebnisse können je nach Teststandort variieren. Es gibt Orte, an denen nur IPv4 angezeigt wird, und Orte, an denen IPv6 angezeigt wird. Auch die Methoden zum Auffinden von DNS-Servern sind unterschiedlich. Vergleichen Sie an mehr als einem Ort und indem Sie zu mehreren Netzwerken wechseln.
Was verrät eine DNS-Abfrage?
DNS-Abfragen enthalten Domänennamen. Seiteninhalte oder eingegebene Werte werden nicht berücksichtigt. DNS ist das Adressbuchsystem des Internets, das von Menschen gelesene Domänennamen in von Computern verwendete IP-Adressen umwandelt. Jedes Mal, wenn Sie eine Adresse in Ihren Browser eingeben oder eine App einen Server kontaktiert, fragt Ihr Gerät zunächst den DNS-Server: „Wie lautet die Adresse dieses Namens?“ Allein durch einen Blick auf den Abfrageverlauf können Sie viel darüber erfahren, wann und auf welchen Dienst Sie zuzugreifen versucht haben.
- mein GerätApp/Browser
- Nur-Text-DNS-Abfragen
- Öffentliches WLANCafé-Router
- Nur-Text-DNS-Abfragen
- Carrier-DNSvorhandener Server
- Bereiche, die exponiert sein können
- mein GerätApp/Browser
- DNS im Tunnel
- Öffentliches WLANCafé-Router
- DNS im Tunnel
- VPN-ServerStageVPN
- Abfrage nach VPN-Server-IP
- DNS-ServerIn der VPN-Konfiguration angeben
- VPN-Verschlüsselung
Herkömmliche DNS-Anfragen gehen unverschlüsselt an den UDP-Port 53. Um dies zu kompensieren, wurden DoH (RFC 8484), das Abfragen in HTTPS umschließt, und DoT (RFC 7858), das Abfragen in TLS umschließt, erstellt. Selbst wenn Sie verschlüsseltes DNS verwenden, kann der Servername (SNI), der beim Herstellen einer Verbindung zu einer Site über HTTPS gesendet wird, im Netzwerk sichtbar sein, wenn die Site und der Browser ECH (Encrypted Client Hello) nicht unterstützen.
| Versandart | Beobachter im selben WLAN | WLAN-Betreiber/Kommunikationsunternehmen | DNS-Server, der die Anfrage empfängt |
|---|---|---|---|
| Einfaches DNS (Klartext) | kann sehen | kann sehen | Sichtbar, mit meiner öffentlichen IP |
| DoH/DoT (verschlüsseltes DNS) | kann nicht sehen | Nicht sichtbar, DNS-Serveradressen sind sichtbar | Sichtbar, mit meiner öffentlichen IP |
| DNS innerhalb eines VPN-Tunnels | kann nicht sehen | Nicht sichtbar, sieht nur, dass es mit dem VPN-Server kommuniziert | Sichtbar, mit VPN-Server-IP |
| Status des DNS-Lecks | Wenn es sich um Klartext handelt, können Sie ihn sehen. | kann sehen | Sichtbar, mit meiner öffentlichen IP |
Secure DNS (DoH) und VPN haben unterschiedliche Zwecke. DoH verschlüsselt nur DNS-Anfragen; Der Site-Zugriff selbst und die IPs, die die Site sieht, bleiben gleich. Ein VPN verschlüsselt die gesamte Kommunikation zwischen Ihrem Gerät oder Browser und dem VPN-Server und ändert die IP, die Websites sehen. Auch der Inkognito-Modus stoppt Leaks nicht. Der Inkognito-Modus ist eine Funktion, die weder Verlauf noch Cookies auf dem Gerät hinterlässt und keine DNS-Anfragen oder WebRTC-Routen ändert.
Wie ermittelt WebRTC eine IP-Adresse?
WebRTC findet auf verschiedene Weise seine eigene Adresse, um zwei Geräte auf dem kürzesten Weg zu verbinden, und übergibt die Ergebnisse an das Skript auf der Webseite. WebRTC ist eine Webstandardtechnologie, die es Ihnen ermöglicht, Videoanrufe, Sprachanrufe und Dateiübertragungen ohne Plugins in Ihrem Browser zu tätigen. Der Prozess der Adresserfassung wird ICE (RFC 8445) genannt. Selbst Seiten, die keine Videoanrufe durchführen, können diesen Prozess mit einem Skript starten.
- Verbindungsobjekt erstellenDas Webseitenskript erstellt RTCPeerConnection
- Sammeln Sie lokale KandidatenIhr Browser erfasst die Adressen der Netzwerkgeräte Ihres Geräts
- STUN-AbfrageFragen Sie den STUN-Server mit UDP, wie meine Adresse aussieht
- Lieferung des KandidatenEine Liste der Kandidaten einschließlich der vom STUN-Server bereitgestellten öffentlichen Adressen wird an die Seite geliefert.
| Kandidatentyp | etwas | Informationen, die möglicherweise offengelegt werden | Schutz aktueller Browser |
|---|---|---|---|
| Gastgeber | Adresse des Netzwerkgeräts der Maschine | Private IP (192.168.x usw.) | Maskiert mit einem zufälligen .local-Namen (mDNS), kann aber auf Websites gesehen werden, die Kamera- und Mikrofonberechtigungen erteilt haben. |
| srflx (Serverreflexion) | Meine öffentliche Adresse, wie sie vom STUN-Server gesehen wird | Öffentliche IP, echte IP, wenn Sie den Proxy umgehen | Kann durch die IP-Verarbeitungsrichtlinie von WebRTC eingeschränkt werden |
| Relais | TURN Adresse des Relay-Servers | IP des Relay-Servers | Wenn Sie Relay verwenden, sieht die andere Partei die Serveradresse anstelle Ihrer IP. |
Das Problem ist die STUN-Abfrage in Schritt 3. Browser-Proxys leiten Webanfragen weiter, aber die UDP-Kommunikation von WebRTC läuft in den Standardeinstellungen des Browsers nicht über den Proxy. Die vom STUN-Server bereitgestellte Adresse ist also nicht die des Proxyservers, sondern meine ursprüngliche öffentliche IP. Anders sieht es bei geräteweiten VPNs aus. Da die gesamte UDP-Kommunikation, einschließlich STUN-Anfragen, über den Tunnel erfolgt, ist die vom STUN-Server gesehene Adresse auch die IP des VPN-Servers.
Browser-Proxy und Standardrichtlinie
- Webanfragen laufen über einen Proxy
- STUN-Anfragen gehen direkt an UDP
- Die Seite kann echte öffentliche IP sehen
Browser-Proxy unddisable_non_proxied_udp
- Verhindern Sie, dass UDP den Proxy durchläuft
- WebRTC verwendet nur Proxy-Pfade
- Einige Anrufe haben unterschiedliche Verbindungsmethoden oder -qualitäten
Geräteweites VPN
- Auch STUN-Anfragen gehen durch den Tunnel.
- Der Kandidat für die öffentliche Adresse ist die IP des VPN-Servers
- Verbindungstrennung und IPv6-Handhabung erfordern eine Bestätigung
Chrome verfügt über eine „WebRTC-IP-Verarbeitungsrichtlinie“, die bestimmt, welche Adresse WebRTC verwendet, und Erweiterungen können diesen Wert ändern. Jeder Wert entspricht vier Methoden, die in der WebRTC IP Address Handling Recommendation (RFC 8828) der IETF beschrieben sind.
| politischen Wert | Bewegung | Belichtungsbereich |
|---|---|---|
| Standard | Sammeln Sie Kandidaten von allen Netzwerkgeräten | Am breitesten (lokale Adressen maskiert durch mDNS) |
| default_public_and_private_interfaces | Verwenden Sie nur Geräte auf der Standardroute und verwenden Sie sowohl öffentliche als auch private Adressen | Gibt keine Adressen anderer Geräte preis |
| default_public_interface_only | Verwenden Sie nur öffentliche Adressen der Standardroute | Private Adressen werden nicht offengelegt |
| disable_non_proxied_udp | Kein UDP über Proxy, verwenden Sie TCP über Proxy, wenn der Proxy UDP nicht unterstützt | Geben Sie keine Adressen von Routen außerhalb des Proxys preis |
Lösung: So überprüfen und beheben Sie die Ursache
Die meisten Lecks haben eine von acht Ursachen: Diese werden meist durch überlappende Einstellungen verursacht. Überprüfen Sie zunächst die in der Diagnosetabelle angegebene Ursachennummer und wiederholen Sie bei jeder Behebung Schritt 6 im Bild oben, um festzustellen, ob sich das Ergebnis geändert hat. Wenn Sie mehrere Einstellungen gleichzeitig ändern, wissen Sie nicht, was funktioniert hat.
Ursache 1 · In der VPN-Konfiguration ist kein DNS-Server vorhanden oder das Gerät verwendet einen anderen DNS.
überprüfen Wenn das VPN aktiviert ist, zeigt der DNS-Test den DNS-Server des WLAN-Routers oder Netzbetreibers an. In den WLAN-Einstellungen Ihres Geräts gibt es häufig manuelles DNS.
lösen Die StageVPN-App bindet einen DNS-Server in die VPN-Konfiguration ein und sendet Anfragen in den Tunnel. Stellen Sie in den Netzwerkeinstellungen Ihres Geräts „Manuelles DNS“ auf „Automatisch“ zurück, trennen Sie dann die Verbindung zum VPN und stellen Sie die Verbindung wieder her. Wenn das Problem weiterhin besteht, überprüfen Sie die Ursachen 3 und 5.
Ursache 2 IPv6 verlässt den Tunnel
überprüfen IPv4 wurde in die VPN-Serveradresse geändert, aber IPv6 bleibt derselbe wie der in Schritt 1 notierte Wert. Wenn das VPN nur IPv4 tunnelt, werden IPv6-Anfragen und -Kommunikationen über die ursprüngliche Route erfolgen.
lösen Die StageVPN-App ist so konfiguriert, dass sie auch IPv6-Kommunikation an den Tunnel sendet (AllowedIPs 0.0.0.0/0, ::/0), daher besteht normalerweise keine Notwendigkeit, sie auszuschalten. Wenn IPv6 immer noch so angezeigt wird, wie es sollte, prüfen Sie zunächst, ob eine andere VPN-App oder Geräteeinstellungen die Route ändern. Einige Teststandorte unterstützen IPv6 nicht. Vergleichen Sie daher auf mehr als einem Standort.
Ursache 3 · Das Betriebssystem fragt den DNS mehrerer Netzwerkgeräte gleichzeitig ab.
überprüfen Insbesondere bei einer VPN-Verbindung auf einem Windows-PC zeigt der DNS-Test sowohl den DNS des VPN als auch den DNS Ihres Mobilfunkanbieters an. Dies wird durch eine Funktion verursacht, die alle Netzwerkgeräte gleichzeitig befragt, wie z. B. die intelligente Multi-Homed-Namensauflösung von Windows.
lösen Halten Sie Ihr Betriebssystem und Ihre VPN-Software auf dem neuesten Stand und wiederholen Sie die Tests. Dieses Phänomen wird hauptsächlich bei geräteweiten VPNs auf PCs gemeldet und tritt aufgrund unterschiedlicher Strukturen nicht in gleicher Weise bei der StageVPN-App auf Smartphones und StageVPN für Chrome auf Chrome auf.
Ursache 4 · Secure DNS (DoH) ist im Browser oder Gerät separat angegeben
überprüfen Der DNS-Test zeigt Server von öffentlichen DNS-Anbietern. In diesem Fall handelt es sich möglicherweise nicht um ein Leck, sondern um eine von Ihnen selbst festgelegte Einstellung. Wenn Sie über ein geräteweites VPN verfügen, wird diese Anfrage ebenfalls durch den Tunnel geleitet, sie wird jedoch vom angegebenen Anbieter und nicht vom DNS in Ihrer VPN-Konfiguration empfangen.
lösen Wenn dies die beabsichtigte Einstellung ist, können Sie sie unverändert lassen. Wenn Sie DNS für Ihre VPN-Konfiguration verwenden möchten, werden die sicheren DNS-Einstellungen in Ihrem Browser und Gerät automatisch geändert. Es ist wichtig, nicht allein aufgrund des Firmennamens davon auszugehen, dass es sich um ein Leck handelt.
Ursache 5 · Andere VPN-, Proxy- und Sicherheits-Apps sind ebenfalls aktiviert
überprüfen Gleichzeitig werden Netzwerkfunktionen anderer VPN-Apps, Proxy-Erweiterungen, Werbefilter oder Sicherheitsprogramme aktiviert. Die Routeneinstellungen überschreiben sich gegenseitig, was dazu führt, dass einige Abfragen an die ursprüngliche Route weitergeleitet werden.
lösen Schalten Sie jeweils nur einen ein. Schalten Sie andere Apps und Erweiterungen aus, trennen Sie StageVPN, verbinden Sie die Verbindung erneut und wiederholen Sie Schritt 6. Die Proxy-Einstellungen von Chrome können jeweils nur eine Erweiterung steuern. Wenn also eine andere Erweiterung einen Proxy verwendet, stellt StageVPN für Chrome keine Verbindung her und teilt Ihnen den Grund dafür mit.
Ursache 6 · Es wird nur ein Browser-Proxy verwendet, es wird jedoch eine Kommunikation außerhalb des Browsers erwartet
überprüfen Ich habe StageVPN für Chrome aktiviert, aber andere Browser, PC-Messenger und E-Mail-Programme verbinden sich über die ursprüngliche IP und den ursprünglichen DNS. Dies ist kein Leck, dies ist der vorgesehene Bereich. Die Erweiterung deckt nur die Kommunikation in Chrome ab.
lösen Wenn Sie Programme außerhalb von Chrome schützen müssen, verwenden Sie ein VPN, das für das gesamte Gerät gilt. Auf Smartphones erledigt die StageVPN-App genau das. Der Unterschied im Umfang zwischen den beiden Methoden ist Browser-VPN vs. App-VPNIch habe es organisiert.
Ursache 7 WebRTC-Richtlinie wurde nicht angewendet
überprüfen Ich habe StageVPN für Chrome aktiviert und kann die ursprüngliche öffentliche IP im WebRTC-Test oder im srflx-Kandidaten in chrome://webrtc-internals sehen. Wenn die WebRTC-Einstellungen zuerst von einer anderen Erweiterung oder einer anderen Unternehmens-/Organisationsverwaltungsrichtlinie gesteuert werden, ändert StageVPN für Chrome die Richtlinie nicht und lässt sie unverändert.
lösen Deaktivieren Sie alle anderen Erweiterungen, die die WebRTC-Einstellungen steuern, und verbinden Sie StageVPN für Chrome erneut. Wenn die Verwaltungsrichtlinie die Ursache ist, wenden Sie sich an Ihren Administrator. Um in einem Inkognito-Fenster zu schreiben, müssen Sie im Erweiterungsverwaltungsbildschirm „Im Inkognito-Modus zulassen“ aktivieren. Wenn diese Option deaktiviert ist, erfolgt die Kommunikation in Inkognito-Fenstern nicht über den Proxy.
Ursache 8 · Der Moment, in dem die VPN-Verbindung unterbrochen wird
überprüfen Die ursprüngliche IP ist erst unmittelbar nach dem Netzwerkwechsel oder dem Aufwachen aus dem Ruhemodus sichtbar und nach einer Weile normal. Während der Trennung erfolgen alle Anfragen und Kommunikationen über den normalen Weg.
lösen Überprüfen Sie vor sensiblen Arbeiten, ob die Verbindungsabschlussanzeige der App oder das Erweiterungssymbol eingeschaltet ist. WireGuard, das von der StageVPN-App verwendet wird, baut auch beim Wechsel von WLAN auf LTE keinen Tunnel wieder auf, das Protokoll kann jedoch vorübergehende Unterbrechungen im Netzwerk selbst nicht ausgleichen. Die Möglichkeit, die Kommunikation automatisch zu blockieren, wenn die VPN-Verbindung getrennt wird, ist keine von StageVPN bereitgestellte Funktion. Das Prinzip ist Erläutern der WireGuard-PrinzipienEs ist drin
Wie stoppen StageVPN-Apps und StageVPN für Chrome Lecks?
Die StageVPN-App reduziert Leckagen, indem sie die gesamte Kommunikation tunnelt, während StageVPN für Chrome Namenssuchen als Proxy durchführt und WebRTC-Richtlinien anpasst. Da der Schutzumfang unterschiedlich ist, unterscheidet sich auch die Art und Weise, wie damit umgegangen wird.
| Artikel | StageVPN-App (iPhone·iPad·Android) | StageVPN für Chrome |
|---|---|---|
| Schutzbereich | Alle Geräte | Chrome-Browser |
| Über VPN-Route gesendete Kommunikation | IPv4·IPv6 Alle (AllowedIPs 0.0.0.0/0, ::/0) | Webanfragen laufen über den Proxy (ausgenommen private IP-Bänder und Localhost). |
| DNS-Abfragen | Weiterleitung innerhalb des Tunnels an den in der VPN-Konfiguration angegebenen DNS-Server. | Anfragen, die über einen Proxy gehen, werden nicht von Chrome, sondern vom Proxyserver gesucht. |
| WebRTC | Die gesamte UDP-Kommunikation läuft über den Tunnel. | „disable_non_proxied_udp“ wird während der Verbindung angewendet und kehrt beim Trennen der Verbindung zur ursprünglichen Einstellung zurück. |
| Was Sie derzeit im Netzwerk sehen | Die Tatsache, dass eine verschlüsselte Kommunikation mit dem VPN-Server erfolgt und die Datenmenge | Namenssuche von Proxy-Server-Adressen, verschlüsselten Verbindungen mit dem Proxy und Kommunikation von Apps außerhalb von Chrome |
| Fälle, die möglicherweise nicht zutreffen | Während die VPN-Verbindung verloren geht, wenn eine andere VPN-App umleitet | Inkognito-Fenster mit deaktiviertem Inkognito-Modus zulassen, wenn eine andere Erweiterung oder Verwaltungsrichtlinie die Proxy-/WebRTC-Einstellungen steuert |
| Zugriffsverlauf (93 Tage) | Angesehene Domains werden nicht erfasst | Der Name des verbundenen Zielhosts wird aufgezeichnet, der Pfad oder Suchbegriff wird jedoch nicht aufgezeichnet. |
StageVPN führt Sie im Rahmen seiner Angebote nicht durch ein separates Einstellungsmenü für den DNS-Leak-Schutz. Das obige Verhalten hängt von der Standard-VPN-Konfiguration der App und der Verbindungsmethode der Erweiterung ab. Der Leistungsumfang beträgt Merkmale und Umfang des AngebotsSie können es hier überprüfen.
Keine Lecks bedeuten, dass Anfragen und Kommunikation über den VPN-Pfad und nicht über den Netzbetreiber erfolgen. Dies bedeutet nicht, dass keine Aufzeichnungen geführt werden. StageVPN speichert Zugriffsdaten gemäß dem Communications Secrets Protection Act 93 Tage lang und zeichnet keine Kommunikationsinhalte auf. Der Artikel ist Hinweis zur Speicherung von ZugriffsdatensätzenNun, der Grund, warum ich es verrate, ist Warum legen wir unsere Richtlinie zur Aufbewahrung von Zugriffsdaten offen?erklärt.
Checkliste zur erneuten Überprüfung: Was überprüfen Sie erneut, nachdem Sie Änderungen vorgenommen haben?
Überprüfen Sie jedes Mal, wenn Sie eine Ursache beheben, die folgenden Punkte noch einmal von Anfang an. Wenn alles erfolgreich ist, liegt kein Leck vor. Wenn ein Element fehlschlägt, wird es auf die Karte mit der entsprechenden Ursache zurückgesetzt.
- Nachdem ich das VPN getrennt und wieder verbunden hatte, überprüfte ich, ob die App den Verbindungsaufbau anzeigte oder das Erweiterungssymbol EIN anzeigte.
- Auf der IP-Verifizierungsseite sehen Sie entweder die VPN-Serveradresse für IPv4 und IPv6 oder IPv6 nicht.
- Der DNS-Test zeigt nicht den DNS-Server des Telekommunikationsunternehmens oder Routers an.
- Der srflx-Kandidat in chrome://webrtc-internals verfügt nicht über die ursprüngliche öffentliche IP.
- Netzwerkfunktionen anderer VPN-Apps, Proxys/VPN-Erweiterungen und Sicherheitsprogramme sind deaktiviert.
- Wenn Sie für Ihr Gerät und Ihren Browser „Manuelles DNS“ oder „Sicheres DNS“ eingestellt haben, haben Sie überprüft, dass dies die beabsichtigte Einstellung ist.
- Ihr Betriebssystem, Ihr Browser sowie die StageVPN-Apps und -Erweiterungen sind auf dem neuesten Stand.
- Gleiches Ergebnis auch nach dem Wechsel zwischen WLAN und mobilen Daten und einem Neustart des Browsers.
- Wenn Sie Programme außerhalb von Chrome schützen müssen, können Sie statt einer Erweiterung ein geräteweites VPN verwenden.
Es ist auch sinnvoll, festzustellen, wann eine erneute Inspektion erforderlich ist. Dies ist nach einem größeren Update Ihres Betriebssystems oder Browsers, nach der Installation einer neuen Erweiterung oder Sicherheits-App oder vor der Durchführung sensibler Arbeiten in einem Netzwerk, mit dem Sie sich zum ersten Mal verbinden, der Fall. Wenn die Einstellungen gleich sind, sich die Ergebnisse aber geändert haben, ist in der Regel eines dieser drei Dinge die Ursache. Sobald Sie den Dreh raus haben, können die 6 Stufen der Diagnose in nur wenigen Minuten abgeschlossen werden.
Wenn das Problem weiterhin besteht, organisieren Sie das Gerätemodell, das Betriebssystem und die App-Version, den Zeitpunkt des Auftretens und die Testergebnisse. KundenbetreuungBitte kontaktieren Sie uns. Bitte senden Sie weder Ihr Passwort noch Ihren Bestätigungscode. Die Geräteeinstellungen, die zusammen mit der Dichtheitsprüfung überprüft werden müssen, sind: 10 Datenschutzeinstellungen für SmartphonesNun, es gibt Risiken, die nicht allein mit einem VPN gelöst werden können. Was VPNs verhindern und was nicht verhindern könnenNun, Ihre Gewohnheiten in öffentlichen Netzwerken sind es Sicherheitsregeln für öffentliches WLANIch habe es organisiert.
Referenzmaterial
- RFC 1034: Domainnamen – Konzepte und Einrichtungen — DNS-Struktur und die Rolle von Resolvern (IETF)
- RFC 8484: DNS-Abfragen über HTTPS (DoH) — So verschlüsseln Sie DNS-Abfragen über HTTPS (IETF)
- RFC 7858: DNS über TLS — So verschlüsseln Sie DNS-Abfragen mit TLS (IETF)
- RFC 8445: Interactive Connectivity Establishment (ICE) – WebRTC-Verbindungskandidatentypen und Erfassungsverfahren (IETF)
- RFC 8828: Anforderungen an die WebRTC-IP-Adressverarbeitung – Adressbereich, den Browser WebRTC (IETF) zur Verfügung stellen
- chrome.privacy-API – Chrome WebRTC IP-Verarbeitungsrichtlinienwerte (Chrome für Entwickler)
- chrome.proxy-API – Erweiterungs-Proxy-Einstellungen, Umgehungsliste und Kontrollprioritäten (Chrome für Entwickler)
- WebRTC-API — RTCPeerConnection und das Konzept der ICE-Kandidaten (MDN Web Docs)
