Viens VPN starp vietām vairākiem VPC AWS Transit Gateway pakalpojumā

Diviem VPC šajā ceturksnī vajag biroja tīklu, un tieši otrajā tunelī tāme lūzt. AWS Transit Gateway var darboties kā kopīgs maršrutēšanas centrs: VPN tiek pievienots vienreiz, un katrs VPC tiek pievienots tam pašam centram. Tad vietējais tīkls sasniedz katru pievienoto VPC caur vienu savienojumu. Tas maina, kam pieder maršrutēšanas lēmums, un tieši šo daļu lielākā daļa projektu izdara nepareizi.

VPN pievienojums un VPC pievienojumi ir atsevišķi objekti vienā vārtējā, tāpēc maršrutēšanas attiecības jābūvē pēc tam.

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

Kāpēc peering nav tas īsceļš, uz kuru cer

Kārdinošā alternatīva ir pabeigt VPN VPC A un ar peering palīdzību pievienot VPC B tam. Parastais VPC peering nenodrošina tranzītu no malas līdz malai caur A VPN savienojumu. Peering partneris sasniedz tikai tās adreses, ko nodrošina pats peering, un VPN mala nav viena no tām. Tranzītu dod centrs; peering dod pāri.

Šis ierobežojums ir peering īpašība, nevis kvota, ko var paaugstināt.

Saistīšana un izplatīšana dara atšķirīgu darbu

Tranzīta vārtejas iekšienē saistīšana izvēlas maršrutu tabulu, pēc kuras meklē no pievienojuma ienākošo trafiku. Izplatīšana nosaka, kuras tabulas saņems pievienojuma apgūtos vai savienotos prefiksus. Viens pievienojums var būt saistīts ar vienu tabulu un vienlaikus izplatīties vairākās. Šo divu sajaukšana ir veids, kā projekts nonāk pie sasniedzamības, ko neviens nebija plānojis.

Pilnībā savienots mazs centrs ir vieglais gadījums.

Ielieciet katru pievienojumu vienā tabulā, un VPN kopā ar abiem VPC prefiksiem izšķiras tīri. Tas arī pieļauj sasniedzamību starp VPC, ko organizācija, iespējams, nekad nav gribējusi, jo kopīgai tabulai nav atzara jēdziena.

Darba slodžu maršruti dzīvo citur

Katram darba slodzes apakštīklam joprojām vajag savu maršrutu uz tranzīta vārteju paredzētajiem vietējiem prefiksiem. Tās VPC maršrutu tabulas ir atsevišķi objekti no pašas vārtējas tabulām. Pievienojiet vajadzīgos prefiksus un saglabājiet esošos maršrutus, nevis aizstājiet katru galamērķi ar jaunu default. Apakštīkla maršruts arī neko neizziņo klienta ierīcei.

Izvēlieties dinamisku vai statisku maršrutēšanu apzināti; peering nedod nevienu.

Izolējiet atzarus, nezaudējot vietējo piekļuvi

Kad A un B abi var sasniegt biroju, bet nedrīkst maršrutēt viens uz otru, sadaliet tabulas. VPN pievienojuma saistītā tabula tur VPC prefiksus. VPC pievienojumu saistītā tabula tur vietējos prefiksus, bez maršruta, kas savieno A ar B. Šo attiecību rada izplatīšana, tāpēc jums nekad nav jāpieņem katra noklusējuma saistīšana.

Tā ir maršrutēšanas izolācija, un tā nav lietojumprogrammas autorizācija.

Drošības grupas, tīkla ACL, resursdatora ugunsmūri un katras pakalpojuma paša atļaujas joprojām nosaka, kurš trafiks tiek pieņemts. Ja nepieciešama pārbaude, projektējiet tās atbalstīto ceļu skaidri, nevis pieņemiet, ka centrs to veic.

Ko centrs nesalabo

Adrešu plāniem joprojām jābūt bez pārklāšanās, jo centrs neļauj vienam prefiksam apzīmēt divas darba slodzes. Katram VPC pievienojumam vajag to Availability Zone pārklājumu, ko gaida tā darba slodzes. Ar BGP klienta ierīces maršrutiem atpakaļ uz katru nepieciešamo prefiksu jāatbilst projektam un tā importa politikai. Trūkstošs paziņojums izskatās tieši kā salauzts tunelis.

VPN savienojums un tranzīta vārtēja tagad ir kopīga infrastruktūra.

Plānojiet tuneļu dublēšanu, ierīču jaudu, uzraudzību un apkopi ap visiem atkarīgajiem VPC, nevis izturieties pret katru kā atsevišķi savienotu.

Migrācija no esošas virtual private gateway shēmas ir pelnījusi to pašu skaidro plānu. Izveidojiet pievienojumus un politikas, pārvietojiet vienu kontrolētu darba slodzes ceļu un apstipriniet atļautās un aizliegtās attiecības pirms vecā ceļa atcelšanas. Centralizācija palīdz, kad tā dod tīkla komandai vienu vietu kopīga savienojuma pārvaldībai, un kaitē, kad tā aiz vienas lielas tabulas paslēpj, kas ko var sasniegt.