VPN a prueba de todo en 2026: lista de verificación paso a paso para hardening, permisos y firewall

Por qué el hardening de servidores VPN en 2026 ya no es un lujo sino una obligación

Los ataques son más rápidos, los errores siguen siendo los mismos

Seamos sinceros: un servidor VPN es la puerta de entrada a nuestra red. Si la cerradura está oxidada, poco ayudará lo demás. En 2026, los atacantes han automatizado más del 80 % de los ataques a puntos de túneles públicos; los bots escanean puertos UDP y TCP, verifican versiones de protocolos, configuraciones predeterminadas e incluso diferencias en los retrasos durante el handshake. ¿Tenemos derecho a equivocarnos? No. Cualquier fallo puede llevar a la fuga de datos de clientes, y estaremos justificándonos durante semanas. Mejor invertir en prevención.

Hardening no es dolor, es disciplina

Muchos confunden el hardening con paranoia. En realidad, es disciplina y prácticas repetibles: permisos mínimos, perímetro cerrado, reglas claras de enrutamiento y auditoría regular. Haces bien el trabajo una vez y luego solo mantienes. No construimos un muro de concreto sin ventanas; instalamos puertas inteligentes, cámaras y alarmas. Y sí, no da miedo.

Rendimiento y seguridad son amigos

Existe el mito de que la seguridad mata la velocidad. No es cierto. Los stacks modernos — WireGuard con ChaCha20-Poly1305, OpenVPN con TLS 1.3 y AES-GCM — ofrecen un gran ancho de banda incluso con nftables estrictas y limitaciones del sistema. Sysctl adecuados, filtros eBPF, separación de planos de control y datos — conseguimos seguridad y velocidad. ¿El truco? La configuración. Por eso tenemos esta lista de verificación.

Modelo de amenazas y elección de protocolo: WireGuard, OpenVPN o IPSec

Formulando el modelo de amenazas

Antes de apretar tornillos, hay que definir de quién y qué nos protegemos. El modelo típico de amenazas para un servidor VPN en 2026 incluye: escáneres masivos, fuerza bruta sobre claves, explotación de vulnerabilidades en demonios, ataques phishing a admins, DDoS y limitación de recursos, fugas de claves y configuraciones, errores de enrutamiento y fugas DNS. Por separado están los riesgos en la nube: abuso de metadatos de instancias, políticas IAM débiles, grupos de seguridad demasiado abiertos. Todo influye en la elección del stack y la configuración.

WireGuard: moderno y minimalista

WireGuard se ha convertido en el estándar de facto por su simplicidad y velocidad. Código pequeño, criptografía fuerte por defecto, claves Ed25519, arquitectura stateless. Ideal para sitio a sitio y acceso de usuarios. Pero WireGuard no tiene autenticación por contraseña o MFA integrada; todo se basa en claves. Por eso la gestión y política de claves son fundamentales. ¿Queremos SSO? Habrá que añadir capas, como control de acceso en el coordinador o proxy.

OpenVPN: clásica flexible con TLS 1.3

OpenVPN sigue vigente. Cuando se necesitan PKI complejas, CRL, certificados cliente, autenticación PAM, LDAP o RADIUS, es útil. En 2026 solo usamos TLS 1.3, ECDHE con X25519 o P-256, cifrados AES-256-GCM y políticas estrictas de renegociación. Más complejo de administrar, pero con MFA y ACL granulares listas a través de plugins y scripts.

IPSec e híbridos

IPSec en modo IKEv2 funciona muy bien para túneles intercentros y integración con hardware de red. Es maduro y eficiente, pero requiere paciencia en configuración y políticas sólidas de cifrado. En la práctica, vemos híbridos: WireGuard para teletrabajadores, IPSec entre datacenters, OpenVPN para integraciones específicas. No se trata de discutir qué es mejor, sino de elegir según la tarea y el modelo de amenazas.

Base mínima del sistema: plataforma, actualizaciones, kernel y sistemas de archivos

Distribución y ciclo de vida

¿Planeamos tranquilidad por 5 años? Elegimos LTS. En 2026 son Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9, AlmaLinux 9 o Alpine 3.20+ para instalaciones ligeras. Menos base significa menos paquetes y menos vulnerabilidades. Bloqueamos repositorios, activamos unattended-upgrades o equivalente, pero actualizamos kernel y servicios críticos de forma controlada, con ventanas y rollback.

Kernel LTS y seguridad

Mantenemos ramas LTS del kernel 6.6 o 6.10 con parches recientes. Verificamos que retpoline y mitigaciones spectre estén activados, habilitamos kernel lockdown, limitamos interfaces inseguras: kptr_restrict=2, dmesg_restrict=1, ajustamos unprivileged_userns_clone según política, deshabilitamos BPF para usuarios sin privilegios o configuramos bpf.strict_mode. Para WireGuard conviene módulo kernel nativo, no DKMS.

Sistemas de archivos y montaje

Particiones separadas para /, /var, /var/log, /var/log/audit y, si es posible, /tmp. Montamos /tmp y /var/tmp con noexec,nosuid,nodev. Para /home y /var con nodev,nosuid. En producción es útil el flag immutable en configuraciones raramente modificadas. Los logs los ponemos en disco o volumen separado para evitar que un DDoS con logs bloquee el sistema. Donde se pueda, activamos integridad y control retroactivo con IMA o al menos AIDE.

Tiempo y fuentes de entropía

NTP no es detalle menor. Tiempo desincronizado arruina certificados, auditoría e investigaciones. Usamos chrony con varios servidores, limitamos fuentes y permisos. Para criptografía monitorizamos rngd o jitterentropy, para que máquinas virtuales no tengan problemas de entropía al arrancar.

Principio de mínimos privilegios: usuarios, systemd, capacidades, MAC

Usuarios y grupos

Los demonios VPN corren con usuario de sistema dedicado, sin login ni shell. Carpetas de configuración y claves con permisos 750 o 700, archivos de claves con 600. No hay secretos legibles para todos. Admins con sudo según roles, sin NOPASSWD general, y auditoría obligatoria para escalados.

Hardening de unit-files systemd

Systemd ofrece muchas banderas de protección. Usamos DynamicUser donde se pueda, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, PrivateDevices=true, NoNewPrivileges=true, MemoryDenyWriteExecute=true, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX, LockPersonality=true, ProtectClock=true, ProtectKernelTunables=true, IPAddressDeny=any con excepciones específicas, CapabilityBoundingSet= y AmbientCapabilities con listas precisas. Solo unas líneas más y reducimos mucho la superficie de ataque.

Capacidades Linux y chroot

Si el demonio no necesita CAP_NET_ADMIN tras iniciar, lo removemos. WireGuard a menudo exige derechos de red admin solo al levantar la interfaz; lo demás puede delegarse a un ayudante separado. Evitamos ejecutar como root por defecto, donde sea posible separamos inicialización y runtime. Chroot o bubblewrap para procesos auxiliares reduce riesgo de escape.

SELinux o AppArmor

En 2026 se vive más fácil con perfiles AppArmor en Ubuntu o SELinux en modo Enforcing en RHEL y derivados. Usamos políticas listas y no las desactivamos “para arreglar rápido”. Un perfil que limita el acceso a rutas y syscall no previstas suele salvar en RCE. Sí, a veces hay que ajustar las políticas, pero es una inversión.

Criptografía y gestión de claves: sin magia

Conjuntos modernos de cifrados

OpenVPN solo TLS 1.3, cifrados TLS_AES_256_GCM_SHA384 o TLS_CHACHA20_POLY1305_SHA256, ECDHE con X25519, firmas ECDSA P-256 o Ed25519, RSA mínimo 3072, preferible 4096 por compatibilidad. WireGuard ya usa ChaCha20-Poly1305, Curve25519, BLAKE2s—excelente por defecto. IPSec IKEv2: AES-GCM, PRF-HMAC-SHA2, PFS con ECP256 o X25519. Nada de SHA-1, 3DES ni RC4, ni siquiera en herencia.

Preparación post-cuántica

En 2026 ya probamos híbridos: X25519+Kyber para intercambio de claves, Ed25519+Dilithium para firmas donde el stack lo permita. En producción activamos híbridos solo tras pruebas de compatibilidad. Para OpenVPN es prospecto mediante parches y librerías externas; para terminación TLS en frontend, ya es realidad. Lo importante: no fantasear, seguir recomendaciones del distro y proveedor criptográfico.

PKI, emisión y revocación

Disponemos de CA aislada, offline, con periodo de emisión claro y política de revocación. Emisión de certificados cliente bajo solicitud, con auditoría, expiración automática y vinculación obligatoria a usuario y dispositivo específico. CRL y OCSP actualizados según cronograma, no «como se pueda». Para WireGuard gestión estricta de claves: prohibido usar configuraciones caseras, coordinación mediante controlador o generador con registro.

Almacenamiento de secretos y rotación

Los secretos no van en git ni wiki. Usamos almacenes como Vault o KMS nativos en la nube, y para configuraciones en fichero, sops con claves en KMS o age. Rotación de claves y certificados según calendario: cada 90 a 180 días, o inmediatamente tras compromiso. Cuando un empleado sale, revocamos acceso el mismo día. Automatizar salva; procesos manuales fallan los viernes por la noche.

Firewall y perímetro: nftables, eBPF y sentido común

Política básica de "denegar todo, excepto"

En 2026 nftables es estándar. Políticas por defecto en drop, permitimos solo puertos y protocolos concretos: UDP 51820 para WireGuard, UDP o TCP 1194 para OpenVPN, IKEv2 500 y 4500 para IPSec, además SSH para administración pero con restricciones de origen. Loopback local permitido, todo lo demás con reglas explícitas. Tablas separadas para input, forward, output, cada una con lógica propia, no paquete único supergenérico.

Limitación de velocidad y anti-DDoS

Agregamos límites de frecuencia para nuevas conexiones y paquetes handshake. Para UDP limitamos por IP y subred, usamos sets y maps para dinámica. En kernel activamos tcp_syncookies, aumentamos cola backlog y buffers, pero con moderación. No olvidamos conntrack; debe estar activo y bien configurado para no topar con límites inesperados.

Enrutamiento, NAT y aislamiento

Para WireGuard a menudo aplicamos policy routing: tráfico desde wg0 va por tablas propias con reglas claras. NAT solo donde es necesario y en rangos concretos. Redes para invitados y admins separadas, nada de mezclar todo. En OpenVPN usamos client-config-dir y ajustes para dar a clientes solo rutas y DNS requeridos. Split-tunnel en cliente solo con consentimiento y política.

IPv6, DNS y métricas

IPv6 no es solo "apagarlo". Si está activo, configuramos direccionamiento, RA y firewall igual que IPv4. Cerramos fugas DNS: indicamos resolutores corporativos vía push o configuración peer, prohibimos consultas DNS externas desde red VPN salvo diseño intencionado. Métricas y logs recolectamos aparte, preferible interfaz de gestión dedicada para no interferir con tráfico real.

Apagando lo innecesario: reducimos superficie de ataque

Servicios y paquetes

Revisamos systemctl list-unit-files y ss -tulpen. Apagamos todo no relacionado con VPN y soporte básico: impresoras, avahi, descubrimiento automático, demonios de actualizaciones GUI, rpcbind, etc. Limpiamos paquetes dejando solo lo imprescindible. Menos código, menos vulnerabilidades. Y sí, "por si acaso" no es argumento válido.

Perfil sysctl

Perfil riguroso de sysctl cierra muchas clases de ataque. Para IPv4: net.ipv4.conf.all.rp_filter=1, accept_redirects=0, send_redirects=0, accept_source_route=0, tcp_syncookies=1, icmp_echo_ignore_broadcasts=1. Para IPv6: net.ipv6.conf.all.accept_ra=0 en servidores sin RA, y prohibición de source route. Desactivamos respuesta a paquetes extraños, limitamos enrutamiento solo donde VPN lo requiere. Persistencia con archivos, no echo en runtime.

Contenedores vs bare-metal

Ejecutar VPN en contenedor es posible, pero exige modelo pensado de permisos y capacidades. Enfoques rootless, cgroup v2, netns limitados funcionan, pero aumentan complejidad y pueden afectar rendimiento. Para puntos de alta carga y simplicidad, suele ser mejor VM o bare-metal para minimizar capas de riesgo. Si es contenedor, sea con set de capacidades y perfiles seccomp claramente definidos.

Nube y metadatos

En cloud bloqueamos acceso a metadatos de instancias desde interfaces públicas, usamos mecanismos tipo IMDSv2, security groups con deny-all y allow específicos, subred privada para admin y bastión separado. Claves de acceso almacenadas en KMS, no en disco del servidor. Snapshots cifrados y acceso tan controlado como bases de datos productivas.

Auditoría, registro y monitoreo: ver, saber, reaccionar

Auditoría del sistema

Activamos auditd, registramos intentos de escalada de privilegios, cambios de config, acceso a claves y unit files. Logs de journald enviados remotamente, con rotación y protección contra llenado de disco. En software VPN registramos solo lo necesario para análisis de incidentes, sin exceso de datos personales. Los logs son herramienta, no basurero.

Monitoreo y métricas

Gráficos duran más que palabras. Capturamos métricas de conexiones, latencia, errores de handshake, llenado de buffers, carga CPU e IRQ. Exportadores Prometheus para sistema y software VPN, alertas con SLO: disponibilidad del endpoint, tiempo de establecimiento de túnel, pico de carga. También tests sintéticos: script que levanta túnel de prueba periódicamente y verifica rutas.

Control de integridad y EDR

AIDE o monitoreo de integridad a nivel de paquetes y configs alertan temprano. Agente EDR ligero con reglas para detectar comportamientos atípicos del proceso VPN, análisis de comandos admin y bloqueos a binarios sospechosos no es lujo. Importante no saturar: alertas deben ser accionables o se desactivan.

Procedimientos de respuesta

Los incidentes ocurren. Necesitamos plan corto: quién está de guardia, cómo aislar nodo, cómo pasar tráfico a reserva, qué logs recolectar y dónde enviar. Lista de chequeo de una página resuelve más que veinte diapositivas olvidadas en Confluence. Practicamos cada trimestre.

Operación y procesos: acceso, actualizaciones, respaldo

Acceso admin y MFA

SSH solo por claves, sin contraseña y con restricción IP. MFA para acceso privilegiado vía PAM y llaves FIDO2 cuando se pueda. Proxies de sesión, registro de comandos, reglas sudo minimalistas. Si hay que hacer cambios en producción, hacerlo con conciencia y trazabilidad. Nada de cuentas compartidas; cada acción, personal.

Actualizaciones sin dolor

Ventanas regulares, canarios, backup de configs, rollback automático. Antes de actualizar snapshot de VM o configs; después checklist: interfaz levantado, tráfico fluye, DNS funciona. Bibliotecas de crypto y kernel solo tras tests. No somos héroes, somos ingenieros.

Respaldo y alta disponibilidad

Dos puntos en zonas o datacenters distintos, IP Anycast o DNS geodistribuido, sincronización de listas y claves cliente. Configs en git cifrados, CI para sintaxis, CD para despliegue vía API. Tests frecuentes de failover: que no nos entere el cliente de problemas.

Cumplimiento y privacidad

Si manejamos datos personales, tenemos política de logging y almacenaje. IP es dato personal según muchas leyes. Tiempos de retención, métodos de anonimización y acceso restringido a logs deben estar regulados. Benchmarks CIS para SO y VPN, procesos ISO 27001 y auditorías internas; suena aburrido, pero luego no da vergüenza.

Lista de verificación paso a paso para hardening de servidores VPN

Preparación de la plataforma

1. Elige distribución LTS y fija repositorios. 2. Actualiza sistema, instala kernel LTS, activa mitigaciones necesarias. 3. Separa discos, configura mounts estrictos y volumen para logs. 4. Configura chrony con varias fuentes, limita accesos. 5. Instala AIDE y base inicial de integridad.

Usuarios y servicios

1. Crea usuario sistema para VPN sin shell. 2. Ajusta permisos en directorios y archivos de claves. 3. Hardening de unit files systemd: ProtectSystem, PrivateTmp, CapabilityBoundingSet y otros. 4. Desactiva y elimina servicios y paquetes innecesarios. 5. Activa SELinux Enforcing o perfil AppArmor.

Criptografía y claves

1. Configura solo cifrados modernos y TLS 1.3 en OpenVPN. 2. Organiza CA aislada, emisión y revocación. 3. Implementa rotación obligatoria de claves y certificados. 4. Traslada secretos a almacenamiento seguro. 5. Planifica piloto PQC y pruebas de compatibilidad.

Red y firewall

1. Activa nftables con política deny por defecto. 2. Permite solo puertos y familias de direcciones necesarias. 3. Implementa limitación de velocidad en handshakes y conexiones. 4. Separa enrutamiento y NAT solo donde preciso. 5. Bloquea fugas DNS y configura IPv6 conscientemente.

Auditoría, monitoreo y respuesta

1. Activa auditd y reglas para operaciones clave. 2. Envía logs a colector remoto, configura rotación. 3. Recolecta métricas y alertas según SLO. 4. Documenta plan de respuesta y capacita al equipo. 5. Verifica regularmente integridad y configuración.

Operación y recuperación ante desastres

1. Implementa MFA y políticas sudo estrictas. 2. Programa ventanas de actualización con canarios y rollback. 3. Despliega segundo punto y prueba failover. 4. Guarda configs en repositorio cifrado y con versiones. 5. Realiza pruebas de restauración y documenta resultados.

Errores frecuentes y casos reales

Dejar todo por defecto

Una empresa lanzó OpenVPN con perfil default TLS 1.2, SHA-1 y sin CRL. Con una fuga de clave, el atacante estuvo semanas dentro. Lo arreglaron cuando clientes detectaron actividad extraña. Resultado: actualizan a TLS 1.3, activan CRL y rotación automática. Doloroso, pero efectivo.

Ignorar IPv6

Apagaron IPv6 "para simplificar". Clientes igual tenían IPv6 pública y evitaban DNS corporativos, causando resultados irrisorios y luego problemáticos. Se corrigió configurando IPv6 en VPN, añadiendo rutas y reglas firewall adecuadas para cerrar fugas.

Sin planes de contingencia

Un servidor, un disco, un punto de entrada. Un DDoS viernes, ingenieros despiertan lunes. Ahora tienen dos puntos, canales de reserva y alertas. Una arquitectura sencilla y redundante aporta más que un super-servidor.

Secretos en repositorio

Sí, aún sucede. Claves WireGuard commiteadas en git, luego sorpresa cuando alguien se conecta desde otro país por la noche. Solución sencilla: sops, KMS y políticas estrictas. Alertas para "private_key" en PR ayudan mucho.

Configuraciones prácticas: detalles que ahorran horas

Sysctl útiles para VPN

Parámetros puntuales eliminan latencias y errores raros. Aumentamos net.core.rmem_max y wmem_max, configuramos net.core.default_qdisc=fq y tcp_congestion_control=bbr2 o cubic según pruebas, vigilamos net.netfilter.nf_conntrack_max según memoria y carga. Cada cambio se prueba, no es por “lo que dicen en Internet”.

nftables: sets y maps

Usamos sets para almacenar IPs admin permitidas, y maps para límites dinámicos. Hace las reglas más claras y rápidas. Logging en nft con burst limitado para no saturar discos. Debug con nft monitor trace, pero cuidado en producción.

WireGuard: política AllowedIPs

Error común: dar 0.0.0.0/0 a todos sin necesidad. Asignamos solo subredes necesarias para acceder el cliente. En túneles sitio a sitio: redes explícitas, nada de rutas transitivas extra. Keepalive en redes inestables cada 25 segundos, pero no es cura mágica.

OpenVPN: perfil servidor

tls-version-min 1.3, cipher AES-256-GCM, ncp-ciphers AES-256-GCM, reneg-sec según política, verify-x509-name para clientes, crl-verify, tls-crypt para proteger handshake de escaneo. Plugin auth-pam para MFA y scripts limitados en client-connect si entra en proceso. Y no olvidar —explicit-exit-notify para UDP.

Control de calidad y mejora continua

Benchmarks y SLO

Sin métricas claras navegamos en la niebla. Definimos SLO: tiempo para levantar túnel, ancho de banda con N clientes, latencia media a redes clave. Ejecutamos benchmarks tras cambios mayores. Comparamos gráficos "antes" y "después", no creemos en corazonadas.

CI/CD seguro para configs

Los configs VPN son código. Ramas, revisiones, chequeos estáticos de sintaxis y entornos de prueba. Despliegue vía pipeline, no manual. Así eliminamos error humano y facilitamos rollback. GitOps baja la tensión y sube predictibilidad.

Feedback de usuarios

Si se quejan de "lentitud", no discutimos, medimos. Frecuentemente es DNS, rutas ineficientes o cuello de botella Wi-Fi en cliente. Checklist diagnóstico de cinco pasos ahorra horas: ping rutas, resolución DNS, revisión MTU, traceroute y test de ancho de banda.

Tendencias 2026

Perfiles híbridos PQC en TLS, transición generalizada a nftables, políticas systemd más estrictas, auge de eBPF XDP para filtrado, Zero Trust a nivel dispositivo donde solo entra VPN si pasa posture checks. No hay que implementar todo, pero entender estas tendencias es útil.

Preguntas frecuentes: lo esencial en breve

¿Es necesario cambiar de OpenVPN a WireGuard ya mismo?

Si tienes PKI madura, MFA y procesos maduros con OpenVPN, no hay urgencia. WireGuard ofrece simplicidad y velocidad, pero requerirás reorganizar gestión de accesos. La respuesta correcta depende de tus procesos e integraciones.

¿Se puede mantener VPN en contenedor de forma segura?

Sí, pero con precaución. Necesitas capacidades limitadas, seccomp, rootless, red clara y entender rendimiento. Para cargas altas y simplicidad, es más común preferir VM o bare-metal.

¿Cómo hacer MFA para WireGuard?

A nivel protocolo no es posible. Se implementa controlando emisión y ciclo de vida de claves, acceso vía proxy o agentes externos que verifican postura del dispositivo y usuario antes de entregar configuración.

¿Conviene desactivar IPv6?

Mejor configurarlo bien. Apagarlo suele causar fugas y rutas inesperadas. Si no se necesita IPv6, desactívalo en interfaces y apps de forma ordenada. Si se usa, configúralo y protege firewall y rutas tan estrictamente como IPv4.

¿Con qué frecuencia rotar claves y certificados?

Al menos cada 90-180 días para usuarios; raíces según política y riesgo. Más importante es automatizar y tener proceso probado de revocación ante incidentes. Sin eso, los plazos son solo números.

¿Qué logs conservar y por cuánto tiempo?

Sólo los necesarios para investigación: inicio de sesión, metadatos de conexiones, errores. Datos personales al mínimo. Los tiempos de retención según política y ley, normalmente entre 30 y 180 días, con acceso muy restringido.

¿Qué es más importante: firewall o SELinux?

No es elección. Firewall controla red, SELinux o AppArmor controlan acceso de procesos. Juntos crean defensa en profundidad. Si quitas uno, tendrás un agujero inesperado.