Configuración segura de la VPN WireGuard para administradores de servidores

Red de mantenimiento en lugar de puertos de administración abiertos al público

Los puertos de administración accesibles públicamente aumentan la superficie de ataque de un servidor: los intentos de inicio de sesión por SSH, las configuraciones erróneas de las interfaces de administración y los servicios de monitorización expuestos accidentalmente son accesibles directamente desde redes externas. El acceso mediante WireGuard reduce esta visibilidad, ya que, en un primer momento, solo es necesario que un puerto UDP definido siga siendo accesible para el túnel cifrado. Sin embargo, WireGuard no camufla el tráfico como HTTPS y no ofrece un modo de transporte TCP.

El modelo ideal para la administración de una VPN suele ser una red de tipo «hub and spoke»: el servidor gestiona la interfaz wg0 y recibe, por ejemplo, la dirección interna 10.77.0.1. El ordenador portátil de una persona autorizada se conecta como un nodo independiente y utiliza, por ejemplo, la dirección 10.77.0.10. SSH, una consola web interna o los puntos finales de monitorización aceptan entonces los accesos a través de la red de túnel en lugar de a través de la dirección pública del servidor.

No se trata de una VPN para usuarios finales destinada a redirigir todo el tráfico web de un dispositivo. Para tareas de mantenimiento, resulta más adecuado un modelo de acceso restringido: el túnel solo sirve como vía de acceso a destinos de administración claramente definidos. Aunque se puede utilizar deliberadamente un túnel completo, este modifica además el enrutamiento, el uso del DNS y la accesibilidad a servicios externos. Estos efectos secundarios no suelen ser necesarios para un acceso destinado exclusivamente al mantenimiento.

El Red de mantenimiento Es únicamente un límite de red. No determina qué cuenta de Linux puede iniciar sesión, qué comandos puede ejecutar dicha cuenta ni si el sistema operativo está actualizado. Además, necesitas claves SSH y cuentas personales, derechos de «sudo» debidamente limitados, reglas de cortafuegos, actualizaciones de seguridad, registro de actividades y un acceso de emergencia bien gestionado. De este modo, un fallo en una única capa de protección no será el único factor que determine el acceso.

Clasificar correctamente las claves, los pares y las direcciones IP permitidas

Cada par de WireGuard dispone de su propio par de claves. La clave privada permanece exclusivamente en el servidor, el ordenador portátil o el dispositivo de gestión correspondiente; en el extremo opuesto solo se almacena la clave pública derivada de ella. Una clave precompartida opcional complementa la criptografía de clave pública con material de clave simétrica adicional. Se trata de una capa adicional, pero no sustituye ni a las claves privadas ni a una gestión de claves trazable.

Coloca un Peer por dispositivo , no un nodo común para un equipo. De este modo, es posible eliminar de forma selectiva una estación de trabajo perdida o un dispositivo de un proveedor de servicios que ya no sea necesario. Las claves de WireGuard permiten el acceso a la red de mantenimiento. Por su parte, las claves SSH autentican a una persona o un dispositivo ante el servicio SSH; por lo tanto, la retirada debe planificarse en ambos niveles.

Son especialmente importantes los Direcciones IP permitidas en el servidor. En WireGuard, forman una tabla de enrutamiento de claves criptográficas: para los paquetes salientes, determinan el par adecuado en función de la dirección de destino. En el caso de los paquetes entrantes ya autenticados, limitan al mismo tiempo las direcciones de origen internas que puede utilizar ese par. Por lo tanto, esta configuración es más que una simple especificación de ruta.

Si al ordenador portátil de administración se le asigna la dirección 10.77.0.10, en el servidor debe figurar, para ese mismo par, AllowedIPs = 10.77.0.10/32. La asignación /32 vincula una única dirección de túnel a este par. Si asignaras de forma general 10.77.0.0/24 a cada par de administración, esta asignación se volvería confusa y la configuración sería innecesariamente amplia. Comprueba además que la red VPN elegida no entre en conflicto con las redes de las sedes, de contenedores ni domésticas.

Planificar los límites de la red y el modelo de acceso

Planifica la red de direcciones VPN antes de la instalación. Elige un rango privado que no se solape ni con las LAN existentes, ni con redes en la nube, ni con redes de Docker o Kubernetes, ni con redes domésticas de uso habitual. Determina a qué sistemas debe poder accederse a través del túnel: solo al servidor de puerta de enlace, a una red de administración delimitada o a servicios concretos. De ello se derivarán posteriormente las rutas de los clientes, las reglas del cortafuegos y, en su caso, las rutas de retorno.

Documenta para cada dispositivo el usuario responsable, la clave pública de WireGuard, la IP fija del túnel, la finalidad del acceso y el procedimiento de revocación. Los grupos deben orientarse en función de las tareas, como el funcionamiento, la gestión de bases de datos o el soporte externo, y no basarse en un enfoque general del tipo „la VPN lo permite todo“. Además, mantén un acceso de emergencia independiente, por ejemplo, una consola del proveedor. Compruébalo antes de realizar cambios en el cortafuegos, SSH o el enrutamiento, para que una regla errónea no provoque un bloqueo.

El Cortafuegos es el límite de red principal: permite el puerto UDP de WireGuard en la interfaz pública, pero solo admite conexiones SSH a través de la interfaz de entrada wg0 o la interfaz de WireGuard realmente utilizada. Una comprobación adicional de la red de origen de la VPN puede restringir aún más la regla, pero no debe sustituir a la vinculación de la interfaz. De este modo, el cortafuegos no acepta paquetes que lleguen a la interfaz pública únicamente por el hecho de que se afirme que la dirección de origen corresponde a una VPN. WireGuard asocia direcciones internas autenticadas a los pares; esta garantía se aplica a los paquetes aceptados a través de la interfaz del túnel.

A nivel de SSH, se añaden claves en lugar del inicio de sesión con contraseña, cuentas personales y reglas de «sudo» lo más limitadas posible. OpenSSH puede configurarse con AllowUsers Vincular cuentas adicionalmente a direcciones de origen o redes CIDR. Esta segunda barrera complementa la establecida en wg0 regla de firewall asociada, pero no la sustituye.

Las aplicaciones web públicas siguen necesitando su propio sistema de seguridad de transmisión a través de HTTPS y los certificados correspondientes. Guía para proteger un sitio web mediante TLS Este nivel se encarga del acceso a través del navegador. Por su parte, WireGuard protege el acceso a la red privada de administración; no sustituye ni a TLS para los servicios públicos ni a sus procesos de inicio de sesión, verificación de permisos y mantenimiento.

Estructura básica con wg-quick sin trampas de enrutamiento

Para un único servidor de mantenimiento basta con una configuración punto a punto: el servidor ejecuta wg0 con la dirección del túnel 10.77.0.1/24, el portátil de administración recibe de forma permanente 10.77.0.10/32. El servidor público solo acepta UDP para WireGuard. Los siguientes archivos son una propuesta de configuración para wg-quick; deliberadamente, no contienen claves reales.

En el servidor, un nodo asocia la clave pública del portátil con su dirección de túnel concreta. La clave privada del servidor permanece exclusivamente en el archivo local. Guarda la configuración, por ejemplo, en /etc/wireguard/wg0.conf y limita el acceso de lectura al contexto de administración, ya que en él se encuentra una clave secreta. Las claves públicas, por el contrario, están destinadas al destinatario correspondiente.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

En el portátil se indica Endpoint a la dirección pública del servidor y al puerto UDP seleccionado. Para el mantenimiento puro del servidor, como cliente se utiliza Direcciones IP permitidas por lo general, solo 10.77.0.1/32 es necesario. De este modo, solo el tráfico dirigido a la dirección VPN del servidor se canaliza a través del túnel; el tráfico de Internet del ordenador portátil sigue su ruta habitual.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

La indicación 0.0.0.0/0 En cambio, en el cliente, una ruta predeterminada IPv4 a través del túnel significa: una Túnel completo. wg-quick Deriva las rutas a partir de las direcciones IP permitidas (AllowedIPs) y gestiona las rutas por defecto con una lógica adicional de enrutamiento basado en políticas. Esto es posible en el caso de un acceso planificado expresamente de este modo, pero, entre otras cosas, modifica el tráfico externo y puede poner de manifiesto problemas de DNS o de accesibilidad.

El ejemplo se refiere exclusivamente a IPv4. Si el servidor dispone de conectividad IPv6 pública, el puerto TCP 22 también debe bloquearse expresamente en ese caso mediante el cortafuegos IPv6, o bien el servicio SSH debe vincularse adecuadamente. Una autorización IPv4 cerrada no protege contra un listener IPv6 que siga siendo accesible públicamente. Planifica por separado las direcciones de túnel IPv6 y los prefijos del lado del cliente; ::/0 sería, en este caso, una ruta por defecto para IPv6 y no un complemento neutral de la configuración de IPv4.

En primer lugar, activa el túnel, comprueba la conexión con la dirección VPN e inicia sesión a través de ella mediante SSH en una segunda sesión. Solo cuando esta vía funcione de forma fiable y se disponga de un acceso independiente a la consola o de emergencia, deberías eliminar el acceso público por SSH. Comprueba tanto la IPv4 como, si procede, la IPv6. Las claves privadas no deben figurar ni en los tickets, ni en los historiales de chat, ni en el control de versiones.

Comparar modelos de enrutamiento y reglas de cortafuegos

El cortafuegos aplica el modelo de acceso deseado. En la interfaz pública, puede aceptar el puerto UDP de WireGuard especificado; sin embargo, el puerto TCP 22 no debe permanecer abierto allí como acceso de administración general. En su lugar, el acceso SSH solo se permite para los paquetes cuya interfaz de entrada sea wg0 o la interfaz WireGuard utilizada. Una comprobación adicional de la red de origen puede limitar aún más el ámbito de la VPN permitido; sin embargo, una regla basada exclusivamente en la dirección de origen no es suficiente.

La vinculación a la interfaz de entrada impide que un paquete que llega a la interfaz pública cumpla los requisitos de autorización SSH únicamente por tener una dirección de origen falsificada procedente del ámbito de la VPN. La asignación criptográfica de WireGuard entre el par y la dirección interna se aplica a los paquetes autenticados en la interfaz del túnel. La sintaxis concreta del cortafuegos debe ajustarse al software utilizado y tener en cuenta de forma inequívoca tanto la interfaz como la familia de direcciones.

Ten muy en cuenta la conectividad IPv6 pública. Si solo se elimina la apertura de IPv4 para el puerto TCP 22, el servicio SSH seguirá siendo accesible desde Internet a través de IPv6. Por lo tanto, bloquea también el puerto en las reglas de IPv6 o configura el servicio SSH de manera que no escuche en una dirección IPv6 pública. Las reglas de IPv4 e IPv6 deben revisarse por separado.

En el caso de un cortafuegos con estado, no basta con considerar únicamente el trayecto de ida deseado. Los paquetes de respuesta de una conexión permitida también deben llegar al cliente; en el caso de los accesos detrás de una pasarela, hay que añadir además el trayecto de vuelta desde la red de destino. Una autorización general de toda la subred VPN para todos los servicios convierte innecesariamente la red de mantenimiento en una amplia red de acceso interna.

Para el mantenimiento de un único servidor, el primer modelo es el más claro. La ruta del cliente hacia 10.77.0.1/32 Es suficiente, y el cortafuegos puede aceptar SSH únicamente para los paquetes que llegan a través de la interfaz WireGuard. Aunque el puerto UDP sigue siendo visible desde el exterior, sin la clave de par correspondiente no se produce ningún acceso administrativo.

El segundo modelo exige una separación clara: en este caso, el servidor VPN no es solo un punto final, sino también un router. El cortafuegos debería permitir, por ejemplo, el acceso SSH a servidores de administración definidos y el acceso HTTPS a una consola interna, limitados en cada caso a la interfaz de entrada de WireGuard, a redes de destino concretas y a puertos específicos. No debes habilitar los puertos de la base de datos en toda la VPN solo porque los usuarios ya estén conectados.

En un «Full Tunnel», el servidor VPN también actúa como puerta de enlace para destinos de Internet. Para ello, debe reenviar paquetes IPv4 entre wg0 y reenviarlas a su enlace ascendente; además, las respuestas necesitan una ruta de retorno a la red VPN. En muchas configuraciones de servidor se utiliza para ello una regla específica de NAT de origen en el enlace ascendente, cuando la red de origen no conoce ninguna ruta hacia el prefijo VPN. Planifica estas reglas de forma consciente y limítalas a la red de túnel prevista.

Un «Full Tunnel» no es un requisito de seguridad de WireGuard, sino una decisión de enrutamiento que se toma en el cliente. Porque wg-quick Dado que las rutas predeterminadas de «AllowedIPs» se procesan de forma especial, esta configuración solo debe utilizarse si se cuenta con una resolución de nombres planificada, una capacidad de puerta de enlace suficiente y reglas de salida adecuadas. Para el uso habitual Administración de VPN suele ser más amplia de lo necesario. En el caso de IPv6, esta misma cuestión de planificación se aborda por separado: ::/0 dirige todo el tráfico IPv6 a través del túnel.

Facilitar el acceso específico a las redes internas

Si los administradores necesitan acceder a otros sistemas privados situados detrás de la pasarela VPN, la tarea pasa de ser un mero acceso al servidor a convertirse en una red de administración enrutada. Planifica primero las redes y los servicios de destino: por ejemplo, SSH a servidores del segmento de administración y HTTPS a una consola interna. Cada ruta adicional amplía el ámbito de confianza y, por lo tanto, debe estar justificada por una tarea operativa concreta.

El primer requisito técnico es que la pasarela pueda reenviar paquetes IPv4. La configuración del núcleo net.ipv4.ip_forward activa este comportamiento. No debe considerarse una simple línea de código sin consecuencias: según la documentación del núcleo, un cambio en ip_forward El resto de parámetros de configuración de IPv4 volverán a sus valores predeterminados del host o del router. Por lo tanto, comprueba las especificaciones de red y seguridad vigentes antes y después del cambio.

En segundo lugar, el cortafuegos necesita una configuración explícita Normas de tránsito en ambas direcciones. Una norma no debería limitarse simplemente a todo el tráfico de wg0 Aceptarlas en la LAN. En su lugar, limítalas a la red de origen de la VPN, a las direcciones de destino previstas y a los protocolos necesarios, por ejemplo, TCP 22 hacia los servidores de administración y TCP 443 hacia una consola. Las bases de datos quedan excluidas de esta autorización, salvo que exista una excepción justificada.

En tercer lugar, la red de destino necesita una ruta de retorno hacia la red VPN, por ejemplo, una ruta para 10.77.0.0/24 a través de la dirección interna de la pasarela. Sin esta ruta de retorno, el trayecto de ida puede funcionar, pero las respuestas no llegan al administrador. Si el enrutamiento no es posible en la red de destino, el NAT de origen en la pasarela puede ser una alternativa técnica; sin embargo, oculta la dirección original del cliente VPN y, por lo tanto, dificulta el registro en el lado de destino y la aplicación de reglas más precisas.

Elige la red de direcciones VPN de manera que no entre en conflicto ni con las redes locales de los administradores ni con las redes existentes de las sedes, en la nube o de contenedores. Los solapamientos hacen que la selección de rutas resulte ambigua y generan errores que pueden parecer un problema de WireGuard o del cortafuegos. Además, documenta las direcciones fijas de los túneles y los dispositivos asociados antes de habilitar más pares o redes de destino.

Gestionar de forma segura el funcionamiento y los cambios

Una red de mantenimiento solo puede mantenerse bajo control si cada dispositivo cuenta con su propio par, su propio par de claves y una dirección IP de túnel fija. Por lo tanto, un inventario debería incluir, como mínimo, la dirección del túnel, la denominación del dispositivo, la persona responsable, la finalidad, la fecha de emisión y la fecha de revisión. La asignación de 10.77.0.10/32 a un ordenador portátil de administración concreto permite rastrear los accesos y evita que varios dispositivos utilicen la misma identidad de VPN.

Planifica el cambio de claves como un proceso operativo habitual, no solo como reacción ante un incidente. Para sustituir un dispositivo, crea un nuevo par con una nueva dirección o una dirección sucesora claramente documentada, comprueba el acceso y, a continuación, elimina el par antiguo. Las claves privadas de WireGuard deben encontrarse exclusivamente en el dispositivo correspondiente; ni los tickets ni los inventarios centrales deben contenerlas.

En caso de pérdida de un ordenador portátil o de que una persona externa deje la empresa, debes eliminar el nodo correspondiente de la configuración del servidor. De este modo, se bloquea su acceso a la red de administración sin necesidad de cambiar las claves de los demás administradores. Retirada por parte de los compañeros pero no es lo mismo que revocar una clave SSH: la clave de WireGuard controla la ruta de red, mientras que la clave SSH controla el inicio de sesión en la cuenta de destino.

Tras eliminar un nodo, WireGuard no puede intercambiar más paquetes a través de ese nodo en una conexión SSH existente; por lo tanto, la conexión se bloquea o finaliza tras una interrupción o un tiempo de espera. Sin embargo, la eliminación no revoca automáticamente el inicio de sesión SSH ya realizado a nivel de aplicación ni finaliza los procesos iniciados previamente. Por lo tanto, en caso de incidente, comprueba además las autorizaciones SSH, los procesos en ejecución, las cuentas y, si procede, los permisos de sudo.

Para realizar modificaciones específicas, se puede wg syncconf comparar una configuración existente de WireGuard con las diferencias explícitas; según el manual, esto debería afectar menos a las sesiones entre pares que setconf. No obstante, no sustituye a la autorización, la revisión por dos personas ni las ventanas de mantenimiento. Antes de cada cambio, asegúrate de que la configuración funciona correctamente y anota cómo restaurarla.

Diagnóstico: desde el protocolo de enlace hasta el acceso SSH

En caso de fallo, separa sistemáticamente el transporte, el enrutamiento y la aplicación. Empieza por el puerto UDP accesible desde la red pública y el protocolo de establecimiento de conexión antes de modificar la configuración de SSH. El comando wg show Muestra, entre otros datos, las direcciones IP permitidas (AllowedIPs), la hora del último handshake y el contador de transferencias para los pares configurados. Los valores que faltan o que no han cambiado indican que existe un problema previo al acceso SSH propiamente dicho.

Si se establece un handshake, comprueba en el cliente y en el servidor la dirección del túnel realmente configurada y la ruta hacia el destino. Para la mera gestión de la pasarela, el cliente debe poder acceder al destino 10.77.0.1 a través de la interfaz de WireGuard. En el caso de destinos internos, hay que tener en cuenta los contadores del cortafuegos, el tráfico de retorno permitido y la ruta de retorno de la red de destino; un establecimiento de conexión satisfactorio no garantiza que se cumplan estos requisitos.

Solo cuando la ruta de red sea correcta, se procederá a comprobar el servicio SSH. Comprueba las entradas relevantes para el inicio de sesión y la restricción de origen en el archivo sshd_config, en particular los recursos compartidos de los usuarios, como AllowUsers, y comprueba el estado de los servicios y los registros con las herramientas de tu distribución. A continuación, revisa la cuenta de usuario y las entradas en authorized_keys y las reglas de sudo por separado. La documentación de configuración por sí sola no garantiza ni que el inicio de sesión se haya realizado correctamente ni que se pueda acceder al servicio.

Las direcciones IP permitidas (AllowedIPs) idénticas o que se solapan no son un simple error de documentación. Al enviar datos, WireGuard asigna las direcciones de destino a un par basándose en estos prefijos; al recibir datos, estos prefijos limitan las direcciones de origen internas del par autenticado. Por lo tanto, los prefijos de host duplicados o contradictorios no constituyen una identificación única y fiable que permita su trazabilidad. Asignación entre pares. No se debe dar por sentado qué resultado concreto generará una herramienta de gestión al aplicar una configuración de este tipo. En su lugar, evita la colisión ya en el inventario y durante la comprobación de la configuración.

Aplica las correcciones de forma controlada y realiza los diagnósticos únicamente con acceso de emergencia disponible. De este modo, un cambio erróneo en los pares, el enrutamiento o el cortafuegos no bloqueará al mismo tiempo la vía de retorno para la reparación. Después de cada aplicación, comprueba de nuevo el handshake, el contador de transferencias, la ruta y el acceso al servicio de administración específicamente habilitado.

wg show
ip route

La elección de la herramienta y los límites de seguridad son decisivos

La elección del método de administración depende de la configuración actual de la gestión del servidor, y no de un método supuestamente universal de WireGuard. wg-quick Es adecuado para configuraciones sencillas: el script auxiliar configura la interfaz, las direcciones y las rutas derivadas de AllowedIPs. En cambio, para redes complejas, la documentación remite a herramientas más específicas o a la configuración directa mediante wg y herramientas de propiedad intelectual.

Si un host ya gestiona su red de forma declarativa mediante systemd-networkd, los archivos .netdev y .network son una alternativa adecuada. systemd-networkd admite configuraciones específicas de WireGuard y puede obtener claves privadas a partir de credenciales; para el contenido confidencial, la documentación recomienda el uso de credenciales cifradas o, como mínimo, permisos de archivo restrictivos como medida de protección. Esto resulta especialmente adecuado para servidores desplegados de forma automatizada.

Accesos directos desde wg y ip Ofrecen el mayor control para la automatización, el enrutamiento basado en políticas y los procesos específicos del cortafuegos, pero requieren un modelo operativo bien definido. Nunca administres la misma interfaz simultáneamente mediante wg-quick, systemd-networkd y scripts propios. La coexistencia de varias entidades responsables puede provocar que las rutas, las direcciones o la configuración de los pares se sobrescriban entre sí, lo que dificulta una reversión fiable.

PersistentKeepalive solo resulta útil para los pares que, al estar detrás de un NAT o de un cortafuegos con seguimiento de estado, rara vez envían datos por sí mismos y, sin embargo, deben seguir siendo accesibles para el tráfico entrante. Si no se especifica nada, está desactivado; la documentación menciona los 25 segundos únicamente como un intervalo posible, no como un valor predeterminado general. Los clientes móviles suelen beneficiarse del roaming, ya que WireGuard puede actualizar el punto final basándose en paquetes autenticados correctamente.

El roaming y la restricción fija de los puntos finales suponen un equilibrio: un cortafuegos que solo acepte UDP procedente de redes de origen conocidas puede limitar la superficie de ataque, pero impide un uso flexible cuando se está fuera de la oficina. WireGuard señala además que un atacante activo puede redirigir la dirección de origen externa y, de este modo, facilitar un ataque de denegación de servicio sin necesidad de leer ni modificar el contenido cifrado.

Un túnel WireGuard no sustituye a la gestión de identidades, la verificación de permisos, las actualizaciones, las copias de seguridad ni el registro de actividades. No disfraza su tráfico como HTTPS y no ofrece modo TCP. Por lo tanto, las aplicaciones web públicas siguen necesitando una protección TLS independiente; en este artículo se explican los requisitos y la implementación. Configurar HTTPS de forma segura. Separa claramente esta capa de protección del acceso a la VPN para la administración.