Das Netzwerk eines VPN-Containers teilen: Was mit DNS passiert

Das Teilen des Netzwerk-Namensraums eines VPN-Containers gibt Ihrer Anwendung die Schnittstellen und Routen des Tunnels. Er gibt ihr nicht den Resolver des Tunnels, auch keine zusammengeführte Kopie von irgendetwas anderem auf dem Host. Diese Lücke erzeugt einen sehr spezifischen Fehler: Öffentliche Namen werden aufgelöst, interne nicht, und die fehlschlagende App sieht aus, als würde sie den falschen DNS-Server verwenden, weil sie es tut. Die Reparatur ist meist kleiner, als die Diagnose vermuten lässt.

Schritt 1: Testen Sie aus der App, nicht vom Host

Führen Sie die Auflösung im betroffenen Container aus, nicht auf dem Host und nicht in einem Browser. docker exec app-container getent hosts db.internal beantwortet die einzige wichtige Frage: Was gibt der Resolver dieses Prozesses zurück.

Löst der Host den Namen auf und der Container nicht, haben Sie den Fehler gefunden. Alles Weitere ist die Wahl eines unterstützten Wegs, ihn zu beheben.

Schritt 2: Lesen Sie das unterstützte Modell der Laufzeitumgebung

Dockers Netzwerkdokumentation verzeichnet Einschränkungen für DNS-Flags bei Containern, die den Netzwerkmodus eines anderen Containers teilen. In Compose network_mode: service:vpn bindet die App an den Namensraum des VPN-Containers, und pro Dienst dns verhalten sich die Einstellungen nicht wie bei einem gewöhnlichen Dienst. Die Auflösung, die Sie erhalten, ist die, über die der gemeinsame Namensraum verfügt.

Benutzerdefinierte Bridge-Netzwerke nutzen Dockers eingebettetes DNS ebenfalls anders als die Standard-Bridge. Deshalb kann eine dns Klausel, die aus einem funktionierenden Bridge-Beispiel kopiert wurde, in einem gemeinsamen Stack gar nichts bewirken. Prüfen Sie die Regelung, bevor Sie die Klausel kopieren.

Eine Loopback-Adresse bezieht sich immer auf den jeweiligen Netzwerkkontext. Innerhalb eines gemeinsamen Namensraums ist 127.0.0.1 nicht der Resolver des Hosts.

Schritt 3: Verfolgen Sie die Abfrage bis zu ihrem Empfänger

Lesen Sie die Resolver-Konfiguration der App, dann jedes anwendungsspezifische verschlüsselte DNS, das die App mitbringt, denn eine App mit eigenem Resolver ignoriert die Datei, die Sie bearbeitet haben. Prüfen Sie dann, ob der gewählte Resolver unter den Routen und der Firewall-Richtlinie des VPN erreichbar ist. Eine Resolver-Adresse auf der anderen Seite des Tunnels ist nutzlos, wenn der Namensraum keine Route dorthin hat. Bestätigen Sie den Empfänger, bevor Sie eine Datei bearbeiten.

Eine IP-Prüfseite im Browser kann Ihnen nicht sagen, wohin Namensabfragen gegangen sind. Sie sagt Ihnen, wohin eine HTTP-Verbindung gegangen ist.

Schritt 4: Beheben Sie die beiden Fehlerklassen unterschiedlich

Wenn Dienstnamen fehlschlagen, während öffentliche Namen funktionieren, liegt das Problem in der Dienstentdeckung innerhalb des Containernetzwerks, nicht in der Liste öffentlicher Resolver. Jede öffentliche DNS-Adresse zu ändern erzeugt keine Einträge, nach denen der Entdeckungsmechanismus des Netzwerks nie gefragt wurde.

Wenn beide Klassen fehlschlagen, beginnen Sie mit der Erreichbarkeit des Resolvers. Wenn nur eine fehlschlägt, beginnen Sie mit dem Entdeckungsmechanismus. Die beiden haben verschiedene Eigentümer, deshalb deckt eine Reparatur nie beide ab.

Schritt 5: Testen Sie nach der Neuerstellung erneut

Ändern Sie die Konfiguration über den unterstützten Mechanismus der Laufzeitumgebung und erstellen Sie dann die Container neu, statt Dateien in einem laufenden zu bearbeiten. Testen Sie einen frischen privaten Namen, einen frischen öffentlichen Namen und die Anwendungsanfrage, die der Auflösung folgt. Eine Änderung an /etc/resolv.conf in einem Container verschwindet bei der Neuerstellung und wird Sie überzeugen, dass die Reparatur funktioniert hat, obwohl sie es nicht tat.

Notieren Sie den Eigentümer des Resolvers und den erwarteten Namensraum neben der Definition des gemeinsamen Netzwerks. Die nächste Person wird beides brauchen.