Dirección de cliente VPN estable con Framed-IP-Address de RADIUS

RADIUS puede responder con una dirección para un usuario determinado; que el túnel la reciba realmente depende de la pasarela. Es en esa distancia entre lo devuelto y lo aplicado donde fracasan la mayoría de los planes de direcciones estables. Un atributo en una respuesta de prueba demuestra que el servidor puede enviarlo, no que el servicio de acceso remoto lo aplique. La secuencia siguiente comprueba ambas mitades antes de que la dirección acabe en las reglas del cortafuegos.

Decida qué capa posee la dirección

Las pasarelas de acceso remoto suelen tener un grupo local, y muchas también pueden aceptar una dirección de la respuesta de autenticación. Cuál gana depende de la plataforma, del protocolo y de la configuración del servicio, así que lea la regla de precedencia para la versión exacta en uso. Donde el grupo local tiene prioridad, el atributo es decorativo y el cliente acaba igualmente en una dirección aleatoria. Anote la decisión, incluido si un valor devuelto debe quedar dentro del rango del grupo o puede quedar fuera.

El RFC 2865 define Framed-IP-Address como la dirección que debe configurarse para el usuario y no dice nada sobre la voluntad de una pasarela concreta de respetarla. La documentación del fabricante es la autoridad sobre la precedencia, no la definición del atributo.

Envíe una petición de prueba y lea la respuesta

Pruebe primero el servidor de forma aislada, para que un atributo ausente no se confunda con un problema de la pasarela. radtest envía una Access-Request e imprime los atributos que vuelven.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Busque Framed-IP-Address en el Access-Accept y confirme que el valor es el previsto y no una dirección del grupo de una regla de reserva. Cuando falta el atributo, la entrada de usuario o la política de autorización no coinciden, y el ajuste de la pasarela no puede aportar lo que el servidor nunca envió. Repita la petición mientras el servidor se ejecuta en modo de depuración si la respuesta cuesta atribuirla a una regla concreta. Mantenga el secreto compartido fuera del historial del intérprete y de los tiques, porque el marcador de arriba no es una credencial.

Confirme que la pasarela respetó el valor

Una respuesta correcta es solo la mitad del contrato. La dirección que aparece en la interfaz del túnel es la observación que importa, y se lee en el cliente en lugar de deducirse de la configuración de la pasarela.

ip -4 addr show tun0

Compare esa dirección con el atributo del Access-Accept. Una discrepancia significa que la pasarela ignoró o reescribió el valor, lo que reabre la cuestión de precedencia de la primera sección. Vuelva a conectarse una vez más, porque una reserva que solo funciona al primer intento suele apuntar a una sesión obsoleta o a un arrendamiento que aún mantiene la conexión anterior. Anote la versión de la pasarela y el protocolo junto al resultado, para que la siguiente persona pueda decir si el comportamiento es específico de la versión.

Planifique la simultaneidad y la revocación

Un nombre de usuario en dos dispositivos no puede corresponder a una sola dirección salvo que la pasarela distinga las sesiones por algo más allá del inicio de sesión. Decida si la correspondencia pertenece a una persona, a un dispositivo inscrito o a la identidad de un certificado, y haga esa elección explícita en el almacén de políticas. Pruebe un segundo cliente simultáneo y compare las dos direcciones asignadas, porque una colisión aquí reaparece más tarde como fallo de enrutamiento. La misma diligencia corresponde al plan de revocación, porque una dirección reasignada mientras reglas antiguas del cortafuegos aún la referencian se convierte en un error de autorización.

El direccionamiento estable simplifica reglas y registros, pero nunca demuestra quién generó un paquete. La autenticación y la autorización de destino siguen importando cuando esa dirección pasa luego a otra sesión.