Installer un relais Tor guard ou middle sur un VPS

Ce que fait un relais Tor sur un VPS

Un relais Tor est un daemon Tor exécuté sur une machine disposant d’une adresse IP publique. Il relaie le trafic chiffré d’autres utilisateurs. Les autorités d’annuaire le publient, puis les clients Tor construisent des circuits en passant par lui. Un relais guard ou middle ne transmet le trafic qu’à un autre relais. Il n’ouvre donc jamais de connexion à un site web au nom d’un tiers. C’est précisément pour cette raison qu’il ne reçoit pas de messages d’abus et qu’il convient à un VPS classique.

La mise en place est rapide : un paquet, quinze lignes de configuration, une règle de pare-feu et un redémarrage. Le reste de ce guide porte sur les points qui posent problème. Il explique notamment comment calculer la consommation de bande passante avec un forfait limité et pourquoi un relais récent, pourtant parfaitement fonctionnel, semble inactif pendant une semaine.

Guard, middle, bridge ou exit : choisissez avant l’installation

Un seul daemon assure ces quatre rôles. Votre configuration et les directory authorities déterminent lequel vous assurez.

• Middle relay. Il reçoit le trafic d’un guard et le transmet à un autre relay. Il ne contacte jamais le site de destination. Chaque nouveau relay commence par ce rôle.
• Guard relay. Il utilise la même configuration, avec un flag supplémentaire. Les directory authorities attribuent le flag Guard aux relays qui sont rapides et stables depuis assez longtemps. Vous ne le choisissez pas. Vous le gagnez, et c’est la configuration ci-dessous qui vous permet de l’obtenir.
• Bridge. C’est un relay volontairement absent du répertoire public, puis distribué en privé aux utilisateurs situés dans des régions où Tor est bloqué. C’est le rôle qui demande le moins d’engagement : faible bande passante, aucune inscription publique et une première étape adaptée si votre projet reste limité.
• Exit relay. C’est le dernier hop, qui ouvre la connexion vers le site de destination. Chaque requête d’un utilisateur sort depuis votre adresse IP. Les signalements d’abus et les demandes de la police arrivent donc chez le titulaire de cette adresse.

L’exit est le seul rôle qui ne convient pas à un VPS généraliste. N’exécutez un exit que chez un fournisseur qui a accepté à l’avance de recevoir ces messages, avec sa propre adresse IP et un contact abuse publié. La plupart des conditions d’hébergement classiques l’interdisent. Si vous les ignorez, le résultat habituel est la suspension du serveur et la perte de l’adresse IP. Un guard ou un middle relay transporte le même trafic utilisateur sans cette exposition.

Tout ce qui suit configure un guard/middle relay. ExitRelay 0 est la ligne qui le maintient dans ce rôle.

Ce dont le VPS a besoin avant de commencer

Le projet Tor publie les exigences minimales applicables aux relais. En août 2026, elles sont les suivantes : une adresse IPv4 publique pour le relais, au moins 10 Mbit/s de bande passante dans chaque direction, avec 16 Mbit/s recommandés, au moins 100 GB de trafic sortant par mois, et 512 MB de RAM jusqu’à 40 Mbit/s ou 1 GB au-delà. Il n’existe pas de règle fixe concernant la disponibilité, mais un relais qui fonctionne moins de deux heures par jour est peu utile au réseau.

La valeur de 10 Mbit/s décrit la ligne, pas le paramètre de configuration. Vous avez besoin d’un port capable de fournir ce débit. La part de cette capacité que vous autorisez au relais est une décision distincte, à prendre en fonction du quota mensuel de transfert. Consultez votre offre avant de modifier la configuration. Si vous choisissez encore un serveur, ce que coûte réellement un VPS par mois explique comment les quotas de transfert sont vendus, et mesurer le débit réseau réel d’un VPS montre comment déterminer ce que fournit la ligne avec iperf3 au lieu de faire confiance à la page commerciale.

Sécurisez d’abord la machine. Un relais est un service public associé à une adresse publique, et cette adresse est analysée quelques minutes après sa publication. Restreindre SSH aux clés et renforcer la configuration de sshd prend dix minutes et doit être fait avant la mise en service du relais, pas après.

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

Utilisez le dépôt apt du Tor Project plutôt que le paquet de la distribution. Le code du relay évolue plus vite qu’une stable release. Les correctifs arrivent donc d’abord dans ce dépôt, tandis que le paquet de la distribution reste en retard entre deux releases.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Ajoutez la clé de signature, puis le dépôt. Le codename est lu depuis la machine. Le même bloc fonctionne donc sur Ubuntu 24.04 (noble) et Debian 13 (trixie).

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
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
tor --version

tor --version affiche la version que vous venez d’installer. Si apt update affiche plutôt une erreur NO_PUBKEY, la clé déchiffrée n’est pas située à l’emplacement indiqué dans la ligne Signed-By:. apt ne dispose donc d’aucune clé pour vérifier le fichier de release. Le paquet deb.torproject.org-keyring sera utile par la suite : il fournit la clé de signature sous forme de paquet standard. apt continue ainsi de fonctionner lorsque cette clé est renouvelée.

Activez les mises à niveau automatiques, puis indiquez-leur la nouvelle origine.

sudo apt install -y unattended-upgrades apt-listchanges

Sur Ubuntu, ajoutez l’origine Tor au bloc Allowed-Origins dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

Sur Debian, le même fichier utilise Origins-Pattern. La ligne à ajouter est "origin=TorProject";. Vérifiez le résultat avec sudo unattended-upgrade --debug --dry-run. Cette commande affiche les origines concernées et n’écrit rien.

Le torrc qui compte

Le paquet installe un /etc/tor/torrc long et abondamment commenté. Seules quelques lignes sont utiles pour un relay. Ajoutez-les à la fin du fichier.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname contient de 1 à 19 caractères, uniquement des lettres et des chiffres. Il n’est pas unique sur le réseau ; c’est le fingerprint qui l’est. C’est le nom qui vous permettra de retrouver votre propre relay dans un champ de recherche. Choisissez donc un nom que vous pouvez épeler au téléphone.

ContactInfo est publié dans le relay descriptor, un document public que n’importe qui peut télécharger. Cette adresse sera donc récupérée par des outils d’indexation. Utilisez une adresse que vous consulterez encore dans deux ans et obfusquez-la si vous le souhaitez. C’est le seul canal dont dispose le Tor Project pour vous avertir d’un problème avec votre relay.

ORPort 9001 est le port auquel se connectent les autres relays et les clients. 9001 est le choix habituel. Le port 443 est l’autre choix courant, car certains réseaux restrictifs autorisent uniquement les connexions sortantes vers 443. Un relay qui écoute sur ce port est donc accessible à davantage de clients. Choisissez 443 uniquement si aucun autre service de la machine n’en a besoin.

SocksPort 0 désactive le proxy SOCKS local, qu’un relay n’utilise pas, et supprime un socket en écoute sur la machine. ExitRelay 0 inscrit explicitement cette intention dans le fichier : ce relay ne se connectera jamais à une destination pour le compte d’un utilisateur. Une personne qui relira la configuration plus tard n’aura pas à le déduire de la valeur par défaut.

Si le VPS possède une adresse IPv6, ajoutez une seconde ligne ORPort. Tor ne peut pas se lier à une adresse IPv6 « quelconque » comme il le fait pour IPv4. Écrivez donc l’adresse entre crochets.

ORPort 9001
ORPort [2001:db8::1]:9001

Sur un VPS de 1 GB, ajoutez MaxMemInQueues 512 MB. Tor détermine la limite de sa file d’attente à partir de la mémoire disponible sur la machine. Sur une petite machine partagée, cette limite est supérieure à ce que vous souhaitez lui allouer. En définissant vous-même cette limite, vous forcez tor à supprimer les cellules en attente lorsque la mémoire est sous pression. Le relay peut ainsi continuer à fonctionner au lieu de consommer de la mémoire jusqu’à ce que le kernel tue le processus.

Ouvrir l’ORPort dans le pare-feu

En entrée, l’ORPort doit être accessible depuis n’importe quel point d’Internet. En sortie, laissez le relay sans restriction : il ouvre des connexions vers des milliers d’autres relays sur de nombreux ports différents, et une allowlist de connexions sortantes le rendrait progressivement inutilisable.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

Vérifiez ensuite le pare-feu réseau du fournisseur. De nombreux panneaux de contrôle exécutent un packet filter devant la machine virtuelle. Une règle ajoutée avec ufw n’y a donc aucun effet : le port apparaît ouvert sur la machine, mais fermé depuis l’extérieur. Si ufw vous est peu familier, les règles ufw à appliquer sur chaque VPS explique la policy par défaut et l’ordre dans lequel les règles sont évaluées.

Dimensionner la bande passante selon votre forfait

La documentation décrit RelayBandwidthRate comme un token bucket distinct qui limite « la bande passante entrante moyenne utilisée pour le trafic relayé sur ce nœud au nombre d’octets par seconde indiqué, et la bande passante sortante moyenne à cette même valeur ». Relisez cette phrase. La limite s’applique séparément à chaque direction. Un relais configuré à 1 Mbit/s peut transférer simultanément 1 Mbit/s en entrée et 1 Mbit/s en sortie. Un fournisseur qui facture les deux directions additionne ces deux volumes.

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

Ces 5 lignes sont des calculs, pas une mesure. Elles indiquent le volume consommé par un débit maintenu pendant 30 jours complets dans les deux directions. En pratique, un relais reste souvent sous sa limite, surtout pendant les premières semaines. Utilisez ce tableau pour écarter les paramètres incompatibles avec votre forfait, pas pour prévoir une facture au gigaoctet près.

À 1 Mbit/s dans chaque direction, un relais transfère environ 21.6 Go par jour. Sur 30 jours, cela représente environ 648 Go de trafic facturé. Ce volume tient dans une enveloppe de 1 To, avec une marge pour les mises à jour et les sauvegardes. Avec 2 Mbit/s, le mois représente 1,296 Go, soit déjà plus qu’un forfait de 1 To. La dernière ligne, 20 Mbit/s, nécessite 12,960 Go par mois et doit être utilisée sur un port non facturé au volume. Si votre fournisseur facture uniquement le trafic sortant, divisez chaque valeur par deux. Vérifiez ce point avant de définir le débit, car les deux modes de facturation diffèrent d’un facteur deux.

Passons maintenant à la configuration. Définissez d’abord la limite de débit, puis le quota.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst correspond à la taille du token bucket. Il autorise donc de courtes pointes au-dessus du débit défini, tout en maintenant la moyenne dans la limite. Une valeur d’environ deux fois le débit constitue un choix raisonnable.

AccountingRule est la ligne que la plupart des opérateurs oublient. La valeur par défaut est max. Elle compare au quota la plus grande des deux directions. Avec cette valeur par défaut, AccountingMax 400 GBytes autorise 400 Go en entrée et 400 Go en sortie, soit 800 Go sur un compteur qui comptabilise les deux directions. AccountingRule sum additionne les lectures et les écritures dans un quota unique, ce qui correspond à la mesure réelle d’une enveloppe de transfert.

Ajoutez également AccountingStart, et n’utilisez jamais AccountingMax seul. Le quota indique le volume autorisé. La ligne de début indique la date de réinitialisation de la période. Sans période, le relais reste en hibernation et rien ne permet de le réactiver.

L’hibernation est une mesure brutale. Lorsque le quota est épuisé, tor l’enregistre dans les journaux et cesse d’accepter du travail :

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

Le relais ne se réactive pas exactement au début de la période suivante. Tor calcule la vitesse à laquelle le dernier quota a été consommé, puis choisit un instant aléatoire dans le nouvel intervalle. Ainsi, des milliers de relais ne rejoignent pas le réseau à la même seconde. Un relais qui disparaît pendant la dernière semaine de chaque mois perd progressivement la stabilité évaluée par les autorités de répertoire. Dimensionnez RelayBandwidthRate de sorte que la limite ne soit jamais atteinte, et conservez AccountingMax comme filet de sécurité pour protéger votre facture.

Démarrer le relais et vérifier qu’il est joignable

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

Dans les minutes qui suivent, le journal doit contenir cette ligne :

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Cette phrase signifie que d’autres relais se sont connectés à votre ORPort et ont établi un circuit via celui-ci. Tant qu’elle n’apparaît pas, votre relais ne figure pas dans l’annuaire et ne transporte absolument aucun trafic. L’échec se présente ainsi :

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Procédez dans l’ordre. L’ORPort est-il ouvert dans ufw ? Est-il également ouvert dans le pare-feu réseau distinct du fournisseur ? L’adresse indiquée dans ce message est-elle bien l’adresse vers laquelle Internet achemine réellement le trafic, et non une adresse privée provenant d’une configuration NAT ? Testez le port depuis une autre machine avec nc -vz 203.0.113.10 9001. Tor répète automatiquement le test de connectivité. Il détecte donc un pare-feu corrigé sans intervention de votre part, et un redémarrage permet de relancer immédiatement le test.

L’identité permanente de votre relais est son empreinte :

sudo cat /var/lib/tor/fingerprint

Environ trois heures après la publication du descripteur, le relais apparaît dans Relay Search. Recherchez le nickname ou collez l’empreinte. Cette page indique ce que le réseau pense de votre relais : les flags qu’il possède, le poids que les autorités lui attribuent et la version qu’il publie.

Pourquoi un nouveau relais Tor a-t-il presque aucun trafic ?

Parce que le réseau ne l’a pas encore mesuré, et que cette mesure prend plusieurs semaines. Le Tor Project décrit la montée en charge en quatre phases. Un opérateur qui ne l’a pas lu conclut que le relais est défaillant et commence à modifier sa configuration.

Pendant les trois premiers jours, le relais n’est pas mesuré. Il publie le résultat de son propre test, mais les directory authorities plafonnent de toute façon son poids publié à 20 KB. Les clients le sélectionnent donc presque jamais. Entre le troisième et le huitième jour environ, les bandwidth authorities mesurent réellement sa capacité et son poids augmente. Il n’est toutefois utilisé que comme middle hop, car aucun client n’accepte de faire d’un relais tout nouveau son first hop.

Vers le huitième jour, le relais peut recevoir le flag Guard. L’attribution de ce flag fait baisser le trafic, ce qui surprend tout le monde. Lorsqu’ils choisissent des middle hops, les clients ignorent les guards, en partant du principe qu’un guard est déjà occupé. Le relais perd donc du trafic de type middle avant de gagner du trafic de type guard. Il ne reconstitue ce trafic que lorsque les clients renouvellent leurs ensembles de guards, ce qui prend plusieurs semaines. Vers le 68e jour, il atteint un régime stable : le nombre de clients qui le retirent équilibre celui des clients qui l’ajoutent.

L’attente réaliste est donc la suivante : rien pendant trois jours, un peu de trafic après une semaine, puis une charge réelle après deux mois. Modifiez un seul paramètre, puis attendez une semaine pour observer son effet. Une page d’état Uptime Kuma auto-hébergée avec un contrôle TCP sur le port 9001 est une meilleure façon d’utiliser cette énergie nerveuse : elle répond à la question que vous pouvez réellement contrôler, à savoir si le port répond toujours.

Surveillez le relais avec nyx

nyx est le moniteur de terminal d’un relais en cours d’exécution. Il communique avec le control port de Tor. Activez donc d’abord celui-ci dans torrc :

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort écoute uniquement sur 127.0.0.1. Avec l’authentification par cookie, un programme doit lire un fichier secret avant de pouvoir exécuter des commandes. Tor écrit ce cookie dans /run/tor/control.authcookie avec l’utilisateur debian-tor et le mode 600, afin qu’aucun autre utilisateur ne puisse le lire. CookieAuthFileGroupReadable 1 accorde l’accès au groupe. Votre propre compte peut ainsi exécuter nyx sans sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Déconnectez-vous, puis reconnectez-vous et exécutez nyx. Le nouveau groupe doit être pris en compte lors de la connexion. Si vous exécutez nyx dans la même session shell, une erreur de permission sur le fichier cookie s’affiche, même si la configuration est correcte. nyx affiche la bande passante en temps réel, la durée de fonctionnement, le flux des journaux et la liste des connexions. Pendant les premières semaines, surveillez surtout le graphique de la bande passante et vérifiez qu’il reste sous votre RelayBandwidthRate.

Exécuter plusieurs relais : MyFamily et les clés de famille

Si vous n’exécutez qu’un seul relais, ignorez cette section. Deux relais ou plus gérés par le même opérateur doivent se déclarer mutuellement. Les clients ne construiront ainsi jamais un circuit qui entre et sort par vos machines, ce qui permettrait à un même opérateur d’en voir les deux extrémités.

La méthode historique consiste à utiliser MyFamily dans le torrc de chaque relais et à y indiquer les fingerprints de tous les autres relais :

MyFamily AAAAAAAAAA,BBBBBBBB

Chaque relais indique tous les autres. L’ajout d’un quatrième relais nécessite donc de modifier quatre fichiers. Tor 0.4.9 a remplacé cette méthode par une clé de famille. Générez une clé, puis partagez-la :

tor --keygen-family myfamily

Cette commande écrit myfamily.secret_family_key et affiche une ligne FamilyId. Copiez le fichier de clé sur chaque relais, dans le sous-répertoire keys de DataDirectory (/var/lib/tor/keys sur Debian et Ubuntu), en conservant le suffixe .secret_family_key. Ajoutez la ligne FamilyId affichée à chaque torrc, puis rechargez la configuration avec sudo systemctl reload tor@default. Pour l’instant, conservez également la liste MyFamily. Les clients qui ne comprennent pas encore les certificats de famille continuent de lire la liste héritée. Le Tor Project annoncera quand elle pourra être supprimée.

Ce qui casse une fois le service en fonctionnement

La version devient obsolète. Les mises à niveau automatiques remplacent le paquet, mais le processus en cours continue d’utiliser le binaire avec lequel il a démarré jusqu’à son prochain redémarrage. Comparez tor --version sur le serveur avec la version affichée sur la page Relay Search du relais. Si elles diffèrent, le réseau utilise encore l’ancienne version. Redémarrez donc le service.

L’horloge dérive. Les documents de consensus et les certificats sont tous liés à une période de validité. Une machine dont l’horloge est fortement décalée rejette le consensus et cesse de publier. timedatectl doit indiquer que l’horloge système est synchronisée. Si ce n’est pas le cas, activez systemd-timesyncd ou installez chrony.

L’adresse IP change. Le descripteur contient l’adresse, et les clients ne peuvent pas joindre une adresse qui a changé. Après toute migration de fournisseur ou tout changement d’adresse, redémarrez tor et surveillez à nouveau la ligne d’auto-test.

Le relais est plus lent que ne le permet l’offre. La cryptographie des relais Tor est efficace sur les processeurs modernes. Le Tor Project estime qu’un processeur prenant en charge AES-NI atteint environ 400 à 450 Mbit/s dans chaque direction. Bien avant cette limite, le débit du port et le quota de transfert deviennent les facteurs limitants. C’est pourquoi la section précédente consacrée à la comptabilisation est plus importante que le matériel.

FAQ

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

Autant que vous l’autorisez, et pas davantage. RelayBandwidthRate limite séparément le trafic relayé dans chaque direction. Un relais configuré à 1 Mbit/s peut donc transporter simultanément 1 Mbit/s en entrée et 1 Mbit/s en sortie. Cela représente environ 21.6 Go par jour, ou 648 Go sur un mois de 30 jours, en comptant les deux directions. Ajoutez AccountingMax avec AccountingRule sum comme quota mensuel strict en dessous de ce débit.

L’exécution d’un relais Tor va-t-elle entraîner des plaintes pour abus ?

Un relais guard ou middle transmet le trafic uniquement à d’autres relais Tor. Il ne se connecte jamais à un site web pour le compte d’un utilisateur. Les plaintes concernant les actions effectuées via Tor sont donc adressées à l’opérateur du relais exit, et non à vous. Vous pouvez toutefois constater des scans et un classement occasionnel de l’adresse IP dans des listes de réputation, car cette adresse est publiée comme relais. Ce sont les relais exit qui reçoivent les messages d’abus et les notifications juridiques. Ils doivent utiliser un fournisseur ayant accepté à l’avance de les traiter. Lisez les conditions de votre fournisseur avant de démarrer l’un ou l’autre type de relais.

Pourquoi mon nouveau relais Tor ne reçoit-il pas de trafic ?

Parce que les nouveaux relais sont volontairement limités jusqu’à ce qu’ils soient mesurés. Pendant les trois premiers jours, les autorités d’annuaire limitent le poids publié à 20 KB. Les clients choisissent donc presque jamais le relais. Les autorités de mesure de la bande passante commencent à le mesurer vers le troisième jour. Il peut recevoir le flag Guard vers le huitième jour. Le trafic diminue de nouveau à ce moment-là, car les clients évitent les guards lorsqu’ils choisissent les hops middle. La charge complète arrive vers le jour 68. Vérifiez que le journal contient « Self-testing indicates your ORPort is reachable from the outside », puis n’intervenez plus.

Puis-je exécuter un relais Tor sur un VPS avec un quota de transfert de 1 TB ?

Oui, à environ 1 Mbit/s dans chaque direction, soit RelayBandwidthRate 125 KBytes. Cela représente environ 648 Go par mois si votre fournisseur comptabilise les deux directions. Il reste alors une marge pour les mises à jour et les sauvegardes. Ajoutez AccountingMax 400 GBytes avec AccountingRule sum et AccountingStart month 1 00:00 afin que le relais passe en hibernation au lieu de dépasser le quota. Si le fournisseur facture uniquement le trafic sortant, vous pouvez doubler le débit.

Dois-je définir MyFamily si je n’exécute qu’un seul relais ?

Non. Les déclarations de famille permettent aux clients d’éviter de construire un circuit passant par deux relais appartenant au même opérateur. Cela n’a aucun intérêt avec un seul relais. Définissez cette configuration dès que vous ajoutez un deuxième relais : indiquez l’empreinte de chaque relais dans la ligne MyFamily de tous les relais, ou utilisez la clé de famille introduite par Tor 0.4.9. Celle-ci distribue un seul FamilyId au lieu d’une liste qui ne cesse de s’allonger.