Retirar PPTP/MS-CHAPv2: manual para una VPN heredada

Las contraseñas de veinte caracteres, rotadas cada mes y guardadas en una caja fuerte, no convierten un servidor PPTP con MS-CHAPv2 en una VPN moderna. La contraseña es una entrada a un intercambio cuya debilidad vive en el propio intercambio. Este manual es para quien heredó ese servidor y debe mover a los usuarios fuera de él sin cortar el sitio que depende de él. Siga los pasos en orden, porque cada uno deja un registro que querrá tener cuando alguien pregunte por qué el acceso cambió de repente.

Escriba la pila antes de tocar nada

Tres capas se funden en la palabra PPTP, y cada una falla a su manera. El túnel es el propio PPTP, GRE más TCP 1723. La autenticación es el método PPP que ofrezca el servidor, aquí MS-CHAPv2. La protección del enlace es MPPE, cuyas claves se derivan de ese intercambio de autenticación. Nombrar las tres evita que una corrección posterior aterrice en la capa equivocada.

Lea la configuración viva en lugar de fiarse de una página wiki, y anote el archivo, el oyente y las últimas sesiones que se autenticaron.

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

En un rol de acceso remoto de Windows el mismo inventario sale de dos comandos, y el segundo importa porque un rol puede anunciar varios métodos a la vez mientras los clientes de campo solo negocian siempre el más débil.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Decida qué transporta hoy realmente el túnel

Enumere a los consumidores antes de elegir un reemplazo: portátiles en itinerancia, un enrutador de sucursal, un terminal de pago, un conjunto de tabletas de campo. Un consumidor que solo necesita llegar a un host interno es fácil de mover. Un consumidor incrustado en hardware que no puede reflashear puede necesitar una pasarela intermedia en lugar de una actualización del cliente, y esa decisión pertenece al plan, no al medio de la migración.

Luego pregunte qué obtendría un atacante que pueda observar o influir en el intercambio de inicio de sesión. Con MS-CHAPv2 la respuesta incluye material que permite recuperar sin conexión la contraseña del usuario, y precisamente por eso la longitud y la rotación no reparan el diseño: el secreto recuperado es válido en todos los sistemas donde el usuario lo reutilizó.

MPPE hereda la misma debilidad, ya que sus claves provienen de ese intercambio, y no le da la integridad por paquete ni el comportamiento de repetición de un cifrado AEAD moderno. Una sesión que se autentica limpiamente ha demostrado compatibilidad con las comprobaciones configuradas y nada más.

Ni una pausa corta para comer ni un número pequeño de usuarios convierten una propiedad criptográfica en una de política.

Ejecute la migración dentro de una sola ventana de mantenimiento

Levante el reemplazo, demuéstrelo con un grupo piloto y luego detenga el oyente antiguo en lugar de dejarlo como un respaldo silencioso. Un respaldo al que todos todavía pueden llegar no es una migración, y mantiene el intercambio débil disponible justo para los usuarios que nunca se molestan en cambiar.

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

Cierre la ruta del cortafuegos en la misma ventana. GRE no tiene puerto que recordar, así que una regla que permite el protocolo 47 por número es fácil de pasar por alto y deja el servicio accesible incluso después de que el demonio se haya ido. Registre la regla que eliminó, su posición anterior y el motivo, para que una revisión de cambios posterior no la restaure por accidente.

Gestione las credenciales por separado de la configuración. Eliminar un perfil de cliente no es una revocación, y una cuenta que todavía se autentica en otro lugar no se ha retirado.

Verifique que el reemplazo hace el trabajo que hacía PPTP

La lista de comprobación no es “¿se conecta?”. Es si la autenticación, la asignación de direcciones, la resolución DNS, la selección de ruta, el comportamiento de reconexión y la verificación del par siguen vigentes bajo el reemplazo. Pruebe cada punto en un dispositivo piloto, en ese orden, y escriba el resultado observado junto a lo esperado.

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

Una dirección en la interfaz demuestra que la negociación se completó. No demuestra que el lado remoto haya autorizado la ruta que espera, y la consulta anterior responde solo por este host, no por una LAN reenviada. Una respuesta del resolutor demuestra la accesibilidad de un resolutor, no que la política de DNS dividido le envíe los nombres correctos.

Reconecte al final, porque ahí es donde más reemplazos retroceden: suspenda un portátil, cambie de red y confirme que el túnel se restablece sin dejar rutas obsoletas.

Reversión, revocación y el registro que deja

La reversión restaura el servicio; no restaura la seguridad, y la diferencia debe decirse en voz alta antes de que se abra la ventana. Si la ruta nueva falla, devuelva a los usuarios por un segundo punto final moderno o una pasarela temporal, no reactivando PPTP para todos. Mantener una ruta de emergencia en el protocolo antiguo amplía la exposición que acaba de documentar.

Tras la migración, revoque las cuentas que se autenticaron por PPTP, deje caducar sus perfiles almacenados y confirme que la regla GRE ha desaparecido de cada dispositivo de borde, incluida la copia de recuperación ante desastres que nadie recuerda.

Deje un registro breve: los protocolos que encontró, la fecha en que se detuvo cada oyente, las versiones de cliente que admite el reemplazo y el propietario que puede reabrir la decisión. La higiene de contraseñas sigue importando después, pero como higiene en un protocolo que se la merece, no como argumento para mantener vivo el antiguo.