AWS Site-to-Site VPN do NAT Gateway: VGW verzus Transit Gateway

Všetci pri prvom pokuse kreslia rovnakú schému: VPN do VPC, NAT gateway von do internetu, hotovo. AWS však túto cestu nepodporuje, keď sa VPN končí na virtual private gateway, a zlyhanie je také tiché, že ho tímy stavajú znova viac ako raz. Funkčný návrh potrebuje transit gateway, čo mení bránu aj smerovacie tabuľky na oboch stranách. Pred kreslením porovnajte oba tvary.

Topológia, ktorá vyzerá samozrejme a nie je podporovaná

Dokumentácia k NAT gateway od AWS kreslí čiaru, ktorá prekvapí každého, kto staval len návrhy s jedným VPC: prevádzku z pripojenia Site-to-Site VPN nemožno smerovať do NAT gateway cez virtual private gateway. Typ brány, na ktorej sa VPN končí, rozhoduje o tom, či vôbec existuje cesta pre preklad adries. Chyba prežíva preto, lebo tunel je UP a inštancia EC2 v tej istej podsieti sa bez problémov dostane na internet. Ani jedno z týchto pozorovaní neoveruje pokazený smer.

V praxi paket príde so zdrojovou adresou z lokálnej siete a nenájde podporovaný ďalší hop, ktorý by ho preložil. Podľa tabuliek je zahodený na výstupnej hranici, a keďže tunel zostáva UP, zatiaľ čo inštancia v tej istej podsieti sa na internet dostane, hlási sa zlyhanie ako problém lokálneho firewallu.

Virtual private gateway verzus transit gateway

Virtual private gateway patrí jednému VPC. Ukončí VPN, nainštaluje trasy do smerovacích tabuliek tohto VPC a tam skončí. Nemá model pripojenia, takže nedokáže odovzdať prevádzku inému VPC ani spoločnému výstupnému segmentu. Celé obmedzenie je v tomto rozsahu jedného VPC a žiadna trasa pridaná vnútri VPC to nezmení.

Transit gateway je regionálny uzol, v ktorom sa VPN, každé spoke VPC a VPC spoločných služieb objavujú ako pripojenia. Má vlastné smerovacie tabuľky, ktoré vyberajú, ktoré pripojenie dostane daný prefix.

Práve tento uzol umožňuje centralizovaný výstup: VPN pristane ako jedno pripojenie, výstupné VPC ako druhé a smerovacia tabuľka transit gateway posiela prefixy smerom na internet z prvého do druhého. S virtual private gateway niet kam poslať, lebo druhé pripojenie neexistuje, a preto sa návrh nedá dodatočne záplatať.

Podporovaná výstupná cesta, hop za hopom

Referenčný návrh má päť hopov a každá šípka je smerovacie rozhodnutie, ktoré musíte nastaviť. Prevádzka opúšťa lokálnu sieť do pripojenia Site-to-Site VPN, smerovacia tabuľka transit gateway ju odovzdá pripojeniu výstupného VPC, kde ju tabuľka podsiete pošle do verejnej NAT gateway. NAT gateway preloží zdroj a internet gateway paket vynesie von.

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, či posledné hopy fungujú, rozhodujú dva detaily. NAT gateway musí byť verejná, s elastic IP a trasou do internet gateway, pretože privátna NAT gateway prekladá medzi sieťami a nikdy sa nestane výstupom do internetu.

Plánujte jednu NAT gateway pre každú Availability Zone, ktorú chcete obsluhovať, a každá tabuľka podsiete má ukazovať na tú miestnu. Tabuľku transit gateway a tabuľky VPC držte v poznámkach ako oddelené objekty, pretože jedna vyberá pripojenie a druhá prostriedok vnútri VPC. Predvolená trasa len v jednej z nich necháva polovicu cesty nedefinovanú a vytvára čiastočné zlyhania, ktoré sa najťažšie prisudzujú.

Práve na spätnej ceste tieto návrhy zlyhávajú

NAT gateway si pamätá stav pri tokoch, ktoré už videla, takže odpovede na odchádzajúce spojenie sa vracajú bez nového vstupného pravidla. Táto vlastnosť nezverejňuje lokálnu službu na internete, a správať sa, akoby áno, znamená, že tím strávi deň ladením spojenia, ktoré by nikdy nevzniklo. Pri prevádzke začatej klientom sa musia zhodnúť štyri trasy: lokálna politika, tabuľka transit gateway, tabuľka výstupnej podsiete a tabuľka NAT podsiete. Ak vynecháte poslednú, požiadavka opustí budovu, zatiaľ čo odpoveď umiera vnútri AWS.

Overte to skutočným klientom za VPN a pozrite sa, akú verejnú zdrojovú adresu predkladá. Ak je to elastic IP NAT gateway, preklad prebieha; ak niečo iné, meriate iný výstup.

Asymetrickú verziu tejto chyby je dobré rozpoznať zavčasu. Keď má tabuľka NAT podsiete jednej Availability Zone spätnú trasu na prefix klienta a iná nie, nové spojenia uspejú alebo zlyhajú podľa zóny, do ktorej tok dopadne, a vzorec sa mylne číta ako nestabilný internet. Porovnávajte tabuľky podsietí pre každú obsluhovanú zónu namiesto opravy tej, kde bol otvorený tiket, pretože chýbajúca trasa je celá závada a na druhej strane netreba nič meniť.

Kedy je explicitný proxy lepší návrh

HTTP proxy na inštancii vo výstupnom VPC je legitímna alternatíva a často lacnejšia. Klienti sú nastavení, aby ho používali, proxy otvára vlastné spojenie von a spätná cesta sa stáva jeho problémom, nie hlavolamom symetrického smerovania. Pri malom počte aplikácií to odstráni väčšinu práce s transit gateway. Dáva aj logy po používateľoch, ktoré NAT gateway nevie vytvoriť.

Nie je však transparentný. Všetko, čo ignoruje nastavenia proxy, a každý protokol, ktorý nie je HTTP, touto cestou nepôjdu.

Voľba závisí od toho, čím vaše aplikácie skutočne hovoria a koľko identity potrebujete v logoch. Kde hovoria HTTP, proxy si miesto zaslúži; kde potrebujete všeobecný výstup pre ľubovoľné protokoly, je návrh s transit gateway ten, ktorý AWS podporuje. Rozhodnúť to vopred je lacnejšie než to zistiť po postavení smerovacích tabuliek.