Zvezda ali polna mreža: katera topologija VPN ustreza vašim lokacijam
Dva delujoča tunela še nista topologija. Preden izberete zvezdišče, mrežo ali zvezdišče z nekaj neposrednimi povezavami, primerjajte tranzit, vedenje ob izpadu in stroške spremembe.
Dve podružnici se ves dan pogovarjata med seboj, tunel med njima pa se izogiba prek podatkovnega centra v drugi regiji. Vsaka zahteva plača to obvoznico dvakrat in nihče tega ne opazi, dokler sinhronizacija datotek ne začne delovati čudno. Tu se vprašanje topologije res začne: ne s tem, kateri diagram je videti bolj odporen, ampak s tem, za kateri vzorec prometa plačujete. Oba načrta delujeta in oba odpovedujeta na različne načine z različnimi stroški.
Najprej preštejte razmerja med vozlišči
Pri N lokacijah polna mreža potrebuje N krat N minus ena, deljeno z dva, tunelov; zvezdišče potrebuje N. Pri petih lokacijah je to deset proti pet, kar je še videti obvladljivo. Pri petnajstih je to 105 proti petnajst, in razlika ni več aritmetična, ampak kadrovska.
Vsako od teh razmerij nosi stanje, ki ga morate upravljati. Pri IPsec to pomeni varnostno asociacijo, identiteto, ključ ali potrdilo, zaznavanje mrtvega partnerja in vsaj eno pot na vsak oddaljeni prefiks. Pri WireGuard to pomeni javni ključ in blok AllowedIPs na partnerja; na partnerja ceneje, a povsem brez odkrivanja: nova lokacija je v vsakem primeru sprememba konfiguracije na vseh obstoječih.
Naj odloča prometna slika, ne risba
Če je promet podružnic večinoma zahteve do osrednjega ERP ali datotečnega gruče, zvezdišče ni kompromis, ampak pravilna oblika: promet je že hotel tja, ena politična točka pa se revidira lažje kot mreža parnih pravil. Mreža si svojo zapletenost zasluži, ko si podružnice izmenjujejo podatke med seboj: replikacija med dvema pisarnama, glas med lokacijami, souporaba CAD, ki jo ducat inženirjev odpira ves dan.
Nerodni primeri so vmes in so večina. Merite, preden se prepirate, namesto da ugibate iz organizacijske sheme.
| 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 |
Tabelo berite kot razsodnika, ne kot pravilo. Tri od štirih vrstic v eno smer običajno odločijo načrt, delitev pa pomeni hibrid, kar večina zrelih omrežij na koncu tudi uporablja.
Zvezdišču je treba povedati, naj posreduje
Dva delujoča tunela podružnica-zvezdišče še ne ustvarita dostopa med podružnicami. Zvezdišče potrebuje omogočeno posredovanje IP, pot do vsakega omrežja podružnice, požarnozidno pravilo, ki dovoli tranzit, in izračunano povratno pot; vsaka podružnica potrebuje pot do prefiksov druge lokacije. Na Linuxovem zvezdišču je to net.ipv4.ip_forward=1 in veriga FORWARD, ki para tiho ne zavrže, v IPsec na osnovi politik pa so to izbirniki prometa, ki na obeh koncih navajajo podomrežje oddaljene podružnice. strongSwan opombe o posredovanju pokrivajo stran jedra in požarnega zidu, ko je prav ta plast tista, ki vam manjka. Poceni preizkus: pošljite promet iz ene podružnice v storitev v drugi in opazujte števce zvezdišča; pravilo, ki nikoli ne naraste, pomeni, da je vrstni red napačen, ne pot.
Osrednja politika je tudi koristen del. Podružnicam lahko dovolite doseganje skupnih storitev, ne da bi dosegale druga drugo, in to matriko dostopa je vredno izrecno zapisati. Manjkajoče poti so slaba zamenjava za pravilo, ki ga nekdo lahko prebere.
Pazite na napol dokončano različico: podružnica A usmerja do podružnice B prek zvezdišča, zvezdišče usmerja v obe smeri, požarni zid zvezdišča pa dovoli nove povezave iz A, ne pa iz B. Prva smer se testira dobro, druga obvisi, kar je videti kot napaka usmerjanja in ni.
Najprej načrtujte izpad, nato običajno pot
Eno zvezdišče je skupna odvisnost in tranzitno grlo, redundanca pa je mesto, kjer načrti z zvezdiščem običajno zgrešijo. Dve zvezdišči pomenita, da vsaka podružnica drži dva tunela, povratna pot pa se mora ujemati z odhodno; ko se ne, stanjski požarni zid zavrže odgovore in simptom je povezava, ki se odpre in nato umre. Večje postavitve to rešujejo s protokolom usmerjanja nad tuneli namesto statičnih prefiksov, kar je več mehanike, a odstrani ugibanje. Kar koli izberete, povratno pot zapišite poleg odhodne, ker je povratna polovica tista, ki je nihče ne preizkusi.
Mreža to tveganje razporedi: izpad povezave ene lokacije ne izolira drugih. Prav tako pomnoži mesta, kjer vas izbira poti lahko preseneti, seje aplikacij pa še vedno ne preživijo spremembe poti brez pomoči.
Noben načrt sam ne ohrani seje TCP med preklopom. Če se aplikacija ne more znova povezati, topologija ni vaš problem.
Izberite po stroških spremembe, nato preverite poti
Začnite z zvezdiščem, ker je ceneje zmotiti se pri njem, in dodajte neposredne tunele za pare, katerih promet to upravičuje. Ta hibrid ni neuspeh pri odločanju; to je načrt, h kateremu se večina organizacij vrne v enem letu. Pomembno je, da ima vsaka neposredna povezava naveden razlog in lastnika.
Nato preverite dve risbi, ne ene. Za običajno pot zaženite traceroute z vsake lokacije na vsak prefiks storitve in potrdite, da se skoki ujemajo z diagramom. Za pot izpada izklopite en tunel in ponovite, ker pot, ki deluje le, dokler vse deluje, ni bila načrtovana, le nastavljena.
Hranite obe risbi z matriko dostopa in se k njima vrnite, ko je dodana lokacija; stroški, ki jih upravljate, so stroški naslednje spremembe, ne eleganca trenutne slike.