D-Link DAP-X1860 FF_OFFLINE_xxx

[wusel (Kai 'wusel' Siering)]

@igami

Über gluon-wan nslookup geht es

Das ist auch faktisch der Weg, über den tunneldigger das Resolving macht, also alles korrekt.

Nun die eigentliche Frage: Was hat es mit search lan auf sich? Und könnte es zu einem Problem führen, dass ich .lan als lokale Domain verwende?

Nein, solange man FQDNs benutzt, greift die Searchlist eh’ nicht:

@man resolv.conf

       search Search list for host-name lookup.
              By default, the search list contains one entry, the local domain
              name.   It  is  determined  from  the local hostname returned by
              gethostname(2); the local domain name is taken to be  everything
              after  the first '.'.  Finally, if the hostname does not contain
              a '.', the root domain is assumed as the local domain name.

              This may be changed by listing the desired  domain  search  path
              following  the search keyword with spaces or tabs separating the
              names.  Resolver queries having fewer than ndots  dots  (default
              is  1)  in  them  will  be attempted using each component of the
              search path in turn until a match is  found.   For  environments
              with  multiple  subdomains  please read options ndots:n below to
              avoid man-in-the-middle attacks and unnecessary traffic for  the
              root-dns-servers.   Note  that this process may be slow and will
              generate a lot of network traffic if the servers for the  listed
              domains  are  not  local,  and  that queries will time out if no
              server is available for one of the domains.

              If there are multiple search directives, only  the  search  list
              from the last instance is used.

              In glibc 2.25 and earlier, the search list is limited to six do‐
              mains with a total of 256 characters.   Since  glibc  2.26,  the
              search list is unlimited.

              The  domain  directive is an obsolete name for the search direc‐
              tive that handles one search list entry only.

Und wie gesagt, die /etc/resolv.conf (Symlink auf /tmp/resolv.conf) greift für alle OpenWrt-Prozesse, die DNS-Server des Meshes nutzend — durch einen Eintrag nameserver 127.0.0.1 wird der lokale dnsmasq gefragt, der auf /tmp/resolv.conf.auto zurückgreift.

Gluon-Prozesse, die mit dem WAN hantieren, greifen – mittelkomplex über iptables gelöst – auf einen dnsmasq-Prozeß zu, der auf Port 54 läuft und /var/gluon/wan-dnsmasq/resolv.conf nutzt, bei mir:

 root@33378-test-20240502:~# cat /var/gluon/wan-dnsmasq/resolv.conf 
 nameserver fd00::9a9b:cbff:feb1:1397
 nameserver 2003:ef:9f17:8900:9a9b:cbff:feb1:1397
 nameserver 192.168.177.9
 nameserver 192.168.177.1
 nameserver 8.8.8.8

Es ist diese iptables-Regel, die die Zugriffe auf 127.0.0.1:53 von Prozessen mit der GID 800 auf 127.0.0.1:54 umbiegt:

Chain OUTPUT (policy ACCEPT 1107 packets, 164K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 371K   23M DNAT       udp  --  *      lo      0.0.0.0/0            127.0.0.1            owner GID match 800 udp dpt:53 to::54

gluon-wan sorgt dafür, daß der ausgeführte Prozeß ensprechend gestartet wird:

 root@33378-test-20240502:~# gluon-wan id
 uid=0(root) gid=800(gluon-mesh-vpn)

Gluon ist an manchen Stellen schon recht komplex Dieser Beiträg könnte auch unter Erklärbar stehen …

Also zusammengefaßt:

• DNS-Debugging bzgl. WAN geht nur über gluon-wan nslookup ... o. ä.
• Welche DNS-Resolver im WAN benutzt werden, steht letztlich in /var/gluon/wan-dnsmasq/resolv.conf
• Mit WAN-Resolvern reden bei Gluon nur Prozesse, die mit der Group-ID 800 laufen; z. B. der tunneldigger-Prozeß
• »Normales« Debugging führt schnell in die Irre, da dann die Mesh-Resolver genommen werden — die es aber ohne Mesh-Verbindung gar nicht gibt.