Tutoriales de VPS
Montar un servidor OpenVPN en un VPS (2026): Ubuntu 24.04, Easy-RSA, UFW y configuración del cliente
Monta un servidor OpenVPN en un VPS con Ubuntu: certificados Easy-RSA, UFW, NAT, configuración .ovpn del cliente, verificación de conexión y revocación de certificados.
Montar un servidor OpenVPN en un VPS (2026): Ubuntu 24.04, Easy-RSA, UFW y configuración del cliente
OpenVPN es adecuado para escenarios de acceso remoto que necesitan compatibilidad con Windows, macOS, Linux, Android, iOS y routers. No es necesariamente más rápido que WireGuard, pero sus clientes son maduros y los permisos de los certificados son claros, por lo que sigue siendo habitual en el acceso a la intranet corporativa, el mantenimiento remoto de dispositivos del hogar y el cifrado en redes Wi-Fi públicas.
Este artículo toma Ubuntu 22.04/24.04 como ejemplo y monta un servidor con autenticación por certificados usando OpenVPN y Easy-RSA de los repositorios del sistema. Al final tendrás un archivo .ovpn que se puede importar directamente en OpenVPN Connect, y habrás tratado el reenvío de IP, UFW, NAT y la revocación de clientes.
| Número de usuarios | Configuración recomendada | Escenarios adecuados |
|---|---|---|
| 1-5 personas | 1 núcleo / 1GB / 20GB SSD | SSH, paneles de intranet y navegación ligera |
| 5-20 personas | 2 núcleos / 2GB / 40GB SSD | Acceso de oficina, servicios de archivos y navegación diaria |
| Más de 20 personas | 4 núcleos / 4GB en adelante | Muchos clientes concurrentes; requiere monitorizar ancho de banda y número de conexiones |
El cifrado de OpenVPN depende bastante del rendimiento de un solo núcleo. El VPS también necesita una IPv4 pública, y el entorno de virtualización debe permitir crear dispositivos TUN. Antes de desplegar, ejecuta:
test -c /dev/net/tun && echo "TUN available" || echo "TUN unavailable"
ip route show default
Si /dev/net/tun no existe, activa TUN/TAP en el panel de control del VPS o contacta con tu proveedor.
Primero actualiza el sistema e instala el software necesario:
sudo apt update
sudo apt install -y openvpn easy-rsa ufw
openvpn --version | head -n 1
La documentación oficial de Ubuntu usa Easy-RSA para crear una CA privada y emitir certificados separados para el servidor y para cada cliente. Copia el directorio de trabajo:
sudo make-cadir /etc/openvpn/easy-rsa
sudo -i
cd /etc/openvpn/easy-rsa
./easyrsa init-pki
./easyrsa build-ca
build-ca pedirá que establezcas una contraseña de CA. Esta contraseña solo se usa al emitir o revocar certificados; no descargues pki/private/ca.key en clientes normales.
El servicio no puede esperar a que se introduzca la contraseña de la clave privada al arrancar, por lo que la clave del servidor usa nopass:
cd /etc/openvpn/easy-rsa
./easyrsa gen-req server nopass
./easyrsa sign-req server server
./easyrsa gen-dh
openvpn --genkey secret /etc/openvpn/ta.key
Copia los archivos que necesita el servidor y restringe los permisos de la clave privada:
cp pki/ca.crt /etc/openvpn/
cp pki/issued/server.crt /etc/openvpn/
cp pki/private/server.key /etc/openvpn/
cp pki/dh.pem /etc/openvpn/
chmod 600 /etc/openvpn/server.key /etc/openvpn/ta.key
Crea /etc/openvpn/server.conf:
port 1194
proto udp4
dev tun
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn-ipp.txt
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-crypt /etc/openvpn/ta.key
remote-cert-tls client
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
auth SHA256
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
keepalive 10 120
persist-key
persist-tun
user nobody
group nogroup
explicit-exit-notify 1
verb 3
redirect-gateway significa que todo el tráfico del cliente pasa por el VPS. Si solo quieres acceder al servidor o a una intranet doméstica, elimina esta línea y publica subredes concretas, por ejemplo:
push "route 192.168.10.0 255.255.255.0"
Activa el reenvío IPv4:
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/50-enable-ipv4-forwarding.conf
sysctl -p /etc/sysctl.d/50-enable-ipv4-forwarding.conf
Primero comprueba el nombre de la interfaz de red pública; no supongas directamente que es eth0:
WAN_IF=$(ip route show default | awk '/default/ {print $5; exit}')
echo "$WAN_IF"
Si UFW ya está activado en el VPS, permite primero SSH y OpenVPN. Si SSH usa un puerto distinto de 22, sustituye la regla correspondiente:
ufw allow OpenSSH
ufw allow 1194/udp
Edita /etc/default/ufw y cambia la política de reenvío a:
DEFAULT_FORWARD_POLICY="ACCEPT"
Añade el bloque NAT al principio del archivo /etc/ufw/before.rules, donde eth0 debe sustituirse por la interfaz de red pública que acabas de encontrar:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
Confirma que el grupo de seguridad de la plataforma cloud también permite UDP 1194 y luego recarga UFW:
ufw enable
ufw reload
ufw status verbose
Antes de activar el firewall, asegúrate de mantener abierta la sesión SSH actual y confirma que las reglas de SSH son correctas. Si te bloqueas, consulta Lista de auto-rescate cuando no puedes entrar por SSH tras activar UFW en un VPS.
La documentación oficial de Ubuntu usa el servicio de plantilla openvpn@配置文件名. Como el archivo de configuración es /etc/openvpn/server.conf, el comando de inicio es:
systemctl enable --now openvpn@server
systemctl status openvpn@server --no-pager
ip addr show tun0
Cuando todo va bien, el registro muestra Initialization Sequence Completed y crea 10.8.0.1:
journalctl -u openvpn@server -n 100 --no-pager
ss -lunp | grep 1194
Algunos paquetes de Debian/Ubuntu colocan la configuración del servidor en /etc/openvpn/server/server.conf, con el nombre de servicio correspondiente openvpn-server@server. Si openvpn@server indica que no encuentra la configuración, ejecuta systemctl list-unit-files | grep openvpn para confirmar qué estructura de directorios usa el paquete actual.
Cada dispositivo usa su propio certificado; no hagas que un teléfono, un ordenador y un router compartan una misma clave privada de cliente:
cd /etc/openvpn/easy-rsa
./easyrsa gen-req phone nopass
./easyrsa sign-req client phone
Genera la configuración de archivo único /root/phone.ovpn, sustituyendo YOUR_VPS_IP por la IP pública o el dominio del servidor:
cat > /root/phone.ovpn <<EOF
client
dev tun
proto udp4
remote YOUR_VPS_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
auth SHA256
verb 3
<ca>
$(cat pki/ca.crt)
</ca>
<cert>
$(sed -ne '/BEGIN CERTIFICATE/,$p' pki/issued/phone.crt)
</cert>
<key>
$(cat pki/private/phone.key)
</key>
<tls-crypt>
$(cat /etc/openvpn/ta.key)
</tls-crypt>
EOF
chmod 600 /root/phone.ovpn
Descarga este archivo de forma segura mediante SFTP e impórtalo en OpenVPN Connect. No lo reenvíes por discos en la nube públicos ni por grupos de chat, porque .ovpn contiene la clave privada del cliente.
Tras conectarse el cliente, comprueba en orden:
ping 10.8.0.1
curl https://ifconfig.me
En modo túnel completo, el segundo comando debe devolver la IP pública del VPS. En el servidor, consulta las conexiones de los clientes:
ip addr show tun0
journalctl -u openvpn@server -f
Las principales diferencias entre OpenVPN y WireGuard son las siguientes:
| Comparación | OpenVPN | WireGuard |
|---|---|---|
| Compatibilidad de clientes | Muy amplia, habitual en entornos empresariales | Buen soporte en sistemas nuevos |
| Método de configuración | CA y certificados de cliente | Claves pública/privada y Peers |
| Rendimiento | Mayor sobrecarga de cifrado y en espacio de usuario | Normalmente menor latencia y mayor rendimiento |
| Revocación de permisos | Revocar un certificado individual | Eliminar el Peer correspondiente |
Si valoras más la velocidad y una configuración sencilla, consulta Tutorial para montar WireGuard VPN en un VPS.
Si pierdes un teléfono o un ordenador, revoca el certificado correspondiente de inmediato:
cd /etc/openvpn/easy-rsa
./easyrsa revoke phone
./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/crl.pem
chmod 644 /etc/openvpn/crl.pem
Añade lo siguiente a la configuración del servidor:
crl-verify /etc/openvpn/crl.pem
Luego reinicia el servicio:
systemctl restart openvpn@server
Confirma que UDP 1194 está permitido tanto en el firewall del sistema como en el grupo de seguridad de la nube, y comprueba si la IP, el puerto y proto del cliente coinciden con los del servidor:
ss -lunp | grep 1194
journalctl -u openvpn@server -n 100 --no-pager
Normalmente se debe a un error en el reenvío de IP, en el nombre de la interfaz NAT o en la política de reenvío de UFW:
sysctl net.ipv4.ip_forward
ip route show default
grep DEFAULT_FORWARD_POLICY /etc/default/ufw
iptables -t nat -L POSTROUTING -n -v
Reinicia primero el servicio y luego revisa el error concreto:
systemctl restart openvpn@server
journalctl -u openvpn@server -xe --no-pager
Revisa sobre todo las rutas de los certificados, los permisos de archivos y si tls-crypt coincide en ambos extremos. No actives BF-CBC ni desactives la verificación de certificados sin criterio para ser compatible con clientes antiguos; actualiza el cliente.
- TUN/TAP está disponible, la IP pública del VPS es estable y UDP 1194 está permitido en el grupo de seguridad.
- La clave privada de la CA solo se guarda en el servidor o en una copia de seguridad sin conexión, y cada dispositivo tiene su propio certificado.
net.ipv4.ip_forward=1está en vigor y NAT usa la interfaz de red pública correcta.- La configuración del cliente no se transmitió por canales públicos y los permisos del archivo son
600. - El servicio está configurado para arrancar al inicio y los registros no muestran errores persistentes de TLS ni de enrutamiento.
- Se han documentado los pasos de revocación de certificados y se hace copia de seguridad periódica de
/etc/openvpn/easy-rsa/pki.
La parte más propensa a errores de un despliegue OpenVPN no es la generación de certificados, sino el puerto, el firewall y la cadena de reenvío. Primero consigue que el cliente pueda llegar a 10.8.0.1 y luego investiga la salida pública; así distingues rápidamente los problemas de TLS de los de NAT.