Una puerta de enlace VPN que entrega la autenticación a Windows NPS necesita un objeto del lado de NPS antes de que pueda ejecutarse cualquier directiva de usuario: una entrada de cliente RADIUS para la puerta de enlace. La mayoría de los intentos fallidos registran la dirección equivocada, porque la dirección que importa es la que usa la puerta de enlace en su ruta de backend, no el nombre de host que el personal escribe en su aplicación VPN. Si ese valor es erróneo, NPS descarta la solicitud en silencio, lo que desde el lado del cliente parece una contraseña incorrecta. Tres condiciones deciden qué dirección corresponde al campo, así que resuélvalas antes de abrir la consola.

Registre la puerta de enlace, no los portátiles ni el grupo

El objeto de cliente RADIUS representa el dispositivo de acceso a la red que envía solicitudes de autenticación. Es la puerta de enlace VPN, no cada portátil que ejecuta el cliente, ni el rango de direcciones que se entregan dentro de los túneles.

Esas direcciones de túnel nunca aparecen como origen de una solicitud RADIUS, porque la solicitud viaja por la ruta de red propia de la puerta de enlace. Registrar una entrada de grupo de clientes produce una directiva que nunca puede coincidir, mientras que la solicitud real llega desde una dirección que NPS nunca ha oído. La misma confusión lleva a añadir la IP doméstica de cada empleado, algo que es a la vez insostenible e incorrecto.

Tres condiciones deciden la dirección que se introduce

Primero, encuentre la dirección de origen que la puerta de enlace usa realmente hacia NPS. Una puerta con varias interfaces suele enviar desde una interfaz de gestión o de backend en lugar de su escucha VPN pública. Segundo, compruebe si hay NAT entre ambas: si la solicitud se traduce, NPS ve la dirección traducida, y ese es el valor que hay que registrar. Tercero, si dos puertas comparten el rol, cada origen de solicitud necesita su propia entrada de cliente, porque un solo objeto con una dirección solo cubre uno de los dos.

Un registro de dos extremos mantiene el par en orden. La tabla siguiente usa direcciones privadas como ilustración, así que sustitúyalas por las que su ruta realmente utiliza.

At NPSAt the VPN gateway
RADIUS client address 10.20.0.10Authentication server 10.20.0.20
Shared secret, agreed valueThe same secret, same value
UDP 1812 permitted from 10.20.0.10UDP 1812 permitted toward 10.20.0.20

Confirme el origen en lugar de adivinarlo. Observe el registro de NPS o del cortafuegos durante un intento, o capture en el host de NPS con sudo tcpdump -ni any udp port 1812. La dirección de esa captura es la única respuesta defendible para la entrada de cliente. Si la puerta tiene varios orígenes posibles, registre cada uno con su propio nombre descriptivo.

El secreto compartido es un valor entre la puerta de enlace y NPS

El secreto compartido autentica la relación entre dispositivos. No es una contraseña de usuario y nunca se distribuye al personal ni se incrusta en perfiles de cliente.

Elija un valor, introdúzcalo en ambos lugares y guárdelo donde vive la copia de seguridad de la configuración de la puerta de enlace. Una discrepancia produce una solicitud que NPS descarta sin un error útil, algo que en el registro de la puerta no se distingue de un servidor inalcanzable. Rótelo durante una ventana de mantenimiento y actualice ambos extremos en el mismo cambio.

Confirme con una solicitud permitida

Use una cuenta controlada y correlacione un solo intento en ambos lados. En la puerta, confirme que la solicitud salió hacia el servidor previsto; en NPS, que llegó desde el cliente registrado y coincidió con la directiva de solicitud de conexión esperada. Un tiempo de espera y un rechazo significan cosas distintas, y tratar ambos como un problema de credenciales desperdicia la hora siguiente. Después pruebe una cuenta válida pero no elegible y una contraseña incorrecta, porque una directiva que acepta todo también pasa la primera prueba.

Por último, compruebe qué hace la puerta con la autorización devuelta. Registrar un cliente RADIUS solo permite que el dispositivo participe; no concede acceso a la LAN a cada sesión resultante.

Mantenga la salida de diagnóstico acotada: sin secretos compartidos, sin contraseñas de usuario, sin cargas completas de paquetes en un tiquete de soporte. Si el diseño exige que el servidor NPS lea atributos del directorio, ese permiso es una tarea administrativa separada del registro del cliente, y cuando falta falla de otra manera.

Artículos relacionados