AWS Client VPN je povezan, a EC2 se še vedno ne odziva

Moj prenosnik je kazal povezan. Odjemalec AWS Client VPN je kazal svoje zeleno stanje, endpoint je zabeležil sejo, in vseeno nisem mogel odpreti vrat MongoDB na instanci EC2 v zasebni podomrežju. Nič ni bilo očitno pokvarjeno: potrdilo je bilo veljavno, profil je prišel iz konzole in tunel je prenašal promet. Napaka je bila moja, ker sem povezan bral kot pooblaščen.

Prijava odgovori natanko na eno vprašanje: sme ta identiteta vzpostaviti sejo? Vse po tem odločajo ločena pravila, ki nikoli ne vidijo tvojega potrdila. Seja, ki se overi, in paket, ki prispe, sta dva različna uspeha, in vrzel med njima je kraj, kjer živi večina poročil tipa VPN je gor, a gostitelj ni dosegljiv.

Spodnje preverbe so vrstni red, ki ga zdaj uporabljam.

Kaj povezana seja v resnici dokazuje

Med handshakeom endpoint preveri odjemalčevo potrdilo glede na svoj trust store ali preusmeri brskalnik k tvojemu ponudniku identitete, ko je konfiguriran SAML. Če to prestane, odjemalec prejme naslov iz odjemalčevega CIDR endpointa in konzola pokaže aktivno povezavo. V nobenem trenutku te izmenjave nihče ne vpraša, ali lahko dosežeš 10.0.4.17 na vratih 27017.

Dovoljenje za cilj je ločen objekt na endpointu. Vsak tok se primerja s pravili avtorizacije, in vsako od njih poveže CIDR cilja s skupino, ki ji je pravilo dodeljeno. Ko nobeno pravilo ne pokriva cilja, endpoint sejo sprejme in promet zavrže. Ni pasice, ni zanke ponovnega povezovanja in ničesar v vmesniku odjemalca, kar bi reklo zavrnjeno.

Primerjaj pravilo avtorizacije z virom, ne z VPC

Naštej pravila in jih položi ob naslov, ki ga instanca v resnici ima:

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

Izhod pokaže CIDR cilja in ID skupine za vsako pravilo. V njem se skrivata dve okvari. Pravilo lahko avtorizira 10.0.0.0/16, medtem ko instanca sedi v peerani VPC na 10.1.0.0/16; peering pot obstaja, a nihče ni napisal pravila avtorizacije za drugo območje. Ali pravilo kaže na skupino v imeniku, katere član je uporabnik v imeniku, ne pa v skupini, ki jo endpoint ocenjuje.

Napiši najožje pravilo, ki pokriva cilj, in drugo dodaj le, ko je drugi CIDR res potreben. Široko pravilo 0.0.0.0/0 iz hitrega zagona deluje, in prav zato preživi v produkcijo in skrije model.

O tem, ali se paket premakne, odločata dve usmerjevalni tabeli

Pot endpointa preslika CIDR cilja v eno od podomrežij, s katerimi je endpoint povezan. To je polovica poti. Lastna usmerjevalna tabela podomrežja mora še vedno vedeti, kako paket poslati naprej, in to šteje v trenutku, ko je cilj za peering povezavo, transit gateway ali lokalnim obsegom, dosegljivim skozi tunel site-to-site.

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

Išči pot, katere cilj se ujema s CIDR virom in katere ciljna točka je povezano podomrežje. Če pot manjka, jo dodaj. Če obstaja in gostitelj še vedno molči, je vrzel na strani VPC, zato jo primerjaj z usmerjevalno tabelo pridruženega podomrežja.

Ena nastavitev na strani odjemalca pokvari usmerjanje, ne da bi pokvarila tunel: profil, ki vsebuje route-nopull. Direktiva reče odjemalcu, ki temelji na OpenVPN, naj prezre poti, ki jih potiska strežnik, zato se vmesnik dvigne le z lastnim naslovom endpointa in cilj preprosto nima poti. Preveri z ip route show na Linuxu ali netstat -rn na macOS, ali pot skozi vmesnik tun obstaja. Če ne, odstrani route-nopull iz izvoženega profila in se znova poveži, da se potisnjene poti uporabijo.

Varnostne skupine ne vidijo naslova tvojega odjemalca

To je del, ki sem ga imel narobe celo popoldne. Za IPv4 endpoint, povezan s podomrežjem, storitev prevede izvorni naslov odjemalca v naslov omrežnega vmesnika endpointa v tem podomrežju. Paket, ki prispe do instance, ne nosi naslova, ki ga je kazal tvoj odjemalec, zato pravilo varnostne skupine, ki dovoljuje sklad odjemalcev, recimo 172.16.0.0/22, ne ustreza ničemur.

Dovoli vrata iz varnostne skupine endpointa, ki je pripeta na vmesnik povezave, ne iz odjemalčevega CIDR. Sklicevanje na skupino je trajnejše od trdo zapisanega naslova, ker naslova vmesnika ne nadzoruješ ti. Omrežni ACL so brez stanja, zato morata tam, kjer so vnosi po meri, tok dovoliti oba smeri, vhodna in izhodna.

Poveži se tudi z zasebnim naslovom instance. Javni IP popelje paket iz VPC in ga pripelje nazaj po drugi poti z drugimi pravili, zato test na javnem naslovu ne pove ničesar o zasebni poti.

Vrstni red izolacije, ki se ustavi pri prvi okvari

Pojdi skozi te po vrsti in se ustavi tam, kjer ena odpove. Vsak korak izloči eno plast, ne vseh.

1. Potrdi, katero identiteto je uporabila seja in katero skupino endpoint ocenjuje. Potrdilo iz enega trust store ni isti subjekt kot trditev SAML iz imenika.
2. Potrdi, da pravilo avtorizacije pokriva CIDR vira za to skupino.
3. Potrdi, da pot endpointa obstaja in kaže na pridruženo podomrežje, nato da lahko usmerjevalna tabela podomrežja pošlje naprej.
4. Potrdi, da varnostna skupina dovoljuje vrata z vmesnika endpointa in ne iz sklada odjemalcev.
5. Testiraj znotraj VPC, s sejo SSM na drugi instanci v istem podomrežju, da ločiš težavo aplikacije od težave odjemalčeve poti.

Ko koraki niso odločilni, se oprem na to tabelo:

Dve podrobnosti računa ustvarita simptome, ki so videti kot odpoved dovoljenj. Vsak uporabnik potrebuje ločeno odjemalčevo potrdilo; če eno deliš med dvema strojema, se seje medsebojno izrivajo, rezultat pa je zanka ponovnega povezovanja, ne zavrnitev. Ko se ustvari nov endpoint, konzola pokaže ime DNS, ki ga nekatere različice odjemalca sprejmejo le z naključno predpono, prikazano na strani endpointa, zato kopiraj celotno ime, namesto da bi ga sestavljal znova.

Če te peti korak ustavi, pred kakršno koli spremembo potegni dnevnik povezav endpointa in preberi vnose avtorizacije. Dnevnik navede preverjeni cilj in pravilo, ki se je ujemalo ali ne, in to skrči vprašanje s štirimi plastmi na en odgovor.