DNS durch einen SSH-SOCKS-Proxy leiten

[ingo2]

Angeregt durch diesen Beitrag von @Lord_Carlos viewtopic.php?f=30&t=179446#p1256608 wollte ich das mal aud die Schnelle ausprobieren. Mein Netzwerk
FritzBox (IPv4 192.168.x.1)-> Debian 10 Serverlein (IPv4 192.168.x.y) mit unbound -> der Client (Debian 10 PC)

VomPC den Tunnel zum Serverlein aufgebaut mit

Code: Alles auswählen

$ ssh -D 1234 -N -f <192.168.x.y> 

Auf dem PC im Browser (Firefox-esr und PaleMoon getestet) entsprechend konfiguriert:

Code: Alles auswählen

Einstellungen -> Erweitert -> Netzwerk -> Verbindung -> Einstellungen -> 
SOCKS-Host = localhost, Port = 1234, SOCKS v5
Kein Proxy für: localhost, > IP PC> 
Proxy für DNS verwenden (nur SOCKS v5)

Test im Browser mit einer URL, die mein unbound normalerweise blockt - die Dopmain wird aufgelöst

Normalerweise - ohne den SOCKS-Proxy - bekomme ich eine leere Seite mit

Pale Moon kann keine Verbindung zu dem Server unter motoren.ru aufbauen.

Test mit

Code: Alles auswählen

dig motoren.ru
SERVER: 192.168.x.y#53	(mein unbound)
motoren.ru.		3600	IN	A	127.53.53.1

Auf den PC's ist als alleiniger nameserver mein unbound konfiguriert

Code: Alles auswählen

search home
nameserver 192.168.x.y		(IP's geändert)
nameserver fd33::abcd:1234:b9ff:fe47:83e8

Als letztes wollte ich versuchen, auch die Namenmsauflösung in der FritzBox ausschließlich durch meinen unbound machen zu lassen - der hat ja die expliziten IP's des gewählten DNS-Providers - das erlaubt die FritzBox nicht, die will unbedingt mindestens einen öffentlichen DNS-resolver haben.
s
Ach ja,
mein unbound hört auf allen Interfaces mit IPv4 und IPv6 und TCP und UDP. Die config:

Code: Alles auswählen

	interface: 0.0.0.0
	interface: ::0

	# Enable IPv4, "yes" or "no".
	do-ip4: yes

	# Enable IPv6, "yes" or "no".
	do-ip6: yes

	# Enable UDP, "yes" or "no".
	do-udp: yes

	# Enable TCP, "yes" or "no".
	do-tcp: yes	
	

Auf dem Serverlein die resolv.conf:

Code: Alles auswählen

domain home
search home
nameserver 127.0.0.1
nameserver 192.168.x.1 (ist nur fallback, falls unbound mal ausfällt)

Die große Frage:
Woher bekommt der Browser (Firefox dasselbe) die Namensauflösung?

[mat6937]

Die große Frage:
Woher bekommt der Browser (Firefox dasselbe) die Namensauflösung?

Evtl. ist im FF das "DNS over HTTPS" aktiviert oder er hat ein anderes fallback für DNS, wenn das mit der resolv.conf nicht funktioniert.

[ingo2]

Die große Frage:
Woher bekommt der Browser (Firefox dasselbe) die Namensauflösung?

Evtl. ist im FF das "DNS over HTTPS" aktiviert oder er hat ein anderes fallback für DNS, wenn das mit der resolv.conf nicht funktioniert.

Also "DNS over HTTPS" ist garantiert nicht aktiviert - dann würde ich keinen eigenen recursiven resolver nutzen, außerdem kann PaleMoon das garnicht.

Da ist noch was anderes im Spiel. Kann es sein dass der SSH-Tunnel nicht den Server nutzt auf dem der Tunnel endet - also mein Serverlein mit unbound?
Vielleicht nimmt der Tunnel auch das Gateway (die FritzBox), um die DNS-Anfragen gleich nach extern zu richten, Doku dazu findet man kaum?

[mat6937]

Vielleicht nimmt der Tunnel auch das Gateway (die FritzBox), um die DNS-Anfragen gleich nach extern zu richten,

Versuch mal mit tcpdump, das festzustellen.

[ingo2]

Ja, das bringt mich weiter:

a) ohne SOCKS-Proxy Aufruf von "motoren.ru":

Code: Alles auswählen

# tcpdump -i eno1 -q udp port 53

22:47:05.819498 IP tux.home.37116 > apu.home.domain: UDP, length 28
22:47:05.819514 IP tux.home.37116 > apu.home.domain: UDP, length 28
22:47:05.820071 IP apu.home.domain > tux.home.37116: UDP, length 44
22:47:05.820094 IP apu.home.domain > tux.home.37116: UDP, length 28

b) mit SOCKS-Proxy Aufruf von "motoren.ru":

Code: Alles auswählen

# tcpdump -i eno1 -q udp port 53
22:30:55.821135 IP tux.home.51386 > apu.home.domain: UDP, length 28
22:30:55.821156 IP tux.home.51386 > apu.home.domain: UDP, length 28
22:30:55.821735 IP apu.home.domain > tux.home.51386: UDP, length 44
22:30:55.821745 IP apu.home.domain > tux.home.51386: UDP, length 28
22:30:55.846993 IP6 p200300c7Ef19b800E8ebBd137a983a33.dip0.t-ipconnect.de.59013 > e.dns.ripn.net.domain: UDP, length 39
22:30:55.847166 IP tux.home.60877 > apu.home.domain: UDP, length 90
22:30:55.861003 IP6 e.dns.ripn.net.domain > p200300c7Ef19b800E8ebBd137a983a33.dip0.t-ipconnect.de.59013: UDP, length 680

Der Einzige, der die Telekom-Hostnamen kennt ist die FritzBox - und die hilft anscheinend immer, denn sie hat die auf jeden Fall für die VoIP-Telefonie.- Deshalb läßt sich das wohl nicht unterbinden.

Aber wieso jetzt der Tunnel nicht die auf meinem Serverlein konfigurierten Wege geht ?
Hier die Namens-Auflösung auf dem normalen Wege im x-Term:

Code: Alles auswählen

dig motoren.ru

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> motoren.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32354
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;motoren.ru.			IN	A

;; ANSWER SECTION:
motoren.ru.		3600	IN	A	127.53.53.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Dec 03 22:58:20 CET 2020
;; MSG SIZE  rcvd: 55

Die lösen jedenfalls nach 127.53.53.1 (einer dummy-Adresse auf) wie in unbound konfiguriert.

Ingo