Periodisk tilgang med AWS Client VPN: revider hvert tilknyttede subnett

En bruker kobler til, åpner den interne appen og får svar; en kollega på samme endepunkt får tidsavbrudd fra en identisk bærbar PC på samme Wi-Fi. Det mønsteret er signaturen til et client VPN-endepunkt med mer enn ett tilknyttet subnett, der stiene ikke er likeverdige. Jeg går gjennom dette fra konsollen og utover, fordi to faner avgjør om resten av undersøkelsen er verdt det. Ingenting i klientkonfigurasjonen forklarer det.

Start ved endepunktet og list tilknytningene

I VPC-konsollen åpner du Client VPN endpoints, velger endepunktet og leser fanen Associations. Hver tilknytning er et subnett i en tilgjengelighetssone, og en klient lander på det tjenesten velger når forbindelsen bygges. Noter subnett-ID-ene og rutetabellen hver av dem faktisk bruker, fordi de to listene er sammenligningen du er i ferd med å gjøre.

Hvis endepunktet viser én enkelt tilknytning, er denne teorien feil og klienten er den bedre mistenkte.

Sammenlign endepunktets rutetabell med hver tilknytning

Åpne fanen Route table på samme endepunkt. Hvert destinasjons-CIDR der har et mål, og for en client VPN er målet en tilknytning og ikke en gateway. AWS krever en destinasjonsoppføring for hvert tilknyttet subnett, så en rute som bare peker på ett av dem gjør tilgangen avhengig av hvor økten landet. Kontroller destinasjonen du faktisk bryr deg om, og deretter autorisasjonsregelen dens, fordi en rute leverer stien og en regel avgjør hvem som kan bruke den.

Når du tabulerer begge lagene, er feilen vanskelig å overse.

Andre rad er hele feilen i de fleste sakene. Endepunktets rute er der, så ingen ser lenger, og pakken dør ett hopp senere inne i VPC-en.

Følg hvert subnett inn i den effektive rutetabellen

Et subnett uten eksplisitt rutetabelltilknytning arver hovedtabellen i VPC-en. Les tabellen som faktisk gjelder, ikke den navnet ser riktig ut på, og sammenlign destinasjon og mål i stedet for etiketten på raden.

AWS-veiledningen for periodisk tilgang beskriver dette som rutetekning på tvers av tilknytninger, som er riktig modell. Endepunktet får pakken til et subnett, og tabellen til det subnettet må fortsatt vite hvor applikasjonsnettet bor.

Rett den manglende raden i tabellen som eier den. Å kopiere en hel rutetabell fra et fungerende subnett kopierer også internett-, apparat- og isolasjonsvalg som aldri var ment for dette, og den byttehandelen er vanligvis verre enn avbruddet du startet med.

Kontroller autorisasjonsregler, deretter veien tilbake

Autorisasjonsregler er per destinasjon og per gruppe, og vurderes separat fra ruter. En destinasjon med ruter overalt men uten regel for brukerens gruppe oppfører seg som et svart hull med en rutetabell som ser sunn ut.

Returveien fortjener samme oppmerksomhet. En peering-forbindelse trenger en rute i appens VPC tilbake til klientens CIDR, sikkerhetsgrupperegler som tillater trafikken i begge ender, og nettverks-ACL-er som ikke slipper den. Enveis nåbarhet, der ping virker og TCP-håndtrykket ikke, peker vanligvis på en ACL eller en sikkerhetsgruppe og ikke på VPN-en.

Endepunktets egne sikkerhetsgrupper sitter på tilknytningens elastiske nettverksgrensesnitt, så en regel som tillater applikasjonsporten fra klientens CIDR må festes til tilknytningen, ikke bare til instansen.

Verifiser med en gjenoppkobling, ikke én heldig forespørsel

Med split tunnel sendes endepunktets ruter når forbindelsen etableres, så et endret rutesett når aldri en klient som blir værende tilkoblet. Koble fra og til igjen via den støttede klienten, og bekreft deretter at de nye rutene finnes på maskinen.

Til slutt, korreler tilkoblingsloggen med adressen klienten fikk, og gjenta testen nok ganger til å treffe mer enn én tilknytning. Én vellykket forespørsel etter en rettelse beviser at én sti virker, og saken handlet om den andre.