navegación autenticada con Squid

El siguiente post muestra un ejemplo de cómo permitir que alguien pueda navegar por Internet solo si se ha autenticado. Es un ejemplo real donde todos los usuarios reciben una IP por DHCP (192.168.1.0/24) y los usuarios "invitados" reciben por DHCP una IP de un rango concreto (192.168.10.0/24).

Dado que todos los usuarios acceden a Internet vía Squid utilizaremos las opciones de autentificación (auth_parm) para logear a los usuarios. Primero de todo creamos un archivo con los usuarios y passwords de los invitados:

# touch /etc/squid/squid.users
# htpasswd /etc/squid/squid.users invitado1
# htpasswd /etc/squid/squid.users invitado2
...

Ahora editamos el archivo de configuración de Squid y configuramos los parámetros auth_parm:

auth_param basic children 3
auth_param basic realm Acceso a Internet restringido. Introduzca su usaurio y 
   contraseña...
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid.users
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Esta es la descripción de los parámetros anteriores:

+ auth_parm basic children: numero de procesos/daemons que realizaran la autentificación. Dependerá un poco del número total de usuarios que puedan acceder a Internet en un momento dado.
+ auth_parm basic real: es el mensaje que saldrá en la ventana de login de tú navegado.
+ auth_parm basic program: definimos el sistema de autentificación y dónde debe buscar los usuarios. + auth_parm basic credentialsttl: especifica el tiempo que estará validado el usuario antes de volverle a pedirle el login.
+ auth_parm basic casesensitive: define si el nombre de usuario es case-sensitive.

Creamos ahora la ACL para decirle sobre que rango debe Squid pedir un login:

acl ip_invitados src 192.168.10.0/24
acl ip_lan src 192.168.1.0/24
acl auth_invitados proxy_auth REQUIRED
...
http_access allow ip_invitados auth_invitados
http_access allow ip_lan
http_access deny all

Básicamente lo que se necesita son dos listas de accesos. Una para definir las IPs que queremos logear (ip_invitados) y otra para definir el requisito de una autentificación (auth_invitados).

Existen varios métodos de autentificación cómo Basic, Digest, NTLM, Negotiate, cada uno de ellos pudiendo atacar contra un backend diferente: LDAP, MySQL, Radius, Active Direcotory, etc. Aquí hay algunos ejemplo con diferentes configuraciones.

wavecom wmod2a (parte ii de ii)

Una vez tenemos las tools de Gammu funcionando es hora de montar nuestro gateway. El gateway tendrá un daemon que escuchará el módem y meterá los SMS en una BBDD. Para enviar utilizaremos el comando gammu tal como hemos visto en la primera parte del post.

Para facilitar las cosas utiizaremos una pagina Web escrita en PHP.

Instalamos Apache+MySQL+PHP:

# apt-get install apache2 php5 libapache2-mod-php5 
# apt-get install libapache2-mod-auth-mysql php5-mysql mysql-server mysql-client
# apt-get install libmysqlclient15-dev

Los mensajes SMS recibidos al módem SMS irán almacenados en una BBDD MySQL, para ello tendremos que crear un schema con las tablas necesarias para añadir esta info. Dentro de /usr/share/doc/gammu/examples/sql/mysql.sql.gz econtraremos un schema de tablas que podemos utilizar:

# cp /usr/share/doc/gammu/examples/sql/mysql.sql.gz /tmp
# gunzip /tmp/mysql.sql.gz
# mysqladmin -u root -p create sms
# mysql -u root -p sms < /tmp/mysql.sql

Ahora le decimos al Gammu que los mensajes recibidos los guarde en las tablas de MySQL. Para ello editamos la configuración y añadimos estos parámetros a los ya existentes:

# cat /etc/gammurc
...
[smsd]
#service = files
service = MYSQL
logfile = syslog
CheckSecurity = 0
debuglevel = 1
user = root
password = 12345
pc = localhost
database = sms
inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/

Nota: Podemos utilizar diferentes tipos de backends. En la configuración anterior se puede utilizar MySQL o directamente ficheros planos alojados en /var/spool/gammu.

Para facilitar la lectura de estas tablas MySQL, hay creada una interfaz PHP que nos ayuda a leer los mensajes recibidos:

# cd /var/www
# wget http://www.syednetworks.com/gammu-sms-gateway.zip
# unzip gammu-sms-gateway.zip

Ahora podemos acceder a esta interfaz desde http://127.0.0.1/gammu-sms-gateway/sms.php. Para que el script sms.php acceda a vuestro MySQL deberéis cambiar la password de acceso a la base de datos por la que tengáis puesta:

Para ello editar el sms.php y cambiamos esta linea:

mysql_connect("localhost", "root", "") or die(mysql_error());

Instalamos y arrancamos el daemon que esperará la llegada de los SMSs:

# apt-get install gammu-smsd
# gammu-smsd -c /etc/gammurc &

Si enviamos un SMS a nuestro módem GSM y vamos mirando el log podremos ir viendo como van entrando los mensajes y cómo se van actualizado las tablas:

# tail -f /var/log/syslog
gammu-smsd[5813]: gammu: 3 "OK"
gammu-smsd[5813]: gammu: RECEIVED frametype 0x00/length 0x1B/27
gammu-smsd[5813]: gammu: 41A|54T|2B+|43C|53S|51Q|0D |0D |0A |2B+|43C|53S|51Q|
   3A:|20 |311 AT+CSQ...+CSQ: 1
gammu-smsd[5813]: gammu: 377|2C,|300|0D |0A |0D |0A |4FO|4BK|0D |0A 
   7,0....OK..     
gammu-smsd[5813]: gammu: Signal quality info received
gammu-smsd[5813]: gammu: Parsing +CSQ: 17,0 with +CSQ: @i, @i
gammu-smsd[5813]: gammu: Parsed int 17
gammu-smsd[5813]: gammu: Parsed int 0
gammu-smsd[5813]: gammu: Leaving GSM_GetSignalQuality
gammu-smsd[5813]: Execute SQL: UPDATE `phones` SET `TimeOut`= (NOW() + 
   INTERVAL 10 SECOND)+0, `Battery`= 0, `Signal`= 51 WHERE `IMEI` = 
   '330122330387360'

Por ultimo queda la parte del envío de SMS. Para ello, desde la pagina sms.php encontraremos un link llamado "Send SMS message" que nos permitirá enviar un SMS desde un formulario Web. Este link llama al archivo send-sms.php. Si lo editamos podremos ver como lo único que realiza es una llamada al binario de gammu:

system( 'sudo /usr/bin/gammu --sendsms EMS ' . escapeshellarg( $destination ) . 
' -text ' . escapeshellarg( $message ) );

Es posible que el path de nuestro binario gammu no corresponda con el de la pagina. Tendremos que cambiar /usr/logal/bin/gammu por /usr/bin/gammu.
Notar que también he añadido la ejecución del comando bajo sudo. Esto es debido a que el usuario que hace la llamada a la función system() es www-data y este usuario no tiene permisos para ejecutar comandos como gammu.

Para que el sudo no pregunte password tenemos que editar el /etc/sudoers y añadir esto:

# cat /etc/sudoers
...
%sudo ALL=NOPASSWD: ALL

Es posible que no tengáis permisos para escribir sobre el fichero de sudoers. Hay que poner permisos de escritura y luego dejarlos como estaba.

Finalmente tenemos que decirle quienes son los usuarios que están dentro de sudoers. Para ello editamos el /etc/groups y modificamos el grupo sudo:

# cat /etc/group | grep sudo
sudo:x:27:usuario1,www-data

wavecom wmod2a (parte i de ii)

Vamos a montar un gateway para enviar y recibir mensajes SMS. La idea es montar este servicio para poder utilizarlo en Nagios y así poder enviar alertas vía SMS.

En verdad se puede realizar con cualquier teléfono móvil, pero esta vez utilizaré un hardware dedicado y especifico para ello un módem GSM Wavecom modelo wmod2a-g900.

El módem se comunicará con el servidor vía interfaz serie, pero como ya no quedan servidores con puerto de serie utilizaré un conversor USB-to-serial. Por tanto lo primero es ver que se detecta correctamente el conversor:

# dmesg | grep USB
[   77.187320] USB Serial support registered for generic
[   77.187348] usbserial: USB Serial Driver core
[   77.196733] USB Serial support registered for pl2303
[   77.208730] usb 6-2: pl2303 converter now attached to ttyUSB0
[   77.208746] pl2303: Prolific PL2303 USB to serial adaptor driver

Ahora instalaremos el soft básico para acceder al módem. Como todo modem, podríamos acceder a el vía comandos AT, pero tendríamos que leernos la documentación del dispositivo. Utilizaremos las herramientas gratuitas de Gammu:

# apt-get install gammu

Encontraremos un archivo de configuración de ejemplo en /usr/share/doc/gammu/examples/config/gammurc.gz. Nosotros crearemos uno con estos parámetros:

# cat /etc/gammurc
[gammu]
port = /dev/ttyUSB0
connection = at19200
name = wavecom
logformat = textall
logfile = gammu.log
startinfo = yes
use_locking = yes
gammuloc = locfile

Cómo puede verse el dispositivo /dev/ttyUSB0 indica la interfaz donde está conectada el módem GSM.

Una vez encendido el módem veamos si las tools de Gammu son capaces de reconocer el modem. Yo recomiendo quitarle el PIN a la tarjeta SIM para evitar problemas. De esta forma cada ver que reiniciemos el módem este estará listo para enviar SMS:

# gammu -c /etc/gammurc identify
Manufacturer         : Wavecom
Model                : unknown (900P)
Firmware             : 320_G250.53 833584 092499 18:13
IMEI                 : 330142330387360
SIM IMSI             : 214071617085412

Enviemos ahora nuestro primer SMS a otro teléfono y veamos que efectivamente está funcionando:

# echo hola | gammu -c /etc/gammurc sendsms TEXT 6938888888
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=115

Más información:
+ Wavecom AT Commands Guide

montando servidores para pequeñas oficinas

Tenemos una pequeña oficina en Portugal donde varios de sus usuarios se conectan remotamente vía cliente software de VPN. Ahora que van a mejorar sus comunicaciones (creo que se ponen una linea de simétrica de más de 2Mb) es hora de enviarles un router que genere las VPNs y que los clientes no tengan que hacer nada para acceder a la central que está en España.

Dado que utilizamos Linux y OpenVPN para conectar esta oficina y los usuarios que viajan enviaremos un servidor que genere estas VPNs. La idea es montarles el servidor de OpenVPN en el dispositivo más pequeño que encontremos, enviarlo por correo, que se lo pinchen a la red y listo...

Pues bien, después de mucho buscar he encontrado esta maravilla llamada ARTIGO: placa pico-ITX, CPU VIA, 1 Ethernet, 4 USB y un video. Lo mínimo para montar un router con Linux. Viene todo desmontado como si fuera puzzle para que lo disfrutes montándolo. Sólo tienes que ponerle la memoria DDR que quieras y el disco IDE o SATA que quieras. Yo he optado por un disco solido. Al realizar funciones de router no quiero partes moviles que puendan romperse con el paso del tiempo.
Aquí tenéis un proveedor oficial en españa: http://www.ibertronica.es/artigo.htm.

Por lo que he leido también tiene un kit para añadirle una antena Wifi.


Para quién le guste el mundo de los mini PCs o busque otros modelos para montarse un barebone aquí tiene esta página: http://www.mini-itx.com/

coordinar un cambio de MX

Esta semana hemos migrado las cuentas de correo de un servidor Postfix en Linux a un servidor Lotus Domino en AIX en una maquina física diferente y en otro centro diferente. Entre todas las cosas que hay que coordinar en esta migración una de ellas es el cambio de los registros MX para que dejen de apuntar a la maquina Postfix y apunten a la nueva maquina Domino.

Dependiendo de la forma de trabajar de cada departamento de IT nosotros hacemos estos cambios un viernes por la tarde de forma que sí algo falla tenemos el fin de semana para arreglar el estropicio y que todo funcione el Lunes… aunque esto depende de cada uno.

Durante un cambio en los servidores, una cosa muy importante que tenemos que controlar es el DNS y en especial los registros MX y TXT. Todos los dominios dados de alta en un DNS tienen un campo asignado donde se indica el TTL (tiempo-de-vida) de los registros.
Este valor en muy importante durante una migración ya que indica el tiempo de caducidad de los registros de nuestro dominio. Por ejemplo, si ponemos un TTL de tres dias y realizamos un cambio en los registros MX , eso querrá decir que el resto del mundo no se enterará que hemos cambiado de MX hasta tres días después. Hasta que no pasen tres dias no volverán a consultar los registros de este dominio.

Aquí tenemos un ejemplo de registro de dominio donde se especifica tres dias de TTL:

$TTL 3D
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609206       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
                        NS      ns2.psi.net.

Por tanto, tres días antes de hacer la migración es aconsejable cambiar este TTL por ejemplo a 5 minitos. El campo TTL se indica en segundos desde 0 a 214748364 (64 años). El 0 indica a los DNS que no cacheen los registros.

Pondríamos un:

$TTL 300

Una vez llegado el día de la migración podemos cambiar los registros MX (o cualquier otro registro) con tranquilidad, sabiendo que nuestro cambio estará disponible a nivel mundial cada 5 minutos. Una vez hecha la migración y hayamos comprobado que ya recibimos correo desde el exterior a nuestro nuevo servidor, podemos volver a dejar el valor por defecto del TTL de nuestro DNS. Cómo reglar general el campo TTL lo utilizan los daemons de DNS para controlar la caducidad pero esto depende mucho de la implementación y la configuración no-estándar que sigan el resto de servidores de DNS.
Para ir comprobando si ya hemos propagado este cambio al resto de DNS podemos utilizar herramientas externas como www.mxtoolbox.com.

Otro de los registros que debemos modificar durante la migración del correo y que siempre se olvida es el registro TXT para aquellos que tengamos o deseemos activar el SPF (Sender Police Framework). Recordar que los registros MX indican las maquinas aceptadas para recibir el correo de un dominio y SPF indica las maquinas aceptadas para el envío de correo de ese dominio. SPF se inventó para combatir el problema del Spam. Cómo históricamente no existía ningún registro SPF en el DNS se optó por utilizar el registro TXT existente que hasta hace poco no servía para nada.

Aquí tenéis un ejemplo del registro TXT:

TXT = "v=spf1 ip4:214.229.188.0/25 ip4:80.34.132.42 mx -all"

Lo que indica esta línea es que las maquinas autorizadas para el envío de correo desde dicho dominio son las maquinas dentro de la red 214.229.188.0/25, la maquina 80.34.132.42, la maquinas especificadas en los MX y ninguna más.

ethernet failover (parte 2 de 2)

Dentro del archivo de configuración /etc/modprobe.conf podemos utilizar diferentes modos de tolerancia a fallos o balanceo de carga.

options bonding mode=<modo> miimon=<msg> downdelay=<msg> updelay=<msg>

El bonding intenta conseguir estos modos:
+ alta disponibilidad: si una interfaz física deja de funcionar el trafico es redireccionado por la otra interfaz.
+ balanceo de carga: el trafico entrante o saliente se puede ir repartiendo por diferentes interfaces a fin de multiplicar el ancho de banda.
Con estas características se definen 7 modos de bonding:

+ modo 0 o balance-rr: se balancea el trafico de la red utilizando el algoritmo de Round-Robin. Con este modo tenemos alta disponibilidad y balanceo.

+ modo 1 o active backup: creo que es el más sencillo. Solo se utiliza una interfaz activa y las otras estan en reposo en caso de fallo. Hay alta disponibilidad pero no balanceo de carga.

+ modo 2 o balanceo-xor: asigna una interfaz a un conjunto de clientes y la otra interfaz a otro conjunto de cliente. Para ello utiliza una formula con la operación binaria xor. Tenemos balanceo de la carga pero no alta disponibilidad.

+ modo 3 o broadcast: se envía la información por todas las interfaces. No veo que este metodo sea una buena idea ¿no?. Hay alta disponibilidad pero no balanceo.

+ modo 4 o 802.3ad: no lo entiendo mucho, pero básicamente lo que hace es formar agrupaciones de interfaces activas y otras esclabas. Este método se basa en un estandard de trunking 802.3ad.

+ modo 5 o balanceo-tbl: el trafico que sale se balancea por cada interfaz. Permite alta disponibilidad y balanceo. Es la mejor alternativa.

+ modo 6 o balanceo-alb: igual que el anterior pero también se balancea la recepción.

Pasemos ahora a explicar los diferentes parámetros del bonding:

+ modo: es el modo de funcionamiento (0,1,2,3,4,5,6 o 7) tal como hemos explicado en el punto anterior.

+ miimon: es el tiempo en milisegundos entre chequeo y chequeo del estado de cada interfaz física.

+ downdelay: tiempo en milisegundos para considerar que una interfaz física ha caido.

+ updelay: tiempo en milisegundos para considerar que una interfaz vuelve a funcionar.

Como regla general los modos 6 y 7 son los recomendados o habituales ya que cada tarjeta física se conectará a un switch diferente. Durante el balanceo cada interfaz utilizará su propia dirección MAC.

En el caso de los modos 0 y 2, las interfaces físicas pueden ir a mismo switch, pero el caso del modo 1 no ya que se dará el caso en que el switch tendrá la misma MAC por dos interfaces físicas diferentes.

ethernet failover (parte 1 de 2)

Supón que tienes un servidor con varias maquinas virtuales dando servicio y que quieres asegurar la conectividad con la red. Al igual que redundamos las fuentes de alimentación o los discos montando RAIDs, también podemos redundar las interfaces de red Ethernet para asegurar una conectividad de alta disponibilidad. El siguiente esquema de red es típico de un entorno de virtualización, pero puede ser extensible a cualquier tipo de servicio crítico como puede ser una maquina de correo.

La técnica que utilizaremos es el bonding (o vinculación) en la cual crearemos una interfaz virtual vinculada a dos (o más) interfaces Ethernets físicas.


Como veis en el siguiente esquema cada interfaz de red se conecta a un switch redundando y cada switch a su backbone.

Lo que haremos es crear una interfaz virtual llamada bond0 y vincularla con eth0 y eth1. Supondremos que estamos en un CentOS 4.5. Editaremos el /etc/modprobe.conf para que el kernel arranque el modulo de bonding:

alias bond0 bonding
options bond0 miimon=80 mode=5

Ahora crearemos la interfaz virtual bond0. Creamos el archivo /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
IPADDR=192.168.1.100
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
GATEWAY=192.168.1.1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

Una vez creada la interfaz virtual editamos nuestras dos interfaces físicas (eth0 y eth1) con este contenido:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

Ahora solo queda reiniciar y hacer pruebas de conectividad con los cables de red para comprobar que efectivamente no perdemos conexión si desconectamos eth0 o eth1.

Si hacemos un ifconfig, veremos como la interfaz virtual es la que coge la dirección IP:

bond0     Link encap:Ethernet  HWaddr 00:1E:C9:D6:DA:6E  
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:c9ff:fed6:da6e/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:5157067 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3927169 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2601662632 (2.4 GiB)  TX bytes:2306432451 (2.1 GiB)

eth0      Link encap:Ethernet  HWaddr 00:1E:C9:D6:DA:6E  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3593230 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2807046 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2459234475 (2.2 GiB)  TX bytes:2154634747 (2.0 GiB)
          Interrupt:194 Memory:dc000000-dc012800 

eth2      Link encap:Ethernet  HWaddr 00:1E:C9:D6:DA:72  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1563837 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1120123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:142428157 (135.8 MiB)  TX bytes:151797704 (144.7 MiB)
          Interrupt:170 Memory:d8000000-d8012800 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6917 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6917 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:6525082 (6.2 MiB)  TX bytes:6525082 (6.2 MiB)

En el siguiente post veremos lo diferentes modos de funcionamiento del bonding y las precauciones que tenemos que tomar según el modo seleccionado.

Más información:
+ Linux Channel Bonding

balancing y failover

Tengo hasta 5 conexiones de salida a Internet, entre caudales garantizados, ADSL, SDSL, etc.
La idea es centralizar todas estas salidas bajo un único gateway de forma que podamos hacer balanceo de carga y failover. Con el balanceo de carga conseguimos que unas peticiones vayan por una línea y otras por otra de forma automática y transparente para el usuario. Con el failover conseguimos que en caso de caída de una conexión de salida, todo el tráfico continuará saliendo por otra conexión.
Hay que tener presente que esta solución no hace una suma de anchos de banda, simplemente reparte las peticiones sobre una u otra conexión.

En el siguiente ejemplo utilizaremos dos conexiones a Internet ADSL, las dos de 6Mb. Utilizaremos una maquina Linux con tres interfaces Ethernet. Una conectada a una ADSL, otra conectada a otra ADSL y por último una interfaz conectada a nuestra red interna. Esta máquina hará de gateway de todos nuestros usuarios de la red interna.

En vez de utilizar una ruta por defecto, configuraremos una ruta por defecto que es multicamino o "multi-path route". Por defecto el kernel equilibrará las rutas sobre los dos posibles proveedores.


Para realizar balanceo utilizaremos iproute y para realizar el failover utilizaremos el siguiente script gwping que es un daemon (escrito en bash) que lo que hace es comprobar cada cierto tiempo el estado de la línea. Si la línea cae automáticamente realiza el switch. Cuando las dos líneas están activas continua haciendo el balancing.

Lo primero que hacemos es añadir estas instrucciones dentro de nuestro /etc/rc.local:

# activamos el forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# le decimos que todos los paquetes que vienen por una ADSL vuelven por la misma.
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.10 table ADSL1
ip route add default via 192.168.1.1 table ADSL1
ip route add 192.168.0.0/24 dev eth1 src 192.168.0.10 table ADSL2
ip route add default via 192.168.0.1 table ADSL2
ip rule add from 192.168.1.10 table ADSL1
ip rule add from 192.168.0.10 table ADSL2

# la carga se reparte (equitativamente) por diferentes gateway.
ip route add default scope global nexthop via 192.168.1.1 dev eth0 weight 1 
   nexthop via 192.168.0.1 dev eth1 weight 1

# activamos el nat en el gateway
iptables -F
iptables -t nat -F
iptables --delete-chain
iptables -t nat --delete-chain
iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
iptables -A INPUT -p ICMP -j ACCEPT
iptables -A INPUT -p TCP -m state --state RELATED -j ACCEPT
iptables -A FORWARD --in-interface eth2 -j ACCEPT

nohup /usr/sbin/gwping &

Observar como se utiliza el parámetro “weight” para decir que las dos adsl tienen la misma importancia. Tienen la misma velocidad. Si tuviéramos una ADSL 4 veces más rápida que otra pondríamos algo como:

ip route add default scope global nexthop via 192.168.1.1 dev eth0 weight 1 
   nexthop via 192.168.0.1 dev eth1 weight 4

El siguiente paso es añadir las tablas ADSL1 y ADSL2 dentro del iproute. Para ello editamos el /etc/iptables2/rt_tables:

root@failover:~# cat /etc/iproute2/rt_tables 
255     local
254     main
253     default
0       unspec
1 ADSL1
2 ADSL2

Ahora copiamos nuestro script gwping a /usr/sbin y le damos permisos de ejecución:

# chmod 755 /usr/sbin/gwping

Si editamos el script gwping podemos configurar los primeros parámetros para ajustarlos a nuestra configuración.

+ EXTIF1 y EXTIF: nombre de la interfaces externas
+ IP1 e IP2: IP de las interfaces
+GW1 y GW2: IP de las ADSLs
+ W1 y W2: peso de cada una de las ADSLs
+ NAME1 y NAME2: nombre de las ADSLs

Una vez reiniciada la maquina debería correr en fondo el daemon gwping (ps –xa | grep gwping). Para comprobar que todo está funcionando debería crearse un fichero de log llamado /var/log/failover donde es posible comprobar como se va realizando el switch entre las ADSLs:

root@failover:/var/log# tail -f failover 
Ping status changed for ADSL2 from 1 to 0
Uptime status will be changed for ADSL1 from 1
Uptime status will be changed for ADSL2 from 1
Restoring default load balancing
ADSL2 Down
Ping status changed for ADSL2 from 0 to 1
Uptime status will be changed for ADSL2 from 0
Ping status changed for ADSL2 from 1 to 0
Uptime status will be changed for ADSL2 from 1
Restoring default load balancing
ADSL1 Down
Ping status changed for ADSL1 from 0 to 1
Uptime status will be changed for ADSL1 from 0
Switching to ADSL2
ADSL1 Down
ADSL1 Down
Ping status changed for ADSL1 from 1 to 0
Uptime status will be changed for ADSL1 from 1
Restoring default load balancing
ADSL1 Down

Para comprobar que todo funciona podéis hacer diferentes consultas desde diferentes usuarios de la red interna a paginas web como http://www.whatismyip.com y comprobar vosotros mismos como se obtienen IPs diferentes dependiendo de si la petición HTTP ha ido por una ADSL u otra.

Más información:
+ Routing por diferentes proveedores
+ Linux Advanced Routing & Traffic Control HOWTO

squid y mrtg

El proxy de Squid nos permite generar gráficas desde cualquier aplicación o cliente SNMP. Para ello simplemente debemos activar el servicio de SNMP en el Squid y comenzar a realizar consultas para saber que carga o uso tiene.
Para ello editamos el /etc/squid/squid.conf y añadimos las siguientes líneas:

# creamos una acl donde le decimos el nombre de la comunidad SNMP que utilizamos
acl snmppublic snmp_community public
# por defecto utilizaremos el puerto 3401/UDP para las consultas
snmp_port 3401
# aplicamos la ACL para que solo la maquina local pueda realizar consultas
snmp_access allow snmppublic localhost
snmp_access deny all

Una vez configurado hacemos un reload de la config:

# /etc/init.d/squid reload

Ahora probamos con el comando snmpwalk si tenemos acceso al servicio SNMP de Squid:

# snmpwalk –c public -v 1 localhost:3401 .1.3.6.1.4.1.3495.1.1                            
SNMPv2-SMI::enterprises.3495.1.1.1.0 = INTEGER: 65552
SNMPv2-SMI::enterprises.3495.1.1.2.0 = INTEGER: 6288060
SNMPv2-SMI::enterprises.3495.1.1.3.0 = Timeticks: (129933578) 15 days, 0:55:35.78

Instalamos la herramienta de MRTG (Multi Router Traffic Grapher) que nos permitirá realizar gráficos del uso de Squid. MRTG generará una página Web cada 5 minutos con los datos. Para ello necesitaremos tener también Apache:

# apt-get install mrtg apache

Creamos el fichero de configuración del MRTG para generar dos tipos de gráficos diferentes:

ImageDir: /var/www/mrtg-squid
Workdir: /var/www/mrtg-squid
LoadMIBS: /etc/squid/mib.txt

Target[proxy-hit]: cacheHttpHits&cacheServerRequests:public@127.0.0.1:3401
MaxBytes[proxy-hit]: 100000
Title[proxy-hit]: HTTP Hits
PageTop[proxy-hit]: <H2>proxy Cache Statistics: HTTP Hits/Requests</H2>
Suppress[proxy-hit]: y
LegendI[proxy-hit]:  HTTP hits
LegendO[proxy-hit]:  HTTP requests
Legend1[proxy-hit]:  HTTP hits
Legend2[proxy-hit]:  HTTP requests
YLegend[proxy-hit]: perminute
ShortLegend[proxy-hit]: req/min
Options[proxy-hit]: nopercent, perminute, dorelpercent, unknaszero, growright

Target[proxy-srvkbinout]: cacheServerInKb&cacheServerOutKb:public@127.0.0.1:3401
MaxBytes[proxy-srvkbinout]: 76800
Title[proxy-srvkbinout]: Cache Server Traffic In/Out
PageTop[proxy-srvkbinout]: <H2>Cache Statistics: Server traffic volume (In/Out)</H2>
Options[proxy-srvkbinout]: growright

Tanto las paginas Web como los datos de las estadísticas generados por MRTG se guardaran en /var/www/mrtg-squid. Si no existe la carpeta habrá que crearla.
Por otro lado necesitaremos el archivo /etc/squid/mib.txt donde se especifican los objetos que se deben monitorizar dentro de Squid. Se puede descargar de los archivos fuentes del Squid o de aquí.

Ahora solo hace falta ejecutar el MRTG cada 5 minutos. Para ello editamos el /etc/crontab y añadimos la siguiente línea:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * root LANG=C /usr/bin/mrtg 
   /etc/squid/mrtg-squid.conf --debug="cfg"

Al cabo de unas horas ya podrás apreciar el uso de tú Squid. Al leer los gráficos del MRTG es muy importante saber bajo que velocidad está generado el gráfico para poder compararlo por ejemplo con el gráfico de tú conexión a Internet. En este caso el gráfico “Squid volum traffic” está en KB/s (Kilobytes por segundo).


Podrás acceder a dos tipos de gráficos: el “http Hits and request” (http:///mrtg-squid/proxy-hit.html) y el “Squid traffic volumn” (http:///mrtg-squid/proxy-srvkbinout.html).

El segundo de ellos indica en KB/s el volumen de datos que entran y salen del Squid. Para interpretar el primero de ellos debemos tener claro las diferencia entre “http request” y “http hits”. Las “http request” son las peticiones http que realizan los clientes. Las “http hits” son las peticiones servidas por el proxy o más concretamente servidas por la cache del proxy. Es decir, contra más se parezcan los “http request” a los “http hits” mejor está funcionando el proxy porque eso quiere decir que el cliente a pedido una pagina Web que el proxy tenía cacheada.
Existe otro parámetro que es el “percentage” que indica el porcentaje de acierto del proxy. Un porcentaje alto indica que todas las paginas que van pidiendo los usuarios están ya cacheadas por el proxy.

Más información:
+ Configuración de un proxy transparente
+ SQUID and MRTG: to SNMP or not SNMP?

un miniserver con una fonera

Hace unos dias que me calló una Fonera 2.0n y no sé muy bien para que. Para el que no sepa que es una Fonera no es más que un access-point bajo Linux al que se le han añadido servicios. La idea es formar una comunidad de Foneros repartidos por todo el mundo de forma que los Foneros compartan una porción de su ancho de banda de conexión a Internet para que otros puedan utilizarlo.

Puedes encontrar un punto de acceso Fon en el mapa oficial de la comunidad: http://maps.fon.com/

Actualmente hay dos Foneras access-points: la Fonera 2n (la más completa) y la Fonera+ (la básica).

Después de trastearla y jugar con ella he decido deshabilitar la Wifi y utilizarla solo de servidor de descargas para bajar ficheros y torrents. La Fonera 2n, a parte de ser access-point (no es un router que elimina la necesidad de nuestra router-ADSL) contiene toda una interfaz Web para administrar torrents, el Facebook, descarga de archivos, el Youtube, el Flicker, etc. Dado que se trata de un aparato muy pequeño es ideal para dejarlo todo el dia encendido bajando cosas. Además tiene la posibilidad de añadirle una llave o disco USB para ir dejando todo lo que estemos bajando.

Estos son los pasos para convertir tú Fonera en un servidor de descargas:

+ Una vez instalada la Fonera y funcionando tal como indica “La guía de instalación rápida” lo que haremos es actualizar el firmware a una versión Developer. La versión Developer permite tener el puerto SSH de la Fonera abierto y poder trastear por su interior. Mi fonera tenía la 2.2.6_ENDUSER y le he puesto la versión 2.3_DEV. Para actualizarla hay que hacer: Panel de control -> Configuración -> Sistema -> Actualizacion Firmware

Para acceder a la configuración Web cargaremos la pagina https://192.168.10.1 una vez que nos hemos conectado al SSID de administración "MyPlace".

+ Cuando tenemos la Fonera con la ultima firmware podemos deshabilitar la compartición libre de nuestra Wifi o el SSID FON_FREE_INTERNET. Haremos: Panel de control -> Configuración -> Fon Spot.
En esto de las Foneras hay dos SSID: uno publico (FON_FREE_INTERNET), que lo acabamos de desactivar y el otro privado (MyPlace) que debe desactivarse por hardware con el interruptor situado detrás de la Fonera.
Una vez hecho esto la Fonera será como otro PC conectado a nuestra red LAN.

Al desconectar las interfaces Wifi debemos acceder directamente vía interfaz Ethernet. Por defecto esta interfaz se configura por DHCP pero desde Panel de control -> Configuración -> Internet es posible asignar una IP a la tarjeta de red de la Fonera. Por ejemplo 192.168.1.99.

+ Ahora lo que tenemos que hacer es activar todos los servicios de administración (Web GUI, SSH, FTP, etc) para que sean accedidos desde nuestro PC de la LAN. Por defecto todos estos servicios solo están disponibles si nos conectamos vía SSID privado, pero lo que queremos es que estén disponibles desde fuera de la Fonera. Para activarlos haremos: Panel de control -> Configuración -> Firewall -> Aplicaciones

Una vez activados todos los servicios deberíamos poder acceder a la Fonera desde nuestra LAN con un https://192.168.1.99.

+ Necesitaremos también un disco o llave USB para las descargas. Una vez introducido, los iconos “Disco USB” y “Navegación de archivos” ya estarán disponibles.

+ Por ultimo solo queda ir al Gestor de descargas o Torrents para controlar nuestras descargas. Para acceder a nuestras descargas podemos ir por carpeta compartida \\192.168.1.99\media con el usuario "fonero" y el password que hayamos puesto durante la instalación.



Nota: al igual que hemos conectado un disco USB, tambien es posible conectar una webcam o una impresora.

Más información:
+ Wiki Fonera 2n