SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-30

VPS-ல் Tor relay அமைப்பது எப்படி? முழுமையான வழிகாட்டி

Linux VPS-ல் Tor guard அல்லது middle relay-ஐ நிறுவுவது எப்படி என்பதை அறிக. torrc கட்டமைப்பு, bandwidth வரம்பு, nyx கண்காணிப்பு மற்றும் consensus ramp நுணுக்கங்களை விளக்குகிறோம்.

VPS-ல் Tor relay எதைச் செய்கிறது

Tor relay என்பது பொது IP முகவரி கொண்ட ஒரு கணினியில் இயங்கும் Tor daemon ஆகும். இது மற்ற பயனர்களுக்கான குறியாக்கம் செய்யப்பட்ட (encrypted) traffic-ஐ முன்னோக்கி அனுப்புகிறது. Directory authorities இதை வெளியிடுகின்றன, மேலும் Tor clients இதன் வழியாக circuits-ஐ உருவாக்குகின்றன. ஒரு guard அல்லது middle relay எப்போதும் traffic-ஐ மற்றொரு relay-க்கு மட்டுமே அனுப்பும்; எனவே இது ஒரு அந்நியருக்காக எந்தவொரு இணையதளத்துடனும் இணைப்பை ஏற்படுத்தாது. இந்த ஒரு காரணத்தால்தான் இதற்கு எந்தவிதமான abuse மின்னஞ்சல்களும் வருவதில்லை, மேலும் ஒரு சாதாரண VPS-க்கு இதுவே பொருத்தமான பங்களிப்பாகும். ஒரு relay மற்றவர்களின் traffic-ஐ மட்டுமே சுமந்து செல்கிறது, சொந்தமாக எதையும் வெளியிடுவதில்லை. எனவே, நீங்கள் packets-ஐ நகர்த்துவதற்குப் பதிலாக உங்கள் சொந்த தளத்தை இந்த network-ல் வைக்க விரும்பினால், nginx-க்கு பின்னால் v3 onion service-ஐ இயக்குவது அதே tor daemon-க்கு ஒரு மாறுபட்ட பணியாகும். ஒரு relay-ஐ இயக்குவது உங்கள் சொந்த browsing தனியுரிமைக்கு எந்த உதவியும் செய்யாது. இது பெரும்பாலானோர் எதிர்பார்ப்பதை விட குறைவான பலனையே தரும் ஒரு தனிப்பட்ட சிக்கலாகும்: SearXNG-ஐ நீங்களே host செய்வது எதை மறைக்கிறது என்பது, ஒரு சேவையை உங்கள் சொந்த VPS-க்கு மாற்றுவது உங்களுக்கு எந்த அளவு பாதுகாப்பைத் தரும் என்பதற்கான சரியான அளவுகோலாகும்.

இதற்கான வேலை மிகக் குறைவு: ஒரு package, பதினைந்து வரிகள் கொண்ட config, ஒரு firewall விதி, ஒரு restart. இந்த வழிகாட்டியின் மீதமுள்ள பகுதிதான் தவறுகள் நடக்கக்கூடிய இடமாகும். Metered plan-ல் bandwidth கணக்கீடு மற்றும் ஒரு ஆரோக்கியமான புதிய relay ஏன் ஒரு வாரத்திற்குச் செயலிழந்தது போலத் தோன்றுகிறது என்பதற்கான காரணங்கள் இதில் அடங்கும்.

Guard, middle, bridge அல்லது exit: நிறுவும் முன் தேர்வு செய்யவும்

ஒரே daemon நான்கு பணிகளையும் செய்கிறது. உங்கள் configuration மற்றும் directory authorities ஆகியவையே நீங்கள் எந்தப் பணியைச் செய்கிறீர்கள் என்பதைத் தீர்மானிக்கின்றன.

  • Middle relay. இது ஒரு guard-இடமிருந்து traffic-ஐப் பெற்று மற்றொரு relay-க்கு அனுப்புகிறது. இது எந்தவொரு destination site-உடனும் நேரடியாகத் தொடர்பு கொள்ளாது. ஒவ்வொரு புதிய relay-ம் இங்கிருந்தே தொடங்குகிறது.
  • Guard relay. இதுவும் அதே configuration தான், ஆனால் கூடுதல் flag கொண்டது. நீண்ட காலமாக வேகமாகவும் நிலையாகவும் செயல்படும் relay-களுக்கு directory authorities 'Guard' flag-ஐ வழங்குகின்றன. இதை நீங்கள் தேர்வு செய்ய முடியாது. உங்கள் செயல்பாட்டின் மூலம் இதைப் பெற வேண்டும், கீழே உள்ள configuration இதற்கான தகுதியை உருவாக்குகிறது.
  • Bridge. இது பொதுவான directory-ல் பட்டியலிடப்படாத ஒரு relay. Tor தடைசெய்யப்பட்ட இடங்களில் உள்ள பயனர்களுக்கு இது ரகசியமாக வழங்கப்படுகிறது. இந்த நான்கில் இதுவே மிகக் குறைந்த பொறுப்புடையது: குறைந்த bandwidth, பொதுப் பட்டியல் இல்லை, உங்கள் திட்டம் சிறியதாக இருந்தால் இதுவே சரியான தொடக்கம். இதற்கு daemon-உடன் இணைந்து obfs4 proxy-யும் இயங்க வேண்டும் மற்றும் மாறுபட்ட torrc வரிகள் தேவை. ஒரு மலிவான VPS-ல் obfs4 bridge அமைப்பது குறித்த வழிகாட்டி, பயனர்களுக்கு bridge line எவ்வாறு வழங்கப்படுகிறது என்பது உட்பட அனைத்தையும் விளக்குகிறது.
  • Exit relay. இதுவே கடைசி hop; இதுதான் destination site-க்கான connection-ஐத் திறக்கிறது. பயனர் செய்யும் ஒவ்வொரு கோரிக்கையும் உங்கள் IP address மூலமே வெளியேறும். எனவே, abuse reports மற்றும் காவல் துறை விசாரணைகள் அந்த IP-யின் உரிமையாளருக்கே வரும்.

Exit relay என்பது பொதுவான VPS-ல் செய்யக்கூடாத ஒரு பணியாகும். இதற்கென ஒப்புக்கொண்ட, பிரத்யேக IP address மற்றும் பொதுவான abuse contact கொண்ட provider-ல் மட்டுமே exit relay-ஐ இயக்க வேண்டும். பெரும்பாலான standard hosting விதிமுறைகள் இதைத் தடை செய்கின்றன. இதை மீறினால், உங்கள் server முடக்கப்பட்டு IP address இழக்க நேரிடும். நீங்கள் இதையே செய்ய விரும்பினால், exit relay இயக்குவதில் உள்ள நடைமுறைகள் என்ற பகுதி, exit-ஐ அனுமதிக்கும் host-ஐக் கண்டறிவது, exit policy மற்றும் reverse DNS எழுதுவது, வரும் மின்னஞ்சல்களுக்குப் பதிலளிப்பது போன்றவற்றை விளக்குகிறது. Guard அல்லது middle relay-ல் இத்தகைய சிக்கல்கள் இன்றி அதே பயனர் traffic-ஐக் கையாள முடியும்.

கீழே உள்ளவை அனைத்தும் ஒரு guard/middle relay-ஐ உருவாக்குவதற்கானவை. ExitRelay 0 என்பது அதை அவ்வாறே வைத்திருக்கும் வரியாகும்.

நீங்கள் தொடங்குவதற்கு முன் VPS-க்குத் தேவையானவை

Tor Project, relay-களுக்கான கட்டாயத் தேவைகளை வெளியிட்டுள்ளது. ஆகஸ்ட் 2026 நிலவரப்படி, அவை பின்வருமாறு: relay-க்கு ஒரு பொது IPv4 முகவரி, ஒவ்வொரு திசையிலும் குறைந்தது 10 Mbit/s அலைக்கற்றை (16 Mbit/s பரிந்துரைக்கப்படுகிறது), மாதத்திற்கு குறைந்தது 100 GB வெளிச்செல்லும் போக்குவரத்து, மற்றும் 40 Mbit/s-க்குக் கீழ் இருந்தால் 512 MB RAM அல்லது அதற்கு மேல் இருந்தால் 1 GB RAM. நிலையான uptime விதிமுறை எதுவும் இல்லை, ஆனால் ஒரு நாளில் இரண்டு மணி நேரத்திற்கும் குறைவாக இயங்கும் relay, network-க்கு எந்தப் பயனும் தராது.

10 Mbit/s என்பது இணைப்பின் வேகத்தைக் குறிக்கிறது, அமைப்பைக் (setting) குறிப்பதல்ல. அந்த வேகத்தை வழங்கக்கூடிய port உங்களுக்குத் தேவை. அந்த இணைப்பில் எவ்வளவு வேகத்தை relay பயன்படுத்த அனுமதிக்கிறீர்கள் என்பது தனிப்பட்ட முடிவு, இது மாதந்திர தரவுப் பயன்பாட்டு வரம்பைப் பொறுத்தது. configuration-ஐ மாற்றும் முன் உங்கள் திட்டத்தைப் படியுங்கள். நீங்கள் இன்னும் ஒரு server-ஐத் தேர்வு செய்கிறீர்கள் என்றால், ஒரு VPS-ன் மாதந்திர உண்மையான செலவு என்பது தரவு வரம்புகள் எவ்வாறு விற்கப்படுகின்றன என்பதை விளக்குகிறது, மேலும் VPS-ன் உண்மையான network throughput-ஐ அளவிடுதல் என்பது விற்பனைப் பக்கத்தை நம்புவதற்குப் பதிலாக iperf3 மூலம் இணைப்பின் வேகத்தை எவ்வாறு கண்டறிவது என்பதைக் காட்டுகிறது.

முதலில் machine-ஐப் பாதுகாப்பானதாக்குங்கள் (harden). ஒரு relay என்பது பொது முகவரியில் இயங்கும் பொதுச் சேவை, எனவே வெளியிடப்பட்ட சில நிமிடங்களிலேயே அந்த முகவரி ஸ்கேன் செய்யப்படும். SSH-ஐ keys மற்றும் பாதுகாப்பான sshd config மூலம் கட்டுப்படுத்துதல் என்பதற்கு பத்து நிமிடங்கள் மட்டுமே ஆகும், இதை relay நேரலையில் வருவதற்கு முன்பே செய்ய வேண்டும், பிறகு அல்ல.

Tor Project repository-லிருந்து Tor-ஐ நிறுவுதல்

Distribution package-க்கு பதிலாக Tor Project-ன் சொந்த apt repository-ஐப் பயன்படுத்தவும். Relay code-ன் மேம்பாடுகள் stable release-ஐ விட வேகமாக நடக்கும்; எனவே, பிழைத்திருத்தங்கள் இந்த repository-க்கு முதலில் வந்துவிடும், distribution package-ல் அவை தாமதமாகவே கிடைக்கும்.

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

முதலில் signing key-ஐச் சேர்க்கவும், பிறகு repository-ஐச் சேர்க்கவும். Codename அந்தந்த machine-லிருந்து தானாகவே கண்டறியப்படுவதால், Ubuntu 24.04 (noble) மற்றும் Debian 13 (trixie) ஆகிய இரண்டிலும் ஒரே block வேலை செய்யும்.

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 நீங்கள் இப்போது நிறுவிய version-ஐக் காட்டும். ஒருவேளை apt update கட்டளை NO_PUBKEY பிழையைக் காட்டினால், Signed-By: வரியில் குறிப்பிடப்பட்டுள்ள பாதையில் dearmored key இல்லை என்று அர்த்தம்; இதனால் release file-ஐச் சரிபார்க்க apt-க்கு key இருக்காது. deb.torproject.org-keyring package பிற்காலத்திற்கு முக்கியமானது: இது signing key-ஐ ஒரு சாதாரண package-ஆக வழங்குகிறது, எனவே key மாற்றப்படும்போது (rotated) 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-ல் அதே கோப்பு Origins-Pattern-ஐப் பயன்படுத்துகிறது, அங்கு சேர்க்க வேண்டிய வரி "origin=TorProject"; ஆகும். sudo unattended-upgrade --debug --dry-run கட்டளை மூலம் முடிவைச் சரிபார்க்கவும்; இது எந்தெந்த origin-களில் செயல்படும் என்பதைக் காட்டும், வேறு எதையும் மாற்றாது.

முக்கியமான torrc கோப்பு

இந்த package நீண்ட, அதிக விளக்கங்கள் கொண்ட /etc/tor/torrc கோப்பை நிறுவுகிறது. ஒரு relay-க்கு ஒரு சில வரிகள் மட்டுமே முக்கியமானவை. அவற்றை கோப்பின் இறுதியில் சேர்க்கவும்.

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

Nickname என்பது 1 முதல் 19 எழுத்துகள் வரை இருக்கலாம், இதில் எழுத்துகள் மற்றும் எண்கள் மட்டுமே இருக்க வேண்டும். இது network-ல் தனித்துவமானது அல்ல, இது உங்கள் அடையாளமும் அல்ல; fingerprint தான் உங்கள் அடையாளம். தேடல் பெட்டியில் உங்கள் relay-ஐக் கண்டறிய இது உதவும், எனவே தொலைபேசியில் எளிதாகச் சொல்லக்கூடிய பெயரைத் தேர்வு செய்யவும்.

ContactInfo என்பது relay descriptor-க்குள் வெளியிடப்படுகிறது. இது எவரும் பதிவிறக்கம் செய்யக்கூடிய பொதுவான ஆவணம் என்பதால், இந்த முகவரி சேகரிக்கப்படும் (scraped). அடுத்த இரண்டு ஆண்டுகளுக்கு நீங்கள் தொடர்ந்து பயன்படுத்தக்கூடிய முகவரியைப் பயன்படுத்தவும், தேவைப்பட்டால் அதை மறைத்து (obfuscate) வைக்கவும். உங்கள் relay-ல் ஏதேனும் சிக்கல் இருந்தால், Tor Project உங்களை எச்சரிக்க இதுவே ஒரே வழியாகும்.

ORPort 9001 என்பது பிற relay-கள் மற்றும் client-கள் இணையும் port ஆகும். 9001 என்பது வழக்கமான port. Port 443 மற்றொரு பொதுவான தேர்வாகும், ஏனெனில் சில கட்டுப்பாடுகள் கொண்ட network-கள் வெளிச்செல்லும் 443-ஐ மட்டுமே அனுமதிக்கும், எனவே அங்கு இயங்கும் relay அதிக client-களுக்குக் கிடைக்கும். அந்த machine-ல் வேறு எந்த சேவைக்கும் 443 தேவைப்படாவிட்டால் மட்டுமே இதைப் பயன்படுத்தவும்.

SocksPort 0 என்பது local SOCKS proxy-ஐ அணைக்கிறது, relay-க்கு இது தேவையில்லை, மேலும் இது machine-லிருந்து ஒரு listening socket-ஐ நீக்குகிறது. ExitRelay 0 என்பது இந்த நோக்கத்தை கோப்பில் எழுதுகிறது: இந்த relay ஒரு பயனர் சார்பாக எந்த இலக்கிற்கும் இணையாது, மேலும் எதிர்காலத்தில் இந்த config-ஐப் படிப்பவர்கள் default அமைப்பிலிருந்து இதைப் புரிந்துகொள்ள வேண்டியதில்லை.

VPS-ல் IPv6 முகவரி இருந்தால், இரண்டாவது ORPort வரியைச் சேர்க்கவும். IPv4-க்குச் செய்வது போல Tor-ஆல் "any" IPv6 முகவரியுடன் இணைய முடியாது, எனவே முகவரியைச் சதுர அடைப்புக்குறிக்குள் (square brackets) எழுதவும்.

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

1 GB VPS-ல், MaxMemInQueues 512 MB-ஐச் சேர்க்கவும். machine-ல் உள்ள நினைவகத்தை வைத்து Tor அதன் queue limit-ஐத் தீர்மானிக்கிறது, சிறிய shared box-ல் இது நீங்கள் விரும்புவதை விட அதிகமாக இருக்கலாம். வரம்பை நீங்களே அமைப்பதன் மூலம், அழுத்தம் ஏற்படும்போது Tor வரிசையில் உள்ள cells-ஐ நீக்கிவிடும், இதனால் kernel அந்த process-ஐக் கொல்லாமல் relay தொடர்ந்து இயங்கும்.

Firewall-ல் ORPort-ஐத் திறக்கவும்

Inbound போக்குவரத்தைப் பொறுத்தவரை, இணையத்தில் எங்கிருந்தும் ORPort-ஐ அணுகக்கூடிய வகையில் இருக்க வேண்டும். Outbound போக்குவரத்திற்கு, relay-ன் கட்டுப்பாடுகளை நீக்கிவிடவும்: இது ஆயிரக்கணக்கான பிற relay-களுடன் பலவிதமான ports-ல் இணைப்புகளை ஏற்படுத்தும். எனவே, outbound allowlist-ஐ அமைப்பது relay-ன் செயல்பாட்டைப் பாதிக்கும்.

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

அதன்பின், service provider-ன் சொந்த network firewall-ஐச் சரிபார்க்கவும். பல control panel-கள் virtual machine-க்கு முன்னால் ஒரு packet filter-ஐ இயக்குகின்றன. நீங்கள் ufw மூலம் சேர்க்கும் விதிகள் அங்கு செயல்படாது; இதனால் server-க்குள் port திறந்திருப்பதாகத் தெரிந்தாலும், வெளியிலிருந்து அது மூடப்பட்டதாகவே இருக்கும். உங்களுக்கு ufw புதியது என்றால், ஒவ்வொரு VPS-லும் இருக்க வேண்டிய ufw விதிகள் என்ற பகுதி, default policy மற்றும் விதிகள் சரிபார்க்கப்படும் வரிசைமுறை குறித்து விளக்குகிறது.

உங்கள் திட்டத்திற்கு ஏற்ப அலைவரிசையை (bandwidth) அமைத்தல்

RelayBandwidthRate என்பது ஒரு தனித்துவமான டோக்கன் பக்கெட் (token bucket) என்று கையேடு விவரிக்கிறது. இது "இந்த நோடில் (node) ரிலே செய்யப்படும் டிராஃபிக்கின் சராசரி உள்வரும் அலைவரிசையை குறிப்பிட்ட பைட்டுகள்/வினாடி என்ற அளவில் கட்டுப்படுத்துகிறது, அதேபோல் சராசரி வெளிச்செல்லும் அலைவரிசையையும் அதே அளவில் கட்டுப்படுத்துகிறது". இதை இருமுறை வாசிக்கவும். இந்த வரம்பு ஒவ்வொரு திசைக்கும் தனித்தனியாகப் பொருந்தும். 1 Mbit/s என அமைக்கப்பட்ட ஒரு ரிலே, ஒரே நேரத்தில் 1 Mbit/s உள்வாங்கவும் 1 Mbit/s அனுப்பவும் முடியும். இரு திசைகளையும் கணக்கிடும் சேவை வழங்குநர், இரண்டின் கூட்டுத்தொகையை கட்டணமாக வசூலிப்பார்.

ChartMonthly traffic at a sustained relay rate, both directions, 30 days
The data behind this chart
[
  {
    "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 வரிசைகள் கணக்கீட்டு முறையைச் சார்ந்தவை, அளவீடு அல்ல: ஒரு ரிலே 30 நாட்களும் முழுமையாக இரு திசைகளிலும் இயங்கினால் ஏற்படும் செலவை அவை காட்டுகின்றன. ஒரு உண்மையான ரிலே, குறிப்பாக முதல் சில வாரங்களில், அதன் உச்ச வரம்பிற்கு கீழேயே செயல்படும். இந்த அட்டவணையைப் பயன்படுத்தி, உங்கள் திட்டத்திற்கு பொருந்தாத அமைப்புகளைத் தவிர்க்கவும்; மாறாக, ஜிகாபைட் அளவில் துல்லியமான கட்டணத்தைக் கணிக்க இதைப் பயன்படுத்த வேண்டாம்.

ஒவ்வொரு திசையிலும் 1 Mbit/s வேகத்தில் ஒரு ரிலே ஒரு நாளைக்கு சுமார் 21.6 GB டிராஃபிக்கை நகர்த்துகிறது. எனவே, 30 நாட்கள் கொண்ட ஒரு மாதத்திற்கு சுமார் 648 GB டிராஃபிக் தேவைப்படும். இது 1 TB ஒதுக்கீட்டிற்குள் அடங்குவதுடன், அப்டேட்கள் மற்றும் பேக்கப்களுக்கும் போதுமான இடம் இருக்கும். 2 Mbit/s அளவிற்கு உயர்த்தினால், மாதத்திற்கு 1,296 GB தேவைப்படும், இது 1 TB திட்டத்தை விட அதிகம். கடைசி வரிசையான 20 Mbit/s-க்கு மாதத்திற்கு 12,960 GB தேவைப்படும், இதற்கு அன்மீட்டர்டு (unmetered) போர்ட் அவசியம். உங்கள் சேவை வழங்குநர் வெளிச்செல்லும் டிராஃபிக்கிற்கு மட்டும் கட்டணம் வசூலித்தால், அனைத்து எண்களையும் பாதியாகக் குறைக்கவும். விகிதத்தை அமைக்கும் முன் உங்கள் சேவை வழங்குநரின் கட்டண முறையை உறுதிப்படுத்தவும், ஏனெனில் இந்த இரண்டு முறைகளுக்கும் இடையே இரண்டு மடங்கு வித்தியாசம் உள்ளது.

இப்போது உள்ளமைவு (config). முதலில் ரேட் லிமிட் (rate limit), இரண்டாவதாக கோட்டா (quota).

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

RelayBandwidthBurst என்பது டோக்கன் பக்கெட்டின் அளவு. இது சராசரி வேகம் மாறாமல் இருக்கும்போது, குறுகிய காலத்திற்கு வேகத்தை அதிகரிக்க அனுமதிக்கிறது. சராசரி வேகத்தை விட இரண்டு மடங்கு என்பது ஒரு சரியான மதிப்பாகும்.

AccountingRule என்பது பெரும்பாலான ஆபரேட்டர்கள் கவனிக்கத் தவறும் வரியாகும். இயல்புநிலை (default) max ஆகும், இது இரண்டு திசைகளில் எது பெரியதோ அதை ஒதுக்கீட்டுடன் ஒப்பிடுகிறது. இயல்புநிலையில், AccountingMax 400 GBytes என்பது 400 GB உள்வரவையும் 400 GB வெளிச்செல்லலையும் அனுமதிக்கிறது, இது இரண்டையும் கணக்கிடும் மீட்டரில் 800 GB ஆகும். AccountingRule sum என்பது உள்வரவு மற்றும் வெளிச்செல்லல் இரண்டையும் கூட்டி ஒதுக்கீட்டுடன் ஒப்பிடுகிறது, இதுவே உண்மையான டேட்டா பரிமாற்ற அளவீடு ஆகும்.

AccountingStart-ஐயும் எழுதவும், AccountingMax-ஐ மட்டும் தனியாக எழுத வேண்டாம். கோட்டா என்பது எண், ஸ்டார்ட் லைன் என்பது அது ரீசெட் ஆகும் காலம். கால அளவு குறிப்பிடப்படாத கோட்டா, ரிலேவை மீண்டும் செயல்பட முடியாமல் முடக்கிவிடும்.

ஹைபர்னேஷன் (hibernation) என்பது ஒரு கடுமையான நடவடிக்கை. ஒதுக்கீடு தீர்ந்தவுடன், tor இதை லாக் (log) செய்துவிட்டு புதிய பணிகளை ஏற்பதை நிறுத்திவிடும்:

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

அடுத்த காலக்கட்டம் தொடங்கியவுடன் ரிலே உடனடியாகச் செயல்படாது. முந்தைய ஒதுக்கீடு எவ்வளவு வேகமாகத் தீர்ந்தது என்பதை tor கண்காணித்து, புதிய கால இடைவெளியில் ஒரு சீரற்ற புள்ளியைத் தேர்வு செய்யும். இதனால் ஆயிரக்கணக்கான ரிலேக்கள் ஒரே வினாடியில் நெட்வொர்க்கிற்குத் திரும்புவது தவிர்க்கப்படும். ஒவ்வொரு மாதத்தின் கடைசி வாரத்தில் ரிலே செயல்படாமல் இருந்தால், டைரக்டரி அத்தாரிட்டி (directory authorities) அளவிடும் அதன் நிலைத்தன்மை (stability) குறையும். RelayBandwidthRate-ஐ உச்ச வரம்பை எட்டாதவாறு அமைக்கவும், AccountingMax-ஐ கட்டணத்தைப் பாதுகாக்கும் கடைசி அரணாக வைத்திருக்கவும்.

Relay-ஐத் தொடங்கி, அது அணுகக்கூடிய நிலையில் உள்ளதா என்பதை உறுதிப்படுத்தவும்

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.

இந்த வாக்கியம், பிற relay-கள் உங்கள் ORPort-உடன் இணைந்து அதன் வழியாக ஒரு circuit-ஐ உருவாக்கியுள்ளன என்பதைக் குறிக்கிறது. இந்த வரி தோன்றும் வரை, உங்கள் relay directory-ல் இருக்காது மற்றும் எந்த traffic-ஐயும் கையாளாது. தோல்வி ஏற்பட்டால், அது இவ்வாறு காட்டப்படும்:

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.

ஒவ்வொரு படியாகச் சரிபார்க்கவும். ORPort, ufw-ல் திறக்கப்பட்டுள்ளதா? அது உங்கள் service provider-ன் தனிப்பட்ட network firewall-லும் திறக்கப்பட்டுள்ளதா? அந்தச் செய்தியில் உள்ள முகவரி, இணையம் உங்களைச் சென்றடையப் பயன்படுத்தும் உண்மையான முகவரியா அல்லது NAT அமைப்பால் உருவாக்கப்பட்ட private முகவரியா என்பதை உறுதிப்படுத்தவும். வேறொரு கணினியிலிருந்து nc -vz 203.0.113.10 9001 மூலம் அந்த port-ஐச் சோதிக்கவும். Tor தானாகவே இந்த self test-ஐ மீண்டும் செய்யும் என்பதால், firewall-ஐச் சரிசெய்த பிறகு நீங்கள் எதையும் செய்யத் தேவையில்லை; service-ஐ restart செய்தால் மாற்றம் உடனடியாக நடைமுறைக்கு வரும்.

உங்கள் relay-ன் நிரந்தர அடையாளம் அதன் fingerprint ஆகும்:

sudo cat /var/lib/tor/fingerprint

Descriptor வெளியிடப்பட்ட சுமார் மூன்று மணி நேரத்திற்குப் பிறகு, Relay Search-ல் உங்கள் relay தோன்றும். உங்கள் nickname-ஐத் தேடவும் அல்லது fingerprint-ஐ paste செய்யவும். உங்கள் relay-ஐப் பற்றி network என்ன கருதுகிறது என்பதை அந்தப் பக்கம் காட்டும்: அது என்னென்ன flags-ஐக் கொண்டுள்ளது, authorities அதற்கு என்ன weight வழங்கியுள்ளன, மற்றும் அது எந்த version-ஐ வெளியிடுகிறது போன்ற தகவல்களை அதில் காணலாம்.

புதிய Tor relay ஏன் மிகக்குறைந்த traffic-ஐ மட்டுமே கையாள்கிறது?

Tor network இன்னும் அந்த relay-ஐ அளவிடவில்லை என்பதே இதற்குக் காரணம்; இந்த அளவீட்டு முறைக்கு பல வாரங்கள் ஆகும். Tor Project இந்த வேக அதிகரிப்பை நான்கு நிலைகளாக விவரிக்கிறது. இதை வாசிக்காத ஒரு operator, relay பழுதடைந்துவிட்டதாகக் கருதி, அமைப்புகளை மாற்றத் தொடங்குகிறார்.

முதல் மூன்று நாட்களுக்கு relay அளவிடப்படாது. அது தனது சொந்த சுய-சோதனை முடிவுகளை மட்டுமே தெரிவிக்கும். Directory authorities அதன் published weight-ஐ 20 KB-ஆகக் கட்டுப்படுத்துவதால், clients அதைத் தேர்வு செய்வதில்லை. சுமார் மூன்றாவது நாள் முதல் எட்டாவது நாள் வரை, bandwidth authorities அதை முறையாக அளவிடும். அப்போது அதன் weight அதிகரிக்கும், ஆனால் அது middle hop-ஆக மட்டுமே பயன்படுத்தப்படும். எந்தவொரு client-ம் ஒரு புதிய relay-ஐத் தனது முதல் hop-ஆக (Guard) பயன்படுத்த விரும்புவதில்லை.

சுமார் எட்டாவது நாளில், அந்த relay Guard flag-ஐப் பெறத் தகுதியுடையதாகிறது. இந்த flag கிடைத்தவுடன் traffic குறைவது பலரையும் ஆச்சரியப்படுத்தும்: clients ஒரு Guard-ஐத் தேர்ந்தெடுக்கும்போது, அது ஏற்கனவே பிஸியாக இருப்பதாகக் கருதி அதை middle hop-ஆகத் தவிர்த்துவிடும். இதனால், Guard traffic கிடைப்பதற்கு முன்பே, அந்த relay தனது middle traffic-ஐ இழக்கிறது. clients தங்களின் Guard செட்களை மாற்றும்போது மட்டுமே traffic மீண்டும் அதிகரிக்கும்; இதற்குப் பல வாரங்கள் ஆகும். சுமார் 68 நாட்களுக்குப் பிறகு, அது ஒரு நிலையான நிலையை (steady state) அடைகிறது. அப்போது, அந்த relay-ஐ நீக்கும் clients-ன் எண்ணிக்கையும், அதைச் சேர்க்கும் clients-ன் எண்ணிக்கையும் சமமாக இருக்கும்.

எனவே, மூன்று நாட்களுக்கு எந்த traffic-ம் இருக்காது, ஒரு வாரத்திற்குப் பிறகு ஓரளவு traffic இருக்கும், இரண்டு மாதங்களுக்குப் பிறகுதான் முழுமையான சுமை இருக்கும் என்று எதிர்பார்ப்பதே சரியானது. ஒரு அமைப்பை மாற்றினால், அதன் விளைவை அறிய ஒரு வாரம் காத்திருக்கவும். A self-hosted Uptime Kuma status page மூலம் port 9001-ல் TCP check செய்வது உங்கள் பதற்றத்தைக் குறைக்க உதவும்: port இன்னும் பதிலளிக்கிறதா என்ற, நீங்கள் கட்டுப்படுத்தக்கூடிய கேள்விக்கு இது விடையளிக்கும்.

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 இருப்பதால், ஒரு நிரல் கட்டளைகளை அனுப்பும் முன் ஒரு ரகசியக் கோப்பை வாசிக்க வேண்டும். Tor அந்த cookie-ஐ /run/tor/control.authcookie-ல் debian-tor பயனருக்காக, 600 mode-ல் எழுதும்; எனவே மற்ற எவராலும் அதை வாசிக்க முடியாது. CookieAuthFileGroupReadable 1 அதை group-க்குத் திறந்துவிடும்; இதுவே உங்கள் சொந்த கணக்கின் மூலம் sudo இல்லாமல் nyx-ஐ இயக்க அனுமதிக்கிறது.

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

Log out செய்து மீண்டும் log in செய்யவும், பிறகு nyx-ஐ இயக்கவும். புதிய group-ஐ login-ன் போதுதான் கணினி எடுத்துக்கொள்ளும், எனவே அதே shell session-ல் nyx-ஐ இயக்கினால், configuration சரியாக இருந்தாலும் cookie கோப்பில் permission error ஏற்படும். nyx நேரடி bandwidth, uptime, log stream மற்றும் connection பட்டியலைக் காட்டும். முதல் சில வாரங்களில், bandwidth வரைபடம் உங்கள் RelayBandwidthRate-க்குக் கீழே இருப்பதை உறுதி செய்வது முக்கியம்.

ஒன்றுக்கும் மேற்பட்ட relay-களை இயக்குதல்: MyFamily மற்றும் family keys

ஒரே ஒரு relay மட்டும் வைத்திருந்தால், இந்தப் பகுதியைத் தவிர்க்கவும். ஒரே நிர்வாகியால் இயக்கப்படும் இரண்டு அல்லது அதற்கு மேற்பட்ட relay-கள், தங்களுக்குள் ஒருவருக்கொருவர் அறிவித்துக்கொள்ள வேண்டும். இல்லையெனில், பயனர்கள் உருவாக்கும் circuit உங்கள் இயந்திரங்கள் வழியாகவே நுழைந்து வெளியேற வாய்ப்புள்ளது; இது ஒரே நிர்வாகி circuit-ன் இரு முனைகளையும் பார்க்க வழிவகுக்கும்.

நீண்டகாலமாகப் பின்பற்றப்படும் முறை, ஒவ்வொரு relay-ன் torrc கோப்பிலும் MyFamily-ஐப் பயன்படுத்தி, மற்ற அனைத்து relay-களின் fingerprints-ஐயும் பட்டியலிடுவதாகும்:

MyFamily AAAAAAAAAA,BBBBBBBB

ஒவ்வொரு relay-ம் மற்ற அனைத்தையும் பட்டியலிட வேண்டும், எனவே நான்காவது relay-ஐச் சேர்க்கும்போது நான்கு கோப்புகளைத் திருத்த வேண்டியிருக்கும். Tor 0.4.9 பதிப்பில் இதற்குப் பதிலாக family key அறிமுகப்படுத்தப்பட்டது. ஒரு key-ஐ உருவாக்கி, அதைப் பகிர்ந்துகொள்ளவும்:

tor --keygen-family myfamily

இது myfamily.secret_family_key கோப்பை உருவாக்கி, ஒரு FamilyId வரியை வெளியீடாகக் காட்டும். அந்த key கோப்பை ஒவ்வொரு relay-க்கும் நகலெடுத்து, DataDirectory-ன் (Debian மற்றும் Ubuntu-வில் /var/lib/tor/keys) keys துணைக்கோப்பகத்தில் வைக்கவும். கோப்பின் .secret_family_key பின்னொட்டு (suffix) மாறாமல் இருக்க வேண்டும். திரையில் காட்டப்பட்ட FamilyId வரியை ஒவ்வொரு torrc கோப்பிலும் சேர்த்து, sudo systemctl reload tor@default மூலம் reload செய்யவும். தற்போதைக்கு MyFamily பட்டியலையும் நீக்காமல் அப்படியே வைத்திருக்கவும். family certificates-ஐ இன்னும் புரிந்துகொள்ளாத clients, பழைய பட்டியலையே வாசிக்கும். அதை எப்போது நீக்கலாம் என்பதை Tor Project அறிவிக்கும்.

இயங்கிக் கொண்டிருக்கும்போது என்னென்ன பாதிப்புகள் ஏற்படும்

பதிப்பு காலாவதியாதல். Unattended upgrades தொகுப்பைப் புதுப்பிக்கும், ஆனால் ஏதேனும் ஒரு செயல்முறை அதை மறுதொடக்கம் செய்யும் வரை, இயங்கிக் கொண்டிருக்கும் process பழைய binary-யையே பயன்படுத்தும். அந்த machine-ல் உள்ள tor --version-ஐ, relay-ன் Relay Search பக்கத்தில் காட்டப்படும் பதிப்போடு ஒப்பிட்டுப் பார்க்கவும். அவை வெவ்வேறாக இருந்தால், network இன்னும் பழைய பதிப்பையே காண்கிறது என்று பொருள்; எனவே service-ஐ மறுதொடக்கம் செய்யவும்.

கடிகார நேர மாறுபாடு (Clock drift). Consensus ஆவணங்கள் மற்றும் certificates அனைத்தும் நேரத்தை அடிப்படையாகக் கொண்டவை. எனவே, system clock அதிக அளவில் மாறுபட்டு இருந்தால், அந்த machine consensus-ஐ நிராகரித்து, தகவல்களை வெளியிடுவதை நிறுத்திவிடும். timedatectl system clock ஒத்திசைக்கப்பட்டிருப்பதை உறுதிப்படுத்த வேண்டும். அவ்வாறு இல்லையெனில், systemd-timesyncd-ஐ enable செய்யவும் அல்லது chrony-ஐ நிறுவவும்.

IP முகவரி மாறுதல். Descriptor முகவரியைக் கொண்டிருக்கும்; முகவரி மாறியிருந்தால், clients-ஆல் அந்த relay-ஐ அடைய முடியாது. ஏதேனும் provider migration அல்லது முகவரி மாற்றத்திற்குப் பிறகு, tor-ஐ மறுதொடக்கம் செய்து, self-test வரியை மீண்டும் கவனிக்கவும்.

திட்டமிடப்பட்டதை விட relay-ன் வேகம் குறைவாக இருத்தல். நவீன processors-ல் Tor-ன் relay crypto திறமையாகச் செயல்படும். Tor Project-ன் கணக்கீட்டின்படி, AES-NI ஆதரவு கொண்ட CPU ஒவ்வொரு திசையிலும் சுமார் 400 முதல் 450 Mbit/s வேகத்தை வழங்கும். அந்த உச்ச வரம்பை எட்டுவதற்கு முன்பே, port வேகம் மற்றும் transfer allowance ஆகியவற்றால் நீங்கள் கட்டுப்படுத்தப்படுவீர்கள். இதனால்தான் வன்பொருளை விட, மேலே குறிப்பிடப்பட்டுள்ள accounting பகுதி முக்கியமானது.

FAQ

Tor relay எவ்வளவு bandwidth-ஐப் பயன்படுத்தும்?

நீங்கள் எவ்வளவு அனுமதிக்கிறீர்களோ, அவ்வளவு மட்டுமே பயன்படுத்தும். RelayBandwidthRate ஒவ்வொரு திசையிலும் relay செய்யப்படும் traffic-ஐத் தனித்தனியாகக் கட்டுப்படுத்துகிறது. எனவே, 1 Mbit/s என அமைக்கப்பட்ட relay, ஒரே நேரத்தில் 1 Mbit/s உள்ளே மற்றும் 1 Mbit/s வெளியே எனச் செயல்படும். இது ஒரு நாளைக்கு சுமார் 21.6 GB அல்லது 30 நாட்கள் கொண்ட மாதத்தில் 648 GB traffic-க்குச் சமம் (இரு திசைகளையும் சேர்த்து). அந்த வேகத்திற்குள் ஒரு குறிப்பிட்ட மாத அளவை நிர்ணயிக்க, AccountingMax உடன் AccountingRule sum-ஐச் சேர்க்கவும்.

Tor relay-ஐ இயக்குவதால் எனக்கு abuse புகார்கள் வருமா?

ஒரு guard அல்லது middle relay, traffic-ஐ மற்ற Tor relay-களுக்கு மட்டுமே கடத்துகிறது; பயனருக்காக எந்த இணையதளத்துடனும் நேரடியாக இணைப்பை ஏற்படுத்தாது. எனவே, Tor வழியாக யாராவது செய்யும் செயல்களுக்கான புகார்கள் exit operator-க்குச் செல்லுமே தவிர, உங்களுக்கு வராது. உங்கள் IP முகவரி பொதுப் பட்டியலில் relay-ஆக இருப்பதால், சில நேரங்களில் scanning அல்லது IP reputation பட்டியல்களில் உங்கள் முகவரி இடம்பெறலாம். Exit relay-களுக்குத்தான் abuse மின்னஞ்சல்களும் சட்ட அறிவிப்புகளும் வரும்; எனவே, அத்தகைய relay-களைத் தொடங்கும் முன், அதை எதிர்கொள்ள ஒப்புக்கொண்ட ஒரு provider-ஐத் தேர்ந்தெடுக்க வேண்டும். எவ்வகையான relay-ஐத் தொடங்குவதற்கு முன்பும் உங்கள் provider-ன் விதிமுறைகளை வாசிக்கவும்.

எனது புதிய Tor relay-க்கு ஏன் traffic வரவில்லை?

புதிய relay-கள் அளவிடப்படும் வரை வடிவமைப்பின்படி கட்டுப்படுத்தப்படுவதால் (throttled) traffic குறைவாக இருக்கும். முதல் மூன்று நாட்களுக்கு, directory authorities அதன் published weight-ஐ 20 KB-ஆகக் கட்டுப்படுத்தும், எனவே clients அந்த relay-ஐத் தேர்ந்தெடுக்காது. மூன்றாவது நாளிலிருந்து bandwidth authorities அதை அளவிடத் தொடங்கும். எட்டாவது நாளில் அது Guard flag-க்குத் தகுதியுடையதாக மாறும். அந்த நேரத்தில், clients middle hops-ஐத் தேர்ந்தெடுக்கும்போது guard-களைத் தவிர்ப்பதால் traffic மீண்டும் குறையலாம். முழுமையான சுமை சுமார் 68-வது நாளில் கிடைக்கும். உங்கள் log-ல் "Self-testing indicates your ORPort is reachable from the outside" என்று உள்ளதா என்பதை உறுதிசெய்துவிட்டு, அதைத் தொடர்ந்து இயங்க விடவும்.

1 TB transfer allowance கொண்ட VPS-ல் Tor relay-ஐ இயக்க முடியுமா?

ஆம், ஒவ்வொரு திசையிலும் சுமார் 1 Mbit/s வேகத்தில் இயக்கலாம், இது RelayBandwidthRate 125 KBytes ஆகும். உங்கள் provider இரு திசைகளையும் கணக்கிட்டால், இது மாதத்திற்கு சுமார் 648 GB ஆகும்; இது updates மற்றும் backups-க்குத் தேவையான இடத்தையும் விட்டுவைக்கும். AccountingMax 400 GBytes உடன் AccountingRule sum மற்றும் AccountingStart month 1 00:00-ஐச் சேர்க்கவும், அப்போதுதான் உங்கள் திட்டத்தை மீறாமல் relay தானாகவே hibernation நிலைக்குச் செல்லும். உங்கள் provider outbound traffic-ஐ மட்டும் கணக்கிட்டால், நீங்கள் இந்த வேகத்தை இருமடங்காக்கலாம்.

நான் ஒரே ஒரு relay-ஐ மட்டும் இயக்கினால் MyFamily-ஐ அமைக்க வேண்டுமா?

தேவையில்லை. ஒரே operator-க்குச் சொந்தமான இரண்டு relay-கள் வழியாக clients circuit-ஐ உருவாக்குவதைத் தவிர்க்கவே family declarations பயன்படுகின்றன; ஒரே ஒரு relay-க்கு இது தேவையற்றது. இரண்டாவது relay-ஐச் சேர்த்தவுடன் இதை அமைக்கவும்: ஒவ்வொரு relay-ன் fingerprint-ஐயும் மற்ற relay-களின் MyFamily வரியில் குறிப்பிடவும். அல்லது Tor 0.4.9-ல் அறிமுகப்படுத்தப்பட்ட family key-ஐப் பயன்படுத்தவும்; இது நீண்டு கொண்டே செல்லும் பட்டியலுக்குப் பதிலாக ஒரே ஒரு FamilyId-ஐப் பயன்படுத்த அனுமதிக்கிறது.