Kodėl EC2 nepasiekia jūsų AWS Client VPN nešiojamojo kompiuterio
Client VPN verčia IPv4 kliento šaltinius į galinio taško tinklo sąsają. Todėl atsakymas veikia, o naujas ryšys iš EC2 – ne.
Nešiojamasis kompiuteris, prijungtas per AWS Client VPN, be problemų pasiekia EC2 programą. Tada bandote atvirkščiai, iš EC2 į klientui priskirtą adresą, ir ryšys užstringa arba atmetamas. Ši asimetrija retai būna trūkstama saugos grupės taisyklė. Client VPN galiniame taške, susietame su VPC potinkliais, AWS verčia IPv4 kliento šaltinius į galinio taško tinklo sąsają, todėl nėra jokio įeinamojo VPC adreso, atstovaujančio jūsų nešiojamajam kompiuteriui.
Pradėkite nuo to, ką rodo įrašas
Padarykite įrašą EC2 hoste, kol klientas jungiasi, ir perskaitykite šaltinio adresą, kurį programa iš tikrųjų mato. Jei tai VPC pusės galinio taško sąsaja, o ne adresas iš klientų telkinio, vertimas patvirtintas dar prieš pakeičiant nė vieną taisyklę.
Klientų telkinys yra priskyrimo diapazonas, o ne potinklis su grįžtamuoju maršrutu. Būtent šiame skirtume dauguma tokių tyrimų ir suklysta.
Vertimas, paaiškinantis asimetriją
Trys srautai painiojami tarpusavyje, ir tik vienas jų yra tas, kurį žmonės testuoja.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN komponentų aprašymas aiškiai nurodo, kad IPv4 kliento šaltiniai verčiami į galinio taško sąsają, ir to pakanka pamatyti, kodėl vidurinė eilutė neturi su kuo sutapti.
Naujam ryšiui reikia maršruto, adreso sprendimo žingsnio ir autorizacijos sprendimo. Vertimo būsena iš kito asmens sesijos nesuteikia nė vieno iš trijų.
Kodėl atsakymas nėra naujas ryšys
TCP atsakymas lyginamas su esamu įrašu, todėl grįžimo kelias veikia visiškai be jokios įeinamosios taisyklės. Naujas SYN iš EC2 hosto neturi įrašo, su kuriuo galėtų sutapti, todėl tampa įprastu išeinančiu bandymu į paskirties vietą, į kurią VPC nemoka patekti.
Štai kodėl apibūdinti tai kaip srautą, einantį tik viena kryptimi, klaidinga. Grįžtamasis srautas šiose sesijose teka nuolat. Be kelio lieka būtent inicijavimas.
Kas vis dar sugadina sesiją, kuri turėtų veikti
Saugos grupės, tinklo ACL ir paties nešiojamojo kompiuterio ugniasienė visi svarbūs ryšiams, kurie turėtų pavykti. Nepavykęs ping pasako mažiausiai, nes ICMP politika dažnai atskirta nuo jus dominančios TCP politikos.
Rašykite šias taisykles pagal išverstą šaltinį, o ne pagal kliento adresą. Taisyklės, susietos su adresu, kuris niekada nepasirodo tinkle, yra dažniausia savo paties sukurta šio dizaino klaida.
Kai VPC tikrai turi pradėti pokalbį
Jei paslauga turi pranešti darbo stočiai, apverskite kryptį ir leiskite klientui palaikyti nuolatinį išeinantį kanalą, į kurį paslauga atsako. Jei visas nuotolinis tinklas turi būti pasiekiamas iš VPC, rinkitės architektūrą, kuri skelbia savo prefiksus ir prieigos politiką, o ne manykite, kad Client VPN tai jau daro. Kliento prieiga prie kliento yra trečias, siauresnis atvejis su savo maršruto ir autorizacijos objektais. Nė vienas iš jų nėra tik žymimasis langelis esamame galiniame taške.
Laikykite sąžiningą ir IPv4 paaiškinimo apimtį. Dabartinė AWS dokumentacija atskiria IPv6, kur šis vertimas netaikomas, ir kitus prijungimo modelius, kurie maršrutizuoja kitaip.
Išbandykite trimis pažymėtais žingsniais: klientas atidaro leidžiamą sesiją, VPC paslauga atsako į tą sesiją, o VPC hostas atidaro naują sesiją kliento link. Tai, kad pirmieji du pavyksta, o trečiasis nepavyksta, yra laukiama šio dizaino forma, o ne defektas, kurį reikia vytis ugniasienės taisyklėmis.