VPS-ல் obfs4 Tor bridge அமைப்பது எப்படி?

Tor bridge என்றால் என்ன, அது ஏன் தேவைப்படுகிறது

Tor bridge என்பது Tor network-க்குள் நுழையும் ஒரு நுழைவாயில் ஆகும். இதன் முகவரி பொதுவான relay பட்டியலில் வெளியிடப்படுவதில்லை. Consensus என்று அழைக்கப்படும் அந்தப் பட்டியல், எவரும் தரவிறக்கம் செய்யக்கூடிய ஒரு கையொப்பமிடப்பட்ட ஆவணமாகும்; தணிக்கையாளர்களும் (censors) இதைத் தரவிறக்கம் செய்கிறார்கள். அந்தப் பட்டியலைப் பயன்படுத்தி Tor-ஐத் தடுப்பது எளிது: consensus-ஐப் பெற்று, அதில் உள்ள அனைத்து முகவரிகளையும் border-ல் தடுத்துவிடலாம். வெளியிடப்பட்ட பட்டியல் ஒரு பலவீனமான புள்ளியாக இருப்பதால், bridge-கள் உருவாக்கப்பட்டுள்ளன. Bridge முகவரிகள் ஒரு நேரத்தில் சில மட்டுமே வழங்கப்படுகின்றன, எனவே ஒரு கோரிக்கையின் மூலம் முழுப் பட்டியலையும் பெற்றுவிட முடியாது.

பட்டியலிடப்படாத முகவரி என்பது தீர்வின் ஒரு பகுதி மட்டுமே. Deep packet inspection (DPI), போக்குவரத்தின் முகவரியைப் பார்க்காமல் அதன் உள்ளடக்கத்தை வைத்து வகைப்படுத்துகிறது. இது TLS (transport layer security) handshake-ன் வடிவத்தை வைத்து Tor இணைப்பைக் கண்டறியும். பட்டியல் இல்லாத தணிக்கையாளரும் கூட, "இது Tor போலத் தெரிகிறது" என்று கண்டறிந்து இணைப்பைத் துண்டிக்க முடியும். Pluggable transport இந்த சமிக்ஞையை நீக்குகிறது. இது client பக்கத்தில் Tor stream-ஐ வேறொரு வடிவத்தில் மறைக்கிறது, உங்கள் bridge அதை மீண்டும் பழைய நிலைக்கு மாற்றுகிறது.

obfs4 என்பது பெரும்பாலான bridge-கள் பயன்படுத்தும் transport ஆகும். இது stream-ஐ எந்த header-ம் மற்றும் நிலையான handshake-ம் இல்லாத bytes-ஆக மாற்றுகிறது, எனவே DPI-ஆல் எந்தவொரு pattern-ஐயும் கண்டறிய முடியாது. இது client-ஐயும் அங்கீகரிக்கிறது (authenticate). ஒரு bridge வரியின் உள்ளே இருக்கும் cert= மதிப்பு ஒரு key ஆகும். bridge பதிலளிப்பதற்கு முன்பே client அந்த key-ஐ வைத்திருப்பதை நிரூபிக்க வேண்டும். இது active probing-ஐத் தடுக்கிறது: உங்கள் முகவரியுடன் இணைந்து அது Tor-ஆ என்று சோதிக்கும் தணிக்கையாளருக்கு எந்தப் பதிலும் கிடைக்காது, அவர்களால் எதையும் அறிய முடியாது.

நீங்கள் எந்த pluggable transport-ஐ இயக்க வேண்டும்?

• obfs4-க்கு ஒரு VPS, இரண்டு TCP ports மற்றும் domain name தேவையில்லை. இது நீங்கள் இயக்கக்கூடிய மிக எளிதான பயனுள்ள கருவியாகும், மேலும் இந்த வழிகாட்டியின் மையப்பொருளும் இதுவே.
• WebTunnel இணைப்பை ஒரு உண்மையான இணையதளத்தின் சாதாரண HTTPS traffic-க்குள் மறைக்கிறது. Tor Project இதற்கான தேவைகளாக, ஒரு static IPv4 address, உங்கள் கட்டுப்பாட்டில் உள்ள ஒரு domain, NGINX அல்லது Apache போன்ற செயல்படும் web server, செல்லுபடியாகும் TLS certificate மற்றும் குறைந்தபட்சம் 1 GB RAM (4 GB பரிந்துரைக்கப்படுகிறது) ஆகியவற்றைக் குறிப்பிடுகிறது. இணைய உலாவலைத் தவிர வேறு எதையும் அனுமதிக்காத நாடுகளில் கூட HTTPS அனுமதிக்கப்படுவதால், சீரற்ற traffic-ஐ சந்தேகத்திற்குரியதாகக் கருதும் நெட்வொர்க்குகளுக்கு இது ஏற்றது.
• Snowflake ஒரு மாறுபட்ட பங்களிப்பாகும். தன்னார்வலர்கள் குறுகிய கால WebRTC proxies-ஐ இயக்குவதால், நுழைவுப் புள்ளிகள் தொடர்ந்து மாறிக்கொண்டே இருக்கும்; எனவே தணிக்கையாளர்கள் தடுப்பதற்கு நிலையான முகவரி எதுவும் இருக்காது. இதற்காக நீங்கள் ஒரு bridge-ஐ இயக்க வேண்டியதில்லை. நீங்கள் ஒரு proxy-ஐ மட்டுமே இயக்குகிறீர்கள், இதற்கு நிலையான முகவரி தேவையில்லை.

obfs4-ல் தொடங்குங்கள். நீங்கள் பின்னர் மற்றொரு முகவரியில் WebTunnel bridge-ஐச் சேர்த்துக்கொள்ளலாம்: இரண்டையும் ஒரே IP-ல் இயக்கினால், அந்த ஒரு முகவரி தடுக்கப்பட்டால் இரண்டுமே செயலிழந்துவிடும்.

ஒரு bridge-ஐ இயக்குவதற்கு எவ்வளவு செலவாகும்?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

ஆகஸ்ட் 2026 நிலவரப்படி, Tor Project ஒரு bridge-க்கு குறைந்தபட்சம் 1 Mbit/s upstream மற்றும் downstream அலைவரிசையை (bandwidth) எதிர்பார்க்கிறது. ஒரு guard அல்லது middle relay-க்கு 10 Mbit/s எதிர்பார்க்கப்படுகிறது, மேலும் 16 Mbit/s பரிந்துரைக்கப்படுகிறது. இவை வெளியிடப்பட்ட தேவைகள், அளவீடுகள் அல்ல. ஒரு புதிய bridge பொதுவாக பல வாரங்களுக்கு அதன் குறைந்தபட்ச அளவை விடக் குறைவாகவே செயல்படும். அதே தேவைகள் பக்கத்தில் ஒரு relay-க்கு மாதத்திற்கு குறைந்தபட்சம் 100 GByte வெளிச்செல்லும் traffic (outbound traffic) இருக்க வேண்டும் என்று குறிப்பிடப்பட்டுள்ளது. மிகச்சிறிய VPS திட்டங்களே இதை ஈடுசெய்துவிடும் என்பதால், பெரிய அளவில் எதையும் வாங்குவதற்கு முன் ஒரு சிறிய VPS-க்கு மாதத்திற்கு எவ்வளவு செலவாகும் என்பதைப் படிக்கவும்.

துஷ்பிரயோக வாய்ப்பு (abuse surface) மிகக் குறைவு, இதுவே பலரும் தவறாகப் புரிந்துகொள்ளும் விஷயம். ஒரு bridge என்பது முதல் படியாகும் (first hop). உங்கள் server-லிருந்து வெளியேறும் traffic மற்றொரு Tor relay-க்குச் செல்கிறதே தவிர, பயனர் தேர்ந்தெடுக்கும் எந்த இணையதளத்திற்கும் நேரடியாகச் செல்வதில்லை. ஒரு கோரிக்கையின் மூலமாக உங்கள் IP முகவரி எந்தவொரு அந்நியரின் web log-லும் இடம்பெறாது, எனவே exit relay இயக்குபவர்கள் எதிர்கொள்ளும் புகார்கள் உங்களுக்கு வராது. இருப்பினும், சில host-கள் எந்தவொரு Tor சேவையையும் தனிப்பட்ட வகையாகக் கருதுவதால், உங்கள் provider-ன் acceptable use policy-ஐச் சரிபார்க்கவும்.

செய்யக்கூடாத ஒரு விஷயம்: ஏற்கனவே இயங்கும் ஒரு public relay-ஐ அதே முகவரியில் bridge-ஆக மாற்ற வேண்டாம். அந்தச் சூழலில் Tor Project-ன் அறிவுரை என்னவென்றால், "IP முகவரி, பெயர் மற்றும் fingerprint" ஆகியவற்றை மாற்ற வேண்டும் என்பதாகும், ஏனெனில் பழைய முகவரி ஏற்கனவே தணிக்கையாளர்கள் பதிவிறக்கம் செய்யும் consensus-ல் இருக்கும். கடந்த வாரம் public relay-ஆக இருந்த ஒரு bridge, ஏற்கனவே blocklist-ல் இருக்கும்.

வேகத்தை விட uptime முக்கியமானது. relay தேவைகளில், "உங்கள் relay ஒரு நாளைக்கு 2 மணி நேரத்திற்கு மேல் இயங்கவில்லை என்றால் அதன் பயன் குறைவு" என்று கூறப்பட்டுள்ளது. ஒரு bridge-ன் நிலை இதைவிட மோசமானது, ஏனெனில் ஒவ்வொரு பயனருக்கும் ஒரே ஒரு முகவரி மட்டுமே இருக்கும், மாற்று வழி (fallback) இருக்காது. ஒரு restart செய்யப்படும்போது அதில் உள்ள அனைத்து பயனர்களும் துண்டிக்கப்படுவார்கள். அது செயல்படுவதை நிறுத்தும் நாளை உடனே தெரிந்துகொள்ள, Uptime Kuma-வில் ஒரு TCP port check-ஐ obfs4 port-க்கு எதிராக அமைக்கவும்.

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

Distribution packages காலாவதியானவை. ஒரு bridge என்பது பாதுகாப்பு மென்பொருள் என்பதால், அது எப்போதும் புதிய பதிப்பாக இருக்க வேண்டும். முதலில் project-ன் சொந்த repository-ஐச் சேர்க்கவும்.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

இப்போது source file-ஐ உருவாக்கவும். Suites: வரியில் உங்கள் release codename இருக்க வேண்டும், எனவே அதை நினைவில் இருந்து தட்டச்சு செய்யாமல், system-லிருந்து நேரடியாகப் படிக்கவும்.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
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 obfs4proxy

apt update உங்கள் codename-க்கு repository-ல் Release file இல்லை என்று காட்டினால், Tor Project அந்த release-ஐ ஆதரிக்கவில்லை என்று பொருள். /etc/apt/sources.list.d/tor.sources-ஐ நீக்கிவிட்டு, sudo apt update-ஐ மீண்டும் இயக்கவும், பிறகு உங்கள் distribution வழங்கும் tor package-ஐ நிறுவவும். கீழே உள்ள அனைத்தும் ஒரே மாதிரியானவை.

obfs4proxy package Debian மற்றும் Ubuntu-விலேயே கிடைக்கிறது (ஆகஸ்ட் 2026 நிலவரப்படி, Debian 13-ல் பதிப்பு 0.0.14). Binary எங்குள்ளது என்பதை உறுதிப்படுத்தவும், ஏனெனில் அதன் path-ஐத்தான் configuration-ல் பயன்படுத்த வேண்டும்:

command -v obfs4proxy || command -v lyrebird

Upstream இந்த project-ன் பெயரை lyrebird என்று மாற்றியுள்ளது, எனவே புதிய package /usr/bin/lyrebird-ஐ நிறுவலாம். அந்த command காட்டும் path-ஐப் பயன்படுத்தவும்.

/etc/tor/torrc கோப்பில் bridge-ஐ உள்ளமைத்தல்

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

இந்த வரிகள் ஒவ்வொன்றிலும் பிழை ஏற்பட வாய்ப்புள்ளதால், ஒவ்வொன்றாகக் கவனிக்கவும்.

BridgeRelay 1 என்பது, பொதுவான consensus-க்கு பதிலாக bridge authority-க்கு தனது descriptor-ஐ அனுப்பும்படி tor-க்கு கட்டளையிடுகிறது. இந்த ஒரே ஒரு வரிதான் relay-ஐ unlisted ஆக மாற்றுகிறது.

ORPort என்பது உண்மையான Tor port ஆகும். இது இணையத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டும், ஏனெனில் tor இதைச் சோதிக்கும்; அந்தச் சோதனை வெற்றிபெறும் வரை descriptor-ஐ வெளியிடாது.

ServerTransportPlugin என்பது tor-க்கு இயக்க வேண்டிய கட்டளையை வழங்குகிறது. tor ஆனது obfs4proxy-ஐ ஒரு child process-ஆகத் தொடங்கி, ஒரு pipe வழியாக அதனுடன் தொடர்பு கொள்கிறது. எனவே, obfs4proxy-க்கு என்று தனியாக service unit கிடையாது, அது systemctl status-ல் ஒருபோதும் காட்டப்படாது.

ServerTransportListenAddr என்பது obfs4proxy கேட்கும் (listen) port-ஐ உறுதிப்படுத்துகிறது. இந்த வரியை நீக்கினால், obfs4proxy தொடங்கும் ஒவ்வொரு முறையும் ஒரு புதிய port-ஐத் தேர்ந்தெடுக்கும்; பெரும்பாலான மறுதொடக்கங்களுக்குப் பிறகு அது மாறும். இதனால், நீங்கள் ஏற்கனவே வழங்கிய ஒவ்வொரு bridge வரியும், எந்தச் சேவையும் இயங்காத ஒரு port-ஐச் சுட்டிக்காட்டும். அந்த வாடிக்கையாளர்களுக்கு connection மறுக்கப்படும், அவர்கள் முயற்சி செய்வதை நிறுத்திவிடுவார்கள்.

ExtORPort auto என்பது extended ORPort-ஐத் திறக்கிறது. இது ஒரு loopback channel ஆகும்; obfs4proxy இதைப் பயன்படுத்தி, வாடிக்கையாளரின் முகவரியுடன் சேர்த்து முடிக்கப்பட்ட இணைப்புகளை tor-க்குத் திருப்பி அளிக்கிறது. Tor Project-ன் அமைப்பு வழிகாட்டி ஒவ்வொரு bridge-லும் இதை உள்ளடக்கியுள்ளது, ஏனெனில் இது இல்லாமல் transport-ஆல் அந்த முகவரியை tor-க்குத் தெரிவிக்க முடியாது.

ContactInfo மற்றும் Nickname ஆகிய இரண்டும் பொதுவானவை. நீங்கள் அடிக்கடி சரிபார்க்கும் மின்னஞ்சல் முகவரியைப் பயன்படுத்தவும், ஏனெனில் ஒரு bridge பழுதடைந்தால் Tor Project உங்களைத் தொடர்புகொள்ள இதுவே வழி. மேலும், நீங்கள் அடையாளம் தெரியாமல் இருக்க விரும்பினால், உங்களை வெளிப்படுத்தாத ஒரு புனைப்பெயரைத் (nickname) தேர்வு செய்யவும்.

BridgeDistribution என்பது உங்கள் முகவரியை பயனர்களுக்கு எந்த distributor வழங்கும் என்பதைத் தீர்மானிக்கிறது. ஏற்றுக்கொள்ளப்பட்ட மதிப்புகள் https, email, telegram, settings, none மற்றும் any ஆகும். முதல் bridge-க்கு any-ஐப் பயன்படுத்தி, கணினியே முடிவெடுக்க அனுமதிக்கவும். நீங்கள் நீங்களே நேரடியாக வழங்கும் ஒரு private bridge-க்கு none-ஐப் பயன்படுத்தவும்; இது முகவரியைப் பொது விநியோகத்திலிருந்து முழுமையாகத் தவிர்க்கும்.

போர்ட் (port) தேர்வு ஏன் முக்கியமானது

இரண்டு போர்ட்களுக்கும் 9001-ஐப் பயன்படுத்த வேண்டாம். Tor Project இதை நேரடியாகவே அறிவுறுத்துகிறது, ஏனெனில் 9001 என்பது பாரம்பரியமான ORPort ஆகும், மேலும் தணிக்கையாளர்கள் இணையத்தில் இதற்காகவே ஸ்கேன் செய்கிறார்கள். tor மற்றும் obfs4proxy ஆகிய இரண்டும் தனித்தனி listener-களைக் கொண்டிருப்பதால், இந்த இரண்டு போர்ட்களும் ஒன்றுக்கொன்று மாறுபட்டதாக இருக்க வேண்டும்.

obfs4-க்கு மிகவும் பாதுகாப்பான போர்ட் 443 ஆகும். கட்டுப்பாடுகள் உள்ள கிட்டத்தட்ட அனைத்து நெட்வொர்க்குகளிலும் வெளிச்செல்லும் (outbound) 443 போர்ட் திறந்திருக்கும், மேலும் இதனுடன் நீண்ட நேரம் நீடிக்கும் இணைப்பு ஒரு சாதாரண இணைய அமர்வு (web session) போலவே தோன்றும். 1024-க்குக் குறைவான போர்ட்களைப் பயன்படுத்த ஒரு கூடுதல் படி தேவைப்படுகிறது, ஏனெனில் obfs4proxy root பயனர் உரிமையுடன் இயங்குவதில்லை:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

திறக்கும் ஒவ்வொரு எடிட்டரிலும் இந்த இரண்டு வரிகளைச் சேர்க்கவும்:

[Service]
NoNewPrivileges=no

இந்த capability மட்டும் போதுமானதல்ல. systemd-ன் NoNewPrivileges, ஒரு செயல்முறை (process) அதன் பெற்றோர் செயல்முறைக்கு இல்லாத எந்தவொரு கூடுதல் உரிமையையும் பெறுவதைத் தடுக்கிறது. file capability என்பது அத்தகைய ஒரு உரிமையே என்பதால், இந்த அமைப்பு செயல்பாட்டில் இருக்கும்போது obfs4proxy-ஆல் 443 போர்ட்டை bind செய்ய முடியாது.

நீங்கள் அந்தப் படியைத் தவிர்க்க விரும்பினால், கவனத்தை ஈர்க்காத ஒரு உயர் போர்ட் எண்ணைத் தேர்ந்தெடுத்துக் குறித்துக் கொள்ளுங்கள். நீங்கள் எதைத் தேர்ந்தெடுத்தாலும், obfs4 போர்ட்டை பிறகு மாற்ற வேண்டாம். ஒரு bridge line என்பது முகவரி, போர்ட், fingerprint மற்றும் certificate ஆகியவற்றை ஒன்றாக இணைக்கிறது. எனவே, போர்ட் மாறியவுடன் பயனரின் பிரவுசரில் ஏற்கனவே உள்ள அனைத்து நகல்களும் வேலை செய்யாமல் போய்விடும்.

இரண்டு firewalls-களிலும் ports-ஐத் திறக்கவும்

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

இரண்டு ports-ம் திறந்திருக்க வேண்டும். பெரும்பாலான service providers தங்கள் control panel-ல் இரண்டாவது firewall-ஐ இயக்குகிறார்கள்; இது குறித்து ufw-க்குத் தெரியாது. server-ல் மட்டும் ஒரு rule இருந்து, panel-ல் இல்லையென்றால், அந்த bridge-ஐ அணுக முடியாது, அது descriptor-ஐயும் வெளியிடாது. இதில் ஏதேனும் ஒன்று உங்களுக்குப் புதியது என்றால், புதிய VPS-க்குத் தேவையான ufw rules மற்றும் Linux-ல் listening port என்றால் என்ன ஆகியவற்றை வாசிக்கவும். அங்கிருக்கும்போதே, SSH-ஐ keys மற்றும் கடினமாக்கப்பட்ட sshd config மூலம் பாதுகாக்கவும். password SSH உள்ள ஒரு server-ல், பட்டியலிடப்படாத bridge இருந்தாலும், அது இன்னும் password SSH கொண்ட server-ஆகவே இருக்கும்.

சேவையைத் தொடங்கி, பதிவுகளை (logs) வாசிக்கவும்

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian மற்றும் Ubuntu-வில் இரண்டு units வழங்கப்படுகின்றன. tor.service என்பது ஒரு சிறிய wrapper ஆகும், tor@default.service என்பது உண்மையான பணியைச் செய்யும் process ஆகும். இதனால்தான் journalctl -u tor காலியாகத் தோன்றும், ஆனால் உங்களுக்குத் தேவையான பதிவுகள் tor@default-ன் கீழ் இருக்கும்.

செயல்பாடு வெற்றிகரமாக முடிந்ததை இரண்டு வரிகள் உறுதிப்படுத்தும்:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

முதல் வரி, reachability சோதனை தேர்ச்சி பெற்றதையும், descriptor bridge authority-க்குச் சென்றதையும் குறிக்கிறது. இது தோன்றவில்லை என்றால், இணையத்திற்கும் உங்கள் server-க்கும் இடையில் ஏதோ ஒன்று ORPort-க்கான traffic-ஐத் தடுக்கிறது. இரண்டாவது வரி நீங்கள் கட்டமைத்த (configured) port-ஐக் காட்ட வேண்டும். அங்கு வேறு port தெரிந்தால், tor-ஆல் ServerTransportListenAddr-ஐச் செயல்படுத்த முடியவில்லை என்று பொருள். இதற்குப் பொதுவான காரணம் transport பெயரில் உள்ள முரண்பாடு ஆகும்: இரண்டு directives-லும் இது obfs4 என்று இருக்க வேண்டும்.

இரண்டு listeners-ம் இயங்குகின்றனவா என்பதை உறுதிப்படுத்தவும்:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

எனது bridge line எங்கே உள்ளது?

obfs4proxy, tor-ன் data directory-க்குள் ஒரு template-ஐ எழுதுகிறது:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

அந்த directory tor பயனருக்குச் சொந்தமானது மற்றும் அதன் mode 700 ஆகும், எனவே sudo இல்லாமல் உங்களுக்கு Permission denied கிடைக்கும். அந்த கோப்பு இந்த வடிவில் ஒரு வரியைக் கொண்டுள்ளது:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

<IP ADDRESS>-ஐ உங்கள் server-ன் public address கொண்டும், <PORT>-ஐ ORPort அல்லாத obfs4 port கொண்டும், <FINGERPRINT>-ஐ tor அதன் data directory-ல் எழுதிய identity fingerprint கொண்டும் மாற்றவும்:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

முதல் கோப்பு உங்கள் nickname மற்றும் bridge line-ல் இருக்க வேண்டிய identity fingerprint-ஐக் கொண்டுள்ளது. இரண்டாவது கோப்பு hashed fingerprint-ஐக் கொண்டுள்ளது; உங்கள் bridge இயங்குகிறதா மற்றும் எத்தனை clients அதை அணுகுகிறார்கள் என்பதைப் பார்க்க, இதைத்தான் நீங்கள் Relay Search-ல் பதிவிட வேண்டும். இவை இரண்டையும் ஒன்றுக்கொன்று மாற்ற முடியாது. hashed மதிப்பைக் கொண்ட ஒரு bridge line, உங்கள் bridge வழங்கும் identity key-உடன் பொருந்தாது, எனவே client தான் தொடங்கிய இணைப்பை நிராகரித்துவிடும்.

ஒரு bridge எவ்வாறு பயனர்களைச் சென்றடைகிறது?

உங்கள் bridge line-ஐ நீங்கள் யாரிடமும் நேரடியாக வழங்க வேண்டியதில்லை. descriptor ஒருமுறை bridge authority-ஐ அடைந்தவுடன், விநியோக அமைப்பு (BridgeDB-ன் அடுத்தகட்டமான rdsys), உங்கள் bridge-ஐ ஒரு குறிப்பிட்ட distributor-க்கு ஒதுக்கும். பயனர்கள் அந்த distributor-இடம் bridge-களைக் கோருவார்கள். ஆகஸ்ட் 2026 நிலவரப்படி, இதற்கான வழிகள் பின்வருமாறு:

• bridges.torproject.org/options என்ற இணையதளப் படிவம்; இது captcha சரிபார்ப்பிற்குப் பிறகு bridge line-களை வழங்கும்.
• Gmail அல்லது Riseup முகவரியிலிருந்து bridges@torproject.org-க்கு அனுப்பப்படும் மின்னஞ்சல்; இது bridge line-களைப் பதிலளிக்கும். கட்டுப்பாடற்ற இலவச மின்னஞ்சல் கணக்குகள் மூலம் தணிக்கையாளர்கள் அனைத்து bridge-களையும் கண்டறியக்கூடும் என்பதால் இந்த வழங்குநர் கட்டுப்பாடு நடைமுறையில் உள்ளது.
• Telegram bot @GetBridgesBot. இதில் /start-ஐ அனுப்பி, பின் /obfs4 அல்லது /webtunnel-ஐப் பயன்படுத்தவும்.
• Tor Browser-ன் Settings பகுதியில் உள்ள Connection பகுதி; இதில் "Request bridges" என்பதைத் தேர்ந்தெடுப்பதன் மூலம் moat channel வழியாக bridge-களைப் பெறலாம்.

ஒரு புதிய bridge அமைக்கப்பட்ட மூன்று மணி நேரத்திற்குப் பிறகு Relay Search-ல் தோன்றும். ஆனால் பயனர்கள் இணைவதற்கு அதிக காலம் எடுக்கும்: Tor Project-ன் கூற்றுப்படி, "தொடர்ச்சியான பயனர்களைக் காண பல நாட்கள் அல்லது வாரங்கள் ஆகலாம்." தொடக்கத்தில் சில வாரங்களுக்குப் பயனர்கள் இல்லாமல் இருப்பது இயல்பானது, இது பிழை அல்ல.

BridgeDistribution none என்பதை அமைப்பதன் மூலம், இந்த விநியோக முறைகளிலிருந்து நீங்கள் விலகிக்கொள்ளலாம். அவ்வாறு செய்யும்போது, தணிக்கையாளர்கள் கண்காணிக்காத ஒரு பாதுகாப்பான வழிமுறை மூலம், தேவைப்படும் நபர்களுக்கு மட்டும் உங்கள் bridge line-ஐ நீங்கள் வழங்கலாம்.

ஏதாவது வேலை செய்யவில்லை என்றால்

Log-ல் self-testing வரி இல்லை. ORPort-ஐ அணுக முடியவில்லை. மற்றொரு machine-லிருந்து nc -vz your.ip 8443 மூலம் அதைச் சோதிக்கவும். Hang ஆகிறது என்றால் packets தடுக்கப்படுகின்றன என்று அர்த்தம், எனவே ufw மற்றும் provider-ன் panel-ஐச் சரிபார்க்கவும். Refusal என்று வந்தால் tor listening நிலையில் இல்லை என்று அர்த்தம், எனவே ss -lntp-ஐச் சரிபார்த்து, config error உள்ளதா என log-ஐப் படிக்கவும்.

பதிவு செய்யப்பட்ட transport நீங்கள் தேர்வு செய்யாத ஒரு port-ஐக் காட்டுகிறது. tor ServerTransportListenAddr-ஐப் புறக்கணித்துவிட்டது. Transport பெயர் ServerTransportPlugin-ல் உள்ள பெயருடன் சரியாகப் பொருந்த வேண்டும், மேலும் இரண்டுமே obfs4-ஆக இருக்க வேண்டும்.

obfs4proxy 443 port-ஐ bind செய்யவில்லை. getcap /usr/bin/obfs4proxy மூலம் capability-ஐ உறுதிப்படுத்தவும், பின் override அந்த unit-ஐ அடைந்ததை systemctl show tor@default -p NoNewPrivileges மூலம் உறுதிப்படுத்தவும். அது NoNewPrivileges=yes என்று காட்டினால், உங்கள் drop-in இயங்காத ஒரு unit-க்குச் சென்றுவிட்டது என்று அர்த்தம்.

/var/lib/tor/pt_state/-க்குள் எதுவும் இல்லை. tor அந்த transport-ஐத் தொடங்கவில்லை, அதாவது ServerTransportPlugin-ல் உள்ள பாதை தவறானது. command -v obfs4proxy-ன் output-உடன் அதை ஒப்பிட்டுப் பார்க்கவும்.

மாற்றம் செய்த பிறகு clients இணைப்பதை நிறுத்திவிட்டன. முகவரி அல்லது obfs4 port-ல் செய்யப்படும் எந்த மாற்றமும் ஏற்கனவே விநியோகிக்கப்பட்ட அனைத்து bridge வரிகளையும் செல்லாததாக்கிவிடும். சில provider-களிடம் rebuild செய்யும்போது server-ன் public IP மாறியுள்ளதா என்பதையும் சரிபார்க்கவும்.

tor தொடங்கவே இல்லை. sudo -u debian-tor tor --verify-config -f /etc/tor/torrc-ஐ இயக்கவும். இது கோப்பைப் பகுப்பாய்வு செய்து, எந்த வரியில் பிழை உள்ளது என்பதைக் காட்டும், மேலும் இயங்கிக்கொண்டிருக்கும் service-ஐப் பாதிக்காது.

FAQ

எனது VPS வழங்குநர் Tor bridge குறித்து புகார் அளிப்பாரா?

Bridge என்பது ஒரு நுழைவுப் புள்ளி மட்டுமே. எனவே, உங்கள் server-லிருந்து வெளியேறும் traffic பிற Tor relay-களுக்குச் செல்லுமே தவிர, பயனர் தேர்ந்தெடுக்கும் எந்த இணையதளத்திற்கும் நேரடியாகச் செல்லாது. ஒரு கோரிக்கையின் மூலமாக உங்கள் IP address யாருடைய இணைய log-லும் பதிவாகாது. இதனால்தான் exit relay இயக்குபவர்கள் சந்திக்கும் புகார்கள் உங்களுக்கு வராது. இருப்பினும், hosting விதிகள் மாறுபடும். சில வழங்குநர்கள் எந்தவொரு Tor சேவையையும் தனிப்பட்ட முறையில் அணுகலாம். எனவே, தொடங்குவதற்கு முன் acceptable use policy-ஐப் படித்துவிட்டு, நீங்கள் படிக்கும் முகவரியை ContactInfo-ல் உள்ளிடவும்.

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

குறைந்தபட்சத் தேவையாக 1 Mbit/s upload மற்றும் download வேகம் பரிந்துரைக்கப்படுகிறது. இது guard அல்லது middle relay-க்குத் தேவைப்படும் 10 Mbit/s-ஐ விடக் குறைவு. உங்கள் bridge-க்கு வரும் பயனர்களை விநியோகஸ்தர் (distributor) தீர்மானிப்பதால், பயன்பாடு ஆரம்பத்தில் பூஜ்ஜியத்திற்கு அருகிலேயே இருக்கும். நீங்கள் ஒரு குறிப்பிட்ட வரம்பை நிர்ணயிக்க விரும்பினால், torrc-ல் RelayBandwidthRate மற்றும் RelayBandwidthBurst ஆகியவற்றை அமைக்கவும்.

எனது புதிய bridge-ல் ஏன் யாரும் இணையவில்லை?

ஒரு bridge Relay Search-ல் தோன்றுவதற்கு சுமார் மூன்று மணிநேரம் ஆகும். Tor Project-ன் வழிகாட்டுதலின்படி, நிலையான பயனர்களைப் பெற சில நாட்கள் அல்லது வாரங்கள் ஆகலாம். journalctl -u tor@default-ல் உள்ள self-testing வரியின் மூலம் descriptor வெளியிடப்பட்டுள்ளதா என்பதைச் சரிபார்க்கவும். Relay Search-ல் உங்கள் hashed fingerprint-ஐத் தேடி, BridgeDistribution என்பது none என அமைக்கப்படவில்லை என்பதை உறுதிப்படுத்தவும்.

நான் obfs4 அல்லது WebTunnel எதை இயக்க வேண்டும்?

நீங்கள் முதன்முதலில் bridge-ஐ இயக்குகிறீர்கள் என்றால் obfs4-ஐத் தேர்ந்தெடுக்கவும்: இதற்கு ஒரு VPS, இரண்டு ports, domain தேவையில்லை, certificate தேவையில்லை. சாதாரணமான traffic-ஐயே தடுக்கும் இடங்களில் WebTunnel-ஐப் பயன்படுத்தவும். இதற்கு நீங்கள் கட்டுப்படுத்தும் ஒரு domain, உண்மையான web server, செல்லுபடியாகும் TLS certificate மற்றும் குறைந்தபட்சம் 1 GB RAM தேவை. நீங்கள் இரண்டையும் இயக்கினால், அவற்றை வெவ்வேறு IP முகவரிகளில் வைக்கவும். இல்லையெனில், ஒரு IP தடுக்கப்பட்டால் ஒரே நேரத்தில் இரண்டு bridge-களும் செயலிழந்துவிடும்.

obfs4 port-ஐப் பிறகு மாற்றினால் என்னவாகும்?

ஏற்கனவே விநியோகிக்கப்பட்ட அனைத்து bridge வரிகளும் வேலை செய்வதை நிறுத்திவிடும். ஒரு bridge வரி என்பது முகவரி, port, fingerprint மற்றும் certificate ஆகியவற்றை ஒன்றாக இணைக்கிறது. எனவே, பழைய வரியைக் கொண்ட பயனர், எந்தச் சேவையும் இயங்காத port-க்கு இணைப்பை ஏற்படுத்த முயன்று தோல்வியடைவார். server-ன் public IP மாறினாலும் இதே நிலைதான் ஏற்படும். setup செய்யும்போதே port-ஐத் தேர்வு செய்து, அதை மாற்றாமல் வைத்திருப்பது நல்லது.