Ouvrir un port à travers le tunnel

Dans l'app de bureau

L'écran est le même sur macOS, Windows et Linux.

Chaque port ajouté est ouvert sur le serveur de sortie et redirigé vers le même port sur ton appareil. Les changements s'appliquent immédiatement, sans reconnexion.

1. 1 Ouvre Paramètres, puis Port forwarding, et active l'interrupteur.
2. 2 « + Ajouter un port », puis un protocole (TCP+UDP, UDP ou TCP) et un numéro entre 49152 et 65535. L'app en propose un libre au hasard si tu n'as pas d'idée, et refuse un numéro hors de la plage.
3. 3 Cinq règles au maximum. La limite vaut pour tout le réseau, quel que soit le serveur de sortie.
4. 4 Quand la sortie accorde le port, la règle affiche « ouvert : 51413 » en vert. Le bouton « Copier le numéro de port », juste à côté, copie ce nombre seul, prêt à coller dans ton client.

Si ce numéro est déjà pris sur la sortie, la règle passe en « port occupé » et l'app te propose deux issues : « Attribuer un port libre », qui te donne un autre numéro tout de suite, ou « Choisir un autre serveur de sortie », qui garde ton numéro et change de sortie.

Le réglage « M'avertir quand un port public change » est actif par défaut. À chaque nouveau port, une notification système affiche « Port forwarding : le port public 51413 est ouvert », puis « Port forwarding : le port public 51413 n'est plus ouvert » quand il disparaît. Son bouton « Ouvrir le port forwarding » te ramène sur l'écran. Tant que la fenêtre de l'app est visible, aucune notification ne s'affiche.

Sur l'écran d'accueil, tant que tu es connecté, une pastille rappelle l'état : « Redirection de port : 51413 TCP+UDP ».

L'écran renvoie ici même, par le lien « Comment configurer votre client torrent ».

Le fichier forwarded_port

L'app écrit les ports publics actifs dans un fichier texte, un port par ligne, dans l'ordre de tes règles. Quand rien n'est ouvert ou que le tunnel tombe, l'app vide le fichier et le laisse en place : un script qui le surveille le trouve toujours. Il se trouve à côté de gui_settings.json, dans le dossier de données de l'app.

L'app bêta écrit dans le même dossier que l'app normale : le nom du dossier ne change pas d'un canal à l'autre. En cas de doute, cherche le dossier qui contient gui_settings.json.

Laisser l'app régler ton client torrent

Sous la liste des règles, le bloc « Client torrent » propose de faire le travail à ta place : « Warren peut saisir le port public dans votre client torrent et le mettre à jour à chaque changement. Activez d'abord l'interface web du client. »

L'app parle à qBittorrent, Transmission et Deluge par leur interface web. Active-la dans ton client et choisis-y un identifiant et un mot de passe : ce sont eux que tu donneras à l'app. Elle se trouve dans Options puis Web UI pour qBittorrent, dans Préférences puis Accès distant pour Transmission. Deluge a une interface web à part, livrée avec le mot de passe deluge, le même pour tout le monde : change-le avant toute chose.

1. 1 « Client » : qBittorrent, Transmission, Deluge, ou « Aucun » pour laisser le bloc au repos.
2. 2 « Adresse de l'interface web » : http://127.0.0.1:8080 pour qBittorrent, http://127.0.0.1:9091 pour Transmission, http://127.0.0.1:8112 pour Deluge.
3. 3 « Nom d'utilisateur » et « Mot de passe » : ceux que tu as choisis dans l'interface web du client (Deluge ne demande que le mot de passe). L'app chiffre le mot de passe avec le trousseau du système, puis le champ affiche « Enregistré ».
4. 4 « Règle » : celle dont le port part dans le client, quand tu en as plusieurs.
5. 5 « Tester la connexion » répond tout de suite, par exemple « Connecté à qBittorrent 5.0.4, à l'écoute sur le port 51413 ». « Appliquer maintenant » renvoie le port courant sans attendre le prochain changement.

Sous le bloc, une ligne dit toujours où en est le client :

• « qBittorrent écoute maintenant sur le port 51413 » : c'est passé.
• « Impossible de joindre qBittorrent à http://127.0.0.1:8080 » : le client est éteint, ou l'adresse est fausse.
• « qBittorrent a refusé la connexion » : identifiant ou mot de passe faux.
• « qBittorrent a refusé le port : ... » : le client a répondu mais refuse ce numéro.
• « En attente d'un port public » : la règle n'a pas encore le sien.
• « Ce système ne peut pas conserver le mot de passe en sécurité » : l'app n'a trouvé aucun trousseau pour chiffrer le mot de passe et n'enregistre pas le réglage. Ça arrive sur un Linux sans trousseau déverrouillé. Ce que tu as tapé reste dans le champ.

Si la sortie accorde un port public différent du numéro de ta règle, l'app repointe la règle sur le port accordé, des deux côtés, puis l'envoie au client. Ce numéro-là, tu ne l'as pas choisi, et il devient ton port d'écoute local : l'app n'accepte donc de la sortie qu'un port entre 49152 et 65535, ce qui l'empêche de tomber sur ton SSH.

Si le client ne répond pas, l'app réessaie trois fois, après 2, 5 puis 10 secondes : un client torrent muet est souvent en train de redémarrer. Un mot de passe refusé n'est pas réessayé, parce que qBittorrent bannit l'adresse qui se trompe plusieurs fois de suite.

En posant le port, l'app coupe aussi l'UPnP et le NAT-PMP du client, pour la raison donnée dans « Avant de commencer ».

Client par client

Si tu préfères tout faire à la main, la démarche est la même dans les trois : couper l'UPnP et le NAT-PMP, poser le port que la sortie a accordé, empêcher le client d'en changer au prochain démarrage.

En ligne de commande

La commande warren arrive avec chaque version de l'app. Elle s'installe aussi seule, sur une machine sans écran, et gère les mêmes cinq règles avec les mêmes contraintes.

warren port-forward enable --internal-port 51413 --protocol both
warren port-forward status
# 51413/TCP+UDP: MAPPED, public port 51413

Les autres sous-commandes suivent : add et remove pour gérer plusieurs règles, disable pour tout couper, get pour relire la configuration, lifetime pour la durée de bail demandée.

Pour un script, --json sort toujours les mêmes champs. Un champ vide reste présent et vaut null.

warren port-forward status --json
{"mappings":[{"internal_port":51413,"protocol":"both","state":"mapped","external_port":51413,"lifetime_granted_secs":3600,"error_reason":null,"error_message":null,"retry_after_secs":null,"attempts_remaining":null,"window_reset_secs":null}]}

--wait attend que chaque règle tienne son port, puis rend un code de sortie : 0 tout est ouvert, 1 il n'y a rien à attendre, 2 le délai est dépassé, 3 une règle a échoué. Ici, le port atterrit dans une variable, prêt pour la suite d'un script de démarrage.

port=$(warren port-forward status --wait --timeout 60 --json | jq '.mappings[0].external_port')

--watch suit les changements, une ligne JSON par changement. Avec --exec, Warren lance ta commande chaque fois qu'un port public change. Un renouvellement qui garde le même numéro ne la déclenche pas.

warren port-forward status --watch --exec 'sh /usr/local/bin/warren-qbt.sh {{PORT}}'

Le script appelé, ici pour qBittorrent et son interface web :

#!/bin/sh
# warren-qbt.sh: push the public port into qBittorrent. Called with the port as
# its only argument, and does nothing when the grant is gone (empty argument).
set -e
case "$1" in '' | *[!0-9]*) exit 0 ;; esac

curl -s -c /tmp/qb.cookie \
  --data 'username=admin&password=CHANGEME' \
  http://127.0.0.1:8080/api/v2/auth/login

curl -s -b /tmp/qb.cookie \
  --data-urlencode 'json={"listen_port":'"$1"',"random_port":false,"upnp":false}' \
  http://127.0.0.1:8080/api/v2/app/setPreferences

Dans la commande, {{PORT}} est remplacé par le port public. L'environnement porte aussi WARREN_PF_PORT, WARREN_PF_INTERNAL_PORT, WARREN_PF_PROTOCOL et WARREN_PF_STATE, qui vaut mapped quand le port arrive et lost quand il part.

Docker

L'image warren-vpn porte le tunnel pour ses voisins de pile. Son port forwarding reprend les variables que les utilisateurs de gluetun connaissent déjà : une pour le port interne, une autre pour la commande à lancer quand le port public change, avec {{PORT}} remplacé par le numéro.

Le port actif est aussi écrit dans /tmp/warren/forwarded_port, si ton conteneur voisin préfère surveiller un fichier.

services:
  warren:
    image: ghcr.io/warrenbrowse/warren-vpn:beta
    cap_add: [NET_ADMIN]
    devices: [/dev/net/tun]
    environment:
      - WARREN_MNEMONIC_FILE=/run/secrets/warren_mnemonic
      - WARREN_PORT_FORWARD_INTERNAL_PORT=6881
      - WARREN_PORT_FORWARD_PROTOCOL=both
      - WARREN_PORT_FORWARD_UP_COMMAND=sh /scripts/qbt-port.sh {{PORT}}
    volumes:
      - ./warren-qbt.sh:/scripts/qbt-port.sh:ro
    secrets: [warren_mnemonic]

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    network_mode: "service:warren"
    depends_on:
      warren:
        condition: service_healthy

secrets:
  warren_mnemonic:
    file: ./warren_mnemonic.txt

Le script monté dans l'exemple est celui de la section précédente : il prend le port en argument et le pose dans le client. Les trois recettes prêtes à l'emploi, une par client, sont dans docker/examples/ du dépôt warren-cli, avec les appels curl déjà écrits et testés.

Docker remplace l'espace réseau quand il redémarre le conteneur warren, et le client torrent garde une poignée sur l'ancien : il affiche zéro pair, sans erreur, jusqu'à ce qu'on le redémarre lui aussi. depends_on ne règle que l'ordre du premier démarrage. Après chaque redémarrage de warren : docker compose restart qbittorrent.

Le reste de la pile Docker est sur la page Serveurs et NAS

Vérifier que le port est ouvert

Un testeur de port en ligne répond « fermé » dès que rien n'écoute, et c'est le cas le plus fréquent : le port est bien ouvert sur la sortie, mais ton client n'est pas encore démarré. Dans l'ordre : lance ton client torrent, vérifie que la règle est accordée (« ouvert : 51413 » dans l'app, MAPPED en ligne de commande), teste ensuite.

Un résultat « filtré » sur un autre port n'a rien d'anormal non plus. Seuls tes ports forwardés sont ouverts sur cette adresse de sortie ; tout le reste est fermé, pour toi comme pour les autres.