PPTP dice que tu contraseña es incorrecta: ¿qué corrección va primero?

Los perfiles PPTP que insisten en que tu contraseña es incorrecta te están diciendo algo más estrecho de lo que parece. El secreto se prueba al final mismo de una cadena que empieza con la negociación de capacidades, así que cualquier desajuste anterior en esa cadena aparece como un fallo de autenticación. Por eso, restablecer la contraseña, volver a escribirla o recrear el perfil no cambia nada. Lee primero la negociación y luego elige la corrección según cuánto del camino controlas.

Por qué el secreto nunca llega a probarse

La autenticación PPP se negocia: el servidor propone métodos, el cliente responde con lo que puede hacer y ambos acuerdan uno antes de que se intercambie cualquier credencial. Cuando el servidor ofrece solo EAP-PEAP y el pppd del cliente no lo implementa, la conversación termina en la fase de propuesta. El servidor registra un fallo de autenticación porque esa es la fase que falló, no porque se haya comparado la contraseña y se haya encontrado insuficiente.

Por eso el error es idéntico para una contraseña incorrecta y para un desajuste de método. Solo el registro los distingue, y solo si se permite que el cliente sea detallado.

Lee la negociación, no el último error

Ejecuta la conexión en primer plano con la depuración activada y lee las líneas de autenticación desde arriba. El registro nombra el método propuesto, el método aceptado y dónde se detuvo el intercambio. Un perfil que nunca sale de CHAP o MSCHAPv2 mientras el servidor espera PEAP es un problema de método, no de credenciales. La última línea de ese registro es donde el cliente se rindió, no donde está la causa.

sudo pppd call provider debug nodetach

Guarda esa salida. También es la prueba que el propietario de la red necesita antes de cambiar la política del servidor, y zanja la cuestión de si la contraseña llegó a intervenir.

La segunda causa se esconde en el archivo de secretos

Si el registro muestra que los métodos coinciden, mira el archivo que guarda el secreto. Un salto de línea o un espacio final escrito en el campo de la contraseña se envían como parte de la contraseña, así que el servidor compara una cadena distinta de la que escribiste. El archivo parece correcto en un editor, y por eso mismo sobrevive a tantos intentos.

sudo cat -A /etc/ppp/chap-secrets

El signo de dólar marca el final de cada línea en esa salida. Un campo de contraseña con algo antes de esa marca, o un espacio suelto entre campos, hay que reescribirlo con las comillas que documenta la herramienta.

Elige la corrección según quién sea el dueño del servidor

Si el servidor es tuyo, permitir MSCHAPv2 para esa cuenta es el cambio más pequeño, y deberías dejar constancia de que aceptaste un método más débil a propósito. Si es de otra persona, la corrección honesta es un cliente que implemente EAP-PEAP; parchear pppd convierte la incompatibilidad en tu problema de mantenimiento. Si la elección de protocolo sigue abierta, PPTP es la parte más débil del diseño y la migración suele ser más barata que mantener vivo un cliente parcheado. Escribe esa decisión junto al perfil para que la siguiente persona no la vuelva a abrir.

Elijas la ruta que elijas, pruébalo después desde una segunda máquina en otra red. Un perfil guardado puede seguir ofreciendo el método antiguo y hacer que un servidor corregido parezca roto. Después quita el ajuste de depuración, ya que los registros PPP detallados pueden capturar más de lo que quieres en una estación de trabajo compartida.