IP fija de VPN: Framed-IP-Address de RADIUS o una reserva en el pool

Tres lugares pueden guardar una dirección interna fija para un cliente VPN, y solo uno de ellos debería poseerla. RADIUS puede devolver la dirección en un Access-Accept, la puerta de enlace puede mantener una asignación estática para la cuenta, y el adaptador del cliente puede configurarse a mano. Los dos primeros son política y el tercero es una suposición local que la puerta de enlace es libre de ignorar o sobrescribir. Elegir entre los dos primeros es la decisión real, y depende de lo que el servidor de acceso a la red implemente realmente.

Tres lugares donde puede vivir una dirección fija

RADIUS posee la dirección cuando la respuesta lleva Framed-IP-Address y la puerta de enlace aplica ese valor a la sesión. La puerta de enlace la posee cuando un administrador asigna la cuenta a una dirección estática dentro del pool. El cliente no posee nada, ni siquiera cuando su adaptador muestra una dirección manual, porque el servidor asigna la dirección interna durante la negociación y un ajuste local solo importa cuando el servidor no envía ninguno. Los tres parecen idénticos en una conexión que funciona, y por eso los conflictos salen tarde. La diferencia aparece al reconectar, en un segundo dispositivo y tras un cambio de política.

Dos propietarios es la configuración que se rompe. Una respuesta de RADIUS que asigna 172.28.4.77 mientras la puerta de enlace mantiene una asignación estática para 172.28.4.90 entrega el valor que el código del fabricante comprueba primero, y el perdedor se descarta sin una línea de registro. La misma cuenta en un segundo dispositivo recibe entonces una dirección duplicada, y el síntoma se lee como un fallo de enrutamiento en lugar de un conflicto de asignación. Resuelva el propietario antes de añadir el segundo mecanismo.

La opción del lado del cliente merece nombrarse solo para poder descartarla. Una dirección manual del adaptador es una preferencia que el sistema operativo puede presentar, no una reserva, y no puede impedir que otra sesión reciba la misma dirección.

Qué puede prometer la respuesta de RADIUS y qué no

RFC 2865define Framed-IP-Address como la dirección IPv4 que debe configurarse para el usuario, y pertenece a Access-Accept. El mismo atributo en Access-Request es solo una pista que el servidor puede ignorar, lo que importa cuando un cliente o una puerta de enlace ofrece una dirección preferida. Nada en el protocolo obliga a la puerta de enlace a respetar la respuesta, porque el servidor de acceso a la red es el componente que la aplica a la sesión.

El soporte es una cuestión de producto y no de protocolo. Algunas puertas de enlace aplican direcciones enmarcadas de forma predeterminada, otras necesitan un interruptor a nivel de grupo antes de hacerlo, y otras aceptan el atributo y nunca lo usan para sesiones de acceso remoto. Ese último caso es el peligroso, porque el registro de contabilidad puede mostrar la respuesta mientras el cliente recibe una dirección del pool. Confirme el comportamiento en el modelo exacto de puerta de enlace y el firmware que ejecuta, no en la documentación de un producto hermano.

Una respuesta que la puerta de enlace ignora se ve exactamente como una respuesta que nunca se envió. Leer el Access-Accept y la dirección de la sesión uno al lado del otro es la única forma de separar los dos casos.

Reserve la dirección dentro del pool que ya enruta

Elija la dirección fija de la subred del pool que la puerta de enlace ya enruta y en la que el cortafuegos ya confía. Una dirección fuera de ese rango convierte un cambio de política en un proyecto de enrutamiento, y la VPN subirá mientras nada detrás de ella podrá responder. Si existen reglas de acceso por dirección, añada la dirección fija a ellas en el mismo cambio.

Decida qué debe hacer una segunda sesión simultánea. Asignar una dirección dos veces no es gestión de dispositivos, y la colisión resultante aparece como conectividad intermitente para ambas sesiones. O emita identidades distintas por dispositivo, o asignaciones distintas, o imponga la simultaneidad con una comprobación admitida, como Simultaneous-Use, en lugar de esperar que el cliente nunca se reconecte antes de que caduque la sesión antigua.

Las rutas de retorno merecen la misma atención que la asignación. La puerta de enlace necesita una ruta al pool, los enrutadores internos necesitan una ruta de vuelta a la puerta de enlace, y la dirección fija hereda ambas. Un solo cliente que funciona mientras todos los demás fallan suele significar que la ruta del pool existe pero la ruta de host para la dirección reservada no.

Pruebe la respuesta antes de confiar en la reserva

Pruebe el lado AAA y el lado de la sesión por separado, porque fallan por motivos distintos. Un radtest local muestra lo que el servidor devuelve para la cuenta sin implicar a la puerta de enlace, y la entrada del archivo de usuarios muestra con qué debe coincidir el servidor. Después reconecte el cliente y compare la dirección que recibió con el atributo de la respuesta.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Un Access-Accept sin el atributo significa que el servidor no coincidió con la entrada o que el atributo no se aplicó a ese usuario. Un Access-Accept con el atributo y un cliente que sigue recibiendo una dirección del pool significa que la puerta de enlace lo ignoró. Un Access-Reject le devuelve a las credenciales o a la política de grupo, y ninguno de estos resultados debería depurarse editando el adaptador del cliente.

Repita la comprobación tras una reconexión y tras un segundo inicio de sesión desde otro dispositivo. Una reserva que solo aguanta la primera sesión es un conflicto de pool esperando a ocurrir, y es más barato encontrarlo ahora que durante una auditoría.

Elija un solo propietario y anótelo

Si la puerta de enlace aplica las direcciones enmarcadas de forma fiable, deje que RADIUS posea la asignación y elimine cualquier asignación estática para la misma cuenta. Si no lo hace, deje que la posea la puerta de enlace y elimine el atributo de la respuesta, para que las dos fuentes no puedan discrepar. Mantener ambas porque cada una casi funciona garantiza una sesión futura con la dirección equivocada y sin causa evidente.

Anote el propietario elegido, la dirección reservada y el pool del que proviene en el registro de la cuenta. La siguiente persona que añada un dispositivo podrá ver si la dirección es una política AAA o una asignación de la puerta de enlace antes de cambiar cualquiera de las dos.