AWS Site-to-Site VPN do NAT gateway: VGW versus Transit Gateway

Všichni první pokus kreslí stejné schéma: VPN do VPC, NAT gateway ven do internetu, hotovo. AWS však tuto cestu nepodporuje, když VPN končí na virtual private gateway, a selhání je tak tiché, že ho týmy stavějí znovu více než jednou. Funkční návrh potřebuje transit gateway, což mění bránu i směrovací tabulky na obou stranách. Než něco nakreslíte, porovnejte oba tvary.

Topologie, která vypadá samozřejmě a není podporovaná

Dokumentace k NAT gateway od AWS kreslí čáru, která překvapí každého, kdo stavěl jen návrhy s jedním VPC: provoz z připojení Site-to-Site VPN nelze směrovat do NAT gateway přes virtual private gateway. Typ brány, na které VPN končí, rozhoduje o tom, zda vůbec existuje cesta pro překlad adres. Chyba přežívá proto, že tunel je UP a instance EC2 ve stejné podsíti se bez potíží dostane na internet. Ani jedno z těchto pozorování neověřuje rozbitý směr.

V praxi paket dorazí se zdrojovou adresou z lokální sítě a nenajde podporovaný další hop, který by ho přeložil. Podle tabulek je zahozen na výstupní hranici, a protože tunel zůstává UP, zatímco instance ve stejné podsíti se na internet dostane, hlásí se selhání jako problém lokálního firewallu.

Virtual private gateway versus transit gateway

Virtual private gateway patří jednomu VPC. Ukončí VPN, nainstaluje trasy do směrovacích tabulek tohoto VPC a tam skončí. Nemá model připojení, takže nedokáže předat provoz jinému VPC ani sdílenému výstupnímu segmentu. Celé omezení je v tomto rozsahu jednoho VPC a žádná trasa přidaná uvnitř VPC to nezmění.

Transit gateway je regionální uzel, ve kterém se VPN, každé spoke VPC a VPC sdílených služeb objevují jako připojení. Má vlastní směrovací tabulky, které vybírají, které připojení dostane daný prefix.

Právě tento uzel umožňuje centralizovaný výstup. VPN přistane jako jedno připojení, výstupní VPC jako druhé a směrovací tabulka transit gateway posílá prefixy směrem k internetu z prvního do druhého. S virtual private gateway není kam poslat, protože druhé připojení neexistuje, a proto se návrh nedá dodatečně záplatovat.

Podporovaná výstupní cesta, hop za hopem

Referenční návrh má pět hopů a každá šipka je směrovací rozhodnutí, které musíte nastavit. Provoz opouští lokální síť do připojení Site-to-Site VPN, směrovací tabulka transit gateway ho předá připojení výstupního VPC, kde ho tabulka podsítě pošle do veřejné NAT gateway. NAT gateway přeloží zdroj a internet gateway paket vynese ven.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

O tom, zda poslední hopy fungují, rozhodují dva detaily. NAT gateway musí být veřejná, s elastic IP a trasou do internet gateway, protože privátní NAT gateway překládá mezi sítěmi a nikdy se nestane výstupem do internetu.

Plánujte jednu NAT gateway pro každou Availability Zone, kterou chcete obsluhovat, a každá tabulka podsítě má ukazovat na tu místní. Tabulku transit gateway a tabulky VPC držte v poznámkách jako oddělené objekty, protože jedna vybírá připojení a druhá prostředek uvnitř VPC. Výchozí trasa jen v jedné z nich nechává polovinu cesty nedefinovanou a vytváří částečná selhání, která se nejhůř přisuzují.

Právě na zpětné cestě tyto návrhy selhávají

NAT gateway si pamatuje stav u toků, které už viděla, takže odpovědi na odchozí spojení se vracejí bez nového vstupního pravidla. Tato vlastnost nezveřejňuje lokální službu na internetu, a chovat se, jako by ano, znamená, že tým stráví den laděním spojení, které by nikdy nevzniklo. U provozu zahájeného klientem se musí shodnout čtyři trasy: lokální politika, tabulka transit gateway, tabulka výstupní podsítě a tabulka NAT podsítě. Když tu poslední vynecháte, požadavek opustí budovu, zatímco odpověď umírá uvnitř AWS.

Ověřte to skutečným klientem za VPN a podívejte se, jakou veřejnou zdrojovou adresu předkládá. Pokud je to elastic IP NAT gateway, překlad probíhá; pokud něco jiného, měříte jiný výstup.

Asymetrickou verzi této chyby je dobré rozpoznat brzy. Když má tabulka NAT podsítě jedné Availability Zone zpětnou trasu na prefix klienta a jiná ne, nová spojení uspějí nebo selžou podle zóny, do které tok dopadne, a vzorec se mylně čte jako nestabilní internet. Porovnávejte tabulky podsítí pro každou zónu, kterou obsluhujete, místo opravy té, kde byl otevřen tiket, protože chybějící trasa je celá závada a na druhé straně není co měnit.

Kdy je explicitní proxy lepší návrh

HTTP proxy na instanci ve výstupním VPC je legitimní alternativa a často levnější. Klienti jsou nastaveni, aby ho používali, proxy otevírá vlastní spojení ven a zpětná cesta je jeho problém, ne hlavolam symetrického směrování. U malého počtu aplikací to odstraní většinu práce s transit gateway. Dává také logy po uživatelích, které NAT gateway neumí.

Není ale transparentní. Vše, co ignoruje nastavení proxy, a každý protokol, který není HTTP, touto cestou nepůjde.

Volba závisí na tom, čím vaše aplikace skutečně mluví a kolik identity v logech potřebujete. Kde mluví HTTP, proxy si místo zaslouží; kde potřebujete obecný výstup pro libovolné protokoly, je návrh s transit gateway ten, který AWS podporuje. Rozhodnout to předem je levnější než to zjistit po postavení směrovacích tabulek.