Servidor WireGuard frente a VPN de malla para dispositivos detrás de CGNAT
Elige una VPN de malla cuando el servidor doméstico y los dispositivos remotos estén detrás de CGNAT y no controles un punto de conexión accesible públicamente; la atravesabilidad de NAT y la infraestructura de retransmisión son precisamente las piezas que faltan. Elige un servidor WireGuard convencional cuando puedas proporcionar un punto de conexión público estable —en casa, mediante IPv6 o en un VPS— y prefieras controlar directamente las claves de los pares, las rutas, las reglas del cortafuegos y la topología del concentrador. CGNAT no hace que WireGuard sea inutilizable, pero cambia la infraestructura que debes proporcionar a su alrededor.
CGNAT elimina la suposición de que el router doméstico tiene una dirección IPv4 pública
Un servidor WireGuard doméstico convencional espera que los pares remotos envíen paquetes a un punto de conexión accesible desde internet. Con NAT normal en el router y una dirección WAN pública, el reenvío de puertos puede dirigir ese punto de conexión al host de WireGuard. Con NAT de nivel de operador, el ISP realiza otra traducción más arriba en la red, por lo que es posible que el router doméstico no controle la asignación pública que necesitan los pares externos.
La RFC 6598 define 100.64.0.0/10 como espacio de direcciones compartido para NAT de nivel de operador. Ver una dirección WAN dentro de ese rango es una señal clara de que existe una traducción en el lado del ISP entre la red doméstica y la internet pública. La consecuencia práctica es que una regla de reenvío de puertos en el router doméstico quizá no cree un punto de conexión IPv4 accesible globalmente.
Este es el primer criterio de decisión. Si el ISP proporciona una dirección IPv4 pública, una ruta IPv6 pública utilizable o un servicio que permita crear la asignación entrante necesaria, un servidor WireGuard autohospedado sigue siendo sencillo. Si no existe ninguna ruta pública, la comparación deja de ser «qué protocolo VPN es mejor» y pasa a ser «quién proporciona la atravesabilidad o la retransmisión».
Un servidor WireGuard gana cuando puedes proporcionar un concentrador accesible
WireGuard convencional es deliberadamente minimalista. Cada par conoce su clave privada, los rangos de IP permitidos y la clave pública y el punto de conexión del par al que debe contactar. Un concentrador en un servidor doméstico es fácil de gestionar cuando tiene una dirección estable y accesible, y los dispositivos remotos pueden iniciar conexiones hacia él.
La documentación de inicio rápido de WireGuard sobre puntos de conexión y keepalives persistentes explica cómo un par detrás de NAT puede mantener activa su asignación enviando tráfico periódicamente. Esto ayuda a que un cliente siga siendo accesible a través de su asignación NAT existente, pero no proporciona a un servidor doméstico detrás de CGNAT un punto de conexión IPv4 público que el abonado no controla.
Por tanto, la opción de un servidor WireGuard encaja en tres diseños habituales de laboratorio doméstico: el ISP proporciona un punto de conexión público; la red doméstica expone el servicio mediante IPv6 utilizable; o un VPS pequeño se convierte en el concentrador WireGuard accesible y la red doméstica inicia un túnel saliente hacia él. En los tres casos, controlas el modelo de enrutamiento y no dependes de un servicio de coordinación de malla para descubrir los pares.
Las VPN de malla ganan cuando la atravesabilidad y el descubrimiento de puntos de conexión son el verdadero problema
Una VPN de malla combina túneles cifrados con coordinación. Los dispositivos se incorporan a la red superpuesta, se descubren entre sí, intercambian información de conexión e intentan atravesar el NAT sin exigir al propietario que escriba manualmente un punto de conexión público para cada red cambiante. Esto es especialmente valioso cuando los portátiles, teléfonos y el servidor doméstico pasan por distintos tipos de NAT que el propietario no controla.
El modelo de conexión actual de Tailscale comienza con una ruta retransmitida, intercambia detalles para una conexión directa, intenta atravesar el NAT y cambia a una conexión UDP directa entre pares cuando es posible. Si la atravesabilidad directa falla, la conexión puede permanecer retransmitida. El valor no reside en una afirmación de cifrado diferente, sino en un sistema automatizado de conectividad alrededor de enlaces basados en WireGuard.
Elige la opción de malla cuando quieras conectar dispositivos detrás de CGNAT independientes, redes Wi-Fi de hoteles, redes móviles o routers domésticos restrictivos sin construir primero un concentrador público. La opción resulta menos atractiva cuando quieres evitar específicamente cualquier dependencia de coordinación externa o cuando el enrutamiento directo y predecible a través de tu propia infraestructura importa más que la comodidad de la incorporación.
La retransmisión de respaldo resuelve la accesibilidad, pero puede convertirse en el límite de rendimiento
Una VPN retransmitida puede seguir conectada funcionalmente cuando falla la atravesabilidad directa entre pares, pero la ruta de datos atraviesa ahora un intermediario. La latencia aumenta según la ubicación y la ruta de la retransmisión, y el rendimiento puede ser inferior al de un túnel directo. Esta diferencia importa más para SMB, copias de seguridad remotas, grandes bibliotecas de fotos o contenido multimedia con una tasa de bits elevada que para SSH y los paneles de control.
La guía de ZeroTier sobre NAT y retransmisión indica que el NAT estricto y CGNAT pueden forzar las conexiones a pasar por servidores de retransmisión, con mayor latencia y un rendimiento limitado en comparación con las rutas directas. Los distintos productos de malla implementan las retransmisiones de forma diferente, pero la compensación arquitectónica es la misma: la comodidad de la atravesabilidad puede trasladar el cuello de botella a la ubicación y la capacidad de la retransmisión.
Esto puede cambiar la elección en un flujo de trabajo intenso de almacenamiento remoto. Una conexión doméstica que no puede aceptar conexiones WireGuard directamente aún puede beneficiarse de un concentrador VPS controlado por el usuario cerca de la vivienda o del usuario, porque crea una retransmisión predecible cuyo tamaño y funcionamiento puedes supervisar. Para un acceso administrativo ligero, el fallback de malla administrado puede ser más sencillo y totalmente adecuado.
Las VPN de malla añaden identidad y políticas que WireGuard puro deja en tus manos
El modelo de pares de WireGuard se centra en la criptografía y las rutas. Si quieres inicio de sesión de usuarios, incorporación de dispositivos, grupos con nombre, políticas de acceso centralizadas, flujos de rotación de claves o un inventario de dispositivos consultable, debes crear esas funciones alrededor del protocolo. Una plataforma de malla normalmente proporciona parte o la totalidad de ese plano de control.
La arquitectura de NetBird describe una plataforma que combina túneles WireGuard con atravesabilidad de NAT, autenticación, ACL y gestión de red. Esto demuestra el eje real de la comparación: una VPN de malla no es simplemente «WireGuard con una interfaz diferente»; añade servicios de coordinación y políticas que WireGuard puro no define intencionadamente.
Para un administrador y tres dispositivos estables, configurar manualmente los pares de WireGuard puede ser más sencillo que operar o confiar en un plano de control más amplio. Para una familia con teléfonos cambiantes, varios portátiles, routers de subred y acceso basado en roles, la incorporación a la malla y las políticas centralizadas pueden reducir la cantidad de archivos de pares y excepciones del cortafuegos que el propietario debe mantener manualmente.
Autohospedar el plano de control de la malla cambia la dependencia del proveedor por la propiedad de la infraestructura
La elección no se limita a un proveedor de malla alojada frente a WireGuard puro. Un plano de control autohospedado puede conservar el modelo de conexión de malla y, al mismo tiempo, poner la coordinación bajo tu administración. Esto reduce la dependencia del proveedor, pero añade un servicio público, una base de datos o estado persistente, copias de seguridad, actualizaciones, certificados y trabajo de recuperación.
Headscale se describe como una implementación autohospedada del servidor de control de Tailscale. Su documentación también admite opciones DERP autohospedadas, lo que muestra claramente la compensación de propiedad: puedes controlar una mayor parte de la coordinación y de la ruta de retransmisión, pero entonces debes mantener esa ruta accesible y recuperable.
No elijas una malla autohospedada únicamente porque el término «autohospedada» encaje con el resto del laboratorio. Úsala cuando la propiedad del plano de control, el almacenamiento de políticas, la independencia del proveedor o la ubicación personalizada de las retransmisiones sean lo bastante importantes como para justificar otro servicio expuesto a internet. De lo contrario, una malla alojada puede eliminar precisamente el problema de disponibilidad que CGNAT hizo difícil en primer lugar.
Elige según la accesibilidad, la ruta de datos y la propiedad del plano de control
Elige un servidor WireGuard cuando exista un punto de conexión público fiable y quieras un diseño transparente de concentrador y radios con claves y rutas explícitas. Es la opción más sólida para un número reducido de pares estables, propietarios cómodos con el trabajo de cortafuegos y DNS, o un diseño asistido por VPS en el que controles la ubicación y la capacidad de la retransmisión.
Elige una VPN de malla cuando los dispositivos estén detrás de CGNAT o de NAT cambiantes, necesites una incorporación sencilla y valga la pena añadir una capa de coordinación para obtener el descubrimiento automático de rutas o la retransmisión de respaldo. Para acceder intensivamente a archivos, comprueba si la sesión es directa o retransmitida, porque la respuesta puede cambiar el rendimiento lo suficiente como para ser relevante.
La comparación de ZimaSpace sobre proxy inverso, WireGuard y Tailscale para servicios familiares remotos cubre la elección más amplia del acceso remoto. Dentro de la rama de las VPN privadas, la regla de decisión aquí es más concreta: si puedes proporcionar el punto de conexión accesible y prefieres control manual, WireGuard es suficiente; si la accesibilidad es el problema recurrente, una VPN de malla justifica su plano de control adicional.
Productos recomendados
Comparaciones de productos
Más para leer
Docker vs. máquina virtual para Plex: ¿qué opción de implementación se adapta mejor?
Un veredicto condicional sobre la implementación de Plex en Docker, máquinas virtuales o Docker dentro de una máquina virtual, basado en requisitos operativos compartidos.
RAM de 8 GB frente a 16 GB frente a 32 GB para Plex: ¿qué nivel se adapta mejor a tu carga de trabajo?
Elige 8 GB para Plex con un uso ajustado de recursos, 16 GB para aplicaciones compartidas de uso moderado o 32 GB para máquinas...
¿La aceleración de hardware dedicada ofrece a Plex una ventaja significativa?
La aceleración por hardware es superior para transcodificaciones repetidas compatibles; el uso exclusivo de la CPU sigue siendo válido para la reproducción directa, las...
