Planifiqueu les subxarxes abans d’una VPN entre seus: renumereu o traduïu

Dues oficines fan servir totes dues 192.168.1.0/24 perquè ningú no va planificar una altra cosa, i s’espera que el túnel ho resolgui. No pot: un encaminador no pot fer que la mateixa adreça privada signifiqui dos llocs diferents. La feina que ho evita es fa abans que s’escrigui el primer paràmetre del túnel.

Inventarieu cada rang, inclòs els que heu oblidat

Recolliu les LAN, els segments de servidors, els pools de clients d’accés remot, els rangs de VPC al núvol i qualsevol xarxa de contenidors o superposada a què els amfitrions hagin d’arribar. Els pools de clients són els que la gent oblida, i s’encavalquen amb un rang d’oficina sorprenentment sovint perquè tots dos es van triar del mateix valor per defecte. Incloeu la xarxa de gestió i qualsevol segment fora de banda.

Anoteu el propietari, la passarel·la, la finalitat i si el prefix ha de ser abastable des de l’altra seu. Un prefix que mai no ha de travessar el túnel no cal que sigui únic, i saber-ho redueix la feina de renumeració.

Feu IPv6 a part, perquè el seu pla i els seus encavalcaments són independents.

Compareu prefixos, no adreces conegudes

Dues xarxes amb adreces d’amfitrió diferents es poden encavalcar igualment, perquè l’encavalcament és una propietat de les màscares i no dels números que la gent recorda. 10.20.0.0/16 conté 10.20.30.0/24 tant si algú ho diu en veu alta com si no. Compareu parells de prefixos sencers i comproveu els agregats contra les xarxes més petites que hi ha a dins. Per això la comprovació pertoca a un full de càlcul i no al cap de ningú.

La mateixa comprovació s’aplica al pool de clients de la mateixa VPN i a qualsevol rang traduït que planifiqueu introduir, ja que un rang traduït que col·lideix és pitjor que l’encavalcament original.

Una taula de prefixos amb màscares ja és prou; un diagrama sense màscares no ho és.

Decidiu què ha de travessar realment

Una seu pot contenir trenta subxarxes mentre que una xarxa de servei necessita accés remot. Partiu d’aquest requisit i anuncieu només el que necessita, perquè els anuncis més petits i les regles d’accés corresponents són més fàcils de revisar i més difícils d’ampliar per accident. Anunciar tots els rangs privats en ús és un hàbit que converteix un túnel en un pont. Com més estret és l’anunci, més petit és el radi d’impacte d’un error futur.

El DNS privat ha de retornar adreces a què els clients previstos puguin arribar, així que un nom que apunta a un rang no anunciat o encavalcat continua trencat encara que la consulta reixi.

Escriviu la llista d’accés abans de la configuració del túnel, no després que falli.

Renumereu o traduïu, i conegueu el cost

Renumerar una xarxa sol ser el remei més clar a llarg termini, i toca reserves, dispositius, DNS, regles de tallafocs i qualsevol cosa amb una adreça incrustada en una configuració. Traduir un rang d’accés és l’alternativa quan renumerar no és pràctic, i costa la identitat d’origen més una classe de protocols que incrusten adreces a la càrrega útil. Trieu-ne una i acabeu-la, perquè una xarxa mig renumerada és pitjor que qualsevol de les dues opcions.

Tant si trieu una cosa com l’altra, documenteu tant l’adreça original com la presentada, perquè cada conversa posterior de resolució de problemes les necessita.

Una solució alternativa sense camí de tornada no és una solució.

Feu servir una matriu de rutes com a prova d’acceptació

Acabeu amb una matriu: prefix local, prefix remot, servei permès i passarel·la de retorn. Aquesta taula és la prova d’acceptació quan el túnel s’aixeca, i també és el document que llegirà el següent enginyer. Proveu des d’amfitrions reals a les subxarxes seleccionades, no des de les passarel·les.

Un ping entre adreces del túnel demostra que el túnel existeix i res sobre el pla d’adreces que hi ha darrere.

Manteniu la matriu amb la configuració del túnel, i la propera addició de seu començarà a partir de dades i no de memòria. La guia de reenviament de strongSwan cobreix el costat de la passarel·la un cop el pla existeix.