AWS Client VPN er tilkoblet, men EC2 svarer fortsatt ikke

Laptop-en min viste tilkoblet. AWS Client VPN-klienten viste sin grønne tilstand, endpointet loggførte en økt, og likevel fikk jeg ikke åpnet en MongoDB-port på en EC2-instans i et privat subnett. Ingenting var tydelig ødelagt: sertifikatet var gyldig, profilen kom fra konsollen, og tunnelen fraktet trafikk. Feilen var min, fordi jeg leste tilkoblet som autorisert.

Innloggingen svarer på nøyaktig ett spørsmål: kan denne identiteten etablere en økt? Alt etterpå avgjøres av egne regler som aldri ser sertifikatet ditt. En økt som autentiserer, og en pakke som ankommer, er to forskjellige suksesser, og gapet mellom dem er der de fleste rapportene av typen VPN er oppe, men verten er utilgjengelig, bor.

Kontrollene nedenfor er rekkefølgen jeg bruker nå.

Hva en tilkoblet økt faktisk beviser

Under handshaken validerer endpointet klientens sertifikat mot sitt trust store, eller omdirigerer nettleseren til identitetsleverandøren din når SAML er konfigurert. Hvis det går gjennom, får klienten en adresse fra endpointets klient-CIDR, og konsollen viser en aktiv forbindelse. På ingen av punktene i den utvekslingen spør noe om du får nå 10.0.4.17 på port 27017.

Tillatelse til en destinasjon er et eget objekt på endpointet. Hver flyt matches mot autorisasjonsreglene, og hver av dem parer et destinasjons-CIDR med gruppen regelen er gitt til. Når ingen regel dekker destinasjonen, godtar endpointet økten og slipper trafikken. Det finnes ingen banner, ingen gjentilkoblingsløkke og ingenting i klientgrensesnittet som sier avvist.

Sammenlign autorisasjonsregelen med ressursen, ikke med VPC-en

List opp reglene og hold dem ved siden av adressen instansen faktisk har:

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

Utdataene viser et destinasjons-CIDR og en gruppe-ID per regel. To feil skjuler seg i dem. Regelen kan autorisere 10.0.0.0/16 mens instansen ligger i en peeret VPC på 10.1.0.0/16; peering-ruten finnes, men ingen skrev en autorisasjonsregel for det andre området. Eller regelen peker på en kataloggruppe som brukeren er med i i katalogen, men ikke i gruppen endpointet vurderer.

Skriv den smaleste regelen som dekker destinasjonen, og legg bare til en andre når et andre CIDR virkelig er nødvendig. En bred 0.0.0.0/0-regel fra en hurtigstart fungerer, og derfor overlever den til produksjon og skjuler modellen.

To rutetabeller avgjør om pakken flytter seg

En endpoint-rute mapper et destinasjons-CIDR til et av subnettene endpointet er knyttet til. Det er halve veien. Subnettets egen rutetabell må fortsatt vite hvordan pakken skal videresendes, og det teller i det øyeblikket destinasjonen ligger bak en peering-forbindelse, en transit gateway eller et lokalt område som er tilgjengelig via en site-to-site-tunnel.

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

Se etter en rute der destinasjonen samsvarer med ressursens CIDR og målet er et tilknyttet subnett. Mangler ruten, legg den til. Finnes den og verten fortsatt er taus, er gapet på VPC-siden, så sammenlign med rutetabellen til tilknytningssubnettet.

Én klientinnstilling bryter rutingen uten å bryte tunnelen: en profil som inneholder route-nopull. Direktivet ber en OpenVPN-basert klient om å ignorere rutene serveren skyver, slik at grensesnittet kommer opp med bare endpointets egen adresse, og destinasjonen har rett og slett ingen rute. Sjekk med ip route show på Linux eller netstat -rn på macOS om det finnes en rute gjennom tun-grensesnittet. Hvis ikke, fjern route-nopull fra den eksporterte profilen og koble til på nytt slik at de skyvede rutene brukes.

Sikkerhetsgrupper ser ikke klientadressen din

Dette er delen jeg hadde feil i en hel ettermiddag. For et IPv4-endpoint knyttet til et subnett oversetter tjenesten klientens kildeadresse til adressen til endpointets nettverksgrensesnitt i det subnettet. Pakken som når instansen, bærer ikke adressen klienten din viste, så en sikkerhetsgrupperegel som tillater klientpoolen, si 172.16.0.0/22, treffer ingenting i det hele tatt.

Tillat porten fra endpointets sikkerhetsgruppe, som er festet til tilknytningens grensesnitt, i stedet for fra klient-CIDR-et. Å referere gruppen er mer holdbart enn å hardkode en adresse, fordi grensesnittadressen ikke er din å kontrollere. Nettverks-ACL-er er tilstandsløse, så der det finnes egne oppføringer, må både inngående og utgående retning tillate flyten.

Koble også til instansens private adresse. En offentlig IP tar pakken ut av VPC-en og inn igjen via en annen vei med andre regler, så en test mot den offentlige adressen sier ingenting om den private veien.

En isolasjonsrekkefølge som stopper ved første feil

Gå gjennom disse i rekkefølge og stopp der en feiler. Hvert trinn utelukker ett lag i stedet for alle.

1. Bekreft hvilken identitet økten brukte og hvilken gruppe endpointet vurderer. Et sertifikat fra ett trust store er ikke samme principal som en SAML-påstand fra katalogen.
2. Bekreft at en autorisasjonsregel dekker ressursens CIDR for den gruppen.
3. Bekreft at en endpoint-rute finnes og peker på et tilknyttet subnett, og deretter at subnettets rutetabell kan sende videre.
4. Bekreft at sikkerhetsgruppen tillater porten fra endpoint-grensesnittet og ikke fra klientpoolen.
5. Test fra innsiden av VPC-en, med en SSM-økt på en annen instans i samme subnett, for å skille et applikasjonsproblem fra et klientveisproblem.

Når trinnene ikke er avgjørende, er denne tabellen det jeg faller tilbake på:

To kontodetaljer gir symptomer som ligner tillatelsesfeil. Hver bruker trenger et eget klientcertifikat; deler man ett mellom to maskiner, fortrenger øktene hverandre, og resultatet er en gjentilkoblingsløkke i stedet for en avvisning. Når et nytt endpoint opprettes, viser konsollen et DNS-navn som noen klientversjoner bare godtar med det tilfeldige prefikset som vises på endpoint-siden, så kopier hele navnet i stedet for å gjenoppbygge det.

Hvis det femte trinnet setter deg fast, hent endpointets tilkoblingslogg og les autorisasjonsoppføringene før du endrer noe. Loggen navngir destinasjonen som ble sjekket og regelen som traff eller ikke traff, og det reduserer spørsmålet med fire lag til ett svar.