LAN za jednou relací AWS Client VPN: co se předává

Notebook se připojí ke koncovému bodu AWS Client VPN, dosáhne privátní podsítě a vše vypadá zdravě. Stolní počítač ve stejné LAN nedosáhne na nic, i když hostitel Linux má také mostní rozhraní a oba stroje jsou na stejném kabelu. V tunelu není nic špatně nastaveno; chybějícím dílkem je směrování a most je falešná stopa.

Rozšíření relace Client VPN na LAN je role brány. Není to Ethernetový segment natažený do spravované služby.

Hostitel funguje a LAN ne

Tunelové rozhraní na linuxovém stroji má adresu uvnitř CIDR klienta Client VPN a koncový bod vložil trasy pro rozsahy VPC. Požadavek z tohoto stroje je lokálně generovaný provoz: vybere trasu, odejde tunelem a dostane odpověď. Tato cesta se nikdy nedotkne kódu přesměrování, rozhraní LAN ani žádného pravidla firewallu, které řídí tranzit.

Provoz z jiného zařízení v LAN je jiný tok. Dorazí na rozhraní LAN, potřebuje trasu ukazující do tunelu, potřebuje zapnuté přesměrování, potřebuje firewall, který ho povolí, a potřebuje, aby se odpověď vrátila stejným hostitelem. Čtyři požadavky a funkční test na notebooku neprokazuje ani jeden. Ze stolního počítače vypadá porucha podivně: tunel je nahoře, přihlašovací údaje platí a cíl prostě nikdy neodpoví. Závada je lokální v cestě přesměrování brány, ne ve službě.

Ne každý klient může být brána

AWS uvádí, že jeho desktopová aplikace Client VPN nepodporuje přesměrování IP a že jiní klienti mohou. Toto omezení rozhoduje architekturu dřív, než je napsán jakýkoli příkaz. Pokud je jediným dostupným klientem oficiální desktopová aplikace, linuxová brána přesměrovávající pro LAN není konfigurace, kterou lze dokončit, a žádné množství maskování to nezmění.

Náhradní klient musí také odpovídat metodě ověřování koncového bodu a politice, kterou hodláte vynucovat. Koncové body založené na certifikátech, adresáři a SAML nepřijímají stejné klientské konfigurace a klientská aplikace třetí strany, která se ověří, ale ignoruje vložené trasy, není zlepšením.

Berte volbu klienta jako součást revize návrhu. Určuje, zda je vzor přesměrování LAN vůbec dostupný, a určuje, jakou identitu koncový bod vidí pro každé zařízení za bránou. Zaznamenejte klienta a konfiguraci koncového bodu, proti níž byl testován. Výměna klienta za půl roku může tiše odstranit schopnost, kterou návrh předpokládal.

Nasměrujte LAN do tunelu a přeložte ji

S podporovaným klientem na místě je zbytek běžná práce brány. Zařízení LAN potřebují trasu pro rozsah VPC ukazující na hostitele Linux a hostitel potřebuje zapnuté přesměrování. Pokud chcete, aby VPC viděla provoz jako připojeného klienta a ne jako libovolnou adresu LAN, přeložte zdroj na cestě ven.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Omezte pravidlo na tunelové rozhraní a rozsah VPC, jak je výše, místo maskování všeho, co hostitel přesměruje. Užší pravidlo se snáz zdůvodňuje a tiše nemění provoz, který měl zachovat původní zdrojovou adresu.

Nechte trasu LAN přicházet automaticky, pokud můžete: volba DHCP, oznámení routeru nebo statická trasa vložená tím, co LAN spravuje. Trasa, která existuje jen na jednom testovacím stroji, způsobí, že návrh bude vypadat rozbitý ve chvíli, kdy to zkusí někdo jiný.

Odpověď také potřebuje cestu

Jakmile požadavek dorazí do VPC, odpověď se musí vrátit přes stejné stavy překladu a najít trasu LAN na bráně. Tato část obvykle funguje, když je pravidlo maskování na místě, protože mapování žije na hostiteli, který ho provedl. Selže, když na straně VPC existuje trasa, která odpověď pošle jinam; proto jsou důležité jak trasa CIDR klienta, tak přiřazení podsítě na koncovém bodu.

Sledujte čítače, ne jen ping. Pravidlo maskování s nulou paketů vám říká, že požadavek nikdy nedorazil na tunelové rozhraní, což ukazuje zpět na trasu LAN nebo na vlastní směrovací tabulku klienta. Pravidlo s pakety, ale bez odpovědí, ukazuje na stranu VPC, autorizační pravidla nebo bezpečnostní skupinu, která nepřijímá přeložený zdroj. Čtěte oba směry, než něco změníte, protože počet rostoucí jen na jedné straně je jednosměrná cesta, ne pomalá.

Pamatujte, že koncový bod je spravovaná služba. Neexistuje konfigurační soubor serveru k úpravě ani direktiva client-config k přidání, takže pokyny napsané pro samostatně spravovaný server OpenVPN s vlastními trasami klientských podsítí se nepřenášejí. V AWS jsou pákami přiřazení podsítě, autorizační pravidla a směrovací tabulky VPC.

Sdílená identita je část, na kterou musí politika odpovědět

Každé zařízení za bránou používá relaci VPN brány. Autorizační pravidla koncového bodu udělují přístup uživateli nebo skupině a z pohledu služby je v této relaci přesně jeden uživatel. Místní přesměrování tuto identitu nenásobí do ověřování pro jednotlivá zařízení a nerozšiřuje kontroly stavu zařízení na tiskárnu v rohu.

To může být přijatelné, nebo to může být důvod, proč je návrh odmítnut. Záleží na tom, co prostředky VPC předpokládají o tom, kdo volá. Sdílená identita, která zapadá do autorizačního modelu, je v pořádku; ta, která tiše promění jednu ověřenou relaci v přístup do celé LAN, je zjištění čekající na sepsání.

Pokud je požadavkem skutečně připojit celé pracoviště k VPC, porovnejte podporovaný návrh lokality k lokalitě, než rozšíříte klienta vzdáleného přístupu. Sémantika se liší a NATovaná klientská relace je špatnou náhradou odkazu mezi lokalitami, když VPC potřebuje zahajovat spojení do LAN.

Rozhodněte klienta, trasu, překlad a příběh identity v tomto pořadí. Každé omezuje další a pořadí vysvětluje, proč hostitel funguje, zatímco LAN ne.