AWS Client VPN je připojený, ale EC2 stále neodpovídá

Můj notebook hlásil připojeno. Klient AWS Client VPN ukazoval zelený stav, endpoint zapsal relaci, a přesto jsem nedokázal otevřít port MongoDB na instanci EC2 v privátní podsíti. Nic nebylo zjevně rozbité: certifikát byl platný, profil přišel z konzole a tunel přenášel provoz. Chyba byla moje, protože jsem připojeno četl jako autorizováno.

Přihlášení odpovídá přesně na jednu otázku: smí tato identita navázat relaci? Všechno po tom rozhodují samostatná pravidla, která váš certifikát nikdy nevidí. Relace, která se autentizuje, a paket, který dorazí, jsou dva různé úspěchy a mezera mezi nimi je místo, kde žije většina stížností typu VPN běží, ale hostitel je nedostupný.

Kontroly níže jsou pořadí, které teď používám.

Co připojená relace skutečně dokazuje

Během handshake endpoint ověřuje klientský certifikát vůči svému trust store, nebo přesměruje prohlížeč na vašeho poskytovatele identity, je-li nakonfigurován SAML. Pokud to projde, klient dostane adresu z klientského CIDR endpointu a konzole ukáže aktivní spojení. V žádném okamžiku té výměny se nic neptá, zda se dostanete na 10.0.4.17 na portu 27017.

Oprávnění k cíli je samostatný objekt na endpointu. Každý tok se porovnává s autorizačními pravidly a každé pravidlo spojuje CIDR cíle se skupinou, které je pravidlo uděleno. Když cíl nepokrývá žádné pravidlo, endpoint relaci přijme a provoz zahodí. Není tu žádný banner, žádná smyčka opětovného připojení ani nic v klientském rozhraní, co by řeklo zamítnuto.

Porovnejte autorizační pravidlo se zdrojem, ne s VPC

Vypište pravidla a položte je vedle adresy, kterou instance skutečně má:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Výstup ukazuje CIDR cíle a ID skupiny pro každé pravidlo. Skrývají se v něm dvě selhání. Pravidlo může autorizovat 10.0.0.0/16, zatímco instance sedí v propojené VPC na 10.1.0.0/16; peeringová trasa existuje, ale nikdo nenapsal autorizační pravidlo pro druhý rozsah. Nebo pravidlo míří na skupinu v adresáři, do které uživatel patří v adresáři, ale ne ve skupině, kterou endpoint vyhodnocuje.

Napište nejužší pravidlo, které cíl pokrývá, a druhé přidejte jen tehdy, když je druhý CIDR skutečně potřeba. Široké pravidlo 0.0.0.0/0 z rychlého startu funguje, a proto přežívá do produkce a skrývá model.

O tom, zda se paket pohne, rozhodují dvě směrovací tabulky

Trasa endpointu mapuje CIDR cíle na jednu z podsítí, se kterými je endpoint spojen. To je polovina cesty. Vlastní směrovací tabulka podsítě stále musí vědět, jak paket předat dál, a to je důležité ve chvíli, kdy je cíl za peeringovým spojením, transit gateway nebo lokálním rozsahem dostupným přes tunel site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Hledejte trasu, jejíž cíl odpovídá CIDR zdroje a jejímž cílem je přidružená podsíť. Pokud trasa chybí, přidejte ji. Pokud existuje a hostitel stále mlčí, mezera je na straně VPC, takže ji porovnejte se směrovací tabulkou přidružené podsítě.

Jedno klientské nastavení rozbíjí směrování, aniž by rozbilo tunel: profil obsahující route-nopull. Direktiva říká klientovi založenému na OpenVPN, aby ignoroval trasy, které server tlačí, takže rozhraní naskočí jen s vlastní adresou endpointu a cíl prostě nemá trasu. Ověřte pomocí ip route show na Linuxu nebo netstat -rn na macOS, zda existuje trasa přes rozhraní tun. Pokud ne, odstraňte route-nopull z exportovaného profilu a připojte se znovu, aby se tlačené trasy použily.

Bezpečnostní skupiny nevidí adresu vašeho klienta

To je část, ve které jsem se půl odpoledne mýlil. U IPv4 endpointu spojeného s podsítí služba překládá zdrojovou adresu klienta na adresu síťového rozhraní endpointu v této podsíti. Paket, který dorazí k instanci, nenese adresu, kterou váš klient zobrazoval, takže pravidlo bezpečnostní skupiny povolující klientský pool, řekněme 172.16.0.0/22, neodpovídá ničemu.

Povolte port z bezpečnostní skupiny endpointu, která je připojena k rozhraní asociace, ne z klientského CIDR. Odkaz na skupinu je trvanlivější než natvrdo zapsaná adresa, protože adresu rozhraní neovládáte vy. Síťové ACL jsou bezstavové, takže tam, kde existují vlastní záznamy, musí tok povolit jak směr dovnitř, tak směr ven.

Připojujte se také na privátní adresu instance. Veřejná IP vynáší paket z VPC a vrací ho dovnitř jinou cestou s jinými pravidly, takže veřejný test neříká o privátní cestě nic.

Izolační pořadí, které se zastaví u prvního selhání

Projděte je v pořadí a zastavte se tam, kde jedno selže. Každý krok vylučuje jednu vrstvu, ne všechny.

1. Ověřte, kterou identitu relace použila a kterou skupinu endpoint vyhodnocuje. Certifikát z jednoho trust store není stejný subjekt jako SAML tvrzení z adresáře.
2. Ověřte, že autorizační pravidlo pokrývá CIDR zdroje pro tuto skupinu.
3. Ověřte, že existuje trasa endpointu a míří na přidruženou podsíť, a pak že směrovací tabulka podsítě umí předat dál.
4. Ověřte, že bezpečnostní skupina povoluje port z rozhraní endpointu, ne z klientského poolu.
5. Testujte zevnitř VPC, pomocí relace SSM na jiné instanci ve stejné podsíti, abyste oddělili problém aplikace od problému klientské cesty.

Když kroky nerozhodnou, vracím se k této tabulce:

Dva údaje o účtu vytvářejí příznaky, které vypadají jako selhání oprávnění. Každý uživatel potřebuje samostatný klientský certifikát; sdílení jednoho mezi dvěma stroji způsobí, že se relace navzájem vytlačují, a výsledkem je smyčka opětovného připojení, ne zamítnutí. Když se vytvoří nový endpoint, konzole zobrazí jméno DNS, které některé verze klienta přijímají jen s náhodným prefixem uvedeným na stránce endpointu, takže zkopírujte celé jméno, místo abyste ho rekonstruovali.

Pokud vás pátý krok zasekne, stáhněte si protokol připojení endpointu a přečtěte záznamy autorizace, než cokoli změníte. Protokol uvádí ověřovaný cíl a pravidlo, které odpovídalo nebo neodpovídalo, což zmenší otázku se čtyřmi vrstvami na jednu odpověď.