Een terrein-tot-terrein-VPN vir verskeie VPC's op AWS Transit Gateway
Koppel die VPN een keer en elke VPC aan een transit gateway, en skei dan assosiasie van propagasie sodat spoke die kantoor kan bereik maar nie mekaar nie.
Twee VPC's het hierdie kwartaal die kantoornetwerk nodig, en dit is by die tweede tonnel waar die skatting breek. AWS Transit Gateway kan as 'n gedeelde roeteringhub dien: die VPN koppel een keer, en elke VPC koppel aan dieselfde hub. Die plaaslike netwerk bereik dan elke gekoppelde VPC deur een verbinding. Dit verander wie die roeteringbesluit besit, en dit is die deel wat die meeste ontwerpe verkeerd kry.
Die VPN-aanhegting en die VPC-aanhegtings is aparte objekte op dieselfde gateway, en daarom moet die roeteringsverhoudings daarna gebou word.
On-premises network <-> Site-to-Site VPN <-> Transit Gateway
|- VPC A
|- VPC B
Waarom peering nie die kortpad is wat mense hoop nie
Die verleidelike alternatief is om die VPN op VPC A te beëindig en VPC B daaraan te peering. Gewone VPC-peering verskaf nie rand-tot-rand-deurvoer deur A se VPN-verbinding nie. 'n Peer bereik die adresse wat die peering self verskaf, en 'n VPN-rand is nie een daarvan nie. Deurvoer is wat 'n hub gee; peering gee 'n paar.
Daardie beperking is 'n eienskap van peering, nie 'n kwota wat jy kan verhoog nie.
Assosiasie en propagasie doen verskillende werk
Binne die Transit Gateway kies assosiasie die roetetabel wat gebruik word om verkeer van 'n aanhegting op te soek. Propagasie besluit watter tabelle die geleerde of gekoppelde prefikse van 'n aanhegting ontvang. 'n Enkele aanhegting kan aan een tabel assosieer terwyl dit in verskeie propageer. Om die twee te verwar is hoe 'n ontwerp bereikbaarheid kry wat niemand beplan het nie.
'n Volledig gekoppelde klein hub is die maklike geval.
Sit elke aanhegting in een tabel en die VPN plus beide VPC-prefikse los skoon op. Dit laat ook VPC-tot-VPC-bereikbaarheid toe wat die organisasie nooit bedoel het nie, want 'n gedeelde tabel het geen begrip van 'n spoke nie.
Werklastroetes woon elders
Elke werklas-subnet het steeds sy eie roete na die Transit Gateway nodig vir die beoogde plaaslike prefikse. Daardie VPC-roetetabelle is aparte objekte van die Transit Gateway se eie tabelle. Voeg die prefikse by wat jy nodig het en behou bestaande roetes eerder as om elke bestemming met 'n nuwe verstek te vervang. 'n Subnetroete adverteer ook niks aan die kliënttoestel nie.
Kies dinamiese of statiese roetering doelbewus; peering lewer nie een van die twee nie.
Isoleer spoke sonder om plaaslike toegang te verloor
Wanneer A en B elkeen die kantoor mag bereik maar nie na mekaar mag roeteer nie, verdeel die tabelle. Die geassosieerde tabel van die VPN-aanhegting hou die VPC-prefikse. Die geassosieerde tabel van die VPC-aanhegtings hou die plaaslike prefikse, met geen roete wat A aan B verbind nie. Propagasie produseer daardie verhouding, so jy hoef nooit elke verstekassosiasie te aanvaar nie.
Dit is roetering-isolasie, en dit is nie toepassingmagtiging nie.
Sekuriteitsgroepe, netwerk-ACL's, gasheerfirewalls en elke diens se eie toestemmings besluit steeds watter verkeer toegelaat word. As inspeksie vereis word, ontwerp die ondersteunde pad eksplisiet eerder as om te aanvaar die hub doen dit.
Wat die hub nie regmaak nie
Adresplanne moet steeds nie oorvleuel nie, want die hub laat nie een prefiks twee werklaste identifiseer nie. Elke VPC-aanhegting het die Availability Zone-dekking nodig wat sy werklaste verwag. Met BGP moet die kliënttoestel se roetes terug na elke vereiste prefiks by die ontwerp en sy invoerbeleid pas. 'n Ontbrekende advertensie lyk presies soos 'n gebreekte tonnel.
Die VPN-verbinding en die Transit Gateway is nou gedeelde infrastruktuur.
Beplan tonnel-redundansie, toestelkapasiteit, monitering en instandhouding rondom alle afhanklike VPC's eerder as om elkeen as onafhanklik gekoppel te behandel.
Migrasie vanaf 'n bestaande virtual private gateway-reëling verdien dieselfde eksplisiete plan. Bou die aanhegtings en beleide, skuif een beheerde werklasroete, en bevestig die toegelate en geweierde verhoudings voordat jy die ou roete aftree. Sentralisering help wanneer dit die netwerkspan een plek gee om gedeelde verbindings te bestuur, en dit skaad wanneer dit verberg wie wie mag bereik agter een groot tabel.