Stjerne eller fullt nett: hvilken VPN-topologi passer for områdene dine
To fungerende tunneler er ikke en topologi. Før du velger et nav, et fullt nett eller et nav med noen direkte lenker, sammenlign transitt, oppførsel ved feil og endringskostnad.
To filialkontorer snakker sammen hele dagen, og tunnelen mellom dem tar en omvei via et datasenter i en annen region. Hver forespørsel betaler for omveien to ganger, og ingen merker det før filsynkroniseringen begynner å føles feil. Det er der topologispørsmålet egentlig begynner: ikke med hvilket diagram som ser mer robust ut, men med hvilket trafikkmønster du betaler for. Begge designene virker, og de feiler på ulike måter med ulik kostnad.
Tell peer-relasjonene først
Med N områder trenger et fullt nett N ganger N minus én, delt på to, tunneler; et nav trenger N. Ved fem områder er det ti mot fem, som fortsatt høres håndterbart ut. Ved femten er det 105 mot femten, og forskjellen er ikke lenger aritmetikk, men bemanning.
Hver av disse relasjonene bærer tilstand du må eie. I IPsec betyr det en sikkerhetsassosiasjon, en identitet, en nøkkel eller sertifikat, deteksjon av døde peers og minst én rute per ekstern prefiks. I WireGuard betyr det en offentlig nøkkel og en AllowedIPs-blokk per peer; billigere per peer, men helt uten oppdagelse: et nytt område er uansett en konfigurasjonsendring på alle eksisterende.
La trafikkblandingen bestemme, ikke tegningen
Hvis filialtrafikken mest er forespørsler til et sentralt ERP- eller filklynge, er et nav ikke et kompromiss, men riktig form: trafikken ville allerede dit, og ett policypunkt er lettere å revidere enn et nett av parvise regler. Et fullt nett fortjener kompleksiteten når filialene utveksler data med hverandre: replikering mellom to kontorer, tale mellom områder, en CAD-deling som et dusin ingeniører åpner hele dagen.
De vanskelige tilfellene ligger imellom, og de er flertallet. Mål før du argumenterer i stedet for å gjette fra et organisasjonskart.
| 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 |
Les tabellen som en avgjører, ikke som en regel. Tre av fire rader i én retning avgjør vanligvis designet, og en deling betyr hybrid, som de fleste modne nettverk ender med å kjøre.
Et nav må få beskjed om å videresende
To fungerende spoke-til-nav-tunneler lager ikke tilgang mellom spokes. Navet trenger IP-videresending aktivert, en rute til hvert spoke-nett, en brannmurregel som tillater transitten og en utregnet returvei; hver spoke trenger en rute til det andre områdets prefikser. På et Linux-nav er det net.ipv4.ip_forward=1 pluss en FORWARD-kjede som ikke stille slipper paret, og i policybasert IPsec er det trafikkvelgere som lister opp fjernspokens subnett i begge ender. strongSwan notatene om videresending dekker kjerne- og brannmursiden når det er det laget du mangler. En billig test er å sende trafikk fra én spoke til en tjeneste på den andre mens du ser på navets tellere; en regel som aldri øker betyr at rekkefølgen er feil, ikke ruten.
Sentral policy er også den nyttige delen. Filialer kan tillates å nå delte tjenester uten å nå hverandre, og den tilgangsmatrisen er verdt å skrive ned eksplisitt. Manglende ruter er en dårlig erstatning for en regel noen kan lese.
Se opp for den halvferdige versjonen: spoke A ruter til spoke B via navet, navet ruter begge veier, og navets brannmur tillater nye tilkoblinger fra A men ikke fra B. Den første retningen tester fint og den andre henger, noe som ser ut som en rutingsfeil og ikke er det.
Design feilen først, deretter den normale veien
Ett enkelt nav er en delt avhengighet og en transittflaskehals, og redundans er der navdesign vanligvis går galt. To nav betyr at hver spoke holder to tunneler, og returveien må stemme med den utgående; når den ikke gjør det, slipper en stateful brannmur svarene og symptomet er en tilkobling som åpnes og deretter dør. Større utrullinger løser det med en rutingsprotokoll over tunnelene i stedet for statiske prefikser, som er mer maskineri men fjerner gjettingen. Uansett hva du velger, skriv returveien ved siden av den utgående, for returhalvdelen er den ingen tester.
Et fullt nett sprer den risikoen: en lenke som går ned isolerer ikke de andre. Det multipliserer også stedene der veivalget kan overraske deg, og applikasjonsøkter overlever fortsatt ikke et veibytte uten hjelp.
Ingen av designene holder en TCP-økt i live gjennom en failover på egen hånd. Hvis applikasjonen ikke kan koble til på nytt, er ikke topologi problemet ditt.
Velg etter endringskostnad, og verifiser deretter rutene
Start med navet, fordi det er det billigere å ta feil om, og legg til direkte tunneler for parene der trafikken rettferdiggjør det. Den hybriden er ikke et mislykket valg; det er designet de fleste organisasjoner lander på innen et år. Det som betyr noe er at hver direkte lenke har en oppgitt grunn og en eier.
Verifiser deretter de to tegningene i stedet for én. For den normale veien, kjør traceroute fra hvert område til hver tjenesteprefiks og bekreft at hoppene stemmer med diagrammet. For feilveien, steng én tunnel og gjenta, for en rute som bare virker mens alt er oppe er ikke designet, bare konfigurert.
Behold begge tegningene sammen med tilgangsmatrisen, og gå gjennom dem når et område legges til; kostnaden du styrer er kostnaden av neste endring, ikke elegansen i det nåværende bildet.