Configurer un bridge Tor obfs4 sur un VPS

Ce qu’est un bridge Tor et pourquoi il existe

Un bridge Tor est un point d’entrée dans le réseau Tor dont l’adresse n’est pas publiée dans la liste publique des relais. Cette liste, appelée consensus, est un document signé que n’importe qui peut télécharger, y compris un censeur. Bloquer Tor à partir de cette liste ne prend qu’un après-midi : il suffit de récupérer le consensus, puis de bloquer toutes les adresses qu’il contient à la frontière du réseau. Les bridges existent parce que la liste publique est le point faible. Leurs adresses sont distribuées en petit nombre, afin qu’aucune requête ne fournisse l’ensemble des adresses.

Une adresse absente de la liste ne suffit qu’à moitié. La deep packet inspection (DPI), qui classe le trafic selon son contenu plutôt que selon son adresse, reconnaît une connexion Tor à la forme de son handshake TLS (transport layer security). Un censeur qui ne possède pas la liste peut tout de même voir que « cela ressemble à Tor » et bloquer la connexion. Un pluggable transport supprime ce signal. Il encapsule le flux Tor dans un autre protocole côté client, puis votre bridge le désencapsule.

obfs4 est le transport utilisé par la plupart des bridges. Il transforme le flux en octets sans en-tête ni handshake fixe, afin que la DPI ne dispose d’aucun motif à rechercher. Il authentifie également le client. La valeur cert= présente dans une ligne de bridge est une clé que le client doit prouver qu’il possède avant que le bridge ne réponde, ce qui empêche le sondage actif : un censeur qui se connecte à votre adresse pour vérifier si elle parle Tor n’obtient aucune réponse et n’apprend rien.

Quel transport enfichable devez-vous utiliser ?

• obfs4 nécessite un VPS, deux ports TCP et aucun nom de domaine. C’est la solution utile la plus simple à déployer et elle fait l’objet de ce guide.
• WebTunnel dissimule la connexion dans un trafic HTTPS ordinaire vers un véritable site web. Le Tor Project indique les prérequis suivants : une adresse IPv4 statique, un domaine que vous contrôlez, un serveur web fonctionnel tel que NGINX ou Apache, un certificat TLS valide, ainsi qu’au moins 1 GB de RAM, avec 4 GB recommandés. Cette solution convient aux réseaux où un trafic à l’aspect aléatoire est en lui-même suspect, car un pays qui autorise peu de choses au-delà de la navigation web autorise généralement toujours HTTPS.
• Snowflake repose sur une autre forme de contribution. Des volontaires exécutent des proxies WebRTC à courte durée de vie. Les points d’entrée changent donc constamment et aucun adresse stable ne peut être bloquée par la censure. Vous n’exploitez pas de bridge pour Snowflake. Vous exécutez un proxy, qui ne nécessite aucune adresse fixe.

Commencez par obfs4. Vous pourrez ajouter ultérieurement un bridge WebTunnel sur une deuxième adresse. Exécuter les deux sur une seule adresse IP signifie qu’un seul blocage de cette adresse désactive les deux.

Quel est le coût d’un bridge ?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

En août 2026, le projet Tor demande à un bridge au moins 1 Mbit/s de bande passante en émission et en réception. Pour un relay guard ou middle, il demande 10 Mbit/s, avec 16 Mbit/s recommandés. Il s’agit d’exigences publiées, pas de mesures. Un nouveau bridge reste généralement bien en dessous de son propre minimum pendant plusieurs semaines. La même page d’exigences demande à un relay au moins 100 GByte de trafic sortant par mois. Les offres les moins chères couvrent déjà ce volume. Consultez donc le coût mensuel réel d’un petit VPS avant de choisir une offre plus grande.

La surface d’abus est limitée, et c’est souvent sur ce point que les erreurs se produisent. Un bridge est le premier saut. Le trafic qui quitte votre serveur est envoyé vers un autre relay Tor, jamais vers un site web choisi par un utilisateur. Votre adresse IP n’apparaît jamais dans le journal web d’un tiers comme source d’une requête. Les messages de plainte que traitent les opérateurs de relay exit n’arrivent donc pas jusqu’à vous. Consultez tout de même la politique d’utilisation acceptable de votre hébergeur, car certains fournisseurs traitent tout service Tor comme un cas particulier. Un bridge et un onion service sont, sur ce point, des images inversées : un bridge n’est utile que parce que son adresse est accessible et finit par être distribuée, tandis que un onion service v3 sur le même type de VPS n’est utile que tant que votre IP publique reste masquée.

Ne faites pas une chose : ne transformez pas un relay public existant en bridge à la même adresse. Pour ce cas, le projet Tor recommande de modifier « l’adresse IP, le nom et l’empreinte », car l’ancienne adresse figure déjà dans le consensus que les censeurs téléchargent. Un bridge qui était un relay public la semaine dernière est déjà présent dans une blocklist.

La disponibilité compte davantage que la vitesse. Les exigences applicables aux relay indiquent que « si votre relay ne fonctionne pas plus de 2 heures par jour, son utilité est limitée ». Un bridge est encore plus pénalisé qu’un relay sur ce point, car chaque client ne dispose que d’une seule adresse et d’aucune solution de repli. Un redémarrage déconnecte tous les utilisateurs qui l’utilisent. Configurez un contrôle de port TCP dans Uptime Kuma sur le port obfs4 afin de savoir le jour où il cesse de répondre.

Installer Tor depuis le dépôt du projet Tor

Les paquets des distributions sont souvent en retard, alors qu’un bridge est un logiciel de sécurité qui doit rester à jour. Ajoutez d’abord le dépôt officiel du projet.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Créez maintenant le fichier source. La ligne Suites: doit contenir le nom de code de votre release. Récupérez-le depuis le système au lieu de le saisir de mémoire.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

Si apt update indique que le dépôt ne contient aucun fichier Release pour votre nom de code, le projet Tor ne prend pas cette release en charge. Supprimez /etc/apt/sources.list.d/tor.sources, exécutez de nouveau sudo apt update, puis installez le paquet tor fourni par votre distribution. La suite est identique.

Le paquet obfs4proxy provient directement de Debian et d’Ubuntu (version 0.0.14 dans Debian 13, en août 2026). Vérifiez où le binaire a été installé, car son chemin doit être renseigné dans la configuration :

command -v obfs4proxy || command -v lyrebird

Le projet amont a été renommé lyrebird. Un paquet plus récent peut donc installer /usr/bin/lyrebird à la place. Utilisez le chemin affiché par cette commande.

Configurer le bridge dans /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Chacune de ces lignes correspond à une cause d’échec possible. Examinez-les donc une par une.

BridgeRelay 1 indique à tor d’envoyer son descripteur à l’autorité des bridges, au lieu de l’envoyer au consensus public. Cette seule ligne rend le relay non répertorié.

ORPort correspond au véritable port Tor. Il doit être accessible depuis Internet, car tor le teste et refuse de publier un descripteur tant que ce test n’a pas réussi.

ServerTransportPlugin indique à tor quelle commande exécuter. tor démarre obfs4proxy en tant que processus enfant et communique avec lui via un pipe. obfs4proxy n’a donc pas sa propre unité de service et n’apparaît jamais dans systemctl status.

ServerTransportListenAddr fixe le port sur lequel obfs4proxy écoute. Si vous omettez cette ligne, obfs4proxy choisit un port libre au démarrage, souvent différent après chaque redémarrage. Toutes les lignes de bridge déjà distribuées pointent alors vers un port sur lequel aucun processus n’écoute. Les clients concernés reçoivent un refus de connexion et cessent leurs tentatives.

ExtORPort auto ouvre l’ORPort étendu, un canal loopback qu’obfs4proxy utilise pour transmettre à tor les connexions établies ainsi que l’adresse du client. Le guide de configuration du Tor Project l’inclut sur chaque bridge, car le transport ne peut pas transmettre cette adresse à tor sans lui.

ContactInfo et Nickname sont tous deux publics. Utilisez une adresse que vous consultez, car c’est ainsi que le Tor Project vous contacte lorsqu’un bridge ne fonctionne plus. Choisissez un pseudonyme qui ne permet pas de vous identifier si vous préférez rester discret.

BridgeDistribution sélectionne le distributeur qui transmet votre adresse aux utilisateurs. Les valeurs acceptées sont https, email, telegram, settings, none et any. Utilisez any pour un premier bridge et laissez le système décider. Utilisez none pour un bridge privé que vous distribuez vous-même. Son adresse ne sera alors pas distribuée publiquement.

Pourquoi le choix des ports est important

N’utilisez pas 9001 pour les deux ports. Le Tor Project le précise directement, car 9001 est l’ORPort traditionnel et les censeurs analysent Internet à sa recherche. Les deux ports doivent également être différents, car tor et obfs4proxy ouvrent chacun leur propre listener.

Le port obfs4 le plus efficace est 443. Les connexions sortantes vers 443 sont autorisées sur presque tous les réseaux restreints, et une connexion longue vers ce port ressemble à une session web ordinaire. L’écoute sur un port inférieur à 1024 nécessite une étape supplémentaire, car obfs4proxy ne s’exécute pas en tant que root :

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Ajoutez ces deux lignes dans chaque éditeur qui s’ouvre :

[Service]
NoNewPrivileges=no

La capability seule ne suffit pas. Le NoNewPrivileges de systemd empêche un processus d’acquérir un privilège que son parent ne possédait pas, et une file capability correspond exactement à ce cas. obfs4proxy ne peut donc pas ouvrir le port 443 tant que ce paramètre reste activé.

Si vous préférez éviter cette étape, choisissez un port élevé peu remarquable et notez-le. Quel que soit votre choix, ne modifiez pas le port obfs4 par la suite. Une ligne de bridge associe l’adresse, le port, l’empreinte et le certificat. Chaque copie déjà présente dans le navigateur d’un utilisateur cesse donc de fonctionner dès que le port change.

Ouvrir les ports sur les deux pare-feu

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

Les deux ports doivent être ouverts. La plupart des fournisseurs utilisent aussi un second pare-feu dans leur panneau de contrôle, que ufw ne connaît pas. Une règle présente sur le serveur mais absente du panneau crée un bridge qui reste inaccessible et ne publie jamais de descripteur. Si l’un de ces deux éléments vous est nouveau, consultez les règles ufw nécessaires sur un VPS neuf et ce qu’est réellement un port en écoute sous Linux. Profitez-en pour sécuriser SSH avec des clés et une configuration sshd renforcée. Un bridge non répertorié sur un serveur où SSH utilise encore des mots de passe reste un serveur où SSH utilise des mots de passe.

Démarrez-le, puis consultez le journal

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian et Ubuntu fournissent deux unités. tor.service est un petit wrapper et tor@default.service est le processus qui effectue le travail. C’est pourquoi journalctl -u tor semble presque vide, alors que le journal recherché se trouve sous tor@default.

Deux lignes indiquent que tout a fonctionné :

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

La première signifie que le test d’accessibilité a réussi et que le descripteur a été transmis à l’autorité du bridge. Si elle n’apparaît jamais, un élément entre Internet et votre serveur bloque le trafic vers l’ORPort. La deuxième ligne doit afficher le port que vous avez configuré. Si elle affiche un autre port, tor n’a jamais appliqué ServerTransportListenAddr. La cause habituelle est un nom de transport incohérent : il doit être obfs4 dans les deux directives.

Vérifiez que les deux listeners existent :

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

Où se trouve ma ligne de bridge ?

obfs4proxy écrit un modèle dans le répertoire de données de tor :

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Ce répertoire appartient à l’utilisateur tor et ses permissions sont 700. Sans sudo, vous obtenez donc Permission denied. Le fichier contient une ligne de cette forme :

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Remplacez <IP ADDRESS> par l’adresse publique de votre serveur, <PORT> par le port obfs4, et non par l’ORPort, puis <FINGERPRINT> par l’empreinte d’identité écrite par tor dans son répertoire de données :

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

Le premier fichier contient votre pseudonyme et l’empreinte d’identité à placer dans une ligne de bridge. Le second contient l’empreinte hachée. C’est cette valeur que vous saisissez dans Relay Search pour vérifier que votre bridge fonctionne et estimer le nombre de clients qui l’atteignent. Ces deux valeurs ne sont pas interchangeables. Une ligne de bridge contenant la valeur hachée ne correspond pas à la clé d’identité présentée par votre bridge. Le client rejette donc la connexion qu’il vient d’ouvrir.

Comment un bridge atteint-il concrètement les utilisateurs ?

Vous ne transmettez votre ligne de bridge à personne. Une fois le descripteur reçu par l’autorité des bridges, le système de distribution (rdsys, le successeur de BridgeDB) affecte votre bridge à un distributeur, puis les utilisateurs demandent des bridges à ce distributeur. En août 2026, les canaux sont les suivants :

• Le formulaire web à l’adresse bridges.torproject.org/options, qui fournit les lignes de bridge après validation d’un captcha.
• Un e-mail envoyé à bridges@torproject.org depuis une adresse Gmail ou Riseup, qui répond avec des lignes de bridge. Cette restriction sur les fournisseurs est nécessaire, car des comptes gratuits illimités permettraient à un censeur d’énumérer tous les bridges.
• Le bot Telegram @GetBridgesBot. Envoyez /start, puis /obfs4 ou /webtunnel.
• Tor Browser lui-même, dans Settings puis Connection, où « Request bridges » les récupère via le canal moat.

Un nouveau bridge apparaît dans Relay Search environ trois heures après sa configuration. Les utilisateurs mettent beaucoup plus de temps à arriver : selon la formulation du Tor Project, « plusieurs jours ou semaines peuvent s’écouler avant que vous voyiez un ensemble d’utilisateurs stable ». L’absence d’activité pendant les deux premières semaines est normale. Elle n’indique pas un problème.

La configuration de BridgeDistribution none désactive tous ces canaux. Vous devez alors transmettre vous-même la ligne de bridge aux personnes qui en ont besoin, par un canal que le censeur ne surveille pas.

Lorsqu’un problème survient

Aucune ligne d’auto-test dans le journal. L’ORPort n’est pas accessible. Testez-le depuis une autre machine avec nc -vz your.ip 8443. Si la commande reste bloquée, les paquets sont probablement bloqués : vérifiez donc ufw et le panneau du fournisseur. Un refus signifie que tor n’écoute pas sur ce port : vérifiez ss -lntp et recherchez une erreur de configuration dans le journal.

Le transport enregistré indique un port que vous n’avez pas choisi. tor a ignoré ServerTransportListenAddr. Le nom du transport doit correspondre exactement à celui indiqué dans ServerTransportPlugin, et les deux valeurs doivent être obfs4.

obfs4proxy ne peut pas écouter sur le port 443. Vérifiez la capacité avec getcap /usr/bin/obfs4proxy, puis vérifiez que la surcharge a bien été transmise à l’unité avec systemctl show tor@default -p NoNewPrivileges. Si la commande affiche NoNewPrivileges=yes, votre drop-in cible une unité qui n’est pas active.

Rien dans /var/lib/tor/pt_state/. tor n’a jamais démarré le transport, ce qui signifie que le chemin indiqué dans ServerTransportPlugin est incorrect. Comparez-le avec la sortie de command -v obfs4proxy.

Les clients ne se connectent plus après une modification. Toute modification de l’adresse ou du port obfs4 invalide toutes les lignes de bridge déjà distribuées. Vérifiez également si l’adresse IP publique du serveur a changé, ce qui peut arriver après une reconstruction chez certains fournisseurs.

tor ne démarre plus du tout. Exécutez sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Cette commande analyse le fichier, indique la ligne problématique et laisse le service en cours d’exécution intact.

FAQ

Mon fournisseur de VPS se plaindra-t-il de l’exécution d’un bridge Tor ?

Un bridge est un point d’entrée. Le trafic qui quitte votre serveur est donc dirigé vers d’autres relais Tor, et jamais vers un site choisi par un utilisateur. Votre adresse IP n’apparaît dans aucun journal web comme source d’une requête. C’est ce qui entraîne les plaintes auxquelles les opérateurs de relais de sortie doivent faire face. Les règles d’hébergement varient toutefois. Certains fournisseurs considèrent tout service Tor comme un cas particulier. Lisez donc la politique d’utilisation acceptable avant de commencer et saisissez une adresse que vous avez lue dans ContactInfo.

Quelle bande passante un bridge Tor utilise-t-il ?

Le minimum publié est de 1 Mbit/s en émission et en réception, contre 10 Mbit/s pour un relais guard ou middle. L’utilisation réelle commence près de zéro, car votre bridge ne transporte que le trafic des utilisateurs qu’un distributeur lui envoie. Si vous voulez imposer une limite maximale, définissez RelayBandwidthRate et RelayBandwidthBurst dans torrc.

Pourquoi personne ne s’est-il connecté à mon nouveau bridge ?

Un bridge met environ trois heures à apparaître dans Relay Search. Selon les recommandations du Tor Project, il faut plusieurs jours ou semaines pour obtenir un ensemble d’utilisateurs régulier. Vérifiez que le descripteur a été publié, ce qui correspond à la ligne d’auto-test dans journalctl -u tor@default, recherchez votre fingerprint haché dans Relay Search et confirmez que BridgeDistribution n’est pas défini sur none.

Dois-je exécuter obfs4 ou WebTunnel ?

Exécutez obfs4 s’il s’agit de votre premier bridge : un VPS, deux ports, aucun domaine et aucun certificat. Utilisez WebTunnel lorsque le trafic à l’apparence aléatoire est lui-même bloqué. Il nécessite un domaine que vous contrôlez, un véritable serveur web, un certificat TLS valide et au moins 1 GB de RAM. Utilisez des adresses distinctes si vous exécutez les deux, car le blocage d’une seule adresse IP supprimerait sinon deux bridges simultanément.

Que se passe-t-il si je modifie ultérieurement le port obfs4 ?

Toutes les lignes de bridge déjà distribuées cessent de fonctionner. Une ligne de bridge associe l’adresse, le port, le fingerprint et le certificat. Un client qui possède l’ancienne ligne ouvre donc une connexion vers un port où aucun service n’est en écoute, puis abandonne. Le même problème se produit lorsque l’adresse IP publique du serveur change. Choisissez le port lors de la configuration et ne le modifiez plus.