Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 3 de Noviembre de 1.998 - Martes
Infovía autentifica a los usuarios utilizando un esquema RADIUS. Lamentablemente la versión RADIUS de Telefónica no es compatible con las especificaciones originales. Ello, aunque, molesto, tiene sentido a la luz de la propia problemática que tiene Infovía.
Los fuentes del RADIUS de Telefónica no son públicos así que quedan dos opciones:
Para el desarrollo de este texto se ha utilizado el siguiente material:
Esta función es la que permite identificar los usuarios conectados y sus características. Se envía un paquete cuando el usuario conecta y se envía otro cuando su conexión se cierra.
El funcionamiento de la versión Infovía es el definido en el RFC. Se utiliza, eso sí, el tipo "proxy", así como las extensiones ASCEND al RADIUS original. Los datos enviados por infovía son:
|
Start User-Name
|
[1] |
Stop User-Name
|
[1] | |
|
| ||||
En "Proxy-State" los CSIVs transmiten la siguiente secuencia, en 38 bytes: "V1 V2 00 04 00 00 00 00 ID ID ID ID NI NI NI NI CI CI CI CI 04 02 CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK"
El servidor RADIUS devuelve exactamente la misma secuencia "Proxy-State", pero cambiando el "V1 V2" inicial por su versión de software local.
Esta función es la que permite verificar las conexiones de los usuarios, así como configurar cosas como su tiempo máximo de inactividad, su tiempo máximo de conexión, etc.
Los datos intercambiados entre Infovía y nuestro servidor RADIUS son:
|
CSIV -> RADIUS |
RADIUS -> CSIV | |||
|
User-Name
User-Password NAS-Identifier NAS-Port NAS-Port-Type Service-Type: Framed Framed-Protocol: PPP State Caller-Id Client-Port-DNIS Acct-Session-Id Proxy-State | [1] [2] [5] [3] [4] [1] |
Service-Type: Framed
Framed-Protocol Framed-IP-Address Framed-IP-Netmask Ascend-Metric Framed-Routing Framed-Compression Ascend-Idle-Limit Ascend-Maximum-Time User-Name Proxy-State | [6] | |
|
En "Proxy-State" los CSIVs transmiten la siguiente secuencia, en 38 bytes: "V1 V2 00 04 00 00 00 00 ID ID ID ID NI NI NI NI CI CI CI CI 04 01 CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK"
El servidor RADIUS devuelve exactamente la misma secuencia "Proxy-State", pero cambiando el "V1 V2" inicial por su versión de software local.
La verificación de usuarios se realiza exactamente igual a las normas RADIUS estándar. Existe, no obstante, una desviación importante respecto a las normas: La sincronización.
Cada CSIV envía a nuestro servidor RADIUS un paquete tipo autentificación de usuario, con fines de sincronización. Esos paquetes se mandan, aproximadamente, cada 90 segundos, y son claramente reconocibles observando parte de su contenido:
48: 69ab 3536 3738 3930 3132 3334 3536 1234 i.567890123456.4
64: 4643 3a20 4d65 6e73 616a 6520 5349 4e43 FC: Mensaje SINC
80: 524f 4e49 534d 4f20 6465 2049 6e66 6f76 RONISMO de Infov
96: 6961 2d54 656c 6566 6f6e 6963 6120 492b ia-Telefonica I+
112: 442e 0130 5573 7561 7269 6f20 6669 6374 D..0Usuario fict
128: 6963 696f 2070 6172 6120 7369 6e63 726f icio para sincro
144: 6e69 736d 6f20 636f 6e20 496e 666f 7669 nismo con Infovi
160: 612e 0506 ffff ffff 0203 0021 1202 0000 a..........!....
Analizando estos paquetes nos encontramos:
Nuestro servidor RADIUS devuelve un paquete de protocolo 3 (Acceso denegado), y su atributo 33 (Proxy-State) será el mismo que el enviado en último lugar (sólo se devuelve éste) en el paquete anterior, cambiando los cuatro primeros bytes de "V1 V2 00 00" a "V1' V2' 00 02".
El formato de cada una de las secuencias "Proxy-State" es "V1 V2 00 00 00 00 00 00 NI NI NI NI NU FF 00 00 [(ID ID ID ID)...]". Si todas esas secuencias no caben en un único paquete, se distribuyen en varios, enviándose de forma alternativa cada 90 segundos (cada 90 segundos se transmite un paquete). El significado es:
Estudiando la documentación anterior puede verse que la versión RADIUS de Infovía es idéntica a su código base (ASCEND), y que las necesarias diferencias para sostener esta arquitectura de red se han centralizado a través del campo "Proxy-State".
Los cambios son necesarios para permitir la coordinación y el sincronismo entre los NAS de Infovía y nuestro servidor RADIUS, que es quien gestiona las direcciones IP. Existen varias posibilidades:
Los NAS y el servidor RADIUS están perfectamente sincronizados.
En este caso los usuarios nuevos serían rechazados (no pueden autentificar). El servidor RADIUS no tiene constancia de los usuarios que han colgado, por lo que no puede liberar sus IPs ni sus sesiones. Por tanto si el CSIV se cae y su tráfico es desviado a través de otro, cualquier usuario que estuviese conectado ya a través de él se verá imposibilitado de conectar por agotamiento de sesiones (tiene sesiones activas).
Esta situación no puede corregirse hasta que se restablezca la comunicación con el CSIV, ya que en ese momento el CSIV envía al servidor RADIUS el estado de sesiones de sus NAS, y las sesiones que ya no existan sencillamente se liberan. Una solución manual es cerrar "a mano" la conexión del usuario con problemas, mediante la utilidad correspondiente.
La versión 3.x del servidor RADIUS de infovía libera todas las conexiones dependientes de un CSIV con elque se ha perdido la comunicación. Ello soluciona el problema.
El servidor RADIUS vuelca su estado en disco y termina. La situación es similar a la anterior. Los usuarios nuevos son rechazados (no existe servidor que los autentifique), y los usuarios que cuelgan quedan en estado inconsistente.
En cuanto se ejecute de nuevo el servidor, leerá su estado y, como en el caso anterior, empezará a cerrar las sesiones inexistentes (usuarios que han colgado) a medida que le vayan llegando los sincronismos de los CSIVs.
Un riesgo muy a tener en cuenta es la posibilidad de que el servidor RADIUS muera por cualquier razón, y al reiniciarlo cargue un estado antiguo y anticuado. Las sesiones que ya no existan (si el estado es antiguo, la mayoría), se liberan gracias a los sincronismos. El problema está con las sesiones activas que no existan en el estado recuperado ya que, entre otras cosas, puede reasignarse su IP a otros usuarios.
En principio el problema es "solucionable" mediante chequeos de consistencia, en los que el servidor RADIUS observa los sincronismos de los CSIVs. Si no aparecen sesiones presentes en su estado, las dá de baja; si aparecen sesiones no presentes en su estado, solicita al NAS que corte la llamada :). Las peticiones de autentificación que vayan entrando mientras el servidor se sincroniza son rechazadas.
La parada controlada del servidor es una opción interesante para, por ejemplo, poder reiniciar la máquina sin necesidad de desconectar a todos los usuarios.
En este caso es similar al del corte en la comunicación. Al arrancar, el CSIV liberará todas las conexiones. El servidor RADIUS detectará este hecho al seguir las sincronizaciones.
Como en el caso de parada controlada, pero sin disponer de estado. En el proceso de sincronizarse con los CSIVs, el servidor procederá al corte sistemático de las conexiones en curso.
Una de las funcionalidades incluídas en las herramientas del servidor RADIUS es la de "desconectar usuario". Dicha orden envía al CSIV correspondiente un paquete RADIUS de rechazo de conexión, como si la autentificación hubiese fallado. No obstante en dicho paquete no se indica -de forma estándar- qué conexión se debe cerrar. Esa información se incluye en el campo "Proxy-State", a modo de sincronismo y con la misma sintaxis ya vista, indicando únicamente las sesiones que quedan en el NAS correspondiente a la sesión que queremos cortar. Obviamente entre ellas no se encuentra "la víctima".
Si no podemos comunicarnos con el CSIV en cuestión no podemos liberar la sesión de este modo; debemos combinar esa función con la de "reutilizar IP".
Todos estos problemas, no contemplados en la especificación RADIUS original son debidos al empleo de este sistema en un entorno de gran demanda de recursos. Telefónica no se puede permitir, por ejemplo, el repetir los paquetes RADIUS de forma indefinida hasta que el proveedor se dá por enterado, que es lo que se especifica en la norma. En ese sentido Telefónica no ha tenido elección.
Algunos enlaces que pueden resultar de interés:
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
