AWS Client VPN konektatuta, baina EC2 oraindik ez du erantzuten

Nire eramangarriak konektatuta zioen. AWS Client VPN bezeroak bere egoera berdea erakusten zuen, endpoint-ak saio bat erregistratu zuen, eta hala ere ezin nuen MongoDB portu bat ireki EC2 instantzia batean subred pribatu batean. Ezer ez zegoen begi-bistakoan hondatuta: ziurtagiria baliozkoa zen, profila kontsolatik zetorren eta tunelak trafikoa zeraman. Akatsa nirea zen, konektatuta baimenduta gisa irakurtzen bainuen.

Saio-hasierak galdera bakarra erantzuten du: identitate honek saio bat ezar dezake? Hori ondoren datozen guztia zure ziurtagiria inoiz ikusten ez duten arau bereiziek erabakitzen dute. Autentifikatzen den saioa eta heltzen den paketea bi arrakasta desberdin dira, eta bien arteko hutsunea VPN-a martxan dago baina host-a ez da iristen motako kexa gehienak bizi diren tokia da.

Beheko egiaztapenak orain erabiltzen dudan ordena dira.

Zer frogatzen du benetan saio konektatu batek

Handshake-an endpoint-ak bezeroaren ziurtagiria bere trust store-aren aurka baliozkotzen du, edo nabigatzailea zure identity provider-era birbideratzen du SAML konfiguratuta dagoenean. Hori pasatzen bada, bezeroak endpoint-aren bezero CIDR-etik helbide bat jasotzen du eta kontsolak konexio aktiboa erakusten du. Truke horretan inoiz ez da galdetzen ea 10.0.4.17-ra irits zaitezkeen 27017 portuan.

Helmuga baterako baimena endpoint-eko objektu bereizia da. Fluxu bakoitza baimen-arauekin parekatzen da, eta bakoitzak helmugako CIDR bat araua ematen zaion taldearekin lotzen du. Inongo arauk helmuga estaltzen ez duenean, endpoint-ak saioa onartzen du eta trafikoa botatzen du. Ez dago banderarik, ez berriro konektatzeko begiztarik, eta ez bezeroaren interfazean ukatuta dioen ezer.

Konparatu baimen-araua baliabidearekin, ez VPC-rekin

Zerrendatu arauak eta jarri instantziak benetan duen helbidearen ondoan:

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

Irteerak helmugako CIDR bat eta talde ID bat erakusten ditu arau bakoitzeko. Bi hutsegite daude ezkutatuta. Arauak 10.0.0.0/16 baimendu dezake instantzia 10.1.0.0/16-n peer egindako VPC batean dagoen bitartean; peering bidea existitzen da, baina inork ez zuen bigarren barrutirako baimen-arau bat idatzi. Edo arauak direktorioko talde bat seinalatzen du, non erabiltzailea direktorioan dagoen baina ez endpoint-ak ebaluatzen duen taldean.

Idatzi helmuga estaltzen duen arau estuena, eta gehitu bigarren bat bigarren CIDR bat benetan beharrezkoa denean soilik. Hasiera azkar batetik datorren 0.0.0.0/0 arau zabalak funtzionatzen du, eta horregatik irauten du produkzioraino eta modeloa ezkutatzen du.

Bi bide-taulak erabakitzen dute paketea mugitzen den

Endpoint bide batek helmugako CIDR bat endpoint-a lotuta dagoen subredetako batera mapatzen du. Bidearen erdia da hori. Subredaren beraren bide-taulak oraindik jakin behar du paketea nola birbidali, eta horrek garrantzia du helmuga peering konexio baten, transit gateway baten edo site-to-site tunel baten bidez iristeko moduko tokiko barruti baten atzean dagoen unean.

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

Bilatu helmuga baliabidearen CIDR-arekin bat datorren eta helburua lotutako subred bat den bide bat. Bidea falta bada, gehitu. Bertan badago eta host-a isilik jarraitzen badu, hutsunea VPC aldean dago, beraz konparatu elkartze-subredaren bide-taularekin.

Bezero aldeko ezarpen batek bideratzea hausten du tunela hautsi gabe: route-nopull duen profil bat. Zuzentarauak OpenVPNean oinarritutako bezeroari esaten dio ez ditzala kontuan hartu zerbitzariak bultzatutako bideak, beraz interfazea endpoint-aren beraren helbidearekin igotzen da eta helmugak ez du biderik. Egiaztatu ip route show erabiliz Linux-en edo netstat -rn macOS-en tun interfazearen bidezko biderik badagoen. Ez badago, kendu route-nopull esportatutako profiletik eta konektatu berriro bultzatutako bideak aplika daitezen.

Segurtasun-taldeek ez dute zure bezeroaren helbidea ikusten

Hau da arratsalde oso batean gaizki eduki nuen zatia. Subred batekin lotuta dagoen IPv4 endpoint baterako, zerbitzuak bezeroaren iturburu-helbidea endpoint-aren sare-interfazearen helbidera itzultzen du subred horretan. Instantziara heltzen den paketeak ez du zure bezeroak erakutsi zuen helbidea eramaten, beraz bezeroen pool-a, esan dezagun 172.16.0.0/22, uzten duen segurtasun-talde arau batek ez du ezerkin bat egiten.

Baimendu portua endpoint-aren segurtasun-taldetik, elkartzearen interfazeari lotuta dagoena, eta ez bezeroaren CIDR-etik. Taldea erreferentziatzea helbide bat gogor kodetzea baino iraunkorragoa da, interfazearen helbidea ez baita zurea kontrolatzeko. Sare ACL-ak egoerarik gabeak dira, beraz sarrera pertsonalizatuak dauden tokian, sarrerako eta irteera norabideek fluxua onartu behar dute.

Instantziaren helbide pribatura ere konektatu. IP publiko batek paketea VPC-tik ateratzen du eta beste bide batetik sartzen du beste arau batzuekin, beraz helbide publikoaren probak ez du ezer esaten bide pribatuaz.

Lehen hutsegitean gelditzen den isolamendu ordena

Joan hauek ordenan eta gelditu bat huts egiten duen tokian. Urrats bakoitzak geruza bat baztertzen du, ez denak.

1. Egiaztatu saioak zein identitate erabili zuen eta endpoint-ak zein talde ebaluatzen duen. Trust store bateko ziurtagiria ez da direktorioko SAML baieztapen bat bezalako subjektu bera.
2. Egiaztatu baimen-arau batek talde horretarako baliabidearen CIDR-a estaltzen duela.
3. Egiaztatu endpoint bide bat badagoela eta lotutako subred batera zuzentzen dela, gero subredaren bide-taulak aurrera egin dezakeela.
4. Egiaztatu segurtasun-taldeak portua endpoint interfazetik uzten duela, ez bezeroen pooletik.
5. Probatu VPC-ren barrualdetik, SSM saio batekin subred bereko beste instantzia batean, aplikazio arazo bat bezeroaren bide arazo batetik bereizteko.

Urratsek erabakitzen ez dutenean, taula hau da nire errekurtsoa:

Kontuaren bi xehetasunek baimen hutsegiteen antzeko sintomak sortzen dituzte. Erabiltzaile bakoitzak bezero ziurtagiri desberdin bat behar du; bat bi makinaren artean partekatzeak saioak elkar bultzatzea eragiten du, eta emaitza berriro konektatzeko begizta da, ez ukapena. Endpoint berri bat sortzen denean, kontsolak DNS izen bat erakusten du, bezeroaren bertsio batzuek endpoint orrialdean agertzen den ausazko aurrizkiarekin soilik onartzen dutena, beraz kopiatu izen osoa berreraiki beharrean.

Bosgarren urratsak trabatuta uzten bazaitu, atera endpoint-aren konexio erregistroa eta irakurri baimen-sarrerak ezer aldatu aurretik. Erregistroak egiaztatutako helmuga eta bat etorri zen edo ez zen araua izendatzen ditu, eta horrek lau geruzako galdera erantzun bakarrera murrizten du.