AWS Client VPN er tilkopla, men EC2 svarar framleis ikkje

Laptopen min viste tilkopla. AWS Client VPN-klienten viste den grøne tilstanden sin, endepunktet logga ei økt, og likevel fekk eg ikkje opna ein MongoDB-port på ein EC2-instans i eit privat subnett. Ingenting var tydeleg øydelagt: sertifikatet var gyldig, profilen kom frå konsollen, og tunnelen frakta trafikk. Feilen var min, fordi eg las tilkopla som autorisert.

Innlogginga svarar på nøyaktig eitt spørsmål: kan denne identiteten opprette ei økt? Alt etterpå blir avgjort av eigne reglar som aldri ser sertifikatet ditt. Ei økt som autentiserer, og ein pakke som kjem fram, er to ulike suksessar, og gapet mellom dei er der dei fleste rapportane av typen VPN er oppe, men verten er utilgjengeleg, bur.

Kontrollane nedanfor er rekkjefølgja eg brukar no.

Kva ei tilkopla økt faktisk beviser

Under handshaken validerer endepunktet sertifikatet til klienten mot sin trust store, eller omdirigerer nettlesaren til identitetsleverandøren din når SAML er konfigurert. Går det gjennom, får klienten ei adresse frå klient-CIDR-en til endepunktet, og konsollen viser ei aktiv tilkopling. På ingen av punkta i den utvekslinga spør noko om du får nå 10.0.4.17 på port 27017.

Løyve til ein destinasjon er eit eige objekt på endepunktet. Kvar flyt blir samanlikna med autorisasjonsreglane, og kvar av dei koplar ein destinasjons-CIDR til gruppa regelen er gitt til. Når ingen regel dekkjer destinasjonen, godtek endepunktet økta og slepper trafikken. Det finst ingen banner, inga gjentilkoplingsløkke og ingenting i klientgrensesnittet som seier avvist.

Samanlikn autorisasjonsregelen med ressursen, ikkje med VPC-en

List opp reglane og hald dei ved sida av adressa instansen faktisk har:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Utdataa viser ein destinasjons-CIDR og ein gruppe-ID per regel. To feil skjuler seg i dei. Regelen kan autorisere 10.0.0.0/16 medan instansen ligg i ein peera VPC på 10.1.0.0/16; peering-ruta finst, men ingen skreiv ein autorisasjonsregel for det andre området. Eller regelen peikar på ei kataloggruppe som brukaren er med i i katalogen, men ikkje i gruppa endepunktet vurderer.

Skriv den smalaste regelen som dekkjer destinasjonen, og legg berre til ein andre når ein andre CIDR verkeleg er nødvendig. Ein brei 0.0.0.0/0-regel frå ein hurtigstart fungerer, og difor overlever han til produksjon og skjuler modellen.

To rutetabellar avgjer om pakken flyttar seg

Ei endepunkt-rute koplar ein destinasjons-CIDR til eitt av subnettane endepunktet er knytt til. Det er halve vegen. Rutetabellen til subnettet sjølv må framleis vite korleis pakken skal sendast vidare, og det tel i det augneblinken destinasjonen ligg bak ei peering-tilkopling, ein transit gateway eller eit lokalt område som er tilgjengeleg via ein site-to-site-tunnel.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Sjå etter ei rute der destinasjonen svarar til CIDR-en til ressursen og målet er eit tilknytt subnett. Manglar ruta, legg ho til. Finst ho og verten framleis er taus, er gapet på VPC-sida, så samanlikn med rutetabellen til tilknytingssubnettet.

Éi klientinnstilling bryt rutinga utan å bryte tunnelen: ein profil som inneheld route-nopull. Direktivet ber ein OpenVPN-basert klient om å ignorere rutene serveren skyv, slik at grensesnittet kjem opp berre med den eigne adressa til endepunktet, og destinasjonen har rett og slett inga rute. Sjekk med ip route show på Linux eller netstat -rn på macOS om det finst ei rute gjennom tun-grensesnittet. Viss ikkje, fjern route-nopull frå den eksporterte profilen og kople til på nytt slik at dei skyvde rutene blir brukte.

Tryggleiksgrupper ser ikkje klientadressa di

Dette er delen eg hadde feil i ein heil ettermiddag. For eit IPv4-endepunkt knytt til eit subnett omset tenesta kjeldeadressa til klienten til adressa til nettverksgrensesnittet til endepunktet i det subnettet. Pakken som når instansen, ber ikkje adressa klienten din viste, så ein tryggleiksgrupperegel som tillet klientpoolen, sei 172.16.0.0/22, treff ingenting i det heile.

Tillat porten frå tryggleiksgruppa til endepunktet, som er fest til grensesnittet i tilknytinga, i staden for frå klient-CIDR-en. Å vise til gruppa er meir haldbart enn å hardkode ei adresse, fordi grensesnittadressa ikkje er di å styre. Nettverks-ACL-ar er tilstandslause, så der det finst eigne oppføringar, må både inngåande og utgåande retning tillate flyten.

Kople også til den private adressa til instansen. Ein offentleg IP tek pakken ut av VPC-en og inn att via ein annan veg med andre reglar, så ein test mot den offentlege adressa seier ingenting om den private vegen.

Ei isolasjonsrekkjefølgje som stoppar ved første feil

Gå gjennom desse i rekkjefølgje og stopp der ein feilar. Kvart steg utelukkar eitt lag i staden for alle.

1. Stadfest kva identitet økta brukte og kva gruppe endepunktet vurderer. Eit sertifikat frå ein trust store er ikkje same principal som ein SAML-påstand frå katalogen.
2. Stadfest at ein autorisasjonsregel dekkjer CIDR-en til ressursen for den gruppa.
3. Stadfest at det finst ei endepunkt-rute som peikar på eit tilknytt subnett, og så at rutetabellen til subnettet kan senda vidare.
4. Stadfest at tryggleiksgruppa tillét porten frå endepunkt-grensesnittet og ikkje frå klientpoolen.
5. Test frå innsida av VPC-en, med ei SSM-økt på ein annan instans i same subnett, for å skilje eit applikasjonsproblem frå eit klientvegproblem.

Når stega ikkje er avgjerande, er denne tabellen det eg fell tilbake på:

To kontodetaljar gjev symptom som liknar løyvefeil. Kvar brukar treng eit eige klientcertifikat; deler ein eitt mellom to maskinar, fortrengjer øktene kvarandre, og resultatet er ei gjentilkoplingsløkke i staden for ei avvising. Når eit nytt endepunkt blir oppretta, viser konsollen eit DNS-namn som nokre klientversjonar berre godtek med det tilfeldige prefikset som står på endepunktsida, så kopier heile namnet i staden for å byggje det opp att.

Viss det femte steget set deg fast, hent tilkoplingsloggen til endepunktet og les autorisasjonsoppføringane før du endrar noko. Loggen namngjev destinasjonen som vart sjekka og regelen som traff eller ikkje traff, og det reduserer spørsmålet med fire lag til eitt svar.