Zakaj EC2 ne doseže vašega prenosnika prek AWS Client VPN
Client VPN pretvori vire IPv4 odjemalca v omrežni vmesnik končne točke. Zato odgovor deluje, nova povezava z EC2 pa ne.
Prenosnik, povezan prek AWS Client VPN, brez težav doseže aplikacijo na EC2. Nato poskusite obratno, z EC2 na naslov, ki je bil dodeljen odjemalcu, in povezava se obesi ali zavrne. Ta asimetrija je redko manjkajoče pravilo varnostne skupine. Na končni točki Client VPN, povezani s podomrežji VPC, AWS pretvori vire IPv4 odjemalca v omrežni vmesnik končne točke, zato ni dohodnega naslova VPC, ki bi predstavljal vaš prenosnik.
Začnite s tem, kar pokaže zajem
Naredite zajem na gostitelju EC2, medtem ko se odjemalec povezuje, in preberite izvorni naslov, ki ga aplikacija dejansko vidi. Če je to vmesnik končne točke na strani VPC in ne naslov iz bazena odjemalcev, je pretvorba potrjena še preden spremenite eno samo pravilo.
Bazen odjemalcev je obseg dodeljevanja, ne podomrežje s povratno potjo. Prav na tej razliki se večina takih preiskav zmoti.
Pretvorba, ki pojasni asimetrijo
Trije tokovi se med seboj zamenjujejo in le eden od njih je tisti, ki ga ljudje preizkušajo.
| 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 |
Opis komponent Client VPN jasno navaja, da se viri IPv4 odjemalca pretvorijo v vmesnik končne točke, kar zadošča, da vidite, zakaj srednja vrstica nima s čim ujemati.
Nova povezava potrebuje pot, korak razreševanja naslova in odločitev o avtorizaciji. Stanje pretvorbe iz seje nekoga drugega ne ponuja nobene od treh.
Zakaj odgovor ni nova povezava
Odgovor TCP se ujema z obstoječim vnosom, zato povratna pot deluje brez vsakršnega dohodnega pravila. Svež SYN z gostitelja EC2 nima vnosa za ujemanje, zato postane običajen izhodni poskus proti cilju, do katerega VPC ne ve, kako priti.
Zato je tudi zavajajoče to opisovati kot promet, ki gre samo v eno smer. Povratni promet v teh sejah nenehno teče. Brez poti je prav začetek.
Kaj še vedno pokvari sejo, ki bi morala delovati
Varnostne skupine, omrežni ACL in požarni zid prenosnika samega so pomembni za povezave, ki bi morale uspeti. Neuspešen ping pove najmanj, ker je politika ICMP pogosto ločena od politike TCP, ki vas zanima.
Ta pravila pišite glede na pretvorjeni vir, ne glede na naslov odjemalca. Pravila, vezana na naslov, ki se v omrežju nikoli ne pojavi, so najpogostejša samo povzročena napaka v tej zasnovi.
Ko mora VPC res začeti pogovor
Če mora storitev obvestiti delovno postajo, obrnite smer in pustite odjemalcu, da vzdržuje trajen izhodni kanal, na katerega storitev odgovarja. Če mora biti celotno oddaljeno omrežje dosegljivo iz VPC, izberite arhitekturo, ki objavi svoje predpone in politiko dostopa, namesto da bi predpostavljali, da Client VPN to že počne. Dostop odjemalec-odjemalec je tretji, ožji primer z lastnimi objekti poti in avtorizacije. Nič od tega ni le potrditveno polje na obstoječi končni točki.
Ohranite pošten tudi obseg razlage IPv4. Sedanja dokumentacija AWS ločuje IPv6, kjer se ta pretvorba ne uporablja, in druge modele povezovanja, ki usmerjajo drugače.
Preizkusite v treh označenih korakih: odjemalec odpre dovoljeno sejo, storitev v VPC odgovori na to sejo in gostitelj v VPC odpre novo sejo proti odjemalcu. To, da prva dva uspeta, tretji pa ne, je pričakovana oblika te zasnove, ne napaka, ki bi jo bilo treba loviti s pravili požarnega zidu.