WireGuard schiebt kein DNS: eine private BIND-Zone bereitstellen

Der Handshake trägt Schlüssel und erlaubte IPs, nie einen Resolver. Hier ist eine fertige private BIND-9-Zone plus die Client-Richtlinie pro Link, die sie auflösen lässt.

Sie haben WireGuard hochgebracht, der Tunnel befördert Verkehr, und der interne Name wird weiterhin nicht aufgelöst. Der nächste Schritt ist meist die Suche nach einer DNS-Einstellung in der WireGuard-Konfiguration, als könne ein Peer einen Resolver mitschieben, wie es andere VPNs tun. Kann er nicht. Der Handshake trägt Schlüssel, Schnittstellenadressen und erlaubte IPs, und er hat kein Feld für DNS-Server oder Suchdomänen. Resolver-Richtlinie lebt auf dem Client, und dort gehört die Korrektur hin.

Tunnel und Resolver sind getrennte Verträge

WireGuard ist bewusst klein. Es bewegt Pakete für die Adressen, die Sie auflisten, und authentifiziert Peers; alles oberhalb dieser Schicht ist Ihr Entwurf. OpenVPN kann eine dhcp-option DNS mitschieben, weil sein Steuerkanal Konfiguration trägt, und dieser Unterschied bringt Leute durcheinander, die zwischen beiden wechseln.

Ein funktionierender Tunnel sagt also nichts über Namensauflösung. Der Client kann eine perfekte Route zu 10.90.0.1 haben und seine Anfragen trotzdem an einen öffentlichen Resolver schicken, weshalb das Symptom wie “das VPN hat DNS kaputtgemacht” aussieht, obwohl DNS nie auf das VPN gezeigt hat.

Bedienen Sie die Zone, ohne zum rekursiven Resolver zu werden

Die Serverseite ist eine kleine autoritative Zone, kein allgemeiner Resolver. In diesem Beispiel ist das Gateway 10.90.0.1, die Clients sind 10.90.0.0/24, und die Anwendung, die Sie interessiert, antwortet auf 10.60.0.20.

Führen Sie diese Einstellungen in den vorhandenen options-Block zusammen, statt einen zweiten anzulegen:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Deklarieren Sie dann die Zone und ihre Datei:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Validieren Sie vor dem Neuladen, denn ein Syntaxfehler beim Neuladen reißt den ganzen Server für jede Zone nieder, die er bedient:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Öffnen Sie UDP und TCP 53 nur an der VPN-Schnittstelle. Eine private Autorität an der öffentlichen Schnittstelle zu veröffentlichen, lädt Anfragen und Aufzählung gleichermaßen ein, und allow-transfer sollte geschlossen bleiben, sofern kein Secondary es wirklich braucht.

Richten Sie den Client darauf aus, pro Link

Nehmen Sie an, dass NetworkManager die Verbindung besitzt und systemd-resolved der Resolver ist. Lesen Sie zunächst die bestehende Richtlinie, besonders eine Root-Routing-Domäne, denn ein ~.-Eintrag wird überragen, was Sie gerade hinzufügen.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Die Tilde ist das wichtige Zeichen. Sie markiert die Domäne als Nur-Route: Namen unter corp.example gehen an den DNS-Server dieses Links, und die Domäne wird nicht als Suchsuffix für Kurznamen angehängt. Ohne sie beginnt das Tippen von portal, portal.corp.example aufzulösen, was für Sie praktisch und für alle anderen überraschend ist. Lassen Sie die Tilde innerhalb der Anführungszeichen, denn eine ohne Anführungszeichen ist eine Shell-Expansion, die darauf wartet, auf Ihr Home-Verzeichnis zu zeigen.

Wenden Sie die Änderung über den Manager an, der die Schnittstelle besitzt, und verbinden Sie dann die Verbindung neu. Starten Sie keine zweite wg-quick-Instanz für dieselbe Schnittstelle; zwei Eigentümer werden um Routen streiten, und einer gewinnt im ungünstigsten Moment.

Prüfen Sie den Pfad vor dem Namen

Fragen Sie den Namen vom Client ab und bestätigen Sie sowohl die Antwort als auch den Server, der sie erzeugt hat:

resolvectl query portal.corp.example

Wenn das 10.60.0.20 zurückgibt, ist der DNS-Vertrag erfüllt. Wenn es in ein Timeout läuft, prüfen Sie zuerst die Route zu 10.90.0.1, dann die Firewall-Regel, dann allow-query auf dem Server. Namensauflösungsfehler in diesem Aufbau sind fast immer Erreichbarkeit oder eine ACL, nicht die Zonendatei. Arbeiten Sie vom Client nach außen, denn der Server kann Ihnen nicht sagen, warum eine Anfrage nie ankam.

Denken Sie daran, dass die Anwendung weiterhin ihre eigene Route und ihre eigene Dienstberechtigung braucht. Ein aufgelöster Name, der auf eine unerreichbare Adresse zeigt, ist ein anderer Fehler im selben Gewand.

Was weiterhin nicht automatisch ist

Anwendungen mit eigener Resolver-Logik ignorieren den System-Resolver völlig, und keine Menge nmcli ändert das. Umgebungen, die DNSSEC validieren, brauchen ein ausdrückliches Trust-Anchor-Design für die private Zone; die Antwort ist keine pauschale Anweisung, die Validierung abzuschalten. Testen Sie mit derselben Client-Software, die Ihre Nutzer laufen lassen, nicht mit einem Werkzeug, das zufällig den System-Resolver benutzt. Die Lücke zwischen beiden ist der ganze Fehlerbericht.

Flotten können diese Client-Richtlinie über ihr Provisioning-System automatisieren, aber die Richtlinie bleibt ein separates Objekt mit einem Eigentümer. Die BIND-9-Referenz behandelt die oben verwendeten Listen- und Abfragesteuerungen, und sie ist der richtige Ort, um das Verhalten für Ihre installierte Version zu bestätigen.

Nächster Schritt: Nehmen Sie die Serial-Erhöhung der Zone und die Prüfkommandos in Ihr Änderungsverfahren auf, damit eine Satzbearbeitung nicht ungeprüft in die Produktion gelangen kann.

Ähnliche Artikel