Wechselnder Zugriff über AWS Client VPN: jedes zugeordnete Subnetz prüfen

Ein Benutzer verbindet sich, öffnet die interne App und bekommt eine Antwort; ein Kollege am selben Endpunkt erhält von einem identischen Laptop im selben Wi-Fi eine Zeitüberschreitung. Dieses Muster ist die Signatur eines Client-VPN-Endpunkts mit mehr als einem zugeordneten Subnetz, bei dem die Pfade nicht gleichwertig sind. Ich gehe das von der Konsole nach außen durch, weil zwei Registerkarten entscheiden, ob sich der Rest der Untersuchung lohnt. Nichts in der Client-Konfiguration erklärt es.

Beim Endpunkt beginnen und die Zuordnungen auflisten

Öffnen Sie in der VPC-Konsole Client VPN endpoints, wählen Sie den Endpunkt und lesen Sie die Registerkarte Associations. Jede Zuordnung ist ein Subnetz in einer Availability Zone, und ein Client landet auf demjenigen, das der Dienst beim Aufbau der Verbindung auswählt. Notieren Sie die Subnetz-IDs und die Routentabelle, die jedes tatsächlich verwendet, denn diese beiden Listen sind der Vergleich, den Sie gleich anstellen.

Zeigt der Endpunkt nur eine Zuordnung, ist diese Theorie falsch und der Client der bessere Verdächtige.

Die Routentabelle des Endpunkts mit jeder Zuordnung vergleichen

Öffnen Sie die Registerkarte Route table am selben Endpunkt. Jedes Ziel-CIDR dort hat ein Ziel, und bei einem Client VPN ist das Ziel eine Zuordnung statt eines Gateways. AWS verlangt einen Zieleintrag für jedes zugeordnete Subnetz, eine Route, die nur auf eines davon zeigt, macht den Zugriff also davon abhängig, wo die Sitzung gelandet ist. Prüfen Sie das Ziel, das Sie wirklich brauchen, und danach dessen Autorisierungsregel, denn eine Route liefert den Pfad und eine Regel entscheidet, wer ihn nutzen darf.

Sobald Sie beide Ebenen tabellarisch erfassen, ist der Fehler kaum zu übersehen.

Zeile zwei ist in den meisten Tickets der ganze Fehler. Die Endpunkt-Route ist vorhanden, also schaut niemand weiter, und das Paket stirbt einen Hop später innerhalb der VPC.

Jedes Subnetz in seine effektive Routentabelle verfolgen

Ein Subnetz ohne ausdrückliche Routentabellenzuordnung erbt die Haupttabelle der VPC. Lesen Sie die Tabelle, die tatsächlich gilt, nicht die, deren Name richtig aussieht, und vergleichen Sie Ziel und Zielobjekt statt der Beschriftung in der Zeile.

Die AWS-Anleitung für wechselnden Zugriff beschreibt das als Routenabdeckung über Zuordnungen hinweg, was das richtige Modell ist. Der Endpunkt bringt das Paket zu einem Subnetz, und die Tabelle dieses Subnetzes muss weiterhin wissen, wo das Anwendungsnetz liegt.

Korrigieren Sie die fehlende Zeile in der Tabelle, der sie gehört. Eine ganze Routentabelle von einem funktionierenden Subnetz zu kopieren, kopiert auch Internet-, Appliance- und Isolationsentscheidungen, die für dieses nie gedacht waren, und dieser Tausch ist meist schlechter als die Störung, mit der Sie begonnen haben.

Autorisierungsregeln prüfen, dann den Rückweg

Autorisierungsregeln gelten pro Ziel und pro Gruppe und werden getrennt von Routen ausgewertet. Ein Ziel mit Routen überall, aber ohne Regel für die Gruppe des Benutzers, verhält sich wie ein schwarzes Loch mit gesund aussehender Routentabelle.

Der Rückweg verdient dieselbe Aufmerksamkeit. Eine Peering-Verbindung braucht eine Route in der App-VPC zurück zum Client-CIDR, Sicherheitsgruppenregeln, die den Verkehr an beiden Enden erlauben, und Netzwerk-ACLs, die ihn nicht verwerfen. Einseitige Erreichbarkeit, bei der ping funktioniert und der TCP-Handshake nicht, deutet meist auf eine ACL oder eine Sicherheitsgruppe hin, nicht auf das VPN.

Die eigenen Sicherheitsgruppen des Endpunkts liegen auf den elastischen Netzwerkschnittstellen der Zuordnung, eine Regel, die den Anwendungsport vom Client-CIDR erlaubt, muss also an der Zuordnung hängen, nicht nur an der Instanz.

Mit einer Neuverbindung prüfen, nicht mit einer glücklichen Anfrage

Bei Split-Tunneling werden Endpunkt-Routen beim Aufbau der Verbindung übertragen, ein geänderter Routensatz erreicht also nie einen Client, der verbunden bleibt. Trennen Sie die Verbindung und verbinden Sie sich über den unterstützten Client neu, und bestätigen Sie dann, dass die neuen Routen auf dem Rechner vorhanden sind.

Korrelieren Sie schließlich das Verbindungsprotokoll mit der Adresse, die der Client erhalten hat, und wiederholen Sie den Test oft genug, um mehr als eine Zuordnung zu treffen. Eine einzelne erfolgreiche Anfrage nach einer Korrektur beweist, dass ein Pfad funktioniert, und das Ticket betraf den anderen.