AWS Client VPN on yhdistetty, mutta EC2 ei silti vastaa

Kannettavani ilmoitti yhdistetty. AWS Client VPN -asiakas näytti vihreää tilaansa, endpoint kirjasi istunnon, ja silti en saanut avattua MongoDB-porttia EC2-instanssilla yksityisessä aliverkossa. Mikään ei ollut selvästi rikki: varmenne oli voimassa, profiili tuli konsolista ja tunneli kuljetti liikennettä. Virhe oli minun, koska luin yhdistetyn tarkoittavan valtuutettua.

Kirjautuminen vastaa täsmälleen yhteen kysymykseen: saako tämä identiteetti muodostaa istunnon? Kaiken sen jälkeen päättävät erilliset säännöt, jotka eivät koskaan näe varmennettasi. Istunto, joka todennetaan, ja paketti, joka saapuu perille, ovat kaksi eri onnistumista, ja niiden välinen kuilu on paikka, jossa suurin osa VPN on ylhäällä mutta isäntä ei vastaa -tyyppisistä ilmoituksista elää.

Alla olevat tarkistukset ovat järjestys, jota nyt käytän.

Mittä yhdistetty istunto todella todistaa

Kättelyn aikana endpoint validoi asiakasvarmenteen omaa trust storeaan vasten tai ohjaa selaimen identiteetintarjoajaasi, kun SAML on määritetty. Jos se menee läpi, asiakas saa osoitteen endpointin asiakas-CIDR:stä ja konsoli näyttää aktiivisen yhteyden. Missään vaiheessa tuota vaihtoa mikään ei kysy, pääsetkö osoitteeseen 10.0.4.17 portista 27017.

Lupa kohteeseen on erillinen objekti endpointissa. Jokainen virta sovitetaan valtuutussääntöihin, ja kukin sääntö yhdistää kohde-CIDR:n ryhmään, jolle sääntö on myönnetty. Kun mikään sääntö ei kata kohdetta, endpoint hyväksyy istunnon ja pudottaa liikenteen. Ei ole banneria, ei uudelleenyhdistämisen silmukkaa eikä mitään asiakkaan käyttöliittymässä, joka sanoisi evätty.

Vertaa valtuutussääntöä resurssiin, älä VPC:hen

Listaa säännöt ja aseta ne sen osoitteen viereen, joka instanssilla todella on:

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

Tuloste näyttää kohde-CIDR:n ja ryhmätunnuksen sääntöä kohden. Siihen kätkeytyy kaksi vikaa. Sääntö voi valtuuttaa 10.0.0.0/16, kun instanssi istuu peeratussa VPC:ssä osoitteessa 10.1.0.0/16; peering-reitti on olemassa, mutta kukaan ei kirjoittanut valtuutussääntöä toiselle alueelle. Tai sääntö osoittaa hakemistoryhmään, johon käyttäjä kuuluu hakemistossa mutta ei siinä ryhmässä, jonka endpoint arvioi.

Kirjoita kapein sääntö, joka kattaa kohteen, ja lisää toinen vain, kun toinen CIDR on todella tarpeen. Pikakäynnistyksen laaja 0.0.0.0/0-sääntö toimii, ja siksi se selviää tuotantoon ja piilottaa mallin.

Kaksi reititystaulua päättää, liikkuuko paketti

Endpoint-reitti kuvaa kohde-CIDR:n yhdeksi niistä aliverkoista, joihin endpoint on liitetty. Se on puoli matkaa. Aliverkon omassa reititystaulussa on yhä tiedettävä, miten paketti välitetään eteenpäin, ja sillä on merkitystä heti, kun kohde on peering-yhteyden, transit gatewayn tai sivustolta sivustolle -tunnelilla saavutettavan paikallisen alueen takana.

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

Etsi reitti, jonka kohde vastaa resurssin CIDR:ää ja jonka kohdeosoite on liitetty aliverkko. Jos reitti puuttuu, lisää se. Jos se on olemassa ja isäntä on yhä vaiti, kuilu on VPC:n puolella, joten vertaa liitoksen aliverkon reititystauluun.

Yksi asiakaspuolen asetus rikkoo reitityksen rikkomatta tunnelia: profiili, joka sisältää route-nopull. Direktiivi käskee OpenVPN-pohjaista asiakasta jättämään huomioimatta reitit, joita palvelin työntää, joten liitäntä nousee vain endpointin omalla osoitteella ja kohteella ei yksinkertaisesti ole reittiä. Tarkista komennolla ip route show Linuxissa tai netstat -rn macOS:ssä, onko tun-liitännän kautta reittiä. Jos ei ole, poista route-nopull viedystä profiilista ja yhdistä uudelleen, jotta työnnetyt reitit tulevat voimaan.

Tietoturvaryhmät eivät näe asiakkaasi osoitetta

Tämä on se osa, jonka sain väärin koko iltapäivän. Aliverkkoon liitetylle IPv4-endpointille palvelu kääntää asiakkaan lähdeosoitteen endpointin verkkoliitännän osoitteeksi siinä aliverkossa. Instanssille saapuva paketti ei kanna osoitetta, jonka asiakkaasi näytti, joten asiakaspoolin, sanotaan 172.16.0.0/22, salliva tietoturvaryhmän sääntö ei vastaa yhtään mitään.

Salli portti endpointin tietoturvaryhmästä, joka on kiinnitetty liitoksen liitäntään, älä asiakas-CIDR:stä. Ryhmään viittaaminen on kestävämpää kuin osoitteen kovakoodaus, koska liitännän osoite ei ole sinun hallittavissasi. Verkon ACL:t ovat tilattomia, joten missä mukautettuja merkintöjä on, sekä saapuvan että lähtevän suunnan on sallittava virta.

Yhdistä myös instanssin yksityiseen osoitteeseen. Julkinen IP vie paketin VPC:stä ulos ja takaisin eri reittiä pitkin eri säännöillä, joten julkinen testi ei kerro yksityisestä reitistä mitään.

Eristysjärjestys, joka pysähtyy ensimmäiseen epäonnistumiseen

Käy nämä järjestyksessä läpi ja pysähdy siihen, missä yksi epäonnistuu. Jokainen vaihe sulkee pois yhden kerroksen, ei kaikkia.

1. Varmista, mitä identiteettiä istunto käytti ja mitä ryhmää endpoint arvioi. Yhden trust storen varmenne ei ole sama subjekti kuin hakemistosta tuleva SAML-väite.
2. Varmista, että valtuutussääntö kattaa resurssin CIDR:n kyseiselle ryhmälle.
3. Varmista, että endpoint-reitti on olemassa ja osoittaa liitettyyn aliverkkoon, ja sitten että aliverkon reititystaulu pystyy välittämään eteenpäin.
4. Varmista, että tietoturvaryhmä sallii portin endpointin liitännästä, ei asiakaspoolista.
5. Testaa VPC:n sisältä SSM-istunnolla toisella instanssilla samassa aliverkossa erottaaksesi sovellusongelman asiakkaan reitin ongelmasta.

Kun vaiheet eivät ole ratkaisevia, turvaudun tähän tauluun:

Kaksi tilitietoa tuottaa oireita, jotka näyttävät lupien epäonnistumisilta. Jokainen käyttäjä tarvitsee erillisen asiakasvarmenteen; yhden jakaminen kahdelle koneelle saa istunnot syrjäyttämään toisiaan, ja tuloksena on uudelleenyhdistämisen silmukka, ei kieltäytyminen. Kun uusi endpoint luodaan, konsoli näyttää DNS-nimen, jonka jotkin asiakasversiot hyväksyvät vain endpoint-sivulla näkyvällä satunnaisella etuliitteellä, joten kopioi koko nimi sen sijaan että rakentaisit sen uudelleen.

Jos viides vaihe jättää sinut jumiin, hae endpointin yhteysloki ja lue valtuutusmerkinnät ennen kuin muutat mitään. Loki nimeää tarkistetun kohteen ja säännön, joka täsmäsi tai ei täsmännyt, ja se kutistaa nelikerroksisen kysymyksen yhdeksi vastaukseksi.