Networking Modes FR

🇬🇧 English · 🇫🇷 Français

Réseau : ports, redirection de port et onglet Réseau

S'applique à Hydranos 4.4.

Cette page s'adresse à vous si vous voulez que les pairs puissent joindre vos moteurs, ou si vous avez ouvert Config › Paramètres avancés (default.toml) (Advanced settings (default.toml)) › Réseau (Network) et voulez savoir ce que font vraiment ces réglages. À la fin, vous saurez ce que fait chacun des cinq modes de l'onglet Réseau, quels ports ouvrir, ce que fait la redirection de port automatique, comment déplacer un port sans redémarrer, comment se comportent IPv6, la découverte de pairs locaux et le filtre IP, et comment vérifier ce qui sort vraiment. Le modèle de fuite, le kill switch et les requêtes propres du démon sont décrits sur VPN & sortie réseau ; les tunnels qu'Hydranos monte lui-même sont sur WireGuard géré.

Les cinq modes

Le sous-onglet Réseau (Network), premier onglet de Paramètres avancés (default.toml), affiche cinq cartes de mode. Vous en choisissez une, remplissez ses champs et cliquez sur Enregistrer ce mode (Save this mode). Les cinq fonctionnent en 4.4.

Carte de mode (libellé exact)	Ce qu'elle fait en 4.4
Direct	Pas de proxy. Chaque moteur sort par l'interface que vous lui choisissez dans Interface per engine (bind_interface), ou par la route par défaut de l'hôte si vous n'en choisissez aucune. Sous Linux, l'interface épingle toutes les sockets du moteur : écoute, uTP, connexions sortantes vers les pairs, annonces HTTP et UDP, DHT, LSD et webseeds. Hors Linux, le champ est masqué (voir L'épinglage d'interface est réservé à Linux ci-dessous). Le kill switch est désarmé dans ce mode, sauf si [daemon] kill_switch = true.
WireGuard, managed by Hydranos	Hydranos monte un tunnel WireGuard par moteur à partir d'un .conf de fournisseur que vous envoyez, y épingle le moteur, résout les noms des trackers par le DNS du tunnel et, pour les fournisseurs qui le proposent, demande un port entrant à la passerelle du tunnel par NAT-PMP. Linux uniquement, avec la capacité NET_ADMIN et les commandes ip et wg. Sur tout autre hôte, la carte est grisée et affiche la raison. Mise en place : WireGuard géré.
Gluetun	Pour Hydranos qui tourne dans le réseau de gluetun. Avec Prendre le port d'écoute depuis gluetun (Take the listen port from gluetun) coché, un moteur lit le port redirigé de gluetun, écoute dessus et le suit quand il change (voir Gluetun ci-dessous).
Proxy SOCKS5 (SOCKS5 proxy)	Les connexions aux pairs, les annonces HTTP, les téléchargements de magnets et de webseeds de tous les moteurs passent par le proxy (en socks5h://, si bien que le proxy résout aussi les noms des trackers). Si le proxy refuse une connexion, Hydranos l'abandonne et ne la retente jamais en direct. L'UDP ne peut pas passer par le proxy : les trackers UDP ne sont pas annoncés, la DHT et LSD sont coupés et l'uTP sortant est coupé. PEX reste actif. Les pairs entrants joignent toujours le port d'écoute propre de l'hôte.
Proxy SOCKS5 + relais PROXY-v2 (SOCKS5 + PROXY-v2 relay)	Comme Proxy SOCKS5, plus une seconde écoute par moteur qui accepte les pairs que votre relais transmet avec leur vraie adresse dans un en-tête PROXY-v2 (voir Relais PROXY-v2 ci-dessous).

Dans tous les modes sauf Direct, le kill switch est armé par défaut. Le moteur qu'il tient alors hors du réseau dépend du mode. En modes Proxy SOCKS5 et Proxy SOCKS5 + relais PROXY-v2 : un moteur sans interface, sans proxy et sans allow_direct. En mode WireGuard, managed by Hydranos : un moteur qui n'a ni tunnel ni Direct (interface par défaut) (Direct (default interface)) (ou allow_direct) ; une interface saisie à la main ne compte pas dans ce mode. En mode Gluetun : seulement un moteur épinglé à une autre interface que celle de gluetun ; un moteur sans interface compte comme couvert par le pare-feu de gluetun. Un moteur bloqué n'a ni écoute, ni connexion sortante, ni annonce, ni DHT, ni LSD. Il ne se rabat pas sur la route de l'hôte. La section Kill switch et requêtes du démon (Kill switch and the daemon's own requests) de l'onglet et le journal de démarrage (kill switch: …) indiquent pour chaque moteur s'il est couvert, en direct assumé ou bloqué. Détails sur VPN & sortie réseau.

Bug connu en 4.4 : la carte Proxy SOCKS5 dit « Personne ne peut vous joindre depuis l'extérieur » (Nobody can connect to you from outside), et sa section de réglages dit que la DHT « si elle est activée, montre toujours l'adresse de cet hôte aux nœuds DHT » (if on, still shows this host's address to DHT nodes). Les deux sont faux. Les moteurs coupent la DHT derrière le proxy, et les pairs entrants joignent le port d'écoute propre de l'hôte si ce port est ouvert ou redirigé. Pour éviter des pairs entrants sur l'adresse de l'hôte, ne redirigez pas et ne publiez pas les ports d'écoute.

Si vous enregistrez Proxy SOCKS5 + relais PROXY-v2 sans Hôte du proxy (Proxy host), l'enregistrement passe avec l'avertissement « Aucun proxy SOCKS5 n'est défini : les pairs entrants arrivent par le relais, mais les connexions sortantes et les annonces partent en direct. » (No SOCKS5 proxy is set: incoming peers come through the relay, but outgoing connections and announces leave directly.) Avec le kill switch armé (la valeur par défaut dans ce mode), un moteur sans interface est au contraire tenu hors du réseau, et un second avertissement le signale.

Comment la page choisit la carte active

Le mode est stocké dans default.toml :

[network]
mode = "socks5"   # direct, wireguard, gluetun, socks5 or proxy_v2

GET /api/network/mode met cette carte en surbrillance. Un fichier sans la clé (écrit avant la 4.4) ou avec une valeur inconnue reçoit un mode déduit des clés : Gluetun si gluetun_port_forward = true dans [race] ou [hoard], sinon Proxy SOCKS5 + relais PROXY-v2 si listen_port_proxy_v2 n'est pas à 0 dans l'une ou l'autre, sinon Proxy SOCKS5 si l'une ou l'autre a un socks5_outbound_host, sinon Direct. La déduction ne donne jamais WireGuard, managed by Hydranos : enregistrez donc une fois depuis l'onglet après une mise à jour.

L'onglet lit la configuration en mémoire du démon. Cette copie est chargée au démarrage et remplacée seulement quand l'interface ou l'API écrit le fichier. Une modification de default.toml à la main n'apparaît qu'après un redémarrage, ou après qu'une modification faite dans l'interface ou par l'API a réécrit le fichier (cela recharge tout le fichier, modifications manuelles comprises).

flowchart LR
    UI["Onglet Réseau<br/>Enregistrer ce mode"] -->|"POST /api/network/mode"| F["default.toml<br/>[network] mode + les clés de ce mode<br/>clés des autres modes supprimées"]
    F -->|"lu au démarrage de chaque moteur"| E["Moteurs : listen_port, bind_interface,<br/>enable_ipv6, SOCKS5, proxy d'annonce,<br/>écoute PROXY-v2, suivi gluetun,<br/>tunnel WireGuard, verdict du kill switch"]
    F -->|"GET /api/network/mode"| C["Carte en surbrillance<br/>= [network] mode"]

Loading

Enregistrer et quitter un mode

• Enregistrer ce mode n'envoie que les champs du mode choisi. Le démon écrit [network] mode et les clés de ce mode, puis supprime les clés des autres modes de [race], [hoard] et du bloc de chaque moteur supplémentaire local : socks5_outbound_*, announce_proxy et announce_ip sauf si le mode est SOCKS5 ou PROXY-v2 ; listen_port_proxy_v2, listen_addr_proxy_v2 et proxy_v2_trusted_sources sauf si c'est PROXY-v2 ; gluetun_* sauf si c'est Gluetun ; wireguard_enabled, wireguard_config, wireguard_provider, wireguard_port et wireguard_port_forward sauf si c'est WireGuard. Revenir à Direct se résume à : cliquer sur Direct, enregistrer.
• Un client qui n'envoie que certains champs (tout autre que l'onglet) garde les autres à leurs valeurs actuelles. Un mode absent signifie le mode en vigueur ; un mode inconnu est refusé (400 unknown network mode).
• Refus, avant toute écriture : un port race ou hoard hors de 1–65535 (400) ; race et hoard sur un même port (409 race and hoard cannot share a listen port) ; le port d'un moteur supplémentaire hors de 1–65535 (400) ; SOCKS5 sans hôte (400 SOCKS5 mode needs the proxy host) ; un port SOCKS5 hors de 1–65535 (400 the SOCKS5 port must be between 1 and 65535) ; dans les deux modes SOCKS5, un Proxy d'annonce (Announce proxy) qui n'est pas une URL de proxy ou une Adresse annoncée aux trackers (Address announced to trackers) qui n'est pas une IP (400) ; PROXY-v2 sans aucun port PROXY-v2, avec un port hors de 0–65535, avec un port égal à un port d'écoute, ou avec race et hoard sur le même (400 race and hoard cannot share a PROXY-v2 port) ; une source de confiance qui n'est pas une IP (400) ; WireGuard, managed by Hydranos sur un hôte qui ne peut pas monter de tunnel (409, avec la raison) ; tout bind_interface hors Linux (400). Un port SOCKS5 à 0 est enregistré comme 1080.
• La réponse est {"status":"ok","mode":…,"restart_required":…,"warnings":[…],"tunnels_down":…}. restart_required ne vaut true que lorsqu'un moteur en cours a été démarré avec des clés réseau différentes, ou quand l'ensemble des moteurs bloqués par le kill switch change. La page affiche alors Enregistré. Les moteurs doivent redémarrer pour appliquer les nouveaux réglages réseau. (Saved. The engines need a restart to apply the new network settings.) avec un bouton Appliquer et redémarrer (Apply & restart), ou Enregistré et appliqué, pas de redémarrage. (Saved and applied, no restart needed.) Appliquer et redémarrer arrête Hydranos proprement et quitte, pour que la politique de redémarrage de votre conteneur ou votre gestionnaire de services le relance (voir Exploiter Hydranos).
• Les avertissements s'affichent à l'enregistrement et à chaque ouverture de l'onglet. Ils couvrent les trackers UDP non annoncés derrière un proxy, la DHT coupée derrière SOCKS5 (pour un moteur dont la DHT est activée), un hôte qui ne peut pas faire tourner WireGuard (dans ce mode), le mode PROXY-v2 sans proxy SOCKS5, les moteurs tenus hors du réseau par le kill switch et, hors des deux modes SOCKS5, TYPHON_ANNOUNCE_PROXY défini dans l'environnement (cette variable est listée sous Défini dans l'environnement (Set in the environment) dans tous les modes).
• Quitter WireGuard, managed by Hydranos démonte les tunnels immédiatement (tunnels_down les compte). Les moteurs épinglés dessus ne joignent plus personne jusqu'au redémarrage ; ils ne se rabattent jamais sur la route de l'hôte.
• GET /api/network/mode renvoie le mot de passe SOCKS5 et la clé API de gluetun sous la forme ******** (de même que GET /api/network/egress pour le mot de passe de [proxy]) ; un enregistrement qui renvoie le masque garde la valeur enregistrée. L'URL du Proxy d'annonce (Announce proxy) n'est pas masquée : un user:pass qu'elle contient est renvoyé en clair par GET /api/settings.

Gluetun

Champs : Prendre le port d'écoute depuis gluetun, Serveur de contrôle gluetun (Gluetun control server) (vide signifie http://127.0.0.1:8000), Clé d'API gluetun (Gluetun API key), Moteur qui prend le port (Engine that takes the port) (Hoard ou Race). Un fournisseur redirige un seul port : seul ce moteur reçoit gluetun_port_forward = true ; l'autre est écrit à false et garde son propre port. Les moteurs supplémentaires n'en héritent jamais.

• Le moteur interroge GET /v1/portforward (ou /v1/openvpn/portforwarded quand la première répond 404), avec la clé dans X-API-Key. Il interroge toutes les 10 s jusqu'à obtenir un port, puis toutes les 60 s. Un 401 ou 403 est journalisé sous la forme … set the gluetun API key, with GET /v1/portforward allowed.
• Ses annonces sont retenues jusqu'à ce que son écoute tienne le port de gluetun. Sans réponse de gluetun, ce moteur n'annonce rien. Un port qui ne peut pas être lié les garde retenues.
• Un nouveau port est appliqué à chaud (TCP et uTP, les annonces suivent). Il n'est pas écrit dans default.toml.
• Dans ce mode, Hydranos ne demande rien au routeur de la maison, et les routes de changement de port d'écoute à chaud refusent ce moteur (409). Le kill switch compte un moteur sans interface comme couvert par le pare-feu de gluetun. Hydranos ne vérifie pas qu'il tourne vraiment dans le réseau de gluetun.

Relais PROXY-v2

Champs sous Relais entrant (Incoming relay) : Port PROXY-v2 Race (Race PROXY-v2 port) et Port PROXY-v2 Hoard (Hoard PROXY-v2 port) (0 = pas d'écoute PROXY-v2 pour ce moteur), Adresse d'écoute (Bind address) (vide = toutes les adresses) et Sources de confiance (Trusted sources) (séparées par des virgules). Les adresses de boucle locale et privées sont toujours de confiance. Un relais sur une adresse publique doit être listé, sinon chaque pair qu'il transmet est refusé. L'écoute est épinglée à l'interface du moteur. Un moteur supplémentaire n'hérite pas du port PROXY-v2 de son rôle : indiquez listen_port_proxy_v2 dans son propre bloc.

La section Proxy SOCKS5 des deux modes proxy contient aussi Proxy d'annonce (facultatif) (Announce proxy (optional)) (announce_proxy : une URL de proxy pour les annonces, les webseeds et les magnets, utilisée à la place du proxy SOCKS5) et Adresse annoncée aux trackers (facultatif) (Address announced to trackers (optional)) (announce_ip, envoyée comme ip=). Les deux sont supprimées quand vous enregistrez un autre mode.

Ports d'écoute

Chaque moteur a un port d'écoute, utilisé à la fois pour :

• TCP : l'écoute des pairs, et
• UDP : la socket uTP, sur le même numéro de port (IPv4 uniquement).

Moteur	Clé	Valeur par défaut dans le default.toml livré
race	[race] listen_port	16171
hoard	[hoard] listen_port	16172
moteur supplémentaire	listen_port dans son bloc engine (tableau de tables TOML)	aucune : vous le choisissez en ajoutant le moteur

Les ports doivent différer d'un moteur à l'autre. L'onglet Réseau refuse le même port pour race et hoard (HTTP 409 "race and hoard cannot share a listen port") et tout port hors de 1–65535 (HTTP 400), moteurs supplémentaires compris. Il ne compare pas les ports des moteurs supplémentaires avec ceux de race et hoard ; + Add an engine dans l'onglet Nodes (POST /api/engines) le fait, et refuse un port déjà pris (409).

Une section sans listen_port reçoit 16171 (rôle race) ou 16172 (rôle hoard). Un moteur dont le port est déjà pris par un autre moteur (un moteur supplémentaire qui hérite du port de son rôle, par exemple) reçoit au démarrage le prochain port libre, avec l'avertissement listen_port missing or taken: using a free one. Ce port n'est pas écrit dans le fichier : définissez donc listen_port explicitement pour chaque moteur supplémentaire. Voir Config : moteurs & drain race.

La section Ports de l'onglet Réseau contient Port d'écoute Race (Race listen port), Port d'écoute Hoard (Hoard listen port), un Port d'écoute de {id} ({id} listen port) par moteur supplémentaire, et Écouter aussi en IPv6 (Listen over IPv6 too). Une modification enregistrée là demande un redémarrage ; pour déplacer un port à chaud, utilisez les routes de Changer le port sans redémarrer ci-dessous. En mode WireGuard, managed by Hydranos, un moteur dont le port vient de son fournisseur n'est pas listé : son port est affiché avec son tunnel.

Ouvrez ces ports sur votre pare-feu, en TCP et en UDP. Sous Docker, publiez-les sur le conteneur (le compose de référence de la page Docker publie 16171/tcp, 16171/udp, 16172/tcp, 16172/udp). Le tableau complet des ports, port web 8199 compris, est sur Installation & premier démarrage.

Les ports publiés et redirigés doivent être égaux au listen_port du moteur. Les trackers reçoivent le port sur lequel le moteur écoute : utilisez donc le même numéro des deux côtés (16172:16172, jamais 47000:16172). Quand vous changez listen_port, alignez la redirection du routeur et les ports publiés : un port publié ou redirigé vers un numéro sur lequel aucun moteur n'écoute n'atteint rien. La seule exception est un tunnel WireGuard géré dont la passerelle accorde un autre port externe par NAT-PMP : le moteur continue d'écouter sur son listen_port dans le tunnel et annonce le port externe (WireGuard géré). Derrière un conteneur VPN (Docker network_mode: "service:gluetun", type de réseau Unraid Container), les lignes de ports vont sur le conteneur VPN, pas sur hydranos ; la recette gluetun est sur VPN & sortie réseau.

flowchart LR
    P["Pair distant"] --> R["Routeur de la maison"]
    M["Redirecteur vers le routeur dans hydranos<br/>un par moteur, NAT-PMP puis UPnP"] -.->|"demande une redirection TCP et UDP<br/>bail d'1 heure, renouvelé toutes les 30 min"| R
    R -->|"16171 TCP et UDP"| RL["race : écoute TCP<br/>et socket uTP"]
    R -->|"16172 TCP et UDP"| HL["hoard : écoute TCP<br/>et socket uTP"]
    P --> G["Passerelle du tunnel WireGuard"]
    F["Suivi du port du tunnel dans hydranos<br/>par moteur tunnelisé dont le fournisseur redirige un port, NAT-PMP seulement"] -.->|"demande une redirection TCP et UDP<br/>bail de 60 s, renouvelé à mi-bail"| G
    G -->|"port accordé par le fournisseur"| TL["moteur tunnelisé : écoute TCP<br/>et socket uTP sur son listen_port"]
    Relay["Votre relais PROXY-v2"] -->|"port PROXY-v2"| PV["Écoute PROXY-v2<br/>(mode SOCKS5 + PROXY-v2)"]

Loading

Redirection de port automatique

La clé de premier niveau auto_port_forward (absente du default.toml livré ; valeur par défaut true) demande à votre routeur de la maison de rediriger le port d'écoute de chaque moteur. Au démarrage, un redirecteur tourne par moteur qui sort par le réseau du routeur de la maison :

1. NAT-PMP vers la passerelle par défaut lue dans /proc/net/route (Linux uniquement ; ignoré sous Windows et macOS). Quatre tentatives de 3 s chacune.
2. Sinon UPnP IGD : découverte SSDP sur 239.255.255.250:1900, puis AddPortMapping sur un service WANIPConnection (v2 ou v1) ou WANPPPConnection, avec la description Hydranos.

Ensuite :

• TCP et UDP sont tous deux redirigés, sur le même port. Un refus côté UDP n'annule pas le TCP : il est journalisé sous la forme UDP not forwarded, uTP and DHT peers cannot reach this engine: … avec forward UDP <port> by hand.
• Il demande le même port externe que le port interne et un bail d'une heure, et le renouvelle toutes les 30 minutes (la moitié du bail demandé, quel que soit le bail accordé par le routeur).
• Si les deux protocoles échouent, il journalise au niveau INFO no automatic port forward; if you are not reachable, forward <port> (TCP and UDP) by hand et réessaie 15 minutes plus tard.
• En cas de succès, il journalise port forwarded by NAT-PMP ou port forwarded by UPnP. Le résultat par moteur figure aussi dans GET /api/port-forward (voir Vérifier la joignabilité).
• Il suit le port en cours du moteur : après un changement de port à chaud (ci-dessous), le nouveau port est redirigé en 5 secondes environ, et l'ancien bail expire simplement.
• Si un routeur NAT-PMP accorde un port externe différent, ce port apparaît dans /api/port-forward (external_port), mais les trackers reçoivent toujours le port interne.
• Il ne change jamais le port d'écoute.

Un moteur tenu hors du réseau par le kill switch n'obtient pas de redirection non plus, sans bruit : aucune ligne de journal, et sa ligne de /api/port-forward reste à forward.by: "pending" (ou "gluetun" s'il porte gluetun_port_forward = true). Pour les autres, aucune redirection n'est demandée au routeur de la maison (le journal dit port mapping: no UPnP/NAT-PMP request to the home router: <why>) pour un moteur :

• avec un tunnel WireGuard géré (le port d'un fournisseur NAT-PMP est demandé à la passerelle du tunnel ; pour un fournisseur manuel ou sans redirection, rien n'est demandé ; voir WireGuard géré) ;
• en mode Gluetun (le port vient du fournisseur VPN) ;
• derrière un proxy SOCKS5 ;
• épinglé à une autre interface que celle qui porte la route par défaut.

Une redirection sur le routeur de la maison publierait l'adresse de l'hôte pour un moteur qui ne sort pas par là.

Désactivez-la quand vous redirigez à la main :

# top of default.toml, outside any [section]
auto_port_forward = false

Avec le réseau bridge par défaut de Docker, le routeur est en général hors de portée de NAT-PMP et d'UPnP : attendez-vous à la ligne de journal « forward by hand » toutes les 15 minutes ; redirigez les ports sur le routeur (voir Docker).

En mode Gluetun, le redirecteur vers le routeur de la maison se tient à l'écart de lui-même. En mode WireGuard, managed by Hydranos, il se tient à l'écart de tout moteur tunnelisé, mais un moteur réglé sur Direct (interface par défaut) est toujours redirigé sur le routeur de la maison. Dans les deux modes, le port du VPN est suivi quand il y en a un à suivre (un tunnel NAT-PMP, ou gluetun_port_forward = true ; voir ci-dessus et WireGuard géré). Si vous faites tourner Hydranos dans un autre VPN qui est la route par défaut du processus alors que l'onglet indique Direct, mettez auto_port_forward = false. Laissée active, la requête NAT-PMP part côté VPN, et tout port différent que le fournisseur accorde ainsi n'est jamais annoncé. Réglez plutôt listen_port sur le port du fournisseur.

Changer le port sans redémarrer

Trois routes déplacent à chaud le port d'écoute d'un moteur et le conservent, sans perdre les torrents ni les pairs connectés :

Méthode et chemin	Moteur
POST /api/race/listen-port	race
POST /api/hoard/listen-port	hoard
POST /api/engines/:id/listen-port	n'importe quel moteur, par identifiant (identifiant inconnu : 404)

• Corps : JSON {"port": <1-65535>}. Le corps est analysé comme du JSON quel que soit le Content-Type.
• Authentification : comme toute route de l'API : en-tête X-Api-Key: YOUR_API_KEY, ou ?apikey=YOUR_API_KEY dans l'URL, ou un cookie de session connectée. Sans cela : 401.
• Réponses (envoyées une fois le nouveau port lié) : 200 {"ok":true,"engine":"hoard","port":51413,"previous_port":16172,"persisted":true} ; 400 pour un port absent ou à 0, un port au-dessus de 65535 ou un corps mal formé ; 409 quand le port est le port d'écoute d'un autre moteur, quand il ne peut pas être lié (le moteur continue d'écouter sur son ancien port, indiqué dans la réponse, et rien n'est écrit), ou quand le moteur prend son port de gluetun ou de son tunnel WireGuard ; 503 quand le moteur n'est pas sur le réseau (tenu à l'écart par le kill switch, ou HYDRANOS_ENGINE_NET=0).

curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
  -d '{"port": 51413}' http://127.0.0.1:8199/api/hoard/listen-port
# {"ok":true,"engine":"hoard","port":51413,"previous_port":16172,"persisted":true}

Ce qui change : les nouvelles sockets TCP (et celle sur [::] quand enable_ipv6 = true) et la nouvelle socket uTP sont liées d'abord, puis les anciennes sont libérées. Si l'une d'elles ne peut pas être liée, rien ne bouge. Dès lors, les annonces envoient le nouveau port, les pairs le reçoivent dans la poignée de main d'extension, et le redirecteur vers le routeur de la maison le redirige. Le port est écrit dans le listen_port du moteur (persisted: false signifie que le déplacement a réussi mais que le fichier n'a pas pu être écrit ; le journal dit listen port moved but not saved). Le journal affiche [peer] hot rebind requested -> port 51413. GET /api/port-forward et le panneau Réseau de l'en-tête affichent le port que le moteur tient maintenant.

Alignez la redirection du routeur et les ports publiés (voir Ports d'écoute ci-dessus). Le port tournant d'un fournisseur VPN est suivi pour vous en mode Gluetun et par un tunnel WireGuard géré ; pour toute autre configuration, appelez cette route avec le nouveau port.

IPv6

enable_ipv6 (dans [race] et [hoard], false par défaut dans le fichier livré) ajoute une écoute TCP sur [::]:<listen_port> à côté de l'écoute IPv4 et permet au moteur d'utiliser les pairs IPv6 appris par PEX. L'uTP reste en IPv4 uniquement. Écouter aussi en IPv6 dans l'onglet Réseau écrit la même valeur dans [race] et [hoard] seulement (pas dans les blocs des moteurs supplémentaires), et affiche la valeur de race.

Avec enable_ipv6 = true, la famille d'adresses de chaque annonce se règle par hôte de tracker. Dans l'onglet Trackers, le réglage Announce d'un tracker propose auto, v4 only et v6 only (stocké dans [announce_ip_modes], appliqué immédiatement, sans redémarrage). auto est la valeur par défaut et envoie une annonce en IPv4 et une en IPv6 avec le même peer id. Pour le modifier : Trackers & annonces.

Avec enable_ipv6 = false, toutes les annonces de ce moteur partent en IPv4 uniquement, quel que soit le réglage du tracker (v6 only compris), si bien qu'aucun tracker ne liste une adresse IPv6 sur laquelle le moteur n'écoute pas.

Découverte de pairs locaux (LSD)

enable_lsd (par moteur ; absent signifie activé pour le rôle race, désactivé sinon ; le fichier livré a true dans [race] et false dans [hoard]) active la découverte de services locaux (Local Service Discovery, BEP 14). Il se règle dans Paramètres avancés (default.toml), pas dans l'onglet Réseau, et s'applique au prochain démarrage du moteur.

• Le moteur émet en multicast sur 239.192.152.143:6771 et [ff15::efc0:988f]:6771 : une tournée par minute, au plus 60 messages de 20 info hashes chacun, chaque torrent au plus une fois toutes les 5 minutes. Seuls les torrents en téléchargement ou qui ont des pairs sont annoncés.
• Les pairs du réseau local entendus en train d'annoncer un hash que le moteur détient vont dans la file de connexions de ce moteur, comme les pairs des trackers.
• Jamais pour un torrent privé, dans un sens comme dans l'autre.
• Coupé derrière un proxy SOCKS5, et sur un moteur tenu hors du réseau. Dans une interface ou un tunnel WireGuard, il est épinglé à ce périphérique et n'atteint jamais le réseau local de l'hôte. S'il ne peut pas rejoindre le groupe à cet endroit, LSD reste coupé, avec une ligne de journal.

L'épinglage d'interface est réservé à Linux

bind_interface épingle les sockets avec SO_BINDTODEVICE, que seul Linux possède. Sous Windows et macOS, depuis la 4.4 :

• l'onglet Réseau masque les champs d'interface et affiche la raison ;
• POST /api/network/mode et POST /api/engines refusent un bind_interface non vide (400, bind_interface is Linux-only: this platform cannot pin every socket of an engine to an interface (TCP peers would leave by the default route). Run the VPN client system-wide instead) ;
• un moteur dont le fichier contient encore la clé reste hors du réseau (ni écoute, ni connexion sortante, ni annonce, ni DHT, ni LSD, ni uTP), avec cet avertissement au démarrage.

Sous Linux, une interface absente au démarrage signifie ni écoute ni uTP pour ce moteur (uTP disabled rather than leak the default route) jusqu'à ce qu'un redémarrage la trouve. Ce que l'épinglage couvre d'autre est décrit sur VPN & sortie réseau.

Filtre IP

Config › Filtre IP (IP filter) bloque des adresses dans les deux sens : aucune connexion n'est acceptée depuis elles ni ouverte vers elles, et un pair déjà connecté est déconnecté dès qu'il devient bloqué. Le filtre s'applique à tous les moteurs.

Contrôle	Signification
Utiliser des listes de blocage (Use block lists)	active ou désactive les listes (désactivées par défaut)
Listes (Lists)	une source par ligne : un chemin absolu commençant par / sur cette machine, ou une URL http(s)://. Formats : PeerGuardian P2P, eMule .dat (les lignes de niveau 128 ou plus signifient « autorisé » et sont ignorées), CIDR, plages a-b ou adresses seules ; en clair, gzip ou zip. Les lignes commençant par #, // ou ; sont des commentaires. Les listes de plus de 256 MiB sont refusées.
Recharger toutes les (Reload every) … heures	24 par défaut, minimum 1
Enregistrer et charger (Save and load)	enregistre et recharge les listes immédiatement
Bannissements (Bans) / Bannir (Ban)	une adresse, un CIDR ou une plage que vous indiquez, avec un motif facultatif. Les bannissements s'appliquent même avec les listes désactivées. Chaque bannissement a un bouton Supprimer (Remove).

• La ligne d'état affiche les plages filtrées et les compteurs de refus entrants, de refus sortants et de déconnexions, ainsi que les plages ou l'erreur de chaque source.
• Une source qui ne se charge pas conserve sa dernière copie valide.
• Les réglages et les bannissements sont dans le store (base principale, hydra.db), pas dans default.toml.
• Chaque ligne de la table des pairs du panneau de détail a un bouton Bannir : l'adresse est déconnectée tout de suite et refusée ensuite ; elle apparaît alors sous Bannissements.
• Les chemins Windows comme C:\lists\level1.dat sont refusés ; utilisez une URL à la place.
• Les téléchargements de listes sont des requêtes propres du démon : ils sortent comme le dit [daemon] egress (voir VPN & sortie réseau).

API : GET/PUT /api/ipfilter, POST/DELETE /api/ipfilter/bans, POST /api/ipfilter/reload (voir API REST).

Vérifier la joignabilité

L'en-tête : IP de sortie et panneau Réseau

• Toutes les 180 s, Hydranos demande à un service d'écho extérieur (api.ipify.org, api6.ipify.org) quelle adresse il voit. Il le demande une fois pour les requêtes propres du démon (par la sortie que dit [daemon] egress), et une fois par moteur via l'interface de ce moteur. Un moteur sans interface n'est mesuré à part que lorsque le démon sort autrement, et jamais tant que le kill switch est armé. Un moteur tenu hors du réseau n'est pas mesuré. Un clic sur IP de sortie (Exit IP) relance la mesure. Avec plusieurs sorties distinctes, l'en-tête affiche {n} exits et les liste dans son info-bulle.
• Le polygone Réseau a un point par moteur. Un clic dessus ouvre le panneau Réseau, avec une ligne par moteur nommée par son identifiant de moteur : rôle, interface ou default route, port {port} (le port qu'il tient maintenant), IPv4/IPv6 de sortie.
• La couleur ne reflète que la sonde sortante : vert la sonde de sortie a répondu (exit probe answered), orange pas encore de réponse par son interface (no answer yet from its interface), rouge la sonde de sortie n'a pas eu de réponse (exit probe got no answer), gris hors ligne (offline). Vert ne signifie pas que les pairs peuvent se connecter à vous.

Bug connu en 4.4 : l'info-bulle du point du panneau dit « si les pairs peuvent joindre cet engine, c'est l'infobulle du point de santé qui le dit » (whether peers can reach this engine is the health dot's tooltip), mais la page ne dessine aucun point de santé. La joignabilité entrante n'est affichée nulle part dans l'interface web. Lisez-la dans GET /api/port-forward ou avec Vérifier ce qui se passe vraiment (ci-dessous).

GET /api/port-forward

Une ligne par moteur : engine, role, listening, listen_port (en cours), inbound_peers (pairs extérieurs connectés depuis le démarrage), reachable et forward. reachable vaut yes dès qu'un tel pair s'est connecté, no quand rien n'écoute, et unproven sinon. forward.by nomme qui redirige le port : upnp ou natpmp (routeur de la maison, avec tcp, udp, udp_error, external_port), wireguard (le tunnel), gluetun, none (avec refused ou error), off (auto_port_forward = false) ou pending. Le niveau supérieur ajoute listen_healthy, all_connectable, ipv6_wanted, public_ip et public_ip_v6. Un pair extérieur connecté est une preuve ; unproven n'est pas un échec.

Vérifier ce qui se passe vraiment

Le bouton en bas de l'onglet Réseau (POST /api/network/check, jusqu'à une minute) affiche une liste Ce qui se passe vraiment (What actually happens) :

1. Adresse de la route par défaut (Address of the default route), mesurée sans interface ni proxy : ce que montrerait une fuite.
2. Pour chaque moteur local, Adresse vue par les trackers (id) (Address trackers see (id)) et Adresse vue par les pairs (id) (Address peers see (id)), mesurées par le chemin que prend ce trafic (proxy d'annonce ou SOCKS5, interface, DNS du tunnel). La ligne échoue avec LEAK: … quand un moteur réglé pour sortir autrement montre l'adresse de la route par défaut, et avec no answer: … quand son tunnel ou son proxy ne répond pas. Un moteur tenu hors du réseau n'est pas sondé.
3. Adresse utilisée par les autres requêtes du démon (Address the daemon's own requests use), comparée de la même façon.
4. Joignabilité entrante (id) (Inbound reachability (id)), d'après les pairs qui se sont réellement connectés (comme /api/port-forward), avec ce qui redirige le port.

Tant que le kill switch est armé (dans tous les modes sauf Direct, par défaut), la route par défaut n'est pas mesurée. Les lignes des moteurs affichent alors warn (« a leak cannot be ruled out ») au lieu d'un verdict. Pour un test de fuite, utilisez le mode Direct, ou mesurez depuis l'extérieur comme ci-dessous.

Vérifier le port entrant depuis l'extérieur

unproven signifie seulement qu'aucun pair ne s'est encore connecté. Pour tester le port vous-même :

1. Vérifiez que le moteur écoute vraiment : GET /api/port-forward affiche listening: true et le listen_port attendu pour lui.
2. Trouvez l'adresse publique que les pairs doivent utiliser : l'adresse WAN de votre routeur ou, derrière un VPN, l'adresse de sortie du VPN et le port que votre fournisseur redirige.
3. Depuis une machine hors de votre réseau et hors du VPN (un téléphone en données mobiles, un serveur distant), lancez nc -vz 203.0.113.5 16172 avec cette adresse et ce port, ou utilisez un testeur de port en ligne. « succeeded »/« open » signifie que la redirection et l'écoute concordent. Un refus ou un délai dépassé signifie que la redirection, le port publié ou listen_port ne concordent pas (voir Ports d'écoute ci-dessus).

Mettre les moteurs hors ligne

Deux variables d'environnement, lues au démarrage :

Variable	Effet
HYDRANOS_ENGINE_NET=0 (aussi false, off ; toute autre valeur signifie activé)	Chaque moteur charge son état mais n'ouvre aucune écoute, n'envoie aucune annonce et ne démarre ni DHT ni LSD ; aucun tunnel WireGuard géré n'est monté. L'interface web, l'API et le store fonctionnent. Ce n'est pas silencieux : la redirection de port (NAT-PMP/UPnP vers votre routeur) et la sonde d'IP de sortie tournent toujours, de même que les autres requêtes sortantes du processus listées sur VPN & sortie réseau. Utile pour inspecter un catalogue sans rien publier.
TYPHON_DISABLE_UTP=1 (ou true)	Aucune socket uTP pour aucun moteur : TCP uniquement, en entrée comme en sortie.

Toutes les variables d'environnement : Config : environnement, CLI & signaux.

Voir aussi

• VPN & sortie réseau : ce qu'épingle bind_interface, le kill switch, les requêtes propres du démon, configurations gluetun et par interface.
• WireGuard géré : un tunnel par moteur, fournisseurs, port NAT-PMP, DNS dans le tunnel.
• Moteurs : race & hoard : ajouter des moteurs supplémentaires avec leur propre port et leur propre interface.
• Trackers & annonces : calendrier des annonces et onglet Trackers.
• Config : moteurs & drain race et Config : démon, auth & global : chaque clé et sa valeur par défaut.
• Docker : ports publiés.