JIT WireGuard

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

Herramientas VPN basadas en WireGuard y acceso a AWS

  • Se comenta Netmaker como una alternativa autocontenible basada en WireGuard, similar a Tailscale; también se recomienda Netbird, aunque se lo critica por la recolección extensa de datos y un comportamiento arriesgado del daemon (por ejemplo, crear túneles SSH como root).
  • Algunos preguntan por qué no usar opciones nativas de AWS (VPC peering, PrivateLink, AWS VPN, SSM). Las respuestas: están pensadas para conectividad entre VPCs, no para acceso SSH barato y simple a través de muchas cuentas; la salida de AWS VPN puede ser costosa para mucho tráfico de datos, mientras que SSM + SSH funciona pero requiere agentes/permisos y más herramientas.

Concepto de JIT WireGuard y detalles de implementación

  • Los peers WireGuard “just-in-time” del blog resuelven el problema de que WireGuard en el kernel no tiene una API nativa de “instalación de peers bajo demanda”.
  • Interceptan solo los paquetes de inicio usando eBPF (udp[8] = 1), y luego deciden en userspace si autorizan e instalan un peer; los peers obsoletos se eliminan después.
  • Algunos sugieren usar NFQUEUE para poner los paquetes en cola hacia userspace y luego devolver un veredicto (drop/allow) tras la configuración, habilitando fail-open y escalado a múltiples workers.
  • Se debate la posibilidad de volver a enviar el paquete inicial del handshake después de instalar el peer; se considera posible y una optimización elegante, aunque no está implementada en el artículo.
  • El enfoque busca soportar muchos peers potenciales sin cargarlos todos previamente en el kernel; los peers viven principalmente en una base de datos y se instalan bajo demanda. Otras soluciones basadas en WireGuard usan técnicas similares para mantenerse dentro de los límites de recursos.
  • JIT se aclara como “just-in-time configuration”, no compilación; algunos señalan que el término se usa mucho fuera de los compiladores (por ejemplo, en manufactura).

Debate sobre el diseño y las limitaciones de WireGuard

  • Una línea de crítica: WireGuard está estrechamente ligado a una interfaz de red; algunos quisieran que fuera un “filtro” genérico utilizable con descriptores de archivo arbitrarios, desbloqueando composiciones más flexibles.
  • Otros defienden su objetivo de diseño: una superficie de configuración mínima para facilitar auditorías y seguridad práctica, frente a la complejidad de IPSec.
  • Las quejas se centran menos en el protocolo y más en las herramientas: configuraciones estilo .ini, desajuste entre wg y wg-quick, y una UX de cliente incómoda (especialmente en Windows).
  • Varios señalan que WireGuard no es una “solución VPN” completa: no incluye envío integrado de rutas/DNS ni distribución centralizada de políticas. Los atajos incluyen ejecutar BGP o escribir clientes personalizados, pero eso resulta demasiado complejo para muchos, especialmente en móviles.
  • El modelo de “cryptokey routing” se ve como fundamental; los productos de nivel superior (Tailscale, Netmaker, etc.) existen precisamente para añadir gestión, políticas y distribución de rutas por encima.

Navegador, userspace y pilas de red alternativas

  • Ejecutar WireGuard en navegadores está limitado por la falta de sockets sin procesar; solo funcionan rutas basadas en HTTP/WebSocket. Algunos proyectos usan relays (por ejemplo, WebSocket sobre servidores relay especializados) y WebAssembly para aproximar el comportamiento de una VPN.
  • OpenZiti/BrowZer se presenta como ejemplo: un modelo de service worker + WebAssembly que permite a los navegadores unirse a una red superpuesta privada mediante WebSockets, después de una inyección inicial de script.
  • flyctl de Fly usa una pila TCP/IP en userspace más WireGuard en userspace; el sistema operativo anfitrión no es el peer de WireGuard, solo lo es el proceso de la CLI. También hay un modo separado de peer “real” para acceso a nivel de sistema operativo.
  • A algunos les parecen extrañas conceptualmente las pilas TCP/IP en userspace, pero otros señalan que fueron comunes históricamente y cada vez son más prácticas.

Mensajería de plano de control (NATS vs HTTP)

  • A los comentaristas les sorprende que la coordinación basada en NATS tuviera suficiente pérdida de mensajes como para afectar la fiabilidad.
  • Se señala que el NATS “core” no ofrece durabilidad/reenvío; JetStream añade esas funciones, pero quizá no estaba configurado o disponible cuando se diseñó.
  • El personal de Fly dice que probablemente “usaron NATS mal” y se dieron cuenta de que un broker de mensajes añadía complejidad sin más expresividad para sus casos simples de mensaje único; un modelo directo de solicitud HTTP es más fácil de razonar y supervisar.

Restricciones de VPN de Apple/macOS

  • Hay una afirmación de que la GUI oficial de WireGuard para macOS debe distribuirse mediante la App Store porque Apple retiene los entitlements de VPN necesarios para apps web o autodesplegadas; esto se presenta como hostil a la privacidad, ya que el uso de la App Store vincula el software con la identidad y el hardware del usuario.
  • Otros lo disputan, señalando clientes VPN que no pasan por la App Store y funcionan bien, lo que sugiere que la afirmación original está exagerada.
  • Aclaración: las API más nuevas de Network Extension/System Extension requieren entitlements específicos, que Apple ahora concede a miembros del Developer Program, así que compilar la app exacta de WireGuard desde el código fuente como no miembro del programa no funcionará completamente sin desactivar funciones de seguridad. Siguen siendo utilizables para apps que no sean de App Store las API VPN más antiguas o diferentes.

Experiencia con la plataforma Fly.io

  • Varios usuarios elogian la ergonomía para desarrolladores de Fly.io: despliegues globales rápidos, arranque muy veloz de cargas de trabajo, red Anycast y funciones como FLY_REPLAY y LiteFS que facilitan el clustering global y el acceso de baja latencia más que en proveedores VPS tradicionales.
  • Otros reportan serios problemas de fiabilidad: caídas de varios días para servicios críticos, una oferta de “db”/Postgres frágil y explícitamente “no administrada”, y caídas de la API/plano de control que bloquean los despliegues. Esto lleva a algunos a migrar a GCP (Cloud Run o GKE) para tener menos sorpresas y mejor documentación.
  • Algunos siguen usando Fly.io pese a sus asperezas, con la esperanza de que la plataforma madure y se convierta en una alternativa estable centrada en Anycast.

Elección de transporte y conectividad

  • En flyctl, WireGuard suele tunelizarse sobre WebSockets por defecto para sobrevivir a redes restrictivas donde UDP (incluso en 443) está bloqueado o es poco fiable; WireGuard puro sobre UDP se admite como opción opt-in.
  • Esta opción por defecto se elige para minimizar fallos de UDP difíciles de depurar; hacer sondeos tipo “happy eyeballs” para elegir entre UDP y WebSocket se considera una complejidad innecesaria dada la orientación de Fly (plataforma cloud, no servicio VPN general).
  • La discusión confirma que el truco del handshake JIT funciona a través de NAT mientras el 4-tuple (IP+puerto de origen/destino) sea consistente, ya que los NAT UDP típicos no inspeccionan el contenido de los paquetes.

Varios

  • Se aclara cierta confusión sobre la explicación de Fly de que WireGuard en kernel no admite peers “bajo demanda”: los peers sí pueden añadirse en tiempo de ejecución, pero el esquema JIT requiere autenticar y decidir antes de añadirlos, para evitar almacenar una gran cantidad de peers que nunca se usan.
  • Se mencionan varios proyectos WireGuard/Noise en userspace (por ejemplo, bibliotecas de Go), con ideas para túneles a nivel de aplicación, transferencia de archivos tipo magic-wormhole y superposiciones estilo service mesh.
  • Desplegar aplicaciones dockerizadas en Fly se describe como sencillo: ejecutar flyctl launch en el directorio con el Dockerfile.