Configurer 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 dotée d’une adresse IP publique. Il relaie le trafic chiffré d’autres personnes. 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 ordinaire. Un relais transporte le trafic d’autres personnes et ne publie rien en son propre nom. Si vous voulez mettre votre propre site sur le réseau au lieu de relayer ses paquets, exécuter un service onion v3 derrière nginx est une tâche différente pour le même daemon tor. L’exécution d’un relais n’améliore pas non plus la confidentialité de votre propre navigation. C’est un problème distinct, avec des limites plus faibles que ne le pensent la plupart des utilisateurs : ce que l’auto-hébergement de SearXNG masque réellement donne une bonne idée de ce que vous apporte le déplacement d’un service sur votre propre VPS.

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 concerne les points qui posent problème : le calcul de la bande passante avec une offre facturée au volume, ainsi que la raison pour laquelle un relais neuf et parfaitement fonctionnel semble inactif pendant une semaine.

Garde, relais intermédiaire, pont ou sortie : choisissez avant l’installation

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

• Relais intermédiaire. Il reçoit le trafic d’un relais de garde et le transmet à un autre relais. Il ne contacte jamais un site de destination. Chaque nouveau relais commence par ce rôle.
• Relais de garde. Il utilise la même configuration, avec un flag supplémentaire. Les directory authorities attribuent le flag Guard aux relais qui sont rapides et stables depuis assez longtemps. Vous ne le choisissez pas. Vous l’obtenez avec le temps, et la configuration ci-dessous permet de l’obtenir.
• Pont. Il s’agit d’un relais volontairement exclu du directory public et communiqué 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 un bon premier choix si votre projet est limité. Il nécessite également un proxy obfs4 exécuté à côté du daemon et un autre ensemble de lignes torrc. Configurer un pont obfs4 sur un VPS économique explique la procédure, notamment la façon de communiquer la ligne du pont aux utilisateurs à la fin.
• Relais de sortie. C’est le dernier hop. Il ouvre la connexion vers le site de destination. Chaque requête effectuée par un utilisateur sort depuis votre adresse IP. Les signalements d’abus et les demandes des services de police arrivent donc chez le titulaire de cette adresse.

Le relais de sortie est le seul rôle qui ne doit pas être exécuté sur un VPS généraliste. Exécutez un relais de sortie uniquement chez un provider 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 standard l’interdisent. Si vous ignorez cette règle, le résultat habituel est la suspension du serveur et la perte de l’adresse IP. Si vous souhaitez malgré tout assurer ce rôle, ce qu’implique réellement l’exécution d’un relais de sortie explique comment trouver un hébergeur qui l’autorise, rédiger l’exit policy et le reverse DNS, puis répondre aux messages lorsqu’ils arrivent. Un relais de garde ou un relais intermédiaire transporte le même trafic utilisateur sans cette exposition.

Tout ce qui suit configure un relais de garde/intermédiaire. 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 des exigences strictes pour les 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 d’uptime fixe, 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. Vous avez besoin d’un port capable de l’atteindre. 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 commercialisés, et mesurer le débit réseau réel d’un VPS montre comment vérifier ce que la ligne fournit avec iperf3 au lieu de faire confiance à la page commerciale.

Sécurisez d’abord la machine. Un relais est un service public accessible à une adresse publique, et cette adresse est analysée dans les minutes qui suivent sa publication. Limiter 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 projet Tor

Utilisez le dépôt apt du projet Tor plutôt que le paquet de la distribution. Le code du relais évolue plus rapidement qu’une version stable. Les correctifs arrivent donc d’abord dans ce dépôt, tandis que le paquet de la distribution reste en retard entre deux versions.

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

Ajoutez la clé de signature, puis le dépôt. Le nom de code est lu sur 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 a affiché une erreur NO_PUBKEY à la place, la clé convertie au format dearmored ne se trouve pas au chemin indiqué dans la ligne Signed-By:. apt ne dispose donc d’aucune clé pour vérifier le fichier de version. Le paquet deb.torproject.org-keyring sera utile ensuite : il fournit la clé de signature sous forme de paquet ordinaire. apt continue ainsi de fonctionner lorsque cette clé est renouvelée.

Activez les mises à niveau automatiques, puis ajoutez cette nouvelle origine à leur configuration.

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 long fichier /etc/tor/torrc abondamment commenté. Seules quelques lignes sont nécessaires 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 descripteur du relay. Il s’agit d’un document public que n’importe qui peut télécharger. Cette adresse sera donc récupérée automatiquement. Utilisez une adresse que vous consulterez encore dans deux ans et masquez-la si vous le souhaitez. C’est le seul moyen dont dispose le Tor Project pour vous avertir d’un problème avec votre relay.

ORPort 9001 est le port auquel les autres relays et les clients se connectent. 9001 est le choix habituel. Le port 443 est l’autre choix courant : certains réseaux restrictifs autorisent uniquement les connexions sortantes vers 443, ce qui permet à davantage de clients d’atteindre un relay qui écoute sur ce port. Choisissez 443 uniquement si aucun autre service sur 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 indique explicitement cette intention dans le fichier : ce relay ne se connectera jamais à une destination au nom d’un utilisateur. Toute personne qui consultera 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 deuxième ligne ORPort. Tor ne peut pas s’attacher à « n’importe quelle » adresse IPv6 comme il le fait avec 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 un petit serveur partagé, cette limite est supérieure à ce que vous souhaitez lui laisser utiliser. Définir vous-même cette limite permet à Tor de supprimer les cellules en attente sous pression. Le relay peut ainsi continuer à fonctionner au lieu de faire croître la file jusqu’à ce que le kernel tue le processus.

Ouvrir l’ORPort dans le firewall

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 en sortie le rendra progressivement inutilisable sans message d’erreur.

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

Vérifiez ensuite le firewall 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’a aucun effet à ce niveau. Le port apparaît alors comme ouvert sur la machine, mais fermé depuis l’extérieur. Si ufw ne vous est pas 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.

Dimensionnez la bande passante en fonction de votre forfait

Le manuel décrit RelayBandwidthRate comme un token bucket distinct qui limite « la consommation moyenne de bande passante entrante pour le trafic relayé sur ce nœud au nombre d’octets par seconde indiqué, et la consommation moyenne de bande passante sortante à 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 comptabilise les deux directions facture donc leur somme.

[
  {
    "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 relèvent de l’arithmétique, pas de la mesure : elles indiquent le coût d’un débit maintenu pendant 30 jours complets dans les deux directions. En pratique, un relais reste souvent sous son plafond, surtout pendant les premières semaines. Utilisez ce tableau pour écarter les configurations incompatibles avec votre budget, 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. Un mois de 30 jours représente donc environ 648 Go de trafic comptabilisé. Cela 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, ce qui dépasse déjà 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 ne facture que le trafic sortant, divisez chaque valeur par deux. Vérifiez ce point avant de définir le débit, car les deux résultats diffèrent d’un facteur deux.

Passons maintenant à la configuration. Limitez d’abord le débit, puis définissez 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, tant que la moyenne reste conforme. Une valeur proche de deux fois le débit est raisonnable.

AccountingRule est la ligne que la plupart des opérateurs oublient. La valeur par défaut est max. Elle compare la plus grande des deux directions au quota. 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.

Écrivez également AccountingStart, et jamais AccountingMax seul. Le quota définit la valeur numérique. La ligne de début définit la période pendant laquelle il est réinitialisé. Un quota sans période laisse le relais en veille, sans mécanisme pour le réactiver.

La mise en veille 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 non plus exactement au début de la période suivante. Tor mesure la vitesse à laquelle le dernier quota a été consommé, puis choisit un moment aléatoire dans le nouvel intervalle. Ainsi, des milliers de relais ne réintègrent 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é que les autorités d’annuaire mesurent. Dimensionnez RelayBandwidthRate de sorte que le plafond ne soit jamais atteint, et conservez AccountingMax comme garde-fou pour protéger la facture.

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

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

Après quelques minutes, 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 le répertoire et ne transporte 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.

Vérifiez les points suivants 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 fournie par une configuration NAT ? Testez le port depuis une autre machine avec nc -vz 203.0.113.10 9001. Tor répète automatiquement l’auto-test. Un problème de pare-feu corrigé est donc détecté sans intervention supplémentaire, et un redémarrage rend le test immédiat.

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 présente la façon dont le réseau considère 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 ne transporte-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 cette montée en charge en quatre phases. Un opérateur qui ne les a pas lues peut conclure que le relais est défectueux et commencer à modifier sa configuration.

Pendant les trois premiers jours, le relais n’est pas mesuré. Il publie le résultat de son propre autotest, mais les autorités d’annuaire plafonnent de toute façon le poids publié à 20 KB. Les clients le sélectionnent donc presque jamais. Entre environ le troisième et le huitième jour, les autorités de bande passante le mesurent réellement et son poids augmente. Il n’est toutefois utilisé que comme nœud intermédiaire, car aucun client n’accepte de faire d’un relais tout récent son premier saut.

Vers le huitième jour, le relais peut obtenir le drapeau Guard. L’obtention de ce drapeau entraîne une baisse du trafic, ce qui surprend souvent : lors du choix des nœuds intermédiaires, les clients ignorent les relais Guard, en supposant qu’un guard est déjà occupé. Le relais perd donc du trafic intermédiaire avant de gagner du trafic Guard. Il ne récupère ce trafic que lorsque les clients renouvellent leur ensemble de guards, ce qui prend plusieurs semaines. Vers le 68e jour, il atteint un état stable : le nombre de clients qui le retirent de leur sélection compense celui des clients qui l’y 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 inquiétude : elle répond à la question que vous pouvez réellement contrôler, à savoir si le port répond toujours.

Surveiller le relais avec nyx

nyx est le moniteur dans le terminal d’un relais en fonctionnement. Il communique avec le port de contrôle de Tor. Activez donc d’abord ce port dans torrc :

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort écoute uniquement sur 127.0.0.1. L’authentification par cookie oblige un programme à 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 que personne d’autre ne puisse le lire. CookieAuthFileGroupReadable 1 rend le fichier accessible 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. Exécutez ensuite nyx. Le nouveau groupe doit être pris en compte à la connexion. Si vous exécutez nyx dans la même session shell, vous obtenez une erreur de permission sur le fichier cookie, 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

Avec un seul relais, ignorez cette section. Deux relais ou plus exploités par le même opérateur doivent se déclarer mutuellement. Ainsi, les clients ne construisent jamais un circuit qui entre et sort par vos machines. Sinon, un même opérateur pourrait voir ses deux extrémités.

La méthode utilisée depuis longtemps consiste à définir MyFamily dans le torrc de chaque relais, en y indiquant les empreintes de tous les autres relais :

MyFamily AAAAAAAAAA,BBBBBBBB

Chaque relais répertorie 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 distribuez-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 du 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 utilisent toujours l’ancienne liste. Le Tor Project indiquera quand elle pourra être supprimée.

Ce qui se dérègle une fois le service en fonctionnement

La version devient obsolète. Les mises à niveau automatiques remplacent le package, mais le processus en cours continue d’utiliser le binaire avec lequel il a démarré tant qu’il n’est pas redémarré. 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 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 donc 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 chez le fournisseur ou tout changement d’adresse, redémarrez tor et attendez de voir à nouveau la ligne d’auto-test.

Le relais est plus lent que ce qu’autorise l’offre. La cryptographie des relais Tor est efficace sur les processeurs modernes. Le Tor Project estime qu’un processeur compatible AES-NI atteint environ 400 à 450 Mbit/s dans chaque sens. Bien avant cette limite, le débit du port et le quota de transfert deviennent les facteurs limitants. C’est pourquoi la section sur la comptabilisation du trafic ci-dessus est plus importante que le matériel.

FAQ

Quelle quantité de 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 transmettre simultanément 1 Mbit/s en entrée et 1 Mbit/s en sortie. Cela représente environ 21.6 Go par jour, soit 648 Go sur un mois de 30 jours, en comptant les deux directions. Ajoutez AccountingMax avec AccountingRule sum comme quota mensuel strict sous cette limite.

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 envoyées à l’opérateur du relais exit, et non à vous. Vous pouvez en revanche observer des scans et voir occasionnellement l’adresse IP inscrite sur une liste de réputation, car elle est publiée comme adresse de relais. Les relais exit reçoivent les messages d’abus et les notifications juridiques. Ils doivent choisir un fournisseur qui a accepté à l’avance de les traiter. Consultez 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 aucun trafic ?

Parce que les nouveaux relais sont volontairement limités tant qu’ils n’ont pas été mesurés. Pendant les trois premiers jours, les autorités d’annuaire limitent le poids publié à 20 KB. Les clients sélectionnent donc presque jamais ce relais. Les autorités de bande passante le mesurent à partir d’environ trois jours. Il peut alors obtenir 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 laissez le relais fonctionner sans intervenir.

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, ce qui correspond à 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-la dès que vous ajoutez un deuxième relais : indiquez l’empreinte de chaque relais dans la ligne MyFamily de chaque 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 s’allonge continuellement.