Aplicaciones principales

Para conseguir que las tablas se rellenen correctamente y los usuarios puedan acceder al sistema se han redactado varios scripts en Perl y un módulo ControlNocat.pm que contiene las funciones utilizadas. Hay dos scripts que se ejecutan para registrar las conexiones realizadas. Concretamente los scripts conexion y salida, que son los encargados de rellenar la tabla de conexiones y el histórico de conexiones. Además de estos dos scripts, existen otros dos que controlan el acceso de los usuarios al sistema. Estos dos scripts son cn_min y cn_hour. cn_min se encarga de comprobar la tabla de conexiones activas para ver si algún usuario ha llegado a su fin y hay que desconectarlo. cn_hour se encarga de comprobar que en la tabla member de la base de datos nocat, están los usuarios que están en un periodo activo en ese momento. Es decir, tiene que insertar los usuarios cuando entran en un periodo de activación, y borrarlos cuando salen del mismo. A continuación se explica el funcionamiento de los scripts con más detalle.

• conexion. Este script se invoca en el servidor de autenticación desde la pasarela cada vez que un usuario se conecta. Cuando el usuario ha sido autenticado, y la pasarela ha insertado la nueva regla en el cortafuegos para permitir navegar al usuario, la pasarela invoca por ssh el script conexion, que se ejecuta en el servidor de autenticación. Este script llama a la función conexion del módulo ControlNocat que lee de la tabla activacion los datos del usuario, concretamente los campos tarifacion, baja, bono y tarifa. Seguidamente guarda en la tabla conexiones los datos correspondientes:
  • El login es un parámetro que se pasa desde la pasarela.
  • Para rellenar inicio utiliza la función NOW() que proporciona MySQL,
  • En fin guarda el campo baja que ha consultado en activacion en todos los casos excepto en el caso de que la conexión sea de tipo pospago, en cuyo caso se almacena el valor NULL. Si es de tipo bono, se le suma el campo bono de activacion al momento actual y se inserta el resultado en el campo fin.
  • La ubicación es un parámetro que se le debe pasar desde la pasarela.
  • La tarifa se rellena desde el valor que se consulta en activacion.
  • El campo facturado se rellena con el valor 'no'. Este campo sólo se utiliza para las conexiones pospago y como es lógico no se puede facturar hasta que la conexión termine.
  En la figura 3.2 se observa el funcionamiento del script conexion^3.3.

  Figura 3.1: Leyenda de los diaframas de flujo

  

  Figura 3.2: Conexion

  
• salida. Este script, al igual que conexion se invoca desde la pasarela, y se invoca justo después de eliminar las reglas del cortafuegos que permitían el acceso de dicho usuario. Esto se puede producir por varios motivos que son: primero que el usuario pulse el botón de logout, en segundo lugar porque el usuario cierre el popup y la conexión expire, o en tercer lugar cuando nosotros borramos del servidor a dicho usuario y el servidor indica a la pasarela que debe cortarle el servicio. Cuando una de estas tres situaciones ocurre la pasarela invoca el script salida con un parámetro que se corresponde con el login del usuario que acaba de abandonar el sistema. El script salida llama a la función salida del módulo ControlNocat.pm que borra la fila correspondiente en conexiones y copia el valor en el histórico de conexiones. En el campo fin se vuelve a utilizar la función NOW() que nos ofrece MySQL. En el caso de que la conexión fuera de tipo bono, se calcula la duración de la misma y se resta al valor de bono en la tabla activacion la duración de la conexión. De esta manera la siguiente vez que se conecte en la tabla activacion seguirá estando el tiempo que le queda por consumir. En el caso de que la duración haya sido mayor que el valor que le quedaba por consumir se almacena 00:00:00. Este caso puede ocurrir ya que el sistema que vamos a utilizar no será exacto y puede dejar ''un minuto de gracia'' a los usuarios, este tema se verá en el siguiente punto. El funcionamiento del script salida está descrito en la figura 3.3.

  Figura 3.3: Salida

  
• cn_min. Es un proceso que se demoniza^3.4, y se conecta con la base de datos ControlNocat. Lo que hace este proceso es llamar a la función check_1min una vez por minuto, concretamente está ajustado para que lo haga cuando los segundos marcan 00. Véase la figura 3.4. La función check_1min^3.5 comprueba en la tabla conexiones si existe alguna conexión en la que el campo fin sea anterior o igual al momento actual, si esto ocurre quiere decir que hay que cortar el servicio de este usuario. Para cortar el servicio se borra al usuario de la tabla member y de la tabla network de la base de datos nocat. Al borrar al usuario de las tablas de nocat, cuando el popup intente renovar las credenciales del usuario será rechazado y no se enviará nada a la pasarela. De tal manera que cuando expire el tiempo predeterminado en la pasarela el usuario dejará de tener acceso a Internet. Debido a esto, el tiempo que se pondrá en la pasarela será el mínimo permitido que es un minuto, para que el usuario pueda navegar como mucho durante un minuto más de lo contratado. Además de quitarlo de la tabla member de nocat, hay que registrar en el histórico de activación que ha dejado de estar activo. Lo único que hay que hace es actualizar el valor de baja en el histórico con la función NOW(). Cuando el login es borrado de la tabla member se desencadena un proceso que llevará a la pasarela a borrar las reglas del cortafuegos que permitían el acceso de ese usuario, después de borrar esta regla se invocará el script salida que será el encargado de borrar de conexiones y pasar al histórico en ese momento.

  Figura 3.4: cn_min

  

  Figura 3.5: check1_min

  
• cn_hour^3.6. Es un script que se conecta con las bases de datos ControlNocat y nocat, y hace las siguientes comprobaciones:
  1. Consulta los usuarios que están dentro de la tabla member.
  2. Consulta en activacion las entradas donde el campo baja es anterior al momento actual, o bien que el campo bono sea igual a 00:00:00. En cualquiera de estos dos casos lo borra de las tablas member y network de nocat para que no pueda seguir navegando. Asimismo, se actualiza el valor de baja en el histórico. Al borrarlos de la base de datos nocat, si el usuario está conectado, cuando pase un minuto se le denegará el permiso y será invocado el script de salida desde la pasarela. El script de salida será el que se encargue de quitar de la tabla conexiones y pasar al histórico.
  3. Comprueba si existe algún usuario que este dado de alta en activacion y no esté en la tabla member de nocat. En ese caso inserta ese login tanto en la tabla member como en la tabla network de la base de datos nocat.
  Este script será ejecutado una vez por hora y para ello programamos una tarea cron^3.7, de forma que se ejecute una vez cada hora en el minuto que nosotros queramos.

  Figura 3.6: check1_hora

  

Hemos visto que a cada minuto se comprueba la tabla conexiones, mientras que a cada hora se comprueba la tabla activacion. La pregunta que nos podemos hacer es: ¿por qué no se comprueban las dos tablas en cn_min una vez cada minuto? La respuesta a esta pregunta es que en la tabla conexiones sólo están las conexiones activas en un momento determinado y la tabla será relativamente pequeña, sin embargo en la tabla activacion puede haber muchos más usuarios. Debemos tener en cuenta que el servidor de autenticación es centralizado y puede contener la información de muchos usuarios. Imaginemos por ejemplo el caso de una cadena de hoteles con un único servidor para todas sus sedes, en la tabla activacion puede haber miles de entradas. Si se consulta esta tabla a cada minuto podríamos congestionar el sistema, debido a esto se ha decidido que a cada minuto sólo se comprueben las conexiones activas cuyo tamaño será menor. Además es imprescindible consultar esta tabla a cada minuto ya que hay que controlar que un usuario no se conecte si no ha pagado. Si un usuario permanece durante una hora en la tabla activacion debiendo estar fuera no pasa nada ya que esto no supone que esté navegando, de hecho en el momento que intente navegar se borrará de la tabla member y se pasará al histórico. Esto último se realiza en la función check_datos que la veremos en el siguiente punto.

Inicio  |   Acerca de  |   Contactar  

SISTEMA DE CONTROL, TARIFICACIÓN Y ADMINISTRACIÓN DEL ACCESO A INTERNET DESDE REDES HETEROGÉNEAS

: Martín Ruiz, Jesús
: Ingeniería Telecomunicación

Contenido del proyecto:

Directorio raíz  >  05 - html  >  node23.html