Android DNS-Leak an VPN vorbei > Fragen zum Workaround bei NetGuard

In diesem Blogbeitrag von @kuketzblog wird unter Abschnitt „5.1 Keine Filterung/Logging“ auf folgendes Problem hingewiesen

Das Problem kurz zusammengefasst: Android routet DNS-Anfragen teilweise am VPN vorbei. Was genau die Ursache für dieses Verhalten ist, konnten wir leider nicht herausfinden. Fakt ist: GrapheneOS routet DNS-Anfragen teilweise am VPN vorbei.

und auch ein Workaround angeboten

Um dieses Problem zu beheben, gibt es aktuell nur eine Lösung: Ihr müsst innerhalb NetGuard unter Einstellungen → Erweiterte Optionen die IP-Adresse von zwei VPN-DNS-Server hinterlegen bzw. eintragen, die über den Port 53 erreichbar sind (keine DoT- oder DoH-Adressen).

So hatte ich das auch bislang erstmal provisorisch eingerichtet, ohne mir weitere Gedanken zu machen. Aktuell baue ich einiges an meiner Konfiguration um, und stelle mir jetzt folgende Fragen:

a) Wenn das OS aus welchem Grund auch immer die Anfrage an der VPN-Schnittstelle vorbei leitet, warum und wie hilft dann eine Einstellung innerhalb der umgangenen VPN-App (hier: NetGuard) als Gegenmaßnahme ?

b) Damit die genannte Lösung greift, welche genauen Setup-Bedingungen müssen erfüllt sein ? Müssen nur beide VPN-DNS eingetragen sein im Sinne von „beide Felder sind plausibel gefüllt“ ? Oder müssen es auch zwei unterschiedliche, funktionierende DNS-Server sein ?

Hat sich jemand schon mal genauer damit beschäftigt und kann hierzu Auskunft geben ?

Nach meinen Informationen schleust das Android-System nur eine Art Verbindung an jeglichen VPNs vorbei: Den Captive-Portal Check (wofür es gute Argumente gibt).

Andere VPNs haben meines Wissens kein Problem mit DNS-Leaks, sodass das Problem tatsächlich an NetGuard liegt. Solche Leaks und Fallstricke habe ich schon selbst bei NetGuard beobachtet, bevor ich es heruntergeschmissen habe.

So nutzt NetGuard standardmäßig Google DNS Server als Fallback wenn man keine eigenen einrichtet. Leider wird bei jedem Verbindungswechsel kurz der Fallback genutzt, bevor der Netzwerkeigene DNS-Server verwendet wird.

1 „Gefällt mir“

Richtig, Capitive-Check Leak ist bekannt und mit GOS ja nicht das große Problem.

Das mit NetGuard ist ja aber mal hochinteressant. Deine Recherche ist plausibel nachvollziehbar und erklärt auch den beschriebenen Workaround. Schon mal DANKE dafür !

Was mich jetzt allerdings ziemlich perplex macht ist, wenn dem NG-Entwickler das Thema (mindestens) seit Anfang 2021 bekannt ist (Deine Anfrage bei XDA) aber dann gemäß dem Blogeintrag ein Jahr später das zu lesen ist

Nach einem Austausch mit Marcel konnte das Problem dann eingegrenzt werden. Es betrifft GrapheneOS, vermutlich aber auch andere Android Custom-ROMs bzw. Android-Versionen. […] Fakt ist: GrapheneOS routet DNS-Anfragen teilweise am VPN vorbei.

Den kurzzeitige Fallback werde ich mal bei Gelegenheit testen - ebenso ob dies auch bei Verwendung von Portforwarding passiert.

>>>>> NACHTRAG 12.10.2023 <<<<<

Zumindest meine Frage b) konnte ich nach Analyse des NG-Quelltextes und praktischer Nachstellung für mich zufriedenstellend beantworten:

Wenn beide Felder sinnvoll mit IPs gefüllt sind (auch identisch), benutzt NG ausschließlich diese Angaben für DNS-Anfragen. Bei „sinnvoll“ ist zu beachten, dass es sich nicht um loopback (127.0.0.1) oder wildcard (0.0.0.0) handeln darf. Ob die Adresse tatsächlich existiert oder erreichbar ist, ist dabei nicht relevant. DNS funktioniert dann halt nur nicht - das kann aber für gewisse Anwendungsfälle auch nützlich sein.

Erst wenn o.g. Bedingungen nicht erfüllt sind, kann das Dilemma seinen Weg nehmen:

  1. Der/die vom System (über die aktuell aktive Netzwerkverbindung) definierte/n DNS wird/werden zur DNS-Liste hinzugenommen.
  2. Wenn die Funktion „LAN-Zugriff erlauben“ eingeschaltet ist, werden DNS innerhalb des aktuell verbundenen Netzwerks aus der DNS-Liste entfernt !
  3. Wenn unter 2) mindestens ein DNS entfernt wurde oder in Summe keiner mehr übrig blieb, werden die Google-Server (NG default) zur DNS-Liste hinzugefügt !

Solange beide Felder „richtig“ gefüllt waren, ist es mir nicht gelungen, seitens NG irgendwie einen Fallback auf Google (oder sonstwo hin) zu provozieren.

Bzgl. Thema „Fallback bei GOS“ konnte ich lediglich feststellen, dass bei der manuellen Einrichtung einer WiFi-Verbindung die Angabe mindestens eines DNS zwingend erforderlich ist und hier Cloudflare (1.0.0.1) voreingestellt wird. D.h. ändert man dies nicht bewusst, wird dies auch übernommen.

Zum eigentlichen Thema des „Leaks“ von Android/GOS bin ich aber leider nicht weiter gekommen. Solange NG auch mit „falscher“ DNS-Einstellung läuft, konnte ich hier auch bei wildestem hin- und her, aus- und einschalten von Netzwerken keine Daten von in NG geblockten Domains laden. Das wäre super, wenn @kuketzblog hier noch mal einen Hinweis geben könnte, wie sich die beobachtete Situation konkret darstellte und wie sich das zum testen ggfs. nachstellen ließe.