Tor-verkko menetti syyskuussa 2026 merkittävän osan välityskapasiteetistaan, kun satoja releitä katosi verkosta lyhyessä ajassa. Tor-projektin oma releoperaattorifoorumi täyttyi samaan aikaan käytännön viesteistä: kaistanrajoitusongelmia, palvelunestohyökkäyksiä vastaan tehtyjä nftables-säätöjä ja kysymyksiä siitä, miksi rele näyttää yhteyksiä muttei silti pääse verkkoon aktiiviseksi. Jos olet miettinyt, kannattaisiko oma palvelinkapasiteetti laittaa Tor-verkon käyttöön, nyt on hyvä hetki aloittaa. Tässä oppaassa pystytetään oma Tor-rele tyhjästä valmiiksi toimivaksi palveluksi, mukaan lukien vaihtoehtoinen obfs4-silta sensuroiduille alueille.

Opas on kirjoitettu Debian- ja Ubuntu-pohjaisille palvelimille, mutta samat periaatteet pätevät muihinkin Linux-jakeluihin pienin komentoeroin. Et tarvitse aiempaa kokemusta Tor-verkon sisäisestä rakenteesta, mutta peruskäsitys komentorivistä, SSH-yhteyksistä ja tekstieditorin käytöstä helpottaa huomattavasti. Koko prosessi vie ensikertalaiselta noin tunnin, kun palvelin on jo valmiiksi käytettävissä ja käyttöjärjestelmä on ajan tasalla. Käymme läpi kaksitoista konkreettista vaihetta, viisi yleisintä sudenkuoppaa, kahdeksan vianmääritystilannetta ja lopuksi valmiin, kopioitavan asennusskriptin, jolla koko releen saa pystyyn yhdellä ajolla.

Miksi Tor tarvitsee lisää releitä juuri nyt

Tor-verkon toimintakyky riippuu suoraan siitä, kuinka moni vapaaehtoinen pyörittää relettä. Mitä enemmän releitä ja mitä laajemmalle ne jakautuvat eri maihin ja operaattoreihin, sitä vaikeampi verkkoa on tukkia tai valvoa yksittäisestä pisteestä käsin. Syyskuussa 2026 verkko koki takaiskun, kun satoja releitä putosi pois lyhyessä ajassa ja advertised-kaistanleveys laski selvästi. Käsittelimme pudotuksen taustoja ja lukuja erillisessä artikkelissamme, mutta lyhyesti sanottuna verkko tarvitsee korvaavaa kapasiteettia, ja jokainen uusi keskirele auttaa suoraan riippumatta siitä, kuinka pieni sen kaistanleveys on.

Samaan aikaan Tor-projektin muu ekosysteemi on liikkeessä. Tor Browser päivittyi syyskuussa versioon 15.0.23, ja Tails-käyttöjärjestelmästä julkaistiin versio 7.13. Myös Rust-pohjainen Arti-toteutus eteni: sen versio 2.6.0 ilmestyi syyskuun alussa Tor-projektin blogin mukaan, vaikka se ei vielä korvaa tavallista C-pohjaista Tor-relettä tuotantokäytössä. Nämä päivitykset eivät suoraan liity releen pystyttämiseen, mutta ne kertovat, että projekti kehittyy aktiivisesti ja infrastruktuuria hoidetaan jatkuvasti. Releoperaattoreiden keskustelupalstalla käytiin syyskuussa läpi muun muassa palvelunestohyökkäyksiä vastaan tehtyjä nftables-konfiguraatioita ja kysymyksiä siitä, miksi silta näyttää toimivalta mutta ei silti näy verkossa aktiivisena. Näihin ongelmiin palataan tämän oppaan vianmääritysosiossa myöhemmin.

Tor-releen pyörittäminen eroaa monesta muusta yksityisyystyökalusta yhdessä keskeisessä asiassa: et suojaa vain omaa liikennettäsi, vaan autat koko yhteisöä. Jos olet aiemmin asentanut Tor Browserin tai pystyttänyt oman piilopalvelun, tiedät jo verkon perusidean. Rele on kuitenkin täysin eri projekti: se ei tarjoile omaa sisältöä, vaan välittää muiden käyttäjien liikennettä anonymiteetin verkon läpi. Se sopii siksi hyvin myös sellaiselle, joka ei itse edes käytä Tor-verkkoa aktiivisesti mutta haluaa tukea digitaalista yksityisyyttä käytännön teolla, ei vain periaatteessa.

Verkon monimuotoisuus on suoraan yhteydessä sen sensuurinkestävyyteen. Jos suuri osa releistä sijaitsee muutamalla samalla palveluntarjoajalla tai muutamassa maassa, yksittäinen päätös estää liikenne kyseisiin osoitteisiin voi vaikuttaa suureen osaan koko verkosta kerralla. Tästä syystä uusi rele täysin uudessa maassa, uudella palveluntarjoajalla tai uudessa IP-osoiteavaruudessa on verkolle arvokkaampi kuin samanlainen rele jo tunnetulla ja hyvin edustetulla operaattorilla. Pohjoismaissa, mukaan lukien Suomessa, on suhteellisen vähän Tor-releitä verrattuna esimerkiksi Saksaan tai Yhdysvaltoihin, joten jokainen uusi suomalainen tai pohjoismainen rele parantaa verkon maantieteellistä kattavuutta suhteessa enemmän kuin sama rele jo tiheästi katetulla alueella.

Rele, silta vai piilopalvelu: mikä ero niillä on

Nämä kolme termiä sekoittuvat helposti, mutta ne palvelevat eri tarkoitusta. Piilopalvelu (.onion-osoite) julkaisee jonkin oman verkkosivun tai palvelun Tor-verkon sisällä ilman, että palvelimen todellinen IP-osoite paljastuu. Rele sen sijaan ei julkaise mitään omaa: se on yksi kolmesta hypystä, joiden läpi muiden käyttäjien liikenne kulkee anonyymisti internetiin. Silta (bridge) on erikoistapaus releestä, joka ei näy julkisessa releluettelossa lainkaan, koska sen tehtävä on auttaa käyttäjiä pääsemään Tor-verkkoon maissa, joissa tavallisia releitä estetään suodattimilla IP-osoitelistojen perusteella.

Käytännön ero näkyy myös riskiprofiilissa. Piilopalvelun ylläpitäjä vastaa julkaisemastaan sisällöstä, aivan kuten tavallisen verkkosivun ylläpitäjä. Tavallisen keskireleen ylläpitäjä ei näe eikä vastaa läpi kulkevasta liikenteestä sisällöllisesti, koska liikenne on salattua kerroksittain eikä keskirele pura viimeistä salauskerrosta. Poistumisrele (exit relay) on tästä poikkeus: se on ketjun viimeinen lenkki, joka lähettää liikenteen selväkielisenä kohdepalvelimelle, ja siksi kohdepalvelin näkee poistumisreleen IP-osoitteen liikenteen lähteenä. Konkreettinen esimerkki auttaa hahmottamaan eron: jos joku käyttää Tor-verkkoa lukeakseen uutissivustoa sensuroidusta maasta käsin, hänen liikenteensä kulkee guard-releen, keskireleen ja poistumisreleen kautta ennen kuin se saapuu uutissivustolle selväkielisenä. Jos sinä pyöritä pelkkää keskirelettä, näet vain salattua dataa etkä koskaan tiedä, mitä sivustoa käyttäjä lopulta lukee. Tämä ero on tärkeä pitää mielessä koko oppaan ajan, koska se vaikuttaa suoraan siihen, minkä releroolin kannattaa valita aloituspisteeksi.

Piirin kolme hyppyä eivät ole sattumanvaraisia rooleiltaan. Tor-asiakas valitsee jokaiseen piiriin yhden guard-releen, yhden keskireleen ja yhden poistumisreleen, ja vaihtaa piirin säännöllisin väliajoin uuteen yhdistelmään. Guard-rele näkee asiakkaan todellisen IP-osoitteen mutta ei tiedä, mitä kohdetta asiakas lopulta selaa. Poistumisrele näkee kohteen mutta ei asiakkaan alkuperäistä IP-osoitetta. Kumpikaan yksittäinen rele ei siis koskaan näe koko kuvaa yhtä aikaa, ja juuri tämä kolmijako on koko Tor-verkon anonymiteettimallin ydin. Keskirele, jonka tässä oppaassa pystytät, ei näe kumpaakaan päätä: ei asiakkaan IP-osoitetta eikä lopullista kohdetta, mikä tekee siitä oikeudellisesti ja teknisesti kevyimmän roolin ylläpitää.

Kolme releroolia vertailussa

Ennen asennusta kannattaa päättää, minkä tyyppistä relettä lähdet pyörittämään. Alla oleva taulukko tiivistää erot käytännön tasolla, ja tämän oppaan asennusosio keskittyy nimenomaan ensimmäiseen riviin.

RooliNäkyvyys kohdepalvelimilleKaistantarveOikeudellinen riskiSopii aloittelijalle
Keskirele (middle/guard)Ei näy, ei kosketa julkista internetiäMatala-keskitaso, skaalautuu kapasiteetin mukaanHyvin matalaKyllä, suositeltu aloitus
Poistumisrele (exit)Näkyy kohdepalvelimen lokeissa liikenteen lähteenäKeskitaso-korkeaKorkeampi, vaatii valmistautumista väärinkäyttöilmoituksiinEi ensimmäiseksi releeksi
Silta (obfs4 bridge)Ei näy julkisessa listassa lainkaanMatala-keskitasoMatalaKyllä, hyvä vaihtoehto keskireleen rinnalle

Tässä oppaassa keskitytään pääasiassa keskireleen pystyttämiseen, koska se on turvallisin ja nopein tapa aloittaa ilman erillistä oikeudellista valmistelua. Oppaan loppupuolella käydään läpi myös obfs4-sillan lisääminen samalle palvelimelle, jos haluat auttaa myös sensuroiduilla alueilla olevia käyttäjiä pääsemään verkkoon käsiksi. Poistumisreleen pystyttämistä ei käsitellä yksityiskohtaisesti tässä oppaassa, koska se vaatii huomattavasti enemmän valmistautumista väärinkäyttöilmoitusten ja palveluntarjoajasuhteiden osalta. Tor-projektin oma keski- ja guard-releen asennusohje sekä siltapalvelimen ohje toimivat hyvänä viitteenä, jos haluat verrata tämän oppaan asetuksia projektin omaan dokumentaatioon.

Rooli ei ole ainoa releen ominaisuus, jonka verkko arvioi automaattisesti. Hakemistoauktoriteetit myöntävät releille myös lippuja (flags) sen perusteella, miten rele käyttäytyy ajan mittaan. Fast-lippu tarkoittaa, että rele on riittävän nopea kannattaakseen sisällyttää useimpiin piireihin. Stable-lippu kertoo, että rele on pysynyt käynnissä pitkään ilman katkoja. Guard-lippu on näistä vaativin: se annetaan vain releille, jotka ovat osoittaneet sekä nopeutta että vakautta pitkällä aikavälillä, koska guard-rele on asiakkaan ensimmäinen ja siksi kaikkein herkin hyppy piirissä. Uusi rele ei saa mitään näistä lipuista heti, ja se on täysin normaalia. Liput kertyvät automaattisesti, kun rele on pyörinyt riittävän kauan riittävän vakaasti, eikä niitä voi pyytää tai pakottaa asetuksilla.

Mistä tietää, että VPS-tarjoaja sallii Tor-releen

Ennen kuin ostat palvelimen, kannattaa käydä läpi muutama käytännön kohta palveluntarjoajan käyttöehdoista. Tämä säästää turhalta työltä, jos joudut myöhemmin siirtämään relettä kesken kaiken toiselle tarjoajalle.

  • Etsi käyttöehdoista mainintaa Toriin, välityspalvelimiin (proxy) tai anonymisointipalveluihin liittyvistä rajoituksista. Jos ehdoissa ei mainita mitään, se ei automaattisesti tarkoita lupaa, mutta se on hyvä lähtökohta.
  • Kysy tuelta suoraan ennen tilausta. Kirjallinen vahvistus sähköpostitse toimii todisteena, jos väärinkäyttöilmoitus myöhemmin herättää kysymyksiä palveluntarjoajan puolella.
  • Vältä halvimpia jaettuja hostingpaketteja. Ne on usein suunniteltu verkkosivuille, eivät jatkuvasti käynnissä oleville taustapalveluille, ja ORPortin kaltaiset avoimet portit voivat olla kokonaan estettyjä paketin tasolla.
  • Suosi tarjoajia, joilla on selkeä ja nopea väärinkäyttöprosessi. Tämä ei liity pelkästään Toriin: nopea ja ammattimainen väärinkäyttöprosessi kertoo yleensä siitä, ettei tarjoaja sulje palvelinta automaattisesti ensimmäisen ilmoituksen perusteella.
  • Tarkista kuukausittainen siirtoraja etukäteen. Jos raja on tiukka, konfiguroi AccountingMax-asetus heti alusta asti, kuten myöhemmin tässä oppaassa neuvotaan, jotta et ylitä sitä vahingossa.

Keskirele on tässä suhteessa helpoin lähtökohta myös tarjoajavalinnan kannalta, koska se ei aiheuta poistumisliikenteeseen liittyviä väärinkäyttöilmoituksia lainkaan. Moni operaattori aloittaa siksi keskireleellä yhdellä tarjoajalla ja laajentaa vasta myöhemmin useampaan palvelimeen tai releeseen eri tarjoajien kesken, kun ensimmäinen asennus on osoittautunut vakaaksi.

Esivaatimukset ennen asennusta

Tor ei vaadi erikoislaitteistoa. Suurin osa pienistä VPS-tarjoajista riittää mainiosti, kunhan tarjoaja sallii Tor-liikenteen ehdoissaan ja palvelimella on julkinen, kiinteä IP-osoite. Tarkista palveluntarjoajan käyttöehdot ennen asennusta: osa halpahintaisista VPS-tarjoajista kieltää Tor-releen tai poistumisliikenteen erikseen, ja tämä kannattaa selvittää ennen kuin asennat mitään. Vanha kotikäytössä oleva pöytäkone kelpaa teknisesti niin ikään, kunhan sillä on julkinen IP-osoite eikä palveluntarjoaja kiellä palvelimien pyörittämistä kotiliittymässä, mutta useimmiten VPS on käytännössä helpompi ja vakaampi vaihtoehto jatkuvasti käynnissä olevalle releelle.

KomponenttiMinimivaatimusSuositus
KäyttöjärjestelmäDebian 12 tai Ubuntu 24.04 LTSUusin LTS-versio, automaattiset turvapäivitykset päällä
Muisti1 Gt RAM2 Gt tai enemmän vilkkaammalle releelle
LevytilaMuutama gigatavu10 Gt, tilaa lokeille ja tilatiedoille
VerkkoJulkinen IPv4-osoite, kiinteä yhteysJulkinen IPv4 ja IPv6, mahdollisimman suuri kaistaraja
Tor-pakettiJakelun repositorion uusin vakaa versioTor-projektin oma paketointipalvelin uusimmalla versiolla
Valvontatyökalu (valinnainen)Ei pakollinenNyx-komentorivityökalu asennettuna

Älä koskaan oleta tarkkaa versionumeroa etukäteen: asenna aina jakelun tai Tor-projektin repositorion sen hetkinen vakaa versio ja tarkista se komennolla tor --version heti asennuksen jälkeen. Tor-projekti ja käyttöjärjestelmien paketinhallinta julkaisevat turvapäivityksiä säännöllisesti, joten sama torrc-tiedosto toimii yleensä versiosta toiseen ilman muutoksia. Jos suunnittelet myöhemmin useamman kuin yhden releen pyörittämistä, kannattaa jo tässä vaiheessa valita eri palveluntarjoaja tai edes eri tietokeskus jokaiselle releelle, koska verkon monimuotoisuus kasvaa enemmän uusista ASN-numeroista kuin kahdesta releestä samalla operaattorilla.

Vaiheet 1–4: palvelimen valmistelu ja Tor-paketin asennus

Vaihe 1: Päivitä palvelin ja tarkista käyttäjäoikeudet. Älä koskaan pyöritä Tor-relettä root-käyttäjänä. Pakettienhallinta luo automaattisesti oman debian-tor-käyttäjän asennuksen yhteydessä, joten sinun ei tarvitse tehdä tätä manuaalisesti Debian- ja Ubuntu-järjestelmissä. Aloita silti aina täydellä järjestelmäpäivityksellä, koska vanhentuneet paketit ovat yleisin syy myöhempiin, vaikeasti jäljitettäviin asennusongelmiin.

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y curl gnupg apt-transport-https

Vaihe 2: Lisää Tor-projektin virallinen pakettivarasto. Jakelun oma tor-paketti toimii sekin, mutta Tor-projektin oma repositorio tuo turvapäivitykset yleensä nopeammin kuin jakelun omat päivityssyklit ehtivät.

echo "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] \
https://deb.torproject.org/torproject.org $(lsb_release -sc) main" \
  | sudo tee /etc/apt/sources.list.d/tor.list
curl -fsSL https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor | sudo tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
sudo apt update

Vaihe 3: Asenna Tor ja tarkista versio. Tämä on hyvä hetki myös tutustua siihen, mitä asetuksia paketti tukee, koska seuraavissa vaiheissa muokataan juuri näitä asetuksia.

sudo apt install -y tor deb.torproject.org-keyring
tor --version
tor --list-torrc-options | head -20

Tulosteen pitäisi näyttää suunnilleen tältä (tarkka versionumero vaihtelee asennushetken mukaan, joten älä huolestu jos numerosarja ei täsmää tähän esimerkkiin):

Tor version 0.4.x.x running on Linux with Libevent, OpenSSL,
Zlib, Liblzma, Libzstd and Glibc.
This build of Tor is covered by the GNU General Public License

Vaihe 4: Pysäytä palvelu ennen konfigurointia. Näin vältät tilanteen, jossa muokkaat torrc-tiedostoa palvelun ollessa jo käynnissä ja unohdat käynnistää sen uudelleen muutosten jälkeen, mikä on yksi yleisimmistä syistä siihen, että “valmis” konfiguraatio ei näytä vaikuttavan mihinkään.

sudo systemctl stop tor@default
sudo systemctl status tor@default

Vaiheet 5–8: torrc-tiedoston määritykset

Vaihe 5: Avaa konfiguraatiotiedosto. Debian- ja Ubuntu-paketeissa tiedosto sijaitsee yleensä osoitteessa /etc/tor/torrc. Tee ensin varmuuskopio alkuperäisestä, jotta voit palata lähtötilanteeseen, jos jokin menee pieleen.

sudo cp /etc/tor/torrc /etc/tor/torrc.orig
sudo nano /etc/tor/torrc

Vaihe 6: Kirjoita perusasetukset keskireleelle. Alla oleva esimerkki pystyttää tavallisen, ei-poistuvan releen. Rivi ExitPolicy reject *:* varmistaa, ettei releesi koskaan toimi poistumispisteenä, mikä pitää oikeudellisen riskin niin matalana kuin mahdollista.

# /etc/tor/torrc: keskirele
Nickname OmaEnsimmainenRele
ContactInfo [email protected]
ORPort 443

# Ei poistumisliikennettä
ExitRelay 0
ExitPolicy reject *:*

# Kaistanrajoitus, säädä palvelimen todellisen kaistan mukaan
BandwidthRate 20 MBytes
BandwidthBurst 30 MBytes

# Valinnainen kuukausikatto mitatuille palvelimille
# AccountingMax 2 TBytes
# AccountingStart month 1 00:00

# Paikallinen hallintaliittymä, ei julkinen
ControlPort 9051
CookieAuthentication 1

Vaihe 7: Aseta ORPort-portti huolella. Portti 443 on hyvä valinta, koska se sulautuu tavalliseen HTTPS-liikenteeseen eikä herätä huomiota palveluntarjoajan verkossa. Jos palvelimella pyörii jo webbipalvelin samassa portissa, valitse jokin muu vapaa portti, esimerkiksi 9001, ja mainitse se selkeästi ContactInfo-kentässä mahdollisia väärinkäyttöilmoituksia varten. Portin valinta ei vaikuta releen tehokkuuteen millään tavalla, joten valitse mikä tahansa vapaa portti, joka ei ole ristiriidassa muun palvelimella pyörivän liikenteen kanssa.

Vaihe 8: Lisää IPv6, jos palvelimella on osoite käytössä. IPv6-tuki lisää verkon monimuotoisuutta, koska yhä useampi käyttäjä yhdistää IPv6:n kautta, ja monella releellä on tähän mennessä vain IPv4-osoite.

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

Vaiheet 9–12: palomuuri, käynnistys ja vahvistus

Vaihe 9: Avaa palomuurista tarvittavat portit. Ilman tätä vaihetta rele käynnistyy näennäisesti onnistuneesti, mutta kukaan ei pääse siihen käsiksi ulkopuolelta, eikä se koskaan saa mitattua kaistanleveyttä eikä liity verkkoon aktiivisena solmuna.

sudo ufw allow 443/tcp
sudo ufw allow ssh
sudo ufw enable
sudo ufw status verbose

Vaihe 10: Käynnistä palvelu ja ota se mukaan automaattiseen käynnistykseen. Tämä varmistaa, että rele käynnistyy uudelleen myös palvelimen uudelleenkäynnistyksen tai ylläpitokatkon jälkeen ilman manuaalista puuttumista.

sudo systemctl enable --now tor@default
sudo systemctl status tor@default

Onnistuneen käynnistyksen loki näyttää tältä:

Sep 23 09:14:02 rele1 Tor[1842]: Bootstrapped 100% (done): Done
Sep 23 09:14:03 rele1 Tor[1842]: Self-testing indicates
your ORPort 443 is reachable from the outside.
Publishing server descriptor.

Vaihe 11: Vahvista, että rele on tavoitettavissa. Rivi Self-testing indicates your ORPort is reachable on tärkein yksittäinen merkki siitä, että kaikki keskeiset asetukset ovat kunnossa. Jos tämä rivi puuttuu kymmenen minuutin sisällä käynnistyksestä, siirry suoraan tämän oppaan vianmääritysosioon sen sijaan, että arvailet mikä meni pieleen.

Vaihe 12: Odota ja seuraa releen ilmestymistä julkiseen listaan. Uusi rele ei saa heti Guard-lippua eikä täyttä mitattua kaistaa, koska hakemistoauktoriteetit tarvitsevat useita päiviä havaintoja ennen luotettavuuden arviointia. Voit seurata oman releesi tilaa Tor-projektin julkisesta Onionoo-rajapinnasta tai Tor Metrics -palvelusta hakemalla nimen tai sormenjäljen perusteella. Kärsivällisyys on tässä vaiheessa tärkeämpää kuin konfiguraation jatkuva säätäminen: anna releen pyöriä ainakin viikko ennen kuin teet isoja muutoksia sen asetuksiin.

Onionoo on Tor-projektin julkinen JSON-rajapinta, joka listaa kaikkien tunnettujen releiden ja siltojen tilan. Sitä voi kysellä suoraan komentoriviltä ilman selainta, mikä on kätevää esimerkiksi palvelimen omissa valvontaskripteissä.

curl -s "https://onionoo.torproject.org/details?search=OmaEnsimmainenRele" \
  | python3 -m json.tool | grep -E "nickname|running|last_seen"

Jos komento palauttaa tyhjän tulosjoukon ensimmäisten tuntien aikana, se on normaalia. Kun kenttä running saa arvon true, rele on virallisesti osa nykyistä konsensusta ja välittää liikennettä aktiivisesti.

Kaistanrajoitusten, ContactInfo-tietojen ja muiden torrc-asetusten hienosäätö

BandwidthRate määrittää pitkän aikavälin keskimääräisen siirtonopeuden, jonka rele saa käyttää, kun taas BandwidthBurst sallii lyhytaikaiset piikit tämän ylitse. Näitä ei kannata jättää oletusarvoihin, jos palveluntarjoajalla on kiinteä kuukausisiirtoraja: käytä AccountingMax-asetusta rajoittamaan kokonaissiirtoa kuukaudessa ja AccountingStart-asetusta määrittämään, milloin laskenta nollautuu. Tämä estää yllättävät lisälaskut mitatulla VPS-sopimuksella, mikä on yksi yleisimmistä syistä siihen, että aloittelijat luopuvat releen pyörittämisestä ensimmäisen kuukauden jälkeen.

Havainnollinen esimerkki: jos palveluntarjoaja sallii yhteensä 2 teratavua siirtoa kuukaudessa, tasainen 20 megatavun sekuntinopeus voisi teoriassa kuluttaa koko kiintiön jo muutamassa päivässä täydellä teholla käytettynä. Tästä syystä AccountingMax 2 TBytes yhdessä kuukausittain nollautuvan AccountingStart-asetuksen kanssa on turvallisempi lähtökohta kuin pelkkä sekuntikohtainen rajoitus: Tor jakaa käytön automaattisesti tasaisemmin koko kuukaudelle sen sijaan, että se käyttäisi koko kiintiön heti alussa.

ContactInfo-kenttä on pieni yksityiskohta, joka säästää paljon vaivaa myöhemmin. Jos releesi IP-osoitteesta tehdään ilmoitus tai jos hakemistoauktoriteetit huomaavat poikkeaman, oikea ja toimiva yhteystieto nopeuttaa asian selvittämistä huomattavasti verrattuna tyhjään kenttään. Monet kokeneet operaattorit lisäävät kenttään myös lyhyen maininnan siitä, että kyseessä on vapaaehtoinen Tor-rele eikä hyökkäyksen lähde, mikä auttaa erityisesti automatisoitujen väärinkäyttöjärjestelmien tulkinnassa kohdepalvelimilla.

Alla oleva taulukko kokoaa yhteen tässä oppaassa käytetyt keskeisimmät torrc-asetukset ja niiden tarkoituksen, jotta voit palata siihen myöhemmin ilman koko oppaan uudelleenlukemista.

AsetusTarkoitusKäytännön huomio
ORPortReleen kuunteluportti muulle Tor-verkolleEi yleistä pakollista oletusarvoa, määritä aina itse
ExitPolicySallitut kohdeportit poistumisliikenteellereject *:* estää poistumisliikenteen kokonaan
BandwidthRate / BandwidthBurstPitkän ja lyhyen aikavälin kaistarajatSäädä aina palvelimen todellisen kaistan mukaan
AccountingMax / AccountingStartKuukausittainen siirtokattoSuositeltu mitatuilla VPS-sopimuksilla
ContactInfoOperaattorin yhteystietoNopeuttaa väärinkäyttöilmoitusten käsittelyä
ControlPort / CookieAuthenticationPaikallinen hallintaliittymä esimerkiksi NyxilleÄlä koskaan avaa julkiseen verkkoon
BridgeRelay / ServerTransportPluginOttaa käyttöön obfs4-sillanVaatii erikseen asennetun obfs4proxy-paketin

Valvonta Nyx-työkalulla ja Onionoo-rajapinnalla

Nyx on komentorivipohjainen valvontatyökalu, joka näyttää reaaliaikaisesti releen kaistankäytön, aktiiviset yhteydet ja lokiviestit yhdessä näkymässä. Se ei ole pakollinen, mutta se nopeuttaa merkittävästi ongelmien havaitsemista verrattuna pelkkien lokitiedostojen selaamiseen.

sudo apt install -y nyx
nyx --version
sudo -u debian-tor nyx

Nyxin virallinen projektisivu listaa kaikki näppäinkomennot ja näkymät. Perusnäkymässä näet reaaliaikaisen kaistankäytön graafina, aktiivisten yhteyksien listan sekä viimeisimmät lokirivit samassa terminaali-ikkunassa ilman erillistä selainta.

Jos ControlPort on määritetty ja CookieAuthentication päällä torrc-tiedostossa (kuten vaiheen 6 esimerkissä), Nyx yhdistyy automaattisesti paikalliseen Tor-prosessiin ilman salasanan syöttöä. Älä koskaan avaa ControlPort-porttia palomuurista julkiseen verkkoon, koska se on tarkoitettu vain paikalliseen hallintaan samalla koneella eikä sitä ole suunniteltu kestämään ulkopuolisia yhteysyrityksiä.

Releen tilan tarkistus komentoriviltä ilman Nyxiä

Jos et halua asentaa erillistä valvontatyökalua, systemd-lokit ja journalctl riittävät perusseurantaan hyvin. Tämä on myös nopein tapa tarkistaa tilanne, jos kirjaudut palvelimelle vain satunnaisesti.

sudo journalctl -u tor@default -f
sudo journalctl -u tor@default --since "1 hour ago" | grep -i bootstrap

obfs4-sillan pystyttäminen sensuurin kiertämiseksi

Jos haluat auttaa erityisesti maissa, joissa tavallisten Tor-releiden IP-osoitteet on suodatettu palomuureilla, silta on tehokkaampi apu kuin tavallinen rele. Silta ei näy julkisessa listassa, joten sitä on vaikeampi estää massasuodattamalla. obfs4 on kuljetusprotokolla, joka naamioi Tor-liikenteen näyttämään satunnaiselta datalta, jotta syväpakettitarkastusta käyttävät suodattimet eivät tunnista sitä Tor-liikenteeksi.

obfs4proxy-liitännäisen asennus

sudo apt install -y obfs4proxy
which obfs4proxy

Tarkista which obfs4proxy -komennolla tarkka asennuspolku, koska se vaihtelee jakelusta toiseen. Käytä juuri tätä polkua seuraavassa torrc-esimerkissä sen sijaan, että kopioit polun suoraan tästä oppaasta, sillä väärä polku on yksi yleisimmistä syistä siihen, ettei silta käynnisty lainkaan.

# /etc/tor/torrc: obfs4-silta
Nickname OmaSilta
ContactInfo [email protected]

BridgeRelay 1
ORPort 443

ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:8443

# Silta ei koskaan toimi poistumispisteenä
ExitPolicy reject *:*

BandwidthRate 10 MBytes
BandwidthBurst 20 MBytes

Sillan yhteystietojen jakaminen turvallisesti

Käynnistyksen jälkeen Tor luo sillan yhteystiedot tiedostoon /var/lib/tor/pt_state/obfs4_bridgeline.txt. Älä koskaan julkaise tätä yhteysriviä avoimesti verkkosivulla tai sosiaalisessa mediassa. Mitä laajemmalle yksittäisen sillan osoite leviää, sitä nopeammin se päätyy myös estolistoille, ja koko työn hyöty menetetään. Tor-projekti jakaa siltoja hallitusti pyynnöstä juuri tästä syystä, joten harkitse sillan yhteystietojen välittämistä sen sijaan luotettujen kanavien kautta niille, jotka niitä oikeasti tarvitsevat.

Yleisimmät sudut asennuksessa

Seuraavat virheet toistuvat säännöllisesti aloittelevilla releoperaattoreilla, ja suurin osa niistä on helppo välttää etukäteen, kun tietää mistä katsoa.

  • Poistumisreleen käynnistäminen kotiverkosta. Kotiliittymän käyttöehdot kieltävät tämän lähes poikkeuksetta, ja poistumisliikenne johtaa nopeasti väärinkäyttöilmoituksiin, jotka päätyvät omalle internet-liittymälle eivätkä erilliselle palveluntarjoajalle.
  • ContactInfo-kentän jättäminen tyhjäksi. Tyhjä kenttä hidastaa jokaista yhteydenottoa ja saa releen näyttämään epäilyttävämmältä automaattisissa väärinkäyttöjärjestelmissä, vaikka kyseessä olisi täysin tavallinen keskirele.
  • ControlPortin avaaminen julkiseen verkkoon. Tämä antaisi kenelle tahansa mahdollisuuden hallita Tor-prosessia etänä, jos autentikointi on väärin määritetty tai puuttuu kokonaan.
  • Kaistanrajoitusten unohtaminen mitatulla sopimuksella. Ilman AccountingMax-asetusta rele voi kuluttaa koko kuukausikiintiön muutamassa päivässä, mikä yllättää monen ensikertalaisen laskutuksessa.
  • Asennus CGNAT-verkon taakse. Jos palveluntarjoaja käyttää operaattoritason osoitteenmuunnosta, ORPort ei koskaan ole aidosti tavoitettavissa ulkopuolelta, vaikka portinohjaus näyttäisi olevan kunnossa reitittimessä.
  • Väärät tiedosto-oikeudet /var/lib/tor-hakemistossa. Manuaalinen muokkaus root-käyttäjänä voi jättää tiedostot omistukseen, jota debian-tor-käyttäjä ei pääse lukemaan, jolloin palvelu kaatuu hiljaisesti käynnistyksen jälkeen ilman selkeää virheilmoitusta.
  • Lokitiedostojen kasvun jättäminen huomiotta. Oletusasetuksilla Tor ei yleensä täytä levyä nopeasti, mutta jos nostat lokitasoa vianmäärityksen ajaksi arvoon debug, muista palauttaa se takaisin tuotantotasolle. Muuten levy voi täyttyä viikkojen kuluessa ja pysäyttää koko palvelun yllättäen.

Vianmääritys: kahdeksan yleisintä ongelmaa

Jos rele ei käynnisty odotetusti tai ei näy verkossa, käy läpi seuraava lista ennen kuin aloitat koko konfiguraation nollaamisen alusta.

  1. Rele ei näy Tor Metricsissä usean tunnin jälkeen. Uuden releen ilmestyminen listalle voi kestää tunneista muutamaan päivään. Tarkista sen sijaan paikallinen loki: jos siellä lukee “Bootstrapped 100%” ja “Self-testing indicates your ORPort is reachable”, asetukset ovat kunnossa ja kyse on vain hakemistoauktoriteettien normaalista viiveestä.
  2. Palvelu jää tilaan “Bootstrapped 0%”. Tämä viittaa yleensä siihen, ettei palvelin pääse ulos verkkoon lainkaan. Tarkista DNS-asetukset ja se, ettei palomuuri estä lähtevää liikennettä porttiin 443 tai 80.
  3. Loki näyttää “ORPort not reachable”. Tarkista ensin oma palomuuri (ufw status), sitten mahdollinen pilvipalveluntarjoajan erillinen suojausryhmä palvelimen ulkopuolella, ja lopuksi se, ettei reitittimen tasolla ole vielä ylimääräistä porttiohjausta estämässä liikennettä.
  4. Kellon vääristymä estää yhteyden hakemistoauktoriteetteihin. Tor on herkkä väärälle kellonajalle. Varmista, että NTP-synkronointi on päällä: timedatectl status ja tarvittaessa sudo timedatectl set-ntp true.
  5. obfs4proxy-binaarin polku on väärä torrc:ssä. Loki näyttää tällöin virheen liitännäisen käynnistyksessä. Aja which obfs4proxy uudelleen ja päivitä ServerTransportPlugin-rivi vastaamaan todellista polkua palvelimellasi.
  6. Palvelu kaatuu välittömästi käynnistyksen jälkeen. Aja sudo systemctl status tor@default ja sudo journalctl -u tor@default -n 50. Yleisin syy on virheellinen torrc-syntaksi tai vaiheessa kuusi mainittu tiedosto-oikeusongelma /var/lib/tor-hakemistossa.
  7. Rele ei koskaan saa Guard-lippua. Guard-lippu vaatii pitkäaikaista, tasaista käytettävyyttä ja riittävää mitattua kaistaa. Jos BandwidthRate on asetettu liian matalaksi, hakemistoauktoriteetit eivät koskaan arvioi relettä riittävän vakaaksi tähän rooliin. Tämä ei ole virhe, vaan odotettu käytös pienelle releelle, eikä se tarkoita, ettei rele silti auttaisi verkkoa.
  8. Palveluntarjoaja sulkee portin tai epää Tor-liikenteen kokonaan. Osa halpahintaisista VPS-tarjoajista suodattaa Tor-liikenteen automaattisesti väärinkäytösten ehkäisemiseksi. Jos ORPort ei koskaan avaudu ulkopuolelta huolimatta oikeista palomuuriasetuksista, ota yhteyttä tarjoajan tukeen ja kysy suoraan Tor-relun sallimisesta, tai vaihda porttiin, joka ei ole yhtä yleisesti suodatettu tarjoajan verkossa.

Oikeudelliset näkökulmat Suomessa ja Pohjoismaissa

Tor-releen pyörittäminen itsessään ei ole rikos missään Pohjoismaassa, mutta oikeudellinen tilanne ei ole täysin yhtenäinen EU:n sisälläkään, koska televiestintä-, tekijänoikeus- ja rikoslainsäädäntö säilyvät kansallisina kysymyksinä jäsenmaiden välillä. Keskeinen käytännön ero on releroolissa: tavallisen keski- tai guard-releen ylläpitäjä ei näe eikä käsittele liikenteen sisältöä, mikä pienentää vastuuriskiä merkittävästi verrattuna poistumisreleeseen, jonka IP-osoite näkyy kohdepalvelimien lokeissa liikenteen lähteenä.

Poistumisreleen ylläpitäjä voi saada väärinkäyttöilmoituksia, tekijänoikeusvaateita tai jopa viranomaisyhteydenottoja, vaikka itse ei olisi tehnyt mitään laitonta. Tästä syystä monet kokeneet operaattorit suosittelevat aloittamaan keskireleellä tai sillalla, ja siirtymään poistumisrooliin vasta, jos on valmis käsittelemään väärinkäyttöprosesseja järjestelmällisesti, esimerkiksi valmiin vastauspohjan ja selkeän exit-policyn avulla. EFF:n ylläpitämä oikeudellinen usein kysytyt kysymykset -sivusto on hyvä lähtökohta yleiskuvan hahmottamiseen, vaikka se ei korvaa paikallista oikeudellista neuvontaa Suomessa, Ruotsissa, Norjassa tai Tanskassa.

Käytännön suositukset ovat samat riippumatta siitä, missä Pohjoismaassa asut: älä säilytä liikennelokeja pidempään kuin operoinnin kannalta on välttämätöntä, pidä ContactInfo-kenttä ajan tasalla, hanki palveluntarjoajalta kirjallinen vahvistus siitä, että Tor-releen pyörittäminen on sallittua, ja dokumentoi releen tarkoitus ja konfiguraatio itsellesi muistiin. Jos harkitset poistumisrelettä, selvitä ensin, tarjoaako paikallinen yliopisto, tietoturvayhdistys tai muu järjestö mahdollisuutta pyörittää relettä sen infrastruktuurissa. Tämä on yleinen tapa jakaa oikeudellista ja operatiivista vastuuta yksittäisen henkilön sijaan, ja monissa yliopistoverkoissa on jo valmiit prosessit tähän.

Tietosuojan näkökulmasta releen ylläpitäjänä käsittelet lähinnä teknisiä lokitietoja, kuten yhteyksien aikaleimoja ja liikennemääriä, et yksittäisten käyttäjien henkilötietoja, koska keskirele ei tiedä kuka piirin toisessa päässä on. Silti kannattaa minimoida kerätty lokidata tarkoituksenmukaisuusperiaatteen mukaisesti: pidä oletuslokitaso tuotannossa, kytke yksityiskohtaisempi debug-taso päälle vain vianmäärityksen ajaksi, ja poista väliaikaiset debug-lokit heti, kun ongelma on ratkaistu. Tämä on hyvä käytäntö riippumatta siitä, minkä tulkinnan alle releen ylläpito omassa maassasi tarkalleen asettuu.

Avainten varmuuskopiointi ja releen pitkäaikainen ylläpito

Kun rele on pyörinyt muutaman viikon ja alkanut kerätä mainetta verkossa, sen identiteettiavaimet muuttuvat arvokkaiksi. Rele tunnistetaan verkossa sen kryptografisen sormenjäljen perusteella, ja jos avaimet katoavat palvelimen kaatuessa, joudut aloittamaan maineen keräämisen alusta uudella identiteetillä. Avaimet sijaitsevat oletuksena hakemistossa /var/lib/tor/keys/, ja ne kannattaa varmuuskopioida heti, kun rele on käynnistynyt onnistuneesti ensimmäisen kerran.

sudo tar -czf tor-relay-keys-backup.tar.gz -C /var/lib/tor keys
scp tor-relay-keys-backup.tar.gz kayttaja@varmuuskopiopalvelin:/turvallinen/sijainti/

Säilytä varmuuskopio erillään itse releestä, mieluiten salattuna, koska kuka tahansa avaimet saava voisi teoriassa esiintyä releenäsi verkossa. Jos siirrät releen kokonaan toiselle palvelimelle, palauta samat avaimet ennen uutta käynnistystä niin verkko tunnistaa sen jatkuvana, jo tunnettuna releenä eikä aloita mainetta nollasta.

Pitkällä aikavälillä releen ylläpito on suurelta osin rutiinia: pidä käyttöjärjestelmä ja Tor-paketti ajan tasalla automaattisilla turvapäivityksillä, tarkista lokit muutaman viikon välein Nyxillä tai journalctl-komennolla, ja seuraa releen mainetilastoja Tor Metricsissä. Jos suunnittelet vaihtavasi palveluntarjoajaa tai siirtäväsi relettä, tee siirto ilmoittamalla ensin uudesta IP-osoitteesta torrc-tiedostossa ja odota, että verkko ehtii päivittää tiedon, ennen kuin sammutat vanhan palvelimen kokonaan.

Edistyneet vinkit kokeneemmalle operaattorille

Kun ensimmäinen rele on pyörinyt vakaasti muutaman viikon, seuraavat säädöt parantavat sekä verkon monimuotoisuutta että oman ylläpidon sujuvuutta pitkällä aikavälillä.

  • MyFamily-asetus useammalle releelle. Jos pyörität useampaa relettä, ilmoita ne toisilleen MyFamily-direktiivillä torrc:ssä. Tämä kertoo Tor-verkolle, että releet kuuluvat samalle operaattorille, jolloin asiakasohjelmisto ei valitse kahta samaan operaattoriin kuuluvaa relettä samaan piiriin, mikä parantaa käyttäjien todellista anonymiteettiä huomattavasti.
  • Hajauta releet eri ASN-numeroiden ja maiden kesken. Verkon kannalta arvokkain lisäys ei ole kymmenes rele samalta palveluntarjoajalta, vaan ensimmäinen rele täysin uudessa verkossa tai maassa. Tor-projektin yliopistoyhteistyöresurssit tarjoavat valmiita malleja tähän, jos harkitset relettä organisaation puolesta.
  • Käytä AccountingMax-asetusta yhdessä kellonaikaan sidotun AccountingStart-asetuksen kanssa mitatuilla VPS-sopimuksilla, jotta kuukausikiintiö ei koskaan yllätä laskutuksessa yllättävän piikin sattuessa.
  • Suojaa palvelunestohyökkäyksiltä nftables-säännöillä. Releoperaattoreiden foorumilla käsiteltiin syyskuussa 2026 tapauksia, joissa yksittäinen rele sai epätavallisen suuren määrän sisääntulevaa liikennettä ilman vastaavaa lähtevää liikennettä, mikä on tyypillinen merkki hyökkäysyrityksestä. Nopeusrajoitussäännöt ORPort-yhteyksille auttavat rajaamaan vaikutusta ilman, että rele lakkaa toimimasta kokonaan.
  • Harkitse konttipohjaista ylläpitoa suuremmassa mittakaavassa. Jos pyörität useampaa relettä, Docker- tai systemd-pohjainen automaatio helpottaa versionhallintaa ja torrc-tiedostojen ylläpitoa yhdenmukaisena kaikilla palvelimilla samanaikaisesti.

Konttipohjainen ylläpito kannattaa erityisesti, jos suunnittelet pyörittäväsi useampaa relettä eri palvelimilla samalla pohjakonfiguraatiolla. Yksinkertaisin tapa on liittää torrc-tiedosto konttiin volyyminä, jolloin itse konttikuva pysyy muuttumattomana ja vain konfiguraatio vaihtelee palvelimien välillä.

# docker-compose.yml -runko keskireleelle
services:
  tor-relay:
    image: debian:12-slim
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./torrc:/etc/tor/torrc:ro
      - tor-data:/var/lib/tor
    command: >
      bash -c "apt-get update && apt-get install -y tor &&
      tor -f /etc/tor/torrc"
volumes:
  tor-data:

Tämä runko on tarkoituksella yksinkertainen lähtökohta, ei tuotantovalmis ratkaisu sellaisenaan. Tuotantokäytössä kannattaa rakentaa oma, kiinteä konttikuva sen sijaan, että asennus tehdään joka käynnistyksellä uudelleen, ja varmistaa, että tor-data-volyymi säilyy pysyvänä myös kontin päivitysten yli, jotta identiteettiavaimet eivät katoa.

Käytännön esimerkki uusien yhteyksien rajoittamisesta ORPortiin nftables-säännöllä näyttää tältä. Se ei estä normaalia Tor-liikennettä, mutta hidastaa massiivista yhteydenavausryöppyä yhdestä lähteestä.

sudo nft add rule inet filter input tcp dport 443 \
  ct state new limit rate 20/second burst 40 packets accept
sudo nft add rule inet filter input tcp dport 443 counter drop

Testaa sääntöä ensin lyhyellä aikaikkunalla ja seuraa Nyxin yhteysnäkymää, ennen kuin otat säännön pysyvästi käyttöön palomuurin konfiguraatiotiedostossa. Liian tiukka nopeusrajoitus voi vahingossa katkoa myös laillisia Tor-asiakkaita, jotka avaavat useita piirejä lyhyessä ajassa.

Valmis kokonaisuus: koko projektin kokoaminen yhteen

Alla on koottu koko releasennuksen keskeiset tiedostot yhteen, jotta voit kopioida ne suoraan tuotantopalvelimelle. Tämä yhdistelmä toteuttaa keskireleen bandwidth-rajoituksella, kuukausikatolla ja automaattisella käynnistyksellä yhdellä ajolla.

# setup-tor-relay.sh: suorita sudo-oikeuksin
#!/bin/bash
set -e
apt update && apt full-upgrade -y
apt install -y tor nyx ufw

cp /etc/tor/torrc /etc/tor/torrc.orig
cat > /etc/tor/torrc <<'EOF'
Nickname OmaEnsimmainenRele
ContactInfo [email protected]
ORPort 443
ExitRelay 0
ExitPolicy reject *:*
BandwidthRate 20 MBytes
BandwidthBurst 30 MBytes
AccountingMax 2 TBytes
AccountingStart month 1 00:00
ControlPort 9051
CookieAuthentication 1
EOF

ufw allow 443/tcp
ufw allow ssh
ufw --force enable

systemctl enable --now tor@default
sleep 15
systemctl status tor@default --no-pager
journalctl -u tor@default --since "2 minutes ago" | grep -i bootstrap

Skripti kattaa asennuksen, torrc-konfiguraation, palomuurisäännöt ja käynnistyksen yhdellä ajolla. Muista vaihtaa ContactInfo-kenttä omaan osoitteeseesi ja säätää BandwidthRate-arvo palvelimesi todellisen kaistan mukaan ennen ajoa. Tallenna skripti esimerkiksi nimellä setup-tor-relay.sh, tee siitä suoritettava komennolla chmod +x setup-tor-relay.sh ja aja se komennolla sudo ./setup-tor-relay.sh.

Ajon jälkeen kannattaa vielä varmistaa portin tavoitettavuus ulkopuolelta erillisellä koneella, esimerkiksi omalta kotikoneelta, sen sijaan että luotat pelkkään paikalliseen lokiin. Tämä paljastaa nopeasti, jos palveluntarjoajan verkon tasolla on ylimääräinen este, jota palvelin itse ei näe.

# Aja tämä ERI koneelta kuin itse rele
nc -vz palvelimen-ip-osoite 443

Jos yhteys onnistuu, tuloste kertoo portin olevan avoinna. Jos yhteys aikakatkeaa, ongelma on todennäköisesti palveluntarjoajan verkon tasolla, ei enää palvelimen omassa palomuurissa tai torrc-konfiguraatiossa. Tämä pieni ulkopuolinen testi säästää usein tunteja turhaa konfiguraation muokkaamista, kun todellinen syy piileekin palvelimen ulkopuolella.

Kun rele on pyörinyt muutaman päivän vakaasti, voit laajentaa samaa runkoa lisäämällä obfs4-sillan rinnalle toiselle palvelimelle tai toiseen porttiin samalla koneella. Jos harkitset myös oman viestintäpalvelun pystyttämistä Tor-verkon ulkopuolelle, Matrix Synapse -palvelimen asennusoppaamme käyttää monelta osin samaa systemd- ja palomuurilogiikkaa kuin tämä opas, joten opit siirtyvät suoraan seuraavaan projektiin.

Miten releesi liittyy laajempaan yksityisyysketjuun

Oma rele ei korvaa muita yksityisyystyökaluja, vaan täydentää niitä verkon tasolla. Jos käytät itse Tor-verkkoa selaamiseen, kannattaa silti tarkistaa säännöllisesti, ettei oma VPN-yhteytesi vuoda tietoja ohi tunnelin: VPN-vuototestiä käsittelevä oppaamme käy läpi tähän tarvittavat työkalut yksityiskohtaisesti. Vastaavasti, jos tavoitteena on täysi anonyymiys käyttöjärjestelmätasolla eikä pelkkä selainliikenne, Whonixin asennus erillisenä työasema- ja yhdyskäytäväympäristönä tarjoaa vahvemman eristyksen kuin tavallinen Tor Browser -asennus yksinään.

Näiden työkalujen yhdistäminen muodostaa huomattavasti vahvemman kokonaisuuden kuin mikään yksittäinen työkalu erikseen: oma rele tukee verkkoa, VPN-vuototestaus varmistaa oman liikenteen, ja Whonix tarjoaa tarvittaessa käyttöjärjestelmätason eristyksen. Rele on tässä ketjussa ainoa osa, joka hyödyttää suoraan myös muita käyttäjiä, ei vain sinua itseäsi, ja siksi se on hyvä lisä kokonaisuuteen, vaikka et itse käyttäisikään Tor-verkkoa päivittäin.

Monelle tässä oppaassa kuvattu keskirele on ensimmäinen kosketus palvelinylläpitoon ylipäätään. Jos huomaat pitäväsi asennuksesta ja ylläpidosta, sama systemd- ja palomuuriosaaminen siirtyy suoraan muihinkin itse isännöityihin palveluihin, kuten salattuun sähköpostiin tai omaan viestintäpalvelimeen. Tor-rele on tässä mielessä hyvä ensimmäinen projekti juuri siksi, että virheiden riski on matala: pahimmillaan rele vain lakkaa toimimasta, eikä väärä konfiguraatio vaaranna mitään omaa dataa tai palvelua taustalla.

Usein kysytyt kysymykset

Onko oman Tor-releen pyörittäminen laillista Suomessa?
Kyllä, tavallisen keski- tai guard-releen pyörittäminen on laillista. Poistumisrele tuo mukanaan enemmän käytännön vastuuta väärinkäyttöilmoitusten käsittelyssä, mutta ei ole itsessään laitonta. Tarkista aina myös palveluntarjoajasi omat käyttöehdot ennen asennusta.

Paljonko kaistaa rele tarvitsee minimissään?
Tor toimii teknisesti hyvin pienelläkin kaistalla, mutta käytännön hyöty verkolle kasvaa selvästi, kun BandwidthRate on vähintään muutamia megatavuja sekunnissa. Hyvin pieni rele ei koskaan saa Guard-lippua, mutta se silti auttaa verkon kokonaiskapasiteettia.

Voinko pyörittää relettä kotoa käsin?
Teknisesti kyllä, mutta se ei ole suositeltavaa. Kotiliittymät ovat usein CGNAT:n takana, mikä estää ORPortin tavoitettavuuden, ja monen operaattorin käyttöehdot kieltävät julkisten palvelimien pyörittämisen kotiliittymässä kokonaan.

Mikä ero on releellä ja VPN-palvelimella?
VPN-palvelin näkee kaiken sen läpi kulkevan liikenteen, koska yhteys puretaan yhdessä pisteessä. Tor-rele on vain yksi kolmesta hypystä eikä pura viimeistä salauskerrosta itse, joten tavallinen keskirele ei näe liikenteen sisältöä eikä lopullista kohdetta.

Kuinka kauan kestää, ennen kuin rele saavuttaa täyden mitatun kaistan?
Hakemistoauktoriteetit mittaavat releen kapasiteettia asteittain useiden päivien tai viikkojen aikana. Uusi rele saa aluksi vain murto-osan sallitusta kaistastaan käyttöön, ja mitattu kaista kasvaa vähitellen sitä mukaa, kun rele osoittautuu vakaaksi ja luotettavaksi ajan kuluessa.

Näkeekö kukaan mitä liikennettä releeni välittää?
Keski- tai guard-releenä toimiessaan palvelimesi käsittelee vain salattua liikennettä, eikä se voi purkaa sisältöä. Vain poistumisrele näkee liikenteen selväkielisenä, koska se on ketjun viimeinen lenkki ennen kohdepalvelinta.

Kannattaako aloittaa poistumisreleellä?
Ei. Aloita keskireleellä tai sillalla, opettele ylläpito ja seuranta, ja harkitse poistumisroolia vasta myöhemmin, jos olet valmis vastaamaan väärinkäyttöilmoituksiin järjestelmällisesti.

Paljonko releen pyörittäminen maksaa kuukaudessa?
Kustannus riippuu suoraan VPS-tarjoajasta ja valitusta kaistarajasta. Pienimmät VPS-paketit, jotka täyttävät tässä oppaassa mainitut minimivaatimukset, ovat yleensä halvimman hintaluokan palvelimia. Suurempi kaistanleveys ja korkeampi kuukausisiirtoraja nostavat hintaa suoraan tarjoajan hinnaston mukaan.

Mitä teen, jos haluan lopettaa releen pyörittämisen?
Sammuta palvelu komennolla sudo systemctl disable --now tor@default ja odota muutama päivä, että rele häviää julkisesta listasta luonnollisesti. Älä vain katkaise palvelinta yhtäkkiä ilman siistiä sammutusta, koska se voi jättää releen näkymään verkossa virheellisesti vielä pitkään sammutuksen jälkeen.

Voinko vaihtaa releen roolia myöhemmin, esimerkiksi keskireleestä silaksi?
Kyllä, torrc-tiedosto voi periaatteessa määrittää releen useaan rooliin, mutta selkeintä on pitää yksi palvelin yhdessä roolissa kerrallaan. Jos haluat kokeilla siltaa, helpoin tapa on lisätä se toiseen porttiin samalla palvelimella tai pystyttää se kokonaan uudelle palvelimelle, jotta keskireleen kertynyt maine ei häiriinny muutoksesta.

Miten tiedän, että releeni todella auttaa verkkoa?
Seuraa releesi tunnistetta Tor Metrics -palvelussa. Kun rele ilmestyy listalle ja alkaa kerätä mitattua kaistaa ja mahdollisesti Guard-lippua, se on aktiivisesti osa verkon reititystä ja välittää oikeiden käyttäjien liikennettä joka päivä.