Proč se EC2 nedostane na váš notebook přes AWS Client VPN
Client VPN překládá IPv4 zdroje klienta na rozhraní koncového bodu. Proto odpověď funguje a nové připojení z EC2 ne.
Notebook připojený přes AWS Client VPN bez potíží dosáhne aplikace na EC2. Pak zkusíte opak, z EC2 na adresu, která byla klientovi přidělena, a spojení se zasekne nebo je odmítnuto. Tahle asymetrie málokdy znamená chybějící pravidlo bezpečnostní skupiny. Na koncovém bodu Client VPN přidruženém k podsítím VPC AWS překládá IPv4 zdroje klienta na síťové rozhraní koncového bodu, takže neexistuje příchozí adresa VPC, která by váš notebook zastupovala.
Začněte tím, co ukáže zachytávání
Zachyťte provoz na hostiteli EC2 během připojování klienta a přečtěte si zdrojovou adresu, kterou aplikace skutečně vidí. Pokud je to rozhraní koncového bodu na straně VPC a ne adresa z fondu klientů, je překlad potvrzen dřív, než změníte jediné pravidlo.
Fond klientů je rozsah pro přidělování, ne podsíť se zpáteční trasou. Právě na tomto rozlišení se většina takových vyšetřování zvrtne.
Překlad, který vysvětluje asymetrii
Tři toky se navzájem pletou a jen jeden z nich je ten, který lidé 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 komponent Client VPN výslovně uvádí, že IPv4 zdroje klienta se překládají na rozhraní koncového bodu, což stačí k tomu, abychom viděli, proč prostřední řádek nemá co porovnat.
Nové připojení potřebuje trasu, krok překladu adresy a rozhodnutí o autorizaci. Stav překladu z cizí relace neposkytuje ani jedno z toho.
Proč odpověď není nové připojení
Odpověď TCP se porovnává s existující položkou, a proto zpáteční cesta funguje úplně bez příchozího pravidla. Čerstvý SYN z hostitele EC2 nemá s čím porovnat, takže se změní na běžný odchozí pokus na cíl, ke kterému VPC neví, jak se dostat.
Proto je také zavádějící popisovat to jako provoz, který jde jen jedním směrem. Zpětný provoz v těchto relacích teče nepřetržitě. Bez cesty je právě zahájení.
Co ještě rozbíjí relaci, která by měla fungovat
Bezpečnostní skupiny, síťové ACL a vlastní firewall notebooku mají význam pro spojení, která mají uspět. Neúspěšný ping řekne nejméně, protože politika ICMP bývá oddělená od politiky TCP, která vás zajímá.
Pište tato pravidla proti přeloženému zdroji, ne proti adrese klienta. Pravidla navázaná na adresu, která se na síti nikdy neobjeví, jsou nejčastější vlastní chybou tohoto návrhu.
Když VPC opravdu musí začít konverzaci
Pokud služba musí upozornit pracovní stanici, obraťte směr a nechte klienta držet trvalý odchozí kanál, na který služba odpovídá. Pokud musí být celá vzdálená síť dostupná z VPC, zvolte architekturu, která publikuje své prefixy a zásady přístupu, místo abyste předpokládali, že to Client VPN už dělá. Přístup klient-klient je třetí, užší případ s vlastními objekty trasy a autorizace. Nic z toho není pouhé zaškrtávací políčko u stávajícího koncového bodu.
Udržujte také rozsah vysvětlení IPv4 poctivý. Současná dokumentace AWS odděluje IPv6, kde se tento překlad neuplatňuje, a jiné modely připojení, které směrují odlišně.
Testujte ve třech označených krocích: klient otevře povolenou relaci, služba ve VPC na tuto relaci odpoví a hostitel ve VPC otevře novou relaci směrem ke klientovi. Úspěch prvních dvou při selhání třetího je očekávaný tvar tohoto návrhu, ne závada, kterou máte honit pravidly firewallu.