- Tailscale Peer Relays es una nueva función de retransmisión de tráfico que reemplaza a los servidores DERP existentes, con una arquitectura que los usuarios pueden desplegar y administrar por su cuenta
- Cada nodo puede asumir el rol de relé con solo abrir un puerto UDP, y se puede activar fácilmente porque está integrado en el cliente de Tailscale
- Ofrece conexiones de alta velocidad y alto rendimiento, logrando un desempeño cercano a una conexión directa incluso detrás de NAT en la nube o firewalls
- Todo el tráfico mantiene cifrado de extremo a extremo basado en WireGuard® y admite fallback automático a DERP y DERP personalizado
- Actualmente está disponible en beta pública, y todos los planes incluyen hasta 2 Peer Relays gratis
Resumen de Tailscale Peer Relays
- Tailscale Peer Relays es un mecanismo de retransmisión de tráfico administrado por el usuario que puede reemplazar a los servidores DERP administrados de Tailscale
- Cualquier nodo de Tailscale puede configurarse como relé y retransmitir tráfico entre nodos dentro del mismo tailnet
- Un relé solo puede retransmitir para nodos del tailnet al que pertenece
- Al ser administrado directamente por el cliente, tiene menos limitaciones de rendimiento que DERP y ofrece alto desempeño incluso en infraestructura de nube cerrada o entornos con firewall
- En pruebas iniciales con socios, registró un rendimiento cercano a la conexión directa y confirmó una velocidad decenas de veces superior frente al DERP existente
Superar entornos con Hard NAT
- Tailscale aplica técnicas mejoradas de NAT traversal para mantener conexiones directas (más del 90%) siempre que sea posible, incluso en entornos NAT
- Sin embargo, en algunos entornos de nube la conexión directa puede ser imposible o ineficiente
- El DERP existente ofrece conexiones estables, pero presenta dificultades en algunos despliegues debido a restricciones de QoS y límites de rendimiento
- Peer Relays fue diseñado como una herramienta de conexión enfocada en el rendimiento, con comunicación de baja latencia basada en UDP y una arquitectura integrada en el cliente que facilita el despliegue
- Los clientes pueden colocar sus propios relés para construir una red de alto rendimiento y gran flexibilidad
Cómo funciona
- Peer Relay usa un único puerto UDP accesible para ambos nodos
- Se puede activar fácilmente con el comando de CLI
tailscale set --relay-server-port
- Si no es posible establecer una conexión directa, aplica fallback automático en el orden Peer Relay → DERP (administrado o personalizado)
- Todas las conexiones están protegidas con cifrado WireGuard®
- Puede configurarse para permitir solo tráfico interno del tailnet mientras se minimizan las excepciones en el firewall
- También admite escalabilidad entre regiones, tolerancia a fallas de red y fallback automático a DERP
Distintos escenarios de uso
- Retransmisión de alta velocidad para tráfico que no puede conectarse directamente en entornos con NAT en la nube (como AWS Managed NAT Gateway)
- En entornos con firewall estricto, basta con abrir un solo puerto UDP para acortar los procesos de aprobación
- Reduce la carga de la red DERP y elimina la necesidad de mantener un DERP personalizado
- Al acceder a redes de clientes cerradas, permite abrir solo los puertos mínimos mediante endpoints predecibles
- En la práctica, los clientes han usado Peer Relay para implementar acceso a redes no administradas, control de rutas de conexión con socios y segmentación de red detallada basada en VPC peering, entre otros casos
Beta pública y política de disponibilidad
- Tailscale Peer Relays ya está disponible de inmediato como beta pública
- Actualmente se están realizando mejoras en visibilidad y depuración
- Los socios iniciales confirmaron despliegue sencillo y rendimiento estable
- Todos los planes, incluido el gratuito, incluyen hasta 2 Peer Relays sin costo, y se pueden ampliar relés adicionales
- Si se necesitan más relés, es posible ampliar la capacidad contactando al equipo comercial de Tailscale
1 comentarios
Opiniones de Hacker News
Esta función me parece realmente razonable
Usa un nodo intermedio solo cuando no es posible una conexión directa, y el tráfico queda cifrado de extremo a extremo
Es parecido a operar tu propio servidor DERP, pero sin necesidad de abrir puertos, y además reduce el uso de los relays de Tailscale, lo que también baja los costos de ancho de banda
Aun así, me pregunto por qué es de pago usar más de dos relays
Si no, quizá ni siquiera necesitarías Tailscale en primer lugar
Como excepción, a veces pasa que dos clientes pueden acceder al relay pero no conectarse directamente entre sí
tinc ya resolvía este problema hace tiempo
Todos los nodos pueden actuar como relay y funciona como una verdadera red mallada sin servidor central
En vez de reimplementarlo, me parecería mejor portarlo sobre WireGuard y en un lenguaje con seguridad de memoria
Incluso pasa mucho que la ruta se cae justo después de establecer una conexión SSH
Como el tráfico se descifra y se vuelve a cifrar en el nodo relay, para tener cifrado de extremo a extremo hay que usar un protocolo experimental
Me gustaría reescribirlo basándome en el protocolo de cjdns, pero no es nada fácil
La nueva función Peer Relay de Tailscale se parece a lo que ZeroTier hacía antes
Cuesta sostener que sea una “función exclusiva de Tailscale”, y además me parece excesivo cobrar extra además de la tarifa por usuario
En cambio, sí tenía problemas con su cifrado propio, la baja de rendimiento en un solo hilo y la lentitud del desarrollo
He probado varias alternativas, pero todavía no hay otra que combine funciones y rendimiento tan bien como Tailscale
Se siente como comparar “si existe FTP, ¿para qué usar Dropbox?”
Me pregunto si se pueden especificar directamente direcciones externas IPv4/IPv6
Lo digo porque a veces el tráfico de envío y recepción usa direcciones distintas, o porque el firewall solo permite algunas entre varias direcciones de conexión a internet
La semana pasada configuré headscale y split horizon SSL, pero al final descubrí que solo DERP es posible
Me parece mejor exponer directamente puertos UDP en la red local
Si la seguridad del cliente de WireGuard ya está suficientemente validada, eso resulta más cómodo
Quisiera saber si intentabas abrir directamente el puerto de WireGuard o si te referías al puerto de Tailscale
Si usas esta función en lugar de DERP, no funcionará en el navegador
Porque está basada en UDP nativo
Me pregunto si más adelante podrían implementarlo con WebTransport
Pero no resuelve el problema del NAT traversal
También estoy siguiendo de cerca el avance de QAD de Iroh
Si todo encaja bien, podría volverse una red mucho más mágica
Me pregunto si el siguiente paso sería que todos los clientes de tailscale acepten automáticamente solicitudes de reenvío, para que la red mallada se autorrecupere sin interrupciones
Pero el punto clave es si se va a permitir o no retransmitir tráfico de otras personas
Con Tailscale se puede conectar servicios entre sí, pero si hubiera una caída de Tailscale, me pregunto si incluso mis propios servicios dejarían de comunicarse entre ellos
No podía conectarme a tailscale, así que tampoco era posible reconectarse
Por eso ahora pienso montar headscale por mi cuenta
Que ni siquiera los dispositivos de la LAN local pudieran comunicarse me pareció bastante absurdo
Me pasé todo el fin de semana haciendo una solución temporal para el Kubernetes Operator, y ahora gracias a esta función voy a poder quitarla por completo
De verdad, bravo
Tenía curiosidad por los casos de uso de esta función
Parece servir para integrar productos SaaS que necesitan datos del sistema del cliente, exponiendo esos datos del lado del cliente a través de un relay
Aun así, parece que seguiría haciendo falta software para autenticación, logging, etc.
Como muchas veces no se puede atravesar el NAT, DERP se usa con frecuencia, pero es lento
Ahora se puede designar como relay a un peer dentro de la red que tenga buena conectividad, para usarlo más rápido
Más que un caso de uso nuevo, es una mejora de rendimiento del DERP existente
En lugar de una estructura tradicional de hub-and-spoke, apunta a una arquitectura P2P donde todos los nodos se conecten directamente por UDP/IP siempre que sea posible
Pero por culpa del NAT y los firewalls, muchas veces no se puede establecer la conexión directa, así que DERP actúa como intermediario
DERP era lento y el usuario no tenía forma de mejorar el rendimiento, pero con este Peer Relay ahora sí puede operar su propio relay
Si eliges bien la ubicación, también puedes reducir la latencia
Claro, no es una función que todos los usuarios necesiten