Managed WireGuard FR

🇬🇧 English · 🇫🇷 Français

WireGuard géré (un tunnel par moteur)

S'applique à Hydranos 4.4.

Pour qui veut mettre chaque moteur dans un VPN sans monter les tunnels soi-même. Vous téléversez le .conf WireGuard que vous donne votre fournisseur, vous en affectez un à chaque moteur, et Hydranos monte le tunnel au démarrage, y épingle le moteur, demande un port entrant au fournisseur et résout les noms des trackers à travers lui. L'hôte garde sa propre route par défaut. Les autres sorties (Direct, Gluetun, SOCKS5), le kill switch et les requêtes du démon lui-même sont sur VPN & sortie réseau.

Ce que ça fait

• Un tunnel par moteur, nommé wg-<engine> (wg-race, wg-hoard, …). Deux moteurs peuvent utiliser deux fournisseurs, ou deux serveurs d'un même fournisseur. Un nom d'interface Linux fait au plus 15 caractères : un identifiant de moteur de 12 caractères au plus donne wg-<id> ; un identifiant plus long n'est pas refusé, son périphérique est raccourci en wg-, les 7 premiers caractères de l'identifiant, - et 4 caractères hexadécimaux dérivés de l'identifiant entier (proton-europe-1 → wg-proton-- + 4 hex), identiques à chaque démarrage.
• wg-quick n'est jamais lancé. Le .conf est analysé, et Hydranos lance ip et wg lui-même. Un AllowedIPs = 0.0.0.0/0 dans le fichier d'un fournisseur ne devient donc jamais la route par défaut de l'hôte : les routes vont dans une table de routage propre au tunnel. Table, PreUp, PostUp et les autres clés de wg-quick ne sont pas appliquées.
• Le moteur est épinglé au périphérique (bind_interface = wg-<engine>, posé par Hydranos en mémoire à chaque démarrage et jamais écrit dans le fichier, si bien qu'un moteur supplémentaire du même rôle n'en hérite pas) : écoute, uTP, connexions sortantes, annonces, DHT, LSD et webseeds passent tous par le tunnel. Un tunnel tombé signifie aucun réseau pour ce moteur, jamais la route par défaut.
• Le port entrant est demandé à la passerelle du tunnel par NAT-PMP (Proton VPN, ou tout fournisseur dont la passerelle répond au NAT-PMP), ou saisi à la main pour les fournisseurs qui l'attribuent sur leur site web.
• Les noms des trackers sont résolus par le serveur DNS = du .conf, à travers le tunnel.

Prérequis

Nécessaire	Pourquoi	Refus quand il manque
Linux	Épinglage au périphérique (SO_BINDTODEVICE) et routage par règles (policy routing)	« Le WireGuard géré nécessite Linux. Sur ce système, montez le tunnel vous-même et choisissez son interface en mode Direct. » (Managed WireGuard needs Linux. On this system, bring the tunnel up yourself and pick its interface in Direct mode.)
CAP_NET_ADMIN dans l'ensemble effectif du processus	ip link add, ip rule, wg setconf	« Le WireGuard géré nécessite la capacité NET_ADMIN, et Hydranos ne l'a pas. Sous Docker, ajoutez cap_add: [NET_ADMIN] (docker run --cap-add=NET_ADMIN) ; avec PUID/PGID, définissez aussi HYDRANOS_CAP_NET_ADMIN=1. » (Managed WireGuard needs the NET_ADMIN capability, and Hydranos does not have it. In Docker, add cap_add: [NET_ADMIN] (docker run --cap-add=NET_ADMIN); with PUID/PGID, also set HYDRANOS_CAP_NET_ADMIN=1.)
ip (iproute2) et wg (wireguard-tools) dans le PATH	Les commandes que lance Hydranos	« Le WireGuard géré nécessite les commandes ip (iproute2) et wg (wireguard-tools), et l'une d'elles n'est pas installée. » (Managed WireGuard needs the ip (iproute2) and wg (wireguard-tools) commands, and one of them is not installed.)

La vérification est faite au chargement de l'onglet Réseau, à l'affectation des tunnels et au démarrage. Là où elle échoue, la carte WireGuard, managed by Hydranos est grisée avec la phrase affichée dessus et ne peut pas être choisie, POST /api/network/mode avec "mode": "wireguard" et une affectation de tunnel répondent tous deux 409 avec la phrase (en anglais), et GET /api/network/mode porte wireguard: {"supported": false, "reason": …}.

Docker

L'image embarque iproute2 et wireguard-tools. Le conteneur a besoin de la capacité, et du sysctl si vous voulez de l'IPv6 dans le tunnel :

services:
  hydranos:
    image: ghcr.io/kheopsian/hydranos:v4.4.1
    cap_add:
      - NET_ADMIN
    sysctls:
      net.ipv6.conf.default.disable_ipv6: 0
    environment:
      PUID: "1000"
      PGID: "1000"
      HYDRANOS_CAP_NET_ADMIN: "1"   # seulement avec PUID/PGID

• cap_add: NET_ADMIN (docker run --cap-add=NET_ADMIN) accorde la capacité au conteneur. Le docker-compose.yml livré a ces lignes en commentaire.
• HYDRANOS_CAP_NET_ADMIN=1 ne compte qu'avec PUID/PGID : l'entrypoint garde alors CAP_NET_ADMIN comme capacité ambiante à travers l'abandon des privilèges, si bien que ip et wg en héritent. Si le conteneur n'a pas reçu la capacité, l'entrypoint dit CAP_NET_ADMIN not available, add --cap-add=NET_ADMIN for managed WireGuard and fwmark routing et démarre sans elle. En root (sans PUID/PGID), cap_add seul suffit.
• Le sysctl garde l'IPv6 sur le nouveau périphérique. Sans lui, Docker crée les interfaces avec l'IPv6 désactivé et le tunnel ne transporte que l'IPv4 (voir IPv6 plus bas).
• Le réseau bridge (par défaut) est l'endroit recommandé : les tunnels vivent dans l'espace de noms réseau propre au conteneur. Sous --network host, ils sont créés sur l'hôte (voir Sous --network host).
• Les ports de pairs publiés sur l'hôte (16171, 16172) ne servent pas à un moteur dans un tunnel : ses pairs arrivent par le tunnel.

Linux (bare metal)

Le service a besoin de CAP_NET_ADMIN et des deux commandes installées. L'unité livrée tourne en User=hydranos sans capacités, donc le mode y est refusé tant que vous n'en accordez pas une (par exemple AmbientCapabilities=CAP_NET_ADMIN dans un drop-in ; non testé par le mainteneur). Voir Linux (bare metal).

Mise en place

Dans Config › Paramètres avancés (default.toml) (Advanced settings (default.toml)) › Réseau (Network) :

1. Choisissez la carte WireGuard, managed by Hydranos. Le bloc WireGuard apparaît.
2. Sous Configuration files, Add a file : choisissez le .conf de votre fournisseur et cliquez sur Envoi (Upload). La réponse est « Enregistré. Choisissez-le pour un engine ci-dessous, puis enregistrez les tunnels. » (Stored. Pick it for an engine below, then save the tunnels.). Recommencez pour chaque fichier (un par moteur).
3. Pour chaque moteur (blocs intitulés local-<engine>) :
   • Sortie (Way out) : un fichier .conf, Direct (interface par défaut) (Direct (default interface)) (la route de l'hôte, en connaissance de cause), ou Non affecté (bloqué par le kill switch) (Not assigned (blocked by the kill switch)).
   • Provider : le fournisseur d'où vient le fichier. Sa note dit comment le port entrant est obtenu.
   • Port given by the provider : affiché seulement pour les fournisseurs qui attribuent le port sur leur site web (AirVPN, Private Internet Access, Windscribe).
4. Cliquez sur Save the tunnels. Affecter au moins un tunnel écrit [network] mode = "wireguard" et retire les clés des autres modes, comme le fait l'enregistrement d'un mode.
5. Redémarrez (Appliquer et redémarrer (Apply and restart) dans le bandeau). Les tunnels montent au démarrage, avant le démarrage des moteurs.

Règles vérifiées à l'enregistrement (400 avec la raison) : le fichier doit exister et s'analyser, un fournisseur doit être choisi, et un fichier par moteur (deux moteurs sur un même fichier partageraient une adresse et un port). Avertissements, enregistrés quand même : un fournisseur à port manuel sans port saisi, un fournisseur sans redirection de port (« This engine takes no incoming connection »), et un moteur laissé Non affecté (bloqué par le kill switch) (« The kill switch keeps this engine off the network until it is given one »).

La section Ports masque ensuite le port d'écoute des moteurs dont le port vient du tunnel : un fournisseur NAT-PMP (sauf si wireguard_port_forward dit manual ou off), ou un tunnel que ce processus a tenté de monter et qui porte un port (port saisi à la main compris, même si le tunnel a échoué). Ce port est affiché sur la ligne du tunnel.

Ce qui est écrit

[network]
mode = "wireguard"

[race]
wireguard_enabled = true
wireguard_config = "proton-nl-12.conf"   # un nom de fichier dans <data_dir>/wireguard
wireguard_provider = "proton"
wireguard_port = 0                       # le port du fournisseur, pour les fournisseurs manuels
wireguard_port_forward = ""              # vide : ce que fait le fournisseur

[hoard]
allow_direct = true                      # « Direct (interface par défaut) »
wireguard_config = ""
wireguard_provider = "proton"
wireguard_port = 0
wireguard_port_forward = ""

• Un moteur Non affecté (bloqué par le kill switch) n'a ni wireguard_enabled ni allow_direct.
• wireguard_port_forward remplace la méthode du fournisseur : manual, natpmp, ou off/none. L'onglet Réseau l'écrit toujours vide ; ne le définissez à la main que pour forcer autre chose.
• Un moteur supplémentaire n'hérite pas du tunnel de son rôle : affectez-lui le sien.
• Un fichier enregistré du temps où le bloc WireGuard avait une case à cocher par moteur (wireguard_enabled = false pour un moteur laissé décoché) est lu, en mode WireGuard, comme Direct.
• Enregistrer n'importe quel autre mode retire toutes les clés wireguard_*, et démonte aussitôt les tunnels en service (tunnels_down dans la réponse) : les moteurs qui y sont épinglés ne joignent plus personne jusqu'au redémarrage que demande cet enregistrement.

Les fichiers

• Stockés dans <data_dir>/wireguard (/config/wireguard sous Docker), dossier en mode 0700, chaque fichier en 0600 dès son premier octet.
• Nom : lettres, chiffres, ., - et _, 96 caractères au plus, se terminant par .conf. 64 Kio au plus.
• Analysé avant d'être stocké : il doit avoir une PrivateKey, une Address dans [Interface] et au moins un [Peer] avec une PublicKey ; sinon le téléversement est refusé avec la raison.
• Jamais renvoyé. L'API liste le nom, l'adresse, le point de terminaison (endpoint) et la clé publique du premier pair ; la clé privée reste sur le disque. La clé est passée à wg setconf sur l'entrée standard, jamais sur une ligne de commande.
• Supprimer (Remove) efface le fichier. Un moteur qui y est encore affecté ne monte pas au démarrage suivant tant qu'un autre fichier n'est pas choisi.
• <data_dir>/wireguard/managed.list enregistre les périphériques créés par Hydranos, afin qu'un tunnel qui n'est plus voulu (moteur supprimé, mode changé pendant l'arrêt) soit démonté au démarrage suivant, sans toucher à un périphérique wg-… créé par l'hôte lui-même.

Comment un tunnel monte

Au démarrage, avant qu'aucun moteur ne rejoigne le réseau :

sequenceDiagram
    participant D as démarrage de Hydranos
    participant K as noyau (ip, wg)
    participant G as passerelle du tunnel
    participant E as moteur
    D->>K: démonter les périphériques de managed.list qui ne sont plus voulus
    D->>D: vérifier Linux, NET_ADMIN, ip et wg, puis lire le .conf
    D->>K: supprimer les anciennes règles et le périphérique wg-engine
    D->>K: ip link add wg-engine type wireguard
    D->>K: wg setconf (clés et pairs sur stdin)
    D->>K: adresses, MTU (1420 si absent), lien activé
    D->>K: routes AllowedIPs dans la table propre au tunnel
    D->>K: ip rule oif wg-engine lookup cette table
    D->>K: ip rule from adresse du tunnel lookup cette table
    D->>D: serveurs DNS du .conf enregistrés pour wg-engine
    D->>D: verdicts du kill switch, moteurs bloqués ignorés
    D->>G: NAT-PMP map TCP et UDP (fournisseurs NAT-PMP, 2 essais)
    G-->>D: port externe, ou pas encore de réponse
    D->>E: démarrage, épinglé à wg-engine, annonces retenues jusqu'à un port
    loop à chaque demi-bail (bail de 60 s), 15 s après un échec
        D->>G: renouveler TCP et UDP sur le même port interne
        G-->>D: port externe, annoncé aux trackers
    end

Loading

• Routage. Chaque tunnel reçoit la table 0x48590000 plus son emplacement (slot : la position du moteur dans la liste des moteurs locaux : race 0, hoard 1, puis les moteurs supplémentaires locaux), une règle oif à la préférence 5100 plus l'emplacement, et une règle from à 6100 plus l'emplacement. Les emplacements sont recalculés à chaque démarrage : retirez un moteur du milieu de la liste et les moteurs qui le suivent descendent d'un emplacement au démarrage suivant. Les règles oif d'un tunnel sont retirées par nom de périphérique, et sa règle from remplace ce qui occupait son nouvel emplacement ; une règle from laissée à un emplacement qu'aucun tunnel ne prend plus est le cas du bug connu ci-dessous. La règle oif attrape toute socket liée au périphérique. La règle from renvoie par le tunnel ce que le noyau émet de lui-même avec l'adresse du tunnel (TCP reset, réponses ICMP), qui sinon sortirait par la route par défaut. Rien d'autre ne change dans ip route ni ip rule.
• Idempotent. Chaque démarrage retire d'abord ce qu'une exécution précédente a laissé sur ce périphérique.
• Un échec (fichier invalide, commande refusée, capacité manquante) est journalisé sous la forme wireguard: the tunnel did not come up; the engine stays pinned to it and reaches nobody (no direct fallback), le périphérique à moitié construit est retiré, et le moteur démarre épinglé à un périphérique qui n'existe pas.
• À l'arrêt, les tunnels sont démontés après l'écriture de l'état de reprise (wireguard: tunnels taken down).
• Avec HYDRANOS_ENGINE_NET=0, aucun tunnel n'est monté.

Bug connu en 4.4 : démonter un tunnel (à l'arrêt, quand un autre mode est enregistré, après un démarrage raté, ou à un démarrage où ce moteur n'a plus de tunnel) retire ses règles oif et son périphérique, pas sa règle from (préférence 6100 plus l'emplacement). Cette règle pointe vers une table laissée vide, elle ne change donc aucune route tant que cette table reste vide. Elle n'est remplacée que lorsqu'un tunnel remonte à cet emplacement avec une adresse de la même famille (et sans conflit d'adresse avec une autre interface) ; quand un tunnel monte à cet emplacement mais que la règle n'est pas remplacée à cause d'un conflit d'adresse, la table contient de nouveau des routes et l'ancienne règle envoie les paquets émis depuis l'ancienne adresse par ce tunnel. Sinon elle reste (sous --network host, dans la liste ip rule de l'hôte) jusqu'à la disparition de l'espace de noms ou de l'hôte.

Le port entrant

Fournisseur (tel que listé)	Comment le port est obtenu
AirVPN	Manuel : créez le port dans l'espace client, saisissez-le dans Port given by the provider
Mullvad	Aucun : pas de connexions entrantes
Other (NAT-PMP capable)	NAT-PMP, passerelle = la première adresse IPv4 DNS = du fichier
Other / none	Aucun (saisissez un port à la main si le fournisseur en redirige un)
Private Internet Access	Manuel (l'API de port propre à PIA n'est pas automatisée)
Proton VPN	NAT-PMP, passerelle 10.2.0.1 (utilisez un serveur marqué P2P)
Windscribe	Manuel : le port de son panneau web

• NAT-PMP redirige TCP et UDP sur le même port. Le bail demandé est de 60 s, renouvelé à la moitié de la durée accordée (au moins toutes les 5 s), et retenté toutes les 15 s après un échec. Une redirection UDP refusée ne coûte que l'uTP et est journalisée (UDP not forwarded, uTP peers cannot reach this engine: …).
• Le port est traduit, pas déplacé. Le moteur continue d'écouter sur son listen_port ; les trackers (et les pairs, dans la poignée de main d'extension) reçoivent le port externe accordé par la passerelle. Les renouvellements demandent toujours le même port interne, donc le port externe reste stable tant que la passerelle le permet.
• Les annonces sont retenues jusqu'à l'arrivée du premier port : wireguard port forward: announces held until the gateway gives a port. Si aucun n'arrive au démarrage, le journal dit wireguard: no port yet; the engine starts with its announces held, et le moteur n'annonce rien tant qu'il n'en a pas.
• Port manuel : wireguard_port devient le listen_port du moteur (le fournisseur redirige le même numéro). Le port 0 signifie aucune connexion entrante.
• GET /api/port-forward signale un tel moteur avec forward.by = "wireguard". Le routeur de la maison n'est jamais sollicité pour le port d'un moteur dans un tunnel, et les routes de changement de port d'écoute à chaud répondent 409 pour un moteur qui suit le port de son tunnel.

Le DNS dans le tunnel

Les adresses DNS = du .conf sont enregistrées pour le périphérique avant le démarrage du moteur. Les annonces HTTP, les annonces UDP, les webseeds et l'amorçage DHT du moteur y résolvent les noms : A et AAAA en UDP, depuis une socket épinglée au tunnel, 2 s par essai et 2 essais par serveur, réponses gardées en cache 5 à 60 s. Si le serveur du tunnel ne répond pas, la résolution échoue : elle ne se rabat jamais sur l'hôte.

Un .conf sans DNS = fonctionne quand même, mais les noms des trackers sont alors résolus par le résolveur de l'hôte : l'essaim ne voit que le tunnel, le fournisseur DNS de l'hôte voit à quels trackers parle le moteur. C'est journalisé (wireguard: the file has no DNS line …), affiché sous la forme noms des trackers résolus par le DNS de l'hôte (fuite des noms) (tracker names resolved by the host's DNS (name leak)) sur la ligne du tunnel, et listé comme une faille par le kill switch. Correctif : ajoutez une ligne DNS = avec le résolveur du fournisseur.

Les requêtes propres au démon utilisent aussi le DNS du tunnel quand [daemon] egress emprunte un tunnel (voir plus bas).

Kill switch et requêtes du démon

En mode WireGuard, le kill switch est armé par défaut, et seuls les trois choix de Sortie comptent :

Sortie	Verdict
un .conf	couvert : son tunnel (un tunnel tombé signifie aucun réseau)
Direct (interface par défaut)	direct en connaissance de cause
Non affecté (bloqué par le kill switch)	BLOQUÉ : ni écoute, ni connexion sortante, ni annonce, ni DHT, ni LSD

Une interface saisie pour un moteur dans un autre mode n'est pas un tunnel ici. Avec [daemon] egress laissé sur auto, les requêtes propres au démon (listes, vérification de mise à jour, webhooks, URL de .torrent) passent par le tunnel de race, sinon par celui du premier moteur dans un tunnel ; sans tunnel à emprunter et avec le kill switch armé, elles sont refusées. hydranos-update trouve le même périphérique. Détails : VPN & sortie réseau.

État en direct

Le bloc WireGuard affiche Live tunnels, une ligne par tunnel (local-<engine>, périphérique, fournisseur) :

Affiché	Signification
carrying traffic	Dernière poignée de main il y a moins de 180 s
no recent handshake	Périphérique présent, pas de poignée de main depuis 180 s ou plus
coupé : cet engine ne joint personne (down: this engine reaches nobody)	Périphérique non créé, ou disparu
port N / no incoming port	Le port redirigé, s'il y en a un
handshake … ago, endpoint	Tiré de wg show <device> latest-handshakes et endpoints
IPv4 only	L'IPv6 a été abandonné (survolez pour la raison)
DNS … par le tunnel (DNS … through the tunnel) / noms des trackers résolus par le DNS de l'hôte (fuite des noms)	Où les noms sont résolus
last attempt failed	La dernière mise en place ou demande de port a échoué (survolez pour l'erreur)

API

Route	Rôle
GET /api/network/wireguard	configs (sans clés), directory, engines (par moteur : assignment = tunnel/direct/none, config_file, provider, manual_port, port_forward, device), providers, supported, unsupported_reason, tunnels (null quand il n'y en a aucun ; chacun avec created, present, up, handshake_age_seconds, endpoint, forwarded_port, degraded, last_error, dns, dns_leak)
POST /api/network/wireguard/configs	Stocker un fichier : champ multipart file, ou corps brut avec ?name=provider.conf. Accepté même là où les tunnels ne peuvent pas être montés
DELETE /api/network/wireguard/configs/:name	Supprimer un fichier ; 404 s'il n'existe pas
POST /api/network/wireguard/engines	{"engines":[{"engine_id","assignment","config_file","provider","manual_port","port_forward"}]} ; répond restart_required, warnings, note. 409 avec la raison sur un hôte qui ne peut pas monter de tunnels

Toutes exigent la clé API, comme le reste de l'API REST (API REST).

IPv6

Un .conf double pile reçoit les deux familles. Si l'adresse ou la route IPv6 ne peut pas être ajoutée (Docker sans le sysctl ci-dessus), le tunnel continue en IPv4 seulement et dit pourquoi : IPv6 is disabled on new interfaces here; the tunnel carries IPv4 only. To keep both, start the container with --sysctl net.ipv6.conf.default.disable_ipv6=0 (or set that sysctl on the host under --network host).

Sous --network host

Les tunnels sont alors créés dans l'espace de noms réseau de l'hôte, à côté des interfaces de l'hôte. Seuls les périphériques enregistrés dans managed.list sont démontés quand ils ne sont plus voulus, et les tables de routage qu'utilise Hydranos sont loin de celle de wg-quick par défaut (51820), donc un tunnel que l'hôte fait tourner lui-même n'est pas touché (ne nommez pas l'un des vôtres wg-<engine>). Si une autre interface détient déjà l'adresse du tunnel (un fournisseur qui donne la même adresse à tous ses clients, avec l'hôte qui fait tourner son propre tunnel), la règle from n'est pas posée, et le journal avertit : les réponses propres au noyau sur cette adresse peuvent sortir par la route par défaut. Faites tourner Hydranos dans son propre espace de noms réseau (un réseau bridge) pour fermer ce trou.

Pas sous Windows ni macOS

Le WireGuard géré est réservé à Linux. Sous Windows et macOS, la carte est grisée avec « Le WireGuard géré nécessite Linux. … » (Managed WireGuard needs Linux. …). Faites plutôt tourner le client VPN pour tout le système (voir Windows et macOS sur VPN & sortie réseau et Windows).

Dépannage

Symptôme	Cause	Correctif
La carte est grisée	L'un des trois prérequis manque ; la carte le nomme	Ajoutez cap_add: NET_ADMIN (et HYDRANOS_CAP_NET_ADMIN=1 avec PUID/PGID), installez iproute2 et wireguard-tools, ou utilisez Linux
coupé : cet engine ne joint personne après un redémarrage	Le tunnel n'est pas monté : voyez wireguard: the tunnel did not come up … et son erreur dans le journal, ou last attempt failed	Corrigez la cause (fichier supprimé, capacité perdue), puis redémarrez. Le moteur ne se rabat jamais sur la route par défaut
no recent handshake	Le serveur du fournisseur ne répond pas : clés erronées ou révoquées, serveur arrêté, UDP vers l'endpoint bloqué	Téléchargez un .conf neuf, essayez un autre serveur
Tunnel monté, no incoming port	Fournisseur sans redirection (Mullvad, Other / none), port manuel non saisi, ou pas de réponse NAT-PMP (Proton : un serveur non marqué P2P)	Choisissez un serveur P2P, ou saisissez le port du fournisseur
Les torrents n'annoncent jamais	Les annonces sont retenues jusqu'à ce que la passerelle donne un port	Comme ci-dessus ; ou définissez wireguard_port_forward = "off" pour ce moteur afin qu'il cesse d'attendre
Un moteur est BLOQUÉ	Sortie laissée sur Non affecté (bloqué par le kill switch)	Donnez-lui un fichier ou Direct (interface par défaut), enregistrez, redémarrez
noms des trackers résolus par le DNS de l'hôte (fuite des noms)	Le .conf n'a pas de ligne DNS =	Ajoutez le serveur DNS du fournisseur au fichier et téléversez-le de nouveau
IPv4 only	IPv6 désactivé sur les nouvelles interfaces (Docker)	Ajoutez le sysctl net.ipv6.conf.default.disable_ipv6: 0
Les requêtes du démon sont refusées	egress = auto, kill switch armé, et aucun moteur n'a de tunnel à prêter	Affectez un tunnel à race, ou définissez [daemon] egress (voir VPN & sortie réseau)

Plus de symptômes réseau : Dépannage.