MSCHAPv2 no es un protocolo VPN: pregunta primero por el túnel

Los nombres de usuario y las contraseñas viajan dentro de un portador, y MSCHAPv2 solo nombra el método que viaja. Pregunta qué túnel lo transporta antes de elegir un perfil de cliente, porque la misma cadena de cuenta aparece en arreglos que no comparten ni una línea de código. Cada perfil que te entregan codifica ambas decisiones, incluso cuando la hoja de instrucciones imprime solo una de ellas. El orden de abajo es lo que un operador puede responder sin adivinar y lo que tú puedes comprobar sin capturar paquetes.

La autenticación viaja dentro de un túnel

Una VPN toma dos decisiones que parecen una: cómo los pares construyen un canal protegido y cómo una persona demuestra su identidad dentro de él. La segunda está impresa en la hoja de instrucciones porque es la que teclea un humano. La primera decide si algún cliente funcionará siquiera, y es la que la gente se salta. Pide al operador que nombre primero el portador y después el método, en ese orden. Dos conexiones pueden exigir el mismo nombre de cuenta y la misma contraseña sin compartir ninguna implementación bajo la casilla de inicio de sesión.

Por eso los ajustes copiados del teléfono que funciona de un compañero pueden fallar en el tuyo, incluso cuando el servidor acepta ambas credenciales. La credencial nunca fue la diferencia; lo era el perfil que la envuelve. ambas partes tienen razón y no se conecta nada suele ser justo esta confusión, y se aclara en cuanto se nombra el portador.

Tres lugares donde aparece el mismo método

En PPP el paso de autenticación espera a que exista un enlace, y RFC 2759 define MS-CHAPv2 como ese paso, por eso el método aparece en L2TP y en despliegues PPTP más antiguos. El túnel termina primero y la negociación PPP ocurre dentro de él, así que una etapa PPP fallida puede dejar el túnel como establecido en el registro del servidor. Lee esas dos etapas por separado antes de concluir que se rechazaron las credenciales. Por tanto, un cliente configurado para L2TP puede ser del todo correcto y aun así ser el cliente equivocado para una puerta de enlace que solo habla IKEv2.

IKEv2 en cambio coloca EAP-MSCHAPv2 dentro del intercambio de claves, así que la misma credencial falla en otro momento y aparece como un error de autenticación y no como un error de sesión. El perfil IKEv2 de la plataforma Android es el ejemplo cotidiano, y pide un certificado o identificador de servidor en lugar de opciones PPP. El nombre de cuenta es idéntico en ambos arreglos, así que no puede decirte cuál tienes. Solo la lista de protocolos admitidos del operador lo resuelve.

Una VPN basada en TLS añade un tercer arreglo, con sus propios campos de usuario y contraseña y sin MS-CHAPv2 en ningún punto del intercambio. Ver una casilla de contraseña no es, por tanto, prueba del protocolo que hay detrás, porque el formulario está construido para parecer conocido. Confirma el protocolo por la documentación del servidor, no por la forma de la ventana del cliente.

Las respuestas que de verdad necesitas

Envía la petición como una lista, porque una lista es difícil de responder a medias. Pide el protocolo del túnel, el método que hay dentro y el cliente que el operador admite en tu plataforma. Después pide la identidad y los ajustes de confianza de la puerta de enlace, el formato de la cuenta y qué debería ser alcanzable una vez levantada la conexión.

Las tres primeras deciden si obtienes un perfil que funcione. Las tres últimas deciden si ese perfil hace lo que el trabajo necesita. Mantén la respuesta adjunta al ticket, porque la siguiente persona hará las mismas seis preguntas. Donde falte una respuesta, trata el hueco como una decisión que el operador aún no ha tomado, no como algo que puedas inferir.

No relajes la verificación de la puerta de enlace

El servidor también demuestra su identidad al cliente, y esa mitad del intercambio no es decoración. Desactivar la verificación de certificados para que un perfil terco conecte acepta cualquier extremo que responda, incluido uno al que nadie pretendía llegar. También oculta una discrepancia real en lugar de resolverla, lo que empuja el fallo a un momento posterior y menos obvio. Un perfil que necesita la comprobación desactivada es un perfil que apunta a algo que no puede verificar.

La discrepancia suele ser un nombre, porque un certificado emitido para un nombre de host falla cuando el perfil marca una dirección. Marca el nombre en lugar de desactivar la comprobación. Una autoridad de certificación privada falla cuando al dispositivo nunca se le dio la raíz, y la solución es distribuir esa raíz por la vía aprobada. Los entornos gestionados esperan que el operador aporte la identidad y el ancla de confianza, y que el perfil haga referencia a ambas. Cuando falta el campo, pide el artefacto en lugar de renunciar a la verificación.

Ajusta el perfil y luego demuestra cada etapa

Una vez conocido el portador, sigue el proceso documentado de ese cliente e introduce solo los campos que pide. Los campos extra rellenados porque existen siguen siendo valores erróneos, y fallan más tarde que los obligatorios. Guarda el perfil sin cambios tras la primera conexión correcta, para que una edición posterior pueda compararse con algo que se sabe que funciona.

Después verifica por etapas: el túnel se establece, el usuario se autentica, aparecen la dirección y las rutas asignadas y un servicio permitido responde. Cada etapa deja su propia línea de registro en el servidor, y leerlas en orden convierte una queja vaga en un hallazgo concreto. Si la plataforma ya no admite el arreglo que describe el operador, eso es una conversación de migración y no un motivo para activar todas las opciones heredadas del dispositivo. Portador, método y perfil son tres respuestas separadas, y una conexión que funciona las tiene las tres de acuerdo.