Técnicamente Skype no es nada del otro mundo y tiene una estabilidad bastante mediocre.  Existen otros programas, como Mumble, que realizan mejor la tarea de transmisión de voz y con el añadido de que la comunicación está encriptada de una forma que controla el usuario, no una compañía sujeta a las necesidades de terceros.  Guste o no, lo cierto es que todo el mundo tiene el bendito Skype y yo tengo que usarlo.  Así que me puse en la labor de asegurarme que el programita no anduviera revisando mi máquina, cosa bastante común en él, y que la transmisión estuviera encriptada de una forma que yo controle, por lo menos hasta donde pueda.

¿Por qué OpenVPN y no un tunel SSH?  Porque un tunel SSH, aunque excelente, no trasporta paquetes UDP sino TCP.  Se puede forzar a Skype a transmitir paquetes TCP pero perderíamos la ventaja de los paquetes UDP para transmisión de voz.  Sobre OpenVPN no voy a decir nada porque hay muy buenos tutoriales en la red.  Solo hace falta asegurarse de comentar una línea en el archivo de configuración del servidor de OpenVPN:

;push “redirect-gateway def1”

Cuando está habilitad, ésta línea fuerza a que todo el tráfico pase por la VPN y eso es lo que no quiero.  Así que del lado del servidor ya está listo el trabajo.

Ahora la VPN en el lado del cliente.  En la máquina donde instalamos Skype, tenemos que decirle que deseamos que pase por la VPN.  Yo uso Debian, pero en otras distribuciones la idea es más o menos la misma.  En /etc/rc.local le añado esto:

iptables -t mangle -A OUTPUT -m owner –uid-owner skype -j MARK –set-mark 1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Nota: Delante de uid-owner y set-mark hay dos guiones no uno.

El primer comando marca los paquetes del usuario “skype” y el segundo permite hacer enmascaramiento de los mismos, para que puedan pasar de mi red interna a la VPN sin perderse en el camino.

Editamos el archivo /etc/iproute2/rt_tables y añadímos al final esto:

300       openvpn

Esto nos permite crear una tabla de enrutamiento cuyo número es 300 y su nombre “openvpn”.

Editamos el archivo /etc/sysctl.conf y habilitamos o añadímos la siguiente línea:

net.ipv4.ip_forward=1

En el archivo de configuración del cliente VPN, /etc/openvpn/client.conf, según lo haya nombrado cada cual, añadimos esto al final:

script-security 2
route-up “/etc/openvpn/rutas.sh”

Y creamos un archivo llamado /etc/openvpn/rutas.sh al cual añadímos esto:

#!/bin/sh
ip route flush table 300
ip rule add fwmark 1 table 300
ip route add default via $route_vpn_gateway table 300
ip route flush cache

El primer comando limpia la tabla 300.  El siguiente le dice al sistema que todos los paquetes marcados con “1” están gobernados por las rutas definidas en la tabla 300.  El siguiente añade la ruta por defecto que van a seguir los paquetes de la tabla 300, en éste caso, uso una variable del propio OpenVPN para asignar automáticamente la dirección.  Y el siguiente limpia el cache de rutas para que entren en vigor todos los cambios.

Le damos permisos de ejecución al archivo y creamos el usuario con:

useradd -m skype

Reiniciamos y tenemos entonces una máquina que va a enrutar todo el tráfico del usuario “skype” a través de la VPN.

Falta activar el usuario y asignarle clave. 

Para arrancar Skype, yo uso éste comando:

gksu -u skype /usr/bin/skype

Dado que, como siempre, esto lo escribo para mí, más que para los demás, no explico los detalles del uso de gksu.  Eso se lo dejo a cada cual.

Pero falta un último detalle.  Yo uso pulseaudio y éste no funciona “de caja” con Skype en ésta configuración.  Hay muchas recetas en Internet de como lograrlo, pero todas adolecen de fallas de seguridad.  Yo edité el archivo /etc/pulse/default.pa y añadí lo siguiente al final:

load-module module-esound-protocol-tcp auth-anonymous=1
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1

De ésta forma el usuario “skype” tiene acceso al servidor de audio de pulse, sin comprometer la seguridad del sistema.

Bueno, hasta aquí dejo la historia.  Espero que le sirva a alguien más.