14.10. VPN sobre IPsec
Anterior | Capítulo 14. Seguridad | Siguiente

## 14.10. VPN sobre IPsec

Escrito por Nik Clayton.

Creación de una VPN entre dos redes, a través de Internet, mediante puertas de enlace (“gateways”) FreeBSD.

### 14.10.1. Qué es IPsec

Escrito por Hiten M. Pandya.

Esta sección le guiará a través del proceso de configuración de IPsec, y de su uso en un entorno consistente en máquinas FreeBSD y Microsoft® Windows® 2000/XP, para hacer que se comuniquen de manera segura. Para configurar IPsec es necesario que esté familiarizado con los conceptos de construcción de un kernel personalizado (consulte el Capítulo 8, Configuración del kernel de FreeBSD).

IPsec es un protocolo que está sobre la capa del protocolo de Internet (IP). Le permite a dos o más equipos comunicarse de forma segura (de ahí el nombre). La “pila de red” IPsec de FreeBSD se basa en la implementación KAME, que incluye soporte para las dos familias de protocolos, IPv4 e IPv6.

### Nota:

FreeBSD 5.X contiene una pila IPsec “acelerada por hardware”, conocida como “Fast IPsec”, que fué obtenida de OpenBSD. Emplea hardware criptográfico (cuando es posible) a través del subsistema crypto(4) para optimizar el rendimiento de IPsec. Este subsistema es nuevo, y no soporta todas las opciones disponibles en la versión KAME de IPsec. Para poder habilitar IPsec acelerado por hardware debe añadir las siguientes opciones al fichero de configuración de su kernel:

options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)

Tenga en cuenta que no es posible utilizar el subsistema “Fast IPsec” y la implementación KAME de IPsec en la misma computadora. Consulte la página de manual fast_ipsec(4) para más información.

IPsec consta de dos sub-protocolos:

- Encapsulated Security Payload (ESP), que protege los datos del paquete IP de interferencias de terceros, cifrando el contenido utilizando algoritmos de criptografía simétrica (como Blowfish, 3DES).

- Authentication Header (AH), que protege la cabecera del paquete IP de interferencias de terceros así como contra la falsificación (“spoofing”), calculando una suma de comprobación criptográfica y aplicando a los campos de cabecera IP una función hash segura. Detrás de todo esto va una cabecera adicional que contiene el hash para permitir la validación de la información que contiene el paquete.

ESP y AH pueden utilizarse conjunta o separadamente, dependiendo del entorno.

IPsec puede utilizarse para cifrar directamente el tráfico entre dos equipos (conocido como modo de transporte) o para construir “túneles virtuales” entre dos subredes, que pueden usarse para comunicación segura entre dos redes corporativas (conocido como modo de túnel). Este último es muy conocido como una red privada virtual (Virtual Private Network, o VPN). ipsec(4) contiene información detallada sobre el subsistema IPsec de FreeBSD.

Si quiere añdir soporte IPsec a su kernel debe incluir las siguientes opciones al fichero de configuración de su kernel:

options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC)

Si quiere soporte para la depuración de errores no olvide la siguiente opción:

options IPSEC_DEBUG #debug for IP security

### 14.10.2. El Problema

No existe un estándar para lo que constituye una VPN. Las VPN pueden implementarse utilizando numerosas tecnologías diferentes, cada una de las cuales tiene sus pros y sus contras. Esta sección presenta un escenario, y las estrategias usadas para implementar una VPN para este escenario.

### 14.10.3. El escenario: dos redes, conectadas por Internet, que queremos que se comporten como una sola

Este es el punto de partida:

- Usted tiene al menos dos sitios

- Ambos sitios utilizan IP internamente

- Ambos sitios están conectados a Internet, a través de una puerta de enlace FreeBSD.

- La puerta de enlace de cada red tiene al menos una dirección IP pública.

- Las direcciones internas de las dos redes pueden ser direcciones IP públicas o privadas, no importa. Puede ejecutar NAT en la máquina que hace de puerta de enlace si es necesario.

- Las direcciones IP internas de las dos redes no colisionan. Aunque espero que sea teóricamente posible utilizar una combinación de tecnología VPN y NAT para hacer funcionar todo esto sospecho que configurarlo sería una pesadilla.

Si lo que intenta es conectar dos redes y ambas usan el mismo rango de direcciones IP privadas (por ejemplo las dos usan `192.168.1.x`)debería renumerar una de las dos redes.

La topología de red se parecería a esto:

Observe las dos direcciones IP públicas. Usaré letras para referirme a ellas en el resto de este artículo. El cualquier lugar que vea esas letras en este artículo reemplácelas con su propia dirección IP pública. Observe también que internamente las dos máquinas que hacen de puerta de enlace tienen la dirección IP .1, y que las dos redes tienen direcciones IP privadas diferentes (`192.168.1.x` y `192.168.2.x` respectivamente). Todas las máquinas de las redes privadas están configuradas para utilizar la máquina `.1` como su puerta de enlace por defecto.

La intención es que, desde el punto de vista de la red, cada red debe ver las máquinas en la otra red como si estuvieran directamente conectadas al mismo router (aunque aunque sea un router ligeramente lento con una tendencia ocasional a tirar paquetes).

Esto significa que (por ejemplo), la máquina `192.168.1.20` debe ser capaz de ejecutar

ping 192.168.2.34

y recibir de forma transparente una respuesta. Las máquinas Windows® deben ser capaces de ver las máquinas de la otra red, acceder a sus ficheros compartidos, etc, exactamente igual que cuando acceden a las máquinas de la red local.

Y todo debe hacerse de forma segura. Esto significa que el tráfico entre las dos redes tiene que ser cifrado.

La creación de una VPN entre estas dos redes es un proceso que requiere varios pasos. Las etapas son estas:

1. Crear un enlace de red “virtual” entre las dos redes, a través de Internet. Probarlo usando herramientas como ping(8) para asegurarse de que funcione.

2. Aplicar políticas de seguridad para asegurarse de que el tráfico entre las dos redes sea cifrado y descifrado de forma transparente. Comprobarlo mediante herramientas como tcpdump(1) para asegurarse de que el tráfico esté siendo efectivamente cifrado.

3. Configurar software adicional en las puertas de enlace FreeBSD para permitir a las máquinas Windows® verse entre ellas a través de la VPN.

#### 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).

### Nota:

En FreeBSD 5.X las funciones de gifconfig(8) se han incluido en 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.

Anterior | Subir | Siguiente
14.9. OpenSSL | Inicio | 14.11. OpenSSH

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.