Migrar desde unha VPN baseada en PPP sen copiar os seus supostos

Unha migración de VPN remata cando os usuarios, os destinos, a resolución de nomes e o comportamento ante fallos seguen sendo correctos, non cando o cliente novo mostra unha icona verde. Os despregamentos antigos baseados en PPP arrastran supostos que nunca se escribiron: un segredo compartido que facía de única comprobación de identidade, un grupo de enderezos fixo que a devasa ten na lista branca, un sufixo DNS que empurra o servidor. Substituír o protocolo sen inventariar eses supostos produce un túnel que completa o handshake e unha fronteira que non existe. O percorrido de abaixo é a orde que eu uso, e o último paso é o que os equipos saltan.

Paso 1: faga inventario do que ofrece a conexión antiga

O inventario escríbese, non se recorda. Anote os clientes admitidos, os roles de autenticación, os grupos de enderezos, as redes protexidas, os requisitos de DNS e os permisos de servizo que necesita cada grupo de usuarios.

Para L2TP/IPsec, separe as dúas capas de forma explícita. A identidade do par de IPsec autentica as máquinas; PPP autentica o usuario, normalmente con CHAP ou MSCHAPv2.

É nesa separación onde os despregamentos antigos esconden os seus supostos. Unha clave precompartida que comparten todos os clientes autentica un grupo e non un dispositivo, e a miúdo é o único que se rotou nunca. Se a conta PPP é o control real por usuario, dígao, porque a substitución ten que reproducir ese control con algo que non sexa unha cadea compartida. Anote tamén os enderezos de orixe fixos e as excepcións de rede local, porque esas son as dependencias que ninguén documenta ata que se rompen.

Paso 2: deseñe a substitución a propósito

Escoller a substitución é un mapeo requisito por requisito: un protocolo e un cliente mantido que a organización admita, con cada requisito de identidade e acceso aterrando nun mecanismo real. Un segredo compartido non equivale automaticamente a unha clave ou certificado por dispositivo, e unha conta PPP por usuario non equivale a un certificado de dispositivo.

Coordine os rangos de enderezos antes que nada, porque un grupo de substitución que se solape cunha LAN doméstica ou de oficina crea un fallo que non ten nada que ver coa forza do cifrado. Comprobe o grupo contra a mesma lista que construíu para o servizo antigo, máis o que o cliente novo asume por defecto. Confirme o encamiñamento de retorno para as redes protexidas e confirme que o cliente novo pode empurrar ou documentar o sufixo DNS que empurraba o antigo. Esas dúas cousas xeran máis tíckets de migración que o cambio de protocolo.

Paso 3: despregue por etapas e verifique tanto o permiso como a denegación

Despregue cun usuario representativo e unha aplicación representativa. Inclúa a resolución DNS privada na proba, porque un túnel que chega a un enderezo pero non pode resolver un nome interno só está migrado á metade. Inclúa tamén o estado de indispoñibilidade esperado: que debe ocorrer cando cae o túnel e se o cliente o impón.

Despois probe un destino que debe seguir denegado. Unha regra ampla de permiso temporal pode facer que o túnel novo pareza san mentres retira en silencio a fronteira de autorización que aplicaba o servizo antigo, e ninguén o nota ata unha auditoría. Compare os resultados de permiso e denegación lado a lado, desde o mesmo cliente, na mesma sesión. Manteña o servizo antigo en marcha ata que as dúas columnas coincidan co deseño.

Antes de mover o acceso de administrador, confirme que ten unha ruta de recuperación autorizada que non dependa do túnel que está a cambiar.

Paso 4: retire a identidade antiga

Retirar ben a identidade antiga significa revogar os usuarios e as credenciais de dispositivo obsoletos a través do servizo que os posúe, e despois eliminar perfís e escoitas antigos cando non quede ningunha dependencia. Borrar un ficheiro local non revoga unha copia noutro sitio, e unha escoita antiga que aínda acepta o segredo compartido antigo é unha porta sen vixilancia.

Paga a pena frear nese punto. Un perfil de cliente dado de baixa nun portátil non é unha credencial revogada; a credencial vive no servidor e segue sendo válida ata que o servidor deixa de aceptala. Busque outras copias da configuración antiga — dispositivos de proba, un teléfono esquecido, un instalador que alguén gardou — e trate o apagado da escoita como o momento en que o servizo antigo remata de verdade. Ata entón, a migración ten dúas portas dianteiras.

O rexistro de aceptación é o inventario do paso un cunha columna engadida: que fai o deseño novo para cada fila e como o verificou. Iso converte unha actualización de protocolo nun requisito de servizo con probas.

Manteña o resultado ligado ao que necesita o servizo e non ao nome do protocolo, porque un protocolo moderno cos supostos antigos copiados dentro é o mesmo risco cun marco mellor. RFC 3193 describe como se transporta L2TP sobre IPsec, o que é un recordatorio útil de que as dúas capas sempre foron decisións separadas. Se o inventario ten unha fila que non pode explicar, pare e averigüe de que depende. A migración remata cando a lista é aburrida.