Periodisk adgang med AWS Client VPN: gennemgå hvert tilknyttet undernet

En bruger opretter forbindelse, åbner den interne app og får et svar; en kollega på samme slutpunkt får en timeout fra en identisk bærbar computer på samme Wi-Fi. Det mønster er signaturen på et client VPN-slutpunkt med mere end et tilknyttet undernet, hvor stierne ikke er ens. Jeg går gennem dette fra konsollen og udad, fordi to faner afgør, om resten af undersøgelsen er værd at lave. Intet i klientkonfigurationen forklarer det.

Begynd ved slutpunktet og list tilknytningerne

I VPC-konsollen åbner du Client VPN endpoints, vælger slutpunktet og læser fanen Associations. Hver tilknytning er et undernet i en tilgængelighedszone, og en klient lander på det, tjenesten vælger, når forbindelsen oprettes. Noter undernets-id’erne og den rutetabel, hver af dem faktisk bruger, fordi de to lister er den sammenligning, du er ved at lave.

Hvis slutpunktet viser en enkelt tilknytning, er denne teori forkert, og klienten er den bedre mistænkte.

Sammenlign slutpunktets rutetabel med hver tilknytning

Åbn fanen Route table på samme slutpunkt. Hvert destinations-CIDR der har et mål, og for en client VPN er målet en tilknytning frem for en gateway. AWS kræver en destinationspost for hvert tilknyttet undernet, så en rute, der kun peger på ét af dem, gør adgangen afhængig af, hvor sessionen landede. Kontroller den destination, du faktisk har brug for, og derefter dens autorisationsregel, fordi en rute leverer stien, og en regel afgør, hvem der må bruge den.

Når du tabulerer begge lag, er fejlen svær at overse.

Anden række er hele fejlen i de fleste sager. Slutpunktets rute er der, så ingen kigger videre, og pakken dør et hop senere inde i VPC’en.

Følg hvert undernet ind i dets effektive rutetabel

Et undernet uden eksplicit rutetabeltilknytning arver VPC’ens hovedtabel. Læs den tabel, der faktisk er i kraft, ikke den, hvis navn ser rigtigt ud, og sammenlign destination og mål frem for etiketten på rækken.

AWS’ vejledning om periodisk adgang beskriver dette som rutetækning på tværs af tilknytninger, hvilket er den rigtige model. Slutpunktet får pakken hen til et undernet, og det undernets tabel skal stadig vide, hvor applikationsnettet bor.

Ret den manglende række i den tabel, der ejer den. At kopiere en hel rutetabel fra et fungerende undernet kopierer også internet-, appliance- og isoleringsvalg, der aldrig var ment til dette, og den byttehandel er normalt værre end det nedbrud, du startede med.

Kontroller autorisationsregler, derefter vejen tilbage

Autorisationsregler er pr. destination og pr. gruppe og vurderes separat fra ruter. En destination med ruter overalt, men uden regel for brugerens gruppe, opfører sig som et sort hul med en rutetabel, der ser sund ud.

Returvejen fortjener samme opmærksomhed. En peering-forbindelse kræver en rute i appens VPC, der peger tilbage på klientens CIDR, sikkerhedsgrupperegler, der tillader trafikken i begge ender, og netværks-ACL’er, der ikke dropper den. Ensrettet nåbarhed, hvor ping virker og TCP-håndtrykket ikke, peger normalt på en ACL eller en sikkerhedsgruppe frem for på VPN’en.

Slutpunktets egne sikkerhedsgrupper sidder på tilknytningens elastiske netværksinterfaces, så en regel, der tillader applikationsporten fra klientens CIDR, skal knyttes til tilknytningen, ikke kun til instansen.

Verificer med en genopkobling, ikke en enkelt heldig anmodning

Med split tunnel sendes slutpunktets ruter, når forbindelsen etableres, så et ændret rutesæt når aldrig en klient, der bliver ved med at være forbundet. Afbryd og genopret forbindelsen via den understøttede klient, og bekræft derefter, at de nye ruter findes på maskinen.

Til sidst korrelerer du forbindelsesloggen med den adresse, klienten fik, og gentager testen nok gange til at ramme mere end én tilknytning. En enkelt vellykket anmodning efter en rettelse beviser, at én sti virker, og sagen handlede om den anden.