Guten Tag,
ich wollte Gluon mal selber bauen und habe mir die conf meiner Community von Github geschnappt.
Klappt soweit auch alles, auch der Router ist im Netz. Der kann aber keine DNS Namen auflösen.
Mit…
echo „nameserver 8.8.8.8“>>/etc/resolv.conf
…funktioniert es. Aber wieso klappt das bei mir nicht, aber bei den anderen? Muss man beim kompilieren von Gluon irgendwo was hinterlegen können, das die Nameserver automatisch gesetzt werden?
Hi,
die Namensauflösung auf dem Freifunk-Router selbst wird vom dnsmasq auf dem Router selbst erledigt, welcher als Upstream (eig. immer) einen Resolver im Freifunk-Netz nutzt.
Ist dein Node denn im FF-Netz? Entweder per Meshing mit einem anderen Knoten oder selbst im VPN?
Viele Grüße,
Manawyrm
Dies ist ein bekanntes „Phänomen“. Die Einstellungen erlauben keine Namensauflösung auf der Konsole. Warum dies so sein muss, ist mir allerdings nie einsichtig geworden. Nur beim Start läuft die Namensauflösung zu „Supernodes“ für über die WAN-Schnittstelle.
Das ist nicht ganz richtig.
Nur Knoten mit Uplink lösen auf und leiten korrekt weiter.
Mesh Knoten können zwar korrekt auflösen jedoch auf der Konsole nicht weiterleiten.
Kurz gesagt: ping geht nur mit Uplink. Nslookup immer.
nicht ganz richtig: deine Beschreibung trifft nur auf legacy IPv4 zu meine ich
Bei IPv6 geht das alles auf jedem Knoten (sofern die jeweilige Community auch IPv6-Adressen für nameserver announct per radvd)
Nicht zwangsläufig. Kommt ein wenig auf Deine Definition von „korrekt“ an.
Das ist der Punkt. Wobei sich ein ping auch noch anders verhalten können als ein nslookup.
Da sind (auf Knoten mit lokalem IP-Uplink am WAN) unterschiedliche Routingtabellen am Werk und die Tools der Busybox sind da etwas vernagelt, was die Wahl der Tabellen anbelangt.
Und „für die richtigen Fullsize-Tools“ ist zumindest in den 4MB-SPI-Modellen kein Platz.
Knoten mit lokaler IPv6 am Wan sind auch betroffen, aber in der umgekehrten Richtung.
Da geht von der Konsole (fast) immer über FF raus und nicht über den lokalen Uplink.
(Ich vermeide bewusst die Unterscheidung „Knoten mit Internet“. Denn Internet haben alle Freifunk-Knoten, solange ein Gateway sehen, das Außenanbindung hat.)
Was du wahrscheinlich willst ist einen Server im Netz der einen DNS-Cache bereitstellt und den per Router Advertisement announced. Dann kann auch jeder Mesh-Knoten über IPv6 DNS-Anfragen stellen. Zusätzlich kannst du auf dem DNS-Cache Freifunk-spezifische Zonen eintragen (.ffabc). Beispielkonfigurationen gibt es morgen.
Wenn Uplink-Knoten die Namensauflösung ihres lokalen dnsmasq über WAN leiten würden wäre das ein DNS-leak.
Dafür gibt es von den Frankfurtern ein Package:
https://github.com/freifunk-ffm/packages/tree/master/gluon-dns-cache
natürlich funktioniert das über IPv6 nur, wenn die Community public IPv6 Adresse benutzt - oder NAT66
nein, das verstehst du falsch. das ist ein cache AUF dem knoten, @PetaByteBoy meint einen im Netz, z.B. auf dem gateway.
Beides geht nur, wenn mindestens das Gateway funktionierendes IPv6 hat.
Ein ping xyz.tld liefert den Fehler bad address … Dies ist unabhängig davon, ob es einen WAN Uplink gibt.
Bei Bedarf kann man einen Nameserver in die /etc/resolv.conf schreiben. Die funktioniert aber nur mit WAN-Uplink.
Ein nslookup xyz.tld liefert ein service unknown. 127.0.0.1 ist als Namesserver in /etc/resolf.conf ziemlich überflüssig.
Dann ist etwas kaputt oder die VPN Verbindung des Knotens nicht da.
Oder eine Domain, die sehr auf lokale Dienste setzt und meint, dass Freifunk ohne Internet auch ganz schön ist.
Um mal ein bisschen Hintergrund zu liefern:
Die resolv.conf muss grundsätzlich 127.0.0.1 enthalten, da die Namensauflösung vom lokalen dnsmasq erledigt wird. Die Upstream-Resolver werden dabei vom netifd verwaltet und sind in der /tmp/resolv.conf.auto zu finden. Das ist nicht Gluon-spezifisch, sondern auf jedem OpenWrt/LEDE-System so.
Gluon ist dabei so konfiguriert, dass die /tmp/resolv.conf.auto nur mit den Nameservern, die im Mesh gefunden werden (durch Router Advertisements) gefüllt wird, und niemals mit denen vom WAN-Interface. Grund ist, dass ein Gluon-Node sich niemals unterschiedlich verhalten soll je nachdem, ob es eine WAN-Verbindung gibt oder nicht; das WAN ist nur ein zusätzlicher Weg, eine Anbindung an ein Mesh zu finden und wird für nichts anderes verwendet. Wenn dein Node keine Adressen auflösen kann, gibt es entweder keine Mesh-Verbindung, oder im Mesh keine Router Advertisements mit (korrektem) RDNSS-Feld.
nslookup und ping verhalten sich dabei identisch, was die Adressauflösung angeht. Was vielleicht verwirren kann, ist, dass ping immer IPv6-Adressen bevorzugt, wenn es A- und AAAA-Records gibt. Mit ping -4 pingt man dann über IPv4.