Přidání místní podsítě k AWS VPN: VGW versus Transit Gateway

Stávající Site-to-Site VPN přenáší 10.60.0.0/16, za stejnou místní branou se objevuje nová servisní síť jako 10.70.0.0/16 a někdo se ptá, zda je potřeba proxy. Obvykle není: směrovaná cesta může prefix přenést, ale jen když se sejdou tři věci, a které tři to je, závisí na architektuře AWS, kterou už provozujete. Virtuální privátní brána má jednu hranici směrovací tabulky; transit gateway přidává druhou. Správné ohlášení a špatná tabulka vytvoří relaci, která vypadá zdravě a nic nedoručí.

Zveřejněte prefix, který brána skutečně dokáže doručit

Místní brána potřebuje cestu k nové síti dřív, než má jakékoli ohlášení smysl. Ohlášení 10.70.0.0/16 přes BGP říká AWS, kam posílat pakety pro tento rozsah; nevytváří však místní předávací cestu, která rozsah zpřístupní na druhém konci. Ověřte, že brána má pro prefix cestu ukazující na zařízení, které ho drží, a že zařízení je nakonfigurováno odpovídat za tyto adresy. Exportní politika a přijímané limity prefixů jsou dalším omezením, protože prefix, který relace vyfiltruje, se do AWS vůbec nedostane.

Agregáty a konkrétnější cesty držte záměrné. Překrývající se cesty přicházející ze dvou směrů jsou rozhodnutí o návrhu, ne detail, který se objeví později.

Cesta první: hranice virtuální privátní brány

U virtuální privátní brány popisuje dokumentace směrování AWS VPN dva režimy distribuce, statické cesty a ohlášení BGP, a oba závisí na směrovací tabulce podsítě, kterou aplikace skutečně používá. Propagace je pohodlná, když ovládáte celý rozsah, a explicitní cesta se snáz promýšlí, když chcete mít cíl uvedený vedle cílového uzlu. V obou případech je kontrola stejná: obsahuje tabulka konkrétní aplikační podsítě funkční cestu k cíli VPN pro nový prefix a vyhrává proti něčemu konkrétnějšímu?

Zdravá relace BGP dokazuje, že kanál existuje. Neříká nic o tom, zda daná tabulka podsítě cestu převzala.

Cesta druhá: transit gateway přidává tabulku

Transit gateway rozděluje jednu otázku na dvě. Podsíť VPC musí poslat cíl na připojení transit gateway a potom musí směrovací tabulka transit gateway vybrat připojení VPN pro stejný prefix. Volby přidružení a propagace určují, které připojené sítě cestu dostanou, takže prefix může být VPN ohlášen správně a přesto se nikdy nedostane do VPC, jejíž tabulka nebyla nikdy přidružena ke správné směrovací tabulce.

Běžná závada je cesta, která existuje v jedné tabulce a ve druhé ne, přičemž každý tým je přesvědčen, že jeho strana je správná. Když obě architektury porovnáte, tato další hranice je celý rozdíl: více míst k prohlédnutí a přesnější kontrola nad tím, kdo cestu dostane.

Ani propagace cest nedává prefix každému připojení. Rozděluje ho do tabulek nakonfigurovaných k jeho příjmu.

Zpětná cesta je samostatné politické rozhodnutí

Příchozí provoz je jen polovina výměny. Nová místní síť potřebuje cestu zpět ke zdrojovým prefixům AWS přes správnou bránu a bezpečnostní politika na obou koncích musí tento pár zdroje a cíle povolit. Pokud tunel vyjednává rozsah ochrany se selektory provozu, nový prefix v něm musí být, jinak je paket zahozen dřív, než se podíváme do jakékoli směrovací tabulky.

Překryv adres je druhá past. Nepřekrývající se, výslovně vlastněné rozsahy to udržují jednoduché; překrývající se rozsahy znamenají překlad nebo přepracování a ani jedno není zaměnitelná varianta stejného receptu.

Testujte se zdrojem v nové síti a cílem v aplikační podsíti, pak to zopakujte opačným směrem. Jednosměrný test dokazuje jediný směr.

Když je proxy skutečně lepší hranicí

Proxy si své místo zaslouží, když je požadavkem úzké servisní rozhraní, když aplikace tuto architekturu už očekává, nebo když síťovou cestu nelze přimět prefix nést bez překladu, který nechcete. Není to náhradní řešení pro záznam ve směrovací tabulce, který nikdo nezkontroloval.

Rozhodujte v tomto pořadí: místní předávání, ohlášení, hranice tabulky, politika zpětné cesty. Opravte první, které selže, a teprve potom se ptejte, zda je směrovaná cesta vůbec správná odpověď.