OpenVPN

Bueno, ya estamos al final de todo, así que no nos vamos a parar mucho en detalles. Las VPN's se usan generalmente para:

  • Conexión entre diversos puntos de una organización a través de Internet
  • Conexiones de trabajadores domésticos o de campo con IP's dinámicas
  • Soluciones extranet para clientes u organizaciones asociadas con los cuales se necesita intercambiar cierta información en forma privada pero no se les debe dar acceso al resto de la red interna.
  • Además brinda una excelente fiabilidad en la comunicación de usuarios móviles así como también al unir dos puntos distantes como agencias de una empresa dentro de una sola red unificada.

Con permiso de la Wikipedia, transcribo lo siguiente:

Supongamos que se tienen dos sitios de una organización conectados a Internet. En ambos se contará con un equipo de conexión a la red de redes que cumplirá la función de ruteo hacia y desde Internet así como firewall para protegerse de accesos no autorizados. El software VPN debe estar instalado en ese firewall o algún dispositivo protegido por él. Uno de los sitios será el "servidor" y será el sitio que contiene la información y sistemas que queremos compartir, mientras que al otro lo llamaremos "cliente". El servidor será entonces configurado para aceptar conexiones desde el cliente (y viceversa). Llegado este punto habremos logrado tener dos sitios comunicados como en una red directa real pero aún no es una VPN dado que falta implementar la "privacidad", pues cualquier nodo intermedio de Internet puede leer la información que viaja sin protección. Lo que se debe hacer seguidamente es establecer mecanismos de cifrado que mediante uso de claves aseguren que solo equipos o personas dueños de esas claves puedan acceder a los datos enviados por la VPN. Todos los datos enviados del punto A al B deberán ser cifrados antes de ser enviados y desci.frados en el otro extremo para posteriormente ser entregados normalmente a su destinatario final. Uno de los factores que diferencian a una implementación de VPN de otra, son los mecanismos que utilicen para cifrar y distribuir claves a todos los integrantes de dicha red.

Existen diferentes soluciones de VPN, implementados a diferente nivel OSI. Por ejemplo:

  • Nivel 2: PPTP o L2TP.
  • Nivel 3: IPsec.
  • Nivel 7: SSL y TLS.

En concreto, OpenVPN implementa VPN a nivel 2 y 3. Se puede configurar de las dos maneras, lo que quiere decir que permite manejar el tráfico de capa 2 (como ethernet) si cierta aplicación lo necesita. OpenVPN es un software de VPN basado en SSL. Es gratis, opensource, sencillo y seguro. Soporta NAT sin problemas, y es un software soportado por Linux, Windows y MacOS (además de otras plataformas).

Para el cifrado de los datos, OpenVPN tiene dos modos considerados seguros, uno basado en la criptografía simétrica (claves estáticas compartidas entre los extremos) y otro en SSL/TLS usando criptografía asimétrica (con un certificado por cada usuario de la VPN). En el caso de la criptografía asimétrica, los certificados pueden ser emitidos por CAs o bien por nosotros mismos.

Vamos a empezar con la siguiente topología:

Tunel inseguro

Vamos a crear un túnel inseguro entre el ordenador remoto y el servidor VPN:

En el servidor VPN:

root@vpnsvr$ openvpn --remote 11.11.11.2 --dev tun0 --ifconfig 10.0.0.1 10.0.0.2

En el cliente VPN:

root@vpncln$ openvpn --remote 12.12.12.2 --dev tun0 --ifconfig 10.0.0.2 10.0.0.1

Deberíamos obtener un mensaje como el siguiente en ambos extremos:

Sat Feb 18 12:53:45 2012 Initialization Sequence Completed

Ahora ya podemos hacer ping de un extremo a otro de la VPN:

root@vpncln$ ping 10.0.0.1
root@vpnsvr$ ping 10.0.0.2

Lo que hemos hecho es crear un tunel no cifrado entre vpnsvr y vpncln (que además de servidor VPN es un router perimetral). En definitiva, es como si tuviésemos un cable dedicado que conecta vpncln y vpnsvr (aunque de momento ese cable es inseguro).

OpenVPN con claves simétricas

Vamos a usar la opción de cifrado más sencilla de OpenVPN: una clave estática compartida. Para ello haremos lo siguiente:

En primer lugar vamos a crear una clave estática compartida en el servidor OpenVPN:

root@vpnsvr$ openvpn --genkey --secret estatica.key

Después deberemos copiar esta clave en el cliente. Por ejemplo, podemos usar ssh:

root@vpncln$ scp estatica.key 11.11.11.2:/etc/openvpn/keys/

A continuación vamos a crear el archivo de configuración del servidor. Dicho archivo estará ubicado en /etc/openvpn/ y su nombre puede ser cualquiera. Por ejemplo "vpnsvr.conf"

## Archivo vpnsvr.conf local 12.12.12.2 dev tun ifconfig 10.0.0.1 10.0.0.2 secret /etc/openvpn/keys/estatica.key

Por otro lado, en el cliente, también debemos crear un archivo de configuración, en /etc/openvpn/ con el siguiente contenido:

### Archivo vpncln.conf remote 12.12.12.2 dev tun ifconfig 10.0.0.2 10.0.0.1 secret /etc/openvpn/keys/estatica.key

Ahora debemos detener OpenVPN en ambos extremos mediante /etc/init.d/openvpn stop. Para iniciarlo, haremos lo siguiente:

En el servidor VPN:

root@vpnsvr$ openvpn /etc/openvpn/vpnsvr.conf

En el cliente:

root@vpncln$ openvpn /etc/openvpn/vpncln.conf

De nuevo deberíamos poder hacer ping entre los extremos del tunel. Y de nuevo, si añadimos las rutas adecuadas podremos acceder a la LAN.

Conexión de un PC con un servidor

Hasta ahora nos hemos preocupado de establecer conexiones VPN entre dos máquinas, de forma que se ven entre sí. A lo sumo, los más inquietos habrán creado rutas estáticas en el cliente, para poder acceder a la red que hay tras el servidor OpenVPN. Pero... ¿Y si el usuario no tiene conocimientos de redes, y no puede o no sabe crear una ruta estática? OpenVPN provee un mecanismo para que estas rutas se generen automáticamente, sin necesidad de establecer rutas manualmente: la opción route

Supongamos la siguiente topología:

Ahora vamos a estudiar los siguientes archivos de configuración. Primero el servidor:

## Archivo vpnsvr2.conf dev tun proto udp ifconfig 10.0.0.1 10.0.0.2 local 12.12.12.2 secret /etc/openvpn/keys/statica.key keepalive 10 60 comp-lzo daemon

Vamos a ver cada una de las opciones:

  • Las opciones iniciales, hasta secret ya las hemos visto.
  • keepalive 10 60 indica que la conexión se mantiene activa con comprobaciones de ping cada 10 segundos. Si tras 60 segundos no hay respuesta, la conexión se da por terminada.
  • comp-lzo permite comprimir el tráfico. Esta opción debe estar tanto en el cliente como en el servidor.
  • daemon permite poner OpenVPN en modo escucha

Por otro lado, está la configuración del cliente:

## Archivo vpncln2.conf remote 12.12.12.2 dev tun ifconfig 10.0.0.2 10.0.0.1 route 192.168.1.0 255.255.255.0 secret /etc/openvpn/keys/statica.key keepalive 10 60 comp-lzo

NOTA sobre IPTABLES: si resulta que el servidor VPN está detrás de un firewall iptables (u otro tipo de firewall), habrá que tocar las iptables para que el tráfico de OpenVPN viaje sin problemas. Para resolver este problema, en primer lugar tenemos que tener claro si OpenVPN está usando TCP o UDP. Por rendimiento, se recomienda utilizar UDP (opción proto udp). Las reglas para la siguiente topología podrían ser algo como lo siguiente:

iptables -A INPUT -p udp --dport 1194 -j ACCEPT iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT iptables -A INPUT -i tun+ -j ACCEPT iptables -A OUTPUT -o tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -o tun+ -j ACCEPT

Un servidor OpenVPN no tiene por qué necesariamente residir en el gateway. De hecho puede estar ubicado dentro de la LAN, de forma que el firewall redirija (en el cado de iptables mediante DNAT) el tráfico al puerto correspondiente (por defecto, 1194 UDP) hacia el servidor OpenVPN.



Una última nota: OpenVPN convive perfectamente con NAT. Es decir, aunque en el gráfico aparezca un cliente directamente conectado a Internet, no tiene por qué ser así. Quizá el siguiente gráfico lo deje un poco más claro.

El hecho de que el cliente está detrás de un router que está enmascarándole, no requiere de ninguna consideración desde el punto de vista de OpenVPN.


Conexiones site-to-site con OpenVPN

Vamos a pensar en esta topología. Existe una oficina principal (HQ) y una sucursal (BRANCH). En este caso deseamos una conexión permanente entre ellas.

En este caso, los archivos de configuración son los siguientes. En el servidor:

remote 11.11.11.1 proto udp port 1194 dev tun ifconfig 10.0.0.1 10.0.0.2 persist-tun persist-local-ip persist-remote-ip comp-lzo keepalive 10 60 secret /etc/openvpn/vpn.key route 192.168.0.0 255.255.255.0 chroot /tmp/openvpn user nobody group nogroup log-append /var/log/openvpn/vpn.log verb 1

En cuanto al cliente (la sucursal):

remote 12.12.12.2 proto udp port 1194 dev tun ifconfig 10.0.0.2 10.0.0.1 persist-tun persist-local-ip persist-remote-ip comp-lzo keepalive 10 60 secret /etc/openvpn/estatica.key route 192.168.1.0 255.255.255.0 chroot /tmp/openvpn user nobody group nogroup log-append /var/log/openvpn/vpn.log verb 1

Conexiones roadwarrior

En las conexiones roadwarrior, se tiene una red privada con uno o varios clientes que accederán a la red como si fueran parte de ella (arquitectura host-to-net). Se trata de una configuración típica, en la que diferentes usuarios (empleados) de una organización se conectan a los recursos de la oficina mientras están en sus casas o en un lugar distante.

Para este apartado, vamos a introducir algunas novedades con respecto a los anteriores:

  • Hasta ahora, especificábamos la IP del servidor y la IP del cliente en los archivos de configuración. En este caso vamos a configurar el servidor para que asigne una IP a cada nuevo cliente que se conecte.
  • Hasta ahora hemos usado una clave estática. Pero... ¿Qué pasa si dicha clave es comprometida? Habría que redistribuir a todos los clientes una nueva clave. En esta ocasión vamos a utilizar una infraestructura PKI, de forma que cada cliente tenga su propio certificado individual.

Lo que a mi juicio puede parecer más confuso es la construcción de la PKI. Vamos a empezar por ahí.

Creación de una PKI para OpenVPN

Lo que vamos a hacer es lo siguiente:

  1. Crear una CA (Certification Authority) con la que se firmarán todos los certificados tanto de servidor como de clientes.
  2. Crear una clave privada y un certificado de clave pública para el servidor. Después firmar el certificado con la clave privada de la CA.
  3. Crear una clave privada y un certificado de clave pública para cada cliente. Después firmar el certificado con la clave privada de la CA.

Crear la CA

En primer lugar, vamos a generar el certificado público y la clave privada de la CA. Para ello se va a hacer uso de los scripts proporcionados por OpenVPN. Para poder disponer de dichos scripts, haremos lo siguiente:

root@vpnsvr$ mkdir /etc/openvpn/easy-rsa root@vpnsvr$ mkdir /etc/openvpn/easy-rsa/2.0 root@vpnsvr$ cp /usr/share/doc/openvpn/examples/esasy-rsa/2.0 /etc/openvpn/easy-rsa/2.0

Ya tenemos disponbiles los scripts. En realidad estos scripts hacen posible un manejo sencillo de otra herramienta, openssl, en la que OpenVPN se apoya para cifrar las comunicaciones.

Para crear la clave privada y pública de la CA primero debemos definir cierta información importante sobre la CA, como la longitud de la clave, el país o la organización emisora. Por ello, nuestro primer paso, es editar el archivo llamado vars (en /etc/openvpn/easy-rsa/2.0) editando los valores de las variables KEY_SIZE, KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG y KEY_EMAIL. Por ejemplo:

export KEY_SIZE=2048 export KEY_COUNTRY=ES export KEY_PROVINCE=MA export KEY_CITY=Marbella export KEY_ORG="Guadalpin.es" export KEY_EMAIL="mauri@guadalpin.es"

Después de esto vamos a ejecutar los siguientes scripts siguientes:

root@vpnsvr$ . ./vars root@vpnsvr$ ./clean-all root@vpnsvr$ ./build-ca

NOTA: Lo explico:

  • El primer comando, exporta las variables de entorno presentes en el script (incluidas las que hemos modificado).
  • El segundo comando crea un directorio para las claves.
  • El tercer comando crea la clave privada y el certificado de clave pública autofirmado de la CA.

Después de esto se han creado dos nuevos archivos en la carpeta /etc/openvpn/easy-rsa/2.0/keys/:

  • ca.crt: fichero correspondiente al certificado público de la CA.
  • ca.key: fichero correspondiente a la clave privada de la CA, la cual debe mantenerse protegida ya que es la clave más importante de toda la PKI.

Crear la clave/certificado del servidor

Ahora vamos a centrarnos en la clave privada y el certificado de clave pública del servidor. Gracias a los scripts de OpenVPN, vamos a tener que ejecutar un único script para que se realicen las siguientes acciones:

  1. Generar una clave privada.
  2. Generar una solicitud de firma de certificado.
  3. Firmar mediante la clave privada de la CA el certificado de clave pública.

Todo ello queda reducido a lo siguiente:

root@vpnsvr$ ./build-key-server vpnsvr

Durante el proceso de creación de la clave deberemos responder algunas preguntas. Hay que responder afirmativamente a la pregunta Sign the certificate? y 1 out of 1 certificate requests certified, commit? [y/n]. Tras realizar estos pasos, hemos generado los siguientes archivos:

  • servidor.crt: archivo correspondiente al certificado público del servidor.
  • servidor.key: archivo correspondiente a la clave privada del servidor, la cual debe permanecer protegida.
  • 01.pem: archivo correspondiente al certificado público del servidor en formato PEM. El nombre del archivo proviene de su número de serie del certificado, el cual es 01.
  • servidor.csr: este archivo es una solicitud de firma de certificado. Aunque el certificado ya está creado, OpenVPN nos deja este archivo por si debemos volver a firmar el certificado con una nueva CA.

Crear la clave/certificado de cada cliente

Al igual que con la clave/certificado del servidor, con un sencillo script, vamos a crear la clave privada y el certificado de clave pública del cliente firmado por la clave privada de la CA. Ejecutamos:

root@vpnsvr$ ./build-key vpncln

Ahora tenemos los siguientes archivos adicionales:

  • client.crt: archivo correspondiente al certificado público del cliente.
  • client.key: archivo correspondiente a la clave privada del cliente, la cual debe permanecer protegida.
  • 02.pem: archivo correspondiente al certificado público del cliente en formato PEM. El nombre del archivo proviene de su número de serie del certificado, el cual es 02.
  • client.csr: este archivo sirve para poder crear el certificado del cliente en otra máquina que pueda crearlo y firmarlo, ya que este archivo tiene toda la información que le hace falta.

NOTA: Aunque no le hayamos puesto una contraseña al certificado, es posible asignarle una contraseña después con el script build-key-pass del siguiente modo:

root@vpnsvr$ ./build-key-pass vpnsvr

Crear los parámetros de Diffie-Hellman

El protocolo Diffie-Hellman permite el intercambio secreto de claves entre dos partes que sin que éstas hayan tenido contacto previo, utilizando un canal inseguro, y de manera anónima (sin autenticar). Se emplea generalmente como medio para acordar claves simétricas (de sesión) que serán empleadas para el cifrado de una sesión, como es el caso de una conexión VPN. Los parámetros de Diffie-Hellman son necesarios para que se pueda ejecutar el protocolo DH. El tamaño de estos parámetros dependerá del valor que le hayamos asignado a la variable KEY_SIZE en el script vars. Para generar los parámetros de DH, ejecutaremos el siguiente script:

root@vpnsvr$ ./build-dh

Como resultado, se ha generado el archivo dhxxxx.pem donde xxxx se corresponde con el tamaño de la clave definio en el archivo vars. Es importante que el archivo dh2048.pem solamente esté en el servidor OpenVPN, y nunca sea copiado a los cliente.

Creación de una clave TLS-AUTH

Además de la encriptación que proporcionarán las claves, podemos añadir un nivel extra de seguridad con una clave TLS-AUTH. Añadiendo esta opción en ambos extremos de la VPN añadimos una firma HMAC extra a todos los paquetes del protocolo Handshake de SSL/TLS garantizando así integridad. De esta forma nos protegemos de ataques DoS y escaneo de puertos. Además, si la firma no es correcta, la conexión queda invalidada y se interrumpe.

Para crear una clave TLS-AUTH debemos ejecutar el siguiente comando:

root@vpnsvr$ cd keys/ root@vpnsvr$ openvpn --genkey --secret ta.key

Después de esto, hemos generado un nuevo archivo, ta.key, que deberá estar en los clientes y en el servidor.

Distribución de archivos

Ya hemos terminado con la creación nuestra CA, así como los certificados de servidor y clientes. Ahora vamos a distribuir los archivos. En el servidor deben estar los siguientes archivos:

  • ca.crt
  • dh2048.pem
  • ta.key
  • vpnsvr.crt
  • vpnsvr.key

Vamos a ubicar todos estos archivos en la carpeta /etc/openvpn/keys, del siguiente modo:

root@vpnsvr$ mkdir -m 0700 /etc/openvpn/keys root@vpnsvr$ cp ca.crt ../../keys root@vpnsvr$ mv dh2048.pem ta.key vpnsvr.crt vpnsvr.key ../../keys

Del mismo modo, en el cliente también debemos ubicar los archivos siguientes:

  • ca.crt
  • ta.key
  • vpncln.crt
  • vpncln.key

Esta copia se realizará al lugar adecuado, dependiendo si el cliente es Linux o es Windows. En el caso de Linux, los archivos estarán ubicados en /etc/openvpn/keys (con los permisos 700) y en Windows en C:\Program files\OpenVPN\config\keys.

Los archivos de configuración

Lo último que nos queda es configurar cliente y servidor. Los siguientes son archivos válidos para el servidor y el cliente.

Para el servidor:

local 12.12.12.2 port 1194 proto udp dev tun daemon server 10.0.0.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 192.168.1.50" max-clients 25 ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/vpnsvr.crt key /etc/openvpn/keys/vpnsvr.key dh /etc/openvpn/keys/dh2048.pem tls-auth /etc/openvpn/keys/ta.key 0 cipher BF-CBC comp-lzo keepalive 10 120 log-append /var/log/openvpn.log status /var/log/openvpn-status.log ifconfig-pool-persist /etc/openvpn/ipp.txt mute 20 verb 4 client-to-client (opcional) persist-key persist-tun

A continuación vamos a describir brevemente lo que hace cada línea del fichero de configuración del servidor OpenVPN:

  • local 212.128.44.254: vinculamos OpenVPN a la interfaz con la dirección IP 212.128.44.254.
  • port 1194: utilizamos el puerto 1194.
  • proto udp: se utilizará el protocolo UDP como protocolo de transporte del túnel.
  • dev tun: indica que vamos a implementar un túnel mediante un dispositivo "tun" de los drivers TUN/TAP.
  • daemon: pone a OpenVPN en modo escucha. El servidor va a segundo plano.
  • server 10.0.0.0 255.255.255.0: El servidor se asigna a sí mismo la dirección .1 como extremo del túnel y asignará las direcciónes IP de la VPN a los clientes que se vayan conectando.
  • push "route 192.168.1.0 255.255.255.0": añadimos una ruta en la tabla de rutas de los Clientes OpenVPN. Mediante esta línea indicamos al Cliente OpenVPN que envie los paquetes que tengan como destino la red de la oficina (192.168.1.0) por la interfaz del túnel, por lo que los Clientes OpenVPN podrán alcanzar la red de la oficina utilizando un túnel seguro por Internet.
  • push "dhcp-option DNS 192.168.0.50": con esta opción indicamos al cliente cual debería ser su DNS que probablemente deseemos definir, para que el cliente pueda usar la DNS de la oficina.
  • max-clients 25: indica que solo podrán haber 25 clientes vpn simultáneamente conectados.
  • ca ca.crt: cargamos el certificado público de la CA.
  • cert servidor.crt: cargamos el certificado del Servidor OpenVPN.
  • key servidor.key: cargamos la clave privada del Servidor OpenVPN.
  • dh dh1024.pem: cargamos los parámetros Diffie Hellman.
  • tls-auth /etc/openvpn/keys/ta.kay 0: con esta opción habilitamos la inclusión de una firma HMAC en las transacciones SSL/TLS. cuando se usa la opción tls-auth y una llave estática, se debe definir una dirección (en este caso 0). El parámetro dirección habilita el uso de 4 llaves (HMAC-send, cipher-encrypt, HMAC-receive, cipher-decrypt) para que cada dirección del flujo de datos tenga su conjunto de llaves HMAC y de cifrado. La dirección debe ser complementaria en cada lado de la conexión, por ejemplo, del lado del servidor usa 0 y del lado del cliente(s) usa 1.
  • cipher BF-CBC: cifrado blowfish. Existen otras posibilidades:
    • cipher BF-CBC = Blowfish (default)
    • cipher AES-128-CBC = AES
    • cipher DES-EDE3-CBC = Triple-DES
  • comp-lzo: indica que se va a utilizar la librería de compresión LZO.
  • keepalive 10 120: el Servidor OpenVPN enviará un ping cada 10 segundos y esperará 120 segundos máximo para recibir contestación. En caso negativo deducirá que el otro extremo ha caido y cerrará la conexión.
  • log-append /var/log/openvpn.log: Escribe los log en el archivo indicado.
  • status /var/log/openvpn-status.log: Registro de eventos para el estado de conexiones. En el log de estado se registra información sobre conexiones activas, truncadas, IP pública origen, certificado, IP virtual, bytes enviados y bytes recibidos por el cliente. Este archivo de estado es actualizado cada minuto.
  • ifconfig-pool-persist /etc/openvpn/ipp.txt: mantiene un fichero llamado "ipp.txt" en el que se encuentran los clientes que se conectan al incluyendo la dirección IP que se le ha asignado y el Common Name del certificado que han entregado al servidor OpenVPN.
  • mute 20: Si se registran 20 mensajes consecutivos de la misma categoria de log serán omitidos.
  • verb 4: nivel de severidad con que se guardan los log.
    • 0 -- quiet except for fatal errors.
    • 1 -- mostly quiet, but display non-fatal network errors.
    • 3 -- medium output, good for normal operation.
    • 9 -- verbose, good for troubleshooting.
  • client-to-client: esta línea es opcional y sirve para que los clientes vpn puedan comunicarse entre ellos o no.
  • persist-key: permite que las claves no tengan que ser re-leidas cuando el Servidor OpenVPN es reiniciado.
  • persist-tun: permite que el túnel no tenga que ser cerrado y re-abierto de nuevo tras reiniciar el Servidor OpenVPN.

En el caso del cliente:

client pull dev tun proto udp remote 12.12.12.2 1194 persist-key persist-tun ca ca.crt cert vpncln.crt key vpncln.key tls-auth ta.key 1 comp-lzo verb 6 ns-cert-type server

Donde los parámetros anteriores significan lo siguiente:

  • client: indicamos a OpenVPN que esta máquina actuará como cliente.
  • pull: indica al servidor OpenVPN que aceptará opciones impuestas, como rutas, por ejemplo. Es una opción complementaria a "push" y solo se debe usar en situaciones en las que se confía en el servidor.
  • dev tun: ya comentada.
  • proto udp: ya comentada.
  • remote 12.12.12.2 1194: indica a que máquina se tiene que conectar para establecer el túnel y el puerto utilizado para ello.
  • persist-key:ya comentada
  • persist-tun: ya comentada
  • ca ca.crt: ya comentada
  • cert vpncln.crt: ya comentada
  • key vpncln.key: ya comentada
  • tls-auth ta.key 1: ya comentada
  • cipher BF-CBC: ya comentada
  • comp-lzo: ya comentada
  • verb 6: ya comentada
  • ns-cert-type server: evita que los clientes se conecten a un servidor que no tenga la designación "nsCertType=server" en su certificado. Esto se consigue al ejecutar el guión "build-key-server".

Ahora podemos hacer pruebas desde un cliente Linux o desde un cliente Windows. Debemos tener en cuenta que el cliente Linux necesitará que se especifique correctamente la ruta a las claves/certificados. Por ejemplo key /etc/openvpn/keys/vpncln.key. En Windows ubicaremos las claves/certificados en C:\Program Files\OpenVPN\config\

Práctica. Observa la siguiente topología:

En ella hay configurados dos VPNs:

  • La de ellos utiliza una clave estática para una conexión site-to-site entre la oficina HQ y Branch. El puerto empleado para esta VPN es el UDP 11944
  • La segunda utiliza una infraestructura de PKI para recibir múltiples conexiones de clientes roadwarrior. El puerto empleado para esta VPN es el puerto por defecto, UDP 1194.

Empleando servidores Debian para los gateways, y un cliente Windows 7 con OpenVPN GUI instalado para el cliente roadwarrior, configura una infraestructura como la pedida.