Shtimi i një nënrrjeti lokal në një AWS VPN: VGW kundrejt Transit Gateway

Një VPN Site-to-Site ekzistues transporton 10.60.0.0/16, një rrjet i ri shërbimi shfaqet pas të njëjtës portë lokale si 10.70.0.0/16, dhe dikush pyet nëse nevojitet një proxy. Zakonisht jo: një shteg i rrugëzuar mund të transportojë prefiksin, por vetëm nëse tre gjëra përputhen, dhe cilat tre varet nga arkitektura AWS që tashmë drejtoni. Një portë private virtuale ka një kufi tabele rrugëtimi; një transit gateway shton një të dytë. Njoftimi i saktë me tabelën e gabuar prodhon një sesion që duket i shëndetshëm dhe nuk dorëzon asgjë.

Publikoni një prefiks që porta vërtet mund ta dorëzojë

Porta lokale ka nevojë për një rrugë përpara drejt rrjetit të ri përpara se çdo njoftim të ketë kuptim. Njoftimi i 10.70.0.0/16 përmes BGP i thotë AWS ku të dërgojë paketat për atë interval; nuk krijon shtegun lokal të përcjelljes që e bën intervalin të arritshëm në skajin tjetër. Konfirmoni që porta ka një rrugë për prefiksin që tregon pajisjen që e mban, dhe që pajisja është konfiguruar të përgjigjet për ato adresa. Politika e eksportit dhe kufijtë e pranuar të prefiksit janë kufizimi tjetër, sepse një prefiks që sesioni e filtron nuk arrin kurrë në AWS.

Mbajini agregatet dhe rrugët më specifike të qëllimshme. Shtigjet që mbivendosen dhe vijnë nga dy drejtime janë një vendim projektimi, jo një detaj që zbulohet më vonë.

Shtegu një: kufiri i portës private virtuale

Me një portë private virtuale, dokumentacioni i rrugëzimit të AWS VPN përshkruan dy mënyra shpërndarjeje, rrugë statike dhe njoftime BGP, dhe të dyja varen nga tabela e rrugëzimit të nënrrjetit që aplikacioni përdor vërtet. Përhapja është e përshtatshme kur kontrolloni të gjithë intervalin, dhe një rrugë e qartë është më e lehtë për t’u arsyetuar kur dëshironi destinacionin të listuar pranë objektivit. Në çdo rast, kontrolli është i njëjtë: a përmban tabela e nënrrjetit specifik të aplikacionit një shteg funksional drejt objektivit VPN për prefiksin e ri, dhe a fiton ai ndaj diçkaje më specifike?

Një sesion i shëndetshëm BGP dëshmon se kanali ekziston. Nuk thotë asgjë nëse një tabelë e caktuar e nënrrjetit e ka konsumuar rrugën.

Shtegu dy: transit gateway shton një tabelë

Një transit gateway e ndan atë pyetje të vetme në dy. Nënrrjeti i VPC duhet ta dërgojë destinacionin te lidhja e transit gateway, dhe pastaj tabela e rrugëzimit e transit gateway duhet të zgjedhë lidhjen VPN për të njëjtin prefiks. Zgjedhjet e asociimit dhe përhapjes përcaktojnë cilat rrjete të lidhura e marrin rrugën, kështu që një prefiks mund të njoftohet saktë nga VPN dhe gjithsesi të mos arrijë kurrë në VPC-në tabela e të cilit nuk u asociua kurrë me tabelën e duhur të rrugëzimit.

Dështimi i zakonshëm është një rrugë që ekziston në një tabelë dhe jo në tjetrën, ku çdo ekip është i bindur se ana e tij është e saktë. Kur krahasoni dy arkitekturat, ky kufi shtesë është i gjithë ndryshimi: më shumë vende për të shikuar, dhe kontroll më i saktë mbi atë se kush e merr rrugën.

As përhapja e rrugëve nuk ia jep prefiksin çdo lidhjeje. Ajo e shpërndan në tabelat e konfiguruara ta marrin.

Shtegu i kthimit është një vendim politikash më vete

Trafiku që mbërrin është vetëm gjysma e shkëmbimit. Rrjeti i ri lokal ka nevojë për një rrugë kthimi drejt prefikseve burimore të AWS përmes portës së duhur, dhe politika e sigurisë në të dy skajet duhet ta lejojë atë çift burimi e destinacioni. Nëse tuneli negocion një shtrirje mbrojtjeje me përzgjedhës trafiku, prefiksi i ri duhet të jetë brenda saj, përndryshe paketa hidhet para se të konsultohet çdo tabelë rrugëzimi.

Mbivendosja e adresave është kurthi tjetër. Intervalet e ndara dhe me pronësi të qartë e mbajnë këtë të thjeshtë; intervalet që mbivendosen nënkuptojnë përkthim ose rindërtim, dhe asnjëra nuk është variant i këmbyeshëm i të njëjtit recetë.

Testoni me një burim në rrjetin e ri dhe një destinacion në nënrrjetin e aplikacionit, pastaj përsëriteni në drejtimin tjetër. Një test njëdrejtimësh dëshmon vetëm një drejtim.

Kur proxy është vërtet kufiri më i mirë

Një proxy e fiton vendin e tij kur kërkesa është një ndërfaqe shërbimi e ngushtë, kur aplikacioni tashmë e pret atë arkitekturë, ose kur shtegu i rrjetit nuk mund të bëhet të transportojë prefiksin pa një përkthim që nuk e dëshironi. Nuk është zgjidhja rezervë për një zë në tabelën e rrugëzimit që askush nuk e ka kontrolluar.

Vendosni në këtë rend: përcjellje lokale, njoftim, kufi i tabelës, politikë kthimi. Rregulloni të parën që dështon, dhe vetëm pastaj pyesni nëse shtegu i rrugëzuar është fare përgjigjja e saktë.