Jinsi ya kuendesha Tor bridge na obfs4 kwenye VPS
Jifunze kusanidi Tor bridge kwa kutumia obfs4 kwenye VPS yako. Pata mwongozo wa kurekebisha torrc, kufungua port kwenye firewall, na kuthibitisha logi ili kuhakikisha inafanya kazi.
Tor bridge ni nini, na kwa nini ipo
Tor bridge ni lango la kuingia kwenye mtandao wa Tor ambalo anwani yake haijachapishwa kwenye orodha ya umma ya relay. Orodha hiyo, inayojulikana kama consensus, ni hati iliyotiwa saini ambayo mtu yeyote anaweza kuipakua, na mdhibiti wa mtandao (censor) pia huipakua. Kuzuia Tor kupitia orodha hiyo huchukua muda mfupi tu: pakua consensus, kisha zuia kila anwani iliyomo kwenye mpaka wa mtandao. Bridge zipo kwa sababu orodha iliyochapishwa ndiyo sehemu dhaifu. Anwani za bridge hutolewa chache kwa wakati mmoja, hivyo ombi moja haliwezi kutoa orodha nzima.
Anwani isiyoorodheshwa ni nusu tu ya suluhisho. Deep packet inspection (DPI), ambayo huainisha trafiki kulingana na maudhui yake badala ya anwani, hutambua muunganisho wa Tor kutokana na umbo la TLS (transport layer security) handshake yake. Mdhibiti asiye na orodha bado anaweza kuona "hii inaonekana kama Tor" na kukata muunganisho. Pluggable transport huondoa ishara hiyo. Hufunga mkondo wa Tor ndani ya kitu kingine upande wa mteja, na bridge yako huifungua.
obfs4 ndiyo transport inayotumiwa na bridge nyingi. Hugeuza mkondo huo kuwa baiti zisizo na header wala handshake isiyobadilika, hivyo DPI haina muundo wa kulinganisha. Pia huthibitisha utambulisho wa mteja. Thamani ya cert= iliyo ndani ya mstari wa bridge ni ufunguo ambao mteja lazima athibitishe kuwa anao kabla ya bridge kujibu chochote, jambo linalozuia active probing: mdhibiti anayeunganisha kwenye anwani yako ili kujaribu kama inazungumza Tor hapati jibu lolote na hajifunzi chochote.
Ni pluggable transport ipi unayopaswa kuendesha?
- obfs4 inahitaji VPS moja, port mbili za TCP, na haihitaji domain name. Hii ndiyo njia rahisi zaidi yenye manufaa unayoweza kuendesha, na ndiyo mada ya mwongozo huu.
- WebTunnel huficha muunganisho ndani ya traffic ya kawaida ya HTTPS inayoelekea kwenye tovuti halisi. Tor Project inaorodhesha mahitaji yake kama IPv4 address isiyobadilika (static), domain unayoimiliki, web server inayofanya kazi kama NGINX au Apache, cheti halali cha TLS, na angalau 1 GB ya RAM huku 4 GB ikipendekezwa. Inafaa kwa mitandao ambapo traffic inayoonekana kuwa ya kawaida inatiliwa shaka, kwa sababu nchi inayoruhusu mambo machache zaidi ya kuvinjari wavuti bado inaruhusu HTTPS.
- Snowflake ni mchango wa aina tofauti. Wajitolea huendesha WebRTC proxies za muda mfupi, kwa hivyo pointi za kuingilia hubadilika kila mara na hakuna anwani thabiti ambayo mdhibiti (censor) anaweza kuizuia. Huendeshi bridge kwa ajili yake. Unaendesha proxy, na haihitaji anwani isiyobadilika.
Anza na obfs4. Unaweza kuongeza WebTunnel bridge baadaye, kwenye anwani ya pili: kuendesha zote mbili kwenye IP moja inamaanisha kuwa anwani moja ikizuiwa, zote mbili hazitafanya kazi.
Kuendesha bridge kunagharimu kiasi gani?
The data behind this chart
[
{
"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
}
]Kufikia Agosti 2026, Tor Project inaomba bridge iwe na angalau 1 Mbit/s ya bandwidth ya kupakia (upstream) na kupakua (downstream). Guard relay au middle relay inaombwa kuwa na 10 Mbit/s, huku 16 Mbit/s ikipendekezwa. Haya ni mahitaji yaliyochapishwa, si vipimo. Bridge mpya kwa kawaida huwa chini ya kiwango chake cha chini kwa wiki kadhaa. Ukurasa huo huo wa mahitaji unaomba relay iwe na angalau 100 GByte ya trafiki ya kutoka (outbound) kwa mwezi, ambayo mipango midogo zaidi tayari inatosheleza, kwa hivyo soma gharama halisi ya VPS ndogo kwa mwezi kabla ya kuchagua ukubwa wowote mkubwa zaidi.
Eneo la hatari ya matumizi mabaya (abuse surface) ni dogo, na hili ndilo jambo ambalo watu wanakosea. Bridge ndiyo hatua ya kwanza (first hop). Trafiki inayotoka kwenye seva yako inaenda kwenye Tor relay nyingine, kamwe haiendi kwenye tovuti iliyochaguliwa na mtumiaji. Anwani yako ya IP haionekani kamwe kwenye logi ya wavuti ya mtu mwingine kama chanzo cha ombi, kwa hivyo barua za malalamiko wanazoshughulikia waendeshaji wa exit relay hazifiki hapa. Hata hivyo, kagua sera ya matumizi inayokubalika ya mtoa huduma wako, kwa sababu baadhi ya wenyeji (hosts) huchukulia huduma yoyote ya Tor kama kesi maalum.
Jambo moja la kuepuka: usibadilishe public relay iliyopo kuwa bridge kwenye anwani hiyo hiyo. Ushauri wa Tor Project kwa kesi hiyo ni kubadilisha "anwani ya IP, jina na fingerprint", kwa sababu anwani ya zamani tayari iko kwenye consensus ambayo wadhibiti (censors) wanapakua. Bridge iliyokuwa public relay wiki iliyopita ni bridge ambayo tayari iko kwenye orodha ya kuzuiwa (blocklist).
Uptime ni muhimu zaidi kuliko kasi. Mahitaji ya relay yanasema kwamba "kama relay yako haifanyi kazi kwa zaidi ya saa 2 kwa siku, manufaa yake ni madogo", na bridge iko katika hali mbaya zaidi kuliko relay hapa, kwa sababu kila mteja ana anwani moja na hana njia mbadala. Kuanzisha upya (restart) kunakata kila mtumiaji aliyepo. Sanidi ukaguzi wa TCP port katika Uptime Kuma dhidi ya port ya obfs4 ili uweze kujua siku ambayo inaacha kujibu.
Sakinisha Tor kutoka kwenye hazina ya Tor Project
Vifurushi vya usambazaji (distribution packages) huwa nyuma kimitindo, na bridge ni programu ya usalama ambayo inapaswa kuwa ya kisasa. Ongeza hazina ya mradi huo kwanza.
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/nullSasa andika faili ya chanzo. Mstari wa Suites: lazima uwe na codename ya toleo lako, kwa hivyo isome kutoka kwenye mfumo badala ya kuiandika kwa kukumbuka.
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 obfs4proxyIkiwa apt update itaripoti kuwa hazina haina faili ya Release kwa ajili ya codename yako, Tor Project haitoi toleo hilo. Futa /etc/apt/sources.list.d/tor.sources, endesha sudo apt update tena, na usakinishe kifurushi cha tor ambacho usambazaji wako unatoa. Kila kitu hapa chini ni sawa.
Kifurushi cha obfs4proxy kinatoka kwa Debian na Ubuntu wenyewe (toleo la 0.0.14 katika Debian 13, kufikia Agosti 2026). Thibitisha mahali binary ilipowekwa, kwa sababu njia yake (path) huenda kwenye usanidi:
command -v obfs4proxy || command -v lyrebirdUpstream wamebadilisha jina la mradi na kuwa lyrebird, kwa hivyo kifurushi kipya zaidi kinaweza kusakinisha /usr/bin/lyrebird badala yake. Tumia njia yoyote ile ambayo amri hiyo inachapisha.
Sanidi bridge katika /etc/tor/torrc
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 anyKila mstari kati ya hiyo una hitilafu inayoweza kutokea, kwa hivyo ichunguze moja baada ya nyingine.
BridgeRelay 1 inaambia tor itume descriptor yake kwa mamlaka ya bridge badala ya consensus ya umma. Mstari huu mmoja ndio unaofanya relay hii kutokuorodheshwa.
ORPort ni port halisi ya Tor. Lazima iweze kufikika kutoka kwenye Internet, kwa sababu tor huifanyia majaribio na hukataa kuchapisha descriptor hadi jaribio hilo lifaulu.
ServerTransportPlugin inatoa amri ya kuendesha tor. tor huanzisha obfs4proxy kama mchakato msaidizi (child process) na huwasiliana nayo kupitia pipe, kwa hivyo obfs4proxy haina service unit yake yenyewe na haionekani kamwe katika systemctl status.
ServerTransportListenAddr hurekebisha port ambayo obfs4proxy husikiliza. Ukiacha mstari huu, obfs4proxy huchagua port yoyote iliyo wazi wakati wa kuanza, na hubadilika baada ya kila restart, hivyo kila bridge line uliyotoa itaelekeza kwenye port ambayo haina huduma inayoisikiliza. Wateja hao watapata muunganisho uliokataliwa na wataacha kujaribu.
ExtORPort auto hufungua extended ORPort, njia ya loopback ambayo obfs4proxy hutumia kurudisha miunganisho iliyokamilika kwa tor pamoja na anwani ya mteja. Mwongozo wa usanidi wa Tor Project unaijumuisha kwenye kila bridge, kwa sababu bila hiyo, transport haiwezi kuripoti anwani hiyo kwa tor.
ContactInfo na Nickname zote ni za umma. Tumia anwani utakayoisoma, kwa sababu ndiyo njia ambayo Tor Project itawasiliana nawe kuhusu bridge iliyoharibika, na chagua jina la utani (nickname) lisilokutambulisha ikiwa ungependa kubaki bila kujulikana.
BridgeDistribution huchagua msambazaji (distributor) anayetoa anwani yako kwa watumiaji. Thamani zinazokubalika ni https, email, telegram, settings, none na any. Tumia any kwa bridge ya kwanza na uruhusu mfumo uamue. Tumia none kwa bridge ya faragha unayotoa wewe mwenyewe, ambayo huizuia anwani hiyo isisambazwe hadharani kabisa.
Kwa nini uchaguzi wa port ni muhimu
Epuka kutumia 9001 kwa port zote mbili. Tor Project inashauri hivyo moja kwa moja, kwa sababu 9001 ni ORPort ya kawaida na wadhibiti wa mtandao huchanganua intaneti kuitafuta. Port hizo mbili lazima ziwe tofauti, kwa sababu tor na obfs4proxy kila moja hufungua listener yake.
Port bora zaidi ya obfs4 ni 443. Traffic ya 443 inayotoka nje inaruhusiwa katika karibu kila mtandao wenye vikwazo, na muunganisho wa muda mrefu kwenye port hiyo huonekana kama kikao cha kawaida cha wavuti. Kufungua port iliyo chini ya 1024 kunahitaji hatua moja ya ziada, kwa sababu obfs4proxy haiendeshwi kama root:
sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.serviceOngeza mistari hii miwili katika kila kihariri kinachofunguka:
[Service]
NoNewPrivileges=noUwezo (capability) pekee hautoshi. NoNewPrivileges ya systemd huzuia mchakato kupata upendeleo wowote ambao mzazi wake hakuwa nao, na file capability ni upendeleo wa aina hiyo, kwa hivyo obfs4proxy inashindwa kufungua 443 wakati mpangilio huo ukiwa umewashwa.
Ikiwa ungependa kuruka hatua hiyo, chagua port ya juu isiyo na umaarufu na uiandike. Chochote utakachochagua, usibadilishe port ya obfs4 baadaye. Mstari wa bridge huunganisha anwani, port, fingerprint na cheti pamoja, kwa hivyo kila nakala iliyopo kwenye kivinjari cha mtumiaji itaharibika mara tu port inapobadilishwa.
Fungua milango kwenye firewalls zote mbili
sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw statusMilango yote miwili inahitaji kuwa wazi, na watoa huduma wengi huendesha firewall ya pili kwenye paneli yao ya udhibiti ambayo ufw haijui chochote kuihusu. Kanuni iliyopo kwenye seva lakini si kwenye paneli hutengeneza daraja (bridge) ambalo haliwezi kufikiwa na halichapishi descriptor yoyote. Ikiwa nusu yoyote ya hii ni ngeni kwako, kanuni za ufw ambazo VPS mpya inahitaji na nini maana halisi ya listening port kwenye Linux vinaelezea hayo. Ukiwa hapo, imarisha SSH kwa kutumia funguo na usanidi wa sshd uliokazwa. Daraja lisiloorodheshwa kwenye seva yenye SSH ya nenosiri bado ni seva yenye SSH ya nenosiri.
Ianzishe, kisha usome logi
sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@defaultDebian na Ubuntu husafirisha unit mbili. tor.service ni wrapper ndogo na tor@default.service ndiyo mchakato unaofanya kazi, ndiyo maana journalctl -u tor inaonekana haina kitu wakati logi unayotaka ipo chini ya tor@default.
Mistari miwili inaashiria kuwa imefanya kazi:
Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'Mstari wa kwanza unamaanisha jaribio la ufikivu limefaulu na descriptor imefika kwa bridge authority. Ikiwa haionekani kamwe, kuna kitu kati ya internet na seva yako kinachozuia trafiki kwenda kwenye ORPort. Mstari wa pili lazima uonyeshe port uliyosanidi. Port tofauti hapo inamaanisha tor haikutumia ServerTransportListenAddr, na sababu ya kawaida ni kutolingana kwa jina la transport: lazima isomwe obfs4 kwenye maelekezo yote mawili.
Thibitisha kuwa listeners wawili wapo:
sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'Laini yangu ya bridge iko wapi?
obfs4proxy huandika kiolezo kwenye saraka ya data ya tor:
sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txtSaraka hiyo inamilikiwa na mtumiaji tor na ina mode 700, kwa hivyo bila sudo utapata Permission denied. Faili hilo lina laini yenye umbo hili:
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0Badilisha <IP ADDRESS> na anwani ya umma ya seva yako, <PORT> na port ya obfs4 na si ORPort, na <FINGERPRINT> na fingerprint ya utambulisho ambayo tor iliandika kwenye saraka yake ya data:
sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprintFaili la kwanza lina jina lako la utani (nickname) na fingerprint ya utambulisho inayopaswa kuwepo kwenye laini ya bridge. La pili lina fingerprint iliyofanyiwa hashing, ambayo ndiyo unayopaswa kubandika kwenye Relay Search ili kuona kama bridge yako inafanya kazi na takriban ni wateja wangapi wanaifikia. Hizi mbili haziwezi kubadilishana. Laini ya bridge iliyo na thamani iliyofanyiwa hashing hailingani na ufunguo wa utambulisho ambao bridge yako inatoa, kwa hivyo mteja hukataa muunganisho alioufungua.
Je, bridge hufikiaje watumiaji?
Hupaswi kumpa mtu yeyote mstari wako wa bridge. Mara tu descriptor inapofika kwa bridge authority, mfumo wa usambazaji (rdsys, mrithi wa BridgeDB) huikabidhi bridge yako kwa msambazaji mmoja, na watumiaji huomba bridge kutoka kwa msambazaji huyo. Kufikia Agosti 2026, njia hizi ndizo zinazotumika:
- Fomu ya tovuti katika bridges.torproject.org/options, ambayo hutoa mistari ya bridge baada ya kujaza captcha.
- Barua pepe kwenda bridges@torproject.org kutoka anwani ya Gmail au Riseup, ambayo hujibu kwa mistari ya bridge. Kizuizi cha mtoa huduma kipo kwa sababu akaunti nyingi za bure zisizo na kikomo zingemruhusu mdhibiti (censor) kubaini kila bridge.
- Telegram bot @GetBridgesBot. Tuma
/start, kisha/obfs4au/webtunnel. - Tor Browser yenyewe, chini ya Settings kisha Connection, ambapo "Request bridges" huzipakua kupitia njia ya moat.
Bridge mpya huonekana katika Relay Search takriban saa tatu baada ya kusanidiwa. Watumiaji huchukua muda mrefu zaidi: Tor Project wenyewe wanasema kuwa "Inaweza kuchukua siku kadhaa au wiki kadhaa hadi uone kundi thabiti la watumiaji." Wiki mbili za kwanza za utulivu ni jambo la kawaida, si hitilafu.
Kuweka BridgeDistribution none kunajiondoa kwenye mifumo yote hiyo. Mstari wa bridge huwa ni wako sasa ili uweze kuutuma kwa watu wanaouhitaji, kupitia njia ambayo mdhibiti haisomi.
Wakati kitu hakifanyi kazi
Hakuna mstari wa self-testing kwenye log. ORPort haipatikani. Ijaribu kutoka kwenye mashine nyingine kwa kutumia nc -vz your.ip 8443. Ikiwa itakwama, inamaanisha pakiti zinadondoshwa, kwa hivyo kagua ufw na paneli ya mtoa huduma wako. Ikiwa itaonyesha kukataa (refusal), inamaanisha tor haisikilizi kwenye port hiyo, kwa hivyo kagua ss -lntp na usome log ili kuona kosa la usanidi.
Transport iliyosajiliwa inaonyesha port ambayo hukuchagua. tor ilipuuza ServerTransportListenAddr. Jina la transport lazima lilingane kabisa na lile lililo kwenye ServerTransportPlugin, na yote mawili lazima yawe obfs4.
obfs4proxy haitaki kufunga (bind) port 443. Thibitisha uwezo huo kwa getcap /usr/bin/obfs4proxy, kisha thibitisha kuwa override imefika kwenye unit kwa systemctl show tor@default -p NoNewPrivileges. Ikiwa itachapisha NoNewPrivileges=yes, inamaanisha drop-in yako ilienda kwenye unit ambayo haiendeshi.
Hakuna kitu ndani ya /var/lib/tor/pt_state/. tor haikuwahi kuanzisha transport, jambo linalomaanisha kuwa njia (path) katika ServerTransportPlugin si sahihi. Ilinganishe na matokeo ya command -v obfs4proxy.
Wateja wameacha kuunganisha baada ya mabadiliko. Mabadiliko yoyote kwenye anwani au port ya obfs4 yanabatilisha kila mstari wa bridge uliokwisha kusambazwa. Kagua kama IP ya umma ya seva imebadilika pia, jambo linalotokea wakati wa rebuild na baadhi ya watoa huduma.
tor haitaki kuanza kabisa. Endesha sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Inachambua faili, inachapisha mstari unaokataa, na inaiacha huduma inayokimbia bila kuigusa.
FAQ
Je, mtoa huduma wangu wa VPS atalalamika kuhusu Tor bridge?
Bridge ni sehemu ya kuingilia, kwa hivyo trafiki inayotoka kwenye seva yako huenda kwa relays nyingine za Tor na kamwe haielekei kwenye tovuti iliyochaguliwa na mtumiaji. Anwani yako ya IP haionekani kwenye logi yoyote ya wavuti kama chanzo cha ombi, na ndiyo sababu ya malalamiko ambayo waendeshaji wa exit relay hukabiliana nayo. Sheria za hosting hutofautiana, na baadhi ya watoa huduma huchukulia huduma yoyote ya Tor kama kesi maalum, kwa hivyo soma sera ya matumizi yanayokubalika (acceptable use policy) kabla ya kuanza na uweke anwani unayoisoma kwenye ContactInfo.
Tor bridge hutumia bandwidth kiasi gani?
Kiwango cha chini kilichochapishwa ni 1 Mbit/s kwa kupakia na kupakua, ikilinganishwa na 10 Mbit/s kwa guard au middle relay. Matumizi halisi huanza karibu na sifuri, kwa sababu bridge yako hubeba trafiki tu kwa watumiaji wanaotumwa kwake na msambazaji. Ikiwa unataka kikomo cha juu, weka RelayBandwidthRate na RelayBandwidthBurst kwenye torrc.
Kwa nini hakuna mtu aliyeunganishwa kwenye bridge yangu mpya?
Bridge huchukua takriban saa tatu kuonekana kwenye Relay Search, na mwongozo wa Tor Project ni kwamba seti thabiti ya watumiaji huchukua siku kadhaa au wiki. Hakikisha kuwa descriptor imechapishwa, ambayo ni mstari wa self-testing kwenye journalctl -u tor@default, tafuta hashed fingerprint yako kwenye Relay Search, na uthibitishe kuwa BridgeDistribution haijawekwa kuwa none.
Je, niendeshe obfs4 au WebTunnel?
Endesha obfs4 ikiwa hii ni bridge yako ya kwanza: VPS moja, ports mbili, hakuna domain, hakuna cheti. Endesha WebTunnel pale ambapo trafiki inayoonekana ya kawaida inazuiwa, kwa sababu inahitaji domain unayoimiliki, seva halisi ya wavuti, cheti halali cha TLS, na angalau 1 GB ya RAM. Ziweke kwenye anwani tofauti ikiwa utaendesha zote mbili, kwa sababu IP moja iliyozuiwa ingeondoa bridges mbili kwa wakati mmoja.
Nini kitatokea nikibadilisha port ya obfs4 baadaye?
Kila mstari wa bridge uliosambazwa huacha kufanya kazi. Mstari wa bridge huunganisha anwani, port, fingerprint na cheti pamoja, kwa hivyo mteja aliye na mstari wa zamani hujaribu kuunganisha kwenye port ambayo hakuna kinachosikiliza na hatimaye hukata tamaa. Hali hiyo hiyo hutokea wakati IP ya umma ya seva inapobadilika. Chagua port wakati wa usanidi na usiibadilishe.