OpenVPN-DNS auf dem Gateway: dnsmasq plus Firewall-Umfang

dnsmasq auf der Tunneladresse betreiben, DNS nur aus dem Client-Pool erlauben, den Resolver pushen und dann direkte Abfragen und die eigene Suche der App testen.

Clients im Tunnel erreichen das Gateway, und das Gateway erreicht den internen Resolver, also sollte DNS funktionieren. Es funktioniert nicht, weil das zwei verschiedene Berechtigungen sind und ein funktionierender DNS-Dienst eine dritte Sache ist. Der Listener muss auf einer Adresse existieren, die die Clients erreichen, die Firewall muss Abfragen an diese Adresse erlauben, und dem Client muss gesagt werden, dass er ihn benutzt. Den Tunnel in beide Richtungen zu öffnen, löst die ersten beiden zufällig und lässt das dritte unerledigt.

Der Listener ist ein lokaler Dienst mit zwei Richtungen

Eingehend schickt ein Client eine Abfrage an die Tunneladresse des Gateways auf Port 53. Ausgehend leitet der Daemon diese Abfrage an seinen konfigurierten Upstream weiter. Beide Hälften müssen funktionieren, und sie scheitern auf unterschiedliche Weise.

Ein vom Client gemeldeter Timeout und ein am Gateway gesehener Timeout sind nicht derselbe Fehler.

Binden Sie die Tunneladresse, nicht jede Adresse

Eine eigene dnsmasq-Instanz für diese Aufgabe braucht eine ausdrückliche Listen-Adresse, einen Bindemodus, der das Erscheinen des Tunnels nach dem Start verträgt, und einen klaren Upstream. Das ist die kleinste Version, die ich verwende:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic bindet die einzelnen Adressen und kommt damit zurecht, wenn tun0 später erscheint, was auf einem Host wichtig ist, auf dem der VPN-Dienst neu startet. Loopback aufzuführen hält lokale Werkzeuge funktionsfähig, ohne einen öffentlichen Listener hinzuzufügen. no-resolv hindert den Daemon daran, Upstreams aus der Resolver-Konfiguration des Hosts zu erben, und no-hosts hindert diese Instanz daran, die hosts-Datei des Gateways zu veröffentlichen. Keine dieser Optionen gibt irgendjemandem die Berechtigung, den Dienst abzufragen.

Prüfen Sie, ob es einen vorhandenen Listener auf Port 53 gibt, bevor Sie einen zweiten Daemon starten, und verwenden Sie den Konfigurationseigentümer der Distribution statt einer verirrten Datei im falschen Verzeichnis.

Erlauben Sie DNS-Eingang, nicht Tunnel-Transit

Die Firewall-Regeln, die das ermöglichen, sind lokale Eingangsregeln, beschränkt auf die Tunnelschnittstelle, den Client-Pool, die Gateway-Adresse und Port 53. Zwei Regeln, eine pro Protokoll, genügen:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS läuft über TCP wie über UDP, eine reine UDP-Regel lässt große Antworten also auf eine Weise scheitern, die sporadisch wirkt. Das sind keine ufw route Berechtigungen, und sie dürfen keine breite Freigabe auf tun0 werden. Die Reihenfolge zählt so viel wie der Inhalt: eine frühere Regel, die den gesamten Eingang von tun0 verwirft, gewinnt weiterhin, und eine Freigabe unterhalb eines endgültigen Verwerfens bewirkt nichts.

Wenn Gateway-DNS jetzt Teil des Entwurfs ist, überarbeiten Sie diese frühere Richtlinie bewusst und halten Sie fest, warum.

Die Upstream-Hälfte ist ein eigener Pfad

Abfragen verlassen das Gateway von seiner eigenen Adresse in Richtung des Upstream-Resolvers, also müssen die Route des Gateways und die Ausgangsrichtlinie gegenüber diesem Resolver den Austausch erlauben. Das ist eine andere Regel als die, die Clients zum Listener lässt, und sie scheitert mit einem anderen Symptom.

Fügen Sie keinen uneingeschränkten Tunnel-Ausgang hinzu, damit Antworten funktionieren; verfolgte Antworten brauchen ihn nicht.

Pushen Sie die Option und prüfen Sie dann die Übergabe

Der Server kann den Resolver gegenüber Clients mit einer gepushten Option ankündigen. Das ist eine Option, keine Anweisung, der das Betriebssystem folgen muss:

push "dhcp-option DNS 10.90.0.1"

Ein Linux-Kommandozeilenclient braucht möglicherweise die Resolver-Integration seines Verbindungsmanagers, und ein verwaltetes Gerät braucht möglicherweise ein aktualisiertes Verwaltungsprofil. Bestätigen Sie den aktiven Resolver auf dem Client nach dem Verbinden, statt anzunehmen, dass der Push angewendet wurde. Wenn zwei Mechanismen gleichzeitig DNS setzen wollen, entsteht ein Wettlauf, der sich als flatternde Auflösung zeigt.

Ziel ist ein Eigentümer für die Resolver-Konfiguration des Clients, und der Push ist dieser Eigentümer meist nur, wenn die Client-Plattform zustimmt.

Testen Sie, was Sie tatsächlich gebaut haben

Fragen Sie einen privaten vollqualifizierten Namen und einen erlaubten externen Namen direkt gegen die Tunneladresse ab, über UDP und TCP. Wiederholen Sie das dann über den gewöhnlichen Suchpfad der Anwendung.

Wenn die direkten Abfragen funktionieren und die Anwendung weiterhin scheitert, liegt der Fehler in der Übergabe und nicht auf dem Server:

  • Der Client hat die gepushte Option nie angewendet.
  • Ein anderer Resolver wurde später gesetzt und gewann den Wettlauf.
  • Die Anwendung nutzt ihre eigene Resolver-Bibliothek oder eine zwischengespeicherte Antwort.

Schließen Sie damit ab, dass eine Quelle außerhalb des genehmigten VPN-Pfads den Listener überhaupt nicht nutzen kann. Eine erfolgreiche Auflösung berechtigt nicht zu der Adresse, die sie zurückgegeben hat, also halten Sie diese beiden Fragen getrennt.

Ähnliche Artikel