Wisselende toegang met AWS Client VPN: controleer elk gekoppeld subnet

Een gebruiker maakt verbinding, opent de interne app en krijgt antwoord; een collega op hetzelfde eindpunt krijgt een time-out van een identieke laptop op dezelfde Wi-Fi. Dat patroon is de signatuur van een client VPN-eindpunt met meer dan één gekoppeld subnet, waarbij de paden niet gelijkwaardig zijn. Ik loop dit van de console naar buiten door, omdat twee tabbladen bepalen of de rest van het onderzoek de moeite waard is. Niets in de clientconfiguratie verklaart het.

Begin bij het eindpunt en som de koppelingen op

Open in de VPC-console Client VPN endpoints, kies het eindpunt en lees het tabblad Associations. Elke koppeling is een subnet in een beschikbaarheidszone, en een client landt op degene die de dienst kiest wanneer de verbinding wordt opgebouwd. Noteer de subnet-ID’s en de routetabel die elk ervan feitelijk gebruikt, want die twee lijsten zijn de vergelijking die u gaat maken.

Als het eindpunt één koppeling toont, is deze theorie onjuist en is de client de betere verdachte.

Vergelijk de routetabel van het eindpunt met elke koppeling

Open het tabblad Route table op hetzelfde eindpunt. Elk bestemmings-CIDR daar heeft een doel, en bij een client VPN is het doel een koppeling en geen gateway. AWS vereist een bestemmingsvermelding voor elk gekoppeld subnet, dus een route die er slechts één van richt, maakt toegang afhankelijk van waar de sessie landde. Controleer de bestemming die u echt belangrijk vindt, en daarna de autorisatieregel ervan, want een route levert het pad en een regel bepaalt wie het mag gebruiken.

Zodra u beide lagen in een tabel zet, is de fout moeilijk te missen.

Rij twee is in de meeste tickets de hele bug. De eindpuntroute is er, dus niemand kijkt verder, en het pakket sterft één hop later binnen de VPC.

Volg elk subnet naar zijn effectieve routetabel

Een subnet zonder expliciete routetabelkoppeling erft de hoofdtabel van de VPC. Lees de tabel die feitelijk geldt, niet degene waarvan de naam juist lijkt, en vergelijk bestemming en doel in plaats van het label op de rij.

De AWS-handleiding voor wisselende toegang beschrijft dit als routedekking over koppelingen, wat het juiste model is. Het eindpunt brengt het pakket naar een subnet, en de tabel van dat subnet moet nog steeds weten waar het applicatienetwerk woont.

Herstel de ontbrekende rij in de tabel die er eigenaar van is. Een hele routetabel van een werkend subnet kopiëren kopieert ook internet-, apparaat- en isolatiekeuzes die nooit voor dit subnet bedoeld waren, en die ruil is meestal erger dan de storing waarmee u begon.

Controleer de autorisatieregels en dan de weg terug

Autorisatieregels gelden per bestemming en per groep en worden los van routes beoordeeld. Een bestemming met overal routes maar zonder regel voor de groep van de gebruiker gedraagt zich als een zwart gat met een gezond uitziende routetabel.

De terugweg verdient dezelfde aandacht. Een peering-verbinding heeft een route in de app-VPC nodig die terugwijst naar de CIDR van de client, beveiligingsgroepsregels die het verkeer aan beide uiteinden toestaan, en netwerk-ACL’s die het niet laten vallen. Eenrichtingsbereikbaarheid, waarbij ping werkt en de TCP-handshake niet, wijst meestal op een ACL of een beveiligingsgroep en niet op de VPN.

De eigen beveiligingsgroepen van het eindpunt staan op de elastische netwerkinterfaces van de koppeling, dus een regel die de applicatiepoort vanaf de client-CIDR toestaat, moet aan de koppeling hangen, niet alleen aan de instantie.

Verifieer met een herverbinding, niet met één gelukkig verzoek

Bij split tunnel worden de routes van het eindpunt gepusht wanneer de verbinding tot stand komt, dus een gewijzigde routeset bereikt nooit een client die verbonden blijft. Verbreek de verbinding en maak opnieuw verbinding via de ondersteunde client, en bevestig daarna dat de nieuwe routes op de machine staan.

Correleer ten slotte het verbindingslogboek met het adres dat de client kreeg, en herhaal de test vaak genoeg om meer dan één koppeling te raken. Eén geslaagd verzoek na een correctie bewijst dat één pad werkt, en het ticket ging over het andere.