Jedna VPN typu lokalita-lokalita pre viacero VPC v AWS Transit Gateway
Pripojte VPN raz a každé VPC k jednej tranzitnej bráne, potom oddeľte asociáciu od propagácie, aby spokes dosiahli kanceláriu, ale nie navzájom.
Dve VPC potrebujú v tomto kvartáli kancelársku sieť a práve na druhom tuneli sa odhad láme. AWS Transit Gateway môže fungovať ako spoločné smerovacie centrum: VPN sa pripojí raz a každé VPC sa pripojí k tomu istému centru. Lokálna sieť potom dosiahne každé pripojené VPC cez jedno spojenie. To mení, kto vlastní rozhodnutie o smerovaní, a to je časť, ktorú väčšina návrhov pokazí.
Pripojenie VPN a pripojenia VPC sú samostatné objekty na tej istej bráne, preto sa smerovacie vzťahy musia vytvoriť až potom.
On-premises network <-> Site-to-Site VPN <-> Transit Gateway
|- VPC A
|- VPC B
Prečo peering nie je skratka, na ktorú ľudia dúfajú
Lákavou alternatívou je ukončiť VPN na VPC A a prepojiť VPC B s ním peeringom. Bežný VPC peering neposkytuje tranzit od okraja po okraj cez VPN spojenie A. Peer dosiahne len adresy, ktoré poskytuje samotný peering, a VPN okraj medzi ne nepatrí. Tranzit dáva centrum; peering dáva pár.
Toto obmedzenie je vlastnosť peeringu, nie kvóta, ktorú možno zvýšiť.
Asociácia a propagácia robia rôznu prácu
Vnútri tranzitnej brány asociácia vyberá smerovaciu tabuľku, podľa ktorej sa vyhľadáva prevádzka prichádzajúca z pripojenia. Propagácia rozhoduje, ktoré tabuľky dostanú naučené alebo pripojené prefixy daného pripojenia. Jedno pripojenie môže byť asociované s jednou tabuľkou a zároveň propagovať do viacerých. Zámena týchto dvoch je spôsob, ako návrh skončí s dosiahnuteľnosťou, ktorú nikto neplánoval.
Plne prepojené malé centrum je jednoduchý prípad.
Dajte každé pripojenie do jednej tabuľky a VPN spolu s oboma prefixami VPC sa vyrieši čisto. To tiež umožní dosiahnuteľnosť medzi VPC, ktorú organizácia možno nikdy nezamýšľala, pretože zdieľaná tabuľka nepozná pojem spoke.
Trasy úloh žijú inde
Každá podsieť úlohy stále potrebuje vlastnú trasu k tranzitnej bráne pre zamýšľané lokálne prefixy. Tie smerovacie tabuľky VPC sú samostatné objekty od vlastných tabuliek tranzitnej brány. Pridajte potrebné prefixy a zachovajte existujúce trasy namiesto nahradenia každého cieľa novým defaultom. Trasa podsiete tiež nič neoznamuje zariadeniu zákazníka.
Vyberte dynamické alebo statické smerovanie vedome; peering nedáva ani jedno.
Izolujte spokes bez straty lokálneho prístupu
Keď A aj B môžu dosiahnuť kanceláriu, ale nesmú smerovať navzájom, rozdeľte tabuľky. Asociovaná tabuľka pripojenia VPN drží prefixy VPC. Asociovaná tabuľka pripojení VPC drží lokálne prefixy, bez trasy spájajúcej A s B. Tento vzťah vytvára propagácia, takže nikdy nemusíte prijať každú predvolenú asociáciu.
Toto je izolácia smerovania, nie autorizácia aplikácie.
Bezpečnostné skupiny, sieťové ACL, hostiteľské firewally a vlastné oprávnenia každej služby stále rozhodujú, ktorá prevádzka sa pripustí. Ak je potrebná inšpekcia, navrhnite jej podporovanú cestu explicitne, namiesto predpokladu, že ju centrum vykoná.
Čo centrum neopraví
Plány adries sa stále nesmú prekrývať, pretože centrum nedovolí, aby jeden prefix označoval dve úlohy. Každé pripojenie VPC potrebuje pokrytie Availability Zone, ktoré jeho úlohy očakávajú. S BGP musia trasy zariadenia zákazníka späť ku každému potrebnému prefixu zodpovedať návrhu a jeho politike importu. Chýbajúce oznámenie vyzerá presne ako rozbitý tunel.
VPN spojenie a tranzitná brána sú teraz zdieľaná infraštruktúra.
Plánujte redundanciu tunelov, kapacitu zariadení, monitorovanie a údržbu okolo všetkých závislých VPC namiesto zaobchádzania s každým ako samostatne pripojeným.
Migrácia z existujúceho usporiadania s virtual private gateway si zaslúži ten istý explicitný plán. Postavte pripojenia a politiky, presuňte jednu kontrolovanú cestu úlohy a pred vyradením starej cesty potvrďte povolené a zakázané vzťahy. Centralizácia pomáha, keď dá sieťovému tímu jedno miesto na správu zdieľanej konektivity, a škodí, keď skryje, kto sa ku komu smie dostať, za jednou veľkou tabuľkou.