AWS Client VPN er forbundet, men EC2 svarer stadig ikke

Min bærbare sagde forbundet. AWS Client VPN-klienten viste sin grønne tilstand, endpointet loggede en session, og alligevel kunne jeg ikke åbne en MongoDB-port på en EC2-instans i et privat subnet. Intet var tydeligt i stykker: certifikatet var gyldigt, profilen kom fra konsollen, og tunnelen transporterede trafik. Fejlen var min, fordi jeg læste forbundet som autoriseret.

Login svarer på præcis ét spørgsmål: må denne identitet etablere en session? Alt derefter afgøres af særskilte regler, som aldrig ser dit certifikat. En session, der autentificerer, og en pakke, der ankommer, er to forskellige succeser, og hullet imellem dem er der, hvor de fleste rapporter af typen VPN er oppe, men værten er utilgængelig, bor.

Kontrollerne nedenfor er den rækkefølge, jeg bruger nu.

Hvad en forbundet session faktisk beviser

Under handshaket validerer endpointet klientcertifikatet mod sit trust store eller omdirigerer browseren til din identity provider, når SAML er konfigureret. Hvis det går igennem, får klienten en adresse fra endpointets klient-CIDR, og konsollen viser en aktiv forbindelse. På intet tidspunkt i den udveksling spørger noget, om du må nå 10.0.4.17 på port 27017.

Tilladelse til en destination er et separat objekt på endpointet. Hver flow matches mod autorisationsreglerne, og hver regel parrer et destinations-CIDR med den gruppe, reglen er givet til. Når ingen regel dækker destinationen, accepterer endpointet sessionen og dropper trafikken. Der er ingen banner, ingen genopkoblingsløkke og intet i klientens UI, der siger afvist.

Sammenlign autorisationsreglen med ressourcen, ikke med VPC’en

List reglerne og hold dem ved siden af den adresse, instansen faktisk har:

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

Outputtet viser et destinations-CIDR og et gruppe-ID pr. regel. Der skjuler sig to fejl i det. Reglen kan autorisere 10.0.0.0/16, mens instansen ligger i en peeret VPC på 10.1.0.0/16; peering-ruten findes, men ingen har skrevet en autorisationsregel for det andet område. Eller reglen peger på en mappegruppe, som brugeren er med i i mappen, men ikke i den gruppe, endpointet evaluerer.

Skriv den snævreste regel, der dækker destinationen, og tilføj først en anden, når et andet CIDR virkelig er nødvendigt. En bred 0.0.0.0/0-regel fra et quick start virker, og derfor overlever den til produktion og skjuler modellen.

To rutetabeller afgør, om pakken flytter sig

En endpoint-rute mapper et destinations-CIDR til et af de subnets, endpointet er tilknyttet. Det er den halve vej. Subnettets egen rutetabel skal stadig vide, hvordan pakken videresendes, og det tæller i det øjeblik, destinationen ligger bag en peering-forbindelse, en transit gateway eller et lokalt område, der kan nås via en site-to-site-tunnel.

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

Led efter en rute, hvis destination matcher ressourcens CIDR, og hvis mål er et tilknyttet subnet. Mangler ruten, så tilføj den. Er den der, og værten stadig tavs, er hullet på VPC-siden, så sammenlign med rutetabellen for tilknytningssubnettet.

Én klientindstilling brækker routing uden at brække tunnelen: en profil, der indeholder route-nopull. Direktivet fortæller en OpenVPN-baseret klient at ignorere de ruter, serveren skubber, så interfacet kommer op med kun endpointets egen adresse, og destinationen er ganske enkelt uden rute. Tjek med ip route show på Linux eller netstat -rn på macOS, om der findes en rute gennem tun-interfacet. Hvis ikke, fjern route-nopull fra den eksporterede profil, og genopkobl, så de skubbede ruter anvendes.

Sikkerhedsgrupper ser ikke din klientadresse

Det er den del, jeg havde forkert i en hel eftermiddag. For et IPv4-endpoint tilknyttet et subnet oversætter tjenesten klientens kildeadresse til adressen på endpointets netværksinterface i det subnet. Den pakke, der når instansen, bærer ikke den adresse, din klient viste, så en sikkerhedsgrupperegel, der tillader klientpoolen, f.eks. 172.16.0.0/22, matcher intet som helst.

Tillad porten fra endpointets sikkerhedsgruppe, som er knyttet til tilknytningens interface, i stedet for fra klient-CIDR’et. At referere gruppen er mere holdbart end at hardcode en adresse, fordi interfaceadressen ikke er din at styre. Netværks-ACL’er er tilstandsløse, så hvor der findes egne poster, skal både den indgående og den udgående retning tillade flowet.

Forbind også til instansens private adresse. En offentlig IP fører pakken ud af VPC’en og ind igen ad en anden vej med andre regler, så en offentlig test siger intet om den private vej.

En isolationsrækkefølge, der stopper ved den første fejl

Gå gennem dem i rækkefølge, og stop hvor en fejler. Hvert trin udelukker et lag i stedet for alle.

1. Bekræft, hvilken identitet sessionen brugte, og hvilken gruppe endpointet evaluerer. Et certifikat fra ét trust store er ikke samme principal som en SAML-assertion fra mappen.
2. Bekræft, at en autorisationsregel dækker ressourcens CIDR for den gruppe.
3. Bekræft, at en endpoint-rute findes og peger på et tilknyttet subnet, og derefter at subnettets rutetabel kan sende videre.
4. Bekræft, at sikkerhedsgruppen tillader porten fra endpoint-interfacet i stedet for fra klientpoolen.
5. Test indefra VPC’en med en SSM-session på en anden instans i samme subnet for at skille et applikationsproblem fra et klientvejsproblem.

Når trinnene ikke er afgørende, er denne tabel det, jeg falder tilbage på:

To kontodetaljer giver symptomer, der ligner tilladelsesfejl. Hver bruger har brug for et separat klientcertifikat; deler man ét mellem to maskiner, fortrænger sessionerne hinanden, og resultatet er en genopkoblingsløkke i stedet for en afvisning. Når et nyt endpoint oprettes, viser konsollen et DNS-navn, som nogle klientversioner kun accepterer med det tilfældige præfiks, der vises på endpoint-siden, så kopiér det fulde navn i stedet for at genskabe det.

Hvis det femte trin efterlader dig fast, så hent endpointets forbindelseslog og læs autorisationsposterne, før du ændrer noget. Loggen navngiver destinationen, der blev tjekket, og reglen, der matchede eller ikke matchede, og det reducerer spørgsmålet med fire lag til ét svar.