Guide pour exploiter un nœud de sortie Tor

Ce que fait un nœud de sortie Tor et ce que cela implique pour vous

Un nœud de sortie Tor est le dernier relais d’un circuit : c’est la machine qui ouvre la connexion vers la destination. La destination journalise donc l’adresse de votre serveur, jamais celle de l’utilisateur. Toutes les autres décisions de ce guide découlent de ce fait. Cette adresse est considérée comme la source de tout le trafic qui la traverse. Elle doit donc être dédiée à cette fonction et hébergée par un provider qui a accepté de transporter ce trafic.

Exploiter un nœud de sortie est l’opposé de se cacher. Le relais figure dans un annuaire public que n’importe qui peut télécharger. Votre adresse de contact apparaît dans cet annuaire sous ContactInfo. Votre nom reverse DNS (domain name system) indique ce qu’est la machine. Le port 80 sert une page qui l’indique également. Vous répondez vous-même aux e-mails d’abuse, sous votre propre nom. Dans ce système, personne n’est plus identifiable qu’un opérateur de nœud de sortie. C’est le rôle d’un nœud de sortie, et c’est pour cela qu’il fonctionne.

Nous exploitons ce type de nœuds. SSD Nodes opère des relais de sortie dans plusieurs pays pour contribuer à la liberté d’expression. Nous louons ces machines auprès de providers qui ont volontairement accepté le trafic de sortie. Nous ne sommes pas leur provider. C’est un choix délibéré, et la section suivante en explique la raison.

Où un exit est approprié, et où il ne l’est pas

Un exit n’a pas sa place sur un VPS (virtual private server) généraliste, et cela vaut aussi pour les nôtres. Un réseau généraliste héberge les sites web, les e-mails, les sauvegardes et les panneaux de contrôle de milliers de clients sans lien entre eux, sur des adresses voisines. Le trafic d’un exit fait apparaître l’une de ces adresses dans des rapports de scan et des blocklists antispam. Les conséquences touchent alors les voisins. Les fournisseurs qui hébergent correctement des exits ont prévu une infrastructure adaptée : des plages d’adresses réservées à cet usage et une équipe abuse qui connaît déjà Tor.

Un hébergeur qui rédige ce guide vous dit donc d’acheter la machine ailleurs. C’est la partie utile. Nous savons ce que le trafic d’un exit fait subir à une adresse, car nous payons d’autres personnes pour transporter le nôtre. Nous les payons parce que le transporter correctement est un métier différent de la vente de serveurs généralistes.

Le Tor Project dit la même chose plus directement. Sa page sur les types de relais indique que les relais exit « have the greatest legal exposure and liability of all the relays » et que « you should not run a Tor exit relay from your home ». Un VPS généraliste qui héberge vos propres projets est plus proche de votre domicile qu’il n’y paraît. C’est une machine à laquelle vous tenez, sur une adresse que vous voulez conserver propre.

Si vous avez un VPS ordinaire et que vous voulez aider le réseau cette semaine, exécutez-y un relais non-exit ou un bridge. Ce n’est pas une solution de second rang. C’est une fonction différente, avec un profil de risque différent, et le réseau a besoin des deux. Un relais non-exit n’ouvre jamais de connexion vers une destination. Il génère donc presque aucune plainte. Les recommandations de Tor demandent au moins 2 MByte/s (mégaoctets par seconde) dans chaque direction avant de le référencer. Un bridge est un point d’entrée non référencé pour les utilisateurs de réseaux soumis à la censure. Il nécessite une connectivité 24/7 et un port TCP (transmission control protocol) ouvert, ce qui en fait l’usage le plus utile qu’une petite machine puisse avoir. Ces deux rôles ont leur place sur du matériel que vous possédez déjà. Un exit, non.

Comment trouver un fournisseur favorable aux nœuds de sortie ?

Posez la question avant de commander, par écrit, et conservez la réponse. Les recommandations de Tor pour les nœuds de sortie suggèrent de procéder en deux étapes : demandez d’abord si le fournisseur accepte un nœud de sortie Tor, puis s’il lui attribuera une adresse ou une plage dédiée. Poser les deux questions en même temps entraîne souvent un refus réflexe.

Quatre questions permettent de savoir si un fournisseur est réellement préparé à ce fonctionnement.

• Pouvez-vous attribuer une adresse IP dédiée, qui n’hébergera rien d’autre, et définir l’enregistrement DNS inverse que je vous indiquerai ?
• Qui reçoit les e-mails d’abus, et pouvez-vous me les transférer sans modification, en conservant l’adresse de l’expéditeur afin que je puisse lui répondre directement ?
• Que se passe-t-il lors de la première plainte : me la transférez-vous, ou mettez-vous d’abord l’adresse en null-route avant de demander des explications ?
• Combien de nœuds de sortie sont déjà présents sur ce réseau ? Les recommandations de Tor sont claires à ce sujet : « il n’est pas utile de regrouper trop de nœuds de sortie chez un même fournisseur d’hébergement favorable ».

Cette dernière question est plus importante qu’il n’y paraît. Une partie de la valeur d’un nœud de sortie dépend de son emplacement sur le réseau. Un autre nœud de sortie sur un réseau qui en héberge déjà cinquante apporte moins que la même machine placée dans un nouvel emplacement. Relay Search indique quels réseaux hébergent déjà des nœuds de sortie ; vous pouvez donc vérifier ce point avant de vous engager.

Obtenez les réponses avant de payer, et achetez la machine avec un compte distinct plutôt que de l’ajouter au compte qui héberge vos autres serveurs. La sécurité d’un hébergement VPS dépend principalement de ce que vous placez à côté de quoi, et cet exemple l’illustre particulièrement bien.

Une adresse, un seul rôle

L’adresse de sortie ne doit héberger aucun autre service. Ni site web, ni messagerie, ni VPN, ni tableau de bord de supervision, ni bastion SSH (secure shell) personnel. Cette adresse finira dans des blocklists, et tout autre service qui y réside commencera à rencontrer des problèmes difficiles à diagnostiquer. Une adresse dédiée à une seule fonction permet aussi de répondre simplement aux réclamations : cette adresse est un relais de sortie, rien d’autre.

Avant d’installer tor, effectuez les opérations habituelles. Utilisez SSH avec authentification par clé uniquement et désactivez l’authentification par mot de passe. Configurez également un pare-feu qui n’autorise que les ports publiés. Sécuriser SSH sur un VPS couvre le premier point et Notions de base sur le pare-feu ufw couvre le second. Un relais de sortie ne publie que deux ports sur Internet : l’ORPort, qui transporte le trafic Tor, et le port 80 pour la page d’information du relais. Tous les autres ports restent fermés.

Activez les mises à niveau automatiques, car un relais de sortie exécutant une ancienne version de tor pose un problème à chaque utilisateur dont le trafic y transite.

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

N’ajoutez pas de journalisation. Capturer en clair les données qui quittent un relais de sortie est techniquement facile. C’est précisément ce qu’un opérateur ne doit jamais faire. La FAQ juridique de Tor de l’EFF le recommande aux opérateurs, car la législation américaine sur les écoutes et les lois comparables d’autres pays peuvent engager leur responsabilité s’ils examinent ce trafic. Conservez la journalisation par défaut de tor au niveau notice, et rien de plus.

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

Les paquets des distributions ont du retard. Utilisez le dépôt du projet Tor afin de recevoir les correctifs de sécurité dès leur publication. En août 2026, la série stable actuelle est la 0.4.9.

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

Saisissez /etc/apt/sources.list.d/tor.sources en remplaçant noble par le nom de code affiché par lsb_release -cs :

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

Ajoutez la clé de signature, puis installez :

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

Le paquet deb.torproject.org-keyring maintient automatiquement cette clé à jour. Le dépôt ne cesse donc pas de fonctionner le jour où la clé est renouvelée. Si apt update signale que le même dépôt est configuré deux fois, vous avez à la fois un fichier .list et un fichier .sources qui le déclarent. L’erreur de source deb822 en double explique comment supprimer ce doublon.

DNS : votre nœud de sortie résout les noms pour tous ses utilisateurs

Un nœud de sortie effectue les résolutions de noms pour chaque circuit qui en sort. Son resolver voit donc une suite de noms appartenant à d’autres personnes. Si vous l’orientez vers un resolver public de grande taille, vous transmettez toute cette suite à une seule entreprise. C’est précisément la centralisation que Tor demande aux opérateurs de nœuds de sortie d’éviter. Exécutez plutôt un resolver validant et cache localement sur le serveur.

sudo apt install -y unbound bind9-dnsutils
sudo cp /etc/resolv.conf /etc/resolv.conf.backup
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf
sudo systemctl enable --now unbound

chattr +i rend le fichier immuable, car les clients DHCP (dynamic host configuration protocol) et resolvconf réécrivent /etc/resolv.conf selon leur propre calendrier. Sans cette protection, un redémarrage peut réorienter vos résolutions vers le resolver du fournisseur, sans aucun avertissement. Les instructions Tor pour Debian et Ubuntu activent également la minimisation des noms de requête. Chaque serveur de noms ne reçoit ainsi que la partie du nom dont il a réellement besoin :

server:
    qname-minimisation: yes

Placez cette configuration dans un fichier sous /etc/unbound/unbound.conf.d/, puis vérifiez que le resolver répond :

sudo systemctl restart unbound
dig +short example.com @127.0.0.1

La présence d’une adresse dans la réponse indique qu’unbound fonctionne. Si unbound refuse de démarrer avec address already in use, un autre processus utilise le port 53. Exécutez sudo ss -lntup | grep :53 et vérifiez quel processus le détient. Sur Ubuntu, systemd-resolved écoute sur 127.0.0.53. Il n’entre donc pas en conflit avec unbound sur 127.0.0.1.

Le torrc d’un relais de sortie

Le paquet Debian lit /etc/tor/torrc. Il s’agit de toute la configuration liée à la sortie.

Nickname     exampleExit01
ORPort       443
ExitRelay    1
SocksPort    0
ContactInfo  email:tor[]example.org abuse:abuse[]example.org url:https://example.org ciissversion:3
ReducedExitPolicy 1
Log          notice syslog

Chaque ligne est indispensable. Examinez-les une par une.

ORPort 443 est le port auquel les autres relais se connectent. Le port 443 traverse les réseaux restrictifs qui bloquent les ports inhabituels. Votre relais est donc joignable par davantage de personnes qu’avec le port traditionnel 9001. Vous ne pouvez utiliser le port 443 que si aucun autre service de cette machine n’en a besoin. C’est un argument supplémentaire en faveur d’une adresse dédiée.

SocksPort 0 désactive le proxy SOCKS local. Un relais n’en a jamais besoin. Un port SOCKS en écoute sur une adresse publique constitue un proxy ouvert, qui sera découvert et utilisé abusivement en quelques heures.

ExitRelay 1 active le mode sortie. Définissez-le explicitement au lieu de dépendre d’une valeur par défaut. Le fichier de configuration indique ainsi clairement le rôle de la machine.

ContactInfo est publié dans l’annuaire public, où tout le monde peut le lire. Rédigez-le au format ContactInfo Information Sharing Specification, que les outils du réseau savent analyser, et conservez ciissversion:3 dedans. Le [] à la place de @ est la convention utilisée par cette spécification pour ralentir les outils de collecte d’adresses. Utilisez une boîte aux lettres que vous consultez chaque jour, car c’est là que vous recevrez les messages liés aux abus.

Si la machine dispose d’un IPv6 fonctionnel, ajoutez un IPv6 ORPort et activez la sortie IPv6. Laissez ces deux éléments absents dans le cas contraire. Un relais qui publie une adresse qu’il ne peut pas réellement utiliser échoue à son propre test de joignabilité.

ORPort   [2001:db8::1]:443
IPv6Exit 1

Politique de sortie : ce que chaque port autorise

La politique de sortie est la liste des destinations auxquelles votre relay accepte de se connecter. Tor la lit de haut en bas et applique la première règle correspondante. ReducedExitPolicy 1 sélectionne une liste adaptée d’environ soixante-dix ports couvrant le Web, la soumission de courriels, la messagerie instantanée et Git. Elle exclut les ports qui génèrent le plus de plaintes. C’est un bon point de départ pour un premier relay de sortie.

Deux règles méritent d’être connues par leur nom. ExitPolicyRejectPrivate est activée par défaut. Elle empêche le relay de sortie de se connecter aux plages d’adresses privées et aux propres adresses du relay. Cela évite que votre relay de sortie soit utilisé pour atteindre le réseau interne de votre fournisseur. Le port 25 (SMTP, protocole simple de transfert de courrier) est refusé et doit le rester. L’autoriser transformerait le relay en source de spam, et l’adresse serait ajoutée aux blocklists en quelques jours.

Un relay de sortie doit autoriser les ports 80 et 443 pour être réellement utile. La documentation Tor sur les relays de sortie l’indique explicitement comme exigence minimale. Si votre fournisseur exige une politique plus restrictive que la politique réduite, un relay de sortie limité au Web reste une contribution utile :

ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*

Terminez la liste par reject *:* afin que votre politique soit autonome et qu’aucune règle supplémentaire ne soit héritée. La politique réduite autorise le port 22 (SSH), qui est généralement à l’origine des signalements de brute force. Ajoutez donc ExitPolicy reject *:22 avant les autres règles si vous préférez ne pas recevoir ce type de courriels. Les ports de partage de fichiers compris entre 6881 et 6999 sont généralement à l’origine des notifications de violation de droits d’auteur. La politique réduite les exclut déjà.

Une modification de la politique n’est prise en compte par les clients qu’après la publication d’un nouveau descripteur par votre relay et sa propagation dans l’annuaire. Attendez donc quelques heures avant d’en évaluer l’effet.

Contact, clés de famille et enregistrement du relais

Enregistrer un relais de sortie consiste à l’associer à un nom qu’un tiers peut vérifier. Deux mécanismes permettent cela, et ils fonctionnent ensemble.

Le premier est un fichier bien connu. Publiez l’identité de votre famille sur un domaine que vous contrôlez, puis indiquez cette preuve dans ContactInfo :

ContactInfo email:tor[]example.org url:https://example.org proof:uri-familyid-ed25519 ciissversion:3

Le fichier se trouve à https://example.org/.well-known/tor-relay/ed25519-family-id.txt et contient l’identifiant de votre famille. N’importe qui peut alors confirmer que la personne qui revendique ces relais contrôle également ce domaine. C’est ce qui distingue une adresse de contact d’une adresse vérifiée.

Le second mécanisme est la famille elle-même. Si vous exploitez plusieurs relais, le réseau doit savoir qu’ils appartiennent au même opérateur. Un client ne construira ainsi jamais un circuit passant par deux de vos machines. Les versions actuelles de tor utilisent pour cela une clé de famille, appelée Happy Families, sur les relais exécutant la version 0.4.9.2-alpha ou ultérieure :

tor --keygen-family exampleFamily

Cette commande écrit exampleFamily.secret_family_key et affiche une ligne FamilyId. Copiez le fichier de clé secrète dans le répertoire de clés de chaque relais (/var/lib/tor/keys sur Debian et Ubuntu), conservez le suffixe .secret_family_key du nom de fichier, ajoutez la ligne FamilyId affichée dans chaque fichier torrc, puis rechargez tor. La documentation de tor précise que vous devez toujours définir l’option historique MyFamily, qui répertorie l’empreinte de chaque relais, jusqu’à ce que le projet annonce qu’elle n’est plus nécessaire. Configurez donc les deux options. L’empreinte de chaque relais se trouve dans /var/lib/tor/fingerprint.

C’est avec la deuxième et la troisième machine que l’exploitation commence à devenir importante. La gestion de plusieurs serveurs Linux à la fois pose ici le même problème qu’ailleurs. Sauvegardez /var/lib/tor/keys hors de la machine. Si vous le perdez, le relais redevient inconnu et doit regagner tous ses flags ainsi que toute sa réputation à partir de zéro.

Abonnez-vous également à la liste de diffusion tor-relays. Les changements qui concernent les opérateurs y sont annoncés en premier.

Le reverse DNS et la page d’information de sortie sur le port 80

Définissez l’enregistrement DNS inverse avant que le relay ne transporte du trafic. Les recommandations de Tor pour les exits demandent d’indiquer la fonction de la machine, par exemple avec tor-exit-01.example.org. La raison est pratique. Lorsqu’une adresse inconnue apparaît dans les journaux d’une personne, son administrateur effectue généralement une résolution inverse. Un nom contenant « tor-exit » répond à la question avant que quiconque ne vous écrive. Une partie des réclamations potentielles ne donne ainsi lieu à aucune réclamation. Demandez à votre fournisseur de définir l’enregistrement PTR (pointer), puis ajoutez un enregistrement direct correspondant de votre côté.

Servez ensuite sur le port 80 une page d’information qui dit la même chose explicitement. Les anciens guides utilisent pour cela le paramètre DirPortFrontPage de Tor, qui dépend d’un DirPort. DirPort est obsolète pour les relays depuis tor 0.4.6.5 ; utilisez donc plutôt un petit serveur web.

sudo apt install -y nginx
sudo install -d -m 755 /srv/tor-exit-notice

Écrivez /srv/tor-exit-notice/index.html :

<!DOCTYPE html>
<html>
<head><title>This is a Tor exit relay</title></head>
<body>
<h1>This is a Tor exit relay</h1>
<p>Traffic from this address was sent by a user of the Tor network. It did not
come from the operator of this machine, and this machine keeps no record of
who sent it.</p>
<p>Operator: Example Org. Abuse reports: abuse@example.org. Every report gets a
reply from a person.</p>
<p>To check whether this address was a Tor exit at a given date and time:
https://metrics.torproject.org/exonerator.html</p>
</body>
</html>

Écrivez ce bloc de serveur dans /etc/nginx/sites-available/tor-exit-notice :

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    root /srv/tor-exit-notice;
    index index.html;
    access_log off;
}

Activez-le, supprimez le site par défaut de nginx, puis vérifiez le résultat :

sudo ln -sf /etc/nginx/sites-available/tor-exit-notice /etc/nginx/sites-enabled/tor-exit-notice
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
curl -s http://127.0.0.1/ | head -n 5

Si nginx -t indique syntax is ok et test is successful, cela signifie que le fichier est syntaxiquement valide. La commande curl doit afficher les premières lignes de votre page d’information. Si elle affiche à la place la page d’accueil de nginx, le site par défaut est toujours activé et votre bloc n’est pas utilisé.

Démarrez-le, puis consultez le journal

sudo systemctl restart tor@default
sudo journalctl -u tor@default -n 50 --no-pager

Après quelques minutes, le journal doit contenir la ligne indiquant que les autres relais peuvent vous joindre :

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

Si cette ligne n’apparaît jamais, l’ORPort n’est pas accessible. Vérifiez que tor est en écoute avec sudo ss -lntp | grep 443, puis testez le port depuis une autre machine avec nc -vz your.address.here 443. Un pare-feu devant le VPS, qu’il soit local ou configuré dans le panneau de contrôle du fournisseur, est généralement en cause.

Vérifiez que le service redémarre après un reboot avec systemctl is-enabled tor. La commande doit afficher enabled.

Le relais apparaît dans Relay Search environ trois heures après son démarrage, avec le nickname choisi. Le trafic augmente ensuite sur plusieurs jours, car la mesure de bande passante du réseau doit observer votre relais avant de lui accorder un poids important. Il est normal qu’un nouvel exit transporte presque aucun trafic le premier jour.

Le guide de gestion des abus et le contenu des messages

Rédigez le guide de gestion avant de recevoir la première plainte, car elle arrive généralement dès la première semaine. La plupart de ces messages sont générés automatiquement. Les recommandations de Tor concernant les nœuds de sortie estiment que les rapports automatisés représentent environ 80% du total. Une réponse standard suffit pour traiter la plupart des autres cas.

Voici ce que vous recevrez réellement. Un rapport d’analyse ou de brute force produit par le système de détection d’intrusion d’un tiers, qui cite votre adresse et un horodatage. Un avis de violation du droit d’auteur, si votre politique autorise les ports de partage de fichiers. Une plainte pour spam dans un forum ou dans des commentaires, envoyée par le propriétaire d’un site. Plus rarement, une demande de conservation de données ou une assignation émise par les autorités, ce qui relève d’une autre catégorie. À ce stade, consultez un avocat au lieu d’utiliser un modèle de réponse.

La réponse est courte et presque toujours identique :

Hello,

Thank you for the report. The address 203.0.113.10 is a Tor exit relay,
operated by <your name> at <your organisation>. The connection you saw was
made by a user of the Tor network. It did not originate on this machine.

This relay keeps no record of which user made which connection, so I cannot
identify the sender and there are no logs for me to hand over.

You can confirm that this address was a Tor exit at the date and time in
question here: https://metrics.torproject.org/exonerator.html

If you would prefer to stop Tor traffic reaching your service, the current
list of exit addresses is published here:
https://check.torproject.org/torbulkexitlist

I read this mailbox personally and will answer any follow-up.

<your name>

Quatre habitudes permettent de gérer ces messages. Répondez dans un délai d’un jour ouvré, depuis l’adresse indiquée dans ContactInfo, et signez de votre nom. Ne proposez jamais d’identifier un utilisateur, car vous ne le pouvez pas. Un opérateur qui laisse entendre le contraire devra ensuite revenir sur cette promesse. Conservez toutes les réponses dans un même dossier, afin qu’un second message concernant le même incident reçoive la même réponse. Si le fournisseur vous transmet une plainte accompagnée d’un avertissement de suspension, répondez d’abord au fournisseur, puis à l’auteur du signalement.

Deux liens sont essentiels dans ces réponses. ExoneraTor répond à la question que se pose réellement l’enquêteur : cette adresse était-elle un nœud de sortie Tor à ce moment précis ? La liste complète des nœuds de sortie est une liste simple des adresses de sortie actuelles, à raison d’une adresse par ligne. Elle s’adresse à ceux qui ont décidé de bloquer Tor et préfèrent le faire précisément plutôt que de procéder au hasard.

Bande passante, coût et deuxième relais

Les relais de sortie transportent du trafic réel. Définissez le plafond mensuel avant de commander et demandez comment le fournisseur facture le dépassement de l’allocation, car le coût réel d’un VPS dépend surtout du volume de transfert inclus, et non du prix affiché. Tor peut appliquer votre limite :

AccountingMax 4 TBytes
AccountingStart month 1 00:00
RelayBandwidthRate 20 MBytes
RelayBandwidthBurst 25 MBytes

AccountingMax met tor en hibernation après le transfert de ce volume pendant la période de facturation, puis le réactive au début de la période suivante. Comparez le premier mois avec le compteur du fournisseur avant de vous fier à cette valeur, car les deux compteurs ne comptabilisent pas toujours les mêmes octets. RelayBandwidthRate limite le débit soutenu, ce qui permet de garder la liaison montante utilisable et de rassurer le fournisseur.

Lorsque vous ajoutez un deuxième relais de sortie, placez-le sur un autre réseau plutôt que dans la même baie que le premier. La diversité est une grande partie de la contribution d’un relais de sortie, et deux machines situées au même endroit peuvent tomber en panne ensemble. Rattachez-les à une même famille, publiez le même contact vérifié pour les deux et répondez aux e-mails reçus sur les deux. Un relais de sortie que personne ne peut joindre est considéré comme un problème anonyme. Un relais dont l’opérateur répond le jour même est considéré comme un serveur géré par une personne, ce qui est effectivement le cas.

FAQ

Puis-je exécuter un nœud de sortie Tor sur un VPS que je possède déjà ?

Non. C’est le seul point sur lequel vous devez être strict. Un nœud de sortie a besoin d’une adresse dédiée qui n’héberge rien d’autre, chez un fournisseur ayant accepté à l’avance d’acheminer le trafic de sortie et de vous transférer les messages d’abus sans les modifier. Sur un VPS polyvalent, y compris le nôtre, cette adresse est déjà utilisée pour un autre service et partage son environnement avec des clients qui exécutent des services classiques. Exécutez plutôt un relay non-sortant ou un bridge obfs4 sur la machine que vous avez déjà. Ces services sont réellement utiles, génèrent presque aucun signalement et ne nécessitent rien de plus que le serveur que vous payez déjà.

Combien de messages d’abus un relay de sortie Tor reçoit-il, et qui les reçoit ?

Cela dépend de votre politique de sortie. Avec ReducedExitPolicy 1, le port 25 rejeté et les ports de partage de fichiers exclus, la plupart des messages reçus concernent des scans automatisés et des attaques par force brute. Les recommandations de Tor estiment que les rapports automatisés représentent environ 80% du total. Les messages sont envoyés à la personne à laquelle le service abuse du fournisseur les transfère. C’est pourquoi vous devez demander, avant de commander, s’il vous les transfère avec l’adresse de l’expéditeur intacte. Publiez la même adresse dans ContactInfo et sur la page d’information du port 80, puis répondez dans un délai d’un jour ouvré.

Dois-je publier mon vrai nom et mon adresse e-mail ?

Oui. ContactInfo est publié dans l’annuaire public des relays, que n’importe qui peut télécharger. Le nom DNS inverse indique ce qu’est la machine, et la page d’information du port 80 reprend ces informations. Cette transparence est prévue par la conception, et non un effet secondaire. Un nœud de sortie sans contact fonctionnel est considéré comme une nuisance anonyme, et certains clients excluent les nœuds de sortie qui ne publient aucun contact. Ajoutez proof:uri-familyid-ed25519 et le fichier /.well-known/tor-relay/ed25519-family-id.txt sur un domaine que vous contrôlez, afin que le contact soit vérifiable et pas seulement déclaré.

Pourquoi mon nouveau relay de sortie a-t-il presque aucun trafic ?

Vérifiez d’abord que journalctl -u tor@default contient Self-testing indicates your ORPort is reachable from the outside. Excellent., car un relay qui échoue au test d’accessibilité n’est jamais publié et ne transporte absolument aucun trafic. Si cette ligne est présente, la cause est généralement le délai. Un relay apparaît dans Relay Search environ trois heures après son démarrage, et les clients ne lui envoient un trafic significatif qu’une fois que la mesure de bande passante du réseau l’a évalué, ce qui prend plusieurs jours. Une politique autorisant les ports 80 et 443 est également nécessaire avant que votre relay soit considéré comme un nœud de sortie.