Haciendo Tailscale más rápido

Artículo original ↗ Discusión en Hacker News ↗

El trabajo reciente de Tailscale para hacer más rápida su VPN de malla basada en WireGuard ha reavivado el debate sobre las compensaciones entre un dataplane en userspace y multiplataforma, y alternativas a nivel de kernel o aceleradas por hardware. Los comentaristas destacan que, aunque Tailscale sobresale en facilidad de configuración, incorporación de dispositivos y traversal de NAT frente a WireGuard o IPsec autogestionados, todavía tiene dificultades para aprovechar plenamente enlaces de varios gigabits y puede aumentar el consumo de batería en dispositivos móviles. También hay un interés activo en direcciones futuras como mejores estrategias de relé, criptografía poscuántica y acelerada por hardware, y un soporte más rico para routers, microcontroladores y modelos de acceso sin app.

Enfoque de plataforma y trabajo en dataplane

  • Las notas de la discusión señalan que la entrada del blog enfatiza Linux/Android porque muchas optimizaciones a nivel de paquetes son específicas del sistema operativo y estas plataformas exponen las funciones necesarias.
  • Se dice que cambios arquitectónicos como multiqueue y las optimizaciones de memoria son, en general, aplicables a otros sistemas operativos.

Rendimiento, userspace vs kernel

  • Varios comentaristas afirman que Tailscale es “lento”, citando la dificultad para superar 1 Gbps en clientes de escritorio y ~10 Gbps en Linux en pruebas sintéticas.
  • Los críticos dicen que la red en userspace, con copias extra y cambios de contexto, tiene un techo inherente y piden WireGuard en kernel o enfoques de copia cero al estilo DPDK/XDP.
  • Otros contraargumentan que las copias de memoria y las syscalls no son los principales cuellos de botella; las decisiones de protocolo e implementación importan más.
  • Un representante de Tailscale responde que el kernel no es automáticamente más rápido; en un momento, su WireGuard en userspace superó a la versión en kernel, y las rutas de alto rendimiento al estilo DPDK también son userspace.

WireGuard vs Tailscale vs alternativas

  • Algunos usuarios cambian de Tailscale a WireGuard puro, citando mejor estabilidad, velocidad percibida y simplicidad gracias a integraciones con routers y a una configuración sencilla de claves.
  • Otros se mueven en la dirección opuesta, elogiando Tailscale por su incorporación trivial, el registro dinámico de dispositivos (incluidos trabajos de CI), la integración fácil de DNS y por sortear las limitaciones de NAT y de reenvío de puertos (por ejemplo, en casas de familiares).
  • Cloudflare Tunnels se menciona como una alternativa “sin app” para algunos casos de uso.

Cripto, aceleración por hardware y poscuántica

  • Hay debate sobre si Tailscale debería desviarse de ChaCha20/Poly1305 de WireGuard hacia AES-GCM para aprovechar la descarga por hardware de NIC para 100–400+ Gbps.
  • Se expresan preocupaciones de que apartarse del diseño cuidadosamente analizado de WireGuard hace perder garantías formales; otros argumentan que cambiar cifrados puede preservar las propiedades principales.
  • Algunos consideran que IPsec es demasiado complejo y, históricamente, delicado; otros señalan que puede usarse con un plano de control simplificado y una fuerte aceleración por hardware.
  • Se discute el soporte poscuántico: algunos sostienen que WireGuard v2 o un dataplane actualizado es inevitable; otros mencionan PSKs como un sustituto limitado “resistente a lo cuántico”.

Relés, enrutamiento y DERP

  • Quejas sobre la latencia de DERP y deseo de un relé más flexible.
  • La función de relé entre pares existe, pero actualmente requiere que el par relé no esté detrás de NAT; los comentaristas quieren un uso más oportunista de pares atravesables por NAT como relés improvisados.

UX del cliente, batería y peculiaridades de plataforma

  • Múltiples comentarios informan de un alto consumo de batería en iOS y al usar nodos de salida; los usuarios quieren dejar Tailscale conectado continuamente sin un drenaje importante.
  • Se informa que el rendimiento del nodo de salida en Apple TV es deficiente; el sistema operativo elimina agresivamente las apps en segundo plano, limitando lo que Tailscale puede hacer.
  • Hay cierta confusión/quejas sobre la exclusión de apps de Android de las rutas VPN; otros señalan que Android permite que las apps opten por no participar, y que “block connections without VPN” puede mitigar fugas.
  • Privacidad DNS: se solicita soporte para DoH; Tailscale señala que usar un servidor DNS de tailnet ya mantiene las consultas DNS privadas a través del túnel, mientras que DoH añade complejidad TLS.

Casos de uso avanzados/de borde y solicitudes de funciones

  • Se pide:
    • Una mejor historia para soporte de microcontroladores/IoT.
    • Una configuración más sencilla de proxy sidecar multinodo cuando los dispositivos no pueden ejecutar Tailscale directamente (hoy a menudo requiere un contenedor por dispositivo proxyado).
    • Una descripción más clara de “queues” y “depth” en los diagramas de red del blog.
  • Algunos usuarios piden explícitamente a Tailscale que no se “enshitify”, reflejando un fuerte entusiasmo pero también preocupación por la dirección del producto a largo plazo.