Periodisk tilgang med AWS Client VPN: gransk kvart tilknytte subnett

Ein brukar koplar til, opnar den interne appen og får svar; ein kollega på same endepunkt får tidsavbrot frå ein identisk berbar PC på same Wi-Fi. Det mønsteret er signaturen til eit client VPN-endepunkt med meir enn eitt tilknytt subnett, der stiane ikkje er likeverdige. Eg går gjennom dette frå konsollen og utover, fordi to faner avgjer om resten av granskinga er verdt det. Ingenting i klientkonfigurasjonen forklarer det.

Start ved endepunktet og list tilknytingane

I VPC-konsollen opnar du Client VPN endpoints, vel endepunktet og les fanen Associations. Kvar tilknyting er eit subnett i ei tilgjengelegheitssone, og ein klient landar på det tenesta vel når sambandet blir bygt. Noter subnett-ID-ane og rutetabellen kvar av dei faktisk brukar, fordi dei to listene er samanlikninga du er i ferd med å gjere.

Viser endepunktet berre éi tilknyting, er denne teorien feil og klienten er den betre mistenkte.

Samanlikn rutetabellen til endepunktet med kvar tilknyting

Opne fanen Route table på same endepunkt. Kvar destinasjons-CIDR der har eit mål, og for ein client VPN er målet ei tilknyting og ikkje ein gateway. AWS krev ein destinasjonsoppføring for kvart tilknytt subnett, så ei rute som berre peikar på eitt av dei gjer tilgangen avhengig av kvar økta landa. Kontroller destinasjonen du faktisk bryr deg om, og deretter autorisasjonsregelen hans, fordi ei rute leverer stien og ein regel avgjer kven som kan bruke han.

Når du tabulerer begge laga, er feilen vanskeleg å oversjå.

Andre rad er heile feilen i dei fleste sakene. Ruta til endepunktet er der, så ingen ser lenger, og pakken døyr eitt hopp seinare inne i VPC-en.

Følg kvart subnett inn i den effektive rutetabellen

Eit subnett utan eksplisitt rutetabelltilknyting arvar hovudtabellen i VPC-en. Les tabellen som faktisk gjeld, ikkje den namnet ser riktig ut på, og samanlikn destinasjon og mål i staden for etiketten på rada.

AWS-rettleiinga for periodisk tilgang skildrar dette som rutetekning på tvers av tilknytingar, som er rett modell. Endepunktet får pakken til eit subnett, og tabellen til det subnettet må framleis vite kvar applikasjonsnettet bur.

Retta den manglande rada i tabellen som eig henne. Å kopiere ein heil rutetabell frå eit fungerande subnett kopierer òg internett-, apparat- og isolasjonsval som aldri var meint for dette, og den byttehandelen er vanlegvis verre enn avbrotet du starta med.

Kontroller autorisasjonsreglar, deretter vegen tilbake

Autorisasjonsreglar er per destinasjon og per gruppe, og blir vurderte separat frå ruter. Ein destinasjon med ruter overalt men utan regel for gruppa til brukaren oppfører seg som eit svart hòl med ein rutetabell som ser sunn ut.

Returvegen fortener same merksemd. Ei peering-tilknyting treng ei rute i appens VPC tilbake til CIDR-en til klienten, sikkerheitsgrupperegler som tillèt trafikken i begge endar, og nettverks-ACL-ar som ikkje slepp han. Einvegssnåbarheit, der ping verkar og TCP-handtrykket ikkje, peikar vanlegvis på ein ACL eller ei sikkerheitsgruppe og ikkje på VPN-en.

Dei eigne sikkerheitsgruppene til endepunktet sit på dei elastiske nettverksgrensesnitta til tilknytinga, så ein regel som tillèt applikasjonsporten frå CIDR-en til klienten må festast til tilknytinga, ikkje berre til instansen.

Stadfest med ein gjenoppkopling, ikkje éin heldig førespurnad

Med split tunnel blir rutene til endepunktet sende når sambandet blir oppretta, så eit endra rutesett når aldri ein klient som blir verande tilkopla. Kople frå og til igjen via den støtta klienten, og stadfest deretter at dei nye rutene finst på maskina.

Til slutt, korreler tilkoplingsloggen med adressa klienten fekk, og gjer testen om att nok gonger til å treffe meir enn éi tilknyting. Éin vellukka førespurnad etter ei retting beviser at éin sti verkar, og saka handla om den andre.