ich habe zunächst erfolgreich über Wireguard eine Konfiguration für Mullvad VPN über eine Socks5 Adresse erstellt, um Inverse Split Tunneling zu ermöglichen. Dabei wird nur Librewolf getunnelt. Bei Librewolf ist der Proxy entsprechend eingetragen. Wenn ich die VPN-Verbindung starte, dann kann ich Firefox ohne VPN verwenden, jedoch immer mit der entsprechenden DNS-Adresse des jeweilig ausgewählten VPN-Servers. Librewolf verbindet sich über den Proxy und wird durchs VPN getunnelt. Bei der zugrundeliegenden conf-Datei von Wireguard ist in dem Fall bei DNS 10.64.0.1 angegeben.
Wenn ich jedoch dezidiert eine Inhaltsfilterung (Malware, Social Media, Ad-Block, Tracking, Glücksspiel) des DNS-Resolvers möchte, dann wäre die DNS Adresse 100.64.0.55. Ist diese entsprechend eingetragen, funktioniert beim Starten des VPNs jedoch nur noch Librewolf, während Firefox keine Seiten mehr aufrufen kann (“Seite nicht gefunden”).
Kann mir das jemand erklären? Wie kann ich das Problem lösen?
Der DNS-Server welcher in deiner Konfigurationsdatei für deinen Wireguard-VPN eingetragen wurde, wird global für das System als DNS-Server festgelegt, wenn du die Wireguard-Verbindung aufbaust.
Daher stammen deine Probleme.
Unter Linux wird der DNS-Server in der Datei /etc/resolv.conf hinterlegt. Das wäre bei deinen ersten geschilderten Fall die 10.64.0.1 - aus dieser lesen dann fast alle Anwendungen wie Firefox, Thunderbird, curl, … die IP-Adresse des DNS-Servers aus und kontaktieren diesen zum Auflösen von Domains.
Ich vermute du hast für den Mullvad VPN-Peer in der Wireguard-Konfiguration AllowedIPs = 10.0.0.0/8 oder ähnliches eingetragen, dadurch kann dann auch der in der Wireguard-Konfigurationsdatei hinterlegte DNS erreicht werden (10.64.0.1 da es im 10.0.0.0/8 Subnetz ist).
Nun hat der von dir gewünschte Mullvad DNS-Server eine IP-Adresse dessen erster Block des Quartetts mit 100 beginnt, das liegt dann nicht im 10.0.0.0/8 Netz - oder welches auch immer unter AllowedIPs bei dir eingetragen ist.
Die Lösung ist hier recht simpel: Du trägst unter AllowedIPs noch zusätzlich die IP Adresse(n) ein, die ebenfalls über das Wireguard VPN geroutet werden soll(en) - explizit nur für den von dir gewählen DNS Server wäre das: AllowedIPs = 10.0.0.0/8, 100.64.0.55/32
Das ist nötig damit der DNS-Server überhaupt erreicht werden kann, da die Mullvad DNS-Server, welche unter diesen IP-Adressen erreichbar sind, nur über die VPN-Verbindung erreicht werden.
Das erklärt auch warum Firefox keine Verbindungen aufbauen kann, sobald du den DNS änderst:
Bei deiner bisherigen Konfiguration können Domains über die 10.64.0.1 IP-Adresse über die VPN-Verbindung aufgelöst werden. Die Anfragen an 100.64.0.55 werden jedoch nicht über das VPN gesendet und laufen über deine normale Verbindung und erreichen daher keinen DNS-Server der die Anfrage beantwortet.
Dass Librewolf weiterhin Webseiten aufrufen kann liegt vermutlich daran, dass du in den Proxy-Einstellungen „Bei Verwendung von SOCKS v5 den Proxy für DNS-Anfragen verwenden“ aktiv hast, wovon Ich dir auch nicht abraten würde.
Wenn es dir um Werbung, Social Media, … Blockierung im Librewolf geht, würde Ich dir eher zu uBlock Origin raten. Das kann mehr als simple DNS Filter - von welchen du die Listen genauso darin eintragen könntest.
In diesen Fall, dass du die Einstellungen für den Proxy so beibehältst, kannst du auch den DNS Eintrag aus der Wireguard-Konfiguration löschen. Dann wird von deinen anderen Anwendungen wieder der DNS-Server kontaktiert, der in der normalen Netzwerkverbindung konfiguriert ist.
Das hält dann auch deine gesamte Konfiguration recht simpel, verständlich und übersichtlich.
Herzlichen Dank für die ausführliche Erklärung! Jetzt verstehe ich die Zusammenhänge schon besser.
Ja, ich habe bei Allowed IPs = 10.64.01/32 eingetragen. Und ja, ich habe bei Librewolf „Bei Verwendung von SOCKS v5 den Proxy für DNS-Anfragen verwenden“ aktiviert.
Ich habe zum Testen jetzt eine conf-Datei mit den entsprechenden Eintragungen erstellt:
DNS = 100.64.0.63
AllowedIPs = 10.64.0.1/32, 100.64.0.63/32
Firefox kann dadurch wieder Seiten aufrufen, jedoch ist die IP-Adresse des DNS-Servers dann nicht 100.64.0.63, sondern der entsprechende DNS-Server des ausgewählten VPNs. Die IP-Adresse des DNS-Servers ist in dem Fall bei Librewofl und Firefox dieselbe. Es scheint also keinen Unterschied zu einer Konfiguration zu geben, bei der unter DNS auch 10.64.0.1 eingetragen ist.
Ich nutze bei Librewolf und Firefox schon Ublock origin im hard mode. Ich hatte es bisher im Blog und im Forum hier so verstanden, dass es sinnvoll ist, gleichzeitig auf DNS-Ebene zu filtern.
Verstehe ich dich richtig, dass ich den DNS-Eintrag in allen conf-Dateien löschen könnte und dann würde Librewolf weiterhin den DNS-Server des VPNs nutzen (hier dann allerdings ohne DNS-Filter), während alle anderen Anwendungen, z. B. Firefox meinen üblichen DNS-Server von adminforge verwenden würden?
Neben Librewolf nutze ich sonst noch Freetube über den Proxy. Dort gibt es allerdings keine DNS-spezifischen EInstellungen. Hieße das dann, dass Freetube im Falle des Löschens der DNS-Server-Adresse in der conf-Datei auch meinen üblichen DNS-Server verwenden würde? Und falls ja, entstünde dadurch ggf. ein Leak bei meinem Versuch mich in dem Fall vor Google zu verschleiern?
Hallo, entschuldige die späte Antwort. Diesmal wieder ein langer Block, aber halte durch!
Das ist richtig so, bei Mullvad sieht die DNS-Konstellation in etwa so aus:
Dein Client kontaktiert den gewählten DNS-Server mit einer der von Mullvad veröffentlichten IP-Adressen mit den entsprechenden Filterlisten: Eine Liste der Kombinationen findet sich auf GitHub
100.64.0.3 - Ad blocking and tracker blocking
100.64.0.63 - ("Everything") Social media, gambling blocking, adult content, malware blocking, ad blocking and tracker blocking
Hier sei besondere Anmerkung auf den Titel gelegt „Custom DNS entries for use with our VPN service“, zu deutsch: „Benutzerdefinierte DNS-Einträge zur Verwendung mit unserem VPN-Dienst“ - diese IP-Adressen sind also nur als DNS-Server über Mullvad VPN erreichbar. Sie liegen in einen reservierten Adressraum, nämlich 100.64.0.0 - 100.127.255.255 bzw. 100.64.0.0/10 - werden also im öffentlichen Internet nicht geroutet. Die Anfrage kann also auf Testseiten auch nicht von dieser IP-Adresse stammen.
Daraufhin wird von diesem deine Anfrage gefiltert. Wenn ein Eintrag für die Domain auf der Filterliste ist, erhält dein Client den Status NXDOMAIN und keine IP-Adresse zurückgeliefert, das verdeutlicht diese Beispielabfrage mit dem Tool dig in der dritten Zeile, nach status::
Schaut gut aus, Facebook.com befindet sich auf der „Social Media“-Filterliste, wird also vom 100.64.0.63 Server ausgefiltert.
Wenn eine Domain nicht in der Filterliste eingetragen ist, wie das für facebook.com der Fall für die „Ad & Tracking“-Filterliste ist, wird die DNS-Anfrage vom Mullvad DNS-Server aufgelöst und du erhältst die IP-Adresse (Zeile 3 & 9):
Dabei ist der Clou: Mullvad hat 64 verschiedene Kombinationen von Filterlisten.
Es wäre absurd hier für jede Filterliste einen DNS-Server mit eigenen Cache bereitzustellen.
Am Ende ließen sich auch noch die gewählten Filterlisten alleine anhand der IP-Adresse des anfragenden Servers feststellen, ohne das mit hunderten einzelnen Anfragen testen zu müssen (die dir uBlock Origin im Hardmode verraten würde)!
Deswegen fragen die ganzen filternden DNS-Server, nach dem Filtern der Anfrage, direkt bei einen zentralen DNS-Server nach, bzw. lauscht der zentrale DNS-Server auf verschiedenen IP-Adressen und filtert mit unterschiedlichen Listen je nach dem welche IP-Adresse angesprochen wird.
Die genaue Konstellation konnte Ich auf die schnelle jetzt nicht nachrecherchieren, aber ein solcher DNS-Server existiert meines Wissens für jeden Mullvad VPN-Endpunkt. Deswegen würde sich die DNS-Server IP-Adresse auf der Testseite definitiv ändern, wenn du den Endpunkt wechselst.
Es wäre auch möglich, dass ein Mullvad VPN-Endpunkt mehrere DNS-Server hat oder andere IP-Adressen zur Auflösung nutzt. Konsistenz ist also für diese nicht garantiert.
Das erklärt dann auch das Phänomen welches du beobachtest:
Während in deiner Konfiguration 100.64.0.3 oder 100.64.0.63 eingetragen ist landet deine Anfrage nach den Filtervorgang an der gleichen Stelle, welche dann die Domain bei den Nameservern im Internet auflöst, egal welche Filterliste verwendet wird - und hierbei der Testseite dann mit der beobachteten IP-Adresse bekannt wird.
Wie oben beschrieben lässt sich also aus den ersten Satz nicht auf die Schlussfolgerung im zweiten schließen. Der bessere Test ist hier also wirklich die Auflösung einer Domain die von A blockiert sein sollte, jedoch nicht von B, auszuprobieren.
So wird z.B. doubleclick.com, welches sich auf der Adblock-Liste von Mullvad befindet, von 10.64.0.1 aufgelöst - oder auch von jeder anderen IP-Adresse, die keinen der Custom-DNS-Servern von Mullvad zugeordnet ist, wenn diese über den VPN geroutet wird, solange der DNS Redirect nicht deaktiviert wurde.
Von 100.64.0.3, oder allen anderen Custom-DNS-Servern von Mullvad, welche die Adblock-Liste enthalten, wird jedoch keine IP-Adresse sondern der Status „NXDOMAIN“ zurückgeliefert.
Nur für Software, welche dann keinen Adblocker integriert hat. Wenn eine Anfrage von uBlock Origin blockiert wird, erreicht diese gar nicht erst den DNS-Server.
Für ein „Defense in Depth“-Konzept kannst du natürlich den DNS-Server auch filtern lassen, persönlich würde Ich, wenn Ich meinen sonstigen Traffic nicht über Mullvad laufen lasse, aber nicht deren Custom-DNS-Server verwenden.
Anstelle dessen würde Ich einen beliebigen anderen verwenden (adminforge, …) - oder Mullvad VPNs öffentlichen DoT-/DoH-Service, der sich nochmal erheblich im Konzept von den Custom-DNS-Servern über die VPN Verbindung unterscheidet und meiner Sicht nach besser für das sonstige System geeignet ist. Dann jedoch am besten auch über DoH oder DoT.
Korrekt, da Librewolf mit konfigurierten Socks5-Proxy, mit DNS-Anfragen über diesen (socks5h), die DNS-Anfragen vom Proxy auflösen lässt und nicht den System-DNS kontaktiert.
Das könnte theoretisch ein möglicher Fall sein, Ich bezweifel es jedoch. Die meiste Software sollte inzwischen socks5h verwenden können und hier die DNS Anfragen über den Proxy auflösen, darauf schließe Ich bei Freetube auch, da es eine Anleitung zur Verwendung mit Tor gibt, welches man auch mit socks5h (also DNS-Auflösung über den Proxy) verwendet bzw. verwenden sollte.
Angenommen es wird dein System DNS kontaktiert, dann lässt sich daraus maximal für deinen Internet Anbieter, etc. schließen, dass dein Computer den Adminforge DNS-Server kontaktiert - ggf. mitsamt der Domain, wenn du kein DoT oder DoH verwendest.
Dem Adminforge DNS-Server ist bekannt, welche Domain du auflösen möchtest, sollte der Adminforge DNS-Server (durch caching) nicht bereits wissen, welche IP-Adresse für youtube.com Verwendung findet, wird diese von Adminforge aufgelöst. Google weiß dann, durch den Betrieb des eigenen Nameservers, dass Adminforge zu den Zeitpunkt der Anfrage wissen möchte welche IP-Adresse „Youtube.com“ hat.
Google selbst weiß aber nicht, dass deine Heimadresse bei Adminforge nach der IP-Adresse für „youtube.com“ gefragt hat - und FreeTube verwendet Mullvad als Proxy.
Deswegen erhält Google hier nicht deine IP-Adresse und weiß auch nicht dass Du (deine IP-Adresse) Youtube (mit FreeTube) aufgerufen hast.
Soweit verständlich? Ich musste mich beeilen, Ich hoffe, das klärt alle Fragen und Zweifel.
Bei genug Neugierde könntest du dir die Anwendungen Wireshark oder TCPdump anschauen und dort nach DNS-Traffic filtern, um deinen DNS-Netzwerktraffic zu analysieren, aber das ist vermutlich eine zu große Hürde für den Anfang, wenn man sich nicht auf tieferer Ebene mit Netzwerkkram beschäftigen möchte.
Richtig cool, dass du dir trotz Eile so viel Zeit für die Erklärung genommen hast!
Ich habe es jetzt, denke ich, zumindest zum Großteil verstanden und mich entsprechend deiner Empfehlung für die Variante ohne eingetragenen DNS-Resolver in der WG-Konfiguration entschieden und bin sehr zufrieden.
