Žvaigždė ar visiškas tinklas: kuri VPN topologija tinka jūsų vietoms

Du filialai visą dieną kalbasi tarpusavyje, o tunelis tarp jų eina per kitame regione esantį duomenų centrą. Kiekviena užklausa už tą apylanką moka du kartus, ir niekas nepastebi, kol failų sinchronizavimas nepradeda atrodyti keistai. Čia ir prasideda topologijos klausimas: ne kuri schema atrodo atsparesnė, o už kokį srauto modelį jūs mokate. Abu sprendimai veikia, ir abu žlunga skirtingais būdais bei skirtingomis kainomis.

Pirmiausia suskaičiuokite ryšių tarp mazgų skaičių

Turint N vietų, visiškam tinklui reikia N padauginto iš N minus vienas, padalyto iš dviejų, tunelių; centrui reikia N. Penkiose vietose tai dešimt prieš penkis, kas dar atrodo įveikiama. Penkiolikoje tai 105 prieš penkiolika, ir skirtumas jau ne aritmetinis, o personalo.

Kiekvienas iš tų ryšių neša būseną, kurią turite prižiūrėti. IPsec tai reiškia saugumo asociaciją, tapatybę, raktą arba sertifikatą, negyvo mazgo aptikimą ir bent vieną maršrutą kiekvienam nuotoliniam prefiksui. WireGuard tai reiškia viešą raktą ir AllowedIPs bloką kiekvienam mazgui; vienam mazgui pigiau, bet visiškai nėra aptikimo: nauja vieta bet kuriuo atveju reiškia konfigūracijos pakeitimą visose esamose.

Tegul sprendžia srauto sudėtis, o ne brėžinys

Jei filialų srautas daugiausia yra užklausos į centrinę ERP ar failų klasterį, centras nėra kompromisas, o teisinga forma: srautas jau norėjo ten eiti, o vienas politikos taškas yra lengviau audituojamas nei porinių taisyklių tinklas. Tinklas savo sudėtingumą pateisina tada, kai filialai keičiasi duomenimis tarpusavyje: replikacija tarp dviejų biurų, balsas tarp vietų, CAD failų saugykla, kurią dešimtys inžinierių atidaro visą dieną.

Nepatogūs atvejai yra per vidurį, ir jų dauguma. Matuokite prieš ginčydamiesi, o ne spėkite iš organizacijos schemos.

Lentelę skaitykite kaip lemiamą veiksnį, o ne taisyklę. Trys iš keturių eilučių viena kryptimi paprastai nusprendžia sprendimą, o pasiskirstymas reiškia hibridą, kurį dauguma brandžių tinklų galiausiai ir naudoja.

Centrui reikia pasakyti, kad jis persiųstų

Du veikiantys filialo-centro tuneliai dar nesukuria prieigos tarp filialų. Centrui reikia įjungto IP persiuntimo, maršruto į kiekvieną filialo tinklą, ugniasienės taisyklės, leidžiančios tranzitą, ir apskaičiuoto grįžimo kelio; kiekvienam filialui reikia maršruto į kitos vietos prefiksus. Linux centre tai net.ipv4.ip_forward=1 ir FORWARD grandinė, kuri tyliai nemeta poros, o politikos pagrindu veikiančiame IPsec tai srauto selektoriai, išvardijantys nuotolinio filialo potinklį abiejuose galuose. strongSwan persiuntimo pastabos apima branduolio ir ugniasienės pusę, kai trūksta būtent to sluoksnio. Pigus testas: siųskite srautą iš vieno filialo į paslaugą kitame ir stebėkite centro skaitiklius; taisyklė, kuri niekada nepadidėja, reiškia, kad neteisinga tvarka, o ne maršrutas.

Centrinė politika taip pat yra naudinga dalis. Filialams galima leisti pasiekti bendras paslaugas nepasiekiant vienas kito, ir tą prieigos matricą verta užrašyti aiškiai. Trūkstami maršrutai yra prastas pakaitalas taisyklės, kurią žmogus gali perskaityti.

Saugokitės pusiau atliktos versijos: filialas A maršrutizuoja į filialą B per centrą, centras maršrutizuoja į abi puses, o centro ugniasienė leidžia naujus ryšius iš A, bet ne iš B. Pirmoji kryptis testuojasi gerai, antroji stringa, kas atrodo kaip maršrutizavimo gedimas, bet nėra.

Pirmiausia suprojektuokite gedimą, tada įprastą kelią

Vienas centras yra bendra priklausomybė ir tranzito kliūtis, o dubliavimas yra vieta, kur centro sprendimai dažniausiai suklysta. Du centrai reiškia, kad kiekvienas filialas laiko du tunelius, o grįžimo kelias turi sutapti su išėjimo keliu; kai nesutampa, būsenos ugniasienė numeta atsakymus, o simptomas yra ryšys, kuris atsidaro ir paskui miršta. Didesni diegimai tai sprendžia maršrutizavimo protokolu per tunelius, o ne statiniais prefiksais, tai daugiau mechanizmų, bet pašalina spėliojimą. Kad ir ką rinktumėtės, grįžimo kelią rašykite šalia išėjimo, nes grįžimo pusė yra ta, kurios niekas netikrina.

Tinklas paskirsto tą riziką: vienos vietos ryšio nutrūkimas neišskiria kitų. Jis taip pat padaugina vietas, kur kelio parinkimas gali nustebinti, o programų sesijos vis tiek neišgyvena kelio pakeitimo be pagalbos.

Nė vienas sprendimas pats neišlaiko TCP sesijos per perjungimą. Jei programa negali prisijungti iš naujo, topologija nėra jūsų problema.

Rinkitės pagal pakeitimo kainą, tada patikrinkite maršrutus

Pradėkite nuo centro, nes tai pigesnis dalykas, dėl kurio galima suklysti, ir pridėkite tiesioginius tunelius toms poroms, kurių srautas tai pateisina. Tas hibridas nėra negebėjimas apsispręsti; tai sprendimas, prie kurio dauguma organizacijų sugrįžta per metus. Svarbu tai, kad kiekvienas tiesioginis ryšys turi nurodytą priežastį ir savininką.

Tada patikrinkite du brėžinius, o ne vieną. Įprastam keliui paleiskite traceroute iš kiekvienos vietos į kiekvieną paslaugos prefiksą ir patvirtinkite, kad šuoliai atitinka diagramą. Gedimo keliui išjunkite vieną tunelį ir pakartokite, nes maršrutas, kuris veikia tik tada, kai viskas veikia, nebuvo suprojektuotas, tik sukonfigūruotas.

Laikykite abu brėžinius su prieigos matrica ir peržiūrėkite juos, kai pridedama vieta; kaina, kurią valdote, yra kito pakeitimo kaina, o ne dabartinio paveikslo elegancija.