La technologie JIT WireGuard

Les améliorations de WireGuard chez Fly.io

• Fly.io convertit des conteneurs en VM et les exécute sur du matériel dans le monde entier en s'appuyant sur la puissance de Firecracker.
• WireGuard est largement utilisé et fait désormais partie de l'API client.
• À chaque exécution du CLI flyctl, une pile TCP/IP est créée et communique directement avec les Fly Machines en utilisant une adresse IPv6 unique.
• Cette approche présente des avantages et des inconvénients, et quelques améliorations ont été apportées.

Situation précédente

• Des serveurs « gateway » répartis dans le monde entier acceptaient les connexions WireGuard et se chargeaient de les relier au bon réseau privé.
• À chaque exécution de flyctl, un processus agent en arrière-plan était créé ou réutilisé.
• L'agent créait une nouvelle configuration de pair WireGuard via l'API GraphQL.
• L'API transmettait la configuration du pair à la gateway appropriée via le système de messagerie NATS.
• Sur la gateway, le service wggwd recevait la configuration, l'enregistrait dans une base SQLite, puis l'ajoutait au noyau.
• L'API répondait à la requête GraphQL en renvoyant la configuration, puis flyctl se connectait au pair WireGuard.
• NATS est rapide, mais ne garantit pas la livraison et ne nettoyait pas les anciens pairs restés sur les gateways.

Une meilleure méthode

• Le stockage des pairs WireGuard ne nécessite pas de base de données complexe.
• Le système a été modifié pour que les gateways récupèrent la configuration depuis l'API chaque fois que nécessaire.
• Il devient possible d'ajouter des pairs au noyau uniquement quand un client veut se connecter, puis de les supprimer lorsqu'ils ne sont plus nécessaires.

Des pairs WireGuard JIT rendus possibles

• L'interface de configuration de WireGuard dans le noyau Linux utilise Netlink.
• Il est possible d'identifier et d'intercepter les paquets de demande de connexion WireGuard avec un filtre BPF et un packet socket.
• WireGuard n'a pas de notion de « client » et de « serveur » ; c'est un protocole point à point.
• Quand flyctl envoie un paquet UDP à une gateway, il s'agit d'une handshake initiation.
• Un filtre BPF permet de capter les connexions entrantes.
• Comme le système repose sur le framework du protocole Noise, il faut déchiffrer pour identifier la requête.
• En créant un flux d'événements, il est possible d'obtenir les clés publiques de tous les utilisateurs qui tentent de se connecter à une gateway.
• Chaque fois qu'un nouveau pair est détecté, ses informations sont récupérées et installées via une requête vers l'API HTTP interne.

Lancer des apps à la minute près

• Sur Fly.io, il est possible de déployer rapidement des apps et d'obtenir son propre pair WireGuard JIT.

Coup d'œil aux graphiques

• Après plusieurs semaines d'exploitation de ce système, le nombre d'anciens pairs WireGuard restés sur les gateways a nettement diminué.
• Les gateways conservent moins d'état et la configuration des pairs est plus rapide.
• Des graphiques Grafana illustrent les résultats positifs obtenus le jour de la bascule.

L'avis de GN⁺

• Les améliorations de WireGuard chez Fly.io constituent un bon exemple d'optimisation des performances et de la fiabilité réseau.
• Cette approche peut être particulièrement utile pour renforcer la gestion du trafic réseau et la sécurité dans les services basés sur le cloud.
• Parmi les autres projets offrant des fonctionnalités similaires, on peut citer Tailscale et ZeroTier, qui proposent eux aussi des alternatives VPN pour les particuliers et les entreprises.
• Lors de l'adoption de WireGuard, il faut prendre en compte la configuration réseau, les politiques de sécurité et la compatibilité.
• Les avantages de ce choix sont des performances élevées et une configuration simple, mais l'intégration à l'infrastructure existante et la gestion peuvent représenter un défi.

[GN⁺]

Commentaires Hacker News

• On dit que le WireGuard du noyau Linux pose des problèmes de conception parce qu’il n’a pas de fonctionnalité permettant d’installer des pairs à la demande.

  • Le WireGuard du noyau Linux complique la conception en raison de l’absence d’une fonctionnalité permettant d’installer des pairs à la demande.
  • Il est possible d’ajouter des pairs à l’exécution, mais l’idée semble être d’authentifier le pair avant de l’ajouter à l’interface afin d’éviter des entrées inutiles.
  • Ils gèrent directement les connexions basées sur le routage de clés chiffrées avec des homologues authentifiés à l’aide de filtres eBPF, puis ajoutent le pair à l’interface une fois la vérification terminée avant de le supprimer après expiration du délai.

• Je suis d’accord pour dire que les requêtes HTTP sont plus fiables qu’un routage via une file de messages, mais j’ai été surpris d’apprendre que des messages perdus avec NATS ont eu un impact important sur le service.

  • Accord avec l’idée que des requêtes HTTP directes sont plus fiables qu’une file de messages, mais étonnement face au fait que des pertes de messages dans NATS aient eu un impact considérable sur le service.
  • On s’attendrait à ce que NATS tente une retransmission en cas de perte de messages, d’où l’interrogation sur la raison de problèmes de fiabilité aussi visibles.

• J’aimerais promouvoir un projet expérimental récent. Si vous souhaitez créer une application Go qui fonctionne comme un pair WireGuard en espace utilisateur, allez y jeter un œil.

  • Présentation de son propre projet à destination de celles et ceux qui souhaitent créer une application Go fonctionnant comme un pair WireGuard en espace utilisateur.
  • Le projet s’appuie sur l’excellent travail de wireguard-go, tout en cherchant à le simplifier pour un usage plus adapté comme bibliothèque.
  • Intérêt pour la construction d’un service mesh, avec l’idée qu’un support multilangage pourrait être difficile mais qu’une API socket devrait pouvoir être implémentée.
  • Mention du fait qu’aucune accélération matérielle ne semble encore visible pour le chiffrement de WireGuard, ce qui pourrait compliquer la concurrence avec mTLS.
  • La personne travaille en freelance dans le domaine des réseaux rapides et sécurisés, et invite les personnes intéressées à la contacter (adresse e-mail dans le profil).

• Il est intéressant que le tunnel WireGuard au-dessus de WebSockets soit la configuration par défaut. Ce n’est pas bon pour les performances, mais cela conviendra sans doute aux tâches DevOps où flyctl est utilisé.

  • Remarque sur le fait que le tunnel WireGuard via WebSockets soit la configuration par défaut.
  • Ce n’est pas optimal pour les performances, mais cela devrait convenir aux tâches DevOps utilisant flyctl.
  • Interrogation sur l’avenir de QUIC/HTTP3 et sur la possibilité que les opérateurs réseau traitent correctement l’UDP sur le port 443 au lieu de le bloquer.

• Nous pouvons installer le pair en tant qu’émetteur, et flyctl est le répondeur. Le noyau Linux initie la connexion WireGuard vers flyctl. Cette méthode fonctionne, et le protocole ne se soucie pas vraiment de savoir qui est serveur ou client. Les nouvelles connexions sont établies aussi vite que possible.

  • Explication du fonctionnement où le pair est installé côté émetteur tandis que flyctl agit comme répondeur, le noyau Linux initiant la connexion WireGuard.
  • Il est mentionné que le protocole ne dépend pas vraiment des rôles serveur/client et que de nouvelles connexions peuvent être établies très rapidement.

• Ma startup a utilisé Fly pendant près d’un an. La fonctionnalité centrale qui permet de faire passer le code à l’état déployé en moins d’une minute est magnifique. On peut lancer ou arrêter de nouveaux nœuds en quelques secondes.

  • Partage d’un retour d’expérience d’une startup ayant utilisé Fly pendant presque un an.
  • Appréciation positive de la rapidité de déploiement du code, tout en estimant que l’entreprise reste un peu immature.
  • Mention d’un épisode où le serveur API de Fly est resté inaccessible pendant 48 heures, ainsi que de problèmes de coupures de connexion incohérentes sur le produit « db ».
  • Il est souligné que l’accès à l’API de Fly tombait souvent en panne, ce qui compliquait le déploiement de modifications sur de nouveaux services.
  • La personne dit regretter l’expérience de déploiement, mais se déclare plus satisfaite en utilisant Cloud Run de GCP.

• « À chaque exécution de flyctl, notre charmante et massive CLI fabrique un stack TCP/IP dans les airs et communique directement avec les Fly Machines grâce à une adresse IPv6 unique. »

  • Expression d’une curiosité face à l’explication selon laquelle flyctl crée à la volée un stack TCP/IP et communique directement avec les Fly Machines via une adresse IPv6 unique.

• Qu’est-ce qui empêche le paquet de handshake initial d’être retransmis vers le stack réseau ? Dans ce cas, il ne devrait pas y avoir de perte de paquets. Et aussi, quel est l’objectif de la vérification de « udp[8] = 1 » dans le filtre eBPF ?

  • Question sur le mécanisme qui empêche la retransmission du paquet de handshake initial vers le stack réseau, ainsi que sur la raison de vérifier une valeur spécifique de paquet UDP dans le filtre eBPF.

• Comment déployer une application Dockerisée quelconque sur Fly.io ? Prenez mon argent.

  • Expression d’intérêt et de motivation pour savoir comment déployer une application Dockerisée sur Fly.io.

• Pour tous les autres, je vais faire sans honte la promotion de Netmaker.

  • Partage d’une expérience satisfaisante avec Netmaker, avec mention d’un besoin personnel d’accès à un AWS VPC et l’espoir que Netmaker soit adopté plus largement.