Vpn-dienst Mullvad waarschuwt voor dns-lekken op Android

naar mijn weten is dit gevaar ook aanwezig op de desktop en routers

Niet precies ditzelfde risico. Op welk besturingssysteem dan ook, als je de routeringstabel aanpast zodat het in-VPN router-IP-adres (bijvoorbeeld 100.64.0.1) wordt gezien als default gateway ("internet") en alleen het IP-adres van de VPN-dienst zelf de echte router in je netwerk gebruikt om naar het internet te komen, dan gaat het besturingssysteem niet opeens alsnog verkeer voor een willekeurig IP-adres naar de echte router sturen wanneer de VPN-software sluit of crasht. Andere software moet de algemene route naar het internet via je router eerst terugzetten alvorens het besturingssysteem dat weer aanziet als een pad voor gewoon internetverkeer. Meestal zal de DHCP-daemon, die bij het besturingssysteem wordt meegeleverd, dat doen.

<detalis>
Feitelijk pas je de routertabel aan van:
0. Stuur verkeer voor 10.0.0.x direct uit op apparaat eth0
1. Stuur alles via 10.0.0.1
naar:
0. Stuur verkeer voor 10.0.0.x direct uit op apparaat eth0
1. Stuur verkeer voor 100.64.0.x direct uit op virtueel apparaat tun0
2. stuur verkeer voor 192.0.2.1 via 10.0.0.1
3. stuur alles via 100.64.0.1
Waarbij het 10.0.x-adres je router is, het 192.0.x-adres de VPN-dienst, en 100.64.x de router binnen de VPN-tunnel. De eerste match wordt direct uitgevoerd, van boven naar onder lezend. Hierdoor kún je niks lekken, want als de VPN-software crasht en vervolgens een pakketje voor 31.22.80.152 aan de kernel gegeven wordt ter verzending, dan gaat regel 3 matchen, dat vervolgens regel 1 gebruikt waar een apparaat aangesproken wordt (tun0) dat niet meer bestaat, en het netwerkpakket dus in bijvoorbeeld "network is unreachable" resulteert. (Kun je zelf uitproberen als je de default route weghaalt en dan 31.22.80.152 (Tweakers) pingt.)

DNS-verkeer is daarnaast nog een losse instelling. De resolver zit meestal op LAN (de router geeft jouw apparaat die informatie in hetzelfde pakket als waarin het je een lokaal IP-adres toewijst) en dus zou je alsnog die bevragingen (queries) lekken: in beide gevallen matcht het regel 0, wordt het uitgestuurd op LAN, en gaat het vanaf daar (via je gewone verbinding dus) het internet op. De VPN-software moet dus ook de DNS-instelling veranderen naar een adres binnen de VPN.
</details>

Op Android is het probleem dat je die rechten standaard niet hebt. Er draait wel een Linux-kernel en die doet ook routeren (jep, jouw telefoon kun je ook als router inzetten want de code/functionaliteit zit er al in), maar de Androidlaag daar bovenop beheert die routeringstabel. Je moet bij de Androidlaag aankloppen als VPN-app, waarna het de nodige dingen voor je aanpast. Ook de in de kernel ingebouwde nftables-firewall (vroeger: iptables) kun je op Android standaard niet zelf beheren. Als je volledige toegang hebt tot je eigen apparaat kan dat natuurlijk wel, en er zijn ook apps die dat makkelijk maken (zoals AFWall+), maar telefoonfabrikanten mogen van Google die toegang niet standaard aanzetten dus dat is pas mogelijk als je een OEM-unlockprocedure uitvoert en bijvoorbeeld een superuser-binary installeert, wat voor veel mensen te technisch en de moeite niet waard is. Hoe dan ook, als de VPN-app crasht of de verbinding wil herconfigureren (misschien naar een nieuwe server switchen als de huidige te druk wordt), dan is het dus afhankelijk van hoe Android daar precies mee omgaat of je op dat moment verkeer lekt buiten de VPN om dat voor binnen de VPN bedoeld was.

Dit probleem heb je op desktops niet, want daar heb je de volledige toegang tot je apparaat en je verleent dat toegangsniveau ook aan de VPN-software. In Windowss verleen je dat wanneer je zo'n fullscreen "Do you want to allow this app to make changes to your device?"-vraag krijgt en op "ja" klikt; op Linux krijg je meestal de vraag je wachtwoord opnieuw in te voeren of moet je het met bijvoorbeeld `sudo` uitvoeren. Vanaf dat moment kan de software eigenhandig die routeringstabel aanpassen en is het niet van een bovenliggende laag afhankelijk om het goed te doen.

Daarmee wordt de verbinding verbroken als de connectie met de VPN wegvalt.

Ik zou dit formuleren als: daarmee is bij het systeem geen functionerend pad naar het internet bekend (behalve naar het/de IP-adres(sen) van de VPN-dienst zelf). Het is niet zozeer dat de code doet "als [connectie met VPN verloren] dan [verbinding verbreken]", want daar kan (een korte) tijd overheen gaan, maar meer dat het bij voorbaat al verbindingen enkel via de VPN mogelijk maakt totdat andere software daar overheen fietst met andere plannen.

[Reactie gewijzigd door Lucb1e op 4 mei 2024 02:39]