LAN hinter einer AWS Client VPN-Sitzung: Was weitergeleitet wird

Der Laptop verbindet sich mit dem AWS Client VPN-Endpunkt, erreicht das private Subnetz, und alles sieht gesund aus. Der Desktop im selben LAN erreicht nichts, obwohl der Linux-Host ebenfalls eine Bridge-Schnittstelle hat und beide Maschinen am selben Kabel hängen. Im Tunnel ist nichts falsch konfiguriert; das fehlende Teil ist das Routing, und die Bridge ist eine falsche Fährte.

Eine Client VPN-Sitzung auf ein LAN auszudehnen ist eine Gateway-Rolle. Es ist kein Ethernet-Segment, das in einen verwalteten Dienst gestreckt wird.

Der Host funktioniert, das LAN nicht

Die Tunnelschnittstelle auf der Linux-Kiste hat eine Adresse innerhalb des Client VPN-Client-CIDR, und der Endpunkt hat Routen für die VPC-Bereiche gepusht. Eine Anfrage auf dieser Kiste ist lokal erzeugter Verkehr: Sie wählt eine Route, verlässt den Host durch den Tunnel und bekommt eine Antwort. Dieser Pfad berührt nie den Weiterleitungscode, die LAN-Schnittstelle oder eine Firewall-Regel, die den Transit regelt.

Verkehr von einem anderen LAN-Gerät ist ein anderer Fluss. Er kommt an der LAN-Schnittstelle an, braucht eine Route in den Tunnel, braucht aktivierte Weiterleitung, braucht eine Firewall, die ihn erlaubt, und braucht die Antwort über denselben Host zurück. Vier Anforderungen, und der funktionierende Laptop-Test beweist keine davon. Vom Desktop aus wirkt der Fehler bizarr: Der Tunnel steht, die Anmeldedaten sind gültig, und das Ziel antwortet einfach nie. Der Defekt liegt lokal im Weiterleitungspfad des Gateways, nicht im Dienst.

Nicht jeder Client kann ein Gateway sein

AWS gibt an, dass seine Client VPN-Desktop-App die IP-Weiterleitung nicht unterstützt und andere Clients dies möglicherweise tun. Diese Einschränkung entscheidet die Architektur, bevor ein Befehl getippt wird. Wenn der einzige verfügbare Client die offizielle Desktop-App ist, ist ein Linux-Gateway, das für das LAN weiterleitet, keine Konfiguration, die Sie fertigstellen können, und kein Maß an Masquerading ändert das.

Der Ersatz-Client muss auch zur Authentifizierungsmethode des Endpunkts und zu der Richtlinie passen, die Sie durchsetzen wollen. Zertifikatsbasierte, verzeichnisbasierte und SAML-gestützte Endpunkte akzeptieren nicht dieselben Client-Konfigurationen, und ein Drittanbieter-Client, der sich authentifiziert, aber die gepushten Routen ignoriert, ist keine Verbesserung.

Behandeln Sie die Client-Wahl als Teil der Design-Überprüfung. Sie entscheidet, ob das LAN-Weiterleitungsmuster überhaupt verfügbar ist, und sie entscheidet, welche Identität der Endpunkt für jedes Gerät hinter dem Gateway sieht. Halten Sie den Client und die Endpunkt-Konfiguration fest, gegen die getestet wurde. Ein Client-Wechsel ein halbes Jahr später kann die Fähigkeit still entfernen, die das Design vorausgesetzt hat.

Leiten Sie das LAN in den Tunnel und übersetzen Sie es

Mit einem unterstützten Client an Ort und Stelle ist der Rest gewöhnliche Gateway-Arbeit. Die LAN-Geräte brauchen eine Route für den VPC-Bereich, die auf den Linux-Host zeigt, und der Host braucht aktivierte Weiterleitung. Wenn die VPC den Verkehr als verbundenen Client sehen soll und nicht als beliebige LAN-Adresse, übersetzen Sie die Quelle auf dem Weg nach draußen.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Beschränken Sie die Regel auf die Tunnelschnittstelle und den VPC-Bereich, wie oben, statt alles zu maskieren, was der Host weiterleitet. Die engere Regel ist leichter zu durchdenken, und sie ändert nicht still Verkehr, der seine ursprüngliche Quelladresse behalten sollte.

Lassen Sie die LAN-Route automatisch kommen, wenn Sie können: eine DHCP-Option, eine Router-Ankündigung oder eine statische Route, die von dem gepusht wird, was das LAN verwaltet. Eine Route, die nur auf einer Testmaschine existiert, lässt das Design in dem Moment kaputt aussehen, in dem jemand anderes es versucht.

Auch die Antwort braucht einen Weg

Sobald die Anfrage die VPC erreicht, muss die Antwort durch dieselben Übersetzungszustände zurückkommen und die LAN-Route am Gateway finden. Dieser Teil funktioniert meist, wenn die Masquerade-Regel vorhanden ist, weil die Zuordnung auf dem Host lebt, der sie durchgeführt hat. Er bricht, wenn die VPC-Seite eine Route hat, die die Antwort woandershin schickt; deshalb sind sowohl die Client-CIDR-Route als auch die Subnetz-Zuordnung am Endpunkt wichtig.

Beobachten Sie die Zähler, nicht nur den Ping. Eine Masquerade-Regel mit null Paketen sagt Ihnen, dass die Anfrage die Tunnelschnittstelle nie erreicht hat, was zurück auf die LAN-Route oder die eigene Routing-Tabelle des Clients zeigt. Eine Regel mit Paketen, aber ohne Antworten zeigt auf die VPC-Seite, die Autorisierungsregeln oder eine Sicherheitsgruppe, die die übersetzte Quelle nicht akzeptiert. Lesen Sie beide Richtungen, bevor Sie etwas ändern, denn ein Zähler, der nur auf einer Seite wächst, ist ein Einbahnweg und kein langsamer.

Denken Sie daran, dass der Endpunkt ein verwalteter Dienst ist. Es gibt keine Server-Konfigurationsdatei zum Bearbeiten und keine client-config-Direktive zum Hinzufügen, sodass Anleitungen für einen selbst verwalteten OpenVPN-Server mit eigenen Client-Subnetz-Routen nicht übertragbar sind. Bei AWS sind die Hebel Subnetz-Zuordnung, Autorisierungsregeln und die Routing-Tabellen der VPC.

Gemeinsame Identität ist der Punkt, den die Richtlinie beantworten muss

Jedes Gerät hinter dem Gateway nutzt die VPN-Sitzung des Gateways. Die Autorisierungsregeln des Endpunkts gewähren einem Benutzer oder einer Gruppe Zugriff, und aus Sicht des Dienstes gibt es genau einen Benutzer auf dieser Sitzung. Lokale Weiterleitung vervielfacht diese Identität nicht in eine Authentifizierung pro Gerät, und sie erweitert Geräte-Posture-Prüfungen nicht auf den Drucker in der Ecke.

Das kann akzeptabel sein, oder es kann der Grund sein, warum das Design abgelehnt wird. Es hängt davon ab, was die VPC-Ressourcen über den Aufrufer annehmen. Eine gemeinsame Identität, die zum Autorisierungsmodell passt, ist in Ordnung; eine, die still eine einzelne authentifizierte Sitzung in LAN-weiten Zugriff verwandelt, ist ein Befund, der darauf wartet, geschrieben zu werden.

Wenn die Anforderung wirklich ist, einen ganzen Standort an eine VPC anzubinden, vergleichen Sie ein unterstütztes Site-to-Site-Design, bevor Sie einen Fernzugriffs-Client erweitern. Die Semantik unterscheidet sich, und eine per NAT übersetzte Client-Sitzung ist ein schlechter Ersatz für eine Standortverbindung, wenn die VPC Verbindungen ins LAN initiieren muss.

Entscheiden Sie den Client, die Route, die Übersetzung und die Identitätsgeschichte in dieser Reihenfolge. Jedes schränkt das nächste ein, und die Reihenfolge erklärt, warum der Host funktioniert, während das LAN es nicht tut.