VPN sobre linux y openswan

Existen muchas alternativas para hacer redes privadas virtuales (VPN) sobre linux, como openvpn, poptop (protocolo pptp) y varias implementaciones de IPsec. Cada solución tiene sus beneficios y debilidades, elijo en este artículo no discutir la mejor opción para cada escenario sino explicar a modo de HOWTO cómo realizar una VPN basada en IPsec con openswan sobre linux, particularmente Debian.

Breve introducción a IPsec

De wikipedia:

IPsec (la abreviatura de Internet Protocol security) es una extensión
al protocolo IP que añade cifrado fuerte para permitir servicios de
autenticación y, de esta manera, asegurar las comunicaciones a través
de dicho protocolo. Inicialmente fue desarrollado para usarse con el
nuevo estándar IPv6, aunque posteriormente se adaptó a IPv4.
IPsec actúa a nivel de capa de red, protegiendo y autenticando los paquetes IP entre los equipos participantes en la comunidad IPsec. No está ligado a ningún algoritmo de encriptación o autenticación, tecnología de claves o algoritmos de seguridad específico. Es más, IPsec es un marco de estándares que permite que cualquier nuevo algoritmo sea introducido sin necesitar de cambiar los estándares.
IPSec está formado por un conjunto de protocolos de cifrado por (1) securing packet flows y (2) key exchange. De la forma:

Encapsulating Security Payload (ESP), el cual provee autenticación, confidencialidad de datos e integridad del mensaje

Authentication Header (AH), provee de autenticación e integridad de datos, pero no de confidencialidad.
Por sus características es el protocolo estándar para la construcción de redes privadas virtuales.

Modos

Transparente: Sólo se encripta el payload (el contenido del mensaje) y no el encabezado, normalmente es usado para túneles de host a host. Hay que tener en cuenta que no puede usarse NAT con el modo transparente, debido a que se rompe la hash al alterar el encabezado.

Túnel: Cada paquete es completamente encriptado y encapsulado dentro de otro, es el modo más usado y permite hacer VPNs de tipo red a red.

Autenticación

Las opciones más populares de autenticación son:

“Secreto compartido”: (aka PSK) usando algoritmos de hashing como MD5 o SHA-1, al parecer recientemente ambos algoritmos de hashing fueron “crackeados”, al menos reducido considerablemente el tiempo de crackeo, aunque todavía son “usables” sólo falta tiempo para que algún matemático refine la técnica y los vuelva trivialmente crackeables.

Certificados digitables: los cuales están basados en encriptación asimétrica. En este ejemplo se utiliza este método con el algoritmo RSA.

Encriptación e intercambio de llaves

La encriptación sólo puede ser realizada usando ESP (o sea no con AH) y los algoritmos normalmente utilizados son: DES, 3DES y AES.
El tráfico se encripta usando llaves que se renuevan a intervalos regulares, para el intercambio de llaves entre los pares se puede usar intercambio manual o automático (IKE).

Manos a la obra

Supongamos que queremos armar una VPN entre la casa central de una empresa y una sucursal para que la última pueda acceder a recursos de la casa central. En ambos lugares tenemos servidores Debian\linux bajo estable trabajando como Firewalls.

La topología del ejemplo es la siguiente:

Como antes nombré, utilizaremos Openswan para armar la VPN, este está disponible tanto en la distribución estable (Sarge), como para la de prueba (etch). Los núcleos oficiales de Debian (2.4 y 2.6) incluyen el stack 26sec por lo que no hay necesidad de recompilar el kernel para tener soporte de ipsec.

Para instalarlo desde la consola como root ejecutamos:

$ apt-get install openswan

Además del paquete se instalaran varios más de los cuales depende. Es
probable que si no tenías instalado el paquete ca-certificates te
consulte acerca de confiar en ciertas Autoridades Certificantes, las
respuestas son indistintas para este ejemplo.

Cuando le toque el turno de configuración a openswan te preguntará por:

Encriptación oportunista: esta opción no es necesaria para nuestro ejemplo y si no la vas a usar es preferible desactivarla.
Creación de un certificado autofirmado: Tampoco es necesario, si no tienes experiencia con ello, no lo crees.
Configuración

Por cada firewall debemos obtener la siguiente información:

IP publica del firewall
Rango IP dentro de la subred que tendra acceso a la VPN
Un nombre con el cual queda extremo pueda reconocerse, su forma es un FQDN precedido con un arroba, ej: @xy.example.com. (Tambien podemos usar las direcciones IP publicas)
Primero creamos una llave en cada servidor ejecutando:
fw-central$ ipsec newhostkey –output – >> /etc/ipsec.secrets
fw-sucursal$ ipsec newhostkey –output – >> /etc/ipsec.secrets

Este proceso puede demorar bastante tiempo en máquinas no muy veloces,
por lo que no desesperes.

El archivo de configuración principal es el /etc/ipsec.conf y en este
se declara un extremo como izquierdo y el otro como derecho, quien es
cada cual es indistinto y además es determinado en la ejecución. Esto
permite tener una misma configuración en ambos extremos sin tener que
hacer traducciones. Para nuestro ejemplo usaremos la casa central como
izquierdo y la sucursal como derecho.

Ahora determinamos la llave pública de cada extremo ejecutando:

fw-central$ ipsec showhostkey –left
fw-sucursal$ ipsec showhostkey –right

esto mostrará algo como:

# RSA 2192 bits fw-central Wed Jan 24 21:48:39 2007
leftrsasigkey=0sAQO9Pc….
# RSA 2192 bits fw-sucursal Sat Feb 3 03:51:44 2007
rightrsasigkey=0sAQOW…

Ahora editamos en ambos extremos el archivo /etc/ipsec.conf y
agregamos al final:

$ vi /etc/ipsec.conf

conn central-a-sucursal

left=1.2.3.4
leftsubnet=172.16.0.0/24
leftid=1.2.3.4
leftrsasigkey=0sAQOGJ…
leftnexthop=%defaultroute
right=1.2.3.5
rightsubnet=192.168.66.0/24
rightid=1.2.3.5
rightrsasigkey=0sAQOW…
rightnexthop=%defaultroute
auto=add # add autoriza la conexion pero no la establece automaticamente

Reiniciamos openswan en ambos servidores:
$ /etc/init.d/ipsec restart

Probamos que levante manualmente:
$ ipsec auto –up central-a-sucursal

Si sale todo bien, el último mensaje dirá algo como:
004 “central-a-sucursal” #2: STATE_QUICK_I2: sent QI2, IPsec SA
established {ESP=>0x84b3d554 …

Consideraciones
Para que el túnel levante automáticamente al inicio se debe cambiar la opción auto=add por auto=start
En el caso de que tengas IP dinámicas en alguno o ambos de los puntos, puedes mirar los ejemplos del wiki de openswan para “roadwarrior”
Es importante que si tienes reglas de NAT estas no se apliquen al tráfico del túnel.
Si tienes un firewall construido con la regla por defecto en denegar todo, debes permitir los protocolos de IPsec (numero 50 y 51). Ej:

iptables -A INPUT -p 50 -j ACCEPT
iptables -A OUTPUT -p 50 -j ACCEPT
iptables -A INPUT -p 51 -j ACCEPT
iptables -A OUTPUT -p 51 -j ACCEPT
No soy un experto en IPsec por lo que pueden haber algunas imprecisiones en este texto, sin embargo espero que el artículo sea de utilidad.

Referencias

http://en.wikipedia.org/wiki/IPSec
http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/ispstep.mspx
http://www.unixwiz.net/techtips/iguide-ipsec.html
http://wiki.openswan.org/index.php/Openswan/Configure

Fuente: http://brsi.blogspot.com/