SSD Nodes Learn 🎉 VPS vanaf $5.50/mnd
Gidsen Matt ConnorDoor Matt Connor · Bijgewerkt 2026-08-13

Zelf een Tor exit node draaien: een praktische gids

Wilt u een Tor exit relay beheren? Leer alles over de juiste hosting, het instellen van ContactInfo, reverse DNS en het professioneel afhandelen van abuse-meldingen.

Wat een Tor exit node doet en wat voor rol u daarmee aanneemt

Een Tor exit node is het laatste relay in een circuit: de machine die de verbinding met de bestemming opent. Hierdoor registreert de bestemming het adres van uw server en nooit dat van de gebruiker. Elke andere beslissing in deze handleiding vloeit voort uit dit ene feit. Het adres wordt beschouwd als de bron van alles wat erdoorheen gaat. Het moet daarom een adres zijn dat niets anders doet, bij een provider die ermee heeft ingestemd dit verkeer te faciliteren.

Het draaien van een exit node is het tegenovergestelde van uzelf verbergen. Het relay staat vermeld in een openbare directory die iedereen kan downloaden. Uw contactadres staat in die directory onder ContactInfo, uw reverse DNS-naam (Domain Name System) kondigt aan wat de machine is, poort 80 serveert een pagina met dezelfde mededeling en u beantwoordt de abuse-mail zelf, onder uw eigen naam. Niemand in dit systeem is beter identificeerbaar dan een exit-operator. Dat is de taak, en dat is waarom de taak werkt.

Wij draaien deze nodes. SSD Nodes beheert exit-relays in verschillende landen als bijdrage aan de vrijheid van meningsuiting. Wij huren die machines van providers die zich bewust hebben aangemeld voor exit-verkeer, en wij zijn niet de provider voor deze machines. Dat is een bewuste keuze, en de volgende sectie legt uit waarom.

Waar een exit thuishoort, en waar niet

Een exit hoort niet thuis op een general-purpose VPS (virtual private server), en dat geldt ook voor die van ons. Een general-purpose netwerk draagt websites, e-mail, back-ups en controlepanelen voor duizenden ongerelateerde klanten op naburige adressen. Exit-verkeer zorgt ervoor dat een van die adressen in scanrapporten en spam-blocklists terechtkomt, en de gevolgen daarvan treffen de buren. Providers die exits op de juiste manier hosten, hebben daarvoor de juiste infrastructuur: adresruimte die specifiek hiervoor is gereserveerd, en een abuse-desk die al weet wat Tor is.

Een host die deze handleiding schrijft, adviseert u dus om de machine ergens anders aan te schaffen. Dat is het nuttige deel. Wij weten wat exit-verkeer met een adres doet omdat wij anderen betalen om het onze te dragen, en wij betalen hen omdat het correct afhandelen daarvan een andere tak van sport is dan het verkopen van general-purpose servers.

Het Tor Project zegt hetzelfde in directere bewoordingen. De pagina over types relays stelt dat exit-relays "de grootste juridische blootstelling en aansprakelijkheid van alle relays hebben" en dat "u geen Tor exit-relay vanaf uw thuislocatie moet draaien". Een general-purpose VPS waar uw eigen projecten op staan, staat dichter bij huis dan het lijkt. Het is een machine waar u waarde aan hecht, op een adres dat u schoon wilt houden.

Als u een gewone VPS heeft en u wilt deze week het netwerk helpen, draai er dan een non-exit relay of een bridge op. Dat is geen troostprijs. Het is een andere taak met een ander risicoprofiel, en het netwerk heeft beide nodig. Een non-exit relay opent nooit een verbinding naar een bestemming, waardoor het vrijwel geen klachten oplevert. De richtlijnen van Tor vragen om ten minste 2 MByte/s (megabytes per seconde) in elke richting voordat het de moeite waard is om deze te vermelden. Een bridge is een niet-vermeld toegangspunt voor gebruikers in gecensureerde netwerken. Deze heeft 24/7 connectiviteit en één open TCP (transmission control protocol) poort nodig, wat het de meest waardevolle taak maakt die een kleine server kan uitvoeren. Beide horen thuis op hardware die u al heeft. Een exit niet.

Hoe vindt u een exit-vriendelijke provider?

Vraag dit schriftelijk voordat u bestelt en bewaar het antwoord. De exit-richtlijnen van Tor adviseren om dit in twee stappen te doen: vraag eerst of de provider überhaupt akkoord gaat met een Tor-exit en vraag daarna of zij hiervoor een toegewezen adres of reeks willen verstrekken. Wanneer u beide tegelijk vraagt, krijgt u vaak een reflexmatige afwijzing.

Vier vragen maken duidelijk of een provider hier werkelijk op is ingericht.

  • Wijst u een toegewezen IP-adres toe dat niets anders host, en stelt u het reverse DNS-record in waar ik om vraag?
  • Wie ontvangt de abuse-mail en stuurt u deze ongewijzigd naar mij door, inclusief het adres van de melder zodat ik direct kan reageren?
  • Wat gebeurt er bij de eerste klacht: stuurt u deze naar mij door, of null-route u het adres eerst en stelt u daarna pas vragen?
  • Hoeveel exits bevinden zich al op dit netwerk? De richtlijnen van Tor zijn hierover duidelijk: "het helpt niet als we te veel exits bij één vriendelijke ISP clusteren".

Die laatste vraag is belangrijker dan het lijkt. Een deel van de waarde van een exit komt voort uit de positie in het netwerk. Een extra exit in een netwerk waar er al vijftig staan, voegt minder toe dan dezelfde machine op een nieuwe locatie. Relay Search toont welke netwerken al exits bevatten, zodat u dit kunt controleren voordat u zich vastlegt.

Zorg dat u de antwoorden heeft voordat u betaalt en schaf de machine aan via een apart account in plaats van deze toe te voegen aan het account waar uw andere servers staan. Hoe veilig VPS-hosting is hangt grotendeels af van wat u naast elkaar plaatst, en dit is daarvan het duidelijkste voorbeeld.

Eén adres, één taak

Het adres van de exit-node mag niets anders hosten. Geen website, geen e-mail, geen VPN, geen monitoring-dashboard en geen persoonlijke SSH (secure shell) jump host. Het adres zal op blocklists belanden, en alles wat daar verder draait, zal op manieren falen die lastig te debuggen zijn. Een adres met één enkel doel houdt uw antwoord op klachten bovendien kort: dit adres is een exit-relay en niets anders.

Voer het reguliere onderhoud uit voordat u Tor installeert. Gebruik uitsluitend SSH-keys met wachtwoordauthenticatie uitgeschakeld en een firewall die alleen de poorten toestaat die u publiceert. Hardening SSH on a VPS behandelt het eerste deel en ufw firewall basics behandelt het tweede. Een exit-node publiceert precies twee poorten naar de buitenwereld: de ORPort die Tor-verkeer afhandelt en poort 80 voor de exit-notice pagina. Al het overige blijft gesloten.

Schakel unattended upgrades in, omdat een exit-node die op een verouderde Tor-versie draait een probleem vormt voor elke gebruiker die erover wordt gerouteerd.

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

Voeg geen logging toe. Het vastleggen van plaintext die een exit-node verlaat is technisch eenvoudig, maar het is het enige wat een operator nooit mag doen. De EFF Tor legal FAQ adviseert operators dit niet te doen, omdat wetgeving rondom het aftappen van communicatie in de Verenigde Staten en vergelijkbare wetgeving elders aansprakelijkheid kan creëren voor het onderzoeken van dat verkeer. Houd de standaard notice-level logging van Tor aan en niets meer.

Tor installeren vanuit de repository van het Tor Project

Distributiepakketten lopen achter. Gebruik de eigen repository van het Tor Project zodat beveiligingsupdates op de dag van release beschikbaar zijn. Per augustus 2026 is de huidige stabiele serie 0.4.9.

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

Schrijf /etc/apt/sources.list.d/tor.sources en vervang noble door de codenaam die lsb_release -cs heeft weergegeven:

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

Voeg de ondertekeningssleutel toe en installeer vervolgens:

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

Het pakket deb.torproject.org-keyring houdt die sleutel zelf actueel, zodat de repository niet onbruikbaar wordt op de dag dat de sleutel verloopt. Als apt update meldt dat dezelfde repository tweemaal is geconfigureerd, heeft u zowel een .list-bestand als een .sources-bestand waarin deze wordt genoemd, en de deb822-foutmelding over dubbele bronnen legt uit hoe u dit oplost.

DNS: uw exit lost namen op voor iedereen die er gebruik van maakt

Een exit voert de naamsopzoekingen uit voor elk circuit dat erdoorheen loopt, waardoor de resolver een stroom aan namen ziet die van anderen zijn. Als u dit naar een grote publieke resolver wijst, geeft u de volledige stroom door aan één bedrijf; dit is de centralisatie die Tor exit-operators vraagt te vermijden. Draai in plaats daarvan een validerende, cachende resolver op de server.

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 markeert het bestand als onveranderlijk, omdat DHCP (dynamic host configuration protocol)-clients en resolvconf /etc/resolv.conf volgens hun eigen planning overschrijven. Zonder dit kan een herstart uw opzoekingen terugzetten naar de resolver van de provider, en er is geen waarschuwing wanneer dit gebeurt. De Debian- en Ubuntu-instructies van Tor schakelen ook query name minimisation in, wat naar elke naamserver alleen het deel van een naam stuurt dat deze daadwerkelijk nodig heeft:

server:
    qname-minimisation: yes

Plaats dit in een bestand onder /etc/unbound/unbound.conf.d/ en bevestig vervolgens dat de resolver antwoordt:

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

Een adres in het antwoord betekent dat unbound werkt. Als unbound niet start met address already in use, houdt een ander proces poort 53 bezet: voer sudo ss -lntup | grep :53 uit en kijk welk proces de eigenaar is. Op Ubuntu luistert systemd-resolved op 127.0.0.53, dus dit botst niet met unbound op 127.0.0.1.

De torrc voor een exit relay

Het Debian-pakket leest /etc/tor/torrc. Dit is de volledige configuratie die relevant is voor de exit-functionaliteit.

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

Elke regel hier is essentieel, dus behandel ze één voor één.

ORPort 443 is de poort waarop andere relays verbinding met u maken. Poort 443 komt door restrictieve netwerken heen die ongebruikelijke poorten blokkeren, waardoor uw relay voor meer mensen bereikbaar is dan via de traditionele 9001. U kunt alleen 443 claimen omdat geen enkele andere service op deze machine deze poort vereist; dit is een extra argument voor een toegewezen adres.

SocksPort 0 schakelt de lokale SOCKS-proxy uit. Een relay heeft deze nooit nodig, en een SOCKS-poort die op een publiek adres luistert, is een open proxy die binnen enkele uren wordt gevonden en misbruikt.

ExitRelay 1 is de schakelaar die dit een exit maakt. Stel deze expliciet in in plaats van te vertrouwen op een standaardwaarde, zodat het configuratiebestand duidelijk aangeeft wat de machine doet.

ContactInfo wordt gepubliceerd in de openbare directory zodat iedereen het kan lezen. Schrijf dit in het formaat van de ContactInfo Information Sharing Specification, aangezien de tooling van het netwerk dit formaat parseert, en behoud ciissversion:3 hierin. De [] in plaats van @ is de conventie die deze specificatie gebruikt om adres-scrapers te vertragen. Gebruik een mailbox die u dagelijks leest, omdat hier de e-mail over misbruik binnenkomt.

Als de machine over een werkende IPv6-verbinding beschikt, voeg dan een IPv6 ORPort toe en schakel IPv6-exiting in. Laat beide weg als dit niet het geval is, omdat een relay die een adres adverteert dat hij niet daadwerkelijk kan gebruiken, niet slaagt voor zijn eigen bereikbaarheidstest.

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

Exit policy: welke poorten worden toegestaan

Het exit policy is de lijst met bestemmingen waarmee uw relay verbinding mag maken. Tor leest deze van boven naar beneden en de eerste overeenkomende regel is bepalend. ReducedExitPolicy 1 selecteert een samengestelde lijst van ongeveer zeventig poorten voor web, mailverzending, chat en git, en sluit de poorten uit die de meeste klachten veroorzaken. Dit is het juiste startpunt voor een eerste exit.

Twee regels zijn belangrijk om bij naam te kennen. ExitPolicyRejectPrivate staat standaard aan en voorkomt dat de exit verbinding maakt met privé-adresbereiken en met de eigen adressen van de relay; dit voorkomt dat uw exit wordt gericht op het interne netwerk van uw provider. Poort 25 (SMTP, simple mail transfer protocol) wordt geweigerd en dient geweigerd te blijven, omdat het toestaan hiervan de relay verandert in een bron van spam en het adres binnen enkele dagen op een blocklist belandt.

Een exit moet poort 80 en 443 toestaan om überhaupt nuttig te zijn. De documentatie voor exit relays van Tor stelt dit minimum direct vast. Als uw provider een strenger beleid vereist dan het reduced policy, is een web-only exit nog steeds een waardevolle bijdrage:

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

Beëindig de lijst met reject *:* zodat uw policy op zichzelf compleet is en er niets verder wordt overgenomen. Het reduced policy staat poort 22 (SSH) toe, wat de gebruikelijke bron is van meldingen over brute-force-aanvallen; voeg daarom ExitPolicy reject *:22 toe boven de rest als u die categorie e-mails liever niet ontvangt. De poorten voor file-sharing in het bereik 6881-6999 zijn de gebruikelijke bron van auteursrechtmeldingen, en het reduced policy sluit deze reeds uit.

Een wijziging in het policy bereikt clients pas nadat uw relay een nieuwe descriptor heeft gepubliceerd en de directory deze heeft verspreid; houd daarom rekening met een paar uur voordat u het effect beoordeelt.

Contactgegevens, family keys en het registreren van de relay

Het registreren van een exit betekent dat u deze koppelt aan een naam die een buitenstaander kan verifiëren. Twee mechanismen doen dit, en ze werken samen.

De eerste is een bekend bestand. Publiceer uw family-identiteit op een domein dat u beheert en verwijs vervolgens naar dat bewijs in ContactInfo:

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

Het bestand bevindt zich op https://example.org/.well-known/tor-relay/ed25519-family-id.txt en bevat uw family-ID. Iedereen kan nu bevestigen dat degene die deze relays claimt, ook het domein beheert. Dat is het verschil tussen een contactadres en een geverifieerd adres.

De tweede is de family zelf. Als u meer dan één relay beheert, moet het netwerk weten dat deze door dezelfde operator worden beheerd, zodat een client nooit een circuit opbouwt via twee van uw machines. De huidige versie van tor doet dit met een family key, genaamd Happy Families, op relays die draaien op 0.4.9.2-alpha of later:

tor --keygen-family exampleFamily

Dit schrijft exampleFamily.secret_family_key en toont een FamilyId-regel. Kopieer het geheime sleutelbestand naar de key-directory van elke relay (/var/lib/tor/keys op Debian en Ubuntu), behoud de .secret_family_key-extensie in de bestandsnaam, voeg de getoonde FamilyId-regel toe aan elke torrc en herlaad tor. De documentatie van Tor is expliciet dat u nog steeds de verouderde MyFamily-optie moet instellen met een lijst van elke relay-fingerprint totdat het project aankondigt dat dit niet langer nodig is; configureer dus beide. De fingerprint van elke relay staat in /var/lib/tor/fingerprint.

Bij de tweede en derde machine begint het beheer een rol te spelen, en het gelijktijdig beheren van meerdere Linux-servers is hier hetzelfde probleem als overal elders. Maak een back-up van /var/lib/tor/keys op een locatie buiten de server. Raakt u dit kwijt, dan keert de relay terug als een vreemde en moet deze elke vlag en al zijn reputatie opnieuw vanaf nul opbouwen.

Abonneer u ook op de tor-relays mailinglijst. Wijzigingen die operators beïnvloeden, worden daar als eerste aangekondigd.

Reverse DNS en de exit-melding op poort 80

Stel het reverse DNS-record in voordat de relay verkeer verwerkt. De exit-richtlijnen van Tor schrijven voor dat u aangeeft wat de server is, in de trant van tor-exit-01.example.org. De reden hiervoor is praktisch. Wanneer een onbekend adres opduikt in de logs van iemand, voert de beheerder als eerste een reverse lookup uit. Een naam die "tor-exit" bevat, beantwoordt de vraag voordat iemand u aanschrijft, waardoor een deel van de potentiële klachten uitblijft. Vraag de provider om het PTR-record (pointer) in te stellen en voeg aan uw kant een bijbehorend forward-record toe.

Host vervolgens een mededeling op poort 80 die hetzelfde in woorden uitlegt. Oudere handleidingen doen dit met de DirPortFrontPage-instelling van tor, die afhankelijk is van een DirPort. DirPort is sinds tor 0.4.6.5 verouderd voor relays, dus gebruik in plaats daarvan een kleine webserver.

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

Schrijf /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>

Schrijf dit server-blok naar /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;
}

Schakel het in, verwijder de standaard-site van nginx en controleer het resultaat:

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

nginx -t met de melding syntax is ok en test is successful betekent dat het bestand correct wordt geparseerd. De curl hoort de eerste regels van uw mededeling weer te geven. Als de welkomstpagina van nginx wordt getoond, is de standaard-site nog ingeschakeld en wordt uw blok niet gebruikt.

Start de service en lees de logbestanden

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

Binnen enkele minuten zou het logbestand de regel moeten bevatten die aangeeft dat andere relays u kunnen bereiken:

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

Als deze regel niet verschijnt, is de ORPort niet bereikbaar. Controleer of tor luistert met sudo ss -lntp | grep 443 en test de poort vervolgens vanaf een andere machine met nc -vz your.address.here 443. Een firewall voor de VPS, hetzij die van uzelf of die in het configuratiescherm van de provider, is meestal de oorzaak.

Controleer of de service na een herstart weer opkomt met systemctl is-enabled tor; dit zou enabled moeten retourneren.

De relay verschijnt ongeveer drie uur na de start op Relay Search, onder de door u gekozen bijnaam. Het verkeer neemt vervolgens in de loop van enkele dagen toe, omdat de bandbreedtemeting van het netwerk uw relay moet observeren voordat clients er veel gewicht aan toekennen. Het is normaal dat een nieuwe exit op de eerste dag nauwelijks verkeer verwerkt.

Het abuse-draaiboek en hoe de e-mail eruitziet

Stel het draaiboek op vóór de eerste klacht, aangezien de eerste melding meestal in de eerste week binnenkomt. Het merendeel van deze e-mails wordt automatisch gegenereerd. Volgens de exit-richtlijnen van Tor bestaat ongeveer 80% van de meldingen uit geautomatiseerde rapporten, en een standaardantwoord volstaat voor het grootste deel van de rest.

Dit is wat er daadwerkelijk binnenkomt. Een rapport over scanning of brute-force, gegenereerd door het inbraakdetectiesysteem van iemand anders, met vermelding van uw adres en een tijdstempel. Een auteursrechtmelding, indien uw beleid het gebruik van poorten voor het delen van bestanden toestaat. Een klacht over spam op een forum of in reacties van een site-eigenaar. Soms ontvangt u een verzoek tot bewaring van gegevens of een dagvaarding van justitie; dit valt in een andere categorie en is het moment waarop u contact opneemt met een advocaat in plaats van een sjabloon te gebruiken.

Het antwoord is kort en is vrijwel elke keer hetzelfde:

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>

Vier gewoontes maken dit effectief. Antwoord binnen één werkdag, vanaf het adres in ContactInfo, ondertekend met uw eigen naam. Bied nooit aan om een gebruiker te identificeren, omdat u dat niet kunt; een beheerder die suggereert dat dit wel kan, moet die belofte later verbreken. Bewaar elk antwoord in één map, zodat een tweede e-mail over hetzelfde incident hetzelfde antwoord krijgt. Als de provider een klacht doorstuurt met een waarschuwing voor schorsing, antwoord dan eerst aan de provider en daarna aan de melder.

Twee links dragen het meeste gewicht in die antwoorden. ExoneraTor beantwoordt de vraag die een onderzoeker daadwerkelijk heeft: was dit adres op dat moment een Tor-exitnode. De bulk exit list is een eenvoudige lijst met actuele exit-adressen, één per regel, voor iedereen die besloten heeft Tor te blokkeren en dit liever nauwkeurig doet dan op basis van aannames.

Bandbreedte, kosten en de tweede relay

Exit-nodes verwerken daadwerkelijk netwerkverkeer. Bepaal het maandelijkse plafond voordat u bestelt en vraag hoe de provider factureert zodra de limiet is bereikt, aangezien wat een VPS werkelijk kost meestal een kwestie is van de datalimiet in plaats van de geadverteerde prijs. Tor kan uw kant van die afspraak afdwingen:

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

AccountingMax zorgt ervoor dat Tor in de slaapstand gaat zodra dit volume in de boekhoudperiode is verwerkt, en weer ontwaakt aan het begin van de volgende periode. Vergelijk de eerste maand met de eigen teller van de provider voordat u het getal vertrouwt, omdat beide niet altijd dezelfde bytes tellen. RelayBandwidthRate begrenst de aanhoudende snelheid, wat de uplink bruikbaar houdt en de provider tevreden stelt.

Wanneer u een tweede exit-node toevoegt, plaats deze dan op een ander netwerk in plaats van in hetzelfde rack als de eerste. Diversiteit is een groot deel van wat een exit-node bijdraagt, en twee machines op één locatie falen tegelijkertijd. Koppel ze aan één familie, publiceer hetzelfde geverifieerde contactadres voor beide en beantwoord de e-mail voor beide. Een exit-node die niemand kan bereiken, wordt behandeld als een anoniem probleem. Een exit-node waarvan de beheerder dezelfde dag nog reageert, wordt behandeld als een server met een persoon erachter, wat ook de werkelijkheid is.

FAQ

Kan ik een Tor exit node draaien op een VPS die ik al heb?

Nee, en dit is het enige punt waar we strikt in moeten zijn. Een exit node vereist een toegewezen adres dat niets anders host, bij een provider die vooraf akkoord is gegaan met het afhandelen van exit-verkeer en het ongewijzigd doorsturen van abuse-meldingen naar u. Op een VPS voor algemeen gebruik, inclusief die van ons, voert dat adres al andere taken uit en deelt het een netwerksegment met klanten die reguliere services draaien. Draai een non-exit relay of een obfs4 bridge op de machine die u al heeft. Deze zijn zeer nuttig, leveren vrijwel geen klachten op en vereisen niets meer dan de server waar u al voor betaalt.

Hoeveel abuse-mail ontvangt een Tor exit relay en wie ontvangt deze?

Dit hangt af van uw exit-policy. Met ReducedExitPolicy 1, waarbij poort 25 is geblokkeerd en poorten voor bestandsuitwisseling zijn uitgesloten, bestaat het grootste deel van de inkomende mail uit geautomatiseerde scans en meldingen van brute-force-pogingen. Volgens de richtlijnen van Tor maken geautomatiseerde rapporten ongeveer 80% van het totaal uit. De mail gaat naar de partij waarnaar de abuse-desk van de provider deze doorstuurt; daarom vraagt u vooraf of zij de mail naar u doorsturen met het adres van de melder intact. Publiceer hetzelfde adres in ContactInfo en op de kennisgevingspagina op poort 80, en reageer binnen één werkdag.

Moet ik mijn echte naam en e-mailadres publiceren?

Ja. ContactInfo wordt gepubliceerd in de openbare relay-directory en iedereen kan deze downloaden, de reverse DNS-naam kondigt aan wat de machine is, en de kennisgevingspagina op poort 80 herhaalt dit. Die transparantie is onderdeel van het ontwerp, niet een bijwerking. Een exit node zonder werkende contactgegevens wordt behandeld als een anonieme overlast, en sommige clients sluiten exit nodes uit die helemaal geen contactgegevens publiceren. Voeg proof:uri-familyid-ed25519 en het /.well-known/tor-relay/ed25519-family-id.txt-bestand toe aan een domein dat u beheert, zodat het contact verifieerbaar is in plaats van enkel vermeld.

Waarom verwerkt mijn nieuwe exit relay bijna geen verkeer?

Controleer eerst of journalctl -u tor@default de waarde Self-testing indicates your ORPort is reachable from the outside. Excellent. bevat, omdat een relay die niet slaagt voor de bereikbaarheidstest nooit wordt gepubliceerd en helemaal geen verkeer zal verwerken. Als die regel aanwezig is, is tijd meestal de factor. Een relay verschijnt ongeveer drie uur na het opstarten in Relay Search, en clients sturen pas significant verkeer zodra de bandbreedtemeting van het netwerk de relay heeft geobserveerd; dit duurt enkele dagen. Een policy die poort 80 en 443 toestaat is bovendien vereist voordat uw relay überhaupt als exit node wordt aangemerkt.

#tor#exit-relay#free-speech#abuse-handling#operations