VPSలో obfs4 Tor bridge ఎలా నడపాలి

Tor bridge అంటే ఏమిటి, అది ఎందుకు అవసరం

Tor bridge అనేది Tor network లోకి ప్రవేశించే ఒక endpoint. దీని address public relay list లో ప్రచురించబడదు. ఆ list ను consensus అంటారు. ఇది ఎవరైనా download చేసుకోగల signed document. censor కూడా దాన్ని download చేయగలదు. దాన్ని ఆధారంగా Tor ను block చేయడానికి ఎక్కువ సమయం అవసరం లేదు: consensus ను fetch చేసి, అందులో ఉన్న ప్రతి address ను network border వద్ద drop చేయవచ్చు. ప్రచురిత list బలహీనమైన స్థానం కాబట్టే bridges ఉన్నాయి. Bridge addresses ను ఒకేసారి మొత్తం కాకుండా, కొద్దికొద్దిగా అందిస్తారు. అందువల్ల ఏ ఒక్క request ద్వారా మొత్తం set బయటపడదు.

List లో లేని address ఉండటం పరిష్కారంలో సగం మాత్రమే. Deep packet inspection (DPI) traffic ను address ఆధారంగా కాకుండా, దాని content ఆధారంగా వర్గీకరిస్తుంది. ఇది TLS (transport layer security) handshake ఆకృతిని బట్టి Tor connection ను గుర్తించగలదు. List లేని censor కూడా “ఇది Tor లాగా కనిపిస్తోంది” అని గుర్తించి connection ను drop చేయగలదు. Pluggable transport ఆ గుర్తింపు సంకేతాన్ని తొలగిస్తుంది. ఇది client వైపు Tor stream ను మరొక రూపంలో wrap చేస్తుంది. మీ bridge దాన్ని unwrap చేస్తుంది.

చాలా bridges నడిపే transport obfs4. ఇది stream ను header లేని, fixed handshake లేని bytes గా మారుస్తుంది. అందువల్ల DPI సరిపోల్చడానికి pattern ఉండదు. ఇది client ను authenticate కూడా చేస్తుంది. Bridge line లోని cert= value ఒక key. Bridge స్పందించే ముందు client తన వద్ద ఆ key ఉందని నిరూపించాలి. దీనివల్ల active probing అడ్డుకోబడుతుంది. Tor మాట్లాడుతుందో లేదో పరీక్షించడానికి censor మీ address కు connect అయినా reply అందదు. అందువల్ల దానికి ఏ సమాచారం తెలియదు.

మీరు ఏ pluggable transport ను అమలు చేయాలి?

• obfs4 కు ఒక VPS, రెండు TCP ports, domain name అవసరం లేదు. అమలు చేయడానికి ఇది అత్యంత సులభమైన ఉపయోగకరమైన ఎంపిక. ఈ guide కూడా దీనినే వివరిస్తుంది.
• WebTunnel కనెక్షన్‌ను నిజమైన website కు పంపే సాధారణ HTTPS traffic లో దాచుతుంది. Tor Project పేర్కొన్న అవసరాలు: static IPv4 address, మీరు నియంత్రించే domain, NGINX లేదా Apache వంటి పనిచేసే web server, చెల్లుబాటు అయ్యే TLS certificate, కనీసం 1 GB RAM; 4 GB సిఫార్సు చేయబడింది. యాదృచ్ఛికంగా కనిపించే traffic‌నే అనుమానాస్పదంగా భావించే networks కు ఇది అనుకూలంగా ఉంటుంది. వెబ్ browsing కు మాత్రమే పరిమిత అనుమతి ఉన్న దేశంలో కూడా HTTPS సాధారణంగా అనుమతించబడుతుంది.
• Snowflake వేరే విధమైన సహకారం. Volunteers తక్కువకాలం పనిచేసే WebRTC proxies ను అమలు చేస్తారు. అందువల్ల entry points నిరంతరం మారుతాయి. censor block చేయగల స్థిరమైన address ఉండదు. దీని కోసం మీరు bridge ను నిర్వహించరు. మీరు proxy ను అమలు చేస్తారు. దానికి fixed address అవసరం లేదు.

ముందుగా obfs4 తో ప్రారంభించండి. తరువాత రెండవ address పై WebTunnel bridge ను జోడించవచ్చు. రెండింటినీ ఒకే IP పై అమలు చేస్తే, ఒక address block అయినప్పుడు రెండూ పనిచేయకుండా పోతాయి.

బ్రిడ్జ్‌ను నడపడానికి అయ్యే ఖర్చు ఏమిటి?

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

August 2026 నాటికి Tor Project ఒక bridge కోసం కనీసం 1 Mbit/s upstream మరియు downstream bandwidth కోరుతోంది. Guard లేదా middle relay కోసం 10 Mbit/s కోరుతోంది; 16 Mbit/s సిఫార్సు చేయబడింది. ఇవి ప్రచురించిన requirements మాత్రమే; కొలిచిన విలువలు కావు. కొత్త bridge సాధారణంగా కొన్ని వారాల పాటు తన కనీస పరిమితికన్నా చాలా తక్కువ bandwidth ఉపయోగిస్తుంది. అదే requirements పేజీ relay కోసం నెలకు కనీసం 100 GByte outbound traffic కోరుతోంది. చిన్న plans లోనే ఇది సాధారణంగా అందుబాటులో ఉంటుంది. కాబట్టి మరింత పెద్ద పరిమాణాన్ని ఎంచుకునే ముందు చిన్న VPS కు నెలకు వాస్తవంగా ఎంత ఖర్చవుతుందో తెలుసుకోండి.

Abuse surface పరిమితంగానే ఉంటుంది. ఈ విషయంలోనే చాలామంది తప్పుగా అర్థం చేసుకుంటారు. Bridge మొదటి hop. మీ server నుంచి బయలుదేరే traffic మరొక Tor relay కు వెళ్తుంది. అది user ఎంచుకున్న website కు నేరుగా వెళ్లదు. Request కు source గా మీ IP address ఎప్పుడూ అపరిచితుడి web log లో కనిపించదు. అందువల్ల exit relay operators నిర్వహించే complaint mail ఇక్కడికి రాదు. అయినప్పటికీ మీ provider యొక్క acceptable use policy ను పరిశీలించండి. కొంతమంది hosts ఏ Tor service నైనా ప్రత్యేక సందర్భంగా పరిగణిస్తారు. Bridge మరియు onion service ఈ విషయంలో పరస్పర విరుద్ధమైన విధానాల్లో పనిచేస్తాయి: దాని address అందుబాటులో ఉండి చివరకు users కు అందించబడినప్పుడే bridge ఉపయోగకరంగా ఉంటుంది. అదే విధంగా అదే రకమైన VPS పై v3 onion service మీ public IP బయటపడకుండా ఉన్నప్పుడే ఉపయోగకరంగా ఉంటుంది.

చేయకూడనిది ఒకటి ఉంది: ఇప్పటికే ఉన్న public relay ను అదే address పై bridge గా మార్చకండి. ఆ సందర్భంలో Tor Project ఇచ్చే సలహా "IP address, name and fingerprint" మార్చాలని. ఎందుకంటే censorలు download చేసే consensus లో పాత address ఇప్పటికే ఉంది. గత వారం public relay గా ఉన్న bridge ఇప్పటికే blocklist లో ఉండే అవకాశం ఉంది.

Speed కంటే uptime ముఖ్యమైనది. Relay requirements ప్రకారం, "మీ relay రోజుకు 2 గంటలకంటే ఎక్కువసేపు నడవకపోతే దాని ఉపయోగకరత పరిమితంగా ఉంటుంది". ఈ విషయంలో bridge పరిస్థితి relay కంటే అధ్వానంగా ఉంటుంది. ప్రతి client కు ఒకే address ఉంటుంది. Fallback ఉండదు. Restart జరిగితే దానిపై ఉన్న ప్రతి user connection కోల్పోతుంది. obfs4 port కు వ్యతిరేకంగా Uptime Kuma లో TCP port check ను ఏర్పాటు చేయండి. అది స్పందించడం ఆపిన రోజే మీకు తెలుస్తుంది.

Tor Project repository నుండి Torని install చేయండి

Distribution packages ఆలస్యంగా వస్తాయి. Bridge అనేది ప్రస్తుత స్థితిలో ఉండాల్సిన security software. ముందుగా 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: lineలో మీ 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కు packages అందించడం లేదని అర్థం. /etc/apt/sources.list.d/tor.sources ను తొలగించి, మళ్లీ sudo apt update నడపండి. తరువాత మీ distribution అందించే tor packageను install చేయండి. దిగువన ఉన్న అన్ని దశలు అలాగే ఉంటాయి.

obfs4proxy packageను Debian మరియు Ubuntu స్వయంగా అందిస్తాయి (August 2026 నాటికి Debian 13లో version 0.0.14). Binary ఎక్కడ install అయిందో నిర్ధారించండి. ఎందుకంటే దాని pathను configలో చేర్చాలి:

command -v obfs4proxy || command -v lyrebird

Upstream project పేరును lyrebirdగా మార్చింది. అందువల్ల కొత్త package బదులుగా /usr/bin/lyrebird ను install చేయవచ్చు. ఆ command చూపించే pathలో ఏది ఉంటే దానినే ఉపయోగించండి.

/etc/tor/torrc లో bridge ను configure చేయండి

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

ఈ ప్రతి line కు ఒక నిర్దిష్ట వైఫల్య కారణం ఉంటుంది. కాబట్టి వాటిని ఒక్కొక్కటిగా పరిశీలించండి.

BridgeRelay 1 ద్వారా tor తన descriptor ను public consensus కు బదులుగా bridge authority కు పంపుతుంది. Relay జాబితాలో కనిపించకుండా చేసేది ఈ ఒక్క line మాత్రమే.

ORPort అసలు Tor port. ఇది internet నుంచి చేరుకోగలిగేలా ఉండాలి, ఎందుకంటే tor దీనిని పరీక్షిస్తుంది. ఆ పరీక్ష విజయవంతం అయ్యే వరకు descriptor ను publish చేయడానికి tor నిరాకరిస్తుంది.

ServerTransportPlugin tor అమలు చేయాల్సిన command ను నిర్దేశిస్తుంది. tor, obfs4proxy ను child process గా ప్రారంభించి pipe ద్వారా దానితో సంభాషిస్తుంది. అందువల్ల obfs4proxy కు ప్రత్యేక service unit ఉండదు. అది ఎప్పుడూ systemctl status లో కనిపించదు.

ServerTransportListenAddr obfs4proxy వినే port ను స్థిరపరుస్తుంది. ఈ line లేకపోతే obfs4proxy startup సమయంలో అందుబాటులో ఉన్న ఖాళీ port ను ఎంచుకుంటుంది. చాలా restart ల తర్వాత వేరే port ఎంచుకుంటుంది. దాంతో మీరు ఇప్పటికే పంపిన ప్రతి bridge line, ఏదీ listening చేయని port ను సూచిస్తుంది. ఆ clients కు connection refused అవుతుంది. తరువాత అవి ప్రయత్నించడం ఆపేస్తాయి.

ExtORPort auto extended ORPort ను తెరుస్తుంది. Obfs4proxy పూర్తయిన connections ను client address తో పాటు tor కు తిరిగి అందించడానికి ఈ loopback channel ను ఉపయోగిస్తుంది. Tor Project setup guide ప్రతి bridge లో దీనిని చేర్చుతుంది. ఇది లేకపోతే transport ఆ address ను tor కు తెలియజేయలదు.

ContactInfo మరియు Nickname రెండూ public. మీరు చదివే address ను ఉపయోగించండి, ఎందుకంటే bridge లో సమస్య ఏర్పడితే Tor Project మిమ్మల్ని సంప్రదించే విధానం అదే. మీరు వివరాలు బయటపెట్టకుండా ఉండాలనుకుంటే, మీ గుర్తింపును వెల్లడించని nickname ను ఎంచుకోండి.

BridgeDistribution మీ address ను users కు ఏ distributor అందించాలో ఎంచుకుంటుంది. అంగీకరించబడే విలువలు https, email, telegram, settings, none మరియు any. మొదటి bridge కోసం any ఉపయోగించి system నిర్ణయాన్ని అనుమతించండి. మీరు స్వయంగా అందించే private bridge కోసం none ఉపయోగించండి. దీంతో address పూర్తిగా public distribution నుంచి బయట ఉంటుంది.

పోర్ట్ ఎంపిక ఎందుకు ముఖ్యమో

రెండు పోర్ట్‌లకూ 9001ను ఉపయోగించవద్దు. Tor Project దీనిని స్పష్టంగా చెబుతోంది, ఎందుకంటే 9001 సంప్రదాయ ORPort మరియు censorలు దీని కోసం internetను scan చేస్తారు. ఈ రెండు పోర్ట్‌లు ఒకదానికొకటి భిన్నంగా కూడా ఉండాలి, ఎందుకంటే tor మరియు obfs4proxy తమ తమ listenerలను bind చేస్తాయి.

obfs4 కోసం 443 అత్యంత అనుకూలమైన port. దాదాపు ప్రతి restricted networkలో outbound 443 తెరిచి ఉంటుంది. దీనికి ఉండే దీర్ఘకాలిక connection సాధారణ web sessionలా కనిపిస్తుంది. 1024 కంటే తక్కువ portకు bind చేయాలంటే ఒక అదనపు దశ అవసరం, ఎందుకంటే obfs4proxy rootగా నడవదు:

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

తెరుచుకునే ప్రతి editorలో ఈ రెండు linesను జోడించండి:

[Service]
NoNewPrivileges=no

capability ఒక్కటే సరిపోదు. systemd యొక్క NoNewPrivileges, parent processకు లేని privilegeను process పొందకుండా ఆపుతుంది. file capability కూడా అదే విధంగా పరిగణించబడుతుంది. అందువల్ల ఈ setting అమల్లో ఉన్నప్పుడు obfs4proxy 443కు bind చేయడంలో విఫలమవుతుంది.

ఆ దశను దాటేయాలనుకుంటే, సాధారణంగా కనిపించే high portను ఎంచుకుని నమోదు చేసుకోండి. ఏ portను ఎంచుకున్నా, తరువాత obfs4 portను మార్చవద్దు. bridge line address, port, fingerprint, certificateలను ఒకదానితో ఒకటి అనుసంధానిస్తుంది. అందువల్ల వినియోగదారు browserలో ఇప్పటికే ఉన్న ప్రతి copy port మారిన వెంటనే పనిచేయడం ఆపుతుంది.

రెండు firewallలలో ports తెరవండి

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

రెండు ports తప్పనిసరిగా open గా ఉండాలి. చాలా providers తమ control panelలో ufwకు తెలియని రెండవ firewallను అమలు చేస్తారు. సర్వర్‌లో rule ఉన్నా panelలో లేకపోతే, ఎప్పటికీ చేరుకోలేని మరియు descriptorను ఎప్పటికీ publish చేయని bridge ఏర్పడుతుంది. ఈ ప్రక్రియలోని ఏదైనా భాగం మీకు కొత్తగా ఉంటే, కొత్త VPSకు అవసరమైన ufw rules మరియు Linuxలో listening port అంటే ఏమిటి చూడండి. అదే సమయంలో, keys మరియు hardened sshd configతో SSHను పరిమితం చేయండి. password SSH ఉన్న సర్వర్‌లో unlisted bridge ఉన్నా, అది password SSH ఉన్న సర్వర్‌గానే ఉంటుంది.

దాన్ని ప్రారంభించి, log ను చదవండి

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 దాదాపు ఖాళీగా కనిపిస్తుంది. మీరు చూడాల్సిన log tor@default కింద ఉంటుంది.

ఇది పనిచేసిందని రెండు lines నిర్ధారిస్తాయి:

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

మొదటి line reachability test విజయవంతమైందని, descriptor bridge authority కు పంపబడిందని అర్థం. అది ఎప్పుడూ కనిపించకపోతే, internet మరియు మీ server మధ్యలోని ఏదో భాగం ORPort కు వెళ్లే traffic ను drop చేస్తోంది. రెండవ line లో మీరు configure చేసిన port కనిపించాలి. అక్కడ వేరే port కనిపిస్తే, tor ServerTransportListenAddr ను apply చేయలేదు. సాధారణ కారణం transport name సరిపోలకపోవడం. రెండు 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 user కు చెందుతుంది మరియు mode 700 లో ఉంటుంది. అందువల్ల sudo లేకపోతే Permission denied వస్తుంది. ఆ file లో ఈ ఆకృతిలో ఒక line ఉంటుంది:

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

మొదటి file లో మీ nickname మరియు bridge line లో ఉండాల్సిన identity fingerprint ఉంటాయి. రెండవ file లో hashed fingerprint ఉంటుంది. మీ bridge నడుస్తుందో లేదో, దానికి సుమారుగా ఎంతమంది clients చేరుతున్నారో చూడటానికి ఈ విలువను Relay Search లో paste చేస్తారు. ఈ రెండింటినీ పరస్పరం మార్చి ఉపయోగించలేరు. Hashed value ఉన్న bridge line, మీ bridge చూపించే identity key తో సరిపోలదు. అందువల్ల client ఇప్పుడే తెరిచిన connection ను తిరస్కరిస్తుంది.

బ్రిడ్జ్ వాస్తవంగా వినియోగదారులను ఎలా చేరుతుంది?

మీరు మీ బ్రిడ్జ్ లైన్‌ను ఎవరికీ నేరుగా ఇవ్వరు. Descriptor బ్రిడ్జ్ అధారిటీకి చేరిన తర్వాత, distribution system (BridgeDB కు వారసుడైన rdsys) మీ బ్రిడ్జ్‌ను ఒక distributor కు కేటాయిస్తుంది. వినియోగదారులు ఆ distributor ను అడిగి బ్రిడ్జ్‌లను పొందుతారు. August 2026 నాటికి మార్గాలు ఇవి:

• bridges.torproject.org/options లోని web form. ఇది captcha తర్వాత బ్రిడ్జ్ లైన్లను అందిస్తుంది.
• Gmail లేదా Riseup చిరునామా నుంచి bridges@torproject.org కు పంపే email. దానికి ప్రతిస్పందనగా బ్రిడ్జ్ లైన్లు వస్తాయి. అపరిమిత ఉచిత accounts ఉన్నవారు ప్రతి బ్రిడ్జ్‌ను enumerate చేయకుండా ఉండేందుకు ఈ provider పరిమితి ఉంది.
• Telegram bot @GetBridgesBot. /start ను పంపి, తరువాత /obfs4 లేదా /webtunnel పంపండి.
• Tor Browser లోనే Settings, తరువాత Connection కు వెళ్లి, "Request bridges" ఎంచుకోవడం. ఇది moat channel ద్వారా బ్రిడ్జ్‌లను పొందుతుంది.

Setup పూర్తయిన సుమారు మూడు గంటల తర్వాత కొత్త బ్రిడ్జ్ Relay Search లో కనిపిస్తుంది. వినియోగదారులు రావడానికి ఇంకా ఎక్కువ సమయం పడుతుంది: Tor Project స్వయంగా ఇలా పేర్కొంటుంది: "స్థిరంగా కనిపించే వినియోగదారుల సమూహం ఏర్పడటానికి అనేక రోజులు లేదా వారాలు పట్టవచ్చు." మొదటి రెండు వారాల్లో కార్యకలాపం తక్కువగా ఉండటం సాధారణం. అది లోపం కాదు.

BridgeDistribution none ను సెట్ చేస్తే ఈ పంపిణీ వ్యవస్థలన్నింటి నుంచి opt out అవుతారు. అప్పుడు బ్రిడ్జ్ లైన్ మీకు అవసరమైన వ్యక్తులకు మీరు స్వయంగా పంపాలి. ఆ సమాచారాన్ని censor చదవని channel ను ఉపయోగించండి.

ఏదైనా పనిచేయకపోతే

లాగ్‌లో self-testing line కనిపించదు. ORPort చేరుకోలేరు. మరొక యంత్రం నుంచి nc -vz your.ip 8443 తో పరీక్షించండి. కనెక్షన్ నిలిచిపోతే packets drop అవుతున్నాయని అర్థం; కాబట్టి ufw మరియు provider panel ను పరిశీలించండి. కనెక్షన్ తిరస్కరించబడితే tor port పై listening చేయడం లేదని అర్థం; కాబట్టి ss -lntp ను పరిశీలించి, config error కోసం log చదవండి.

నమోదైన transport లో మీరు ఎంచుకోని port కనిపిస్తుంది. tor ServerTransportListenAddr ను పట్టించుకోలేదు. Transport name ServerTransportPlugin లో ఉన్న పేరుతో ఖచ్చితంగా సరిపోవాలి. రెండూ obfs4 అయి ఉండాలి.

obfs4proxy port 443 పై bind కావడం లేదు. ముందుగా getcap /usr/bin/obfs4proxy తో capability ని నిర్ధారించండి. తరువాత override unit కు చేరిందో లేదో systemctl show tor@default -p NoNewPrivileges తో నిర్ధారించండి. అది NoNewPrivileges=yes ను చూపిస్తే, మీ drop-in నడుస్తున్న unit కు కాకుండా వేరే unit కు వర్తించింది.

/var/lib/tor/pt_state/ లో ఏమీ లేదు. tor transport ను ఎప్పుడూ ప్రారంభించలేదు. అంటే ServerTransportPlugin లోని path తప్పుగా ఉంది. దాన్ని command -v obfs4proxy output తో పోల్చండి.

మార్పు చేసిన తర్వాత clients కనెక్ట్ కావడం ఆగిపోయింది. address లేదా obfs4 port లో చేసిన ఏ మార్పైనా ఇప్పటికే పంపిణీ చేసిన ప్రతి bridge line ను చెల్లనిదిగా చేస్తుంది. Server యొక్క public IP కూడా మారిందో లేదో పరిశీలించండి. కొంతమంది providers వద్ద rebuild చేసినప్పుడు ఇది జరుగుతుంది.

tor అసలు start కావడం లేదు. sudo -u debian-tor tor --verify-config -f /etc/tor/torrc ను అమలు చేయండి. అది file ను parse చేసి, సమస్య ఉన్న line ను చూపిస్తుంది. నడుస్తున్న service కు ఎలాంటి మార్పు చేయదు.

FAQ

నా VPS provider Tor bridge గురించి అభ్యంతరం చెబుతుందా?

Bridge ఒక entry point. అందువల్ల మీ server నుంచి బయటకు వెళ్లే network traffic ఇతర Tor relays కు వెళ్తుంది; user ఎంచుకున్న site కు నేరుగా వెళ్లదు. ఏ web log లోనూ request source గా మీ IP address కనిపించదు. Exit relay operators ఎదుర్కొనే complaints కు ఇదే ప్రధాన కారణం. Hosting rules provider ను బట్టి మారుతాయి. కొంతమంది providers ఏ Tor service నైనా ప్రత్యేక సందర్భంగా పరిగణిస్తారు. కాబట్టి ప్రారంభించే ముందు acceptable use policy చదవండి. మీరు చదివిన address ను ContactInfo లో నమోదు చేయండి.

Tor bridge ఎంత bandwidth ఉపయోగిస్తుంది?

ప్రచురిత కనిష్ఠ పరిమాణం upload మరియు download రెండింటికీ 1 Mbit/s. Guard లేదా middle relay కు ఇది 10 Mbit/s. వాస్తవ వినియోగం దాదాపు సున్నా నుంచి ప్రారంభమవుతుంది. ఎందుకంటే distributor మీ bridge కు పంపే users traffic ను మాత్రమే bridge మోస్తుంది. ఖచ్చితమైన గరిష్ఠ పరిమితి కావాలంటే torrc లో RelayBandwidthRate మరియు RelayBandwidthBurst సెట్ చేయండి.

నా కొత్త bridge కు ఎవరూ ఎందుకు connect కాలేదు?

Bridge Relay Search లో కనిపించడానికి సుమారు మూడు గంటలు పడుతుంది. స్థిరమైన users సమూహం ఏర్పడటానికి అనేక రోజులు లేదా వారాలు పడుతుందని Tor Project guidance చెబుతోంది. Descriptor publish అయిందో లేదో తనిఖీ చేయండి. ఇది journalctl -u tor@default లోని self-testing line. Relay Search లో మీ hashed fingerprint ను వెతకండి. అలాగే BridgeDistribution, none కు సెట్ కాలేదని నిర్ధారించండి.

నేను obfs4 లేదా WebTunnel నడపాలా?

ఇది మీ మొదటి bridge అయితే obfs4 నడపండి. దీనికి ఒక VPS, రెండు ports, domain అవసరం లేదు, certificate కూడా అవసరం లేదు. Random-looking traffic కూడా block చేసే network లో WebTunnel నడపండి. దీనికి మీరు నియంత్రించే domain, నిజమైన web server, చెల్లుబాటు అయ్యే TLS certificate, కనీసం 1 GB RAM అవసరం. రెండింటినీ నడిపితే వేర్వేరు addresses ఉపయోగించండి. లేకపోతే ఒక IP block అయినప్పుడు రెండు bridges ఒకేసారి అందుబాటులో లేకుండా పోతాయి.

తరువాత obfs4 port మార్చితే ఏమి జరుగుతుంది?

ఇప్పటికే పంపిణీ చేసిన ప్రతి bridge line పనిచేయడం ఆపేస్తుంది. Bridge line address, port, fingerprint, certificate లను ఒకదానితో ఒకటి అనుసంధానిస్తుంది. అందువల్ల పాత line ఉన్న client ఏ service వినని port కు connection తెరవడానికి ప్రయత్నించి విఫలమవుతుంది. Server యొక్క public IP మారినప్పుడు కూడా ఇదే జరుగుతుంది. Setup సమయంలో port ఎంచుకుని, తరువాత దాన్ని మార్చకుండా ఉంచండి.