Dvě VPC potřebují v tomto čtvrtletí kancelářskou síť a právě na druhém tunelu se odhad láme. AWS Transit Gateway může fungovat jako sdílené směrovací centrum: VPN se připojí jednou a každá VPC se připojí ke stejnému centru. On-premises síť pak dosáhne na každou připojenou VPC přes jedno spojení. Tím se mění, kdo vlastní rozhodnutí o směrování, a to je část, kterou většina návrhů pokazí.

Připojení VPN a připojení VPC jsou samostatné objekty na stejné bráně, a proto se směrovací vztahy musí vytvořit až potom.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Proč peering není zkratka, v kterou lidé doufají

Lákavou alternativou je ukončit VPN na VPC A a propojit VPC B s ní peeringem. Běžný VPC peering neposkytuje tranzit od okraje k okraji přes VPN spojení VPC A. Peer dosáhne na adresy, které poskytuje samotný peering, a VPN okraj mezi ně nepatří. Tranzit dává centrum; peering vám dá pár.

Toto omezení je vlastnost peeringu, ne kvóta, kterou lze zvýšit.

Asociace a propagace dělají různou práci

Uvnitř transit gateway asociace vybírá směrovací tabulku, podle které se vyhledává provoz přicházející z připojení. Propagace rozhoduje, které tabulky dostanou naučené nebo připojené prefixy daného připojení. Jedno připojení může být asociováno s jednou tabulkou a zároveň propagovat do několika. Záměna obojího je způsob, jak návrh skončí s dosažitelností, kterou nikdo neplánoval.

Plně propojené malé centrum je snadný případ.

Dejte každé připojení do jedné tabulky a VPN spolu s oběma prefixy VPC se čistě vyřeší. To také umožní dosažitelnost mezi VPC, kterou organizace možná nikdy nezamýšlela, protože sdílená tabulka nezná pojem spoke.

Trasy úloh žijí jinde

Každá podsíť úlohy stále potřebuje vlastní trasu k transit gateway pro zamýšlené místní prefixy. Tyto směrovací tabulky VPC jsou samostatné objekty od vlastních tabulek transit gateway. Přidejte potřebné prefixy a zachovejte existující trasy místo nahrazení každého cíle novým defaultem. Trasa podsítě také nic neoznamuje zařízení zákazníka.

Vyberte dynamické nebo statické směrování vědomě; peering nedává ani jedno.

Izolujte spokes bez ztráty místního přístupu

Když A i B mohou dosáhnout do kanceláře, ale nesmějí směrovat navzájem, rozdělte tabulky. Asociovaná tabulka připojení VPN drží prefixy VPC. Asociovaná tabulka připojení VPC drží místní prefixy, bez trasy spojující A s B. Tento vztah vytváří propagace, takže nikdy nemusíte přijmout každou výchozí asociaci.

Toto je izolace směrování, nikoli autorizace aplikace.

Bezpečnostní skupiny, síťové ACL, hostitelské firewally a vlastní oprávnění každé služby stále rozhodují, jaký provoz se připustí. Pokud je potřeba inspekce, navrhněte její podporovanou cestu explicitně, místo abyste předpokládali, že ji centrum provede.

Co centrum neopraví

Plány adres se stále nesmějí překrývat, protože centrum nedovolí, aby jeden prefix označoval dvě úlohy. Každé připojení VPC potřebuje pokrytí Availability Zone, které jeho úlohy očekávají. S BGP musí trasy zařízení zákazníka zpět ke každému potřebnému prefixu odpovídat návrhu a jeho politice importu. Chybějící oznámení vypadá přesně jako rozbitý tunel.

VPN spojení a transit gateway jsou nyní sdílená infrastruktura.

Plánujte redundanci tunelů, kapacitu zařízení, monitorování a údržbu kolem všech závislých VPC, místo abyste s každou zacházeli jako se samostatně připojenou.

Migrace ze stávajícího uspořádání s virtual private gateway si zaslouží stejný explicitní plán. Postavte připojení a politiky, přesuňte jednu řízenou cestu úlohy a před vyřazením staré cesty potvrďte povolené i zakázané vztahy. Centralizace pomáhá, když dá síťovému týmu jedno místo pro správu sdílené konektivity, a škodí, když schová, kdo se k komu smí dostat, za jednu velkou tabulku.

Související články