Hub og eiker mot fullt maskenett: kva VPN-topologi passar for anlegga dine
To tunnelar som verkar er ikkje ein topologi. Samanlikne transitt, åtferd ved feil og endringskostnad før du vel ein hub, eit maskenett eller ein hub med nokre direkte lenkjer.
To filialkontor snakkar saman heile dagen, og tunnelen mellom dei går omvegen om eit datasenter i ein annan region. Kvar førespurnad betaler for den omvegen to gonger, og ingen legg merke til det før filsynchroniseringa byrjar kjennast feil. Det er der topologispørsmålet verkeleg byrjar: ikkje med kva diagram som ser meir robust ut, men med kva trafikkmønster du betaler for. Begge designa verkar, og dei feilar på ulike måtar til ulik kostnad.
Tel partilhøva før noko anna
Med N anlegg treng eit fullt maskenett N gonger N minus ein, delt på to, tunnelar; ein hub treng N. Ved fem anlegg er det ti mot fem, som enno høyrest overkomeleg ut. Ved femten er det 105 mot femten, og skilnaden er ikkje lenger aritmetikk men bemanning.
Kvart av desse høva ber tilstand du må eiga. I IPsec tyder det ein sikkerheitsassosiasjon, ein identitet, ein nøkkel eller sertifikat, død-peer-deteksjon og minst éi rute per fjernt prefiks. I WireGuard tyder det ein offentleg nøkkel og ein AllowedIPs blokk per part, som er billegare per part men kjem heilt utan oppdaging: eit nytt anlegg er ei konfigurasjonsendring på kvart eksisterande anlegg uansett.
La trafikkblandinga avgjere, ikkje teikninga
Viss filialtrafikken mest er førespurnader til ein sentral ERP eller filklynge, er ein hub ikkje eit kompromiss, det er den rette forma: trafikken ville alt dit, og eitt politikkpunkt er lettare å revidere enn eit maskenett av parvise reglar. Eit maskenett tener inn kompleksiteten sin når filialar utvekslar data med kvarandre — replikering mellom to kontor, tale mellom anlegg, ein CAD-del som eit dusin ingeniørar opnar heile dagen.
Dei vanskelege tilfella ligg i mellom, og dei er fleirtalet. Mål før du diskuterer i staden for å gjette frå eit 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 ein skiljedommar, ikkje ein regel. Tre av fire radene som peikar same veg avgjer oftast designet; ei splitting tyder hybrid, som dei fleste modne nettverk endar med å køyre uansett.
Ein hub må få beskjed om å videresende
To fungerande eike-til-hub-tunnelar skaper ikkje eike-til-eike-tilgang. Huben treng IP-videresending slått på, ei rute til kvart eike-nett, ein brannmurregel som tillèt gjennomgangen, og returvegen utrekna; kvar eike treng ei rute for den andre staden sine prefiks. På ein Linux-hub er det net.ipv4.ip_forward=1 pluss ei FORWARD kjede som ikkje stille droppar paret, og på politikkbasert IPsec er det trafikkveljarar som listar det fjerne eike-subnettet i begge endar. strongSwan sine merknader om videresending dekkjer kjernen og brannmursida når det er laget du manglar. Ein billeg test er å sende trafikk frå ei eike til ein teneste på den andre medan du ser på teljarane til huben; ein regel som aldri aukar tyder at rekkjefølgja er feil, ikkje ruta.
Sentral politikk er òg den nyttige delen. Filialar kan få lov til å nå delte tenester utan å nå kvarandre, og den tilgangsmatrisa er verdt å skrive ned eksplisitt. Manglande ruter er eit dårleg substitutt for ein regel nokon kan lese.
Sjå etter halvferdig-versjonen: eike A ruter til eike B gjennom huben, huben ruter begge vegar, og brannmuren til huben tillèt nye tilkoplingar frå A men ikkje frå B. Den første retninga testar fint og den andre heng, noko som ser ut som ein rutefeil og ikkje er det.
Design feilen først, så den normale vegen
Ein einaste hub er ein delt avhengnad og ein transittflaskehals, og redundans er der hub-design oftast går gale. To hubar tyder at kvar eike held to tunnelar, og returvegen må samsvare med den utgåande; gjer han ikkje det, droppar ein tilstandsbrannmur svara og symptomet er ei tilkopling som opnar og så døyr. Større utrullingar løyser dette med ein ruteprotokoll over tunnelane i staden for statiske prefiks, som er meir maskineri men fjernar gjettinga. Uansett kva du vel, skriv returvegen ved sida av den utgåande, for returhalvdelen er den ingen testar.
Eit maskenett spreier den risikoen: at lenkja til ein stad går ned isolerer ikkje dei andre. Det multipliserer òg stadene der ruteval kan overraske deg, og applikasjonsøkter overlever framleis ikkje eit rutebyte utan hjelp.
Ingen av designa held ei TCP-økt i live gjennom ein failover av seg sjølv. Viss applikasjonen ikkje kan kople seg til på nytt, er ikkje topologien problemet ditt.
Vel etter endringskostnad, stadfest så rutene
Start med huben, for det er den billegaste tingen å ta feil om, og legg til direkte tunnelar for para der trafikken rettferdiggjer det. Den hybriden er ikkje eit nederlag i å velje; det er designet dei fleste organisasjonar landar på innan eit år. Det som tel er at kvar direkte lenkje har ein oppgitt grunn og ein eigar.
Stadfest så dei to teikningane i staden for éin. For den normale vegen traceroute frå kvar stad til kvart tenesteprefiks og stadfest at hoppane stemmer med diagrammet. For feilvegen, steng ein tunnel og gjer det om att, for ei rute som berre verkar medan alt er oppe er ikkje designa, berre konfigurert.
Hald begge teikningane saman med tilgangsmatrisa, og ta dei fram att når ein stad blir lagd til; kostnaden du styrer er kostnaden ved neste endring, ikkje elegansen i det noverande bildet.