OpenVPN: Parte 2 — Cómo funciona: PKI, certificados y configuración básica

En esta parte se explica de qué consiste la instalación de OpenVPN Community y cómo crear una configuración mínima funcional: autoridad certificadora, certificados del servidor y de clientes, clave tls-crypt, archivos server.conf y client.ovpn. Los ejemplos están pensados para OpenVPN 2.6 y 2.7 en Linux.

Cómo confían entre sí clientes y servidor

OpenVPN usa una infraestructura de claves públicas (PKI):

• autoridad certificadora (CA) — par de claves con el que se firman todos los demás certificados. La clave privada de la CA es lo más valioso en la instalación; conviene no guardarla en el servidor VPN;
• certificado del servidor — firmado por la CA y marcado como de servidor. El cliente comprueba que se conecta al servidor y no a otro cliente con un certificado similar;
• certificados de clientes — uno por cada usuario o dispositivo;
• lista de certificados revocados (CRL) — para certificados de empleados despedidos o dispositivos perdidos.

Al conectarse, las partes intercambian certificados y verifican que ambos estén firmados por la misma CA. En este esquema la contraseña de usuario no es necesaria, pero se puede añadir como segundo factor.

Autoridad certificadora con Easy-RSA

Easy-RSA es la utilidad del proyecto OpenVPN para gestionar la PKI. En Debian y Ubuntu se instala con el paquete easy-rsa. Conjunto mínimo de comandos:

./easyrsa init-pki
./easyrsa build-ca
./easyrsa build-server-full server nopass
./easyrsa build-client-full ivanov

• init-pki crea el directorio pki;
• build-ca crea la autoridad certificadora y pide una contraseña para su clave — establece una robusta;
• build-server-full server nopass emite la clave y el certificado del servidor sin contraseña, de lo contrario el servicio no podrá arrancar sin intervención humana;
• build-client-full ivanov emite la clave y el certificado del cliente; con contraseña — si el usuario la introducirá al conectarse, con nopass — si no.

El resultado queda en los directorios: pki/ca.crt — certificado de la CA, pki/issued/ — certificados, pki/private/ — claves privadas.

No es obligatorio generar parámetros de Diffie–Hellman (gen-dh). La documentación de OpenVPN recomienda dh none: entonces se usa intercambio de claves en curvas elípticas (ECDH), que es más rápido y moderno.

Clave tls-crypt

El parámetro tls-crypt cifra y firma todo el canal de control con una clave compartida. Esto aporta tres ventajas: el servidor no responde a paquetes sin la clave, por lo que un escáner no ve OpenVPN en el puerto; los certificados no se transmiten en claro; ataques al stack TLS desde terceros son imposibles.

La clave se crea con el comando:

openvpn --genkey tls-crypt tc.key

El archivo tc.key se copia en el servidor y en todos los perfiles de cliente.

UDP o TCP

Por defecto conviene elegir UDP. Dentro del túnel ya van conexiones TCP de las aplicaciones, y cuando el transporte también es TCP, en pérdidas de paquetes las retransmisiones se solapan y la conexión se ralentiza mucho.

TCP (habitualmente en el puerto 443) está justificado cuando UDP está bloqueado: redes hoteleras y corporativas a veces permiten solo tráfico web. Un esquema cómodo es tener dos instancias del servidor: principal por UDP y de reserva por TCP.

Configuración mínima del servidor

Archivo /etc/openvpn/server/server.conf:

port 1194
proto udp
dev tun
topology subnet
server 10.8.0.0 255.255.255.0

ca ca.crt
cert server.crt
key server.key
dh none
tls-crypt tc.key

keepalive 10 120
persist-tun
user nobody
group nogroup

verb 3
explicit-exit-notify 1

• server 10.8.0.0 255.255.255.0 — subred del túnel; el servidor recibe 10.8.0.1, los clientes — el resto de direcciones;
• keepalive 10 120 — comprobación de enlace cada 10 segundos, desconexión tras 120 segundos de inactividad;
• user y group — tras el arranque el servicio funciona sin privilegios root (en sistemas compatibles con RHEL el grupo se llama nobody);
• explicit-exit-notify 1 — el servidor avisa a los clientes sobre un reinicio y ellos se reconectan de inmediato.

El cifrado no se especifica intencionadamente: las versiones 2.6 y 2.7 negocian el mejor común de la lista data-ciphers.

Para que los clientes vean la red de la oficina, añada una ruta, por ejemplo push "route 192.168.1.0 255.255.255.0", y active en el servidor el reenvío de paquetes (net.ipv4.ip_forward = 1). Todo el tráfico a Internet de los clientes a través del VPN lo dirige la línea push "redirect-gateway def1", pero para eso en el servidor también hará falta NAT.

El servicio se inicia así: systemctl enable --now openvpn-server@server (el nombre tras @ es el nombre del archivo de configuración). En Debian y Ubuntu este servicio mantiene por sí mismo el archivo de estado con los clientes conectados; no es necesario indicar status por separado.

Perfil del cliente

Archivo ivanov.ovpn:

client
dev tun
proto udp
remote vpn.example.ru 1194
resolv-retry infinite
nobind
persist-tun
remote-cert-tls server
verb 3

<ca>
...contenido de ca.crt...
</ca>
<cert>
...contenido de pki/issued/ivanov.crt...
</cert>
<key>
...contenido de pki/private/ivanov.key...
</key>
<tls-crypt>
...contenido de tc.key...
</tls-crypt>

remote-cert-tls server es obligatorio: exige que el certificado en el otro extremo sea realmente de servidor. Sin ello, cualquier cliente con un certificado del mismo CA podría hacerse pasar por servidor.

Revocación de certificado

Cuando un empleado se va, se revoca su certificado:

./easyrsa revoke ivanov
./easyrsa gen-crl

El archivo pki/crl.pem se copia en el servidor, y en server.conf se añade la línea crl-verify crl.pem. El CRL tiene vigencia limitada, por lo que hay que ejecutar gen-crl antes de su caducidad — si no, el servidor dejará de aceptar a todos los clientes.

Errores típicos

• Clave de la CA en el servidor VPN. Si el servidor es comprometido, el atacante podrá emitir sus propios certificados. Mantenga la CA en una máquina separada y copie al servidor solo ca.crt.
• Falta remote-cert-tls server en el perfil. El cliente confiará en cualquier certificado del mismo centro.
• TCP “por si acaso”. Sin necesidad, el transporte TCP solo ralentiza el túnel.
• CRL caducado. Los clientes dejan de conectarse de repente, y en el registro del servidor aparece un error de verificación del CRL.
• No hay reenvío de paquetes. El cliente se conecta, pero no ve la red de la oficina: ip_forward no está activado o en la gateway de la oficina no hay ruta de retorno a la subred del túnel.

Ejemplos paso a paso listos: servidor en MikroTik — «Configuración del servidor OpenVPN en MikroTik RouterOS», servidor en Ubuntu y cliente en Keenetic — «OpenVPN: configuración de servidor Ubuntu y cliente Keenetic». Desplegar un VPN llave en mano se puede contratar en la página «Configuración de VPN».