Verschlüsselt Ihr VPN DNS – oder nur den nächsten Hop?

Das Aktivieren von verschlüsseltem DNS auf dem VPN-Server wird oft als Schließen eines Leaks beschrieben, und diese Beschreibung verbirgt, welche Verbindung sich geändert hat. Der Hop vom Client zum Resolver und der Hop vom Resolver zum Upstream sind getrennte Verbindungen mit getrennten Eigentümern. Verschlüsselt man eine davon, bleibt die andere genau so, wie sie war.

Schreiben Sie auf, wer die Anfrage in jeder Stufe erhält, bevor Sie eine Konfigurationsdatei anfassen.

Zwei Anordnungen sehen auf einer Einstellungsseite gleich aus

In der ersten Anordnung betreibt das Gerät DNS over TLS selbst, und der Tunnel trägt diese Verbindung nur zu einem Resolver Ihrer Wahl. Die TLS-Sitzung endet am Resolver, das heißt, der Resolver sieht die Anfrage, und der VPN-Ausgang sieht Chiffrat, das er nicht lesen kann. In der zweiten Anordnung sendet das Gerät gewöhnliches DNS durch den Tunnel an einen Weiterleiter auf dem VPN-Host, und dieser Weiterleiter öffnet seine eigene verschlüsselte Verbindung zu einem vorgelagerten Resolver. Beide sehen in einer Funktionsliste wie "verschlüsseltes DNS mit einer VPN" aus, und sie legen die lesbare Anfrage in verschiedene Gebäude.

Der Unterschied ist messbar und nicht philosophisch. Suchen Sie die TLS-Sitzung auf dem Client oder auf dem Server, und Sie wissen, welche Anordnung Sie tatsächlich haben.

Kartieren Sie die Resolver-Kette, bevor Sie sie ändern

Zählen Sie die Resolver auf dem Weg und benennen Sie die Rolle jedes einzelnen. Eine weiterleitende Komponente übergibt eine Anfrage an einen anderen Resolver, während ein rekursiver Resolver die Arbeit des Antwortfindens erledigt und möglicherweise direkt mit autoritativen Servern spricht. Diese Rollen werden genau deshalb getrennt definiert, und die Resolver-Definitionen in RFC 9076 lohnen sich zu lesen, bevor Sie annehmen, dass es ein einziges Upstream-Ziel gibt. Ein Host, der seinen eigenen rekursiven Resolver betreibt, hat kein einziges "Upstream", das er verschlüsseln könnte, was den ganzen Plan ungültig macht.

Fragen Sie dann, welche Komponente der Client verwenden soll. Eine DNS-Adresse, die das VPN-Profil zustellt, sagt Ihnen, wohin Anfragen gehen, nicht welcher Prozess sie beantwortet.

Beachten Sie auch das Fehlerverhalten. Wenn der verschlüsselte Upstream unerreichbar wird, schlägt der Weiterleiter dann geschlossen fehl, fällt er auf Klartext zurück oder auf einen anderen Resolver? Diese Entscheidung gehört in den Bericht, weil sie die Datenschutzgarantie in dem Moment verändert, in dem der Tunnel am wenigsten gesund ist.

Prüfen Sie, welcher Hop verschlüsselt ist

Beginnen Sie beim Client und bestätigen Sie, ob er eine TLS-Sitzung zu Port 853 hält. Eine Anfrage, die über Port 53 korrekt aufgelöst wird, beweist nichts über Verschlüsselung.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Gehen Sie dann zum VPN-Host und suchen Sie die ausgehende verschlüsselte Verbindung, die der Weiterleiter geöffnet hat. Die Socket-Tabelle sagt Ihnen, ob eine Upstream-TLS-Sitzung existiert und welcher Prozess sie besitzt:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Zeigt der Client eine TLS-Sitzung und der Server keine, sind Sie in der ersten Anordnung, und der Server kann Anfragen, die er auf IP-Ebene weiterleitet, nicht lesen. Zeigt der Server die TLS-Sitzung und der Client gewöhnlichen Datenverkehr auf Port 53 innerhalb des Tunnels, sind Sie in der zweiten Anordnung: Der weitere Hop ist geschützt, und der Weiterleiter liest weiterhin jeden Namen, den das Gerät anfragt. Dieses zweite Ergebnis ist kein Fehler, aber es Ende-zu-Ende-Verschlüsselung zu nennen, ist falsch.

Eigentümer und Fehlerverhalten festhalten

Eigentum entscheidet, was Sie versprechen dürfen. Der Geräteeigentümer kontrolliert eine verschlüsselte Verbindung auf Client-Seite, während der VPN-Administrator die weitere Verbindung kontrolliert, die sein Weiterleiter aufbaut. Wer keines von beiden betreibt, kann den Weg nur beschreiben.

Prüfen Sie vor dem Aktivieren die interne Namensgebung. Organisationsnamen an einen öffentlichen Resolver zu senden ist kein gleichwertiges Design, und eine Split-Horizon-Zone, die nur innerhalb des Netzwerks existiert, wird upstream überhaupt nicht aufgelöst. Testen Sie nach der Änderung einen internen und einen öffentlichen Namen und bewahren Sie das Ergebnis zusammen mit der Konfigurationsänderung auf. Wenn der verschlüsselte Weg die Auflösung für interne Hosts bricht, ist die Lösung eine Resolver-Regel mit begrenztem Geltungsbereich und kein breiterer Tunnel.

Schließen Sie ab, indem Sie einen Satz pro Hop schreiben: welche Komponente die Anfrage erhalten hat, ob dieser Hop verschlüsselt war und wer den Namen lesen kann. Wenn der Satz für den VPN-Host weiterhin sagt, dass er Anfragen lesen kann, sollte die Dokumentation das sagen, denn einem Diagramm, das etwas anderes behauptet, wird jemand vertrauen, der die Befehle nie ausgeführt hat.