Planifiqueu els rangs d’adreces VPN privats abans que els llocs col·lideixin

Dos llocs que tots dos fan servir 192.168.1.0/24 poden arribar a internet i, tot i així, no arribar-se l’un a l’altre. La passarel·la no genera cap error; instal·la una ruta per a aquest prefix i envia cada paquet al parell que el va reclamar primer. Res de l’handshake, la llista de xifratges ni la mètrica de la interfície no diu quin parell s’equivoca. La planificació d’adreces és la part del disseny que ho resol abans que ningú es connecti.

Inventarieu cada espai que ha de ser accessible

Anoteu els rangs que s’han d’encaminar, no només els que esteu configurant. Això vol dir LAN dels llocs, pools de clients VPN, subxarxes al núvol, xarxes de gestió i fora de banda, segments de laboratori i les xarxes des de les quals els usuaris es connecten habitualment des de casa. Un router de consum que arriba com a 192.168.1.0/24 no és hipotètic, i el mateix prefix apareix en hotels i recintes firals. L’inventari és una taula de prefix, propietari i propòsit, i és l’únic artefacte que evita que el mateix rang es lliuri dues vegades.

Afegiu els prefixos que espereu durant l’any vinent, perquè un pla que només cobreix avui falla al primer lloc nou. Marqueu cada fila amb qui el pot canviar, no només amb qui en és propietari.

La reutilització és el que ho fa difícil: l’espai privat és finit i cada organització tracta 10.0.0.0/8 com a seu. Un pla no pot prometre que cap LAN de convidats futura caigui en un dels vostres prefixos, així que el disseny ha de dir què passa quan ho fa. Dues regles fan la major part de la feina. Poseu els pools de clients en un sol bloc contigu que pugueu resumir i no assigneu mai un rang que un altre equip ja encamina. Tota la resta és un registre que algú manté actualitzat.

Per què una superposició derrota la taula d’encaminament

Una ruta és un prefix més un següent salt, i el reenviament tria el prefix coincident més llarg. Quan dos parells reclamen tots dos 192.168.1.0/24, la taula en té una sola entrada, així que el trànsit dels dos llocs surt pel mateix túnel. El segon lloc no està mal configurat; és inabastable perquè el primer respon per les mateixes adreces. Cap mètrica no els pot separar, perquè la coincidència passa abans que es consultin les mètriques.

La fallada és asimètrica i fàcil de malinterpretar. Els hosts del lloc A arriben a la passarel·la i a alguns serveis, mentre que els hosts del lloc B no responen res, i el registre mostra un túnel sa en totes dues direccions. Aquest patró és una col·lisió d’adreces i no una fallada d’autenticació o del tallafoc, i confirmar-ho requereix un abocament de la taula comparat amb l’inventari.

Dimensioneu deliberadament el pool de clients i els rangs dels llocs

Un pool de clients VPN és un rang que la passarel·la lliura una adreça a la vegada, així que la seva mida limita la concurrència. Un /24 té 254 adreces utilitzables, cosa generosa per a un equip petit i justa per a una branca que executa contenidors; un /22 no costa res extra dins de l’espai privat i elimina la discussió. Manteniu el pool contigu i allunyat de cada LAN de lloc, perquè la ruta resumida cap als clients no s’empassi mai un lloc. Reserveu el rang fins i tot mentre el pool és buit, perquè un rang no escrit és el que assignarà el proper enginyer.

Els llocs reben rangs dimensionats per als hosts esperats més el creixement, alineats en una frontera que se sumaritza netament. Els buits deliberats entre assignacions no costen res i compren espai per agregar més endavant.

Després comproveu la direcció que la gent oblida: el camí de tornada. Cada router de lloc necessita una ruta cap al pool de clients, i el concentrador necessita una ruta cap a cada prefix de lloc que serveix. Una taula de prefixos polida sense camí de tornada al pool continua sent un disseny trencat, i el símptoma és una connexió unidireccional que no respon res. Manteniu les dues direccions a la mateixa taula i reviseu-la sempre que s’afegeixi un lloc.

La traducció i la renumeració resolen problemes diferents

Quan ja existeix una superposició, hi ha dues opcions honestes i una de deshonesta. La renumeració elimina la col·lisió permanentment i costa una finestra de manteniment més cada adreça codificada que hàgiu oblidat. La traducció d’adreces trasllada el rang privat d’un costat a un altre rang a la vora del túnel, cosa que deixa els dos llocs intactes però afegeix estat, trenca protocols que incrusten adreces i fa els registres més difícils de llegir. L’opció deshonesta és una ruta d’host cap a un sol servidor, que passa una prova i falla tota la resta.

Trieu per control i vida útil. Un lloc que posseïu i podeu programar pertany al camí de la renumeració; una xarxa de soci que no podeu tocar, usada per a una sola aplicació, és candidata a traducció amb una correspondència documentada. Escriviu aquesta correspondència, perquè una traducció que només existeix dins d’un fitxer de configuració desapareix en el moment que el fitxer se substitueix.

Proveu des del costat llunyà abans de desplegar

Proveu des d’una xarxa que no allotja la passarel·la, perquè la LAN pròpia de la passarel·la amaga la majoria d’errors d’encaminament. Connecteu un client darrere d’un router domèstic corrent, després arribeu a un servei de cada lloc i a un dins del pool de clients. Proveu també la direcció inversa, des d’un host de lloc cap al client, perquè els camins de tornada fallen independentment. Una prova que només fa ping a la passarel·la demostra que el túnel està aixecat i res més.

Manteniu rangs, propietaris i correspondències de traducció en un sol registre compartit que el lloc següent llegeix abans d’assignar res. Reviseu-lo quan s’afegeix un lloc i tracteu un rang no documentat com un defecte i no com una sorpresa.

El registre és el lliurable. Un pla que viu a la memòria de tres persones falla la primera vegada que un d’ells està de vacances, i una superposició trobada en producció costa més del que hauria costat la taula.