Gately v0.6.4.1 est disponible

4 novembre 2026

Télécharger v0.6.4.1 · GitHub Release

Plusieurs instances Tailscale

• Chaque instance exécute son propre tailscaled avec son propre répertoire d'état, socket de contrôle et port WireGuard : une machine peut rejoindre plusieurs tailnets à la fois, par exemple une instance en mode noyau pour un Headscale distant et une instance en espace utilisateur pour un Headscale local.
• Un répertoire d'état existant peut être réutilisé pour conserver l'identité et l'adresse du nœud ; l'ancienne configuration à instance unique devient une instance nommée tailscale lors de la mise à jour, avec la même ligne de commande.
• Une seule instance en mode noyau peut être activée à la fois (tailscaled utilise une table de routage et une marque de pare-feu fixes) ; les conflits de répertoire d'état, de socket et de port sont signalés à l'enregistrement ou à l'activation. Modifier une instance ne redémarre qu'elle.
• Changement d'API : /api/tailscale/secrets, /restart et /logout passent à /api/tailscale/instances/{key}/… par instance, et PUT /api/tailscale/settings n'enregistre plus que les chemins des programmes ; les scripts utilisant les anciens points d'accès doivent être adaptés.

Plusieurs instances NetBird

• Même approche que Tailscale : démons, répertoires d'état, adresses de contrôle et ports WireGuard séparés ; l'ancienne configuration migre vers une instance nommée netbird.
• Les contrôles de conflit couvrent aussi les ports WireGuard (0 vaut le port par défaut 51820) et l'adresse SOCKS5 des instances en espace utilisateur (vide vaut 127.0.0.1:1080).
• Lorsqu'un service NetBird installé séparément fonctionne en mode noyau (une interface wt existe, ou le socket du système signale une interface noyau connectée), une instance en mode noyau ne fonctionne pas à côté de lui et en affiche la raison.
• Changement d'API : les instances se trouvent sous /api/netbird/instances, avec état, redémarrage, déconnexion et clé de configuration par instance.

Voir Tunnels et réseaux.

Les notifications indiquent le nom du serveur

Le titre devient [Gately · nom du serveur] Titre de l'événement et le corps gagne une ligne Serveur : les notifications de plusieurs serveurs arrivant dans la même boîte ou le même groupe se distinguent facilement. Le nom se règle dans les paramètres de notification ; vide, le nom d'hôte est utilisé, et les modèles Webhook peuvent utiliser la variable {server}. Voir Notifications.

Autres améliorations et corrections

• Les routes du routage par protocole peuvent être désactivées temporairement : les réglages sont conservés, les connexions passent aux routes plus larges ou à la cible par défaut, et la bascule n'interrompt pas les autres connexions.
• Correction DNSPod : dnsapi.cn rejette désormais les User-Agent contenant DDNS Client, ce qui faisait échouer toute synchronisation DNSPod et la validation DNS-01 des certificats.
• ipw.cn ne se résout plus : les recherches d'IP publique par défaut commencent désormais par ipv4.ddnspod.com et ipv6.ddnspod.com, et les adresses ipw.cn enregistrées sont remplacées au démarrage.
• Page des sauvegardes ouverte, une entrée d'audit d'accès sensible et une notification ne sont plus enregistrées toutes les quelques secondes ; seul le téléchargement d'un fichier de sauvegarde l'est.
• Les comptes en lecture seule ne voient plus le bouton de renommage des groupes.