Yll apo rrjetë e plotë: cila topologji VPN i përshtatet lokacioneve tuaja

Dy zyra degësh bisedojnë me njëri-tjetrin gjithë ditën, dhe tuneli mes tyre bën një xhiro përmes një qendre të dhënash në një rajon tjetër. Çdo kërkesë paguan dy herë për atë xhiro, dhe askush nuk e vëren derisa sinkronizimi i skedarëve fillon të duket i gabuar. Këtu fillon vërtet pyetja e topologjisë: jo me atë se cila skemë duket më e qëndrueshme, por me atë se për çfarë modeli trafiku po paguani. Të dyja modelet punojnë, dhe të dyja dështojnë në mënyra të ndryshme me kosto të ndryshme.

Numëroni marrëdhëniet mes nyjeve para çdo gjëje

Me N lokacione, një rrjetë e plotë kërkon N herë N minus një, pjesëtuar me dy, tunele; një qendër kërkon N. Me pesë lokacione kjo është dhjetë kundrejt pesë, që ende tingëllon e menaxhueshme. Me pesëmbëdhjetë është 105 kundrejt pesëmbëdhjetë, dhe diferenca nuk është më aritmetike, por e personelit.

Secila prej këtyre marrëdhënieve mban gjendje që duhet ta administroni. Në IPsec kjo do të thotë një asociacion sigurie, një identitet, një çelës ose certifikatë, zbulimin e nyjes së vdekur dhe të paktën një rrugë për çdo prefiks të largët. Në WireGuard do të thotë një çelës publik dhe një bllok AllowedIPs për çdo nyje; më lirë për nyje, por pa asnjë zbulim: një lokacion i re është në çdo rast ndryshim konfigurimi në të gjitha ato ekzistuese.

Le të vendosë përzierja e trafikut, jo vizatimi

Nëse trafiku i degëve është kryesisht kërkesa drejt një ERP-i qendror ose një grupi skedarësh, një qendër nuk është kompromis, por forma e duhur: trafiku tashmë donte të shkonte atje, dhe një pikë e vetme politike është më e lehtë për t'u audituar sesa një rrjetë rregullash dyshe. Rrjeta e plotë e meriton kompleksitetin kur degët shkëmbejnë të dhëna mes tyre: replikim mes dy zyrave, zë mes lokacioneve, një ndarje CAD që një duzinë inxhinierësh e hapin gjithë ditën.

Rastet e pavolitshme qëndrojnë në mes, dhe ata janë shumica. Matni përpara se të debatoni, në vend që të hamendësoni nga një skemë organizative.

Lexojeni tabelën si vendimtare, jo si rregull. Tre nga katër rreshta në një drejtim zakonisht e zgjidhin projektin, dhe një ndarje do të thotë hibrid, që është ajo që shumica e rrjeteve të pjekura përfundimisht përdorin.

Qendrës duhet t'i thuhet të përcjellë

Dy tunele funksionale degë-qendër nuk krijojnë akses mes degëve. Qendra ka nevojë për përcjellje IP të aktivizuar, një rrugë drejt çdo rrjeti dege, një rregull muri zjarri që lejon transitin dhe rrugën e kthimit të llogaritur; çdo degë ka nevojë për një rrugë drejt prefikseve të lokacionit tjetër. Në një qendër Linux kjo është net.ipv4.ip_forward=1 plus një zinxhir FORWARD që nuk e hedh çiftin në heshtje, ndërsa në IPsec të bazuar në politika janë selektorë trafiku që listojnë nënrrjetin e degës së largët në të dy skajet. strongSwan shënimet për përcjelljen mbulojnë anën e kernelit dhe të murit të zjarrit kur pikërisht ai shtresë ju mungon. Një test i lirë: dërgoni trafik nga një degë drejt një shërbimi në tjetrën duke vëzhguar numëruesit e qendrës; një rregull që nuk rritet kurrë tregon se rendi është i gabuar, jo rruga.

Politika qendrore është gjithashtu pjesa e dobishme. Degëve mund t'u lejohet të arrijnë shërbime të përbashkëta pa arritur njëra-tjetrën, dhe kjo matricë aksesi ia vlen të shkruhet në mënyrë eksplicite. Rrugët që mungojnë janë një zëvendësim i dobët për një rregull që dikush mund ta lexojë.

Kujdes nga versioni i gjysmë-bërë: dega A rrugëton drejt degës B përmes qendrës, qendra rrugëton në të dy drejtimet, dhe muri i zjarrit i qendrës lejon lidhje të reja nga A, por jo nga B. Drejtimi i parë testohet mirë dhe i dyti ngec, që duket si defekt rrugëtimi dhe nuk është.

Projektoni së pari dështimin, pastaj rrugën normale

Një qendër e vetme është varësi e përbashkët dhe pikë e ngushtë transitit, dhe teprica është vendi ku projektet me qendër zakonisht gabojnë. Dy qendra do të thonë që çdo degë mban dy tunele, dhe rruga e kthimit duhet të pajtohet me atë të daljes; kur nuk pajtohet, një mur zjarri me gjendje i hedh përgjigjet, dhe simptomi është një lidhje që hapet dhe pastaj vdes. Vendosjet më të mëdha e zgjidhin këtë me një protokoll rrugëtimi mbi tunele në vend të prefikseve statike, që është më shumë mekanizëm, por heq hamendësimin. Çfarëdo që zgjidhni, shkruani rrugën e kthimit pranë asaj të daljes, sepse gjysma e kthimit është ajo që askush nuk teston.

Një rrjetë e plotë e shpërndan atë rrezik: rënia e lidhjes së një lokacioni nuk i izolon të tjerët. Ajo gjithashtu shumëfishon vendet ku zgjedhja e rrugës mund t'ju befasojë, dhe sesionet e aplikacioneve ende nuk i mbijetojnë një ndryshimi rruge pa ndihmë.

Asnjëri prej projekteve nuk e mban vetë një sesion TCP gjallë gjatë një kalimi. Nëse aplikacioni nuk mund të rilidhet, topologjia nuk është problemi juaj.

Zgjidhni sipas kostos së ndryshimit, pastaj verifikoni rrugët

Filloni me qendrën, sepse është gjëja më e lirë për të gabuar, dhe shtoni tunele të drejtpërdrejta për çiftet, trafiku i të cilëve e justifikon. Ai hibrid nuk është dështim për të vendosur; është projekti ku shumica e organizatave konvergojnë brenda një viti. Rëndësi ka që çdo lidhje e drejtpërdrejtë të ketë një arsye të deklaruar dhe një pronar.

Pastaj verifikoni dy vizatime, jo një. Për rrugën normale, ekzekutoni traceroute nga çdo lokacion drejt çdo prefiksi shërbimi dhe konfirmoni që hopet përputhen me diagramin. Për rrugën e dështimit, mbyllni një tunel dhe përsëriteni, sepse një rrugë që funksionon vetëm sa kohë gjithçka është lart nuk është projektuar, vetëm konfiguruar.

Mbani të dyja vizatimet bashkë me matricën e aksesit dhe rikthejuni atyre kur shtohet një lokacion; kostoja që menaxhoni është kostoja e ndryshimit të ardhshëm, jo eleganca e pamjes aktuale.