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. Il suffit d’un après-midi pour bloquer Tor à partir de cette liste : télécharger le consensus, puis bloquer toutes les adresses qu’il contient à la frontière du réseau. Les bridges existent parce que cette liste publique est le point faible. Les adresses des bridges sont distribuées en petites quantités, afin qu’aucune requête ne fournisse l’ensemble des adresses.

Une adresse non répertoriée 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). Même sans disposer de la liste, un censeur peut 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, de sorte que la DPI ne trouve aucun motif à reconnaître. Il authentifie également le client. La valeur cert= dans une ligne de bridge est une clé que le client doit prouver qu’il détient avant que le bridge ne réponde, ce qui empêche le probing 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 seul VPS, deux ports TCP et aucun nom de domaine. C’est la solution utile la plus simple à déployer et le sujet de ce guide.
• WebTunnel dissimule la connexion dans du trafic HTTPS ordinaire vers un site web réel. Le projet Tor 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ù le trafic d’apparence aléatoire est déjà suspect, car un pays qui autorise peu de choses au-delà de la navigation web autorise malgré tout le HTTPS.
• Snowflake est une autre forme de contribution. Des volontaires exécutent des proxies WebRTC éphémères. Les points d’entrée changent donc constamment et il n’existe aucune adresse stable qu’un censeur puisse bloquer. 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 seconde adresse. Exécuter les deux sur une seule IP signifie qu’une seule adresse bloquée 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 montante et descendante. 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 plus petits forfaits couvrent déjà ce volume. Consultez donc le coût mensuel réel d’un petit VPS avant de choisir une configuration plus importante.

La surface d’abus est limitée. C’est le point que l’on comprend souvent mal. Un bridge est le premier hop. Le trafic qui quitte votre serveur va vers un autre relay Tor, jamais vers le site web choisi par l’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 relais de sortie n’arrivent donc pas ici. Consultez malgré tout la politique d’utilisation acceptable de votre fournisseur, car certains hébergeurs traitent tout service Tor comme un cas particulier.

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

La disponibilité compte davantage que la vitesse. Les exigences applicables aux relais 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 adresse et d’aucun fallback. 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 de sources. La ligne Suites: doit contenir le nom de code de votre release. Récupérez-le donc 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 en charge cette release. 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 sera utilisé 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 de panne. Examinez-les donc une par une.

BridgeRelay 1 indique à tor d’envoyer son descripteur à l’autorité des bridges plutôt qu’au consensus public. C’est cette ligne qui rend le relay non répertorié.

ORPort correspond au port Tor réel. 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 est en écoute. Si vous omettez cette ligne, obfs4proxy choisit un port libre au démarrage, souvent différent après un redémarrage. Chaque ligne de bridge déjà distribuée pointe alors vers un port où aucun service n’est en écoute. Les clients obtiennent une connexion refusée et cessent d’essayer.

ExtORPort auto ouvre l’ORPort étendu, un canal loopback qu’obfs4proxy utilise pour transmettre à tor les connexions établies avec 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 publics. Utilisez une adresse que vous consultez, car le Tor Project l’utilise pour vous contacter en cas de problème avec le bridge. Choisissez un pseudonyme qui ne permet pas de vous identifier si vous préférez rester discret.

BridgeDistribution sélectionne le distributor 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 reste ainsi complètement exclue de la distribution publique.

Pourquoi le choix des ports est important

Évitez d’utiliser 9001 pour les deux ports. Le Tor Project le recommande explicitement, car 9001 est l’ORPort traditionnel et les censeurs recherchent ce port sur Internet. Les deux ports doivent également être différents, car tor et obfs4proxy ouvrent chacun leur propre listener.

Le port obfs4 le plus fiable est 443. Les connexions sortantes vers 443 sont autorisées sur presque tous les réseaux restreints, et une connexion persistante vers ce port ressemble à une session web ordinaire. Utiliser 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 ne suffit pas à elle seule. Le NoNewPrivileges de systemd empêche un processus d’acquérir un privilège que son parent ne possédait pas, et une capability de fichier 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.

Ouvrez 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 exécutent aussi un second pare-feu dans leur panneau de contrôle, auquel ufw n’a pas accès. 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 aspects 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 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 simple 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 seconde ligne doit afficher le port que vous avez configuré. Un autre port indique que 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ù est 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, et <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 nickname et l’empreinte d’identité à utiliser dans une ligne de bridge. Le second contient l’empreinte hachée. C’est cette valeur que vous collez 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 réellement les utilisateurs ?

Vous ne transmettez votre ligne de bridge à personne. Une fois le descripteur parvenu à l’autorité des bridges, le système de distribution (rdsys, le successeur de BridgeDB) attribue 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 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 existe, car des comptes gratuits en nombre illimité 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 être nécessaires avant que vous voyiez un ensemble stable d’utilisateurs ». L’absence d’activité pendant les deux premières semaines est normale et ne signale pas un problème.

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

Quand quelque chose ne fonctionne pas

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 filtrés. Vérifiez donc ufw et le panneau du fournisseur. Un refus signifie que tor n’écoute pas. Vérifiez alors ss -lntp et consultez le journal pour rechercher une erreur de configuration.

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 doivent être obfs4.

obfs4proxy ne peut pas s’attacher au 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 a été appliqué à une unité qui n’est pas en cours d’exécution.

Rien dans /var/lib/tor/pt_state/. tor n’a jamais démarré le transport. Le chemin indiqué dans ServerTransportPlugin est donc incorrect. Comparez-le à 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é. Cela peut se produire lors d’une reconstruction chez certains fournisseurs.

tor ne démarre pas du tout. Exécutez sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. La commande analyse le fichier, affiche la ligne qui pose problème et laisse le service en cours d’exécution tel quel.

FAQ

Mon fournisseur de VPS se plaindra-t-il d’un bridge Tor ?

Un bridge est un point d’entrée. Le trafic qui quitte votre serveur est donc destiné à d’autres relais Tor, et jamais au 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 génère les plaintes auxquelles les opérateurs de relais de sortie doivent faire face. Les règles d’hébergement varient néanmoins. Certains fournisseurs traitent tout service Tor comme un cas particulier. Lisez donc la politique d’utilisation acceptable avant de commencer et indiquez une adresse que vous consultez 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. En pratique, l’utilisation commence près de zéro, car votre bridge ne transporte que le trafic des utilisateurs qu’un distributeur lui envoie. Pour imposer une limite stricte, 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. D’après les recommandations du Tor Project, il faut plusieurs jours ou semaines pour obtenir un ensemble d’utilisateurs régulier. Vérifiez que le descriptor a bien é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 utiliser obfs4 ou WebTunnel ?

Utilisez 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é. Cette solution nécessite un domaine que vous contrôlez, un véritable serveur web, un certificat TLS valide et au moins 1 GB de RAM. Placez-les sur des adresses distinctes si vous utilisez les deux, car le blocage d’une seule adresse IP supprimerait sinon deux bridges en même temps.

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 sur lequel aucun service n’écoute, puis abandonne. Il en va de même lorsque l’adresse IP publique du serveur change. Choisissez le port pendant la configuration et ne le modifiez plus.