Paano Magpatakbo ng Tor Relay sa Iyong VPS

Ano ang ginagawa ng Tor relay sa isang VPS

Ang Tor relay ay isang Tor daemon sa machine na may public IP address. Nagpapasa ito ng naka-encrypt na traffic para sa ibang tao. Pino-publish ito ng directory authorities, at bumubuo ang Tor clients ng mga circuit sa pamamagitan nito. Ang guard o middle relay ay nagpapasa lamang ng traffic sa isa pang relay. Hindi ito kumokonekta sa website para sa ibang tao. Dahil dito, hindi ito karaniwang nakatatanggap ng abuse mail. Ito rin ang kontribusyong angkop sa isang ordinaryong VPS. Nagpapasa ang relay ng traffic ng ibang tao at wala itong sariling pino-publish. Kaya kung ang gusto mo ay ilagay sa network ang sarili mong site sa halip na magpasa ng mga packet para rito, ibang gawain ang pagpapatakbo ng v3 onion service sa likod ng nginx gamit ang parehong tor daemon. Wala ring ginagawa ang pagpapatakbo ng relay para sa privacy ng sarili mong browsing. Hiwalay na problema ito, at mas limitado ang pakinabang kaysa sa inaasahan ng karamihan: magandang sukatan kung gaano kalaki ang naitutulong ng paglipat ng isang serbisyo sa sarili mong VPS ang kung ano talaga ang itinatago ng pag-self-host ng SearXNG.

Maliit ang kinakailangang setup: isang package, labinlimang linya ng config, isang firewall rule, at isang restart. Ang natitirang bahagi ng guide na ito ang karaniwang nagkakaproblema. Kasama rito ang bandwidth arithmetic sa isang metered plan at ang dahilan kung bakit mukhang hindi gumagana sa loob ng isang linggo ang isang bagong relay kahit ganap itong maayos.

Guard, middle, bridge, o exit: pumili bago mag-install

Isang daemon ang nagpapatakbo sa lahat ng apat na role. Ang configuration mo, kasama ang directory authorities, ang tumutukoy kung alin ka.

• Middle relay. Tumatanggap ito ng traffic mula sa isang guard at ipinapasa ito sa isa pang relay. Hindi ito direktang kumokonekta sa destination site. Dito nagsisimula ang bawat bagong relay.
• Guard relay. Pareho ang configuration, pero may idinadagdag na flag. Ibinibigay ng directory authorities ang Guard flag sa mga relay na sapat nang mabilis at stable sa loob ng itinakdang panahon. Hindi ikaw ang pumipili nito. Kailangan mo itong makuha, at ang configuration sa ibaba ang tumutulong para makuha mo ito.
• Bridge. Isang relay ito na sadyang hindi isinasama sa public directory at pribadong ipinapamahagi sa mga user sa mga lugar kung saan naka-block ang Tor. Ito ang may pinakamaliit na commitment sa apat: mababang bandwidth, walang public listing, at tamang unang hakbang kung maliit ang plano mo. Kailangan din nito ng obfs4 proxy na tumatakbo kasabay ng daemon at ibang set ng mga linya sa torrc. Ipinapaliwanag ng pag-set up ng obfs4 bridge sa isang murang VPS ang prosesong ito, pati kung paano ibinibigay sa mga user ang bridge line sa huli.
• Exit relay. Ito ang huling hop na nagbubukas ng connection papunta sa destination site. Ang bawat request ng user ay lumalabas gamit ang IP address mo, kaya ang mga abuse report at pagtatanong ng pulis ay mapupunta sa may-ari ng address na iyon.

Ang exit ang tanging role na hindi dapat patakbuhin sa isang general-purpose VPS. Magpatakbo lamang ng exit sa provider na sumang-ayon nang maaga na tumanggap ng mga email tungkol dito, may sarili itong IP address, at may public na abuse contact. Ipinagbabawal ito ng karamihan sa standard hosting terms. Karaniwang resulta ng pagbalewala rito ang pagsuspinde sa server at pagkawala ng IP address. Kung ito pa rin ang gusto mong gawin, ipinapaliwanag sa kung ano talaga ang kasangkot sa pagpapatakbo ng exit relay kung paano maghanap ng exit-friendly host, magsulat ng exit policy at reverse DNS, at sumagot sa email kapag dumating ito. Parehong nagdadala ng user traffic ang guard at middle relay, pero wala ang ganitong exposure.

Ang lahat ng nasa ibaba ay nagko-configure ng guard/middle relay. ExitRelay 0 ang linyang nagpapanatili rito sa ganitong role.

Mga Kailangan ng VPS Bago Ka Magsimula

Nagtatakda ang Tor Project ng mahigpit na requirement para sa mga relay. Noong August 2026, kabilang dito ang isang public IPv4 address para sa relay, bandwidth na hindi bababa sa 10 Mbit/s sa bawat direksiyon at inirerekomendang 16 Mbit/s, hindi bababa sa 100 GB na outbound traffic bawat buwan, at 512 MB na RAM kung mas mababa sa 40 Mbit/s ang bandwidth o 1 GB kung mas mataas dito. Walang itinakdang fixed uptime, pero kaunti ang naitutulong sa network ng relay na tumatakbo nang wala pang dalawang oras bawat araw.

Inilalarawan ng 10 Mbit/s na value ang line, hindi ang setting. Kailangan mo ng port na kayang magbigay nito. Hiwalay na desisyon kung gaano kalaking bahagi ng line ang papayagan mong gamitin ng relay, batay sa buwanang transfer allowance. Basahin ang plan mo bago mo baguhin ang config. Kung pumipili ka pa lang ng server, ipinapaliwanag sa kung magkano talaga ang gastos sa VPS bawat buwan kung paano ibinebenta ang transfer allowance, at ipinapakita sa pagsukat sa aktuwal na network throughput ng VPS kung paano alamin ang performance ng line gamit ang iperf3 sa halip na umasa sa sales page.

I-harden muna ang machine. Ang relay ay isang public service na gumagamit ng public address, at ini-scan ang address sa loob ng ilang minuto matapos itong i-publish. Sampung minuto lang ang kailangan para sa pag-lock down ng SSH gamit ang mga key at hardened na sshd config, at dapat itong gawin bago maging live ang relay, hindi pagkatapos.

I-install ang tor mula sa repository ng Tor Project

Gamitin ang sariling apt repository ng Tor Project sa halip na ang package ng distribution. Mas mabilis ang paglabas ng mga update sa relay code kaysa sa stable release, kaya nauuna sa repository na ito ang mga fix at nahuhuli ang package ng distribution sa pagitan ng mga release.

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

Idagdag ang signing key, pagkatapos ay ang repository. Kinukuha ang codename mula sa machine, kaya gumagana ang parehong block sa Ubuntu 24.04 (noble) at Debian 13 (trixie).

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

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

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

Ipinapakita ng tor --version ang bersyon na kaka-install mo lang. Kung nag-print ang apt update ng error na NO_PUBKEY sa halip, wala sa path na tinukoy sa linyang Signed-By: ang dearmored key, kaya walang key ang apt na magagamit sa pag-verify ng release file. Mahalaga ang package na deb.torproject.org-keyring para sa mga susunod na hakbang: kasama nito ang signing key bilang ordinaryong package, kaya patuloy na gagana ang apt kapag pinalitan ang key.

I-on ang automatic upgrades, pagkatapos ay idagdag ang bagong origin sa configuration nito.

sudo apt install -y unattended-upgrades apt-listchanges

Sa Ubuntu, idagdag ang Tor origin sa block na Allowed-Origins sa /etc/apt/apt.conf.d/50unattended-upgrades:

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

Sa Debian, Origins-Pattern ang ginagamit ng parehong file; ang linyang idaragdag ay "origin=TorProject";. Suriin ang resulta gamit ang sudo unattended-upgrade --debug --dry-run. Ipinapakita nito ang mga origin na gagamitin nito at wala itong sinusulatan.

Ang mahalagang torrc

Nag-i-install ang package ng mahaba at maraming komentong /etc/tor/torrc. Iilan lamang sa mga linya nito ang mahalaga para sa isang relay. Idagdag ang mga ito sa dulo ng file.

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

Ang Nickname ay may 1 hanggang 19 character, at mga letra at digit lamang. Hindi ito natatangi sa network; ang fingerprint ang nagsisilbing identity nito. Ito ang gagamitin mo para mahanap ang sarili mong relay sa search box, kaya pumili ng pangalang madali mong ma-spell sa telepono.

Inilalathala ang ContactInfo sa relay descriptor. Isa itong public document na maaaring i-download ng kahit sino, kaya maaaring makuha ang address mula rito. Gumamit ng address na mababasa mo pa rin pagkalipas ng dalawang taon, at i-obfuscate ito kung gusto mo. Ito lamang ang channel ng Tor Project para balaan ka tungkol sa problema sa relay mo.

Ang ORPort 9001 ang port na ginagamit ng ibang relay at client para kumonekta. Karaniwang ginagamit ang 9001. Isa pang karaniwang pagpipilian ang port 443 dahil pinapayagan lamang ng ilang restrictive network ang outbound 443. Dahil dito, mas maraming client ang makakaabot sa relay na nakikinig dito. Piliin lamang ang 443 kung walang ibang serbisyo sa machine ang nangangailangan nito.

Isinasara ng SocksPort 0 ang lokal na SOCKS proxy, na hindi ginagamit ng relay, at inaalis ang isang listening socket sa machine. Isinusulat naman ng ExitRelay 0 ang layunin sa file: hindi kailanman kokonekta ang relay na ito sa isang destination para sa user, at hindi na kailangang hulaan ito ng sinumang susuri sa configuration sa hinaharap batay lamang sa default.

Kung may IPv6 address ang VPS, magdagdag ng pangalawang linya ng ORPort. Hindi makapag-bind ang Tor sa "any" IPv6 address gaya ng ginagawa nito sa IPv4, kaya isulat ang address sa loob ng square brackets.

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

Sa isang 1 GB VPS, idagdag ang MaxMemInQueues 512 MB. Tinutukoy ng Tor ang queue limit batay sa memory na nakikita nito sa machine. Sa maliit na shared box, maaaring mas mataas ito kaysa sa gusto mong gamitin ng Tor. Kapag ikaw mismo ang nagtakda ng limit, dini-discard ng Tor ang mga naka-queue na cell kapag mataas ang pressure. Nakaliligtas dito ang relay sa halip na patuloy na lumaki ang paggamit ng memory hanggang patayin ng kernel ang process.

Buksan ang ORPort sa firewall

Sa inbound traffic, dapat maabot ang ORPort mula sa kahit saan sa internet. Sa outbound traffic, huwag higpitan ang relay. Kumokonekta ito sa libo-libong ibang relay gamit ang maraming magkakaibang port, kaya tahimik itong mapipinsala ng outbound allowlist.

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

Suriin din ang network firewall ng provider. Maraming control panel ang nagpapatakbo ng packet filter sa harap ng virtual machine. Walang epekto roon ang idinagdag mong rule gamit ang ufw. Dahil dito, lumalabas na open ang port sa server ngunit closed mula sa labas. Kung bago sa iyo ang ufw, ipinapaliwanag sa mga ufw rule na dapat nasa bawat VPS ang default policy at ang pagkakasunod-sunod ng pagtutugma ng mga rule.

Iayon ang bandwidth sa iyong plan

Inilalarawan ng manual ang RelayBandwidthRate bilang hiwalay na token bucket na naglilimita sa “average incoming bandwidth usage para sa relayed traffic sa node na ito sa tinukoy na bilang ng bytes bawat segundo, at sa average outgoing bandwidth usage sa kaparehong halaga.” Basahin iyon nang dalawang beses. Hiwalay na ipinapatupad ang limit sa bawat direksiyon. Ang relay na nakatakda sa 1 Mbit/s ay maaaring maglipat ng 1 Mbit/s papasok at 1 Mbit/s palabas nang sabay, at kung parehong direksiyon ang sinusukat ng provider, ang kabuuan ang sisingilin.

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

Ang 5 row na iyon ay kalkulasyon, hindi aktuwal na sukat: ipinapakita ng mga ito kung magkano ang halaga ng isang rate kung mapapanatili ito ng relay nang buong 30 araw sa parehong direksiyon. Kadalasang mas mababa sa cap ang aktuwal na relay, lalo na sa mga unang linggo. Gamitin ang table upang alisin ang mga setting na hindi pasok sa budget, hindi upang hulaan ang invoice hanggang gigabyte.

Sa 1 Mbit/s bawat direksiyon, naglilipat ang relay ng humigit-kumulang 21.6 GB bawat araw, kaya ang 30 araw na buwan ay nagkakahalaga ng humigit-kumulang 648 GB ng metered traffic. Pasok ito sa 1 TB allowance at may matitira pa para sa updates at backups. Kapag itinaas sa 2 Mbit/s, magiging 1,296 GB ang konsumo sa isang buwan, na lampas na sa 1 TB plan. Ang huling row, 20 Mbit/s, ay nangangailangan ng 12,960 GB bawat buwan at dapat ilagay sa unmetered port. Kung outbound traffic lang ang sinisingil ng provider mo, hatiin sa dalawa ang bawat halaga. Alamin muna kung alin ang ginagamit mo bago itakda ang rate, dahil dalawang beses ang diperensiya ng dalawang sagot.

Ngayon ang config. Unahin ang rate limit, saka ang quota.

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

Ang RelayBandwidthBurst ang laki ng token bucket, kaya pinapayagan nito ang maiikling spike na lampas sa rate habang pinananatili ang average. Makatuwirang itakda ito sa humigit-kumulang dalawang beses ng rate.

Ang AccountingRule ang linyang pinakamadalas makaligtaan ng mga operator. Ang default ay max, na sumusukat sa mas malaki sa dalawang direksiyon laban sa quota. Sa default, pinapayagan ng AccountingMax 400 GBytes ang 400 GB papasok at 400 GB palabas, o 800 GB sa meter na parehong direksiyon ang binibilang. Binibilang ng AccountingRule sum ang pinagsamang read at write laban sa iisang quota, na siyang aktuwal na sinusukat ng transfer allowance.

Isulat din ang AccountingStart; huwag gamitin ang AccountingMax nang mag-isa. Ang quota ang nagsasaad ng bilang, at ang start line ang nagsasaad kung kailan ito nire-reset. Kapag walang period ang quota, mananatiling naka-hibernate ang relay at walang magbabalik dito sa operasyon.

Magaspang na mekanismo ang hibernation. Kapag naubos ang quota, ila-log ito ng tor at hihinto sa pagtanggap ng trabaho:

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

Hindi rin eksaktong magsisimula muli ang relay sa simula ng susunod na period. Sinusubaybayan ng Tor kung gaano kabilis naubos ang huling quota at pumipili ng random na oras sa loob ng bagong interval, upang hindi sabay-sabay bumalik sa network ang libo-libong relay. Ang relay na nawawala sa huling linggo ng bawat buwan ay patuloy na nawawalan ng stability na sinusukat dito ng directory authorities. Itakda ang RelayBandwidthRate upang hindi kailanman maabot ang cap, at panatilihin ang AccountingMax bilang backstop na nagpoprotekta sa invoice.

Simulan ang relay at tiyaking maaabot ito

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

Sa loob ng ilang minuto, dapat maglaman ang log ng linyang ito:

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

Ibig sabihin nito, kumonekta pabalik sa iyong ORPort ang ibang relay at bumuo sila ng circuit sa pamamagitan nito. Hangga't hindi ito lumalabas, wala pa sa directory ang iyong relay at wala itong pinapadalang traffic. Ganito ang hitsura ng error:

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

Suriin ito ayon sa pagkakasunod-sunod. Bukas ba ang ORPort sa ufw? Bukas din ba ito sa hiwalay na network firewall ng provider? Ang address ba sa mensaheng iyon ang address na aktuwal na ginagamit ng internet para maabot ka, at hindi isang private address mula sa NAT setup? Subukan ang port mula sa ibang machine gamit ang nc -vz 203.0.113.10 9001. Awtomatikong inuulit ng Tor ang self-test, kaya mapapansin nito ang naayos na firewall kahit wala kang gawin. Nagiging agad ang pagsubok kapag nag-restart.

Ang permanenteng identity ng iyong relay ay ang fingerprint nito:

sudo cat /var/lib/tor/fingerprint

Humigit-kumulang tatlong oras matapos ma-publish ang descriptor, lalabas ang relay sa Relay Search. Hanapin ang nickname o i-paste ang fingerprint. Ipinapakita ng page na iyon kung paano nakikita ng network ang iyong relay: kung aling mga flag ang taglay nito, anong weight ang ibinibigay rito ng mga authority, at kung anong version ang pino-publish nito.

Bakit halos walang traffic ang isang bagong Tor relay?

Dahil hindi pa ito nasusukat ng network, at inaabot ng ilang linggo ang pagsukat. Inilalarawan ng Tor Project ang pagtaas ng kapasidad sa apat na yugto. Kapag hindi ito nabasa ng operator, iisipin niyang sira ang relay at magsisimula siyang magpalit ng mga setting.

Sa unang tatlong araw, hindi sinusukat ang relay. Iniuulat nito ang resulta ng sarili nitong self-test, ngunit nililimitahan pa rin ng directory authorities sa 20 KB ang published weight nito. Dahil dito, halos hindi ito pinipili ng mga client. Mula humigit-kumulang ikatlong araw hanggang ikawalong araw, aktuwal itong sinusukat ng bandwidth authorities at tumataas ang weight nito. Gayunman, middle hop lamang ang gamit dito dahil walang client na handang gawing unang hop ang isang bagong relay.

Sa paligid ng ikawalong araw, nagiging eligible ang relay para sa Guard flag. Kapag nakuha nito ang flag, bumababa ang traffic, na ikinagugulat ng marami. Iniiwasan ng mga client ang mga guard kapag pumipili ng middle hop dahil ipinapalagay nilang may ginagamit nang guard. Kaya nawawala sa relay ang middle traffic bago ito magkaroon ng guard traffic. Unti-unti lamang itong nakakabawi habang nagpapalit ang mga client ng guard set, at inaabot ito ng ilang linggo. Sa humigit-kumulang ika-68 araw, naaabot nito ang steady state, kung saan nagtutumbasan ang mga client na nag-aalis dito at ang mga client na nagdaragdag dito.

Kaya ang makatotohanang inaasahan ay walang traffic sa loob ng tatlong araw, may kaunting traffic pagkalipas ng isang linggo, at may tunay na load pagkalipas ng dalawang buwan. Isang setting lang ang baguhin, pagkatapos ay maghintay ng isang linggo upang makita ang epekto nito. Mas kapaki-pakinabang na gamitin ang enerhiyang dulot ng pag-aalala sa isang self-hosted Uptime Kuma status page na may TCP check sa port 9001. Sasagutin nito ang tanong na kaya mong kontrolin: kung tumutugon pa rin ang port.

Subaybayan ang relay gamit ang nyx

Ang nyx ang terminal monitor para sa tumatakbong relay. Nakikipag-ugnayan ito sa control port ng tor, kaya i-enable muna ito sa torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

Ang ControlPort ay nakikinig lamang sa 127.0.0.1, at nangangahulugan ang cookie authentication na kailangang magbasa ang isang program ng secret file bago ito makapagpatupad ng mga command. Isinusulat ng Tor ang cookie sa /run/tor/control.authcookie bilang user na debian-tor, na may mode na 600, kaya walang ibang makakabasa nito. Binubuksan ito ng CookieAuthFileGroupReadable 1 para sa group. Dahil dito, maaaring patakbuhin ng sarili mong account ang nyx nang hindi gumagamit ng sudo.

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

Mag-log out at mag-log in muli, pagkatapos ay patakbuhin ang nyx. Kailangang ma-load ang bagong group sa pag-login. Kung patatakbuhin mo ang nyx sa parehong shell session, magkakaroon ng permission error sa cookie file kahit tama ang configuration. Ipinapakita ng nyx ang live bandwidth, uptime, log stream, at listahan ng mga koneksyon. Sa mga unang linggo, ang dapat subaybayan ay ang bandwidth graph at tiyaking nananatili itong mas mababa sa iyong RelayBandwidthRate.

Pagpapatakbo ng higit sa isang relay: MyFamily at mga family key

Kung iisa lang ang relay, laktawan ang seksyong ito. Kailangang ideklara ng dalawa o higit pang relay na pinapatakbo ng iisang operator ang isa't isa. Sa ganitong paraan, hindi gagawa ang mga client ng circuit na pumapasok at lumalabas sa mga machine mo, na magbibigay sa isang operator ng kakayahang makita ang magkabilang dulo nito.

Ang matagal nang paraan ay ang MyFamily sa torrc ng bawat relay, na naglilista ng mga fingerprint ng lahat ng iba pang relay:

MyFamily AAAAAAAAAA,BBBBBBBB

Inililista ng bawat relay ang lahat ng iba pang relay. Kaya kapag nagdagdag ng ikaapat na relay, kailangan mong mag-edit ng apat na file. Pinalitan ito ng Tor 0.4.9 ng isang family key. Bumuo ng isang key, pagkatapos ay ibahagi ito:

tor --keygen-family myfamily

Isinusulat nito ang myfamily.secret_family_key at nagpi-print ng isang linyang FamilyId. Kopyahin ang key file sa bawat relay, sa keys subdirectory ng DataDirectory (/var/lib/tor/keys sa Debian at Ubuntu), at panatilihin ang .secret_family_key suffix. Idagdag ang na-print na linyang FamilyId sa bawat torrc at i-reload gamit ang sudo systemctl reload tor@default. Panatilihin din muna ang listahang MyFamily. Binabasa pa rin ng mga client na hindi pa nakauunawa ng family certificate ang legacy list. Ipaaalam ng Tor Project kapag maaari na itong alisin.

Mga nasisira matapos itong gumana

Nalaos ang bersyon. Pinapalitan ng unattended upgrades ang package, pero patuloy na ginagamit ng tumatakbong process ang binary na inilunsad nito hanggang sa ma-restart ito. Ihambing ang tor --version sa server sa bersyong ipinapakita sa Relay Search page ng relay. Kung magkaiba ang mga ito, luma pa rin ang nakikita ng network, kaya i-restart ang service.

Umaatras ang oras ng system clock. May takdang oras ang mga consensus document at certificate, kaya tinatanggihan ng machine na malaki ang diperensiya ng oras ang consensus at humihinto sa pag-publish. Dapat iulat ng timedatectl na synchronized ang system clock. Kung hindi, i-enable ang systemd-timesyncd o i-install ang chrony.

Nagbabago ang IP address. Nasa descriptor ang address, at hindi maaabot ng mga client ang address na nailipat. Pagkatapos ng anumang migration ng provider o pagbabago ng address, i-restart ang tor at bantayan muli ang self-test line.

Mas mabagal ang relay kaysa sa pinapayagan ng plan. Mahusay ang relay crypto ng Tor sa mga modern processor, at tinatantiya ng Tor Project na kayang umabot ang CPU na may AES-NI support sa humigit-kumulang 400 hanggang 450 Mbit/s sa bawat direksiyon. Matagal bago maabot ang limitasyong iyon, malilimitahan ka na ng bilis ng port at transfer allowance. Ito ang dahilan kung bakit mas mahalaga ang accounting section sa itaas kaysa sa hardware.

FAQ

Gaano karaming bandwidth ang ginagamit ng Tor relay?

Kasing dami lamang ng itinakda mong pahintulot, at wala nang higit pa. Nililimitahan ng RelayBandwidthRate ang relayed traffic nang magkahiwalay sa bawat direksiyon, kaya ang relay na itinakda sa 1 Mbit/s ay maaaring magdala ng 1 Mbit/s na papasok at 1 Mbit/s na palabas nang sabay. Katumbas ito ng humigit-kumulang 21.6 GB bawat araw, o 648 GB sa loob ng 30 araw na buwan, kasama ang parehong direksiyon. Idagdag ang AccountingMax kasama ng AccountingRule sum bilang hard monthly quota sa ilalim ng rate na iyon.

Magkakaroon ba ako ng abuse complaint kapag nagpatakbo ako ng Tor relay?

Ang guard relay o middle relay ay nagpapasa lamang ng traffic sa iba pang Tor relay at hindi kailanman direktang kumokonekta sa website para sa user. Kaya ang mga reklamo tungkol sa ginawa ng isang tao gamit ang Tor ay ipinapadala sa exit operator, hindi sa iyo. Ang maaari mong makita ay scanning at paminsan-minsang IP reputation listing, dahil pampublikong nakalista ang address bilang relay. Ang exit relay ang tumatanggap ng abuse mail at legal notices, at kailangan nito ng provider na sumang-ayon nang maaga na humawak ng mga iyon. Basahin ang terms ng provider bago simulan ang alinman sa dalawang uri.

Bakit walang traffic ang bago kong Tor relay?

Dahil sinasadyang i-throttle ang mga bagong relay hanggang masukat ang mga ito. Sa unang tatlong araw, nililimitahan ng directory authorities sa 20 KB ang published weight, kaya halos hindi pinipili ng mga client ang relay. Sinusukat ito ng bandwidth authorities mula humigit-kumulang ikatlong araw, nagiging eligible ito para sa Guard flag sa bandang ikawalong araw, at muling bumababa ang traffic sa puntong iyon dahil iniiwasan ng mga client ang mga guard kapag pumipili ng middle hop. Dumarating ang full load sa bandang ika-68 araw. Tiyaking ipinapakita ng log ang "Self-testing indicates your ORPort is reachable from the outside", pagkatapos ay huwag na itong baguhin.

Maaari ba akong magpatakbo ng Tor relay sa isang VPS na may 1 TB transfer allowance?

Oo, sa humigit-kumulang 1 Mbit/s sa bawat direksiyon, na katumbas ng RelayBandwidthRate 125 KBytes. Umaabot ito sa tinatayang 648 GB bawat buwan kung sinusukat ng provider ang parehong direksiyon, kaya may natitirang kapasidad para sa updates at backups. Idagdag ang AccountingMax 400 GBytes kasama ng AccountingRule sum at AccountingStart month 1 00:00 upang mag-hibernate ang relay sa halip na lumampas sa plan. Kung outbound lamang ang sinisingil ng provider, maaari mong doblehin ang rate.

Kailangan ko bang itakda ang MyFamily kung isa lamang ang relay na pinapatakbo ko?

Hindi. Ginagamit ang family declarations upang iwasan ng mga client ang pagbuo ng circuit sa pamamagitan ng dalawang relay na pagmamay-ari ng iisang operator. Wala itong kabuluhan kung iisa lamang ang relay. Itakda ito kapag nagdagdag ka ng ikalawa: ilista ang fingerprint ng bawat relay sa MyFamily line ng bawat relay, o gamitin ang family key na ipinakilala ng Tor 0.4.9. Ipinapamahagi nito ang isang FamilyId sa halip na isang listahang patuloy na humahaba.