Hub-en-spoke of volledige mesh: watter VPN-topologie pas by jou persele

Twee takkantore praat heeldag met mekaar, en die tonnel tussen hulle loop via 'n datasentrum in 'n ander streek. Elke versoek betaal twee keer vir daardie ompad, en niemand merk dit totdat die lêersinkronisering verkeerd begin voel nie. Dit is waar die topologievraag werklik begin: nie by watter diagram veerkragtiger lyk nie, maar by watter verkeerspatroon jy betaal. Albei ontwerpe werk, en hulle faal op verskillende maniere teen verskillende koste.

Tel die portverhoudings voordat jy enigiets anders doen

Met N persele het 'n volledige mesh N maal N minus een, gedeel deur twee, tonnels nodig; 'n hub het N nodig. By vyf persele is dit tien teenoor vyf, wat nog haalbaar klink. By vyftien is dit 105 teenoor vyftien, en die verskil is nie meer rekenkunde nie, maar personeel.

Elkeen van daardie verhoudings dra toestand wat jy moet besit. In IPsec beteken dit 'n sekuriteitsassosiasie, 'n identiteit, 'n sleutel of sertifikaat, dooieportopsporing en ten minste een roete per afgeleë voorvoegsel. In WireGuard beteken dit 'n publieke sleutel en 'n AllowedIPs blok per port, wat per port goedkoper is, maar heeltemal sonder ontdekking kom: 'n nuwe perseel is in elk geval 'n konfigurasieverandering op elke bestaande een.

Laat die verkeersamestelling besluit, nie die tekening nie

As takverkeer meestal versoeke aan 'n sentrale ERP of lêergroep is, is 'n hub nie 'n kompromie nie, dit is die regte vorm: die verkeer wou al daarheen gaan, en een beleidspunt is makliker om te oudit as 'n mesh van paargewyse reëls. 'n Mesh verdien sy kompleksiteit wanneer takke data met mekaar uitruil — replikasie tussen twee kantore, stem tussen persele, 'n CAD-deel wat 'n dosyn ingenieurs heeldag oopmaak.

Die ongemaklike gevalle lê tussenin, en dit is die meerderheid. Meet voordat jy argumenteer eerder as om uit 'n organisasiediagram te raai.

Lees die tabel as 'n beslisser, nie as 'n reël nie. Drie van vier rye wat een kant toe wys, besleg die ontwerp gewoonlik; 'n verdeling beteken 'n hibried, wat die meeste volwasse netwerke in elk geval uiteindelik gebruik.

'n Hub moet aangesê word om te stuur

Twee werkende spoke-na-hub-tonnels skep nie toegang tussen spoke nie. Die hub benodig IP-aansturing geaktiveer, 'n roete na elke spoke-netwerk, 'n firewallreël wat die deurvoer toelaat, en die terugpad uitgewerk; elke spoke het 'n roete vir die ander perseel se voorvoegsels nodig. Op 'n Linux-hub is dit net.ipv4.ip_forward=1 plus 'n FORWARD ketting wat nie die paar stilweg laat val nie, en op beleidsgebaseerde IPsec is dit verkeerskeurders wat die afgeleë spoke-subnet aan beide kante lys. By strongSwan aansturingsnotas dek die kern- en firewallsy wanneer dit die laag is wat jy mis. 'n Goedkoop toets is om verkeer van een spoke na 'n diens op die ander te stuur terwyl jy die hub se tellers dophou; 'n reël wat nooit toeneem nie, beteken die volgorde is verkeerd, nie die roete nie.

Sentrale beleid is ook die nuttige deel. Takke kan toegelaat word om gedeelde dienste te bereik sonder om mekaar te bereik, en daardie toegangsmatriks is die moeite werd om eksplisiet neer te skryf. Ontbrekende roetes is 'n swak plaasvervanger vir 'n reël wat iemand kan lees.

Pas op vir die halfvoltooide weergawe: spoke A stuur na spoke B deur die hub, die hub stuur beide kante toe, en die hub se firewall laat nuwe verbindings van A toe maar nie van B nie. Die eerste rigting toets goed en die tweede hang, wat soos 'n roetefout lyk en nie een is nie.

Ontwerp eers die faling, dan die normale pad

'n Enkele hub is 'n gedeelde afhanklikheid en 'n deurvoerknelpunt, en oortolligheid is waar hub-ontwerpe gewoonlik verkeerd loop. Twee hubs beteken elke spoke hou twee tonnels, en die terugpad moet met die uitgaande een ooreenstem; wanneer dit nie doen nie, laat 'n staatvolle firewall die antwoorde val en die simptoom is 'n verbinding wat oopgaan en dan sterf. Groter ontplooiings los dit met 'n roeteringsprotokol oor die tonnels eerder as statiese voorvoegsels, wat meer masjinerie is maar die raaiery verwyder. Wat jy ook al kies, skryf die terugpad langs die uitgaande een, want die terughelfte is die een wat niemand toets nie.

'n Mesh versprei daardie risiko: een perseel se skakel wat afgaan, isoleer nie die ander nie. Dit vermenigvuldig ook die plekke waar padkeuse jou kan verras, en toepassingsessies oorleef steeds nie 'n padverandering sonder hulp nie.

Geen van die twee ontwerpe hou 'n TCP-sessie uit sy eie oor 'n oorskakeling aan die lewe nie. As die toepassing nie kan herverbind nie, is topologie nie jou probleem nie.

Kies volgens veranderingskoste, en verifieer dan die roetes

Begin met die hub, want dit is die goedkoopste ding om verkeerd oor te wees, en voeg direkte tonnels by vir die pare wie se verkeer dit regverdig. Daardie hibried is nie 'n versuim om te besluit nie; dit is die ontwerp waarop die meeste organisasies binne 'n jaar saamkom. Wat saak maak, is dat elke direkte skakel 'n genoemde rede en 'n eienaar het.

Verifieer dan die twee tekeninge eerder as een. Vir die normale pad, traceroute van elke perseel na elke diensvoorvoegsel en bevestig dat die spronge by die diagram pas. Vir die foutpad, sluit een tonnel en herhaal dit, want 'n roete wat net werk terwyl alles op is, is nie ontwerp nie, net gekonfigureer.

Hou albei tekeninge by die toegangsmatriks, en hersien hulle wanneer 'n perseel bygevoeg word; die koste wat jy bestuur is die koste van die volgende verandering, nie die elegansie van die huidige prentjie nie.