Ich möchte bei Nutzung der mobilen Datenverbindung meines Smartphones ( Lineage 18.1 ) nicht mehr den DNS-Servers meines Anbieters nutzen, sondern ( wie ja auch über WLAN leicht möglich ) einen eigenen eintragen.
Entsprechend den Ausführungen von Mike auf der Seite:
hatte ich das von Mike gepostete Startup- und Shutdown-Skript als eigenes Skript angelegt und unter ./data/local/ gespeichert und unter der AFWALL+ / Skript festlegen die Pfadangabe ./data/local/iptables_on.sh eingetragen.
Bezogen auf den Passus im Skript:
# Set a specific dns server for all networks except home WiFi (192.168.150.0/24)
$IPTABLES -t nat -I OUTPUT ! -s 192.168.150.0/24 -p tcp --dport 53 -j DNAT --to-destination 116.203.32.217:53
$IPTABLES -t nat -I OUTPUT ! -s 192.168.150.0/24 -p udp --dport 53 -j DNAT --to-destination 116.203.32.217:53
hätte ich erwartet, dass eine Abfrage des aktuell genutzten DNS-Servers mittels ./dnsleaktest.sh mir, den wie in Mikes Skript angegeben Dns-Server 116.203.32.217:53 anzeigt, doch leider werden mir nach Abfrage die DNS-Server meines Anbieters weiterhin angezeigt.
Hat jemand eine Idee, woran es liegen könnte bzw., was ich falsch gemacht habe?
Würde mich über Antworten bzw. Lösungsvorschläge sehr freuen.
unter „Skript festlegen“ ist es nun so eingetragen: /data/local/iptables_on.sh
Leider wieder dieselbe Ausgabe unter ./dnsleaktest.sh als auch mittels bspw. dnsleaktest.com
Könne es daran liegen, dass ich das Skript unter meinem Debian (MXLinux) erstellt hatte und dieses Skript dann in das Androidverzeichnis /data/local/ kopiert hatte und das Skript stattdessen unter Android erstellt werden muss?
So viel ich weiß, wird im Falle der Nutzung eines VPN’s wird immer der DNS-Server des VPN-Anbieters genutzt. Ist zumindest bei mir bei Nutzung eines openvpn’s eindeutig immer der Fall.
Sinn und Zweck des Posts von Mike und insbesondere der Erstellung des Skripts und dem Eingeben der Pfadangabe zum Skript in der AFWALL soll ja wohl sein ( wenn ich das richtig verstanden habe ), dass alle DNS-Abfragen -außer der über die WLAN-Schnittstelle - über die im Skript enthaltene IP-Adresse, in Beispiel " 116.203.32.217 " laufen sollen.
Nutze ich mein Smartphone zu Hause, ist dies so gut wie immer ins WLAN eingebunden und nutzt einen festgelegten DNS-Server ( in diesem Fall über pihole mit unbound ), also alle Clients im Netzwerk benutzen den selben DNS-Server.
Meine Absicht war ja nun, außerhalb meines WLANs bei der notwendigen Nutzung über Mobilfunk ebenfalls nicht den DNS-Server meines Anbieters zwangsweise benutzen zu müssen. Bin ich unterwegs, schalte ich die WLAN-Suche aus und logge mich in fremde WLANs dann nur unter Nutzung eines VPN-Clients ein, was sicherstellt, dass ich dann nicht den DNS-Server des fremden WLANs benutze.
Warum nun die Umsetzung von Mikes Skript bei mir nicht klappt, weiß ich nicht, vermute aber mal, dass die im Skript definierten IPTABLES-Regeln keine Anwendung finden. Ok, ich muss mich noch in die Erstellung von Customskripts einarbeiten…
Unabhängig vom bisherigen konnte ich eben aber - zuvor den DNS-Cache vom Handy gelöscht durch: Flugmodus ein / 30 Sekunden warten / dann wieder Flugmodus aus …einen DNS-Server meiner Wahl unter Netzwerk/Internet/Privates DNS einstellen, wobei bei alleiniger Nutzung der mobilen Verbindung ( WLAN aus ) durch Eingabe im Terminal: ./dnsleaktest.sh als auch bspw. dnsleaktest.com der von mir eingegebene DNS-Server bestätigt wurde.
Dieses "Gewurschtel’ hat natürlich zur Folge, dass der Eintrag unter „Privates DNS“ ( wäre aber auch eben deaktivierbar… ) dann auch für die Abfragen innerhalb des eigenen WLANs genutzt werden. Sind beide DNS-Server-Einträge im Router/pihole/Whereever… und die unter „Privates DNS“ identisch, nutzt man über WLAN als auch über Mobilfunk den gleichen DNS-Server. Will man für beide Schnittstellen unterschiedliche DNS-Anbieter benutzen, ist diese „Lösung“ etwas umständlich; wenn man den selben Anbieter für beide Schnittstellen benutzen will, evtl. eine Möglichkeit.
Und nein, dies löst das Problem mit der mangelnden Ausführung/Umsetzung von Mikes Post nicht.