14.10. VPN sobre IPsec

ping 192.168.2.34

14.10.3.1. Paso 1: Creación y prueba de un enlace de red “virtual”

Suponga que está en la puerta de enlace de la red red #1 (con dirección IP pública A.B.C.D, dirección IP privada 192.168.1.1), y ejecuta ping 192.168.2.1, que es la dirección privada de la máquina con dirección IP W.X.Y.Z. ¿Qué hace falta para esto?

1. La puerta de enlace necesita saber cómo alcanzar a 192.168.2.1. En otras palabras, necesita tener una ruta hasta 192.168.2.1.

2. Las direcciones IP privadas, como las que están en el rango 192.168.x no deberían aparecer en Internet. Por eso, cada paquete que mande a 192.168.2.1 necesitará encerrarse dentro de otro paquete. Este paquete debe tener todas las características de haber sido enviado desde A.B.C.D, y tendrá que ser enviado a W.X.Y.Z. Este proceso recibe el nombre de encapsulado.

3. Una vez que este paquete llega a W.X.Y.Z necesitará ser “desencapsulado”, y entregado a 192.168.2.1.

Puede verlo como si necesitara un “túnel” entre las dos redes. Las dos “bocas del túnel” son las direcciones IP A.B.C.D y W.X.Y.Z, y debe hacer que el túnel sepa cuáles serán las direcciones IP privadas que tendrán permitido el paso a través de él. El túnel se usa para transferir tráfico con direcciones IP privadas a través de la Internet pública.

Este túnel se crea mediante la interfaz genérica, o dispositivo gif en FreeBSD. Como puede imaginarse la interfaz gif de cada puerta de enlace debe configurarse con cuatro direcciones IP: dos para las direcciones IP públicas, y dos para las direcciones IP privadas.

El soporte para el dispositivo gif debe compilarse en el kernel de FreeBSD en ambas máquinas añadiendo la línea

device gif

a los ficheros de configuración del kernel de ambas máquinas, compilarlo, instalarlo y reiniciar.

La configuración del túnel es un proceso que consta de dos partes. Primero se le debe decir al túnel cuáles son las direcciones IP exteriores (o públicas) mediante gifconfig(8). Después configure las direcciones IP con ifconfig(8).

En la puerta de enlace de la red #1 debe ejecutar las siguientes dos órdenes para configurar el túnel.

gifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff
     

En la otra puerta de enlace ejecute las mismas órdenes, pero con el orden las direcciones IP invertido.

gifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff
     

Ahora ejecute:

gifconfig gif0

y podrá ver la configuración. Por ejemplo, en la puerta de enlace de la red #1 vería algo parecido a esto:

# gifconfig gif0
gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --> W.X.Y.Z
     

Como puede ver se ha creado un túnel entre las direcciones físicas A.B.C.D y W.X.Y.Z, y el tráfico que puede pasar a través del túnel es entre 192.168.1.1 y 192.168.2.1.

Esto también habrá agregado una entrada en la tabla de rutas de ambas máquinas, que puede examinar con netstat -rn. Esta salida es de la puerta de enlace de la red #1.

# netstat -rn
Routing tables
 
Internet:
Destination      Gateway       Flags    Refs    Use    Netif  Expire
...
192.168.2.1      192.168.1.1   UH        0        0    gif0
...
     

Como el valor de “Flags” lo indica, esta es una ruta de equipo, lo que significa que cada puerta de enlace sabe como alcanzar la otra puerta de enlace, pero no saben cómo llegar al resto de sus respectivas redes. Ese problema se solucionará en breve.

Es posible que disponga de un cortafuegos en ambas máquinas, por lo que tendrá que buscar la forma de que el tráfico de la VPN pueda entrar y salir limpiamente. Puede permitir todo el tráfico de ambas redes, o puede que quiera incluir reglas en el cortafuegos para que protejan ambos extremos de la VPN uno del otro.

Las pruebas se simplifican enormemente si configura el cortafuegos para permitir todo el tráfico a través de la VPN. Siempre puede ajustar las cosas después. Si utiliza ipfw(8) en las puertas de enlace una orden similar a

ipfw add 1 allow ip from any to any via gif0

permitirá todo el tráfico entre los dos extremos de la VPN, sin afectar al resto de reglas del cortafuegos. Obviamente tendrá que ejecutar esta orden en ambas puertas de enlace.

Esto es suficiente para permitir a cada puerta de enlace hacer un ping entre ellas. En 192.168.1.1 deberí poder ejecutar

ping 192.168.2.1

y obtener una respuesta; es obvio que debería poder hacer los mismo en la otra puerte de enlace.

Aún no podrá acceder a las máquinas internas de las redes. El problema está en el encaminamiento: aunque las puertas de enlace saben cómo alcanzarse mútuamente no saben cómo llegar a la red que hay detrás de la otra.

Para resolver este problema debe añadir una ruta estática en cada puerta de enlace. La orden en la primera puerta de enlace podría ser:

route add 192.168.2.0 192.168.2.1 netmask 0xffffff00
     

Esto significa “Para alcanzar los equipos en la red 192.168.2.0, envía los paquetes al equipo 192.168.2.1”. Necesitará ejecutar una orden similar en la otra puerta de enlace, pero obviamente con las direcciones 192.168.1.x.

El tráfico IP de equipos en una red no será capaz de alcanzar equipos en la otra red.

Ya tiene dos tercios de una VPN, puesto que ya es “virtual” y es una “red”. Todavía no es privada. Puede comprobarlo con ping(8) y tcpdump(1). Abra una sesión en la puerta de enlace y ejecute

tcpdump dst host 192.168.2.1

En otra sesión en el mismo equipo ejecute

ping 192.168.2.1

Verá algo muy parecido a esto:

16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply
     

Como puede ver los mensajes ICMP van y vienen sin cifrar. Si usa el parámetro -s en tcpdump(1) para tomar más bytes de datos de estos paquetes verá más información.

Obviamente esto es inaceptable. La siguiente sección explicará cómo asegurar el enlace entre las dos redes para que todo el tráfico se cifre automáticamente.

Sumario:

• Configure ambos kernel con “pseudo-device gif”.

• Edite /etc/rc.conf en la puerta de enlace #1 y añada las siguientes líneas (reemplazando las direcciones IP según sea necesario).

  gifconfig_gif0="A.B.C.D W.X.Y.Z"
  ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
  static_routes="vpn"
  route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
           
  

• Edite la configuración de su cortafuegos (/etc/rc.firewall, o lo que corresponda) en ambos equipos y añada

  ipfw add 1 allow ip from any to any via gif0
  

• Haga los cambios oportunos en el /etc/rc.conf de la puerta de enlace #2, invirtiendo el orden de las direcciones IP.

14.10.3.2. Paso 2: Asegurar el enlace

Para asegurar el enlace usaremos IPsec. IPsec ofrece un mecanismo para que dos equipos coincidan en una llave de cifrado, y usar esta llave para cifrar los datos entre los dos equipos.

Existen dos áreas de configuración a tener en cuenta:

1. Debe existir un mecanismo para que los dos equipos se pongan de acuerdo en el mecanismo de cifrado que van a utilizar. Una vez que los dos equipos se han puesto de acuerdo dice que existe una “asociación de seguridad” entre ellos.

2. Debe existir un mecanismo para especificar que tráfico debe ser cifrado. Obviamente, usted no querrá cifrar todo su tráfico saliente: solo querrá cifrar el tráfico que es parte de la VPN. Las reglas con las que determinará qué tráfico será cifrado se llaman “políticas de seguridad”.

Tanto las asociaciones de seguridad como las políticas de seguridad son responsabilidad del kernel, pero pueden ser modificadas desde el espacio de usuario. Antes de poder hacerlo, tendrá que configurar el kernel para que incluya IPsec y el protocolo ESP (Encapsulated Security Payload). Incluya en el fichero de configuración de su kernel lo siguiente:

options IPSEC
options IPSEC_ESP
      

Recompile y resintale su kernel y reinicie. Como se dijo anteriormente, tendrá que hacer lo mismo en el kernel de las dos puertas de enlace.

Tiene dos opciones cuando se trata de configurar asociaciones de seguridad. Puede configurarlas a mano en los dos equipos, lo que significa elegir el algoritmo de cifrado, las llaves de cifrado, etc, o puede utilizar alguno de los dæmons que implementan el protocolo de intercambio de llaves de Internet (IKE, Internet Key Exchange).

Le recomiendo la segunda opción. Aparte de otras consideraciones es más fácil de configurar.

La edición y despliegue se efectúa con setkey(8). Todo esto se entiende mejor con una analogía. setkey es a las tablas de políticas de seguridad del kernel lo que route(8) es a las tablas de rutas del kernel. También puede usar setkey ver las asociaciones de seguridad en vigor, siguiendo con la analogía, igual que puede usar netstat -r.

Existen numerosos dæmons que pueden encargarse de la gestión de asociaciones de seguridad en FreeBSD. En este texto se muestra cómo usar uno de ellos, racoon (que puede instalar desde security/racoon en la colección de ports de FreeBSD.

El software security/racoon debe ejecutarse en las dos puertas de enlace. En cada equipo debe configurar la dirección IP del otro extremo de la VPN y una llave secreta (que usted puede y debe elegir, y debe ser la misma en ambas puertas de enlace).

Los dos dæmons entran en contacto uno con otro, y confirman que son quienes dicen ser (utilizando la llave secreta que usted configuró). Los dæmons generan una nueva llave secreta, y la utilizan para cifrar el tráfico que discurre a través de la VPN. Periódicamente cambian esta llave, para que incluso si un atacante comprometiera una de las llaves (lo cual es teóricamente cercano a imposible) no le serviriía de mucho: para cuando el atacante haya “crackeado” la llave los dæmons ya habrán escogido una nueva.

El fichero de configuración de racoon está en ${PREFIX}/etc/racoon. No debería tener que hacer demasiados cambios a ese fichero. El otro componente de la configuración de racoon (que sí tendrá que modificar) es la “llave pre-compartida”.

La configuración por defecto de racoon espera encontrarla en ${PREFIX}/etc/racoon/psk.txt. Es importante saber que la llave precompartida no es la llave que se utilizará para cifrar el tráfico a través del enlace VPN; solamente es una muestra que permite a los dæmons que administran las llaves confiar el uno en el otro.

psk.txt contiene una línea por cada sitio remoto con el que esté tratando. En nuestro ejemplo, donde existen dos sitios, cada fichero psk.txt contendrá una línea (porque cada extremo de la VPN solo está tratando con un sitio en el otro extremo).

En la puerta de enlace #1 esta línea debería parecerse a esta:

W.X.Y.Z            secreto

Esto es, la dirección IP pública del extremo remoto, un espacio en blanco, y una cadena de texto que es el secreto en sí. en el extremo remoto, espacio en blanco, y un texto de cadena que proporcina el secreto. Obviamente, no debe utilizar “secret” como su llave; aplique aquí las reglas y recomendaciones habituales para la elección de contraseñas.

En la puerta de enlace #2 la línea se parecería a esta

A.B.C.D            secreto

Esto es, la dirección IP pública del extremo remoto, y la misma llave secreta. psk.txt debe tener modo 0600 (es decir, modo de solo lectura/escritura para root) antes de que ejecute racoon.

Debe ejecutar racoon en ambas puertas de enlace. También tendrá que añadir algunas reglas a su cortafuegos para permitir el tráfico IKE, que se transporta sobre UDP al puerto ISAKMP (Internet Security Association Key Management Protocol). Esto debe estar al principio de las reglas de su cortafuegos.

ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
      

Una vez que ejecute racoon puede tratar de hacer un ping a una puerta de enlace desde la otra. La conexión todavía no está cifrada porque aún no se han creado las asociaciones de seguridad entre los dos equipos: esto puede llevar un poco de tiempo; es posible que advierta un pequeño retraso antes de los ping empiecen responder.

Una vez creadas las asociaciones de seguridad puede verlas utilizando setkey(8). Ejecute

setkey -D

en cualquiera de los equipos para comprobar la información de la asociación de seguridad.

Ya está resuelta la mitad del problema. La otra mitad es configurar sus políticas de seguridad.

Queremos crear una política de seguridad sensata, así que vamos a revisar lo que tenemos configurado hasta el momento. Esta revisión abarca ambos extremos del enlace.

Cada paquete IP que usted manda tiene una cabecera que contiene datos acerca del paquete. La cabecera incluye la dirección IP de destino y del origen. Como ya sabemos, las direcciones IP privadas como el rango 192.168.x.y no deberían aparezcan en Internet. Dado que es a través de Internet por donde los queremos transmitir los debemos encapsular dentro de otro paquete. Este paquete debe contener tanto la dirección IP de destino y origen públicas sustituidas por las direcciones privadas.

Así que si su paquete saliente empezó pareciendose a este:

tras el encapsulado se parecerá bastante a este:

El dispositivo gif se encarga del encapsulado. Como puede ver el paquete tiene una dirección IP real en el exterior, y nuestro paquete original ha sido envuelto como dato dentro del paquete que enviaremos a través de Internet.

Obviamente, queremos que todo el tráfico entre las VPN vaya cifrado. Pongamos esto último en palabras para comprenderlo mejor:

“Si un paquete sale desde A.B.C.D, y tiene como destino W.X.Y.Z, cífralo utilizando las asociaciones de seguridad necesarias.”

“Si un paquete llega desde W.X.Y.Z, y tiene como destino A.B.C.D, descífralo utilizando las asociaciones de seguridad necesarias.”

Este planteamiento se aproxima bastante, pero no es exactamente lo que queremos hacer. Si lo hiciera así todo el tráfico desde y hacia W.X.Y.Z, incluso el tráfico que no forma parte de la VPN, será cifrado; esto no es lo que queremos. La política correcta es la siguiente:

“Si un paquete sale desde A.B.C.D, y está encapsulando a otro paquete, y tiene como destino W.X.Y.Z, cífralo utilizando las asociaciones de seguridad necesarias.”

“Si un paquete llega desde W.X.Y.Z, y está encapsulando a otro paquete, y tiene como destino A.B.C.D, descífralo utilizando las asociaciones de seguridad necesarias.”

Un cambio sutil, pero necesario.

Las políticas de seguridad también se imponen utilizando setkey(8). setkey(8) proporciona un lenguaje de configuración para definir la política. Puede introducir las instrucciones de configuración a través de la entrada estándar (stdin), o puede usar la opción -f para especificar un fichero que contenga las instrucciones de configuración.

La configuración en la puerta de enlace #1 (que tiene la dirección IP pública A.B.C.D) para forzar que todo el tráfico saliente hacia W.X.Y.Z vaya cifrado es:

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
      

Ponga estas órdenes en un fichero (por ejemplo /etc/ipsec.conf) y ejecute

# setkey -f /etc/ipsec.conf

spdadd le dice a setkey(8) que queremos añadir una regla a la base de datos de políticas de seguridad. El resto de la línea especifica qué paquetes se ajustarán a esta política. A.B.C.D/32 y W.X.Y.Z/32 son las direcciones IP y máscaras de red que identifican la red o equipos a los que se aplicará esta política. En nuestro caso queremos aplicarla al tráfico entre estos dos equipos. -P out dice que esta política se aplica a paquetes salientes, e ipsec hace que el paquete sea asegurado.

La segunda línea especifica cómo será cifrado este paquete. esp es el protocolo que se utilizará, mientras que tunnel indica que el paquete será después encapsulado en un paquete IPsec. El uso repetido de A.B.C.D y W.X.Y.Z se utiliza para seleccionar la asociación de seguridad a usar, y por último require exige que los paquetes deben cifrarse si concuerdan con esta regla.

Esta regla solo concuerda con paquetes salientes. Necesitará una regla similar para los paquetes entrantes.

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Observe el in en lugar del out en este caso, y la inversión necesaria de las direcciones IP.

La otra puerta de enlace (que tiene la dirección IP pública W.X.Y.Z) necesitará reglas similares.

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Finalmente, necesita añadir reglas a su cortafuegos para permitir la circulación de paquetes ESP e IPENCAP de ida y vuelta. Tendrá que añadir reglas como estas a ambos equipos.

ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
      

Debido a que las reglas son simétricas puede utilizar las mismas reglas en ambas puertas de enlace.

Los paquetes salientes tendrán ahora este aspecto:

Cuando los paquetes llegan al otro extremo de la VPN serán descifrados (utilizando las asociaciones de seguridad que han sido negociadas por racoon). Después entrarán al interfaz gif, que desenvuelve la segunda capa, hasta que nos quedamos con paquete má interno, que puede entonces viajar a la red interna.

Puede revisar la seguridad utilizando la misma prueba de ping(8) anterior. Primero, inicie una sesión en la puerta de enlace A.B.C.D, y ejecute:

tcpdump dst host 192.168.2.1

En otra sesión en la misma máquina ejecute

ping 192.168.2.1

Debería ver algo similar a lo siguiente:

XXX tcpdump output

ahora, como puede ver, tcpdump(1) muestra los paquetes ESP. Si trata de examinarlos con la opción -s verá basura (aparentemente), debido al cifrado.

Felicidades. Acaba de configurar una VPN entre dos sitios remotos.

Sumario

• Configure ambos kernel con:

  options IPSEC
  options IPSEC_ESP
           
  

• Instale security/racoon. Edite ${PREFIX}/etc/racoon/psk.txt en ambas puertas de enlace añadiendo una entrada para la dirección IP del equipo remoto y una llave secreta que ambos conozcan. Asegúrese de que este fichero esté en modo 0600.

• Añada las siguientes líneas a /etc/rc.conf en ambos equipos:

  ipsec_enable="YES"
  ipsec_file="/etc/ipsec.conf"
           
  

• Crée en ambos equipos un /etc/ipsec.conf que contenga las líneas spdadd necesarias. En la puerta de enlace #1 sería:

  spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
    esp/tunnel/A.B.C.D-W.X.Y.Z/require;
  spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
    esp/tunnel/W.X.Y.Z-A.B.C.D/require;
  

  En la puerta de enlace #2 sería:

  spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
    esp/tunnel/W.X.Y.Z-A.B.C.D/require;
  spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
    esp/tunnel/A.B.C.D-W.X.Y.Z/require;
  

• Añada a su(s) cortafuegos las reglas necesarias para que permita(n) el paso de tráfico IKE, ESP e IPENCAP en ambos equipos:

  ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
  ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
  ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
  ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
  ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
  ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
           
  

Los dos pasos previos deben bastar para levantar la VPN. Las máquinas en cada red seán capaces de dirigirse una a otra utilizando direcciones IP, y todo el tráfico a través del enlace será cifrado de forma automática y segura.