Ihr Split-Tunnel erreicht die App, aber nicht ihren DNS-Server

Das Subnetz der Anwendung zu routen ist der offensichtliche Teil eines Split-Tunnels, und es ist nicht die ganze Aufgabe. Der Resolver sitzt oft auf einer anderen Adresse als die Anwendung, der er dient, sodass ein funktionierender Tunnel die Abfrage dennoch außerhalb lassen kann. Ein Profil, das 10.80.0.0/16 und sonst nichts trägt, schickt die Abfrage für 10.90.0.53 über die lokale Schnittstelle, wo keine private Zone existiert. Fügen Sie den Pfad zum Resolver hinzu und sehen Sie sich dann die zweite Hälfte des Problems an: welchen Server der Client tatsächlich wählt.

Der Mythos: eine Route deckt den ganzen Dienst ab

Ein Split-Tunnel ist eine Liste von Zielen, die durch die Verbindung gehen, keine Beschreibung eines Dienstes. Das Anwendungs-Subnetz und die Resolver-Adresse sind zwei Ziele, und ein Profil kann das eine ohne das andere tragen. Wenn das passiert, ist die Anwendung über die Adresse erreichbar, während ihr Name scheitert, was eher wie ein DNS-Fehler als wie eine Routing-Lücke aussieht.

Das Subnetz um den Resolver ist auch nicht automatisch abgedeckt. Eine Host-Route zu einer einzelnen Adresse reicht für diesen Resolver und öffnet seine Nachbarn nicht. Das ist der Sinn einer Host-Route: schmal by design und leicht zu vergessen, wenn der nächste Dienst im selben Subnetz auftaucht.

Drei Dinge müssen zutreffen, damit die Abfrage funktioniert: Der Client routet die Resolver-Adresse durch den Tunnel, das Gateway nimmt diese Anfrage an und leitet sie weiter, und der Resolver akzeptiert die Quelle, die er erhält. Eine Antwort muss außerdem auf dem vereinbarten Weg zurückkommen. Fehlt eines davon, ist das Symptom identisch, weshalb es sich lohnt, die Adresstabelle aufzuschreiben, bevor man eine Konfiguration anfasst.

Ermitteln Sie, welche Adressen das Profil tragen muss

Listen Sie die Ziele der Reihe nach auf: das Anwendungsnetz, die Resolver-Adresse und den öffentlichen Endpunkt, der den Tunnel selbst terminiert. Das dritte darf niemals in den Tunnel geroutet werden, weil die äußere Verbindung einen Weg braucht, der existiert, bevor der Tunnel existiert.

Nehmen Sie sowohl UDP als auch TCP für DNS auf, da von Implementierungen erwartet wird, TCP neben UDP zu unterstützen, und ein blockierter TCP-Pfad langsame, teilweise Fehler statt sauberer erzeugt. Wird die private Zone auch über IPv6 bedient, verwendet die entsprechende Host-Ausnahme eine IPv6-Adresse und ein Präfix und ist ein eigener Eintrag.

Notieren Sie, was das Profil bereits abdeckt, bevor Sie etwas hinzufügen. Eine doppelte Route ist harmlos, aber eine unerwartete bestehende Route sagt Ihnen, dass das Profil für einen anderen Adressplan entworfen wurde als den, den Sie erhalten haben.

Fügen Sie die Host-Route über den Eigentümer der Verbindung hinzu

Bei einem lokal verwalteten nativen Windows-Profil gehört die Route zur Verbindung und nicht zur globalen Routing-Tabelle des Rechners. Zeigen Sie die Ergänzung zuerst in der Vorschau an und wenden Sie sie dann mit demselben Bereich an, den das Profil verwendet.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

Der erste Befehl zeigt die Änderung als Vorschau, ohne etwas zu installieren, und der zweite listet die Routen auf, die das Profil derzeit trägt. Microsofts Referenz zu Add-VpnConnectionRoute dokumentiert die Bereiche pro Benutzer und für alle Benutzer; ein Profil für alle Benutzer braucht seinen eigenen Bereichsparameter, und ein Befehl pro Benutzer gegen ein Profil für alle Benutzer schlägt fehl oder landet am falschen Ort.

Wenn das Profil verwaltet wird oder von einem Herstellerclient stammt, gehört die Änderung diesem Eigentümer. Eine permanente Systemroute über eine Verbindungsrichtlinie zu stapeln funktioniert, bis die Richtlinie erneut angewendet wird und die Route verschwindet, was normalerweise während eines Supportanrufs und nicht während des Testens geschieht. Dieser Fehler ist still: Die Route verschwindet, der Name löst nicht mehr auf, und niemand verbindet die beiden Ereignisse. Legen Sie die Änderung im eigenen Datensatz des Eigentümers ab, damit die nächste erneute Anwendung sie trägt, statt sie zu löschen.

Verbinden Sie das Profil nach dem Anwenden neu, statt anzunehmen, die Route sei wirksam geworden. Routenänderungen an einer laufenden Verbindung werden nicht immer übernommen, und ein erneutes Verbinden stellt auch den Zustand her, den Ihre Benutzer tatsächlich haben werden.

Prüfen Sie, welchen Resolver der Client tatsächlich verwendet hat

Eine Route steuert Pakete, die an den Resolver adressiert sind. Sie entscheidet nicht, welche Namen dorthin geschickt werden sollen, und diese Auswahl ist ein eigener Mechanismus. Unter Windows können effektive Namespace-Regeln einen Resolver pro Domäne wählen, während die DNS-Einstellungen des Profils einen Standard liefern. Diese beiden Schichten können sich widersprechen, ohne einen Fehler zu erzeugen, weshalb eine direkte Abfrage nur die Hälfte des Beweises ist.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

Der erste Befehl gibt die geltende Namespace-Richtlinie aus, und der zweite fragt den privaten Resolver direkt nach dem Namen der Anwendung. Eine direkte Antwort beweist, dass der Pfad und der Resolver funktionieren; sie beweist nicht, dass die eigene Abfrage der Anwendung diesen Server gewählt hat. Vergleichen Sie sie mit einer normalen Abfrage desselben Namens und mit der Antwort, die die Anwendung erhält.

Berücksichtigen Sie Caches und sicheres DNS auf Browserebene, das den System-Resolver für vom Benutzer eingegebene Namen vollständig umgehen kann. Ein Suchsuffix ist eine weitere falsche Fährte: Es erweitert einen kurzen Namen zu einem voll qualifizierten und hat nichts damit zu tun, welcher Server antwortet.

Schließen Sie ab, indem Sie neu verbinden und die normale Abfrage wiederholen, und bestätigen Sie dann, dass gewöhnliches Surfen weiterhin seiner genehmigten Richtlinie folgt. Den privaten Resolver durch einen öffentlichen zu ersetzen, damit ein unabhängiger Name auflöst, ist keine Reparatur, und es verschiebt private Abfragen still dorthin, wo sie nie hingehören sollten.