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

Tor bridge అంటే ఏమిటి, అది ఎందుకు ఉంది

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

List లో లేని address అనేది పరిష్కారంలో సగం మాత్రమే. Deep packet inspection (DPI) traffic యొక్క address కంటే content ఆధారంగా దాన్ని classify చేస్తుంది. ఇది 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 కు ఇది అనుకూలం. Web browsing మినహా చాలా traffic ను అనుమతించని country లో కూడా HTTPS సాధారణంగా అనుమతించబడుతుంది.
• Snowflake వేరే రకమైన సహకారం. Volunteers తక్కువకాలం మాత్రమే పనిచేసే WebRTC proxies ను నడుపుతారు. అందువల్ల entry points నిరంతరం మారుతాయి. Censor block చేయగల stable address ఉండదు. దీని కోసం మీరు bridge ను operate చేయరు. మీరు proxy ను నడుపుతారు. దీనికి fixed address అవసరం లేదు.

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

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

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

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

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

Tor Project repository నుండి Tor ను ఇన్‌స్టాల్ చేయండి

Distribution packages ఆలస్యంగా అందుబాటులోకి వస్తాయి. Bridge అనేది ఎప్పటికప్పుడు తాజా స్థితిలో ఉండాల్సిన security software. ముందుగా ప్రాజెక్ట్‌దైన 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

మీ codename కోసం repository వద్ద Release file లేదని apt update చూపిస్తే, Tor Project ఆ release కు packages అందించదు. /etc/apt/sources.list.d/tor.sources ను తొలగించి, మళ్లీ sudo apt update ను అమలు చేయండి. తరువాత మీ distribution అందించే tor package ను ఇన్‌స్టాల్ చేయండి. దిగువన ఉన్న దశలన్నీ అలాగే ఉంటాయి.

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

command -v obfs4proxy || command -v lyrebird

Upstream ప్రాజెక్ట్ పేరును 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

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

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

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

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

ServerTransportListenAddr obfs4proxy వినే port ను స్థిరంగా నిర్దేశిస్తుంది. ఈ లైన్ లేకపోతే startup సమయంలో obfs4proxy ఖాళీగా ఉన్న port ను ఎంచుకుంటుంది. చాలా restarts తర్వాత వేరే port ఎంచుకుంటుంది. అప్పుడు మీరు ఇప్పటికే పంపిణీ చేసిన ప్రతి bridge line, ఏదీ వినని 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 మిమ్మల్ని సంప్రదించేది ఈ address ద్వారానే. మీరు వివరాలు వెల్లడించకుండా ఉండాలనుకుంటే, మిమ్మల్ని గుర్తించలేని nickname ను ఎంచుకోండి.

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

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

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

obfs4 కోసం 443 అత్యంత బలమైన పోర్ట్. దాదాపు ప్రతి పరిమిత 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‌కు లేని privilege‌ను process పొందకుండా నిరోధిస్తుంది. File capability కూడా అదే తరహా privilege కాబట్టి, ఈ setting అమల్లో ఉన్నంతకాలం obfs4proxy 443కు bind అవ్వదు.

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

రెండు firewallsలో portsను తెరవండి

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

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

ప్రారంభించి, తర్వాత 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 ను వర్తింపజేయలేదు. సాధారణ కారణం 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 లో bridge line లో ఉండాల్సిన మీ nickname మరియు 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. దానికి ప్రత్యుత్తరంగా బ్రిడ్జ్ లైన్‌లు వస్తాయి. అపరిమిత ఉచిత ఖాతాల ద్వారా ఒక్క censor ప్రతి బ్రిడ్జ్‌ను గుర్తించకుండా జాబితా చేయగల అవకాశం ఉండటంతో ఈ provider పరిమితి ఉంది.
• Telegram bot @GetBridgesBot. /start పంపిన తర్వాత /obfs4 లేదా /webtunnel పంపండి.
• Tor Browser లో Settings, ఆపై Connection కింద ఉన్న "Request bridges" ఎంపిక. ఇది moat channel ద్వారా బ్రిడ్జ్‌లను పొందుతుంది.

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

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

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

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

మీరు ఎంచుకోని port ను registered transport చూపిస్తోంది. 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 ను run చేయండి. ఇది file ను parse చేసి, అభ్యంతరం ఉన్న line ను చూపిస్తుంది. నడుస్తున్న service ను మాత్రం మార్చదు.

FAQ

నా VPS provider Tor bridge గురించి అభ్యంతరం వ్యక్తం చేస్తారా?

Bridge ఒక entry point. అందువల్ల మీ server నుంచి బయటకు వెళ్లే traffic ఇతర Tor relays కు వెళ్తుంది; user ఎంచుకున్న site కు నేరుగా వెళ్లదు. Request source గా మీ IP address ఎవరి web log లోనూ కనిపించదు. 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. వాస్తవ వినియోగం దాదాపు zero నుంచి ప్రారంభమవుతుంది. ఎందుకంటే distributor మీ bridge కు పంపే users traffic ను మాత్రమే అది మోస్తుంది. గరిష్ఠ పరిమితిని ఖచ్చితంగా నిర్ణయించాలనుకుంటే torrc లో RelayBandwidthRate మరియు RelayBandwidthBurst సెట్ చేయండి.

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

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

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

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

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

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