Domänenbasiertes VPN-Routing versus IP-Routen: Was passt?
Ein Hostname in einem Split-Tunnel-Feld ist keine Route. Vergleichen Sie Domänenregeln und explizite Präfixe bei Aktualisierung, Subdomänenabdeckung und dem Verhalten bei DNS-Änderungen.
Eine IP-Route entspricht einem Adresspräfix, und der Kernel wendet sie an, ohne weitere Fragen zu stellen. Eine domänenbasierte VPN-Regel entspricht einem Namen, was bedeutet, dass irgendetwas im Stack entscheiden muss, welche Adressen dieser Name aktuell bezeichnet, und diese Entscheidung aktuell halten muss. Das sind verschiedene Mechanismen mit unterschiedlichen Fehlerarten, und Anbieter verwenden für beides dasselbe Wort. Ein Vergleich in Funktionslisten verfehlt den Punkt; vergleichen Sie sie danach, was passiert, wenn sich die Antwort ändert.
Die nützliche Trennung verläuft zwischen einer Regel, die auflöst, und einer Regel, die es nicht tut.
Womit jede Regel tatsächlich übereinstimmt
Eine Präfixregel entspricht Zieladressen in einer Routing-Tabelle. Nichts wird aufgelöst, nichts läuft ab, und die Übereinstimmung ist für jedes Paket exakt. Eine Domänenregel entspricht der Anfrage einer Anwendung nach einem Namen, den RFC 1034 als einen Baum von Labels und nicht als Adresse definiert. Manche Produkte lösen den Namen einmal auf und installieren die resultierenden Adressen als Routen, wodurch die Regel zu einer IP-Regel mit angehängtem Aktualisierungs-Timer wird.
Wissen Sie, welche der beiden Sie haben, bevor Sie debuggen, denn der Fehler sieht in jedem Fall völlig anders aus.
Wo die Domänenregel im Stack sitzt
Wenn das Produkt Domänenregeln über einen lokalen Proxy umsetzt, muss der Datenverkehr diesen Proxy erreichen, und Anwendungen, die den Systemproxy ignorieren, umgehen die Regel vollständig. Wenn es sie durch Auflösen von Namen und Hinzufügen von Routen umsetzt, sind die Adressen nur so frisch wie die letzte Aktualisierung. Wenn es den Resolver abfängt, wird das DNS-Verhalten Teil der Routing-Richtlinie, und ein Ausweich-Resolver kann sie stillschweigend rückgängig machen.
Lesen Sie das Modell des Anbieters statt das Etikett der Einstellung. Zwei Clients mit einem Feld namens Split Tunnel können drei verschiedene Dinge tun.
Vergleichen Sie, was kaputtgeht
Drei Dinge gehen unterschiedlich kaputt. Adresswechsel: Ein CDN-Hostname kann innerhalb von Minuten zu einem anderen Adresssatz auflösen, sodass eine kopierte Liste schnell veraltet. Subdomänenabdeckung: Eine Regel für example.com deckt api.example.com möglicherweise ab oder nicht, und die Dokumentation ist normalerweise eindeutig, welcher Fall gilt. Auflösungsfehler: Wenn der Resolver ausfällt, kann ein auflösender Client auf das Tunneln des Datenverkehrs oder auf direktes Senden zurückfallen.
Nur das zweite ist eine Konfigurationsfrage. Die anderen beiden sind Designfragen dazu, wie viel das Produkt raten will.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
Wann das Präfix die bessere Antwort ist
Für ein stabiles privates Subnetz ist ein explizites Präfix klarer, schneller und leichter zu prüfen. Es übersteht auch einen Resolver-Ausfall, weil nichts aufgelöst werden muss. Greifen Sie zu einer Domänenregel, wenn der Dienst gehostet wird, wenn Adressen rotieren oder wenn Sie die Zielmenge wirklich nicht aufzählen können. Greifen Sie nicht nur deshalb danach, weil der Hostname das ist, was Sie zufällig kennen.
Eine geratene statische Liste ist das Schlechteste aus beidem: Sie sieht gepflegt aus und übersieht stillschweigend Datenverkehr an dem Tag, an dem der Anbieter einen Host hinzufügt.
Prüfen Sie mit einer frischen Anfrage
Testen Sie mit einer kalten Anfrage nach einer normalen Wiederverbindung, denn eine zwischengespeicherte Seite berührt die Regel möglicherweise nie. Lösen Sie den Namen auf und prüfen Sie dann, wohin die Verbindung tatsächlich ging. dig +short app.example.com liefert den aktuellen Adresssatz, und die Verbindungsliste des Clients sagt Ihnen, welche Schnittstelle den Datenfluss getragen hat.
Wiederholen Sie das nach dem Aktualisierungsintervall, das das Produkt dokumentiert. Wenn der Adresssatz wandert und die Regel nicht folgt, haben Sie das echte Verhalten gefunden.
Halten Sie auch die Resolver-Richtlinie getrennt. Eine Domänenregel braucht korrekte Namensdaten, entscheidet aber nicht von sich aus, welcher Resolver die Abfrage beantwortet.