AWS Client VPN ar bastionas pasiekti peering VPC

Vienas Client VPN endpoint gali pasiekti VPC, kuris yra peering ryšyje su jo susietu VPC, ir tam legitimizuoti bastiono nereikia. Pasirinkimas, kurį verta padaryti, yra kur srautas pereina iš rankų į rankas: endpoint maršrutas, kuris nusileidžia asociacijos potinkyje ir kerta peering ryšį, arba hostas peering VPC, kuris užbaigia sesiją. Abu keliai veikia ir jie žlunga skirtingose vietose, todėl sprendimas yra apie nuosavybę ir auditą, o ne apie tai, ką leidžia AWS. Štai kaip renkuosi tarp jų, ir keturi įrašai, kurie padaro maršrutizuotą kelią veikiantį.

Du keliai, vienas endpoint, skirtingi savininkai

Maršrutizuotame kelyje kliento srautas pasiekia endpoint, išverčiamas į Client VPN tinklo sąsajos adresą asociacijos potinkyje ir palieka tą potinklį per peering ryšį iš A į B. VPC B neužbaigia jokios VPN sesijos; jis mato įprastą srautą iš VPC A, todėl jo grįžtamasis maršrutas rodo į VPC A, o ne į klientų telkinį.

Bastiono kelyje klientas pirmiausia pasiekia hostą. Bastionas A vis dar palieka paskutinį šuolį kirsti peering ryšį, tad peering darbas lieka ir pridedama sesija. Bastionas B taip pat reikalauja kelio nuo kliento, ir kai tas kelias yra tas pats endpoint maršrutas, turite maršrutizuotą dizainą plius vieną šuolį. Bastionas atima darbą tik tada, kai jis jau egzistuoja, jau patvirtintas, ir tai, kas už jo, reikalauja sesijos ribos, o ne tinklo ribos.

Keturi įrašai padaro maršrutizuotą kelią veikiantį

AWS dokumentuoja šį scenarijų Client VPN how-it-works puslapyje, ir praktiškai viskas susiveda į keturis įrašus, kuriuos valdo dvi ar trys komandos. Diapazonai yra iliustratyvūs; peering diapazonas turi būti unikalus, o grįžtamasis diapazonas turi atitikti jūsų planą.

Maršrutas ir leidimas yra atskiros kontrolės. Teisingas endpoint maršrutas be atitinkamos autorizacijos taisyklės klientui nieko neduoda; autorizacijos taisyklė paskirčiai, kurios endpoint negali maršrutizuoti, duoda jam juodą skylę. Abi turi įvardyti tą patį diapazoną.

Endpoint maršrutas rodo į potinklį endpointo pačio VPC, niekada į peering ryšį. VPC maršrutų lentelės rodo į peering ryšį, niekada į instanciją ar sąsają. Vertės kopijavimas tarp jų išsaugomas be priekaištų ir nieko nemaršrutizuoja.

Kadangi asociacijos potinklis išverčia kliento šaltinį, B turi maršrutizuoti atgal į VPC A, o ne į klientų telkinį. Kliento diapazono siuntimas per peering ryšį atrodo simetriškai, praeina peržiūrą ir tyliai žlunga, nes B niekada nemato paketo su kliento šaltiniu.

Saugos grupės ir paskutinis leidimo metras

Maršrutizavimas įneša paketus į B; B vis tiek sprendžia. Aktyviam peering ryšiui tame pačiame regione B saugos grupė gali nurodyti grupę, taikomą Client VPN asociacijai, o tai išlaiko taisyklę siaurą ir atlaiko adresų pokyčius. Kur grupės nuoroda neįmanoma, aiškiai leiskite asociacijos potinklio diapazoną, o ne plėskite iki 0.0.0.0/0, nes tai maršrutizavimo klaidą paverčia nepaaiškinamu timeout.

Tada patikrinkite, ko maršrutizavimas niekada neliečia: tinklo ACL abiejuose potinkliuose, programos leidžiamų sąrašą arba token auditoriją, ir DNS. Peering nekopijuoja privačių hostinamų zonų, todėl nešiojamasis kompiuteris gali turėti veikiantį maršrutą į adresą, kurio negali išspręsti, o peering ryšys neprideda pasitikėjimo sertifikatu. Nukreipkite endpoint į resolverį, kuris atsako už B, tada patvirtinkite, kad privatus vardas ir sertifikatas sutampa.

Kai bastionas yra sąžiningas atsakymas

Laikau tris trigerius sąmoningam bastiono pasirinkimui. Peering VPC priklauso komandai, kuri nepridės grįžtamojo maršruto jūsų diapazonui arba nepriims grupės nuorodos. Prieiga turi būti patvirtinama arba registruojama kiekvienai sesijai, o programa negali to pati išlaikyti. Arba paskutinis šuolis turi likti B viduje, nes paslauga išsprendžiama tik ten ir jos TLS tapatybė prisegta prie vidinio vardo.

Niekas iš to nėra apėjimas fakto, kad peering nėra tranzityvus. Netranzityvumas riboja, ką gali daryti B ištekliai: jie negali naudoti A kaip tranzito į trečią VPC, su kuria A yra peering ryšyje. Tai niekada nereiškė, kad VPN naudotojas negali pasiekti tiesiogiai peering VPC, o bastionas, pastatytas apeiti šį neteisingą skaitymą, yra hostas, kurį reikia lopyti be priežasties.

Atvirkštinė klaida laikui bėgant kainuoja daugiau: praleiskite kiekvieną komandą per vienintelį jau egzistuojantį bastioną, tada atraskite, kad jo saugos grupė, maršrutų lentelė ir lopo langas yra produkcijos priklausomybė. Užrašykite, kurį trigerį hostas aptarnauja, ir išveskite jį iš eksploatacijos, kai trigeris išnyks.

Transit Gateway ir keli asociacijos keičia aritmetiką

Jei endpoint prijungtas tiesiogiai prie Transit Gateway, o ne prie potinklio, modelis keičiasi: klientai nebeverčiami į sąsajos adresą asociacijos potinkyje, o gateway maršrutų lentelės turi nešti kliento diapazoną plius prijungimą, kuris veda į peering VPC. Tai švariau mastelyje, bet darbas persikelia iš keturių įrašų į gateway maršrutų lenteles.

Kelios asociacijos padaugina patikras. Endpoint maršrutas priklauso endpointui, bet kiekvienas asociacijos potinklis reikalauja maršrutų lentelės su tikru peering kitu šuoliu. Sesija gali pavykti per vieną asociaciją, kol kita neturi grįžtamojo kelio, todėl išbandykite kiekvieną.

Patikros tvarka, kuri greitai randa lūžį

Vykdykite juos iš eilės; kiekvienas žingsnis gali praeiti, kol kitas žlunga, o kliento timeout beveik niekada nepasako, kuris lūžo.

1. Išspręskite programos vardą iš kliento ir patikrinkite, ar adresas yra peering diapazone.
2. Prisijunkite, tada perskaitykite endpoint ryšių žurnalą asociacijai, kuri užbaigė sesiją.
3. Tame asociacijos potinkyje patvirtinkite, kad maršrutų lentelė nukreipia peering diapazoną į aktyvų peering ryšį.
4. B išteklių potinkyje patvirtinkite grįžtamąjį įrašą sąsajos diapazonui ir atitinkančias grupės taisykles.
5. Išbandykite vieną leistiną operaciją ir vieną išteklį, kuris turi likti nepasiekiamas; antrasis pagauna derinimo likučius.
6. Prisijunkite iš naujo po bet kurio split-tunnel maršruto pakeitimo, nes veikiantis tunelis nepriims naujo maršrutų rinkinio.

Du simptomus verta atsiminti. SYN, kuris pasiekia B be atsakymo, beveik visada yra trūkstamas grįžtamasis maršrutas. Ryšys, kuris baigiasi ir tada atstatomas, paprastai yra grupė, ACL arba programa. Nė vienas neatrodo endpoint žurnale kaip priežastis, todėl laikykite keturis įrašus su savininku prie kiekvieno.

Jei nė vienas iš trijų trigerių negalioja, užbaikite maršrutizuotą kelią ir užrašykite tuos keturis įrašus. Jei vienas galioja, laikykite bastioną tik tai ribai ir palikite endpoint maršrutą paslaugoms, kurioms nereikia sesijos priešais.