Hub i spoke o malla completa: quina topologia VPN encaixa amb els vostres llocs

Dues oficines branca es parlen tot el dia, i el túnel entre elles fa un desviament per un centre de dades d'una altra regió. Cada petició paga aquest desviament dues vegades, i ningú no ho nota fins que la sincronització de fitxers comença a semblar estranya. Aquí és on comença de veritat la pregunta de la topologia: no amb quin diagrama sembla més resilient, sinó amb quin patró de trànsit esteu pagant. Tots dos dissenys funcionen, i fallen de maneres diferents amb costos diferents.

Compteu les relacions entre parells abans que res

Amb N llocs, una malla completa necessita N per N menys un, dividit entre dos, túnels; un hub en necessita N. Amb cinc llocs són deu contra cinc, cosa que encara sembla assumible. Amb quinze són 105 contra quinze, i la diferència ja no és aritmètica sinó de personal.

Cadascuna d'aquestes relacions porta estat del qual heu de ser propietaris. En IPsec això vol dir una associació de seguretat, una identitat, una clau o certificat, detecció de parell mort i com a mínim una ruta per cada prefix remot. En WireGuard vol dir una clau pública i un AllowedIPs bloc per parell, que és més barat per parell però arriba del tot sense descobriment: un lloc nou és un canvi de configuració a cada lloc existent igualment.

Deixeu que decideixi la barreja de trànsit, no el dibuix

Si el trànsit de les branques és sobretot peticions a un ERP central o a un clúster de fitxers, un hub no és un compromís, és la forma correcta: el trànsit ja volia anar allà, i un sol punt de política és més fàcil d'auditar que una malla de regles per parells. Una malla guanya la seva complexitat quan les branques intercanvien dades entre elles — replicació entre dues oficines, veu entre llocs, un recurs CAD compartit que una dotzena d'enginyers obren tot el dia.

Els casos incòmodes queden al mig, i són la majoria. Mesureu abans de discutir en lloc d'endevinar a partir d'un organigrama.

Llegiu la taula com un desempat, no com una regla. Tres de quatre files en una direcció normalment resolen el disseny; una divisió vol dir híbrid, que és el que la majoria de xarxes madures acaben fent servir de totes maneres.

Cal dir al hub que reenviï

Dos túnels spoke-hub que funcionen no creen accés spoke-spoke. El hub necessita el reenviament IP activat, una ruta cap a cada xarxa spoke, una regla de tallafocs que permeti el trànsit i el camí de tornada resolt; cada spoke necessita una ruta per als prefixos de l'altre lloc. En un hub Linux això és net.ipv4.ip_forward=1 més FORWARD una cadena que no descarta el parell en silenci, i en IPsec basat en polítiques són selectors de trànsit que llisten la subxarxa spoke remota als dos extrems. A strongSwan, les notes de reenviament cobreixen la part del nucli i del tallafocs quan és aquesta la capa que us falta. Una prova barata és enviar trànsit d'un spoke a un servei de l'altre mentre observeu els comptadors del hub; una regla que mai no augmenta vol dir que l'ordre és equivocat, no la ruta.

La política central també és la part útil. Es pot permetre que les branques arribin a serveis compartits sense arribar-se entre elles, i aquesta matriu d'accés val la pena escriure-la explícitament. Les rutes que falten són un mal substitut d'una regla que algú pugui llegir.

Vigileu la versió a mig fer: el spoke A encamina cap al spoke B a través del hub, el hub encamina en tots dos sentits, i el tallafocs del hub permet connexions noves des d'A però no des de B. La primera direcció es prova bé i la segona es penja, cosa que sembla una fallada d'encaminament i no ho és.

Dissenyueu la fallada, després el camí normal

Un sol hub és una dependència compartida i un coll d'ampolla de trànsit, i la redundància és on els dissenys amb hub solen fallar. Dos hubs vol dir que cada spoke manté dos túnels, i el camí de tornada ha de coincidir amb el de sortida; quan no ho fa, un tallafocs amb estat descarta les respostes i el símptoma és una connexió que s'obre i després mor. Els desplegaments grans ho resolen amb un protocol d'encaminament sobre els túnels en lloc de prefixos estàtics, que és més maquinària però elimina les endevinalles. Trieu el que trieu, escriviu el camí de tornada al costat del de sortida, perquè la meitat de tornada és la que ningú no prova.

Una malla reparteix aquest risc: que caigui l'enllaç d'un lloc no aïlla els altres. També multiplica els llocs on la selecció de camí us pot sorprendre, i les sessions d'aplicació encara no sobreviuen a un canvi de camí sense ajuda.

Cap dels dos dissenys manté una sessió TCP viva a través d'un basculament per si sol. Si l'aplicació no pot tornar a connectar-se, la topologia no és el vostre problema.

Trieu pel cost del canvi, després verifiqueu les rutes

Comenceu pel hub, perquè és la cosa més barata d'equivocar-se, i afegiu túnels directes per als parells el trànsit dels quals ho justifica. Aquest híbrid no és una incapacitat de decidir; és el disseny amb què la majoria d'organitzacions convergeixen dins d'un any. L'important és que cada enllaç directe tingui una raó declarada i un responsable.

Després verifiqueu els dos dibuixos en lloc d'un. Per al camí normal, traceroute des de cada lloc fins a cada prefix de servei i confirmeu que els salts coincideixen amb el diagrama. Per al camí de fallada, atureu un túnel i repetiu-ho, perquè una ruta que només funciona mentre tot està en marxa no s'ha dissenyat, només s'ha configurat.

Conserveu tots dos dibuixos amb la matriu d'accés, i reviseu-los quan s'afegeixi un lloc; el cost que gestioneu és el cost del proper canvi, no l'elegància de la imatge actual.