Üks saidilt-saidile VPN mitme VPC jaoks AWS Transit Gateway juures

Kahel VPC-l on sel kvartalil kontorivõrku vaja ja just teise tunneliga murdub hinnang. AWS Transit Gateway saab toimida ühise marsruutimiskeskmena: VPN ühendatakse üks kord ja iga VPC ühendatakse sama keskme külge. Seejärel jõuab kohalik võrk igasse ühendatud VPC-sse ühe ühenduse kaudu. See muudab, kellel on marsruutimisotsus, ja just selle osa teeb enamik projekte valesti.

VPN-i kinnitus ja VPC-de kinnitused on samal lüüsil eraldi objektid, seepärast tuleb marsruutimissuhted hiljem üles ehitada.

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

Miks peering ei ole see lühike tee, mida loodetakse

Ahvatlev alternatiiv on lõpetada VPN VPC A peal ja peering-ühendada VPC B sellega. Tavaline VPC peering ei paku servast serva transiiti läbi A VPN-ühenduse. Peer jõuab aadressidele, mille peering ise annab, ja VPN-i serv ei ole üks neist. Transiidi annab keskus; peering annab paari.

See piirang on peeringu omadus, mitte kvoot, mida saab tõsta.

Seostamine ja levitamine teevad erinevat tööd

Transiidilüüsi sees valib seostamine marsruutimistabeli, mille järgi otsitakse kinnituselt saabuvat liiklust. Levitamine otsustab, millised tabelid saavad kinnituse õpitud või ühendatud prefiksid. Üks kinnitus saab olla seotud ühe tabeliga, levides samal ajal mitmesse. Mõlema segiajamine on viis, kuidas projekt jõuab kättesaadavuseni, mida keegi ei planeerinud.

Täielikult ühendatud väike keskus on lihtne juhtum.

Pange iga kinnitus ühte tabelisse ja VPN koos mõlema VPC prefiksiga laheneb puhtalt. See lubab ka VPC-de vahelist kättesaadavust, mida organisatsioon võib-olla kunagi ei kavatsenud, sest jagatud tabel ei tunne haru mõistet.

Töökoormuste marsruudid elavad mujal

Igal töökoormuse alavõrgul on endiselt vaja oma marsruuti transiidilüüsi suunas kavandatud kohalike prefiksite jaoks. Need VPC marsruutimistabelid on transiidilüüsi enda tabelitest eraldi objektid. Lisage vajalikud prefiksid ja säilitage olemasolevad marsruudid, selle asemel et asendada iga sihtkoht uue defaultiga. Alavõrgu marsruut ei teata ka kliendi seadmele midagi.

Valige dünaamiline või staatiline marsruutimine teadlikult; peering ei anna kumbagi.

Isoleerige harud kohalikku juurdepääsu kaotamata

Kui A ja B tohivad mõlemad kontorisse jõuda, kuid ei tohi üksteise suunas marsruutida, jagage tabelid. VPN-i kinnituse seotud tabel hoiab VPC prefikseid. VPC-de kinnituste seotud tabel hoiab kohalikke prefikseid, ilma marsruudita, mis ühendab A-d B-ga. Levitamine loob selle suhte, nii et te ei pea kunagi kõiki vaikimisi seostamisi aktsepteerima.

See on marsruutimise isolatsioon ja see ei ole rakenduse autoriseerimine.

Turvagrupid, võrgu ACL-id, hosti tulemüürid ja iga teenuse enda õigused otsustavad endiselt, milline liiklus lubatakse. Kui on vaja kontrolli, kavandage selle toetatud tee selgesõnaliselt, selle asemel et eeldada, et keskus seda teeb.

Mida keskus ei paranda

Aadressiplaanid peavad endiselt mitte kattuma, sest keskus ei luba ühel prefiksil tähistada kahte töökoormust. Iga VPC kinnitus vajab Availability Zone katvust, mida tema töökoormused ootavad. BGP-ga peavad kliendi seadme marsruudid tagasi iga vajaliku prefiksi juurde vastama projektile ja selle impordipoliitikale. Puuduv teade näeb välja täpselt nagu katkine tunnel.

VPN-ühendus ja transiidilüüs on nüüd jagatud taristu.

Planeerige tunnelite liiasus, seadmete võimsus, monitooring ja hooldus kõigi sõltuvate VPC-de ümber, selle asemel et kohelda igaüht eraldi ühendatuna.

Üleminek olemasolevalt virtual private gateway lahenduselt väärib sama selgesõnalist plaani. Ehitage kinnitused ja poliitikad, liigutage üks kontrollitud töökoormuse marsruut ja kinnitage lubatud ja keelatud suhted enne vana tee kasutusest kõrvaldamist. Tsentraliseerimine aitab, kui annab võrgumeeskonnale ühe koha jagatud ühenduvuse haldamiseks, ja kahjustab, kui peidab ühe suure tabeli taga, kes kelleni jõuda tohib.