Funcionamiento de la pasarela

En el método run (figura A.2) hay un bucle infinito que va atendiendo peticiones y realizando algunas comprobaciones. Para atender las peticiones crea una pila donde va guardando los sockets que se conectan al puerto 5280. Dentro de poll_socket va creando procesos hijos que son los que atienden realmente las peticiones de los clientes. El método que utiliza para atender a los clientes es accept_client (figura A.3).

Figura A.2: Gateway-run

En el método accept_client de la clase Gateway se crea un objeto de la clase Peer que guarda los datos del cliente e inmediatamente llama al método handle de la clase Captive. La clase Captive hereda de la clase Gateway. Es el método handle de la clase Captive el que realmente maneja las conexiones. Primero lee la petición que se recibe en la línea de dirección del explorador, comprueba si va dirigida a él o es una conexión nueva de un cliente que no está autenticado. Cuando un usuario no está autenticado y hace una petición a una web, ésta es redirigida al puerto 5280. Lo que hace en este caso la pasarela es capturar la petición y enviarla al servidor de autenticación. Por el contrario si la petición va dirigida a la pasarela puede ser por tres razones. Es una petición para mostrar el estado de la pasarela, en ese caso se muestra la página status; puede ser una petición de logout, en tal caso se desconecta al cliente del sistema llamando a Gateway->deny(figura A.6); y la tercera opción es que el usuario esté en el proceso de autenticación. Si es así la pasarela ya ha capturado la petición previamente, ha redirigido al usuario al servidor de autenticación y el usuario ha recibido un mensaje cifrado y firmado del servidor de autenticación que es el que en este momento recibe la pasarela para analizar.

Figura A.3: Gateway-accept_client

En primer lugar vamos a ver cómo se capturan las peticiones y despues veremos cómo se verifican los mensajes y se actúa en consecuencia. Para capturar las peticiones se guardan los parámetros del usuario: MAC, token, la dirección que ha solicitado, LoginTimeout y la dirección de la pasarela. Todos estos parámetros se ponen junto con la dirección del servidor de autenticación y se redirige al cliente a esta dirección. De forma que el servidor de autenticación recibe una petición del cliente directamente donde está contenida la información de la pasarela. Para ver cómo actúa el servidor de autenticación vea la sección A.1.2. Por ahora nos basta saber que devuelve un mensaje cifrado y firmado al cliente para ser enviado a la pasarela en cinco segundos. Una vez que ha recibido este mensaje podemos ver cómo actúa el método handle cuando lo recibe. Cuando recibe este mensaje ve que va dirigido hacia él y no es ni una petición del estado ni una petición de logout. Entonces, para analizar este mensaje se llama al método verify de la clase Passive(figura A.4).

Figura A.4: Passive-verify

En el método verify se descodifica el mensaje y se comprueba que el token que trae es el mismo token que nosotros habíamos generado para ese usuario. Se guardan el usuario, su MAC y el grupo al que pertenece y dependiendo de la acción que diga el servidor se llama al método permit(figura A.5) de la clase Gateway, o a método deny(figura A.6). Suponiendo que todo el proceso ha sido correcto el usuario debe estar autenticado y en el método permit se llama al método permit de la clase Firewall que es el que actúa sobre las reglas del cortafuegos. Para esto llama al script access.fw que mediante dos líneas como estas: iptables -t mangle -A NoCat -m -mac-source mac -s ipaddress -j MARK -set-mark marca iptables -t filter -A NoCat_Inbound -d ipaddress -j ACCEPT donde mac, ipaddress y marca son la dirección MAC del cliente, la dirección ip del cliente y una marca, que será 0x1, 0x2 o 0x3 dependiendo de la clase a la que pertenezca el usuario. Como vimos al iniciar el firewall hay una reglas para que los paquetes con las marcas 0x1, 0x2 o 0x3 sean aceptados. El resultado de las iptables cuando un usuario con dirección IP igual a 192.168.1.13 y MAC 00:05:1C:0F:B4:07 está autenticado es el siguiente:

# Generated by iptables-save v1.2.8 on Fri Aug 22 15:25:06 2003
*mangle
:PREROUTING ACCEPT [2813929:2352625211]
:INPUT ACCEPT [605055:294899204]
:FORWARD ACCEPT [2207607:2057559378]
:OUTPUT ACCEPT [492163:255556825]
:POSTROUTING ACCEPT [2698025:2312682229]
:NoCat - [0:0]
-A PREROUTING -j NoCat 
-A OUTPUT -p tcp -m tcp --dport 22 -j TOS --set-tos 0x10 
-A OUTPUT -p tcp -m tcp --dport 80 -j TOS --set-tos 0x08 
-A OUTPUT -p tcp -m tcp --dport 443 -j TOS --set-tos 0x08 
-A OUTPUT -p tcp -m tcp --dport 22 -j TOS --set-tos 0x10 
-A OUTPUT -p tcp -m tcp --dport 80 -j TOS --set-tos 0x08 
-A OUTPUT -p tcp -m tcp --dport 443 -j TOS --set-tos 0x08 
-A NoCat -i eth1 -j MARK --set-mark 0x4 
-A NoCat -s 192.168.1.13 -m mac --mac-source 00:05:1C:0F:B4:07 -j 
MARK --set-mark 0x2 
COMMIT
# Completed on Fri Aug 22 15:25:06 2003

La nueva línea que vemos es la última de la cadena NoCat y marca los paquetes con origen la dirección IP y la dirección MAC del cliente que se conecta. A partir de ahora todos los paquetes de ese usuario serán marcados con la marca 0x2, y vimos anteriormente que al iniciar la pasarela había un regla en la tabla NAT para enmascarar los paquetes con la marca 0x2 y una regla en la tabla filter para dejarlos pasar.

# Completed on Fri Aug 22 15:25:06 2003
# Generated by iptables-save v1.2.8 on Fri Aug 22 15:25:06 2003
*filter
:INPUT ACCEPT [27298:29394652]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [25151:119102926]
:NoCat - [0:0]
:NoCat_Inbound - [0:0]
:NoCat_Ports - [0:0]
-A FORWARD -j NoCat 
-A NoCat -j NoCat_Ports 
-A NoCat -j NoCat_Inbound 
-A NoCat -s 192.168.1.0/255.255.255.0 -i eth1 -m mark --mark 0x1 -j ACCEPT 
-A NoCat -s 192.168.1.0/255.255.255.0 -i eth1 -m mark --mark 0x2 -j ACCEPT 
-A NoCat -s 192.168.1.0/255.255.255.0 -i eth1 -m mark --mark 0x3 -j ACCEPT 
-A NoCat -s 192.168.1.0/255.255.255.0 -d 192.168.1.32 -p tcp -m tcp 
   --dport 80 -j ACCEPT 
-A NoCat -s 192.168.1.32 -d 192.168.1.0/255.255.255.0 -p tcp -m tcp 
   --sport 80 -j ACCEPT 
-A NoCat -s 192.168.1.0/255.255.255.0 -d 192.168.1.32 -p tcp -m tcp 
   --dport 443 -j ACCEPT 
-A NoCat -s 192.168.1.32 -d 192.168.1.0/255.255.255.0 -p tcp -m tcp 
   --sport 443 -j ACCEPT 
-A NoCat -s 192.168.0.254 -d 192.168.1.0/255.255.255.0 -o eth1 -j ACCEPT 
-A NoCat -s 192.168.1.0/255.255.255.0 -d 192.168.0.254 -i eth1 -p tcp 
   -m tcp --dport 53 -j ACCEPT 
-A NoCat -s 192.168.1.0/255.255.255.0 -d 192.168.0.254 -i eth1 -p udp 
   -m udp --dport 53 -j ACCEPT 
-A NoCat -s ! 192.168.1.32 -i eth0 -p tcp -m tcp --dport 5280 -j DROP 
-A NoCat -j DROP 
-A NoCat_Inbound -d 192.168.1.13 -j ACCEPT 
-A NoCat_Ports -i eth1 -p tcp -m tcp --dport 5280 -j ACCEPT 
-A NoCat_Ports -i eth1 -p udp -m udp --dport 5280 -j ACCEPT 
COMMIT
# Completed on Fri Aug 22 15:25:06 2003

La única línea nueva corresponde a la cadena NoCat_Inbound y establece que se acepten todos los paquetes que vayan dirigidos hacia el cliente.

Figura A.5: Gateway-permit

En el caso de que se llame al método deny. Esto puede ocurrir por varias razones: el usuario pulse logout, expire el tiempo marcado en la directiva Logintimeout sin recibir una autenticación, o que el servidor mande en el mensaje que no está autenticado. En cualquiera de estos casos se llama al método deny de la clase Gateway, que realiza la operación inversa al método permit. Es decir llama al método deny de la clase firewall que vuelve a llamar al script access.fw, pero esta vez diciendo que debe borrar las reglas insertadas antes. De tal manera que los paquetes de dicho usuario dejan de estar marcados con una marca de privilegio, y se vuelven a marcar con 0x4. Entonces la próxima petición que haga ese usuario volverá a ser redirigdo al puerto 5280 de la pasarela y vuelve a empezar el proceso.

Figura A.6: Gateway-deny

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  >  node85.html