AWS Client VPN povezan, ali EC2 se i dalje ne odaziva

Moj laptop je pokazivao povezan. AWS Client VPN klijent je pokazivao zeleno stanje, endpoint je zabilježio sesiju, a ja ipak nisam mogao otvoriti MongoDB port na EC2 instanci u privatnoj podmreži. Ništa očigledno nije bilo pokvareno: certifikat je bio valjan, profil je došao iz konzole, a tunel je prenosio saobraćaj. Greška je bila moja, jer sam povezan čitao kao autorizovan.

Prijava odgovara tačno na jedno pitanje: smije li ovaj identitet uspostaviti sesiju? Sve poslije toga odlučuju odvojena pravila koja nikad ne vide vaš certifikat. Sesija koja se autentificira i paket koji stigne dva su različita uspjeha, a jaz između njih je mjesto gdje živi većina prijava tipa VPN radi, ali host je nedostupan.

Provjere ispod su redoslijed koji sada koristim.

Šta povezana sesija zapravo dokazuje

Tokom handshakea endpoint provjerava klijentski certifikat prema svom trust storeu ili preusmjerava preglednik na vaš identity provider kad je konfiguriran SAML. Ako to prođe, klijent dobija adresu iz klijentskog CIDR-a endpointa i konzola pokazuje aktivnu vezu. Ni u jednom trenutku te razmjene ništa ne pita možete li dosegnuti 10.0.4.17 na portu 27017.

Dozvola za odredište je odvojen objekt na endpointu. Svaki tok se poredi s pravilima autorizacije, a svako pravilo spaja CIDR odredišta s grupom kojoj je pravilo dato. Kad nijedno pravilo ne pokriva odredište, endpoint prihvata sesiju i odbacuje saobraćaj. Nema bannera, nema petlje ponovnog povezivanja i ničega u klijentskom sučelju što kaže odbijeno.

Uporedite pravilo autorizacije s resursom, ne s VPC-om

Izlistajte pravila i stavite ih pored adrese koju instanca stvarno ima:

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

Izlaz pokazuje CIDR odredišta i ID grupe po pravilu. U njemu se kriju dva kvara. Pravilo može autorizovati 10.0.0.0/16 dok instanca stoji u peerovanom VPC-u na 10.1.0.0/16; peering ruta postoji, ali niko nije napisao pravilo autorizacije za drugi raspon. Ili pravilo pokazuje na direktorijsku grupu u koju se korisnik pridružuje u direktoriju, ali ne i u grupi koju endpoint procjenjuje.

Napišite najuže pravilo koje pokriva odredište i dodajte drugo samo kad je drugi CIDR zaista potreban. Široko pravilo 0.0.0.0/0 iz brzog starta radi, i zato preživi u produkciji i sakrije model.

Dvije rute tabele odlučuju hoće li paket krenuti

Endpoint ruta mapira CIDR odredišta na jednu od podmreža s kojima je endpoint povezan. To je pola puta. Vlastita ruta tabela podmreže još mora znati kako proslijediti paket, a to je važno onog trenutka kad je odredište iza peering veze, transit gatewaya ili lokalnog raspona dostupnog preko site-to-site tunela.

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

Tražite rutu čije odredište odgovara CIDR-u resursa i čija je meta povezana podmreža. Ako ruta nedostaje, dodajte je. Ako postoji, a host i dalje ćuti, jaz je na strani VPC-a, pa uporedite s rutom tabelom podmreže asocijacije.

Jedna klijentska postavka kvari rutiranje bez kvarenja tunela: profil koji sadrži route-nopull. Direktiva govori klijentu zasnovanom na OpenVPN da ignoriše rute koje server gura, pa se interfejs podiže samo s vlastitom adresom endpointa i odredište jednostavno nema rutu. Provjerite s ip route show na Linuxu ili netstat -rn na macOS-u postoji li ruta kroz tun interfejs. Ako ne postoji, uklonite route-nopull iz izvezenog profila i ponovo se povežite da bi se gurnute rute primijenile.

Sigurnosne grupe ne vide adresu vašeg klijenta

To je dio u kojem sam griješio cijelo jedno poslijepodne. Za IPv4 endpoint povezan s podmrežom, servis prevodi izvornu adresu klijenta u adresu mrežnog interfejsa endpointa u toj podmreži. Paket koji stigne do instance ne nosi adresu koju je vaš klijent prikazao, pa pravilo sigurnosne grupe koje dozvoljava klijentski pool, recimo 172.16.0.0/22, ne pogađa baš ništa.

Dozvolite port iz sigurnosne grupe endpointa, koja je prikačena na interfejs asocijacije, a ne iz klijentskog CIDR-a. Pozivanje na grupu trajnije je od tvrdo upisane adrese, jer adresom interfejsa ne upravljate vi. Mrežni ACL-ovi su bez stanja, pa gdje postoje prilagođeni unosi, i dolazni i odlazni smjer moraju dopuštati tok.

Povežite se i na privatnu adresu instance. Javni IP izvodi paket iz VPC-a i vraća ga drugim putem s drugim pravilima, pa javni test ne govori ništa o privatnom putu.

Redoslijed izolacije koji staje na prvom kvaru

Prođite kroz ovo po redu i stanite gdje nešto padne. Svaki korak isključuje jedan sloj, a ne sve njih.

1. Potvrdite koji je identitet sesija koristila i koju grupu endpoint procjenjuje. Certifikat iz jednog trust storea nije isti subjekt kao SAML tvrdnja iz direktorija.
2. Potvrdite da pravilo autorizacije pokriva CIDR resursa za tu grupu.
3. Potvrdite da endpoint ruta postoji i cilja povezanu podmrežu, zatim da ruta tabela podmreže može proslijediti dalje.
4. Potvrdite da sigurnosna grupa dozvoljava port s interfejsa endpointa, a ne iz klijentskog poola.
5. Testirajte iz VPC-a, SSM sesijom na drugoj instanci u istoj podmreži, da razdvojite problem aplikacije od problema klijentskog puta.

Kad koraci ne budu odlučujući, oslanjam se na ovu tabelu:

Dva detalja računa daju simptome koji liče na odbijanje dozvola. Svakom korisniku treba poseban klijentski certifikat; dijeljenje jednog na dva računara čini da sesije potiskuju jedna drugu, a rezultat je petlja ponovnog povezivanja, ne odbijanje. Kad se stvori novi endpoint, konzola prikazuje DNS ime koje neke verzije klijenta prihvataju samo sa slučajnim prefiksom prikazanim na stranici endpointa, pa kopirajte puno ime umjesto da ga rekonstruišete.

Ako vas peti korak zaglavi, izvucite dnevnik veza endpointa i pročitajte unose autorizacije prije nego što bilo šta promijenite. Dnevnik imenuje provjereno odredište i pravilo koje se poklopilo ili nije, a to svodi pitanje s četiri sloja na jedan odgovor.