Miks EC2 ei jõua teie AWS Client VPN sülearvutini
Client VPN tõlgib IPv4 kliendi allikad lõpp-punkti liidesesse. Seetõttu vastus toimib, aga uus ühendus EC2-st mitte.
AWS Client VPN-i kaudu ühendatud sülearvuti jõuab EC2 rakenduseni probleemideta. Seejärel proovite vastupidist, EC2-st kliendile määratud aadressile, ja ühendus jääb rippuma või lükatakse tagasi. See asümmeetria on harva puuduv turvagrupi reegel. VPC alamvõrkudega seotud Client VPN-i lõpp-punktis tõlgib AWS IPv4 kliendi allikad lõpp-punkti võrguliidesesse, seega puudub sissetulev VPC aadress, mis esindaks teie sülearvutit.
Alustage sellest, mida püüdmine näitab
Tehke EC2 hostis püüdmine, kui klient ühendub, ja lugege allika aadressi, mida rakendus tegelikult näeb. Kui see on VPC-poolne lõpp-punkti liides, mitte kliendikogumi aadress, on tõlkimine kinnitatud enne, kui muudate ühtki reeglit.
Kliendikogum on määramisvahemik, mitte alamvõrk tagasiteega. Just sellel eristusel lähevad enamik selliseid uurimisi valesti.
Tõlkimine, mis seletab asümmeetriat
Kolm voogu aetakse omavahel segi ja ainult üks neist on see, mida inimesed testivad.
| 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-i komponentide kirjeldus ütleb selgesõnaliselt, et IPv4 kliendi allikad tõlgitakse lõpp-punkti liidesesse, millest piisab, et näha, miks keskmisel real pole millegagi sobida.
Uus ühendus vajab marsruuti, aadressi tuvastamise sammu ja autoriseerimisotsust. Kellegi teise seansi tõlkimise olek ei anna neist ühtegi.
Miks vastus ei ole uus ühendus
TCP vastust sobitatakse olemasoleva kirjega, seepärast toimib tagasitee ilma ühegi sissetuleva reeglita. Värske SYN EC2 hostist ei leia sobivat kirjet, nii et sellest saab tavaline väljuv katse sihtkohta, kuhu VPC ei tea, kuidas jõuda.
Seepärast on eksitav kirjeldada seda liiklusena, mis liigub ainult ühes suunas. Tagasiliiklus voolab nendes seanssides pidevalt. Ilma teeta on just algatamine.
Mis ikka rikub seansi, mis peaks toimima
Turvagrupid, võrgu ACL-id ja sülearvuti enda tulemüür on kõik olulised ühenduste jaoks, mis peaksid õnnestuma. Ebaõnnestunud ping ütleb kõige vähem, sest ICMP poliitika on sageli teie huvipakkuvast TCP poliitikast eraldi.
Kirjutage need reeglid tõlgitud allika, mitte kliendi aadressi järgi. Reeglid, mis on seotud aadressiga, mida võrgus kunagi ei nähta, on selle disaini kõige levinum ise tekitatud viga.
Kui teenus peab tõesti vestlust alustama
Kui teenus peab tööjaama teavitama, pöörake suund ümber ja laske kliendil hoida püsivat väljuvat kanalit, millele teenus vastab. Kui terve kaugvõrk peab olema VPC-st kättesaadav, valige arhitektuur, mis avaldab oma prefiksid ja juurdepääsupoliitika, selle asemel et eeldada, et Client VPN teeb seda juba. Klient-kliendi juurdepääs on kolmas, kitsam juhtum oma marsruudi- ja autoriseerimisobjektidega. Miski neist ei ole lihtsalt märkeruut olemasolevas lõpp-punktis.
Hoidke ka IPv4 selgituse ulatus aus. Praegune AWS dokumentatsioon eristab IPv6, kus seda tõlkimist ei rakendata, ja muud ühendusmudelid, mis marsruudivad teisiti.
Testige kolmes märgistatud sammus: klient avab lubatud seansi, VPC teenus vastab sellele seansile ja VPC host avab kliendi suunas uue seansi. See, et kaks esimest õnnestuvad ja kolmas ebaõnnestub, on selle disaini oodatud kuju, mitte defekt, mida tulemüürireeglitega taga ajada.