VPS वर Tor guard किंवा middle relay कसे चालवायचे

VPS वर Tor relay काय करते

Tor relay हा सार्वजनिक IP address असलेल्या मशीनवर चालणारा Tor daemon आहे. तो इतर लोकांसाठी encrypted traffic पुढे पाठवतो. Directory authorities ही relay प्रकाशित करतात आणि Tor clients तिच्यामधून circuits तयार करतात. Guard किंवा middle relay traffic फक्त दुसऱ्या relay कडे पाठवते. त्यामुळे ती अनोळखी व्यक्तीच्या वतीने वेबसाइटशी connection कधीही उघडत नाही. या एका कारणामुळे abuse mail येत नाही. तसेच सामान्य VPS साठी हे योग्य योगदान ठरते. Relay इतर लोकांचा traffic वाहून नेते आणि स्वतःची कोणतीही माहिती प्रकाशित करत नाही. त्यामुळे नेटवर्कवर स्वतःची site उपलब्ध करून द्यायची असेल, आणि तिच्यासाठी packets पुढे पाठवायचे नसतील, तर nginx च्या मागे v3 onion service चालवणे हे त्याच tor daemon साठी वेगळे काम आहे. Relay चालवल्याने तुमच्या स्वतःच्या browsing च्या privacy मध्ये कोणतीही वाढ होत नाही. हा स्वतंत्र प्रश्न आहे आणि त्याची मर्यादा बहुतेक लोकांच्या अपेक्षेपेक्षा कमी असते: स्वतःच्या VPS वर SearXNG चालवल्याने प्रत्यक्षात काय लपते यावरून service स्वतःच्या VPS वर हलवल्याने किती फायदा होतो, याचा योग्य अंदाज येतो.

प्रत्यक्ष काम कमी आहे: एक package, config च्या पंधरा ओळी, एक firewall rule आणि एक restart. या मार्गदर्शकाचा उर्वरित भाग ज्या ठिकाणी समस्या निर्माण होतात त्याबद्दल आहे. Metered plan वरील bandwidth चे गणित आणि पूर्णपणे निरोगी असलेली नवीन relay एका आठवड्यासाठी बंद असल्यासारखी का दिसते, हे त्यात स्पष्ट केले आहे.

Guard, middle, bridge किंवा exit: install करण्यापूर्वी भूमिका निवडा

एकच daemon ही चारही भूमिका पार पाडतो. तुमची config आणि directory authorities मिळून तुम्ही कोणती भूमिका पार पाडता हे ठरवतात.

• Middle relay. हे guard कडून traffic स्वीकारते आणि तो दुसऱ्या relay कडे पाठवते. हे destination site शी कधीही थेट संपर्क साधत नाही. प्रत्येक नवीन relay याच भूमिकेपासून सुरू होते.
• Guard relay. हीच configuration वापरली जाते; तिच्यावर एक flag जोडला जातो. पुरेसा काळ वेगवान आणि स्थिर राहिलेल्या relay ला directory authorities Guard flag देतात. तुम्ही तो स्वतः निवडू शकत नाही. तो मिळवावा लागतो आणि खालील config मुळे तो मिळतो.
• Bridge. हा relay public directory मधून जाणीवपूर्वक वगळला जातो आणि Tor blocked असलेल्या ठिकाणी वापरकर्त्यांना खाजगीरित्या दिला जातो. चार भूमिकांपैकी ही सर्वांत कमी बांधिलकीची भूमिका आहे: कमी bandwidth, public listing नाही आणि तुमची योजना लहान असल्यास हा योग्य पहिला टप्पा आहे. daemon सोबत obfs4 proxy चालवावा लागतो आणि torrc lines चा वेगळा संच वापरावा लागतो. स्वस्त VPS वर obfs4 bridge सेट करणे या प्रक्रियेत हे सर्व स्पष्ट केले आहे. शेवटी bridge line वापरकर्त्यांपर्यंत कशी पोहोचवायची हेही त्यात दिले आहे.
• Exit relay. हा शेवटचा hop असतो आणि destination site शी connection उघडतो. वापरकर्ता केलेली प्रत्येक request तुमच्या IP address वरून बाहेर जाते. त्यामुळे abuse reports आणि police inquiries हा address ज्याच्या मालकीचा आहे त्याच्याकडे येतात.

Exit भूमिका general-purpose VPS वर चालवू नका. हा exit फक्त अशा provider वर चालवा, ज्याने अशी mail स्वीकारण्यास आधीच सहमती दर्शवली आहे, ज्याचा स्वतःचा IP address आहे आणि published abuse contact आहे. बहुतेक standard hosting terms हे प्रतिबंधित करतात. त्याकडे दुर्लक्ष केल्यास सामान्यतः server suspend होतो आणि IP address गमावला जातो. तरीही तुम्हाला हीच भूमिका पार पाडायची असल्यास, exit relay चालवण्यात प्रत्यक्षात काय समाविष्ट असते या मार्गदर्शिकेत exit-friendly host शोधणे, exit policy आणि reverse DNS लिहिणे, तसेच mail आल्यावर त्याला उत्तर देणे समाविष्ट आहे. Guard किंवा middle relay हीच user traffic हाताळतात, पण या प्रकारचा उघडपणा निर्माण करत नाहीत.

खालील सर्व configuration guard/middle relay तयार करते. ExitRelay 0 ही ती भूमिका एकच ठेवणारी line आहे.

सुरू करण्यापूर्वी VPS साठी आवश्यक गोष्टी

The Tor Project relay साठी आवश्यक असलेल्या अटी प्रकाशित करते. October 2026 नुसार त्या अशा आहेत: relay साठी एक public IPv4 address, प्रत्येक दिशेने किमान 10 Mbit/s bandwidth आणि 16 Mbit/s ची शिफारस, दरमहा किमान 100 GB outbound traffic, तसेच 40 Mbit/s पेक्षा कमी वेगासाठी 512 MB RAM किंवा त्यापेक्षा जास्त वेगासाठी 1 GB RAM. Uptime साठी कोणताही निश्चित नियम नाही. मात्र, दररोज दोन तासांपेक्षा कमी वेळ चालणारा relay नेटवर्कसाठी फारसा उपयुक्त नसतो.

10 Mbit/s हा आकडा line चा वेग दर्शवतो, setting नाही. तो वेग हाताळू शकणारा port आवश्यक आहे. त्या line पैकी relay ला किती bandwidth द्यायची, हा मासिक transfer allowance लक्षात घेऊन स्वतंत्रपणे घ्यायचा निर्णय आहे. Configuration मध्ये बदल करण्यापूर्वी तुमचा plan तपासा. अजून VPS निवडत असाल, तर VPS ची दरमहा प्रत्यक्ष किंमत किती असते येथे transfer allowances कशा विकल्या जातात हे स्पष्ट केले आहे. तसेच VPS चा प्रत्यक्ष network throughput मोजणे येथे sales page वर अवलंबून न राहता iperf3 वापरून line प्रत्यक्षात काय करू शकते हे कसे तपासायचे ते दाखवले आहे.

सर्वप्रथम machine harden करा. Relay ही public address वर चालणारी public service आहे आणि address प्रकाशित झाल्यानंतर काही मिनिटांत scan केला जातो. SSH ला keys आणि hardened sshd config पुरते मर्यादित करणे यासाठी दहा मिनिटे लागतात. Relay live करण्यापूर्वी हे करा; नंतर करू नका.

Tor Project repository मधून tor install करा

distribution package ऐवजी Tor Project चे स्वतःचे apt repository वापरा. Stable release पेक्षा relay code अधिक वेगाने बदलतो. त्यामुळे fixes या repository मध्ये प्रथम उपलब्ध होतात आणि releases दरम्यान distribution package मागे राहते.

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

Signing key जोडा आणि त्यानंतर repository जोडा. Codename मशीनमधून वाचले जाते. त्यामुळे हाच block Ubuntu 24.04 (noble) आणि Debian 13 (trixie) वर कार्य करतो.

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

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

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

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

tor --version तुम्ही नुकतीच install केलेली version दाखवते. त्याऐवजी apt update ने NO_PUBKEY error दाखवला असल्यास, dearmored key Signed-By: line मध्ये नमूद केलेल्या path वर नाही. त्यामुळे release file तपासण्यासाठी apt कडे key उपलब्ध नाही. deb.torproject.org-keyring package पुढे महत्त्वाचे ठरते. ते signing key सामान्य package म्हणून release करते. त्यामुळे key rotate केल्यावरही apt कार्यरत राहते.

Automatic upgrades सुरू करा आणि त्यांना नवीन origin बद्दल माहिती द्या.

sudo apt install -y unattended-upgrades apt-listchanges

Ubuntu वर Tor origin /etc/apt/apt.conf.d/50unattended-upgrades मधील Allowed-Origins block मध्ये जोडा:

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

Debian वर त्याच file मध्ये Origins-Pattern वापरले जाते. त्यात जोडायची line "origin=TorProject"; आहे. sudo unattended-upgrade --debug --dry-run वापरून परिणाम तपासा. हे command ज्या origins वर कृती केली जाईल ते दाखवते आणि काहीही लिहित नाही.

महत्त्वाचे torrc

पॅकेज एक लांब आणि भरपूर टिप्पण्या असलेली /etc/tor/torrc फाइल स्थापित करते. Relay साठी त्यातील केवळ काही ओळी महत्त्वाच्या आहेत. त्या फाइलच्या शेवटी जोडा.

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

Nickname मध्ये 1 ते 19 अक्षरे आणि अंक असतात. तो नेटवर्कवर अद्वितीय नसतो; तुमची ओळख fingerprint असते. Search box मध्ये स्वतःचा relay शोधण्यासाठी तुम्ही हे नाव वापराल. त्यामुळे फोनवरून सहज उच्चारता येईल असे नाव निवडा.

ContactInfo relay descriptor मध्ये प्रकाशित केला जातो. Relay descriptor हा सार्वजनिक दस्तऐवज असल्यामुळे कोणीही तो download करू शकतो आणि हा पत्ता scraped केला जाईल. दोन वर्षांनंतरही तुम्ही वाचत राहाल असा पत्ता वापरा. आवश्यक असल्यास तो obfuscate करा. तुमच्या relay मधील समस्येबद्दल Tor Project तुम्हाला इशारा देऊ शकणारे हेच एकमेव माध्यम आहे.

ORPort 9001 हा इतर relays आणि clients जोडण्यासाठी वापरला जाणारा port आहे. 9001 हा प्रचलित पर्याय आहे. Port 443 हाही सामान्य पर्याय आहे. काही प्रतिबंधित networks केवळ outbound 443 ला परवानगी देतात. त्यामुळे तिथे listening करणारा relay अधिक clients साठी reachable असतो. Box वर इतर कोणत्याही सेवेला Port 443 आवश्यक नसल्यासच तो निवडा.

SocksPort 0 स्थानिक SOCKS proxy बंद करतो. Relay त्याचा वापर करत नाही. यामुळे machine वरील एक listening socket कमी होतो. ExitRelay 0 ही अपेक्षा फाइलमध्ये स्पष्टपणे नोंदवतो: हा relay user च्या वतीने कोणत्याही destination शी कधीही connect होणार नाही. नंतर config वाचणाऱ्या व्यक्तीला हे default वरून अनुमान काढावे लागणार नाही.

VPS ला IPv6 address असल्यास tor तो आधीपासून वापरण्याचा प्रयत्न करतो. tor 0.4.5 पासून, address नसलेली ORPort line IPv4 आणि IPv6 दोन्हीवर listening करते आणि relay चा IPv6 address IPv4 address प्रमाणेच शोधते. Discovery चुकीचा address निवडत असल्यासच square brackets मध्ये address लिहिलेली दुसरी ORPort line जोडा. तसेच तो address reachable असल्याची खात्री असणे आवश्यक आहे. Reachability test अयशस्वी झालेला explicit IPv6 ORPort relay ला त्याचा descriptor publish करण्यापासून थांबवतो.

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

1 GB VPS वर MaxMemInQueues 512 MB जोडा. Machine वर दिसणाऱ्या memory नुसार Tor queue limit ठरवतो. छोट्या shared box वर ही मर्यादा तुम्हाला अपेक्षित वापरापेक्षा जास्त असू शकते. ही limit स्वतः निश्चित केल्यास दबाव असताना tor queued cells discard करतो आणि relay कार्यरत राहतो. अन्यथा queue वाढत जाऊन kernel process बंद करू शकतो.

Firewall मध्ये ORPort उघडा

Inbound दिशेने ORPort इंटरनेटवरील कोणत्याही ठिकाणाहून पोहोचण्यायोग्य असणे आवश्यक आहे. Outbound दिशेने relay वर कोणतेही निर्बंध ठेवू नका. ते अनेक वेगवेगळ्या port वर हजारो इतर relay शी connections उघडते. Outbound allowlist मुळे relay ची कार्यक्षमता नकळत गंभीरपणे कमी होईल.

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

त्यानंतर provider चा स्वतःचा network firewall तपासा. अनेक control panel virtual machine च्या पुढे packet filter चालवतात. त्यामुळे ufw ने जोडलेल्या rule चा तिथे काहीही परिणाम होत नाही. परिणामी, port server वर open दिसतो, पण बाहेरून closed दिसतो. ufw तुमच्यासाठी नवीन असल्यास, प्रत्येक VPS वर असायला हवेत असे ufw rules default policy आणि rules ज्या क्रमाने तपासल्या जातात ते स्पष्ट करते.

तुमच्या प्लॅननुसार bandwidth चे आकारमान ठरवा

Manual मध्ये RelayBandwidthRate स्वतंत्र token bucket म्हणून वर्णन केले आहे. हे “या node वरील relayed traffic साठी सरासरी incoming bandwidth usage निर्दिष्ट bytes per second पर्यंत आणि सरासरी outgoing bandwidth usage त्याच मूल्यापर्यंत मर्यादित” करते. हे दोनदा वाचा. मर्यादा प्रत्येक दिशेसाठी स्वतंत्रपणे लागू होते. 1 Mbit/s वर सेट केलेला relay एकाच वेळी 1 Mbit/s incoming आणि 1 Mbit/s outgoing traffic हाताळू शकतो. दोन्ही दिशांचे मोजमाप करणारा provider त्यांच्या बेरजेवर billing करतो.

[
  {
    "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"
  }
]

त्या 5 rows मोजमापावर आधारित नाहीत; त्या arithmetic आहेत. Relay पूर्ण 30 days दोन्ही दिशांनी तो rate सतत राखल्यास त्याची किंमत किती येईल, हे त्या दाखवतात. प्रत्यक्ष relay बहुतेक वेळा आपल्या cap पेक्षा कमी traffic वापरतो, विशेषतः पहिल्या काही weeks मध्ये. परवडत नसलेल्या settings वगळण्यासाठी table वापरा. Gigabyte नुसार invoice अचूक भाकीत करण्यासाठी ती वापरू नका.

प्रत्येक दिशेस 1 Mbit/s असल्यास relay दररोज सुमारे 21.6 GB traffic हाताळतो. त्यामुळे 30 day month मध्ये metered traffic सुमारे 648 GB येईल. हे 1 TB allowance मध्ये updates आणि backups साठी काही जागा ठेवून बसते. 2 Mbit/s पर्यंत वाढवल्यास त्या month मध्ये 1,296 GB लागतील. हे 1 TB plan पेक्षा आधीच जास्त आहे. शेवटच्या row मधील 20 Mbit/s साठी दर month ला 12,960 GB लागतात. त्यामुळे तो unmetered port वर चालवावा. तुमचा provider फक्त outbound traffic साठी billing करत असल्यास प्रत्येक figure अर्धा करा. Rate सेट करण्यापूर्वी तुमच्याकडे कोणती billing पद्धत आहे ते निश्चित करा. कारण या दोन पर्यायांमध्ये दोनपट फरक असतो.

आता config पाहू. आधी rate limit आणि त्यानंतर quota सेट करा.

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

RelayBandwidthBurst हे token bucket चे आकारमान आहे. त्यामुळे average rate कायम ठेवताना ते rate पेक्षा जास्त असलेले short spikes अनुमत करते. Rate च्या सुमारे दुप्पट value योग्य आहे.

AccountingRule ही ओळ बहुतेक operators कडून दुर्लक्षित होते. Default value max आहे. ती quota विरुद्ध दोन दिशांपैकी जास्त वापर मोजते. Default वापरल्यास AccountingMax 400 GBytes 400 GB incoming आणि 400 GB outgoing अनुमत करते. दोन्ही दिशांचे मोजमाप करणाऱ्या meter वर हे 800 GB होते. AccountingRule sum read आणि write यांची बेरीज एका quota विरुद्ध मोजते. Transfer allowance प्रत्यक्षात याच वापराचे मोजमाप करते.

AccountingStart देखील लिहा. AccountingMax एकट्याने कधीही लिहू नका. Quota ही संख्या आहे आणि start line हा quota reset होण्याचा period ठरवतो. Period नसलेला quota relay ला hibernating स्थितीत ठेवतो आणि पुन्हा सुरू करण्यासाठी कोणताही trigger राहत नाही.

Hibernation हे अतिशय कठोर साधन आहे. Quota संपल्यावर tor हा event log मध्ये नोंदवतो आणि नवीन work स्वीकारणे थांबवतो:

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

पुढील period सुरू होताच relay नेमक्या त्या क्षणी wake होत नाही. Tor ने मागील quota किती वेगाने वापरला हे track करते आणि नवीन interval मधील random point निवडते. त्यामुळे हजारो relays एकाच second ला network वर परत येत नाहीत. प्रत्येक month च्या शेवटच्या week मध्ये अदृश्य होणारा relay directory authorities ज्या stability चे मोजमाप करतात ती stability सतत गमावतो. RelayBandwidthRate असे आकारमान ठरवा की cap कधीही गाठला जाणार नाही. Invoice चे संरक्षण करणारा backstop म्हणून AccountingMax कायम ठेवा.

रीले सुरू करा आणि ते पोहोचण्यायोग्य आहे याची खात्री करा

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

काही मिनिटांत log मध्ये ही ओळ दिसली पाहिजे:

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

याचा अर्थ असा की इतर relays तुमच्या ORPort शी जोडले गेले आणि त्यामधून circuit तयार केले. ही ओळ दिसेपर्यंत तुमचा relay directory मध्ये नसतो आणि कोणतीही वाहतूक हाताळत नाही. अपयशाचा संदेश असा दिसतो:

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.

हे तपासणे क्रमाने करा. ufw मध्ये ORPort खुला आहे का? Provider च्या स्वतंत्र network firewall मध्येही तो खुला आहे का? त्या संदेशातील address हा इंटरनेटवरून प्रत्यक्ष तुमच्यापर्यंत route होणारा address आहे का, की NAT setup मधील private address आहे? वेगळ्या मशीनवरून nc -vz 203.0.113.10 9001 वापरून port तपासा. Tor स्वतःची self test आपोआप पुन्हा करतो. त्यामुळे firewall दुरुस्त केल्यावर ते तुमच्या हस्तक्षेपाशिवाय लक्षात येते आणि restart केल्यास तपासणी त्वरित होते.

तुमच्या relay ची कायमस्वरूपी ओळख त्याचा fingerprint आहे:

sudo cat /var/lib/tor/fingerprint

descriptor प्रकाशित झाल्यानंतर साधारण तीन तासांनी relay Relay Search वर दिसतो. nickname शोधा किंवा fingerprint paste करा. त्या पृष्ठावर network ला तुमच्या relay विषयी दिसणारी माहिती असते: त्याच्याकडे कोणते flags आहेत, authorities त्याला किती weight देतात आणि तो कोणती version publish करीत आहे.

नवीन Tor relay वर जवळजवळ कोणताही traffic का येत नाही?

कारण नेटवर्कने त्याचे अद्याप मापन केलेले नसते आणि हे मापन पूर्ण होण्यासाठी काही आठवडे लागतात. Tor Project या वाढीचे चार टप्पे सांगते. ते न वाचलेला operator relay मध्ये बिघाड आहे असा निष्कर्ष काढतो आणि configuration मध्ये बदल करू लागतो.

पहिल्या तीन दिवसांत relay चे मापन झालेले नसते. तो स्वतःच्या self test चा निकाल report करतो. तरीही directory authorities प्रकाशित weight 20 KB पर्यंत मर्यादित ठेवतात. त्यामुळे clients तो जवळजवळ कधीच निवडत नाहीत. साधारण तिसऱ्या दिवसापासून आठव्या दिवसापर्यंत bandwidth authorities त्याचे प्रत्यक्ष मापन करतात आणि weight वाढत जाते. मात्र तो फक्त middle hop म्हणून वापरला जातो. कोणताही client अगदी नवीन relay ला first hop करण्यास तयार नसतो.

साधारण आठव्या दिवशी relay Guard flag साठी पात्र ठरतो. हे flag मिळाल्यानंतर traffic कमी होतो आणि याचे सर्वांना आश्चर्य वाटते. Clients middle hop निवडताना guards वगळतात, कारण guard आधीच व्यस्त आहे असे ते गृहीत धरतात. त्यामुळे relay ला guard traffic मिळण्यापूर्वीच middle traffic कमी होते. Clients त्यांचे guard sets बदलत गेल्यावरच हा traffic पुन्हा वाढतो. यासाठी काही आठवडे लागतात. साधारण 68 व्या दिवसापर्यंत relay स्थिर स्थितीत पोहोचतो. या स्थितीत relay काढून टाकणारे clients आणि तो जोडणारे clients यांचे प्रमाण संतुलित होते.

म्हणून वास्तववादी अपेक्षा अशी आहे: तीन दिवस काहीही नाही, एका आठवड्यानंतर काही traffic आणि दोन महिन्यांनंतर प्रत्यक्ष load. एकावेळी एकच setting बदला. त्याचा परिणाम पाहण्यासाठी मग एक आठवडा थांबा. 9001 पोर्टसाठी TCP check असलेले self-hosted Uptime Kuma status page ही अस्वस्थतेचा उपयोग करण्याची अधिक चांगली पद्धत आहे. त्यामुळे तुम्ही प्रत्यक्ष नियंत्रित करू शकत असलेल्या प्रश्नाचे उत्तर मिळते: पोर्ट अजूनही प्रतिसाद देत आहे का.

nyx सह relay निरीक्षण करा

nyx हे सुरू असलेल्या relay साठी terminal monitor आहे. ते tor च्या control port शी संपर्क साधते. त्यामुळे torrc मध्ये ते आधी enable करा:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort फक्त 127.0.0.1 वर listen करते. Cookie authentication मुळे commands जारी करण्यापूर्वी प्रोग्रामने secret file वाचणे आवश्यक असते. Debian आणि Ubuntu वर शेवटच्या दोन ओळी package default चाच असतात: tor package चे स्वतःचे /usr/share/tor/tor-service-defaults-torrc CookieAuthentication 1, CookieAuthFileGroupReadable 1 आणि CookieAuthFile /run/tor/control.authcookie सेट करते. त्यामुळे tor cookie /run/tor/control.authcookie मध्ये debian-tor user म्हणून लिहिते. सुरुवातीपासूनच ती debian-tor group ला वाचता येते. torrc मध्ये या दोन ओळी लिहिल्याने configuration नंतर वाचणाऱ्या व्यक्तीला ही माहिती दिसते. तुमच्या स्वतःच्या account ला sudo शिवाय nyx चालवता येण्याचे कारण म्हणजे त्या group चे membership.

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

Log out करून पुन्हा log in करा. त्यानंतर nyx चालवा. नवीन group login वेळी लागू होणे आवश्यक आहे. त्यामुळे configuration योग्य असतानाही त्याच shell session मध्ये nyx चालवल्यास cookie file वर permission error येतो. nyx live bandwidth, uptime, log stream आणि connection list दाखवते. सुरुवातीच्या काही आठवड्यांत पाहायची बाब म्हणजे bandwidth graph तुमच्या RelayBandwidthRate पेक्षा खाली राहतो का.

एकापेक्षा जास्त relay चालवणे: MyFamily आणि family keys

एकच relay असल्यास हा विभाग वगळा. एकाच operator कडून चालवले जाणारे दोन किंवा अधिक relay यांनी एकमेकांची घोषणा करणे आवश्यक आहे. त्यामुळे clients तुमच्या machines मधून प्रवेश करून त्यांच्यामधूनच बाहेर जाणारा circuit तयार करणार नाहीत. असा circuit तयार झाल्यास एका operator ला त्या circuit चे दोन्ही टोक दिसू शकतात.

दीर्घकाळ वापरली जाणारी पद्धत म्हणजे प्रत्येक relay च्या torrc मध्ये MyFamily ठेवणे आणि इतर सर्व relay चे fingerprints नमूद करणे:

MyFamily AAAAAAAAAA,BBBBBBBB

प्रत्येक relay मध्ये इतर प्रत्येक relay ची नोंद असते. त्यामुळे चौथा relay जोडताना चार files संपादित कराव्या लागतात. Tor 0.4.9 मध्ये family key जोडली आहे. ती यादीची जागा घेत नाही, तर तिच्यासोबत कार्य करते. tor manual मध्ये family जाहीर करण्यासाठी ही key भविष्यातील प्राधान्याची पद्धत असल्याचे म्हटले आहे. मात्र सध्या relay families ने ही key आणि MyFamily दोन्ही configure करावेत, असेही त्यात नमूद आहे. तुमचे सर्व relay 0.4.9.2-alpha किंवा त्यानंतरचे version चालवत असतील, तर एक key generate करून ती सर्व relay वर share करा:

tor --keygen-family myfamily

यामुळे myfamily.secret_family_key लिहिले जाते आणि FamilyId line print होते. ही key file प्रत्येक relay वर DataDirectory च्या keys subdirectory मध्ये copy करा. Debian आणि Ubuntu वर हा path /var/lib/tor/keys असतो. .secret_family_key suffix कायम ठेवा. Print झालेली FamilyId line प्रत्येक torrc मध्ये जोडा आणि sudo systemctl reload tor@default ने reload करा. MyFamily यादी तशीच ठेवा. family keys समजत नसलेले clients अजूनही फक्त जुनी यादी वाचतात. म्हणून manual मध्ये दोन्ही configure करण्यास सांगितले आहे.

चालू झाल्यानंतर काय बिघडू शकते

आवृत्ती कालबाह्य होते. Unattended upgrades पॅकेज बदलतात; परंतु प्रक्रिया सुरू केल्यानंतर ती पुन्हा सुरू होईपर्यंत चालू प्रक्रिया तिच्याबरोबर सुरू झालेली binary वापरत राहते. बॉक्सवरील tor --version आणि relay च्या Relay Search पृष्ठावर दाखवलेली आवृत्ती यांची तुलना करा. त्या वेगळ्या असल्यास network ला अजूनही जुनी आवृत्ती दिसत आहे. त्यामुळे सेवा पुन्हा सुरू करा.

घड्याळाचा वेळ पुढे-मागे होतो. Consensus documents आणि certificates हे सर्व वेळेवर आधारित असतात. त्यामुळे घड्याळाची वेळ मोठ्या प्रमाणात चुकीची असलेले machine consensus नाकारते आणि publishing थांबवते. timedatectl ने system clock synchronized असल्याचे दाखवले पाहिजे. तसे नसेल तर systemd-timesyncd enable करा किंवा chrony install करा.

IP address बदलतो. Descriptor मध्ये address असतो. बदललेल्या address पर्यंत clients पोहोचू शकत नाहीत. Provider migration किंवा address change झाल्यानंतर tor पुन्हा सुरू करा आणि self-test line पुन्हा दिसते का ते monitor करा.

Relay ची गती योजनेने परवानगी दिलेल्या मर्यादेपेक्षा कमी असते. आधुनिक processors वर Tor चे relay crypto कार्यक्षम आहे. Tor Project च्या मते AES-NI support असलेला CPU प्रत्येक दिशेने सुमारे 400 ते 450 Mbit/s हाताळू शकतो. त्या मर्यादेपर्यंत पोहोचण्यापूर्वीच port speed आणि transfer allowance हे मुख्य मर्यादक ठरतात. म्हणूनच वरील accounting section hardware पेक्षा अधिक महत्त्वाचा आहे.

FAQ

Tor relay साठी किती bandwidth वापरली जाते?

तुम्ही जितकी परवानगी देता तितकीच, त्यापेक्षा जास्त नाही. RelayBandwidthRate प्रत्येक दिशेतील relayed traffic स्वतंत्रपणे मर्यादित करते. त्यामुळे 1 Mbit/s वर सेट केलेला relay एकाच वेळी 1 Mbit/s incoming आणि 1 Mbit/s outgoing traffic हाताळू शकतो. दोन्ही दिशा धरल्यास हे दररोज सुमारे 21.6 GB किंवा 30 दिवसांच्या महिन्यात 648 GB होते. या दराखाली hard monthly quota म्हणून AccountingMax सोबत AccountingRule sum जोडा.

Tor relay चालवल्यामुळे मला abuse complaints मिळतील का?

Guard किंवा middle relay traffic फक्त इतर Tor relays कडे पाठवतो. तो वापरकर्त्याच्या वतीने कधीही वेबसाइटशी थेट कनेक्ट होत नाही. त्यामुळे कोणीतरी Tor द्वारे केलेल्या कृतींबाबतच्या तक्रारी exit operator कडे जातात, तुमच्याकडे नाही. relay म्हणून IP address सार्वजनिकपणे सूचीबद्ध असल्यामुळे scanning आणि अधूनमधून IP reputation listing मात्र दिसू शकते. Abuse mail आणि legal notices exit relaysनाच मिळतात. त्यामुळे त्यांच्यासाठी अशा प्रकरणांचे व्यवस्थापन करण्यास आधीच सहमत असलेला provider आवश्यक असतो. कोणताही प्रकार सुरू करण्यापूर्वी provider च्या terms वाचा.

माझ्या नवीन Tor relay ला traffic का मिळत नाही?

नवीन relays चे मोजमाप होईपर्यंत त्यांचा वेग रचनेनुसार मर्यादित केला जातो. पहिल्या तीन दिवसांत directory authorities प्रकाशित weight 20 KB वर मर्यादित ठेवतात. त्यामुळे clients हा relay जवळजवळ कधीही निवडत नाहीत. साधारण तिसऱ्या दिवसापासून bandwidth authorities त्याचे मोजमाप करतात. आठव्या दिवसाच्या आसपास तो Guard flag साठी पात्र ठरतो. त्या वेळी traffic पुन्हा कमी होते, कारण middle hops निवडताना clients guards टाळतात. साधारण 68 दिवसांनी पूर्ण load येतो. log मध्ये "Self-testing indicates your ORPort is reachable from the outside" दिसत असल्याची खात्री करा आणि त्यानंतर relay मध्ये बदल करू नका.

1 TB transfer allowance असलेल्या VPS वर Tor relay चालवता येईल का?

होय. प्रत्येक दिशेला सुमारे 1 Mbit/s ठेवल्यास ते RelayBandwidthRate 125 KBytes आहे. provider दोन्ही दिशांचे मोजमाप करत असल्यास याचा महिन्याला साधारण 648 GB वापर होतो. त्यामुळे updates आणि backups साठी काही headroom उरतो. relay ने plan ची मर्यादा ओलांडण्याऐवजी hibernate करावे यासाठी AccountingMax 400 GBytes सोबत AccountingRule sum आणि AccountingStart month 1 00:00 जोडा. provider फक्त outbound traffic साठी शुल्क आकारत असल्यास हा दर दुप्पट करू शकता.

मी फक्त एक relay चालवत असल्यास MyFamily सेट करणे आवश्यक आहे का?

नाही. एकाच operator च्या मालकीच्या दोन relays मधून client ने circuit तयार करू नये यासाठी family declarations असतात. एकच relay असल्यास त्याचा अर्थ नाही. दुसरा relay जोडताच ते सेट करा: प्रत्येक relay चा fingerprint प्रत्येक relay च्या MyFamily line मध्ये नमूद करा. प्रत्येक relay Tor 0.4.9.2-alpha किंवा त्यानंतरची आवृत्ती चालवत असल्यावर shared family key ची FamilyId line देखील जोडा. सध्या tor manual मध्ये दोन्ही configure करण्यास सांगितले आहे, जेणेकरून जुने clients देखील family ओळखू शकतील.