Warren sans l'app de bureau

Un conteneur qui porte le tunnel

L'image warren-vpn fait tourner le client Warren sans interface graphique, dans la forme popularisée par gluetun : un seul conteneur détient le tunnel, le kill-switch et l'espace réseau, et tout ce qui doit sortir par le VPN rejoint cet espace. En Docker Compose, c'est une ligne dans le service voisin ; en Kubernetes, c'est un side-car dans le même pod.

Warren ne parle ni WireGuard ni OpenVPN, donc aucun conteneur VPN générique ne sait le transporter. Cette image est la voie prévue partout où des conteneurs tournent : un serveur Linux, un Synology, un QNAP, un Unraid, un TrueNAS, un cluster Kubernetes.

• Le kill-switch est actif par défaut. Si le démon meurt, l'espace réseau meurt avec lui : il n'existe aucun instant où le trafic peut sortir à côté du tunnel.
• Le port forwarding NAT-PMP est intégré. Quand le serveur de sortie accorde un port public, le conteneur l'écrit dans un fichier et lance la commande que tu lui as donnée, port substitué, pour le pousser dans ton application : un client torrent écoute et s'annonce alors sur ce même port. La recette complète pour qBittorrent, identifiants compris, est dans docker/examples/ du dépôt.
• La phrase de récupération se monte en fichier, jamais en variable d'environnement : une variable se lit dans un docker inspect. Dans un conteneur, le démon ne peut pas la sceller avec la puce de la machine et retombe sur un fichier lisible par le seul compte root, donc traite le volume d'état comme un secret.
• Il faut NET_ADMIN et /dev/net/tun. Le conteneur pose ses règles dans son propre espace réseau et ne touche jamais au pare-feu de la machine hôte.

L'image est reconstruite et publiée à chaque version du démon et à chaque correctif de l'image elle-même, mais le paquet reste privé pour l'instant : un docker pull répond « unauthorized ». En attendant, le script du dépôt construit la même image en local, autour du dernier démon publié, sous le nom exact que les exemples utilisent.

git clone https://github.com/WarrenBrowse/warren-cli && cd warren-cli
./docker/build.sh -t ghcr.io/warrenbrowse/warren-vpn:beta

Ensuite, le voisin qui doit passer par le tunnel rejoint l'espace réseau du conteneur Warren, et attend qu'il soit connecté avant de démarrer.

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_RELAY_LOCATION=fi
    secrets: [warren_mnemonic]
    restart: unless-stopped

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

secrets:
  warren_mnemonic:
    file: ./warren_mnemonic.txt

Un serveur Linux, sans conteneur

Le client Warren, c'est un démon (warren-daemon) et une commande (warren). Les deux tournent sans Electron, sans écran et sans session graphique : une machine en SSH suffit. Le dépôt warren-cli publie les paquets prêts à poser (deb, rpm, archive générique, macOS, Windows), leurs sommes de contrôle, le service qui va avec (systemd, OpenRC ou sysvinit), et un installeur en une ligne qui lit la machine et choisit pour toi.

curl -fsSL https://raw.githubusercontent.com/WarrenBrowse/warren-cli/main/scripts/install.sh | sudo sh

Ensuite tu crées ton compte, tu ajoutes du temps avec ton code, tu choisis un pays et tu connectes.

warren account create
warren account redeem <code>
warren relay set location FR
warren connect
warren status

Un seul démon Warren par machine : le paquet serveur et l'app de bureau se disputeraient la même socket et la même identité de pare-feu, donc ils s'excluent. Alpine et les autres systèmes musl ne sont pas couverts, et l'installeur te le dit au lieu de te laisser un binaire qui ne démarre pas.

Routeurs, Apple TV, gluetun : la passerelle locale

Un routeur, une Apple TV ou une console n'offrent souvent qu'un seul client VPN, et ce client parle WireGuard. Warren a son propre protocole, donc ces appareils ne savent pas s'y connecter directement.

La passerelle warren-bolthole comble ce trou. Elle met en œuvre le protocole WireGuard pour que les clients WireGuard standard puissent utiliser Warren, et tourne sans aucun privilège sur une machine de ton réseau : un NAS, un Raspberry Pi, un serveur, un conteneur. Côté réseau local, tes appareils s'y connectent avec leur client habituel ; côté internet, tout ressort dans un seul tunnel Warren vers la sortie.

La commande warren-bolthole init écrit un fichier de configuration par appareil, à importer tel quel : en QR code dans l'app WireGuard d'un téléphone, en fichier sur une Apple TV, dans LuCI sur OpenWrt ou l'interface d'un GL.iNet. Un routeur compte pour un seul appareil et emmène derrière lui tout ce qui n'a aucun client VPN, une console par exemple. Une pile gluetun existante garde son image d'origine : provider custom, type wireguard, et le fichier d'environnement que la passerelle génère.

Tout cela a été éprouvé sur une vraie sortie du réseau : wg-quick d'origine en mode noyau et en espace utilisateur, un gluetun non modifié, le DNS résolu dans le tunnel sans fuite locale, et le port forwarding NAT-PMP qui atteint un service posé derrière un appareil, vérifié depuis un point neutre d'internet.

La passerelle vit dans le dépôt du SDK Rust, warren-sdk-rs, et se construit avec cargo aujourd'hui. La mise en route :

export WARREN_MNEMONIC_FILE=/etc/warren/mnemonic
export WARREN_BOLTHOLE_LAN=1 WARREN_BOLTHOLE_LISTEN=0.0.0.0:51820
warren-bolthole init --peers 2 --label tv --label router
warren-bolthole show tv --qr
warren-bolthole run

• Tous les appareils d'une même passerelle partagent une seule session Warren : une seule adresse de sortie, une seule place d'appareil sur le compte, un seul quota de port forwarding, une bande passante commune. Les fichiers clients sont des clés de ton compte : réserve-les à tes propres appareils. Les appareils sont isolés les uns des autres par défaut.
• L'obfuscation de Warren commence à la passerelle. Entre ton appareil et elle, c'est du WireGuard ordinaire, reconnaissable par n'importe quelle inspection de trafic. Sur ton réseau local, c'est exactement le but ; ne publie jamais le port UDP de la passerelle sur internet.
• Quand le tunnel Warren tombe, la passerelle se tait : elle ne répond plus rien aux appareils tant que la sortie n'est pas prouvée de nouveau, et rien ne peut sortir à côté du tunnel. Le kill-switch de l'appareil reste son propre réglage : active « Bloquer les connexions sans VPN » sur Android, l'équivalent de ton routeur, ou le pare-feu intégré de gluetun.

« WireGuard » est une marque déposée de Jason A. Donenfeld. Ce projet n'est ni affilié au projet WireGuard, ni approuvé par lui.