Privates DNS in Pritunl fehlgeschlagen? Eine schmale Resolver-Route hinzufügen

Private Namen werden im Unternehmensnetz für alle aufgelöst und laufen im VPN für alle in einen Timeout. Der Resolver antwortet dem Gateway, die Route dorthin existiert, und die Abfrage bekommt trotzdem nie eine Antwort. Was fehlt, ist kein weiterer öffentlicher Resolver und keine breitere Route: Es fehlt eine Quelladresse, auf die der private DNS-Server antworten will.

Bestätigen Sie, dass der Resolver Ihren Client-Pool ablehnt

Beweisen Sie zuerst, dass der Fehler an der Quelle liegt und nicht an der Erreichbarkeit. Fragen Sie von einem verbundenen Client den privaten Resolver direkt ab und beobachten Sie, ob die Anfrage in einen Timeout läuft oder als Ablehnung zurückkommt. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 mit Timeout, während dieselbe Abfrage vom Gateway gelingt, deutet auf eine Zugriffsrichtlinie am Resolver hin. Eine SERVFAIL-Antwort deutet auf etwas ganz anderes hin, meist auf die Zone oder den vorgelagerten Forwarder.

Notieren Sie die Adresse des Clients vor dem Test. ip -4 addr show tun0 auf dem Client oder die in der Konsole angezeigte Lease sagt Ihnen, welchen Pool der Resolver sieht.

Prüfen Sie dann, ob der Pfad überhaupt existiert. Eine Route, die die Resolver-Adresse in den Tunnel schickt, ist Voraussetzung, nicht die Lösung; kommen Pakete nie an, wird die Quellrichtlinie nie befragt. Prüfen Sie das mit ip route get 10.40.0.53 auf dem Client.

Fügen Sie eine Host-Route hinzu, statt alles zu übersetzen

Pritunls Anleitung für privates DNS beschreibt das schmale Mittel: eine NAT-fähige /32-Route für die Resolver-Adresse, wobei diese Adresse als DNS-Server der Clients ausgewählt wird. Die Route ändert die Quelle, die der Resolver sieht, nur für DNS-Verkehr. Anwendungsverkehr behält das quellenerhaltende Design, das Sie dafür gewählt haben.

Konfigurieren Sie sie über den unterstützten Routeninhaber des Servers, nachdem Sie bestehende Routen auf Überschneidungen geprüft haben. Im obigen Beispiel ist das Ziel 10.40.0.53/32 mit aktiviertem NAT, und der Client-Pool bleibt 10.90.0.0/24. Übersetzen Sie nicht den gesamten privaten Bereich, um einen Dienst zu reparieren, denn jede nachgelagerte Richtlinie, die auf der echten Adresse des Clients beruht, wird stattdessen das Gateway sehen. Bestätigen Sie die Adresse, die der Resolver tatsächlich erhält, indem Sie während einer Testauflösung sein Abfrageprotokoll beobachten. Eine Host-Route allein beweist nichts über Übersetzung oder Erlaubnis.

Der Resolver muss die übersetzte Quelle weiterhin über UDP und TCP zulassen, und seine Antworten müssen zurückkehren können. Eine Quellenänderung kann keine fehlende Zone und keinen fehlenden Datensatz erzeugen.

Entscheiden Sie, ob der Server oder der Client die Abfrage sendet

Pritunl dokumentiert außerdem eine DNS-Proxy-Anordnung, die an VPN Client DNS Mapping gebunden ist, bei der der Server vorgelagerte Abfragen für Clients weiterleitet. In diesem Modell gehört die vorgelagerte Quelle zum eigenen Netzwerkkontext des Servers, und eine Ausnahme auf Client-Seite ist die falsche Lösung.

Stellen Sie vor jeder Änderung fest, welches Modell aktiv ist. Drei überlappende Reparaturen, ein Proxy, eine Resolver-Überschreibung am Client und ein manuelles NAT-Skript bedeuten meist, dass niemand festgestellt hat: welche Komponente die Abfrage senden soll. Prüfen Sie auch den Bootstrap: Ein rein privater Resolver kann nicht der einzige Weg sein, den Endpunkt zu finden, bevor der Tunnel existiert, und eine dauerhafte Resolver-Änderung sollte die Verbindung nicht überleben.

Testen Sie eine private Auflösung, keine öffentliche Webseite

Prüfen Sie nach dem Anwenden der Änderung und dem erneuten Verbinden die effektive Resolver-Konfiguration des Clients und lösen Sie dann einen Namen auf, von dem Sie wissen, dass er nur in der privaten Zone existiert. dig intranet.example.net ohne ausdrücklichen Server zeigt, was der Client tatsächlich nutzt. Folgen Sie dem mit einer Anfrage an die Adresse, die diese Auflösung zurückgegeben hat, denn Auflösung und Dienstzugriff sind getrennte Schritte. Ein Browser, der öffentliche Seiten über DNS-over-HTTPS lädt, beweist nichts über den privaten Resolver-Pfad des Betriebssystems. Ein öffentlicher sekundärer Resolver ist auch keine Autorität für eine interne Zone.

Notieren Sie Resolver-Adresse, /32-Route und Client-DNS-Einstellung zusammen in den Server-Notizen. Die Hälfte dieser Konfiguration, allein wiederhergestellt, reproduziert den ursprünglichen Fehler.

Bestätigen Sie schließlich, dass der Tunnel das Anwendungsziel nach erfolgreichem DNS weiterhin routet. Route, Dienstzugriff und Authentifizierung bleiben unabhängig von der Namensauflösung, und eine funktionierende Auflösung sagt nichts über den Durchsatz. Wenn die private Seite langsam ist, aber aufgelöst wird, hat der Resolver seine Arbeit getan und das Problem ist auf den Pfad gewandert.