Windows-VPN-DNS-Leak: Warum die Metrik die Route schlägt

Eine Abfrage verlässt den Rechner und erreicht den Heimrouter, während jedes Paket getunnelt wird. Die naheliegende Schlussfolgerung ist eine fehlende Route, und die Route ist meist in Ordnung. Windows kann anhand der Schnittstellenmetrik wählen, welcher Resolver befragt wird, und ein Tunneladapter verliert diesen Vergleich häufig gegen den drahtlosen.

Zwei Erklärungen für ein Leck

Die Routenerklärung besagt, dass ein Teil des Verkehrs dem Tunnel entkommt, also müssen die Standardroute oder die Split-Tunnel-Liste falsch sein. Diese Erklärung lässt sich mit einem Befehl prüfen, und wenn die Standardroute in den Tunnel zeigt, ist sie erledigt. Prüfen Sie sie zuerst, weil sie billig ist, und legen Sie sie dann beiseite, wenn sie sauber zurückkommt.

Die Rangfolgenerklärung besagt, dass der Verkehr vollständig getunnelt ist und die Abfrage dennoch an einen anderen Resolver geht. Windows behandelt die Resolver-Wahl als eine Eigenschaft je Schnittstelle mit einer Reihenfolge, sodass ein physischer Adapter mit besserer Metrik DNS für einen Namen liefern kann, obwohl die Pakete zur aufgelösten Adresse durch den Tunnel laufen. Beide Erklärungen erzeugen auf einer Leak-Testseite dasselbe Symptom, weshalb der Test nicht die Diagnose ist. Nur eine davon wird durch Bearbeiten von Routen repariert.

Metriken und Resolver gemeinsam vergleichen

Notieren Sie die Schnittstellen, ihre Metriken und ihre konfigurierten Server, solange der Tunnel läuft. Lesen Sie sie als Tabelle und nicht als zwei getrennte Listen, denn die Frage ist, welcher Resolver zuerst kommt, nicht welche Resolver existieren.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Trägt der Tunneladapter eine höhere Zahl als der physische Adapter, ist sein Resolver nicht bevorzugt, und ein interner Name geht an das, was die physische Seite anbietet. Dieser Router kann aus dem Cache antworten, die Abfrage weiterleiten oder sie ablehnen, und keines dieser Ergebnisse ist das Design, das Sie wollten. Die Rangfolge ist eine Präferenz, also verliert sie still, statt einen Fehler zu melden.

Ein Tunneladapter ganz ohne konfigurierten Resolver ist eine ebenso häufige Variante. Der Client bringt die Schnittstelle hoch, ohne DNS zu schieben, sodass sich die Rangfrage gar nicht stellt.

Den Tunnel hochstufen und erneut prüfen

Geben Sie der Tunnelschnittstelle in einer erhöhten Shell die niedrigste Metrik, oder erhöhen Sie den Wert des physischen Adapters. Beides sind Einstellungen je Schnittstelle und beides ist umkehrbar, was zählt, wenn Sie einen Rechner ändern, vor dem Sie vielleicht nicht sitzen.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Die Änderung ist sofort sichtbar, und der DNS-Client und andere Verbraucher cachen die bereits getroffene Wahl. Verbinden Sie den Tunnel neu oder starten Sie neu, bevor Sie etwas in ein Abfrageergebnis hineinlesen. Ein zu früh ausgeführter Test wiederholt das alte Verhalten und sieht wie eine gescheiterte Reparatur aus.

Fragen Sie dann einen internen und einen öffentlichen Namen ab und prüfen Sie, welcher Server geantwortet hat. Microsofts Referenz zu automatischen Metriken erklärt, warum der niedrigste Wert bevorzugt wird und wie die automatische Zuweisung abgeleitet wird.

Über eine Neuverbindung hinweg haltbar machen

Eine manuelle Metrik auf einem Adapter, der bei jeder Verbindung neu erstellt wird, ist eine Einstellung, die verschwindet. Baut der Client die Schnittstelle neu auf, braucht die Überschreibung ein Skript nach dem Verbinden, eine Richtlinie oder eine Clientkonfiguration, die DNS besitzt, solange die Verbindung steht.

Statisch konfigurierte Server auf dem physischen Adapter haben dasselbe Haltbarkeitsproblem umgekehrt. Sie antworten weiter für diese Schnittstelle, bis sie entfernt werden, und DHCP füllt sie mit dem nächsten Lease wieder auf, sodass ihr Entfernen eine Messung und kein Design ist. Das haltbare Design ist eine Namensauflösungsrichtlinie für den internen Namensraum, oder ein Client, der DNS für die Dauer der Verbindung übernimmt. Notieren Sie in jedem Fall die Resolver-Liste vor und nach einer Neuverbindung, stellen Sie die ursprüngliche Metrik wieder her, wenn Sie mit dem Testen fertig sind, und bestätigen Sie, dass das frühere Verhalten zurückgekehrt ist.