Acceso remoto resiliente mediante WireGuard y VPS
Implementación de una ruta de acceso remoto mediante WireGuard y un VPS para reducir la dependencia de una IP pública específica y del proveedor de Internet utilizado por la oficina.
- WireGuard
- Linux
- Ubuntu Server
- VPS
- Windows Server 2016
- RDP
- Networking
- Nginx
El caso en perspectiva
Problema
No todos los enlaces permitían publicar servicios de la misma forma: Izzi, por ejemplo, operaba bajo CGNAT. Disponer de varios proveedores no eliminaba la dependencia de la ruta de acceso asociada a una IP pública específica. El objetivo era desacoplar el acceso remoto del ISP de la oficina, de modo que pudiera conservarse una vía de acceso mientras el Windows Server tuviera alguna salida funcional a Internet.
Solución
Se implementó una red WireGuard con un VPS público como punto intermedio y Windows Server 2016 como peer, para permitir el acceso remoto desde distintas redes externas sin depender de un ISP específico de la oficina. El acceso RDP utilizaba la dirección privada VPN 10.0.0.10 del servidor. Para Alpha ERP se configuró una ruta con dominio alternativo mediante Nginx en el mismo VPS, que actuaba como proxy hacia el servicio accesible a través de esa dirección VPN.
Resultado
Se habilitó una ruta alternativa de acceso remoto mediante la red WireGuard, reduciendo la dependencia de una IP pública específica del enlace de Internet de la oficina. Mientras el Windows Server y el VPS conservaran conectividad a Internet, la red VPN podía mantener una vía de acceso independiente del ISP utilizado por la oficina.
Contexto
La organización contaba con varios proveedores de Internet y un Windows Server 2016 que alojaba servicios utilizados remotamente. El acceso remoto existente, incluido RDP, dependía de una ruta asociada a una IP pública, principalmente mediante el enlace de Telmex. Alpha ERP también dependía de una ruta que podía verse afectada cuando fallaba la conectividad principal.
Restricciones
- No todos los enlaces permitían publicar servicios de la misma forma; Izzi operaba bajo CGNAT.
- La solución debía integrarse con la infraestructura existente.
- Los servicios remotos continuaban alojados en Windows Server 2016, que debía conservar conectividad a Internet mediante alguno de los enlaces disponibles.
- El costo de implementación debía mantenerse bajo.
Arquitectura
Usuario remoto
PC / laptop
Cliente WireGuard con configuración local. El usuario activa el túnel cuando necesita acceso.
VPS · Ciudad de México
Ubuntu Server / Linux
Endpoint público de WireGuard y punto de interconexión.
Nginx se ejecuta en este mismo VPS.
Infraestructura de la oficina
Windows Server 2016
Peer WireGuard instalado directamente. Aloja los servicios internos utilizados remotamente.
Dirección privada VPN10.0.0.10IP PRIVADA / VPN
Servicios: RDP / Alpha ERP
Windows Server inicia conectividad hacia el endpoint público mediante una salida a Internet disponible en la infraestructura de la oficina.
Acceso remoto · RDP
Usuario activa WireGuard → VPS → red WireGuard → Windows Server / 10.0.0.10 → RDP.
Ruta de aplicación · Alpha ERP
Ruta alternativa → Nginx en el VPS → red WireGuard → Windows Server / 10.0.0.10 → Alpha ERP.
Por qué funciona en este entorno
El Windows Server podía establecer conectividad saliente hacia el VPS público como peer WireGuard, sin necesitar una conexión entrante mediante una IP pública del ISP. Los usuarios se conectaban al mismo entorno VPN y alcanzaban al servidor por su dirección privada estable.
La oficina disponía de varios ISP y no todos permitían publicar servicios de la misma forma; Izzi operaba bajo CGNAT. La VPN no seleccionaba el proveedor: necesitaba una salida funcional a Internet del servidor y conectividad del VPS.
Las decisiones principales fueron utilizar un VPS público como punto de interconexión y configurar Windows Server 2016 como peer WireGuard con la dirección privada VPN 10.0.0.10. Nginx, en el mismo VPS, proporcionaba una ruta alternativa para Alpha ERP hacia el servicio del servidor a través de la VPN. El VPS se migró a Ciudad de México para reducir latencia.
Trabajo implementado
Implementación
- Preparación de un VPS Linux con Ubuntu Server.
- Configuración de WireGuard en el VPS como endpoint público de la VPN.
- Instalación y configuración de WireGuard directamente en Windows Server 2016 como peer.
- Asignación de la dirección privada estable 10.0.0.10 al Windows Server dentro de la red WireGuard.
- Configuración de clientes WireGuard en los equipos remotos, con el túnel guardado localmente y activación o desactivación por parte del usuario.
- Pruebas de conectividad desde una red externa hacia la dirección VPN del Windows Server y comprobación del acceso remoto por la nueva ruta.
- Configuración de Nginx en el mismo VPS como proxy para una ruta con dominio alternativo de Alpha ERP hacia el servicio accesible mediante 10.0.0.10.
- Migración del VPS a una ubicación en Ciudad de México para disminuir latencia.
Pruebas documentadas
Validación
- Desde una red externa se activó el túnel WireGuard del equipo remoto.
- Se comprobó la conectividad hacia 10.0.0.10, la dirección privada del Windows Server dentro de la VPN.
- Se verificó que el acceso remoto al Windows Server funcionara por la nueva ruta.
- La prueba buscaba comprobar que el acceso no dependiera de una única IP pública de la oficina ni de una única red externa.
Limitaciones
- El acceso depende de la disponibilidad y conectividad a Internet del VPS.
- El Windows Server debe conservar una salida funcional a Internet.
- Los servicios remotos dependen de la disponibilidad del propio Windows Server.
- El paso por el VPS introduce un salto adicional y un coste de latencia respecto a una conexión directa.
- La configuración de la VPN debe mantenerse correctamente.
¿Necesitas resolver un problema similar?
Podemos comenzar por entender el contexto, las restricciones y las alternativas disponibles.