Hub og eger eller fuldt mesh: hvilken VPN-topologi passer til dine lokationer

To filialkontorer taler sammen hele dagen, og tunnelen mellem dem tager en omvej gennem et datacenter i en anden region. Hver anmodning betaler for den omvej to gange, og ingen bemærker det, før filsynkroniseringen begynder at føles forkert. Det er her, topologispørgsmålet virkelig begynder: ikke med hvilket diagram der ser mere robust ud, men med hvilket trafikmønster du betaler for. Begge design virker, og de fejler på forskellige måder med forskellige omkostninger.

Tæl peer-forbindelserne før noget andet

Med N lokationer kræver et fuldt mesh N gange N minus en, divideret med to, tunneler; en hub kræver N. Ved fem lokationer er det ti mod fem, hvilket stadig lyder overkommeligt. Ved femten er det 105 mod femten, og forskellen er ikke længere aritmetik men bemanding.

Hver af disse forbindelser bærer tilstand, du skal eje. I IPsec betyder det en sikkerhedsassociation, en identitet, en nøgle eller et certifikat, registrering af døde peers og mindst én rute for hvert fjernpræfiks. I WireGuard betyder det en offentlig nøgle og en AllowedIPs blok for hver peer, hvilket er billigere for hver peer, men kommer helt uden opdagelse: en ny lokation er under alle omstændigheder en konfigurationsændring på hver eksisterende.

Lad trafikmikset bestemme, ikke tegningen

Hvis filialtrafikken mest er anmodninger til et centralt ERP- eller filklyngesystem, er en hub ikke et kompromis, det er den rigtige form: trafikken ville allerede derhen, og ét politikpunkt er lettere at revidere end et mesh af parrvis regler. Et mesh fortjener sin kompleksitet, når filialer udveksler data med hinanden — replikering mellem to kontorer, tale mellem lokationer, et delt CAD-drev, som et dusin ingeniører åbner hele dagen.

De akavede tilfælde ligger i mellem, og de er flertallet. Mål, før du diskuterer, i stedet for at gætte ud fra et organisationsdiagram.

Læs tabellen som en afgørelse, ikke som en regel. Tre af fire rækker i én retning afgør normalt designet; en deling betyder en hybrid, som de fleste modne netværk alligevel ender med at køre.

En hub skal have besked om at videresende

To fungerende spoke-til-hub-tunneler skaber ikke spoke-til-spoke-adgang. Huben skal have IP-videresendelse slået til, en rute til hvert spoke-netværk, en firewallregel der tillader transit, og returvejen udregnet; hver spoke skal have en rute til den anden lokations præfikser. På en Linux-hub er det net.ipv4.ip_forward=1 plus FORWARD en kæde, der ikke lydløst dropper parret, og på politikbaseret IPsec er det trafikvælgere, der lister den fjernede spokes undernet i begge ender. Hos strongSwan noterne om videresendelse dækker kernen og firewallsiden, når det er det lag, du mangler. En billig test er at sende trafik fra en spoke til en tjeneste på den anden, mens du ser på hubens tællere; en regel, der aldrig stiger, betyder, at rækkefølgen er forkert, ikke ruten.

Central politik er også den nyttige del. Filialer kan få lov at nå delte tjenester uden at nå hinanden, og den adgangsmatrix er værd at skrive eksplicit ned. Manglende ruter er en dårlig erstatning for en regel, som nogen kan læse.

Hold øje med den halvfærdige version: spoke A ruter til spoke B gennem huben, huben ruter begge veje, og hubens firewall tillader nye forbindelser fra A men ikke fra B. Den første retning tester fint, og den anden hænger, hvilket ligner en rutefejl og ikke er det.

Design fejlen, derefter den normale vej

En enkelt hub er en delt afhængighed og en transitflaskehals, og redundans er der, hvor hub-design normalt går galt. To hubs betyder, at hver spoke holder to tunneler, og returvejen skal stemme med den udgående; når den ikke gør, dropper en stateful firewall svarene, og symptomet er en forbindelse, der åbner og derefter dør. Større udrulninger løser det med en routingprotokol over tunnelerne i stedet for statiske præfikser, hvilket er mere maskineri, men fjerner gætteriet. Uanset hvad du vælger, så skriv returvejen ved siden af den udgående, fordi den tilbagegående halvdel er den, ingen tester.

Et mesh spreder den risiko: at ét steds link går ned isolerer ikke de andre. Det formerer også de steder, hvor vejvalg kan overraske dig, og applikationssessioner overlever stadig ikke et vejskift uden hjælp.

Ingen af designene holder en TCP-session i live gennem et failover af sig selv. Hvis applikationen ikke kan genoprette forbindelsen, er topologien ikke dit problem.

Vælg efter ændringsomkostning, og verificér derefter ruterne

Start med huben, fordi det er den billigere ting at tage fejl af, og tilføj direkte tunneler for de par, hvis trafik retfærdiggør det. Den hybrid er ikke en undladelse af at beslutte; det er det design, de fleste organisationer konvergerer mod inden for et år. Det vigtige er, at hvert direkte link har en angivet grund og en ejer.

Verificér derefter de to tegninger i stedet for én. Til den normale vej, traceroute fra hver lokation til hvert tjenestepræfiks og bekræft, at hopene matcher diagrammet. Til fejlvejen lukker du en tunnel og gentager det, fordi en rute, der kun virker, mens alt er oppe, ikke er designet, kun konfigureret.

Behold begge tegninger sammen med adgangsmatricen, og tag dem op igen, når en lokation tilføjes; den omkostning, du styrer, er omkostningen ved den næste ændring, ikke elegansen i det nuværende billede.