VPS पर obfs4 Tor bridge कैसे सेटअप करें

Tor bridge क्या है और यह क्यों मौजूद है

Tor bridge, Tor नेटवर्क में प्रवेश का एक ऐसा बिंदु है जिसका पता सार्वजनिक relay सूची में प्रकाशित नहीं होता है। उस सूची को, जिसे consensus कहा जाता है, एक हस्ताक्षरित दस्तावेज़ माना जाता है जिसे कोई भी डाउनलोड कर सकता है, और सेंसर भी इसे डाउनलोड कर लेते हैं। इससे Tor को ब्लॉक करना बहुत आसान है: consensus प्राप्त करें, और फिर उसमें मौजूद हर पते को बॉर्डर पर ड्रॉप कर दें। Bridges इसलिए मौजूद हैं क्योंकि प्रकाशित सूची ही सबसे कमज़ोर कड़ी है। Bridge के पते एक बार में कुछ ही दिए जाते हैं, ताकि कोई भी एक अनुरोध पूरी सूची को उजागर न कर सके।

एक असूचीबद्ध (unlisted) पता समाधान का केवल आधा हिस्सा है। Deep packet inspection (DPI), जो traffic को उसके पते के बजाय उसकी सामग्री के आधार पर वर्गीकृत करता है, Tor कनेक्शन को उसके TLS (transport layer security) हैंडशेक के स्वरूप से पहचान लेता है। बिना सूची वाला सेंसर भी यह देख सकता है कि "यह Tor जैसा दिखता है" और कनेक्शन को ड्रॉप कर सकता है। एक pluggable transport इस संकेत को हटा देता है। यह client साइड पर Tor स्ट्रीम को किसी अन्य चीज़ में लपेट (wrap) देता है, और आपका bridge उसे खोल (unwrap) देता है।

obfs4 वह transport है जिसे अधिकांश bridges चलाते हैं। यह स्ट्रीम को ऐसे बाइट्स में बदल देता है जिनमें कोई हेडर और कोई निश्चित हैंडशेक नहीं होता, इसलिए DPI के पास मिलान करने के लिए कोई पैटर्न नहीं बचता। यह client को प्रमाणित भी करता है। bridge लाइन के अंदर का cert= मान एक ऐसी key है जिसे client को यह साबित करना होता है कि वह उसके पास है, इससे पहले कि bridge कोई उत्तर दे। यह active probing को विफल कर देता है: एक सेंसर जो यह परीक्षण करने के लिए आपके पते से जुड़ता है कि क्या वह Tor बोलता है, उसे कोई उत्तर नहीं मिलता और वह कुछ भी नहीं जान पाता।

आपको कौन सा pluggable transport चलाना चाहिए?

• obfs4 के लिए एक VPS, दो TCP ports की आवश्यकता होती है और किसी domain name की जरूरत नहीं होती। यह सबसे आसान उपयोगी चीज है जिसे आप चला सकते हैं, और यही इस guide का विषय है।
• WebTunnel कनेक्शन को एक वास्तविक website के सामान्य HTTPS traffic के भीतर छिपा देता है। Tor Project इसकी आवश्यकताओं को इस प्रकार सूचीबद्ध करता है: एक static IPv4 address, एक domain जिस पर आपका नियंत्रण हो, एक कार्यशील web server जैसे कि NGINX या Apache, एक valid TLS certificate, और कम से कम 1 GB RAM (4 GB की सिफारिश की जाती है)। यह उन networks के लिए उपयुक्त है जहाँ यादृच्छिक दिखने वाला traffic ही संदिग्ध होता है, क्योंकि जो देश web browsing से अधिक की अनुमति नहीं देते, वे भी HTTPS की अनुमति देते हैं।
• Snowflake एक अलग प्रकार का योगदान है। स्वयंसेवक अल्पकालिक WebRTC proxies चलाते हैं, इसलिए entry points लगातार बदलते रहते हैं और censor के लिए ब्लॉक करने हेतु कोई स्थिर पता नहीं होता। आप इसके लिए bridge संचालित नहीं करते हैं। आप एक proxy चलाते हैं, और इसे किसी fixed address की आवश्यकता नहीं होती।

obfs4 से शुरुआत करें। आप बाद में किसी दूसरे address पर WebTunnel bridge जोड़ सकते हैं: एक ही IP पर दोनों को चलाने का अर्थ है कि एक ही blocked address दोनों को बंद कर देगा।

एक ब्रिज चलाने की लागत क्या है?

[
  {
    "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 एक ब्रिज के लिए कम से कम 1 Mbit/s की अपस्ट्रीम और डाउनस्ट्रीम बैंडविड्थ की अपेक्षा करता है। एक गार्ड या मिडिल रिले के लिए 10 Mbit/s की मांग की जाती है, जबकि 16 Mbit/s की अनुशंसा की जाती है। ये प्रकाशित आवश्यकताएं हैं, न कि मापन। एक नया ब्रिज आमतौर पर हफ्तों तक अपनी न्यूनतम सीमा से काफी नीचे रहता है। वही आवश्यकता पृष्ठ एक रिले के लिए प्रति माह कम से कम 100 GByte आउटबाउंड ट्रैफ़िक मांगता है, जिसे सबसे छोटे प्लान भी पूरा कर लेते हैं, इसलिए किसी भी बड़े प्लान को चुनने से पहले एक छोटा VPS प्रति माह वास्तव में कितना खर्च होता है पढ़ें।

दुरुपयोग (abuse) की संभावना कम है, और यही वह हिस्सा है जिसे लोग गलत समझते हैं। एक ब्रिज पहला हॉप होता है। आपके सर्वर से निकलने वाला ट्रैफ़िक किसी अन्य Tor रिले पर जाता है, न कि उस वेबसाइट पर जिसे उपयोगकर्ता ने चुना है। आपका IP पता कभी भी किसी अजनबी के वेब लॉग में अनुरोध के स्रोत के रूप में दिखाई नहीं देता है, इसलिए एग्जिट रिले ऑपरेटरों को मिलने वाले शिकायत ईमेल यहाँ नहीं आते हैं। फिर भी अपने प्रदाता की 'acceptable use policy' की जाँच करें, क्योंकि कुछ होस्ट किसी भी Tor सेवा को विशेष श्रेणी में रखते हैं।

एक काम जो न करें: किसी मौजूदा पब्लिक रिले को उसी पते पर ब्रिज में न बदलें। इस मामले के लिए Tor Project की सलाह है कि "IP पता, नाम और फिंगरप्रिंट" बदलें, क्योंकि पुराना पता पहले से ही उस कंसेंसस में होता है जिसे सेंसर डाउनलोड करते हैं। जो ब्रिज पिछले सप्ताह एक पब्लिक रिले था, वह ऐसा ब्रिज है जो पहले से ही ब्लॉकलिस्ट में है।

स्पीड से ज्यादा अपटाइम मायने रखता है। रिले की आवश्यकताओं में कहा गया है कि "यदि आपका रिले दिन में 2 घंटे से अधिक नहीं चल रहा है, तो इसकी उपयोगिता सीमित है", और इस मामले में एक ब्रिज की स्थिति रिले से भी खराब होती है, क्योंकि प्रत्येक क्लाइंट के पास एक पता होता है और कोई बैकअप नहीं होता है। एक रीस्टार्ट उस पर मौजूद हर उपयोगकर्ता का कनेक्शन काट देता है। obfs4 पोर्ट के लिए Uptime Kuma में TCP पोर्ट चेक सेट करें ताकि आपको उस दिन पता चल जाए जब यह जवाब देना बंद कर दे।

Tor Project repository से Tor इंस्टॉल करें

Distribution packages पुराने होते हैं, और bridge एक ऐसी security software है जिसे हमेशा अद्यतित (current) रहना चाहिए। सबसे पहले 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 यह रिपोर्ट करता है कि repository में आपके codename के लिए कोई Release file नहीं है, तो इसका मतलब है कि Tor Project उस release को support नहीं करता है। /etc/apt/sources.list.d/tor.sources को delete करें, sudo apt update को फिर से चलाएँ, और अपनी distribution द्वारा प्रदान किया गया tor package इंस्टॉल करें। नीचे दी गई बाकी प्रक्रिया समान है।

obfs4proxy package स्वयं Debian और Ubuntu से आता है (अगस्त 2026 तक, Debian 13 में version 0.0.14)। पुष्टि करें कि binary कहाँ इंस्टॉल हुई है, क्योंकि इसका path config में डालना होगा:

command -v obfs4proxy || command -v lyrebird

Upstream ने project का नाम बदलकर lyrebird कर दिया है, इसलिए हो सकता है कि नया package इसके बजाय /usr/bin/lyrebird इंस्टॉल करे। वह path उपयोग करें जो वह command print करती है।

/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, tor को निर्देश देता है कि वह अपना डिस्क्रिप्टर पब्लिक कंसेंसस के बजाय ब्रिज अथॉरिटी को भेजे। यही वह एकमात्र लाइन है जो रिले को अनलिस्टेड (unlisted) बनाती है।

ORPort वास्तविक Tor पोर्ट है। इसे इंटरनेट से एक्सेस किया जा सकना चाहिए, क्योंकि tor इसका परीक्षण करता है और जब तक यह परीक्षण पास नहीं हो जाता, तब तक डिस्क्रिप्टर प्रकाशित करने से इनकार कर देता है।

ServerTransportPlugin, tor को चलाने के लिए कमांड देता है। tor, obfs4proxy को एक चाइल्ड प्रोसेस के रूप में शुरू करता है और एक पाइप के माध्यम से उससे बात करता है, इसलिए obfs4proxy की अपनी कोई सर्विस यूनिट नहीं होती और यह कभी भी systemctl status में दिखाई नहीं देता है।

ServerTransportListenAddr उस पोर्ट को निर्धारित करता है जिस पर obfs4proxy लिसन (listen) करता है। यदि आप इस लाइन को छोड़ देते हैं, तो obfs4proxy स्टार्टअप पर एक फ्री पोर्ट चुन लेता है, और अधिकांश रीस्टार्ट के बाद एक अलग पोर्ट चुनता है। इस स्थिति में, आपके द्वारा पहले से दिए गए सभी ब्रिज लाइन ऐसे पोर्ट की ओर इशारा करेंगे जहाँ कोई सर्विस लिसन नहीं कर रही है। उन क्लाइंट्स को कनेक्शन रिफ्यूज्ड (refused) का एरर मिलेगा और वे प्रयास करना बंद कर देंगे।

ExtORPort auto, एक्सटेंडेड ORPort को खोलता है। यह एक लूपबैक चैनल है जिसका उपयोग obfs4proxy, क्लाइंट के एड्रेस के साथ पूर्ण कनेक्शन को वापस tor को सौंपने के लिए करता है। The Tor Project की सेटअप गाइड में इसे हर ब्रिज पर शामिल किया गया है, क्योंकि इसके बिना ट्रांसपोर्ट उस एड्रेस को tor को रिपोर्ट नहीं कर सकता है।

ContactInfo और Nickname दोनों पब्लिक हैं। एक ऐसा ईमेल एड्रेस उपयोग करें जिसे आप नियमित रूप से चेक करते हैं, क्योंकि इसी के माध्यम से The Tor Project आपसे किसी खराब ब्रिज के बारे में संपर्क करता है। एक ऐसा निकनेम चुनें जो आपकी पहचान उजागर न करे, यदि आप गुमनाम रहना चाहते हैं।

BridgeDistribution यह चुनता है कि कौन सा डिस्ट्रीब्यूटर आपका एड्रेस उपयोगकर्ताओं को देगा। स्वीकार्य मान https, email, telegram, settings, none और any हैं। पहले ब्रिज के लिए any का उपयोग करें और सिस्टम को निर्णय लेने दें। यदि आप स्वयं किसी को ब्रिज एड्रेस देना चाहते हैं, तो none का उपयोग करें, जो एड्रेस को पूरी तरह से पब्लिक डिस्ट्रीब्यूशन से बाहर रखता है।

पोर्ट का चयन क्यों महत्वपूर्ण है

दोनों पोर्ट्स के लिए 9001 का उपयोग न करें। The Tor Project सीधे तौर पर ऐसा करने से मना करता है, क्योंकि 9001 पारंपरिक ORPort है और सेंसर इसे इंटरनेट पर स्कैन करते हैं। दोनों पोर्ट्स एक-दूसरे से अलग होने चाहिए, क्योंकि tor और obfs4proxy दोनों अपने स्वयं के listener bind करते हैं।

सबसे प्रभावी obfs4 पोर्ट 443 है। लगभग हर प्रतिबंधित नेटवर्क पर आउटबाउंड 443 खुला रहता है, और इससे बना लंबे समय तक चलने वाला कनेक्शन एक सामान्य वेब सत्र जैसा दिखता है। 1024 से नीचे के पोर्ट को bind करने के लिए एक अतिरिक्त चरण की आवश्यकता होती है, क्योंकि 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 किसी प्रक्रिया को ऐसी कोई भी privilege प्राप्त करने से रोकता है जो उसके parent के पास नहीं थी, और file capability बिल्कुल वही है, इसलिए जब यह सेटिंग चालू रहती है तो obfs4proxy 443 को bind करने में विफल रहता है।

यदि आप उस चरण को छोड़ना चाहते हैं, तो कोई सामान्य हाई पोर्ट चुनें और उसे लिख लें। आप जो भी चुनें, obfs4 पोर्ट को बाद में न बदलें। एक bridge line एड्रेस, पोर्ट, फिंगरप्रिंट और सर्टिफिकेट को एक साथ जोड़ती है, इसलिए जैसे ही पोर्ट बदलता है, उपयोगकर्ता के ब्राउज़र में मौजूद हर कॉपी काम करना बंद कर देती है।

दोनों फायरवॉल पर पोर्ट खोलें

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

दोनों पोर्ट खुले होने चाहिए। अधिकांश प्रदाता अपने कंट्रोल पैनल में एक दूसरा फायरवॉल भी चलाते हैं जिसके बारे में ufw को कोई जानकारी नहीं होती। जो नियम सर्वर पर तो मौजूद है लेकिन पैनल में नहीं, वह एक ऐसा ब्रिज बनाता है जो कभी भी एक्सेस नहीं हो पाता और न ही कोई डिस्क्रिप्टर पब्लिश करता है। यदि इनमें से कोई भी हिस्सा आपके लिए नया है, तो एक नए VPS के लिए आवश्यक ufw नियम और Linux पर लिसनिंग पोर्ट वास्तव में क्या होता है में इसकी जानकारी दी गई है। जब आप वहां हों, तो SSH को कीज़ और एक हार्डन्ड sshd कॉन्फ़िगरेशन के साथ सुरक्षित करें। पासवर्ड SSH वाले सर्वर पर एक अनलिस्टेड ब्रिज का मतलब अभी भी पासवर्ड SSH वाला सर्वर ही है।

इसे start करें, फिर 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 के अंतर्गत होता है।

दो पंक्तियाँ दर्शाती हैं कि यह सफल रहा:

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 test सफल रही और descriptor bridge authority के पास चला गया। यदि यह कभी दिखाई नहीं देता है, तो internet और आपके server के बीच कुछ ऐसा है जो ORPort के traffic को रोक (drop) रहा है। दूसरी पंक्ति में आपके द्वारा 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> को अपने सर्वर के public address से, <PORT> को ORPort के बजाय obfs4 port से, और <FINGERPRINT> को उस identity fingerprint से बदलें जिसे tor ने अपनी data directory में लिखा है:

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

पहली file में आपका nickname और वह identity fingerprint होता है जो bridge line में होना चाहिए। दूसरी file में hashed fingerprint होता है, जिसे आप यह देखने के लिए Relay Search में paste करते हैं कि क्या आपकी bridge चल रही है और लगभग कितने clients उस तक पहुँच रहे हैं। ये दोनों एक-दूसरे के स्थान पर इस्तेमाल नहीं किए जा सकते। hashed value वाली bridge line उस identity key से मेल नहीं खाती जिसे आपकी bridge प्रस्तुत करती है, इसलिए client उस connection को अस्वीकार कर देता है जिसे उसने अभी-अभी खोला है।

एक bridge वास्तव में उपयोगकर्ताओं तक कैसे पहुँचता है?

आप अपनी bridge line किसी को भी खुद नहीं देते हैं। एक बार जब descriptor bridge authority तक पहुँच जाता है, तो distribution system (rdsys, जो BridgeDB का उत्तराधिकारी है) आपकी bridge को एक distributor को सौंप देता है, और उपयोगकर्ता उस distributor से bridge मांगते हैं। अगस्त 2026 तक, मार्ग इस प्रकार हैं:

• bridges.torproject.org/options पर वेब फॉर्म, जो captcha के बाद bridge lines प्रदान करता है।
• Gmail या Riseup पते से bridges@torproject.org पर ईमेल, जो bridge lines के साथ उत्तर देता है। प्रदाता पर यह प्रतिबंध इसलिए है क्योंकि असीमित मुफ्त खातों के माध्यम से कोई सेंसर हर bridge की सूची बना सकता है।
• Telegram bot @GetBridgesBot। /start भेजें, फिर /obfs4 या /webtunnel भेजें।
• स्वयं Tor Browser, Settings के अंतर्गत Connection में, जहाँ "Request bridges" उन्हें moat channel के माध्यम से प्राप्त करता है।

एक नई bridge सेटअप के लगभग तीन घंटे बाद Relay Search में दिखाई देती है। उपयोगकर्ताओं को आने में काफी अधिक समय लगता है: Tor Project के अपने शब्दों में, "उपयोगकर्ताओं का एक स्थिर समूह देखने में आपको कई दिन या सप्ताह लग सकते हैं।" शुरुआती दो सप्ताह का शांत रहना सामान्य है, यह कोई त्रुटि नहीं है।

BridgeDistribution none सेट करने से आप इस पूरी प्रक्रिया से बाहर हो जाते हैं। इसके बाद bridge line पूरी तरह से आपकी होती है, जिसे आप उन लोगों को भेज सकते हैं जिन्हें इसकी आवश्यकता है, ऐसे माध्यम से जिसे सेंसर नहीं पढ़ रहा है।

जब कुछ काम न करे

लॉग में कोई self-testing लाइन नहीं है। ORPort तक पहुँचा नहीं जा सकता। इसे किसी अन्य मशीन से nc -vz your.ip 8443 का उपयोग करके टेस्ट करें। यदि यह hang हो जाता है, तो इसका मतलब है कि packets drop हो रहे हैं, इसलिए ufw और provider के पैनल की जाँच करें। यदि connection refuse होता है, तो इसका मतलब है कि tor listen नहीं कर रहा है, इसलिए ss -lntp की जाँच करें और config error के लिए लॉग पढ़ें।

registered transport में वह port दिखाई दे रहा है जिसे आपने नहीं चुना था। tor ने ServerTransportListenAddr को अनदेखा कर दिया। transport का नाम ServerTransportPlugin में दिए गए नाम से बिल्कुल मेल खाना चाहिए, और दोनों obfs4 होने चाहिए।

obfs4proxy port 443 पर 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 में दिया गया path गलत है। इसकी तुलना command -v obfs4proxy के output से करें।

बदलाव के बाद clients ने connect करना बंद कर दिया। address या obfs4 port में किया गया कोई भी बदलाव पहले से वितरित की गई हर bridge लाइन को अमान्य कर देता है। जाँचें कि क्या सर्वर का public IP भी बदल गया है, जो कुछ providers के साथ rebuild करने पर होता है।

tor बिल्कुल भी शुरू नहीं हो रहा है। sudo -u debian-tor tor --verify-config -f /etc/tor/torrc चलाएँ। यह फाइल को parse करता है, उस लाइन को प्रिंट करता है जिस पर उसे आपत्ति है, और चल रही service को प्रभावित नहीं करता है।

FAQ

क्या मेरा VPS प्रदाता Tor bridge के बारे में शिकायत करेगा?

एक bridge एक entry point है, इसलिए आपके सर्वर से निकलने वाला traffic अन्य Tor relays तक जाता है, न कि उस साइट तक जिसे उपयोगकर्ता ने चुना है। आपका IP address किसी के भी web log में request के स्रोत के रूप में दिखाई नहीं देता है, और यही वह कारण है जिससे exit relay operators को शिकायतें मिलती हैं। होस्टिंग के नियम अलग-अलग हो सकते हैं, और कुछ प्रदाता किसी भी Tor service को एक विशेष मामले के रूप में देखते हैं, इसलिए शुरू करने से पहले acceptable use policy को पढ़ें और एक ऐसा पता डालें जिसे आप ContactInfo में पढ़ते हैं।

एक Tor bridge कितनी bandwidth का उपयोग करता है?

प्रकाशित न्यूनतम सीमा 1 Mbit/s अप और डाउन है, जबकि guard या middle relay के लिए यह 10 Mbit/s है। वास्तविक उपयोग शून्य के करीब से शुरू होता है, क्योंकि आपका bridge केवल उन उपयोगकर्ताओं के लिए traffic ले जाता है जिन्हें एक distributor इसे भेजता है। यदि आप एक कठोर सीमा (hard ceiling) चाहते हैं, तो torrc में RelayBandwidthRate और RelayBandwidthBurst सेट करें।

मेरे नए bridge से कोई क्यों नहीं जुड़ा है?

एक bridge को Relay Search में दिखाई देने में लगभग तीन घंटे लगते हैं, और Tor Project का मार्गदर्शन यह है कि उपयोगकर्ताओं का एक स्थिर समूह बनने में कई दिन या सप्ताह लगते हैं। जाँचें कि क्या descriptor प्रकाशित हो गया है, जो journalctl -u tor@default में self-testing लाइन है, Relay Search में अपने hashed fingerprint को देखें, और पुष्टि करें कि BridgeDistribution को none पर सेट नहीं किया गया है।

क्या मुझे obfs4 चलाना चाहिए या WebTunnel?

यदि यह आपका पहला bridge है तो obfs4 चलाएं: एक VPS, दो ports, कोई domain नहीं, कोई certificate नहीं। WebTunnel तब चलाएं जब random दिखने वाला traffic खुद ही block हो, क्योंकि इसके लिए एक domain जिसे आप नियंत्रित करते हैं, एक वास्तविक web server, एक valid TLS certificate, और कम से कम 1 GB RAM की आवश्यकता होती है। यदि आप दोनों चलाते हैं तो उन्हें अलग-अलग addresses पर रखें, क्योंकि एक block हुआ IP अन्यथा एक साथ दो bridges को हटा देगा।

यदि मैं बाद में obfs4 port बदल दूँ तो क्या होगा?

वितरित की गई हर bridge लाइन काम करना बंद कर देगी। एक bridge लाइन address, port, fingerprint और certificate को एक साथ जोड़ती है, इसलिए पुरानी लाइन रखने वाला client एक ऐसे port पर connection खोलने की कोशिश करता है जहाँ कुछ भी listen नहीं कर रहा होता है और वह हार मान लेता है। यही बात तब भी लागू होती है जब सर्वर का public IP बदल जाता है। सेटअप के दौरान port चुनें और उसे न बदलें।