ip netns exec und DNS: Warum Namen im Namespace scheitern

Ein Befehl erreicht 10.8.0.5 innerhalb des VPN-Namespace ohne Beschwerden, und derselbe Befehl scheitert in dem Moment, in dem er einen Hostnamen verwendet. Der Namespace hat eigene Schnittstellen, Routen und Sockets; er hat keine eigene Resolver-Datei. Wenn nichts eine dorthin legt, liest der Prozess im Inneren die /etc/resolv.conf des Hosts und fragt einen Server, der von diesem Netzwerk-Stack aus möglicherweise nicht erreichbar ist.

Das ist ein Problem der Dateiauswahl und kein Routingproblem, und genau deshalb funktioniert das numerische Ziel weiterhin.

Prüfen Sie die Resolver-Sicht, die der Prozess tatsächlich erhält

Gehen Sie nicht davon aus, dass die verwendete Shell dem Prozess entspricht, den Sie debuggen. Eine grafische Anwendung, eine systemd-Unit und ein Container können jeweils in einen anderen Mount- oder Netzwerkkontext eintreten. Führen Sie die Abfrage über denselben Startpfad aus und geben Sie die Resolver-Datei von innen aus.

Für einen mit ip netns add erstellten Namespace ist die Prüfung nur zum Lesen kurz:

ip netns exec vpn cat /etc/resolv.conf

Beachten Sie, ob das Ergebnis eine erreichbare Adresse, einen Loopback-Stub oder einen symbolischen Link nennt, der auf einen Ort mit anderer Erreichbarkeit zeigt.

Was der exec-Helfer tatsächlich einbindet

Das Werkzeug ip-netns dokumentiert die Konfiguration pro Namespace unter /etc/netns/NAME/. Wenn es einen Prozess startet, erstellt der Helfer einen Mount-Namespace und bindet diese Dateien über ihre üblichen Pfade ein, sodass der Prozess die namespacespezifische Kopie sieht. Das ist eine Bequemlichkeit genau dieses Starters. Ein anderer Weg in einen Netzwerk-Namespace, etwa über unshare oder eine Container-Runtime, bildet das nicht automatisch nach.

Der Loopback-Resolver ist hier die Falle: 127.0.0.53 bedeutet den eigenen Loopback des Namespace, nicht den Stub des Hosts. Ein Stub, der nur im Host-Namespace lauscht, wird im neuen nicht zu einem Dienst.

Wählen Sie einen Resolver, den der Namespace erreichen kann

Welchen Server die Datei auch nennt, er braucht weiterhin eine Route aus diesem Namespace. Ein öffentlicher Resolver kann öffentliche Namen beantworten und für eine interne Zone trotzdem scheitern, weil der private Dienst nur über den Tunnel erreichbar ist. Prüfen Sie die Route gleichzeitig mit der Adresse, nicht erst, nachdem die Abfrage bereits gescheitert ist.

Anwendungen mit eigenem Resolver, etwa eine mit DNS over HTTPS, können die Datei völlig ignorieren. Hat das Werkzeug eine eigene DNS-Einstellung, ändert das Ändern von resolv.conf daran nichts, und der Namespace war nie das Problem.

Schreiben Sie die Datei an die richtige Stelle

Legen Sie die Datei pro Namespace unter /etc/netns/NAME/resolv.conf an und lassen Sie den Starter sie präsentieren. Halten Sie sie minimal: ein oder zwei erreichbare Server und die Suchdomains, die die Aufgabe braucht. Bearbeiten Sie nicht die generierte Resolver-Datei des Hosts, um eine für eine Prozessgruppe gedachte Sicht zu reparieren, denn das ändert jede Anwendung auf der Maschine. Nutzt der Host einen Resolver-Manager, konfigurieren Sie den Namespace-Pfad über diesen Manager, statt gegen ihn anzukämpfen.

Halten Sie den Dateiinhalt im Runbook fest. Sonst testet die nächste Person den Resolver des Hosts, sieht eine funktionierende Antwort und schließt, dass der Namespace in Ordnung ist.

Testen Sie den gesamten Pfad erneut

Testen Sie im Namespace mit einer numerischen Adresse, einem internen Namen und einem öffentlichen Namen. Diese Reihenfolge trennt Erreichbarkeit von Auflösung und trennt interne Zonen von öffentlichen. Erstellen Sie den Namespace dann neu und wiederholen Sie es, denn eine Datei, die nur in einer laufenden Instanz existiert, verschwindet mit ihr.

Stellen Sie sicher, dass der Prozess und nicht die Shell die Datei erhält. Eine Abfrage, die aus einer interaktiven Shell funktioniert und aus einem Dienst scheitert, ist ein Befund zum Mount-Kontext, und es lohnt sich, ihn vor dem nächsten Vorfall aufzuschreiben, statt ihn von Grund auf neu zu entdecken.