Prečo sa EC2 nedostane na váš notebook cez AWS Client VPN
Client VPN prekladá IPv4 zdroje klienta na sieťové rozhranie koncového bodu. Preto odpoveď funguje a nové pripojenie z EC2 nie.
Notebook pripojený cez AWS Client VPN bez problémov dosiahne aplikáciu na EC2. Potom skúsite opak, z EC2 na adresu, ktorá bola klientovi pridelená, a spojenie sa zasekne alebo je odmietnuté. Táto asymetria málokedy znamená chýbajúce pravidlo bezpečnostnej skupiny. Na koncovom bode Client VPN priradenom k podsieťam VPC AWS prekladá IPv4 zdroje klienta na sieťové rozhranie koncového bodu, takže neexistuje prichádzajúca adresa VPC, ktorá by váš notebook zastupovala.
Začnite tým, čo ukáže zachytávanie
Zachyťte premávku na hostiteľovi EC2 počas pripájania klienta a prečítajte si zdrojovú adresu, ktorú aplikácia skutočne vidí. Ak je to rozhranie koncového bodu na strane VPC a nie adresa z fondu klientov, preklad je potvrdený skôr, než zmeníte jediné pravidlo.
Fond klientov je rozsah na prideľovanie, nie podsieť so spätnou trasou. Práve na tomto rozlíšení sa väčšina takýchto vyšetrovaní zvrtne.
Preklad, ktorý vysvetľuje asymetriu
Tri toky sa navzájom pletú a iba jeden z nich je ten, ktorý ľudia testujú.
| 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 |
Popis komponentov Client VPN výslovne uvádza, že IPv4 zdroje klienta sa prekladajú na rozhranie koncového bodu, čo stačí na to, aby sme videli, prečo prostredný riadok nemá čo porovnať.
Nové pripojenie potrebuje trasu, krok prekladu adresy a rozhodnutie o autorizácii. Stav prekladu z cudzej relácie neposkytuje ani jedno z toho.
Prečo odpoveď nie je nové pripojenie
Odpoveď TCP sa porovnáva s existujúcim záznamom, a preto spätná cesta funguje úplne bez prichádzajúceho pravidla. Čerstvý SYN z hostiteľa EC2 nemá s čím porovnať, takže sa zmení na bežný odchádzajúci pokus na cieľ, ku ktorému VPC nevie, ako sa dostať.
Preto je tiež zavádzajúce opisovať to ako premávku, ktorá ide len jedným smerom. Spätná premávka v týchto reláciách tečie nepretržite. Bez cesty je práve začatie.
Čo ešte pokazí reláciu, ktorá by mala fungovať
Bezpečnostné skupiny, sieťové ACL a vlastný firewall notebooku majú význam pre spojenia, ktoré by mali uspieť. Neúspešný ping povie najmenej, pretože politika ICMP je často oddelená od politiky TCP, ktorá vás zaujíma.
Píšte tieto pravidlá voči preloženému zdroju, nie voči adrese klienta. Pravidlá naviazané na adresu, ktorá sa v sieti nikdy neobjaví, sú najčastejšou vlastnou chybou tohto návrhu.
Keď VPC naozaj musí začať konverzáciu
Ak musí služba upozorniť pracovnú stanicu, otočte smer a nechajte klienta držať trvalý odchádzajúci kanál, na ktorý služba odpovedá. Ak musí byť celá vzdialená sieť dostupná z VPC, zvoľte architektúru, ktorá zverejňuje svoje prefixy a politiku prístupu, namiesto toho, aby ste predpokladali, že Client VPN to už robí. Prístup klient-klient je tretí, užší prípad s vlastnými objektmi trasy a autorizácie. Nič z toho nie je len zaškrtávacie políčko na existujúcom koncovom bode.
Udržiavajte čestný aj rozsah vysvetlenia IPv4. Súčasná dokumentácia AWS oddeľuje IPv6, kde sa tento preklad neuplatňuje, a iné modely pripojenia, ktoré smerujú odlišne.
Testujte v troch označených krokoch: klient otvorí povolenú reláciu, služba vo VPC odpovie na túto reláciu a hostiteľ vo VPC otvorí novú reláciu smerom ku klientovi. To, že prvé dva uspejú a tretí zlyhá, je očakávaný tvar tohto návrhu, nie porucha, ktorú treba naháňať pravidlami firewallu.