Migrar d’una VPN basada en PPP sense copiar-ne les suposicions

Una migració de VPN s’acaba quan els usuaris, les destinacions, la resolució de noms i el comportament davant de fallades continuen sent correctes, no quan el client nou mostra una icona verda. Els desplegaments antics basats en PPP porten suposicions que mai no es van escriure: un secret compartit que feia d’única comprovació d’identitat, un pool d’adreces fix que el tallafoc té a la llista blanca, un sufix DNS que empeny el servidor. Substituir el protocol sense inventariar aquestes suposicions produeix un túnel que fa l’handshake i una frontera que no existeix. El recorregut de sota és l’ordre que jo faig servir, i l’últim pas és el que els equips s’estalvien.

Pas 1: feu inventari del que ofereix la connexió antiga

L’inventari s’escriu, no es recorda. Anoteu els clients compatibles, els rols d’autenticació, els pools d’adreces, les xarxes protegides, els requisits de DNS i els permisos de servei que necessita cada grup d’usuaris.

Per a L2TP/IPsec, separeu explícitament les dues capes. La identitat de l’igual d’IPsec autentica les màquines; PPP autentica l’usuari, normalment amb CHAP o MSCHAPv2.

És en aquesta separació on els desplegaments antics amaguen les seves suposicions. Una clau precompartida que comparteixen tots els clients autentica un grup, no un dispositiu, i sovint és l’única cosa que s’ha rotat mai. Si el compte PPP és el control real per usuari, digueu-ho, perquè la substitució ha de reproduir aquest control amb alguna cosa que no sigui una cadena compartida. Anoteu també adreces d’origen fixes i excepcions de xarxa local, perquè aquestes són les dependències que ningú no documenta fins que es trenquen.

Pas 2: dissenyeu la substitució deliberadament

Triar la substitució és un mapatge requisit per requisit: un protocol i un client mantingut que l’organització admeti, amb cada requisit d’identitat i accés aterrant en un mecanisme real. Un secret compartit no equival automàticament a una clau o certificat per dispositiu, i un compte PPP per usuari no equival a un certificat de dispositiu.

Coordineu els rangs d’adreces abans que res, perquè un pool de substitució que se solapi amb una LAN domèstica o d’oficina crea una fallada que no té res a veure amb la força del xifratge. Comproveu el pool contra la mateixa llista que vau construir per al servei antic, més el que el client nou assumeix per defecte. Confirmeu l’encaminament de retorn per a les xarxes protegides i confirmeu que el client nou pot empènyer o documentar el sufix DNS que empentava l’antic. Aquests dos punts generen més tiquets de migració que el canvi de protocol.

Pas 3: desplegueu-ho per etapes i verifiqueu tant el permís com la denegació

Desplegueu amb un usuari representatiu i una aplicació representativa. Incloeu la resolució DNS privada a la prova, perquè un túnel que arriba a una adreça però no pot resoldre un nom intern només està migrat a mitges. Incloeu també l’estat d’indisponibilitat esperat: què ha de passar quan el túnel cau i si el client ho imposa.

Després proveu una destinació que ha de continuar denegada. Una regla àmplia de permís temporal pot fer que el túnel nou sembli saludable mentre elimina en silenci la frontera d’autorització que aplicava el servei antic, i ningú no ho nota fins a una auditoria. Compareu els resultats de permís i denegació costat a costat, des del mateix client, en la mateixa sessió. Manteniu el servei antic en marxa fins que les dues columnes coincideixin amb el disseny.

Abans de moure l’accés d’administrador, confirmeu que teniu un camí de recuperació autoritzat que no depengui del túnel que esteu canviant.

Pas 4: retirau la identitat antiga

Retirar correctament la identitat antiga vol dir revocar els usuaris i les credencials de dispositiu obsolets a través del servei que els posseeix, i després eliminar perfils i escoltadors antics quan no quedi cap dependència. Esborrar un fitxer local no revoca una còpia en un altre lloc, i un escoltador antic que encara accepta el secret compartit antic és una porta sense vigilància.

Val la pena frenar en aquest punt. Un perfil de client desmantellat en un portàtil no és una credencial revocada; la credencial viu al servidor i continua vàlida fins que el servidor deixa d’acceptar-la. Cerqueu altres còpies de la configuració antiga — dispositius de prova, un telèfon oblidat, un instal·lador que algú va guardar — i tracteu l’aturada de l’escoltador com el moment en què el servei antic s’acaba de veritat. Fins aleshores, la migració té dues portes davanteres.

El registre d’acceptació és l’inventari del pas u amb una columna afegida: què fa el disseny nou per a cada fila i com ho vau verificar. Això converteix una actualització de protocol en un requisit de servei amb proves.

Manteniu el resultat lligat al que necessita el servei i no al nom del protocol, perquè un protocol modern amb les suposicions antigues copiades a dins és el mateix risc amb un marc millor. RFC 3193 descriu com es transporta L2TP sobre IPsec, cosa que és un recordatori útil que les dues capes sempre van ser decisions separades. Si l’inventari té una fila que no podeu explicar, atureu-vos i esbrineu què en depèn. La migració s’acaba quan la llista és avorrida.