VPS वर obfs4 Tor bridge कसा चालवायचा

Tor bridge म्हणजे काय आणि ते का अस्तित्वात आहे

Tor bridge हा Tor नेटवर्कमध्ये प्रवेश करण्याचा असा बिंदू आहे ज्याचा address सार्वजनिक relay list मध्ये प्रकाशित केलेला नसतो. या list ला consensus म्हणतात. ते कोणीही download करू शकणारे signed document आहे आणि censor देखील ते download करू शकतो. त्यावरून Tor block करण्यासाठी एक दुपार पुरेशी असते: consensus मिळवा आणि त्यातील प्रत्येक address सीमेवर drop करा. Published list हा कमकुवत दुवा असल्यामुळे bridges अस्तित्वात आहेत. Bridge addresses एकावेळी काही मोजकेच दिले जातात. त्यामुळे एकाही request मधून संपूर्ण संच मिळत नाही.

Unlisted address हा उत्तराचा केवळ एक भाग आहे. Deep packet inspection (DPI) हे address ऐवजी content नुसार traffic चे वर्गीकरण करते. ते TLS (transport layer security) handshake च्या रचनेवरून Tor connection ओळखते. List नसलेला censor देखील "हे Tor सारखे दिसते" असे ओळखून connection drop करू शकतो. Pluggable transport हा संकेत काढून टाकतो. Client side वर तो Tor stream ला दुसऱ्या स्वरूपात लपेटतो आणि तुमचा bridge ते पुन्हा उघडतो.

obfs4 हा बहुतेक bridges वर चालणारा transport आहे. तो stream ला header नसलेल्या आणि fixed handshake नसलेल्या bytes मध्ये रूपांतरित करतो. त्यामुळे DPI कडे जुळवण्यासाठी कोणताही pattern राहत नाही. तो client चे authentication देखील करतो. Bridge line मधील cert= value ही अशी key आहे की bridge उत्तर देण्यापूर्वी client कडे ती असल्याचे client ने सिद्ध करणे आवश्यक असते. त्यामुळे active probing निष्फळ ठरते: Tor बोलते का हे तपासण्यासाठी censor तुमच्या address ला connect झाला, तरी त्याला कोणतेही उत्तर मिळत नाही आणि त्याला काहीही माहिती मिळत नाही.

कोणता pluggable transport चालवावा?

• obfs4 साठी एक VPS, दोन TCP ports आणि domain name आवश्यक आहे. तुम्ही चालवू शकणाऱ्या उपयुक्त पर्यायांपैकी हा सर्वात सोपा आहे आणि या मार्गदर्शकाचा विषयही हाच आहे.
• WebTunnel connection ला प्रत्यक्ष वेबसाइटकडे जाणाऱ्या सामान्य HTTPS traffic मध्ये लपवतो. Tor Project नुसार यासाठी static IPv4 address, तुमच्या नियंत्रणाखालील domain, NGINX किंवा Apache सारखा कार्यरत web server, valid TLS certificate आणि किमान 1 GB RAM आवश्यक आहे; 4 GB RAM ची शिफारस केली जाते. random-looking traffic स्वतःच संशयास्पद मानला जातो अशा networks साठी हा योग्य आहे. कारण एखादा देश web browsing व्यतिरिक्त फारच कमी traffic परवानगी देत असला, तरी HTTPS ला परवानगी देतो.
• Snowflake हा वेगळ्या प्रकारचा contribution आहे. Volunteers अल्पकाळासाठी WebRTC proxies चालवतात. त्यामुळे entry points सतत बदलत राहतात आणि censor ला block करता येईल असा stable address उपलब्ध राहत नाही. यासाठी तुम्ही 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 upstream आणि downstream bandwidth मागतो. guard किंवा middle relay साठी 10 Mbit/s आवश्यक असून 16 Mbit/s ची शिफारस केली आहे. या प्रकाशित आवश्यकता आहेत; ही मोजमापे नाहीत. नवीन ब्रिज साधारणपणे अनेक आठवडे त्याच्या किमान मर्यादेपेक्षा खूप कमी bandwidth वापरतो. त्याच requirements page वर relay साठी दरमहा किमान 100 GByte outbound traffic मागितले आहे. सर्वात स्वस्त plans मध्ये ते आधीच समाविष्ट असते. त्यामुळे मोठे आकारमान ठरवण्यापूर्वी लहान VPS ची प्रतिमहिना प्रत्यक्ष किंमत किती असते ते पहा.

abuse surface लहान असते. याबाबत लोकांकडून नेमकी हीच चूक होते. ब्रिज हा पहिला hop असतो. तुमच्या server मधून बाहेर जाणारा traffic दुसऱ्या Tor relay कडे जातो; user ने निवडलेल्या website कडे थेट जात नाही. तुमचा IP address कोणत्याही अनोळखी व्यक्तीच्या web log मध्ये request चा source म्हणून दिसत नाही. त्यामुळे exit relay operators हाताळतात ते complaint mail येथे येत नाही. तरीही तुमच्या provider चे acceptable use policy तपासा, कारण काही hosts कोणत्याही Tor service ला special case मानतात.

एक गोष्ट करू नका: विद्यमान public relay ला त्याच address वर bridge मध्ये रूपांतरित करू नका. त्या परिस्थितीसाठी Tor Project चा सल्ला म्हणजे "IP address, name and fingerprint" बदलणे. कारण जुना address censor डाउनलोड करत असलेल्या consensus मध्ये आधीच आहे. मागील आठवड्यात public relay असलेला bridge blocklist वर आधीच असतो.

वेगापेक्षा uptime अधिक महत्त्वाचा आहे. Relay requirements मध्ये म्हटले आहे की "if your relay is not running for more than 2 hours a day its usefulness is limited". या बाबतीत bridge relay पेक्षा अधिक अडचणीत असतो, कारण प्रत्येक client कडे एकच address असतो आणि fallback नसतो. Restart झाल्यावर त्यावरील प्रत्येक user चे connection तुटते. obfs4 port साठी Uptime Kuma मध्ये TCP port check सेट करा, म्हणजे तो प्रतिसाद देणे थांबवतो त्या दिवशीच तुम्हाला कळेल.

Tor Project repository मधून Tor install करा

Distribution packages मागे राहतात आणि bridge हे सध्याच्या आवृत्तीवर असावे असे सुरक्षा-सॉफ्टवेअर आहे. आधी प्रकल्पाचे स्वतःचे 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 ला support करत नाही. /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 configuration मध्ये द्यावा लागेल:

command -v obfs4proxy || command -v lyrebird

Upstream ने प्रकल्पाचे नाव lyrebird असे बदलले आहे. त्यामुळे नवीन package त्याऐवजी /usr/bin/lyrebird install करू शकते. त्या 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 tor ला त्याचा descriptor public consensus ऐवजी bridge authority कडे पाठवण्यास सांगते. Relay सूचीबाहेर ठेवण्याचे काम ही एकच ओळ करते.

ORPort हा वास्तविक Tor पोर्ट आहे. तो इंटरनेटवरून पोहोचण्यायोग्य असणे आवश्यक आहे, कारण tor त्याची चाचणी करते. ही चाचणी यशस्वी होईपर्यंत tor descriptor प्रकाशित करण्यास नकार देते.

ServerTransportPlugin tor ने चालवायची command निर्दिष्ट करते. tor child process म्हणून obfs4proxy सुरू करते आणि pipe द्वारे त्याच्याशी संवाद साधते. त्यामुळे obfs4proxy ची स्वतंत्र service unit नसते आणि ते systemctl status मध्ये कधीही दिसत नाही.

ServerTransportListenAddr obfs4proxy कोणत्या पोर्टवर listening करेल हे निश्चित करते. ही ओळ वगळल्यास obfs4proxy startup वेळी मोकळा पोर्ट निवडते. बहुतेक restart नंतर तो वेगळा पोर्ट निवडतो. त्यामुळे तुम्ही आधी दिलेल्या प्रत्येक bridge line मध्ये listening नसलेल्या पोर्टचा निर्देश राहतो. त्या 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 पोहोचवेल हे निवडते. स्वीकारली जाणारी values आहेत: https, email, telegram, settings, none आणि any. पहिल्या bridge साठी any वापरा आणि system ला निर्णय घेऊ द्या. स्वतः वितरित केलेल्या private bridge साठी none वापरा. यामुळे address पूर्णपणे public distribution च्या बाहेर राहतो.

पोर्टची निवड महत्त्वाची का आहे

दोन्ही पोर्टसाठी 9001 वापरू नका. Tor Project याबाबत स्पष्ट सूचना देते, कारण 9001 हा पारंपरिक ORPort आहे आणि सेन्सर त्यासाठी इंटरनेट स्कॅन करतात. दोन्ही पोर्ट एकमेकांपेक्षा वेगळेही असले पाहिजेत, कारण tor आणि obfs4proxy स्वतःचे listener स्वतंत्रपणे bind करतात.

obfs4 साठी सर्वात योग्य पोर्ट 443 आहे. जवळजवळ प्रत्येक प्रतिबंधित नेटवर्कवर outbound 443 खुले असते आणि त्यावरचे दीर्घकाळ चालणारे कनेक्शन सामान्य web session सारखे दिसते. 1024 पेक्षा कमी पोर्टवर bind करण्यासाठी एक अतिरिक्त पायरी आवश्यक आहे, कारण obfs4proxy root म्हणून चालत नाही:

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

प्रत्येक editor मध्ये उघडलेल्या फाइलमध्ये या दोन ओळी जोडा:

[Service]
NoNewPrivileges=no

ही capability एकटी पुरेशी नाही. systemd चे NoNewPrivileges एखाद्या प्रक्रियेला तिच्या parent कडे नसलेला कोणताही privilege मिळवण्यापासून थांबवते. File capability नेमके हेच करते. त्यामुळे हे setting सुरू असताना obfs4proxy 443 वर bind होण्यात अपयशी ठरते.

ही पायरी टाळायची असल्यास, साधारण दिसणारा high port निवडा आणि तो नोंदवून ठेवा. तुम्ही कोणताही port निवडला तरी obfs4 port नंतर बदलू नका. Bridge line मध्ये address, port, fingerprint आणि certificate एकत्र निश्चित केलेले असतात. त्यामुळे वापरकर्त्याच्या browser मध्ये आधीपासून असलेली प्रत्येक copy port बदलताच काम करणे थांबवते.

दोन्ही firewall वर पोर्ट उघडा

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

दोन्ही पोर्ट खुले असणे आवश्यक आहे. बहुतेक providers त्यांच्या control panel मध्ये दुसरा firewall चालवतात, ज्याची ufw ला कोणतीही माहिती नसते. सर्व्हरवर असलेला पण control panel मध्ये नसलेला rule असा bridge तयार करतो जो कधीही reachable होत नाही आणि descriptor प्रकाशित करत नाही. यापैकी कोणताही भाग नवीन असल्यास, नवीन VPS साठी आवश्यक असलेले ufw rules आणि Linux मध्ये listening port म्हणजे नेमके काय हे त्याचे स्पष्टीकरण देतात. त्याच वेळी, keys वापरून आणि hardened sshd config सह SSH सुरक्षित करा. box वर unlisted bridge असला, तरी password SSH असलेला box तसाच राहतो.

ते सुरू करा, नंतर 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 टाकून देत आहे. दुसऱ्या ओळीत तुम्ही 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 मध्ये तुमचे nickname आणि bridge line मध्ये वापरायचा identity fingerprint असतो. दुसऱ्या file मध्ये hashed fingerprint असतो. तुमचा bridge चालू आहे का आणि अंदाजे किती clients त्याच्यापर्यंत पोहोचतात हे पाहण्यासाठी हा fingerprint Relay Search मध्ये paste करा. हे दोन्ही एकमेकांच्या जागी वापरता येत नाहीत. hashed value असलेली bridge line तुमचा bridge सादर करत असलेल्या identity key शी जुळत नाही. त्यामुळे client ने नुकतेच उघडलेले connection नाकारले जाते.

ब्रिज प्रत्यक्षपणे वापरकर्त्यांपर्यंत कसा पोहोचतो?

तुम्ही तुमची bridge line कोणालाही थेट देत नाही. descriptor bridge authority कडे पोहोचल्यानंतर distribution system (BridgeDB चा उत्तराधिकारी rdsys) तुमचा bridge एका distributor कडे नियुक्त करते आणि वापरकर्ते त्या distributor कडून bridges मागतात. August 2026 पर्यंत उपलब्ध मार्ग पुढीलप्रमाणे आहेत:

• bridges.torproject.org/options वरील web form, जो captcha नंतर bridge lines देतो.
• bridges@torproject.org वर Gmail किंवा Riseup address वरून पाठवलेला email. त्याला उत्तर म्हणून bridge lines मिळतात. ही provider restriction ठेवण्याचे कारण असे आहे की अमर्यादित free accounts मुळे एखाद्या censor ला प्रत्येक bridge ची यादी तयार करता आली असती.
• Telegram bot @GetBridgesBot. /start पाठवा आणि त्यानंतर /obfs4 किंवा /webtunnel पाठवा.
• Tor Browser मधील Settings आणि नंतर Connection येथे असलेला "Request bridges" पर्याय. तो moat channel द्वारे bridges मिळवतो.

नवीन bridge सुरू केल्यानंतर सुमारे तीन तासांनी तो Relay Search मध्ये दिसतो. वापरकर्ते येण्यासाठी मात्र अधिक वेळ लागतो. Tor Project च्या स्वतःच्या शब्दांत, "वापरकर्त्यांचा स्थिर संच दिसेपर्यंत काही दिवस किंवा आठवडे लागू शकतात." पहिल्या दोन आठवड्यांत कमी वापरकर्ते असणे सामान्य आहे; ही त्रुटी नाही.

BridgeDistribution none सेट केल्यास या सर्व वितरण पद्धतींमधून opt out केले जाते. त्यानंतर bridge line गरज असलेल्या लोकांना तुम्हालाच द्यावी लागते, आणि त्यासाठी censor वाचत नसलेले channel वापरावे.

जेव्हा काही कार्य करत नाही

लॉगमध्ये self-testing ओळ नाही. ORPort पोहोचण्यायोग्य नाही. nc -vz your.ip 8443 वापरून दुसऱ्या मशीनवरून त्याची चाचणी करा. विनंती अडकून राहिल्यास packets टाकून दिले जात आहेत. त्यामुळे ufw आणि provider चे panel तपासा. Connection नाकारली गेल्यास tor listening करत नाही. त्यामुळे ss -lntp तपासा आणि configuration error साठी log वाचा.

नोंदणीकृत 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 कनेक्ट होणे थांबले. address किंवा obfs4 port मध्ये केलेला कोणताही बदल आधी वितरित केलेल्या प्रत्येक bridge line ला अवैध करतो. Server चा public IP देखील बदलला आहे का ते तपासा. काही providers कडे rebuild केल्यावर असे होऊ शकते.

tor अजिबात सुरू होत नाही. sudo -u debian-tor tor --verify-config -f /etc/tor/torrc चालवा. ते file parse करते, ज्या ओळीवर आक्षेप आहे ती दाखवते आणि चालू service वर कोणताही परिणाम करत नाही.

FAQ

माझा VPS provider Tor bridge बद्दल तक्रार करेल का?

Bridge हा entry point असतो. त्यामुळे तुमच्या सर्व्हरवरून बाहेर जाणारा network traffic इतर Tor relay कडे जातो आणि वापरकर्त्याने निवडलेल्या कोणत्याही site कडे थेट जात नाही. कोणत्याही web log मध्ये request चा source म्हणून तुमचा IP address दिसत नाही. Exit relay operators ना ज्या तक्रारींचा सामना करावा लागतो, त्या याच कारणामुळे निर्माण होतात. Hosting rules provider नुसार बदलतात. काही providers कोणत्याही Tor service ला special case मानतात. त्यामुळे सुरू करण्यापूर्वी acceptable use policy वाचा आणि वाचलेला address ContactInfo मध्ये द्या.

Tor bridge किती bandwidth वापरतो?

प्रकाशित केलेली किमान मर्यादा upstream आणि downstream साठी 1 Mbit/s आहे. Guard किंवा middle relay साठी ही मर्यादा 10 Mbit/s आहे. प्रत्यक्ष वापर सुरुवातीला जवळजवळ शून्य असतो, कारण distributor ज्या users ना तुमच्या bridge कडे पाठवतो त्यांचाच traffic तुमचा bridge वाहून नेतो. कमाल मर्यादा निश्चित करायची असल्यास torrc मध्ये RelayBandwidthRate आणि RelayBandwidthBurst सेट करा.

माझ्या नवीन bridge शी कोणीही connect का झालेले नाही?

Bridge ला Relay Search मध्ये दिसण्यासाठी सुमारे तीन तास लागतात. सातत्याने users जोडले जाण्यासाठी अनेक दिवस किंवा आठवडे लागू शकतात, असे Tor Project च्या मार्गदर्शनात नमूद केले आहे. Descriptor publish झाला आहे का ते तपासा. journalctl -u tor@default मधील self-testing line हे दर्शवते. Relay Search मध्ये तुमचा hashed fingerprint शोधा आणि BridgeDistribution हे none वर set केलेले नाही याची खात्री करा.

मी obfs4 चालवावे की WebTunnel?

हा तुमचा पहिला bridge असल्यास obfs4 चालवा. यासाठी एक VPS, दोन ports, domain नसणे आणि certificate नसणे पुरेसे आहे. Random-looking traffic स्वतःच blocked असेल अशा ठिकाणी WebTunnel चालवा. त्यासाठी तुमच्या नियंत्रणाखाली domain, प्रत्यक्ष web server, valid TLS certificate आणि किमान 1 GB RAM आवश्यक आहे. दोन्ही चालवत असल्यास त्यांना वेगवेगळ्या addresses वर ठेवा. अन्यथा एक IP blocked झाल्यास दोन्ही bridges एकाच वेळी बंद होतील.

नंतर obfs4 port बदलल्यास काय होते?

आधीच वितरित केलेली प्रत्येक bridge line काम करणे थांबवते. Bridge line मध्ये address, port, fingerprint आणि certificate एकत्र निश्चित केलेले असतात. त्यामुळे जुनी line असलेला client अशा port शी connection उघडतो जिथे कोणतीही service listening नसते आणि connection सोडून देतो. Server चा public IP बदलल्यावरही हेच घडते. Setup दरम्यान port निवडा आणि नंतर तो बदलू नका.