En VPN od lokacije do lokacije za več VPC v AWS Transit Gateway

Dva VPC to četrtletje potrebujeta pisarniško omrežje in prav pri drugem tunelu se ocena zlomi. AWS Transit Gateway lahko deluje kot skupno usmerjevalno središče: VPN se pripne enkrat in vsak VPC se pripne na isto središče. Nato lokalno omrežje doseže vsak pripet VPC prek ene povezave. To spremeni, kdo ima odločitev o usmerjanju, in prav to večina načrtov naredi narobe.

Priključek VPN in priključki VPC so ločeni objekti na istem prehodu, zato je treba usmerjevalne odnose zgraditi pozneje.

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

Zakaj peering ni bližnjica, ki ji ljudje upajo

Mamljiva alternativa je zaključiti VPN na VPC A in VPC B povezati z njim prek peeringa. Običajni VPC peering ne omogoča tranzita od roba do roba prek VPN povezave A. Peer doseže le naslove, ki jih ponuja sam peering, in VPN rob ni eden od njih. Tranzit daje središče; peering daje par.

Ta omejitev je lastnost peeringa, ne kvota, ki bi jo lahko dvignili.

Povezovanje in širjenje opravljata različno delo

Znotraj tranzitnega prehoda povezovanje izbere usmerjevalno tabelo, po kateri se išče promet, ki prihaja s priključka. Širjenje odloči, katere tabele prejmejo naučene ali povezane predpone priključka. En priključek je lahko povezan z eno tabelo in hkrati širi v več. Zamenjava teh dveh je način, kako se načrt konča z dosegljivostjo, ki je nihče ni načrtoval.

Popolnoma povezano majhno središče je lahek primer.

Vsak priključek postavite v eno tabelo in VPN se skupaj z obema predponama VPC čisto razreši. To dovoljuje tudi dosegljivost med VPC, ki si je organizacija morda nikoli ni želela, ker skupna tabela ne pozna pojma spoke.

Poti delovnih obremenitev živijo drugje

Vsaka podomrežje delovne obremenitve še vedno potrebuje svojo pot proti tranzitnemu prehodu za predvidene lokalne predpone. Te usmerjevalne tabele VPC so ločeni objekti od lastnih tabel prehoda. Dodajte potrebne predpone in ohranite obstoječe poti, namesto da bi vsak cilj zamenjali z novim defaultom. Pot podomrežja tudi nič ne oglašuje napravi stranke.

Dinamično ali statično usmerjanje izberite zavestno; peering ne ponuja nobenega.

Izolirajte spokes brez izgube lokalnega dostopa

Ko lahko A in B oba dosežeta pisarno, ne smeta pa usmerjati drug na drugega, razdelite tabele. Povezana tabela priključka VPN vsebuje predpone VPC. Povezana tabela priključkov VPC vsebuje lokalne predpone, brez poti, ki bi povezala A z B. To razmerje ustvari širjenje, zato vam ni treba nikoli sprejeti vsake privzete povezave.

To je izolacija usmerjanja in ni avtorizacija aplikacije.

Varnostne skupine, omrežni ACL, požarni zidovi gostiteljev in lastna dovoljenja vsake storitve še vedno odločajo, kateri promet je sprejet. Če je potreben pregled, načrtujte njegovo podprto pot izrecno, namesto da predpostavljate, da ga središče izvede.

Česa središče ne popravi

Načrti naslovov se še vedno ne smejo prekrivati, ker središče ne dovoli, da bi ena predpona označevala dve delovni obremenitvi. Vsak priključek VPC potrebuje pokritost Availability Zone, ki jo pričakujejo njegove delovne obremenitve. Z BGP morajo poti naprave stranke nazaj do vsake potrebne predpone ustrezati načrtu in njegovi politiki uvoza. Manjkajoča objava je videti natanko kot pretrgan tunel.

Povezava VPN in tranzitni prehod sta zdaj skupna infrastruktura.

Načrtujte redundanco tunelov, zmogljivost naprav, spremljanje in vzdrževanje okoli vseh odvisnih VPC, namesto da bi vsakega obravnavali kot neodvisno povezanega.

Selitev z obstoječe ureditve z virtual private gateway si zasluži enak izrecen načrt. Zgradite priključke in politike, premaknite eno nadzorovano pot delovne obremenitve in potrdite dovoljena in zavrnjena razmerja, preden umaknete staro pot. Centralizacija pomaga, ko omrežni ekipi da eno mesto za upravljanje skupne povezljivosti, in škoduje, ko skrije, kdo lahko doseže koga, za eno veliko tabelo.