Hviezda alebo plná sieť: ktorá topológia VPN sa hodí pre vaše lokality
Dva funkčné tunely ešte nie sú topológia. Predtým, ako vyberiete centrum, sieť alebo centrum s niekoľkými priamymi spojmi, porovnajte tranzit, správanie pri výpadku a náklady na zmenu.
Dve pobočky sa celý deň rozprávajú medzi sebou a tunel medzi nimi obchádza cez dátové centrum v inom regióne. Každá požiadavka platí za tú obchádzku dvakrát a nikto si to nevšimne, kým synchronizácia súborov nezačne pôsobiť nesprávne. Tu sa otázka topológie naozaj začína: nie tým, ktorý diagram vyzerá odolnejšie, ale tým, za aký vzor prevádzky platíte. Oba návrhy fungujú a oba zlyhávajú rôznymi spôsobmi s rôznymi nákladmi.
Najprv spočítajte vzťahy medzi uzlami
Pri N lokalitách potrebuje plná sieť N krát N mínus jedna, delené dvoma, tunelov; centrum potrebuje N. Pri piatich lokalitách je to desať proti piatim, čo stále znie zvládnuteľne. Pri pätnástich je to 105 proti pätnástim a rozdiel už nie je aritmetický, ale personálny.
Každý z tých vzťahov nesie stav, ktorý musíte spravovať. V IPsec to znamená bezpečnostnú asociáciu, identitu, kľúč alebo certifikát, detekciu mŕtveho partnera a aspoň jednu trasu na každý vzdialený prefix. Vo WireGuard to znamená verejný kľúč a blok AllowedIPs pre každého partnera; na partnera lacnejšie, ale úplne bez objavovania: nová lokalita je tak či tak zmena konfigurácie na všetkých existujúcich.
Nech rozhoduje zmes prevádzky, nie kresba
Ak je prevádzka pobočiek hlavne požiadavkami na centrálny ERP alebo súborový klaster, centrum nie je kompromis, ale správny tvar: prevádzka tam už chcela ísť a jeden politický bod sa audituje ľahšie ako sieť párových pravidiel. Sieť si svoju zložitosť zaslúži vtedy, keď si pobočky vymieňajú dáta navzájom: replikácia medzi dvoma kanceláriami, hlas medzi lokalitami, zdieľanie CAD, ktoré tucet inženierov otvára celý deň.
Nepohodlné prípady sú v strede a je ich väčšina. Merajte skôr, ako budete argumentovať, namiesto hádania z organizačnej schémy.
| 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 |
Čítajte tabuľku ako rozhodcu, nie ako pravidlo. Tri zo štyroch riadkov jedným smerom zvyčajne rozhodnú návrh a rozdelenie znamená hybrid, ktorý väčšina zrelých sietí napokon prevádzkuje.
Centru treba povedať, aby preposielalo
Dva funkčné tunely pobočka-centrum ešte nevytvárajú prístup medzi pobočkami. Centrum potrebuje zapnuté preposielanie IP, trasu do každej siete pobočky, pravidlo firewallu, ktoré tranzit povoľuje, a vyriešenú spätnú cestu; každá pobočka potrebuje trasu do prefixov druhej lokality. Na Linuxovom centre je to net.ipv4.ip_forward=1 plus reťazec FORWARD, ktorý dvojicu potichu nezahodí, a v IPsec postavenom na politikách sú to selektory prevádzky, ktoré na oboch koncoch uvádzajú podsieti vzdialenej pobočky. strongSwan poznámky k preposielaniu pokrývajú stranu jadra a firewallu, keď je to práve tá vrstva, ktorá vám chýba. Lacný test: pošlite prevádzku z jednej pobočky na službu v druhej a sledujte počítadlá centra; pravidlo, ktoré nikdy nenarastie, znamená, že nesprávne je poradie, nie trasa.
Centrálna politika je tiež užitočná časť. Pobočkám možno povoliť dosiahnuť spoločné služby bez toho, aby dosiahli jedna druhú, a tú maticu prístupu sa oplatí výslovne zapísať. Chýbajúce trasy sú slabou náhradou za pravidlo, ktoré niekto dokáže prečítať.
Pozor na naplno ukončenú verziu: pobočka A smeruje do pobočky B cez centrum, centrum smeruje oboma smermi a firewall centra povoľuje nové spojenia z A, ale nie z B. Prvý smer sa testuje dobre a druhý visí, čo vyzerá ako chyba smerovania a nie je.
Najprv navrhnite výpadok, potom normálnu cestu
Jediné centrum je spoločná závislosť a tranzitné hrdlo a redundancia je miesto, kde návrhy s centrom zvyčajne zlyhávajú. Dve centrá znamenajú, že každá pobočka drží dva tunely a spätná cesta sa musí zhodovať s odchádzajúcou; keď sa nezhoduje, stavový firewall zahodí odpovede a príznakom je spojenie, ktoré sa otvorí a potom zomrie. Väčšie nasadenia to riešia smerovacím protokolom nad tunelmi namiesto statických prefixov, čo je viac mechaniky, ale odstraňuje hádanie. Čokoľvek vyberiete, zapíšte spätnú cestu vedľa odchádzajúcej, pretože spätná polovica je tá, ktorú nikto netestuje.
Sieť to riziko rozprestiera: výpadok spoja jednej lokality neizoluje ostatné. Násobí však aj miesta, kde vás výber cesty môže prekvapiť, a relácie aplikácií stále neprežijú zmenu cesty bez pomoci.
Ani jeden návrh sám neudrží TCP reláciu počas prepnutia. Ak sa aplikácia nevie znovu pripojiť, topológia nie je váš problém.
Vyberajte podľa nákladov na zmenu, potom overte trasy
Začnite centrom, pretože je to lacnejšia vec, v ktorej sa dá pomýliť, a pridajte priame tunely pre dvojice, ktorých prevádzka to odôvodňuje. Ten hybrid nie je zlyhanie pri rozhodovaní; je to návrh, na ktorom sa väčšina organizácií ustáli do roka. Dôležité je, aby každé priame spojenie malo uvedený dôvod a vlastníka.
Potom overte dva výkresy namiesto jedného. Pre normálnu cestu spustite traceroute z každej lokality na každý prefix služby a potvrďte, že skoky zodpovedajú diagramu. Pre cestu výpadku vypnite jeden tunel a zopakujte to, pretože trasa, ktorá funguje len vtedy, keď všetko beží, nebola navrhnutá, len nastavená.
Uchovajte oba výkresy s maticou prístupu a vráťte sa k nim, keď pribudne lokalita; náklady, ktoré riadite, sú náklady nasledujúcej zmeny, nie elegancia súčasného obrázka.