AWS Client VPN mit Split-Tunnel: Welche Routen Sie veröffentlichen sollten

Die Konsole bietet einen Schalter für den Split-Tunnel, also wirkt die Entscheidung wie ein Kontrollkästchen. Ist sie nicht. Was den Client tatsächlich erreicht, ist die veröffentlichte Routenmenge des Endpunkts, und diese Liste entscheidet, welche privaten Präfixe den Tunnel nutzen, ob allgemeiner Internetverkehr lokal bleibt oder über AWS hinausgeht und mit welchem Resolver der Client noch sprechen kann. Drei Fragen klären das Design, und jede lässt sich schlecht beantworten, während die Verbindung trotzdem gelingt.

Ein Split-Tunnel-Flag ist keine Zielliste

AWS beschreibt Split-Tunneling als das Hinzufügen von Endpunkt-Routen zur Routentabelle des Clients beim Verbindungsaufbau. Eine Route für die private VPC begrenzt den Tunnel auf dieses Ziel; alles andere folgt dem gewohnten Pfad des Clients. Eine Standardroute ist eine andere Anweisung mit anderer Wirkung, deshalb warnt die Split-Tunnel-Dokumentation davor, 0.0.0.0/0 auf einem für diesen Modus konfigurierten Endpunkt zu veröffentlichen: Das bricht die Konnektivität eher, als sie zu erweitern. Die Routentabelle des Endpunkts ist die Richtlinie, und die Routentabelle des Clients ist das Ergebnis, das Sie prüfen können.

Lesen Sie die Routentabelle des Endpunkts und die installierten Routen des Clients zusammen. Die Bezeichnung beschreibt eine Absicht; die Routen beschreiben, was passiert.

Entscheidung eins: Soll allgemeiner Internetverkehr lokal bleiben?

Wenn Surfen die eigene Verbindung des Nutzers verwenden soll, veröffentlichen Sie nur die privaten Ziele, die die Aufgabe braucht, und hören Sie dort auf. Fügen Sie keine Internetroute hinzu, nur weil ein Volltunnel-Tutorial eine enthielt, und nehmen Sie nicht an, dass die zusätzliche Route die Sicherheit verbessert. Sie ändert den Pfad, sie fügt keine Richtlinie hinzu, und sie kostet meist Latenz, die Sie nicht eingeplant haben.

Wenn Internetverkehr über AWS hinausgehen soll, bauen Sie die dokumentierte Internetzugriffsarchitektur: Endpunktroute, Autorisierungsregeln, den Pfad des zugeordneten Subnetzes, Sicherheitsrichtlinie und einen funktionierenden Upstream-Ausgang. Eine Standardroute allein liefert nichts davon.

Entscheidung zwei: welche privaten Präfixe, autorisiert von wem?

Veröffentlichen Sie die kleinste Menge von Zielen, die der tatsächlichen Arbeitslast dient, und prüfen Sie, ob jedes zugeordnete Subnetz dorthin routen kann. Das Routenziel des Endpunkts und das VPC-Routing des Subnetzes sind verschiedene Schichten, und eine Route in der einen ist kein Beleg für die andere. Die Autorisierung ist wieder getrennt: Ein Ziel kann erreichbar und trotzdem verweigert sein, weil die Gruppe des Clients keine Regel hat, die es erlaubt.

Eine einzelne erfolgreiche Sitzung zu testen beweist einen Pfad. Prüfen Sie jedes zugeordnete Subnetz, denn eine später hinzugefügte Subnetzzuordnung ist genau der Ort, an dem die fehlende Route meist liegt.

Wenn ein Ziel über den Namen erreichbar sein muss, beachten Sie, dass als Nächstes die Namensauflösung zu klären ist, nicht die Route.

Entscheidung drei: welcher Resolver folgt dem Tunnel?

Ein Client kann einen DNS-Server erhalten, der nur über das VPN erreichbar ist, und dieser Resolver funktioniert nur, wenn seine Adresse selbst in einer autorisierten Route liegt. Prüfen Sie beide Hälften: Die Resolveradresse folgt einer veröffentlichten Route, und der Server antwortet auf die Namen, nach denen die Anwendung fragt. Eine Anfrage, die über die Adresse gelingt, während der Hostname scheitert, deutet auf Namensgebung hin, nicht auf Routing, und das Debuggen des Tunnels verschwendet in diesem Fall den Nachmittag.

Öffentliche Namen sollten so aufgelöst werden wie vor der Verbindung, ein weiterer Grund, präzise zu sein bei dem, was Sie veröffentlichen.

Ändern Sie die Routenmenge und prüfen Sie dann beide Welten

AWS dokumentiert, dass das Ändern von Routen an einem Split-Tunnel-Endpunkt Clientverbindungen zurücksetzt. Planen Sie die Änderung mit diesem Wissen: anwenden, über den unterstützten Client neu verbinden und die installierten Routen neu lesen, statt dem vor der Bearbeitung angewandten Zustand zu vertrauen. Veralteter angewandter Zustand ist der häufigste Grund, warum eine korrekte Änderung kaputt aussieht.

Akzeptieren Sie das Design erst, wenn sich eine private Ressource und ein öffentliches Ziel beide wie beabsichtigt verhalten, nach Name und nach Adresse, in den Adressfamilien, die Sie tatsächlich unterstützen. Ein Tunnel, der authentifiziert, ist nicht dasselbe wie ein Tunnel, der korrekt aufteilt.

Schreiben Sie die Routenliste neben der Begründung ins Runbook, damit die nächste Person eine absichtliche Auslassung von einer vergessenen unterscheiden kann.