Zvaigzne vai pilnīgs tīkls: kura VPN topoloģija atbilst jūsu vietām
Divi strādājoši tuneļi vēl nav topoloģija. Pirms izvēlaties centru, tīklu vai centru ar dažiem tiešiem savienojumiem, salīdziniet tranzītu, uzvedību atteices gadījumā un izmaiņu izmaksas.
Divi filiāles biroji visu dienu sarunājas savā starpā, un tunelis starp tiem iet cauri datu centram citā reģionā. Katrs pieprasījums par to apkārtceļu maksā divreiz, un neviens to nepamana, kamēr failu sinhronizācija sāk šķist nepareiza. Šeit arī sākas topoloģijas jautājums: nevis kura diagramma izskatās izturīgāka, bet par kuru trafika modeli jūs maksājat. Abi risinājumi strādā, un abi sabrūk dažādos veidos ar dažādām izmaksām.
Vispirms saskaitiet vienādranga attiecības
Ar N vietām pilnīgam tīklam vajag N reizināts ar N mīnus viens, dalīts ar divi, tuneļus; centram vajag N. Piecās vietās tas ir desmit pret piecām, kas vēl šķiet paveicami. Piecpadsmit vietās tas ir 105 pret piecpadsmit, un atšķirība vairs nav aritmētiska, bet personāla.
Katra no šīm attiecībām nes stāvokli, kas jums jāpārvalda. IPsec tas nozīmē drošības asociāciju, identitāti, atslēgu vai sertifikātu, miruša vienādranga noteikšanu un vismaz vienu maršrutu katram attālinātajam prefiksam. WireGuard tas nozīmē publisku atslēgu un AllowedIPs bloku katram vienādaram; uz vienu vienādrangu lētāk, bet pilnīgi bez atklāšanas: jauna vieta jebkurā gadījumā nozīmē konfigurācijas izmaiņas visās esošajās.
Lai izlemj trafika sastāvs, nevis zīmējums
Ja filiāļu trafiks galvenokārt ir pieprasījumi uz centrālo ERP vai failu klasteri, centrs nav kompromiss, tas ir pareizā forma: trafiks jau gribēja doties turp, un viens politikas punkts ir vieglāk auditējams nekā pāru noteikumu tīkls. Tīkls savu sarežģītību pelna tad, kad filiāles apmainās ar datiem savā starpā: replikācija starp diviem birojiem, balss starp vietām, CAD koplietojums, ko ducis inženieru atver visu dienu.
Neērtie gadījumi atrodas pa vidu, un tie ir vairākums. Mēriet pirms strīdaties, nevis miniet no organizācijas shēmas.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Lasiet tabulu kā izšķirošo, nevis kā noteikumu. Trīs no četrām rindām vienā virzienā parasti izšķir projektu, bet sadalījums nozīmē hibrīdu, ko lielākā daļa nobriedušu tīklu galu galā izmanto.
Centram ir jāpasaka, ka jāpārsūta
Divi strādājoši filiāles-centra tuneļi vēl neveido piekļuvi starp filiālēm. Centram nepieciešama ieslēgta IP pārsūtīšana, maršruts uz katru filiāles tīklu, ugunsmūra noteikums, kas atļauj tranzītu, un aprēķināts atgaitas ceļš; katrai filiālei vajadzīgs maršruts uz otras vietas prefiksiem. Linux centrā tas ir net.ipv4.ip_forward=1 un FORWARD ķēde, kas klusi neizmet pāri, bet uz politiku balstītā IPsec tie ir trafika atlasītāji, kuros abos galos uzskaitīts attālinātās filiāles apakštīkls. strongSwan pārsūtīšanas piezīmes aptver kodola un ugunsmūra pusi, kad tieši tā slāņa trūkst. Lēts tests: sūtiet trafiku no vienas filiāles uz pakalpojumu otrā un vērojiet centra skaitītājus; noteikums, kas nekad nepalielinās, nozīmē, ka nepareiza ir secība, nevis maršruts.
Centrālā politika arī ir noderīgā daļa. Filiālēm var atļaut sasniegt koplietotos pakalpojumus, nesasniedzot viena otru, un šo piekļuves matricu ir vērts skaidri pierakstīt. Trūkstoši maršruti ir slikts aizstājējs noteikumam, ko cilvēks var izlasīt.
Uzmanieties no pusgatavās versijas: filiāle A maršrutē uz filiāli B caur centru, centrs maršrutē abos virzienos, un centra ugunsmūris atļauj jaunus savienojumus no A, bet ne no B. Pirmais virziens testējas labi, otrais karājas, kas izskatās pēc maršrutēšanas kļūdas, bet nav.
Vispirms projektējiet atteici, tad parasto ceļu
Viens centrs ir kopīga atkarība un tranzīta šaurums, un dublēšana ir vieta, kur centra projekti parasti kļūdās. Divi centri nozīmē, ka katra filiāle tur divus tuneļus, un atgaitas ceļam jāsaskan ar izejošo; ja nesaskan, stāvokļa ugunsmūris nomet atbildes, un simptoms ir savienojums, kas atveras un pēc tam mirst. Lielāki izvietojumi to risina ar maršrutēšanas protokolu tuneļu virsū, nevis statiskiem prefiksiem, tas ir vairāk mehānismu, bet novērš minēšanu. Lai ko izvēlētos, atgaitas ceļu rakstiet blakus izejošajam, jo atgaitas puse ir tā, ko neviens netesta.
Tīkls izplata šo risku: vienas vietas saites pārtraukums neizolē pārējās. Tas arī vairo vietas, kur ceļa izvēle var pārsteigt, un lietojumprogrammu sesijas joprojām neiztur ceļa maiņu bez palīdzības.
Neviens risinājums pats nenotur TCP sesiju pārslēgšanās laikā. Ja lietojumprogramma nevar atkārtoti pievienoties, topoloģija nav jūsu problēma.
Izvēlieties pēc izmaiņu izmaksām, tad pārbaudiet maršrutus
Sāciet ar centru, jo tā ir lētākā lieta, kurā kļūdīties, un pievienojiet tiešus tuneļus tiem pāriem, kuru trafiks to attaisno. Šis hibrīds nav nespēja izlemt; tas ir projekts, pie kura lielākā daļa organizāciju nonāk gada laikā. Svarīgi, lai katram tiešajam savienojumam būtu norādīts iemesls un īpašnieks.
Pēc tam pārbaudiet divus zīmējumus, nevis vienu. Parastajam ceļam palaidiet traceroute no katras vietas uz katru pakalpojuma prefiksu un apstipriniet, ka lēcieni atbilst diagrammai. Atteices ceļam izslēdziet vienu tuneli un atkārtojiet, jo maršruts, kas darbojas tikai tad, kad viss darbojas, nav projektēts, tikai konfigurēts.
Turiet abus zīmējumus kopā ar piekļuves matricu un pārskatiet tos, kad tiek pievienota vieta; izmaksas, ko jūs pārvaldāt, ir nākamās izmaiņas izmaksas, nevis pašreizējā attēla elegance.