Kleiner Exkurs:
OS: 17.01-SNAPSHOT, r3981+103-184fe1 FW: 1.0.0~116
HW: Ubiquiti UniFi AP Pro
root@33332-Schalueckstr-107-11d9:~# nslookup heise.de
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: heise.de
Address 1: 193.99.144.80
Address 2: 2a02:2e0:3fe:1001:302::
root@33332-Schalueckstr-107-11d9:~# cat /tmp/gluon/wan-dnsmasq/resolv.conf
nameserver 2001:678:2c0:1::1
nameserver 192.168.5.31
nameserver 192.168.5.33
nameserver 8.8.8.8
root@33332-Schalueckstr-107-11d9:~#
Allerdings ist sie aktuell auch connected — Gluon hat zwei Resolver, einen auf Port 53, den normale Anwendungen fragen (und der nur tut, wenn Verbindung zum Mesh besteht), und einen auf Port 54, der die NS aus /tmp/gluon/wan-dnsmasq nutzt und (nur) von fastd/tunneldigger genutzt wird:
root@33332-Schalueckstr-107-11d9:~# netstat -anu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 0.0.0.0:54 0.0.0.0:*
udp 0 0 0.0.0.0:42112 0.0.0.0:*
udp 0 0 0.0.0.0:48081 0.0.0.0:*
udp 0 0 :::546 :::*
udp 0 0 :::546 :::*
udp 0 0 :::53 :::*
udp 0 0 :::54 :::*
udp 0 0 ff02::1:16962 :::*
udp 0 0 fe80::26a4:3cff:feb1:11d9:16962 :::*
udp 0 0 :::1001 :::*
root@33332-Schalueckstr-107-11d9:~# ps w | grep dnsmas
2016 dnsmasq 1052 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c -k -x /var/run/dnsmasq/dnsmasq.cfg02411c.pid
2083 root 1120 S /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo -p 54 -h -r /var/gluon/wan-dnsmasq/reso
23418 root 1184 S grep dnsmas
root@33332-Schalueckstr-107-11d9:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
[…]
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DNAT udp -- anywhere localhost owner GID match gluon-mesh-vpn udp dpt:domain to::54
Sprich: fastd läuft unter GID gluon-mesh-vpn, dadurch werden dessen DNS-Anfragen an localhost auf Port 54 umgeleitet, wo der dnsmasq für’s externe Resolving läuft. Kann man auch simulieren:
root@33332-Schalueckstr-107-11d9:~# nslookup -query=TXT o-o.myaddr.l.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
o-o.myaddr.l.google.com text = "2a06:e881:1700:1:400:c0ff:fefb:e251"
root@33332-Schalueckstr-107-11d9:~# start-stop-daemon -S -c root:gluon-mesh-vpn -x nslookup -- -query=TXT o-o.myaddr.l.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
o-o.myaddr.l.google.com text = "91.1.346.266"
91.1.346.266 ist meine aktuelle Telekom-IP, über die der interne Resolver rausgeht, was beweißt, daß die Anfrage nicht über’s Mesh läuft.
2a06:e881:1700:1:400:c0ff:fefb:e251 die IP des FFGT-Gateways, welches auch den Resolver bietet.
Mesh-only-Knoten, verbunden:
root@33330-mail-de-AVM4020-test:~# cat /tmp/gluon/wan-dnsmasq/resolv.conf
root@33330-mail-de-AVM4020-test:~# nslookup -query=TXT o-o.myaddr.l.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
o-o.myaddr.l.google.com text = "2a06:e881:1700:1:400:c0ff:fefb:e251"
root@33330-mail-de-AVM4020-test:~# start-stop-daemon -S -c root:gluon-mesh-vpn -x nslookup -- -query=TXT o-o.myaddr.l.google.com
;; connection timed out; no servers could be reached
Ergo:
Ohne Mesh-Verbindung hast Du auf dem Knoten kein DNS, nur fastd/tunneldigger können, über den Upstream-DNS via DHCP, Namen auflösen. In obigem Status müßte ein start-stop-daemon -S -c root:gluon-mesh-vpn -x nslookup -- heise.de funktionieren.
0.7.9/Gluon 2016.2.x (2016!) hat das noch anders gelöst, IIRC; es gilt aber das oben gesagte prinzipiell auch: lokale Kommandos außer dem VPN-Kram laufen gegen den normalen Resolver, der nur tut, wenn Verbindung ins Mesh besteht. VPN-Daemons hingegen laufen gegen den/die WAN-DNS-Server, weshalb fastd auf mesh-only-Knoten i. d. R. auch kein VPN über’s Mesh aufbaut (mangels DNS-Auflösung) und aktiviert bleiben kann.
Warum gehen beide Nameserver, aber nicht die Abfrage ohne Angabe des NS?