Tecnología JIT WireGuard

Mejoras de WireGuard en Fly.io

• Fly.io convierte contenedores en VM y los ejecuta globalmente en hardware aprovechando la potencia de Firecracker.
• Usa mucho WireGuard, y ahora forma parte de la API para clientes.
• Cada vez que se ejecuta la CLI flyctl, crea un stack TCP/IP y se comunica directamente con Fly Machines usando una dirección IPv6 única.
• Este enfoque tiene ventajas y desventajas, y hay varias mejoras.

Situación anterior

• Los servidores "gateway" distribuidos por todo el mundo aceptaban conexiones WireGuard y se encargaban de conectarlas a la red privada adecuada.
• Cada vez que se ejecutaba flyctl, se creaba o conectaba un proceso de agente en segundo plano.
• El agente generaba una nueva configuración de peer de WireGuard en la API GraphQL.
• La API enviaba la configuración del peer al gateway correspondiente a través del sistema de mensajería NATS.
• En el gateway, el servicio wggwd recibía la configuración, la guardaba en una base de datos SQLite y la agregaba al kernel.
• La API respondía a la solicitud GraphQL entregando la configuración, y flyctl se conectaba al peer de WireGuard.
• NATS es rápido, pero no garantiza la entrega ni limpia los peers antiguos que quedan en los gateways.

Una mejor manera

• Almacenar peers de WireGuard no requiere una base de datos compleja.
• Se cambió para que el gateway obtenga la configuración desde la API cada vez que la necesite.
• Los peers se pueden agregar al kernel solo cuando un cliente quiere conectarse, y eliminarse cuando ya no hagan falta.

Hacer posibles los peers JIT de WireGuard

• La interfaz de configuración de WireGuard en el kernel de Linux usa Netlink.
• Los paquetes de solicitud de conexión de WireGuard pueden identificarse e interceptarse con filtros BPF y sockets de paquetes.
• WireGuard no tiene los conceptos de "cliente" y "servidor"; es un protocolo punto a punto.
• Cuando flyctl envía un paquete UDP al gateway, eso es un handshake initiation.
• Se pueden capturar conexiones entrantes usando filtros BPF.
• Como se basa en el framework del protocolo Noise, hay que descifrar para identificar la solicitud.
• Es posible crear un feed de eventos para obtener las claves públicas de todos los usuarios que intentan conectarse al gateway.
• Cada vez que se detecta un peer nuevo, se obtiene e instala su información mediante una solicitud a una API HTTP interna.

Lanzar apps por minuto

• En Fly.io se pueden desplegar apps rápidamente y obtener su propio peer JIT de WireGuard.

Revisando las gráficas

• Tras operar este sistema durante varias semanas, se redujo notablemente la cantidad de peers antiguos de WireGuard que quedaban en los gateways.
• Los gateways mantienen menos estado y la configuración de peers es más rápida.
• Se comparten gráficos de Grafana para mostrar los buenos resultados del día de la transición.

Opinión de GN⁺

• La mejora de WireGuard en Fly.io es un buen ejemplo de cómo elevar significativamente el rendimiento y la estabilidad de la red.
• Este enfoque puede ser especialmente útil para reforzar la gestión del tráfico de red y la seguridad en servicios basados en la nube.
• Otros proyectos con funciones similares incluyen Tailscale y ZeroTier, que también ofrecen alternativas de VPN para usuarios individuales y empresas.
• Al adoptar WireGuard, hay que considerar la configuración de red, las políticas de seguridad y la compatibilidad.
• Las ventajas de elegir esta tecnología son su alto rendimiento y su configuración sencilla, aunque puede presentar retos en la integración con la infraestructura existente o en su administración.

[GN⁺]

Comentarios en Hacker News

• WireGuard del kernel de Linux no tiene una forma de instalar peers bajo demanda, lo que al parecer causa problemas para construir el diseño.

  • El WireGuard del kernel de Linux presenta dificultades de diseño por la falta de una función para instalar peers según la solicitud.
  • Se pueden agregar peers en tiempo de ejecución, pero parece que se busca autenticar al peer antes de agregarlo a la interfaz para evitar entradas innecesarias.
  • Usan filtros eBPF para gestionar directamente conexiones basadas en enrutamiento de claves criptográficas con contrapartes autenticadas, y una vez completada la verificación, agregan el peer a la interfaz y luego lo eliminan tras un timeout.

• Estoy de acuerdo en que una solicitud HTTP es más confiable que el enrutamiento por una cola de mensajes, pero me sorprendió que los mensajes perdidos por NATS hayan afectado tanto al servicio.

  • Coincide en que las solicitudes HTTP directas son más confiables que una cola de mensajes, pero le resulta extraño que la pérdida de mensajes en NATS haya tenido un impacto tan grande en el servicio.
  • Esperaba que NATS intentara retransmitir los mensajes en caso de pérdida, y expresa dudas sobre por qué se produjeron problemas de confiabilidad tan notorios.

• Quiero promocionar un proyecto experimental reciente. Si te interesa construir apps en Go que funcionen como peers de WireGuard en espacio de usuario, échale un vistazo.

  • Presenta su propio proyecto para quienes estén interesados en construir apps en Go que funcionen como peers de WireGuard en espacio de usuario.
  • Se basa en el excelente trabajo de wireguard-go, pero busca simplificarlo para que sea más adecuado para usarlo como librería.
  • Tiene interés en construir un service mesh, y aunque el soporte para varios lenguajes puede ser difícil, cree que sería posible implementar una API de sockets.
  • Menciona que todavía no ve aceleración por hardware para el cifrado de WireGuard, por lo que podría ser difícil competir con mTLS.
  • Comenta que trabaja como freelancer en redes rápidas y seguras, y que quien tenga interés puede contactarlo (su correo está en el perfil).

• Es interesante que tunelizar WireGuard sobre WebSockets sea la configuración predeterminada. No es bueno para el rendimiento, pero probablemente sirva para tareas de DevOps donde se usa flyctl.

  • Señala que tunelizar WireGuard a través de WebSockets sea la configuración por defecto.
  • No parece lo ideal para el rendimiento, pero estima que no será un problema para tareas de DevOps en las que se usa flyctl.
  • Se pregunta por el futuro de QUIC/HTTP3 y cuestiona si los operadores de red llegarán a manejar correctamente UDP en el puerto 443 en vez de bloquearlo.

• Nosotros podemos instalar al peer como iniciadores, y flyctl es quien responde. El kernel de Linux inicia la conexión WireGuard hacia flyctl. Este método funciona, y al protocolo no le importa demasiado quién es el servidor y quién es el cliente. Las nuevas conexiones se establecen lo más rápido posible.

  • Explica el enfoque en el que ellos instalan al peer como iniciadores y flyctl actúa como respondedor, mientras el kernel de Linux inicia la conexión WireGuard.
  • Señala que al protocolo no le afecta mucho la distinción entre servidor y cliente, y que las nuevas conexiones pueden establecerse muy rápidamente.

• Mi startup usó Fly durante casi un año. La función principal, pasar del código al código desplegado en menos de un minuto, es hermosa. Puedes levantar y bajar nodos nuevos en cuestión de segundos.

  • Comparte la experiencia de su startup usando Fly durante casi un año.
  • Valora positivamente la capacidad de desplegar código con rapidez, pero siente que la empresa todavía es algo inmadura.
  • Menciona una experiencia en la que el servidor de API de Fly estuvo inaccesible durante 48 horas, así como problemas de desconexiones inconsistentes en el producto "db".
  • Señala que el acceso a la API de Fly se caía con frecuencia, lo que dificultaba desplegar cambios en nuevos servicios.
  • Dice que extraña la experiencia de despliegue, pero que está más satisfecho usando Cloud Run de GCP.

• “Cada vez que ejecutas flyctl, nuestra encantadora y enorme CLI crea una pila TCP/IP de la nada y se comunica directamente con Fly Machines con su propia dirección IPv6 única.”

  • Expresa curiosidad por la explicación de que, al ejecutar flyctl, se crea en el acto una pila TCP/IP y se establece comunicación directa con Fly Machines mediante una dirección IPv6 única.

• ¿Qué impide que el paquete inicial del handshake sea retransmitido a la pila de red? Si se hiciera, parecería que no habría pérdida de paquetes. Además, ¿cuál es el propósito de revisar udp[8] = 1 en el filtro eBPF?

  • Plantea una pregunta sobre el mecanismo que evita que el paquete inicial del handshake sea retransmitido a la pila de red y sobre la razón para comprobar un valor específico en paquetes UDP dentro del filtro eBPF.

• ¿Cómo despliego una aplicación dockerizada cualquiera en Fly.io? Tomen mi dinero.

  • Expresa interés y disposición a pagar por saber cómo desplegar una aplicación dockerizada en Fly.io.

• Para todos los demás, voy a promocionar descaradamente Netmaker.

  • Comparte una experiencia satisfactoria usando Netmaker, menciona la necesidad personal de acceder a una AWS VPC y espera que Netmaker sea adoptado más ampliamente.