Conectar sedes: ¿VPN, Tailscale, NetBird o Cloudflare Mesh?

Trabajo mucho en la interconexión de redes empresariales. Las mismas preguntas aparecen con frecuencia: ¿cuál es la mejor solución para conectar nuestras sedes? ¿Necesitamos direcciones IP públicas? ¿Es segura? ¿Y seguirá sirviendo si añadimos una delegación, cambiamos de conexión a Internet o incorporamos empleados?

Mi respuesta depende de las necesidades reales de la empresa. Dos sedes fijas con cortafuegos existentes parten de condiciones distintas a varias oficinas pequeñas con conexiones cambiantes. También hay cuestiones más allá del túnel: quién lo administra, dónde se controla el acceso y qué dependencias está dispuesta a mantener la empresa.

Por eso prefiero entender la arquitectura antes de elegir un producto. Una VPN tradicional entre sedes puede encajar perfectamente. Tailscale o NetBird pueden simplificar la gestión y el establecimiento de conexiones. Cloudflare Mesh traslada el recorrido de los datos a la red del proveedor. Estas diferencias determinan dónde tiene sentido cada enfoque.

Aquí hablamos de conectar redes completas de distintas sedes. El acceso individual de empleados desde casa aparece después como uso complementario de acceso remoto.

Nuestro ejemplo: Tres redes de sedes conectadas

La central utiliza 10.1.0.0/24, la delegación 10.2.0.0/24 y el laboratorio doméstico 10.3.0.0/24. Cada sede dispone de una pasarela que permite alcanzar las redes remotas. Las impresoras y los NAS que quedan detrás no necesitan clientes VPN propios. Todos los modelos buscan lo mismo: conectividad controlada entre estas tres redes.

Se crea una red enrutada de capa 3. Las sedes no comparten automáticamente un dominio de difusión ni funcionan entre ellas todos los protocolos de descubrimiento local. El DNS debe resolver correctamente los nombres internos y los routers locales necesitan rutas hacia las redes remotas.

Primero quiero saber qué red necesita qué servicios. La delegación puede necesitar el servidor de archivos sin acceso a la administración del laboratorio. El servidor de copias necesita su destino, pero no todos los equipos de la otra sede. Estas decisiones siguen siendo necesarias con cualquier solución.

Site-to-site describe la conexión, no la topología

Site-to-site significa red a red. No obliga a que todo el tráfico atraviese un cortafuegos central. La estrella con la central como concentrador es habitual; los túneles directos entre parejas de sedes también proporcionan conectividad site-to-site. Las pasarelas de Tailscale, NetBird o Cloudflare Mesh pueden cumplir esa misma función.

Tailscale y NetBird buscan caminos directos para los datos aunque el registro y la coordinación se gestionen de forma centralizada. La red de Cloudflare está distribuida geográficamente, pero el tráfico entre sedes sigue atravesándola. No es una conexión directa entre pares. La red del proveedor sustituye al cortafuegos central como punto de tránsito.

IP públicas y requisitos que cambian

La pregunta por la IP pública suele surgir pronto. Distingo entre que una conexión sea accesible desde fuera y que su dirección permanezca estable. Una IP pública fija facilita planificar un extremo VPN accesible. No es necesaria en todas las sedes: una delegación puede iniciar un túnel saliente hacia una pasarela central accesible. Según el diseño, el DNS dinámico también puede ayudar con direcciones cambiantes.

Se complica cuando ambos extremos están detrás de un NAT de operador restrictivo sin un extremo directamente accesible. Especialmente con Internet móvil, conviene comprobar qué direcciones y conexiones entrantes ofrece realmente el operador. Tailscale y NetBird intentan establecer conexiones directas atravesando NAT y recurren a relés cuando hace falta. Cloudflare Mesh establece conexiones salientes a la red del proveedor.

También quiero que el siguiente cambio resulte manejable. Otra sede, un cambio de operador o una conexión sin accesibilidad entrante pueden transformar una configuración sencilla en otra tarea. No hace falta sustituir preventivamente algo que funciona, pero sí considerar estas posibilidades antes de decidir la topología.

VPN tradicional entre sedes: Se encargan las pasarelas

Dos cortafuegos o routers establecen un túnel cifrado, normalmente con IPsec o WireGuard configurado manualmente. El enrutamiento local envía el tráfico destinado a la red remota al túnel. La otra pasarela lo descifra y lo reenvía a la red de destino.

Con tres sedes, la central puede actuar como concentrador. La delegación y el laboratorio se conectan a ella. Simplifica la estructura, pero sus intercambios pasan por la central. Una malla completa conecta directamente cada pareja. Para n sedes hacen falta n × (n − 1) / 2 conexiones: tres con tres sedes y ya 45 con diez. Los controladores y mecanismos dinámicos reducen el trabajo; las VPN clásicas no se limitan a estrellas configuradas a mano.

Ventajas: encaja con los cortafuegos existentes y límites claros entre sedes. Controlamos los extremos del túnel. No hay otro proveedor de malla en el recorrido de los datos; reglas, rutas y registros se integran en la administración existente.

Inconvenientes: el trabajo de rutas, claves y operación crece con las sedes. NAT, direcciones cambiantes y fabricantes diferentes dificultan el diagnóstico. Los usuarios móviles suelen requerir una configuración de acceso remoto aparte.

Una IP pública fija en cada sede no es un requisito universal. A menudo basta un concentrador accesible y túneles salientes desde las delegaciones. El DNS dinámico y la travesía de NAT también ayudan. Si ambos extremos tienen CGNAT restrictivo, una conexión directa resulta más difícil sin un extremo accesible o intermediario.

Para dos sedes estables con cortafuegos adecuados sigue siendo una opción sensata. No sustituiría una VPN que funciona solo porque otro producto muestra menos campos de configuración.

Tailscale: Conexiones directas con coordinación central

Tailscale añade a WireGuard registro de dispositivos, coordinación y políticas de acceso. Su servicio de control ayuda a los participantes a encontrarse. Los datos circulan directamente entre pares siempre que es posible. Si NAT o el cortafuegos lo impiden, un relé ofrece otra ruta. Incluso mediante DERP, los datos permanecen cifrados entre los pares de Tailscale.

Los routers de subred conectan LAN completas al tailnet. El escenario site-to-site documentado utiliza Linux en ambos extremos. Los dispositivos situados detrás no necesitan agente, pero sí rutas adecuadas. Desactivar el NAT de origen para conservar las direcciones originales hace especialmente importante planificar el camino de vuelta.

Ventajas: los dispositivos LAN existentes participan mediante routers de subred. Las conexiones directas evitan el desvío obligatorio por una sede central. Se pueden añadir dispositivos individuales con la misma plataforma.

Inconvenientes: no se garantiza una ruta directa. Los relés pueden cambiar latencia y caudal. La coordinación alojada sigue siendo una dependencia operativa; el plan y las funciones deben ajustarse al despliegue.

El cifrado WireGuard termina en el par participante. Si es un router de subred, el tramo LAN siguiente queda fuera del túnel. HTTPS o SSH siguen siendo útiles dentro de la red privada.

NetBird: Una malla similar que permite alojamiento propio

NetBird también utiliza WireGuard, intenta conexiones directas y emplea relés cuando hace falta. Los pares de enrutamiento conectan las redes cuyos dispositivos no ejecutan el cliente. La guía actual de site-to-site describe Networks, Resources y sus políticas de acceso.

Ventajas: el proyecto de código abierto ofrece una alternativa autohospedada al servicio en la nube. Es relevante cuando infraestructura y administración deben quedar bajo nuestra responsabilidad. Grupos y políticas permiten limitar el acceso con precisión.

Inconvenientes: alojarlo implica actualizaciones, copias, supervisión y disponibilidad de coordinación y relés. Una instalación rápida no elimina esas tareas. El montaje site-to-site documentado con Networks mantiene el enmascaramiento activado, por lo que el destino no ve simplemente la dirección original. Otras variantes de enrutamiento requieren planificación aparte.

Tailscale y NetBird son cercanos, pero sus configuraciones no son intercambiables. Los evaluaría según el enrutamiento y modelo de identidad necesarios. Código abierto tampoco implica que todas las funciones tengan uso ilimitado: hay que revisar licencias y funciones para el despliegue previsto.

Cloudflare Mesh: La red del proveedor es el recorrido

Los participantes establecen conexiones salientes a Cloudflare. El tráfico entre sedes atraviesa su red. No es necesario conectar cada sede directamente con todas las demás ni mantener un concentrador VPN propio. Aun así, el límite de confianza y el recorrido difieren de una malla WireGuard directa.

Ventajas: combina conectividad y políticas Gateway centrales. Puede encajar especialmente donde ya se utiliza Cloudflare One. Sedes detrás de NAT y clientes móviles se conectan mediante tráfico saliente.

Inconvenientes: operación y rutas dependen del proveedor. Su tratamiento debe cumplir los requisitos de confianza y privacidad de los datos sensibles. TLS o SSH siguen siendo útiles. Hay que medir si el recorrido beneficia a la aplicación concreta; una red troncal mundial no garantiza más rendimiento en todas partes.

Para un despliegue nuevo seguiría el cliente actualmente documentado. Cloudflare presenta Mesh en beta y exige MASQUE en el perfil del nodo. Con WireGuard documenta limitaciones en alta disponibilidad y rutas IPv6 y por nombre de host. Que un router soporte WireGuard no basta para considerarlo un nodo Mesh equivalente.

Tampoco debe confundirse Mesh con un túnel cloudflared para aplicaciones concretas. Aquí hablamos de conectividad IP privada bidireccional entre participantes y redes enrutadas.

Las diferencias de un vistazo

Estas son las diferencias que valoro primero. Hay que comprobar el plan necesario y el recorrido real en cada entorno.

Qué espero de una interconexión segura

Cuando preguntan qué solución es más segura, primero miro las conexiones permitidas y la gestión de accesos. Un túnel cifrado puede permitir demasiado. Quiero definir qué redes alcanzan qué servicios, cómo proteger administradores y cómo retirar accesos. MFA para administración y usuarios registrados personalmente, permisos limitados y pasarelas mantenidas forman parte de la valoración.

Los límites del cifrado también cambian. La VPN termina en las pasarelas. Tailscale y NetBird cifran entre pares, que pueden ser routers de subred. El LAN posterior no queda cifrado automáticamente. Con Cloudflare, el procesamiento dentro de su red debe encajar con los requisitos de la empresa. HTTPS o SSH siguen siendo útiles para la aplicación.

Una conexión saliente simplifica la instalación y puede evitar un servicio VPN públicamente accesible en la delegación. No sustituye una política. Una IP pública tampoco vuelve inseguro un cortafuegos por sí sola. El riesgo depende de los servicios expuestos, su protección y la operación. No establezco una clasificación de seguridad por el nombre del producto.

Qué quiero verificar antes de darlo por válido

Deben funcionar ida y vuelta. La ruta a 10.2.0.0/24 corresponde al router o cliente responsable. Si el destino responde por otra pasarela predeterminada, hace falta una ruta de retorno adecuada. SNAT facilita las respuestas, pero cambia la dirección visible y afecta a registros y reglas. Debe ser una decisión consciente.

Dos nodos de la red superpuesta no bastan para alta disponibilidad. Los dispositivos LAN deben alcanzar su siguiente pasarela tras una avería. Keepalived y VRRP pueden proporcionar una dirección virtual. Las rutas remotas también deben seleccionar un nodo sano. Quiero ver qué sucede con sesiones TCP nuevas y existentes cuando falla una pasarela o su túnel. Un proceso activo y un ping correcto solo responden a parte de esa pregunta.

Las pruebas también deben incluir conexiones bloqueadas deliberadamente. Si SSH debe funcionar y otra aplicación no, hay que comprobarlo. ICMP no demuestra que una regla TCP actúe. Registro, políticas y cortafuegos de destino deben coincidir.

Quedan detalles menos visibles que determinan el uso diario: prefijos únicos, nombres internos y MTU adecuada. Ni 192.168.x.x ni 10.x.x.x garantiza ausencia de conflictos. Si funcionan pings pequeños y se atascan transferencias grandes, no considero terminada la conexión.

Comparar rendimiento requiere la misma transferencia y aplicación interactiva sobre los enlaces reales. Hay que registrar ruta directa o por relé, carga CPU y comportamiento tras cambiar de conexión. Mi valoración trata de arquitectura y operación; no ofrece una clasificación de velocidad medida de estos productos.

Acceso remoto: Añadir dispositivos individuales

Si un empleado conecta su portátil desde casa a la empresa, es acceso remoto o client-to-site. El cliente funciona en el portátil y no conecta automáticamente toda la red doméstica con la central. Se puede utilizar el servicio del cortafuegos central o los clientes de estas plataformas. El registro personal permite asociar permisos a usuarios y grupos.

Un despacho doméstico también puede ser una sede site-to-site: una pasarela conecta una red autorizada o VLAN con la central. La diferencia es si conectamos un equipo o una red, no dónde trabaja la persona. Para equipos individuales, el acceso remoto suele ofrecer el alcance adecuado. No hay motivo para hacer accesible toda la red privada sin pretenderlo.

Dónde tiene sentido cada enfoque para mí

Con pocas sedes fijas y cortafuegos existentes, empezaría por VPN tradicional, eligiendo entre estrella y túneles directos. Para sedes detrás de NAT con gestión central y rutas directas cuando sea posible, compararía Tailscale y NetBird. Si gestionar la coordinación es un requisito firme, NetBird entra pronto en la evaluación. Donde ya hay políticas Cloudflare One, examinaría Mesh, su beta y el tratamiento dentro del proveedor. El acceso remoto adicional es un criterio independiente.

Headscale es otra opción: una implementación autohospedada del servidor de coordinación Tailscale. Es un proyecto separado con su propia cobertura funcional, no un reemplazo completo de todas las funciones alojadas. WireGuard manual ya forma parte del modelo tradicional y encaja si bastan unos túneles sin otra capa de gestión.

Cuando me preguntan qué es mejor, quiero recomendar algo que encaje con la empresa y sus próximos cambios. En una instalación modesta con cortafuegos existentes puede seguir siendo VPN tradicional. Otras condiciones de conexión o necesidades administrativas hacen interesantes las mallas. Decidiría según si las conexiones necesarias pueden operarse con seguridad, comprenderse y recuperarse tras una avería.

Hasta la próxima,
Joe