Warum DNS unter Windows nach dem OpenVPN-Verbindungsaufbau ausfällt

Ein Ping an den Resolver im Büro wird auch nach dem Verbindungsaufbau von "OpenVPN" noch beantwortet, und trotzdem schlägt jede Namensauflösung fehl. Die Adresse ist erreichbar, der Port nicht, eine Kombination, die Sinn ergibt, sobald man weiß, dass Windows DNS pro Adapter filtern kann. Mit block-outside-dns im Profil ist dieser Filter der erste Verdächtige, und die Routentabelle ist die falsche Stelle zum Suchen. Die beiden Tests unten trennen die Schichten in Sekunden.

Erreichbare Adresse, toter Port

Ein erfolgreicher Ping beweist, dass der Host läuft und ein Weg existiert. Über die Erlaubnis, Port 53 zu erreichen, sagt er nichts, weil der betreffende Filter auf einer anderen Ebene arbeitet und am Adapter ansetzt. Deshalb kann dieselbe Maschine ICMP beantworten und jede Anfrage an dieselbe Adresse ablehnen. Führen Sie beide Tests in derselben Sitzung aus, bevor Sie irgendeine Konfiguration ändern.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Das Paar ist die Diagnose. Normaler Verkehr ins Subnetz läuft weiter, während die Namensauflösung stirbt, und man schließt, der Server sei defekt oder DNS sei nie übermittelt worden. Beide Erklärungen sind teuer zu verfolgen, und die Belege deuten auf etwas Engeres. Bestätigen Sie das Paar, bevor Sie eine Einstellung anfassen.

Die Option ist eine Regel der Filterplattform

Die OpenVPN-Referenz beschreibt block-outside-dns als Einschränkung der Windows Filtering Platform, die Anwendungen daran hindert, DNS auf Adaptern außerhalb des Tunnels zu erreichen. Sie deckt TCP und UDP Port 53 ab. Weil der Filter in der WFP und nicht in der gewöhnlichen Firewall-Regelliste liegt, ändert eine Freigaberegel an anderer Stelle das Ergebnis nicht zwangsläufig. Deshalb scheitert der übliche Rat, DNS zu erlauben, weiterhin.

Die Einstellung kann aus dem importierten Profil oder vom Server kommen, und die Datei, die Sie zuletzt bearbeitet haben, "ist kein Beleg dafür, was der Client geladen hat". Lesen Sie die wirksame Konfiguration und das Verbindungsprotokoll zusammen. Die Option ist zudem Windows-spezifisch, und sie als übertragbar zu behandeln erzeugt Ratschläge, die nicht gelten.

Suchen Sie die Client-Komponente, die die Einschränkung besitzt, statt weitere Regeln hinzuzufügen. Der Eigentümer ist das, was sie tatsächlich entfernen kann.

Ein Filter ist kein Resolver

Verkehr außerhalb des Tunnels zu blockieren, installiert keinen funktionierenden Resolver darin. Die Option entfernt einen Weg und überlässt die DNS-Konfiguration des Tunnels demjenigen, der das Profil eingerichtet hat. Ein Profil, das nie einen Resolver übermittelt hat, hat jetzt gar keinen.

Arbeiten Sie drei Prüfungen der Reihe nach ab. Erstens, welchen Resolver die fehlschlagende Anwendung tatsächlich nutzt. Zweitens, ob der Client die VPN-DNS-Einstellungen angewendet hat. Drittens, welche Schnittstelle den Verkehr zu diesem Resolver trägt.

1. Verwendeter Resolver: vergleichen Sie Resolve-DnsName -Server <resolver-ip> <name> mit den DNS-Servern, die ipconfig /all auflistet.
2. VPN-DNS angewendet: prüfen Sie die DNS-Einträge des Tunneladapters in derselben Ausgabe von ipconfig /all.
3. Verwendete Schnittstelle: Find-NetRoute -RemoteIPAddress <resolver-ip> benennt die ausgehende Schnittstelle für dieses Ziel.

Ein LAN-Resolver wird unter dieser Richtlinie konstruktionsbedingt unerreichbar, selbst während anderer LAN-Verkehr funktioniert. Das ist die Option bei der Arbeit. Braucht das Design VPN-DNS, korrigieren Sie die Resolver-Registrierung und den Tunnelweg; sind lokale Ausnahmen per Split DNS nötig, muss der Eigentümer der Konfiguration diese Ausnahmen auf unterstützte Weise ausdrücken.

Was die Option nicht abdeckt

Port 53 ist nicht die ganze Namensauflösung. DNS over HTTPS und DNS over TLS nutzen andere Transportwege, und manche Anwendungen führen ihre eigene Resolver-Logik unabhängig von Systemeinstellungen aus. Ein Browser kann Namen daher auflösen, während die Kommandozeile es nicht kann.

Behandeln Sie diesen Unterschied als Diagnose und nicht als Widerspruch. Vergleichen Sie beides, bevor Sie entscheiden, dass der System-Resolver defekt ist.

Halten Sie die Schlussfolgerung eng, wenn Sie sie aufschreiben. Diese Option beschränkt einen Transport auf einer Plattform, und der Rest des Auflösungswegs ist eine eigene Designfrage mit eigenem Eigentümer.

Prüfen Sie den Zustand vor und nach dem Trennen

Führen Sie dieselbe Abfrage während der Verbindung aus und erneut, nachdem der besitzende Client getrennt hat. Die erste sollte für einen externen Resolver fehlschlagen, solange der Tunnel steht, und die zweite sollte gelingen, sobald der Filter entfernt ist. Schlägt sie nach dem Trennen weiterhin fehl, wurde der Filter nicht aufgeräumt.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Ein Neustart des Client-Dienstes oder der Maschine räumt einen veralteten Filter meist auf. Das bestätigt die Diagnose, ohne eine dauerhafte Lösung zu belegen. Notieren Sie, was Sie gesehen haben, denn ein Filter, der ein Trennen übersteht, wird es wieder tun, und der Eintrag ist es, der einen Fehlerbericht rechtfertigt.

Erst nach diesen Prüfungen ist es sinnvoll, den Resolver zu ersetzen oder die Firewall-Richtlinie neu aufzubauen. Beides sind größere Änderungen, als die Belege stützen.