AWS Client VPN ir pievienots, bet EC2 joprojām neatbild

Mans portatīvais rādīja pievienots. AWS Client VPN klients rādīja savu zaļo stāvokli, endpoint reģistrēja sesiju, un tomēr es nevarēju atvērt MongoDB portu EC2 instancē privātā apakštīklā. Nekas acīmredzami nebija salūzis: sertifikāts bija derīgs, profils nāca no konsoles, un tunelis nesa datplūsmu. Kļūda bija mana, jo es lasīju pievienots kā autorizēts.

Pieteikšanās atbild tieši uz vienu jautājumu: vai šī identitāte drīkst izveidot sesiju? Visu pēc tam nosaka atsevišķi noteikumi, kas nekad neredz tavu sertifikātu. Sesija, kas autentificējas, un pakete, kas ierodas, ir divi dažādi panākumi, un plaisa starp tiem ir vieta, kur dzīvo lielākā daļa ziņojumu tipa VPN ir ieslēgts, bet hosts nav sasniedzams.

Zemāk esošās pārbaudes ir secība, ko tagad izmantoju.

Ko pievienota sesija patiešām pierāda

Handshake laikā endpoint validē klienta sertifikātu pret savu trust store vai novirza pārlūku uz tavu identitātes nodrošinātāju, kad SAML ir konfigurēts. Ja tas iziet, klients saņem adresi no endpoint klienta CIDR un konsolē parādās aktīvs savienojums. Nevienā šīs apmaiņas brīdī nekas nejautā, vai tu vari sasniegt 10.0.4.17 uz portu 27017.

Atļauja galamērķim ir atsevišķs objekts endpoint. Katra plūsma tiek salīdzināta ar autorizācijas noteikumiem, un katrs no tiem savieno galamērķa CIDR ar grupu, kurai noteikums piešķirts. Kad neviens noteikums neaptver galamērķi, endpoint pieņem sesiju un izmet datplūsmu. Nav ne reklāmjoslas, ne atkārtotas pieslēgšanās cilpas, ne kāda klienta saskarnes elementa, kas teiktu atteikts.

Salīdzini autorizācijas noteikumu ar resursu, nevis ar VPC

Uzskaiti noteikumus un noliec tos blakus adresei, kas instancei patiešām ir:

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

Izvade rāda galamērķa CIDR un grupas ID katram noteikumam. Tajā slēpjas divas kļūmes. Noteikums var autorizēt 10.0.0.0/16, kamēr instance atrodas peerotā VPC uz 10.1.0.0/16; peering maršruts pastāv, bet neviens nav uzrakstījis autorizācijas noteikumu otrajam diapazonam. Vai arī noteikums norāda uz direktorija grupu, kurai lietotājs pieder direktorijā, bet ne grupai, kuru endpoint novērtē.

Uzraksti šaurāko noteikumu, kas aptver galamērķi, un pievieno otru tikai tad, kad otrs CIDR tiešām ir vajadzīgs. Plats 0.0.0.0/0 noteikums no ātrās palaišanas strādā, un tāpēc tas izdzīvo līdz produkcijai un slēpj modeli.

Par to, vai pakete kustēsies, lemj divas maršrutu tabulas

Endpoint maršruts kartē galamērķa CIDR uz vienu no apakštīkliem, ar kuriem endpoint ir saistīts. Tā ir puse ceļa. Paša apakštīkla maršrutu tabulai joprojām jāzina, kā paketi pārsūtīt tālāk, un tas kļūst svarīgi mirklī, kad galamērķis atrodas aiz peering savienojuma, transit gateway vai vietējā diapazona, kas sasniedzams pa site-to-site tuneli.

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

Meklē maršrutu, kura galamērķis atbilst resursa CIDR un kura mērķis ir saistīts apakštīkls. Ja maršruta nav, pievieno to. Ja tas ir un hosts joprojām klusē, plaisa ir VPC pusē, tāpēc salīdzini ar asociācijas apakštīkla maršrutu tabulu.

Viens klienta puses iestatījums salauž maršrutēšanu, nesalaužot tuneli: profils, kurā ir route-nopull. Direktīva liek OpenVPN balstītam klientam ignorēt maršrutus, ko serveris bīda, tāpēc saskarne ceļas tikai ar paša endpoint adresi un galamērķim vienkārši nav maršruta. Pārbaudi ar ip route show Linux vai netstat -rn macOS, vai ir maršruts caur tun saskarni. Ja nav, izņem route-nopull no eksportētā profila un pieslēdzies no jauna, lai bīdītie maršruti tiktu piemēroti.

Drošības grupas neredz tava klienta adresi

Šī ir daļa, ko visu pēcpusdienu biju sapratis nepareizi. IPv4 endpoint, kas saistīts ar apakštīklu, pakalpojums pārtulko klienta avota adresi uz endpoint tīkla saskarnes adresi tajā apakštīklā. Pakete, kas nonāk instancē, nesatur adresi, ko rādīja tavs klients, tāpēc drošības grupas noteikums, kas atļauj klientu baseinu, teiksim 172.16.0.0/22, neatbilst nekam.

Atļauj portu no endpoint drošības grupas, kas piesaistīta asociācijas saskarnei, nevis no klienta CIDR. Atsauce uz grupu ir noturīgāka par cieti ierakstītu adresi, jo saskarnes adresi nekontrolē tu. Tīkla ACL ir bez stāvokļa, tāpēc tur, kur ir pielāgoti ieraksti, gan ienākošajam, gan izejošajam virzienam jāatļauj plūsma.

Pieslēdzies arī instances privātajai adresei. Publiska IP izved paketi no VPC un ieved to atpakaļ pa citu ceļu ar citiem noteikumiem, tāpēc publiskas adreses tests neko nepasaka par privāto ceļu.

Izolācijas kārtība, kas apstājas pie pirmās kļūmes

Izej cauri pēc kārtas un apstājies tur, kur viens neizdodas. Katrs solis izslēdz vienu slāni, nevis visus.

1. Pārliecinies, kuru identitāti sesija izmantoja un kuru grupu endpoint novērtē. Sertifikāts no viena trust store nav tas pats subjekts kā SAML apgalvojums no direktorija.
2. Pārliecinies, ka autorizācijas noteikums aptver resursa CIDR šai grupai.
3. Pārliecinies, ka endpoint maršruts pastāv un ir vērsts uz saistītu apakštīklu, un pēc tam, ka apakštīkla maršrutu tabula var pārsūtīt tālāk.
4. Pārliecinies, ka drošības grupa atļauj portu no endpoint saskarnes, nevis no klientu baseina.
5. Pārbaudi VPC iekšienē, ar SSM sesiju citā instancē tajā pašā apakštīklā, lai atdalītu lietojumprogrammas problēmu no klienta ceļa problēmas.

Kad soļi nav izšķiroši, es atgriežos pie šīs tabulas:

Divas konta detaļas rada simptomus, kas izskatās kā atļauju kļūmes. Katram lietotājam vajadzīgs atsevišķs klienta sertifikāts; vienu dalot starp divām mašīnām, sesijas izspiež viena otru, un rezultāts ir atkārtotas pieslēgšanās cilpa, nevis atteikums. Kad tiek izveidots jauns endpoint, konsolē parādās DNS vārds, ko dažas klienta versijas pieņem tikai ar nejaušo prefiksu, kas redzams endpoint lapā, tāpēc nokopē pilno vārdu, nevis rekonstruē to.

Ja piektais solis tevi iestrēdzina, pirms kaut ko mainīt izvelc endpoint savienojumu žurnālu un izlasi autorizācijas ierakstus. Žurnāls nosauc pārbaudīto galamērķi un noteikumu, kas atbilda vai nē, un tas četru slāņu jautājumu savelk vienā atbildē.