EAP a través de una puerta de enlace VPN: quién termina el método

Los tiques describen un inicio de sesión VPN fallido y una política RADIUS que exige un método más fuerte como si fueran el mismo problema, y no lo son. La puerta de enlace acepta una credencial y la reenvía, o bien lleva una conversación EAP entre el cliente y el servidor de autenticación. Cuál de las dos cosas ocurre decide si un cambio en el servidor puede arreglar algo. Lea el intercambio antes de editar el grupo de servidores.

Dos rutas de autenticación que se parecen en un registro

En la primera ruta, la puerta de enlace VPN recoge un usuario y una contraseña y envía una RADIUS Access-Request con un atributo de contraseña. El servidor de autenticación la compara con su almacén y responde aceptar o rechazar. El cliente nunca ejecuta un método EAP porque nada se lo pidió.

En la segunda ruta, el cliente y el servidor de autenticación ejecutan el método EAP de extremo a extremo, y la puerta de enlace reenvía atributos EAP-Message entre ellos. La puerta sigue terminando la conversación RADIUS externa, pero la lógica del método vive en los dos extremos.

Ambas rutas producen una línea en el registro que dice que la autenticación falló. Solo la segunda puede verse afectada por el método EAP que prefiere el servidor, y solo la primera por cómo lee la puerta la contraseña. Tratarlas como intercambiables es cómo los equipos pasan un día cambiando grupos de servidores para un cliente que nunca iba a hablar PEAP.

Dónde se ejecuta realmente el método

RFC 3579 define el esquema de paso: el NAS lleva paquetes EAP en atributos RADIUS y no necesita código específico para cada tipo de EAP. Por eso una puerta puede admitir PEAP y EAP-TLS sin implementar ninguno.

Una puerta que envía una contraseña no lleva PEAP, aunque el backend aceptara PEAP de otro cliente. Habilitar PEAP en la política del servidor no añade un método a un cliente que nunca ofreció uno.

Los ajustes de autenticación PPP pertenecen al servicio PPP. No reconfiguran en silencio cada ruta IPsec o XAuth antigua que usa el mismo servidor AAA, así que un cambio que funciona para un tipo de acceso puede dejar intacto el otro.

Lo que el NAS debe admitir

El paso traslada el requisito del código del método al soporte del portador. La puerta debe poder llevar EAP por su protocolo VPN, y el cliente RADIUS que corre en ella debe poder enviar y recibir atributos EAP-Message de los tamaños implicados.

En IKEv2, EAP forma parte de un flujo de autenticación definido, y las comprobaciones de identidad y confianza del servidor vienen de ese flujo. Una etiqueta PEAP tomada de un despliegue 802.1X no se traslada automáticamente porque la negociación a su alrededor es distinta.

El lado del cliente también tiene requisitos. Debe estar configurado para el método, confiar en el certificado del servidor que presenta el método y tener credenciales que el método pueda usar. Un método basado en certificados sin certificado de cliente falla antes de que RADIUS vea nada, lo que es un problema de aprovisionamiento y no de política del servidor.

Lea un intento antes de cambiar la política

Capture un único intento aprobado en la puerta y en el servidor de autenticación. Busque atributos EAP-Message en la petición RADIUS. Su presencia indica que se usa la ruta de paso; su ausencia apunta a un intercambio de credenciales.

En una puerta Linux, una captura en el puerto RADIUS muestra qué atributos hay en el cable:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Luego compare el punto de rechazo. Un fallo en la puerta antes de cualquier paquete RADIUS significa que el cliente y la puerta no se pusieron de acuerdo sobre el método. Un rechazo RADIUS con atributos EAP significa que los extremos ejecutaron el método y uno de ellos rechazó el resultado.

Planifique la migración como un solo cambio de extremo a extremo

Cambiar el método significa cambiar a la vez la configuración del cliente, el soporte del portador en la puerta, la política del método en el servidor y el almacén de credenciales. Hágalo en ese orden y mantenga una ruta funcional hasta que la nueva quede probada. Un cambio solo en el servidor es una conjetura y normalmente rompe a los clientes que funcionaban. Prepare el cambio en una identidad de prueba antes de tocar el grupo.

Anote la combinación que funciona: protocolo VPN, portador EAP, método del par, método del servidor, tipo de credencial y comprobación de identidad del servidor.

Mantenga el AAA de inicio de sesión administrativo separado de la autenticación VPN, salvo que la tarea incluya ambos explícitamente. Un cambio pensado para el acceso remoto no debe quitarle la capacidad de gestionar el dispositivo que lo termina.