AWS Client VPN konektita, sed EC2 ankoraŭ ne respondas

Mia tekkomputilo diris konektita. La kliento AWS Client VPN montris sian verdan staton, la endpoint registris seancon, kaj tamen mi ne povis malfermi MongoDB-pordon sur EC2-instalaĵo en privata subreto. Nenio estis evidente rompita: la atestilo estis valida, la profilo venis el la konzolo, kaj la tunelo portis trafikon. La eraro estis mia, ĉar mi legis konektita kiel rajtigita.

Ensaluto respondas precize unu demandon: ĉu tiu identeco rajtas starigi seancon? Ĉion poste decidas apartaj reguloj, kiuj neniam vidas vian atestilon. Seanco, kiu aŭtentikiĝas, kaj pako, kiu alvenas, estas du malsamaj sukcesoj, kaj la breĉo inter ili estas kie loĝas la plej multaj raportoj de la tipo la VPN funkcias sed la gastiganto neatingeblas.

La kontroloj sube estas la ordo, kiun mi nun uzas.

Kion konektita seanco vere pruvas

Dum la manpremo la endpoint validigas la klientan atestilon kontraŭ sia trust store, aŭ plusendigas la retumilon al via identiga provizanto kiam SAML estas agordita. Se tio pasas, la kliento ricevas adreson el la klienta CIDR de la endpoint kaj la konzolo montras aktivan konekton. En neniu momento de tiu interŝanĝo io demandas, ĉu vi povas atingi 10.0.4.17 sur pordo 27017.

Permeso por celo estas aparta objekto sur la endpoint. Ĉiu fluo estas komparata kun la aŭtorigaj reguloj, kaj ĉiu el ili parigas celan CIDR kun la grupo, al kiu la regulo estas donita. Kiam neniu regulo kovras la celon, la endpoint akceptas la seancon kaj forĵetas la trafikon. Ne estas standardo, nek rekonekta buklo, nek io en la klienta fasado, kio diras rifuzita.

Komparu la aŭtorigan regulon kun la rimedo, ne kun la VPC

Listigu la regulojn kaj metu ilin apud la adreson, kiun la instalaĵo vere havas:

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

La eligilo montras celan CIDR kaj grupan ID por ĉiu regulo. Du paneoj kaŝiĝas en ĝi. La regulo povas aŭtorigi 10.0.0.0/16 dum la instalaĵo sidas en peerita VPC sur 10.1.0.0/16; la peering-itinero ekzistas, sed neniu skribis aŭtorigan regulon por la dua gamo. Aŭ la regulo montras al dosieruja grupo, al kiu la uzanto aliĝas en la dosierujo sed ne en la grupo, kiun la endpoint taksas.

Skribu la plej mallarĝan regulon, kiu kovras la celon, kaj aldonu duan nur kiam dua CIDR estas vere bezonata. Larĝa regulo 0.0.0.0/0 el rapida starto funkcias, kaj tial ĝi postvivas en produktado kaj kaŝas la modelon.

Du itinertabeloj decidas, ĉu la pako moviĝas

Endpoint-itinero mapas celan CIDR al unu el la subretoj, kun kiuj la endpoint estas asociita. Tio estas duono de vojo. La propra itinertabelo de la subreto ankoraŭ devas scii, kiel plusendi la pakon, kaj tio gravas en la momento, kiam la celo estas malantaŭ peering-konekto, transit gateway aŭ loka gamo atingebla per site-to-site-tunelo.

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

Serĉu itineron, kies celo kongruas kun la CIDR de la rimedo kaj kies celobjekto estas asociita subreto. Se la itinero mankas, aldonu ĝin. Se ĝi estas kaj la gastiganto restas silenta, la breĉo estas sur la VPC-flanko, do komparu kun la itinertabelo de la asocia subreto.

Unu klientflanka agordo rompas la itineradon sen rompi la tunelon: profilo, kiu enhavas route-nopull. La direktivo diras al kliento bazita sur OpenVPN ignori la itinerojn, kiujn la servilo puŝas, do la interfaco leviĝas nur kun la propra adreso de la endpoint kaj la celo simple ne havas itineron. Kontrolu per ip route show en Linux aŭ netstat -rn en macOS, ĉu ekzistas itinero tra la tun-interfaco. Se ne, forigu route-nopull el la eksportita profilo kaj rekonektiĝu, por ke la puŝitaj itineroj aplikiĝu.

Sekurecaj grupoj ne vidas la adreson de via kliento

Tio estas la parto, kiun mi havis malĝusta dum tuta posttagmezo. Por IPv4-endpoint asociita kun subreto, la servo tradukas la fontan adreson de la kliento al la adreso de la retinterfaco de la endpoint en tiu subreto. La pako, kiu alvenas al la instalaĵo, ne portas la adreson, kiun montris via kliento, do sekurecgrupa regulo, kiu permesas la klientan pool, diru 172.16.0.0/22, kongruas kun nenio.

Permesu la pordon el la sekureca grupo de la endpoint, kiu estas alligita al la interfaco de la asocio, anstataŭ el la klienta CIDR. Referenci la grupon estas pli daŭra ol malmola adreso, ĉar la adreson de la interfaco vi ne kontrolas. Retaj ACL estas senstataj, do kie ekzistas propraj enskriboj, kaj la enira kaj la elira direkto devas permesi la fluon.

Konektiĝu ankaŭ al la privata adreso de la instalaĵo. Publika IP elportas la pakon el la VPC kaj reportas ĝin per alia vojo kun aliaj reguloj, do publika testo diras nenion pri la privata vojo.

Izola ordo, kiu haltas ĉe la unua paneo

Trairu ilin laŭ ordo kaj haltu tie, kie unu paneas. Ĉiu paŝo ekskludas unu tavolon anstataŭ ĉiujn.

1. Konfirmu, kiun identecon la seanco uzis kaj kiun grupon la endpoint taksas. Atestilo el unu trust store ne estas la sama subjekto kiel SAML-aserto el la dosierujo.
2. Konfirmu, ke aŭtoriga regulo kovras la CIDR de la rimedo por tiu grupo.
3. Konfirmu, ke endpoint-itinero ekzistas kaj celas asociitan subreton, poste ke la itinertabelo de la subreto povas plusendi plu.
4. Konfirmu, ke la sekureca grupo permesas la pordon el la endpoint-interfaco, ne el la klienta pool.
5. Testu el interne de la VPC, per SSM-seanco sur alia instalaĵo en la sama subreto, por apartigi aplikadan problemon de klientvoja problemo.

Kiam la paŝoj ne estas decida, mi fidas je ĉi tiu tabelo:

Du kontodetaloj produktas simptomojn, kiuj aspektas kiel permesaj paneoj. Ĉiu uzanto bezonas apartan klientan atestilon; dividi unu inter du maŝinoj igas la seancojn anstataŭigi unu la alian, kaj la rezulto estas rekonekta buklo anstataŭ rifuzo. Kiam nova endpoint kreiĝas, la konzolo montras DNS-nomon, kiun iuj klientversioj akceptas nur kun la hazarda prefikso montrita sur la endpoint-paĝo, do kopiu la plenan nomon anstataŭ rekonstrui ĝin.

Se la kvina paŝo vin blokos, eltiru la konektan protokolon de la endpoint kaj legu la aŭtorigajn enskribojn antaŭ ol ŝanĝi ion. La protokolo nomas la kontrolitan celon kaj la regulon, kiu kongruis aŭ ne, kaj tio kunpremas la demandon de kvar tavoloj al unu respondo.