SSD Nodes Learn Hosting plans →
Mwongozo Matt ConnorNa Matt Connor · Imeboreshwa 2026-08-31

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 bandari, na kusoma logi ili kuthibitisha kuwa daraja linafanya kazi.

Daraja la Tor ni nini, na kwa nini lipo

Daraja la Tor ni sehemu ya kuingilia kwenye mtandao wa Tor ambayo 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 kutoka kwenye orodha hiyo huchukua muda mfupi: pakua consensus, kisha zuia kila anwani iliyomo kwenye mpaka wa mtandao. Madaraja yapo kwa sababu orodha iliyochapishwa ndiyo sehemu dhaifu. Anwani za madaraja hutolewa chache kwa wakati mmoja, kwa hivyo ombi moja haliwezi kutoa seti nzima ya anwani.

Anwani isiyoorodheshwa ni nusu tu ya suluhisho. Deep packet inspection (DPI), ambayo huchambua 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 mtiririko wa Tor ndani ya kitu kingine upande wa mteja, na daraja lako huifungua.

obfs4 ndiyo transport inayotumiwa na madaraja mengi. Hugeuza mtiririko kuwa baiti zisizo na header na zisizo na handshake maalum, kwa hivyo DPI haina muundo wa kulinganisha. Pia huthibitisha utambulisho wa mteja. Thamani ya cert= iliyo ndani ya mstari wa daraja ni ufunguo (key) ambao mteja lazima athibitishe kuwa anao kabla ya daraja kujibu chochote, jambo linalozuia active probing: mdhibiti anayeunganisha kwenye anwani yako ili kujaribu kama inazungumza Tor hapati jibu na hajifunzi chochote.

Ni usafiri gani wa aina ya pluggable unaopaswa kuutumia?

  • obfs4 inahitaji VPS moja, port mbili za TCP, na haihitaji jina la domain. Hii ndiyo huduma rahisi zaidi unayoweza kuendesha, na ndiyo mada ya mwongozo huu.
  • WebTunnel huficha muunganisho ndani ya trafiki ya kawaida ya HTTPS kuelekea tovuti halisi. Tor Project inaorodhesha mahitaji yake kama anwani ya IPv4 isiyobadilika (static), domain unayomiliki, seva ya wavuti inayofanya kazi kama vile NGINX au Apache, cheti halali cha TLS, na angalau 1 GB ya RAM huku 4 GB ikipendekezwa. Inafaa kwa mitandao ambapo trafiki inayoonekana kama ya kawaida inatiliwa shaka, kwa sababu nchi inayoruhusu kuvinjari wavuti pekee bado inaruhusu HTTPS.
  • Snowflake ni mchango wa aina tofauti. Wajitolea huendesha proxy za WebRTC za muda mfupi, kwa hivyo pointi za kuingilia hubadilika kila mara na hakuna anwani thabiti ambayo mdhibiti anaweza kuizuia. Huendeshi bridge kwa ajili yake. Unaendesha proxy, na haihitaji anwani maalum.

Anza na obfs4. Unaweza kuongeza bridge ya WebTunnel baadaye, kwenye anwani ya pili: kuendesha zote mbili kwenye IP moja kunamaanisha kuwa anwani moja ikizuiwa, zote mbili hazitafanya kazi.

Gharama ya kuendesha bridge ni nini?

ChartTor Project published minimum bandwidth, August 2026
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 halisi. 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 kwa mwezi, ambayo mipango midogo zaidi ya VPS tayari inatosheleza, kwa hivyo soma gharama halisi ya VPS ndogo kwa mwezi kabla ya kuchagua ukubwa wowote mkubwa.

Uwezekano wa matumizi mabaya ni mdogo, na hili ndilo jambo ambalo watu wengi hulikosea. Bridge ndiyo hop ya kwanza. Trafiki inayotoka kwenye seva yako huenda kwenye relay nyingine ya Tor, 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. Bridge na onion service ni kinyume katika suala hili: bridge ni muhimu tu kwa sababu anwani yake inaweza kufikiwa na hatimaye kugawiwa, wakati v3 onion service kwenye aina hiyo hiyo ya VPS ni muhimu tu wakati IP yako ya umma inapobaki ikiwa imefichwa.

Jambo moja la kuepuka: usibadilishe relay ya umma 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 inayopakuliwa na wadhibiti (censors). Bridge iliyokuwa relay ya umma wiki iliyopita ni bridge ambayo tayari iko kwenye orodha ya kuzuiliwa (blocklist).

Uptime ni muhimu zaidi kuliko kasi. Mahitaji ya relay yanasema kwamba "ikiwa relay yako haifanyi kazi kwa zaidi ya saa 2 kwa siku, manufaa yake ni machache", na bridge iko katika hali mbaya zaidi kuliko relay hapa, kwa sababu kila mteja ana anwani moja na hana njia mbadala. Kuanzisha upya (restart) seva kunakata kila mtumiaji aliyepo. Sanidi ukaguzi wa TCP port katika Uptime Kuma dhidi ya port ya obfs4 ili ujue siku ambayo inapoacha 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 huu 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/null

Sasa andika faili ya chanzo. Laini ya Suites: lazima iwe na codename ya toleo lako, kwa hivyo isome kutoka kwenye mfumo badala ya kuiandika kutoka kichwani.

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

Ikiwa 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 Debian na Ubuntu wenyewe (toleo 0.0.14 katika Debian 13, kufikia Agosti 2026). Thibitisha mahali binary ilipowekwa, kwa sababu njia (path) yake huenda kwenye usanidi:

command -v obfs4proxy || command -v lyrebird

Upstream 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 any

Kila mstari kati ya hiyo una uwezekano wa kufeli, kwa hivyo ichunguze moja baada ya nyingine.

BridgeRelay 1 inaambia tor itume descriptor yake kwa bridge authority badala ya public consensus. Mstari huu mmoja ndio unaofanya relay kutokuorodheshwa.

ORPort ndio port halisi ya Tor. Lazima iweze kufikika kutoka kwenye Internet, kwa sababu tor huijaribu na hukataa kuchapisha descriptor hadi jaribio hilo lifanikiwe.

ServerTransportPlugin inatoa amri ya kuendesha tor. tor huanzisha obfs4proxy kama child process na huwasiliana nayo kupitia pipe, kwa hivyo obfs4proxy haina service unit yake yenyewe na haionekani kamwe katika systemctl status.

ServerTransportListenAddr huweka port ambayo obfs4proxy inasikiliza. Ukiacha mstari huu, obfs4proxy huchagua port yoyote iliyo wazi wakati wa kuanza, na hubadilika baada ya kila restart, kwa hivyo kila bridge line uliyotoa itaelekeza kwenye port ambayo hakuna kinachosikiliza. Wateja hao watapata connection iliyokataliwa na wataacha kujaribu.

ExtORPort auto hufungua extended ORPort, njia ya loopback ambayo obfs4proxy hutumia kurudisha connection zilizokamilika 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 lisilokutambulisha ikiwa ungependa kubaki bila kujulikana.

BridgeDistribution huchagua msambazaji 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 kusambazwa hadharani kabisa.

Kwa nini uchaguzi wa port ni muhimu

Epuka kutumia 9001 kwa ports zote mbili. Tor Project inashauri hivyo moja kwa moja, kwa sababu 9001 ni ORPort ya asili na wadhibiti wa mtandao huchanganua mtandao ili kuitafuta. Ports hizo mbili lazima pia ziwe tofauti, kwa kuwa tor na obfs4proxy kila moja hufungua msikilizaji wake (listener).

Port bora zaidi kwa ajili ya obfs4 ni 443. Port 443 ya kutoka (outbound) iko wazi katika karibu kila mtandao wenye vikwazo, na muunganisho wa muda mrefu kwenda huko huonekana kama kikao cha kawaida cha wavuti. Kufunga (binding) 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.service

Ongeza mistari hii miwili katika kila kihariri kinachofunguka:

[Service]
NoNewPrivileges=no

Uwezo (capability) pekee hautoshi. NoNewPrivileges ya systemd huzuia mchakato kupata upendeleo wowote ambao mzazi wake hakuwa nao, na uwezo wa faili ni hasa huo, kwa hivyo obfs4proxy inashindwa kufunga 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 pindi tu port inapobadilishwa.

Fungua milango kwenye firewall zote mbili

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

Milango yote miwili inahitaji kuwa wazi, na watoa huduma wengi huendesha firewall ya pili kwenye paneli yao ya udhibiti ambayo ufw haijui chochote kuihusu. Sheria iliyopo kwenye seva lakini haipo kwenye paneli hutengeneza daraja (bridge) ambalo haliwezi kufikika na halichapishi descriptor yoyote. Ikiwa nusu yoyote ya hii ni ngeni kwako, sheria za ufw ambazo VPS mpya inahitaji na nini maana halisi ya listening port kwenye Linux zinaelezea 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@default

Debian na Ubuntu husambaza unit mbili. tor.service ni wrapper ndogo na tor@default.service ndiyo mchakato unaofanya kazi, ndiyo maana journalctl -u tor inaonekana karibu haina kitu wakati logi unayotaka ipo chini ya tor@default.

Mistari miwili inaonyesha kuwa imefanikiwa:

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 kuwa jaribio la ufikivu limefaulu na descriptor imetumwa kwa bridge authority. Ikiwa haionekani kamwe, kuna kitu kati ya Internet na seva yako kinazuia trafiki kwenda kwenye ORPort. Mstari wa pili lazima uonyeshe port uliyosanidi. Port tofauti hapo inamaanisha kuwa tor haikutumia ServerTransportListenAddr, na sababu ya kawaida ni jina la transport lisilolingana: lazima lisomeke 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.txt

Saraka hiyo ni mali ya mtumiaji tor na ina mode 700, kwa hivyo bila sudo utapata Permission denied. Faili hiyo ina laini yenye umbo hili:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Badilisha <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-fingerprint

Faili ya kwanza ina jina lako la utani (nickname) na fingerprint ya utambulisho inayopaswa kuwemo kwenye laini ya bridge. Faili ya pili ina 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 hazibadilishani. 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?

Hutoi mstari wako wa bridge kwa mtu yeyote. Pindi descriptor inapofika kwa bridge authority, mfumo wa usambazaji (rdsys, mrithi wa BridgeDB) huikabidhi bridge yako kwa msambazaji mmoja, na watumiaji huwaomba wasambazaji hao bridge. Kufikia Agosti 2026, njia hizi ndizo zinazotumika:

  • Fomu ya tovuti iliyo kwenye 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 kutuma mistari ya bridge. Kizuizi cha mtoa huduma kipo kwa sababu akaunti zisizo na kikomo zingemruhusu mdhibiti (censor) kubaini kila bridge.
  • Telegram bot @GetBridgesBot. Tuma /start, kisha /obfs4 au /webtunnel.
  • Tor Browser yenyewe, chini ya Settings kisha Connection, ambapo "Request bridges" huzichota kupitia njia ya moat.

Bridge mpya huonekana kwenye Relay Search takriban saa tatu baada ya usanidi. Watumiaji huchukua muda mrefu zaidi: maelezo ya Tor Project yanasema kuwa "Inaweza kuchukua siku kadhaa au wiki kadhaa hadi uone idadi thabiti ya watumiaji." Wiki mbili za kwanza za utulivu ni jambo la kawaida, si hitilafu.

Kuweka BridgeDistribution none kunakuondoa kwenye mfumo huu wote. 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 inakwama, inamaanisha pakiti zinadondoshwa, kwa hivyo kagua ufw na paneli ya mtoa huduma wako. Ikiwa inakataa, inamaanisha tor haisikilizi, 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 haitafunga 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 inachapisha NoNewPrivileges=yes, 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 iliyo kwenye 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 imehama 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 inayofanya kazi 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 katika 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 katika 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 katika torrc.

Kwa nini hakuna aliyeunganishwa kwenye bridge yangu mpya?

Bridge huchukua takriban saa tatu kuonekana katika 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 katika journalctl -u tor@default, tafuta fingerprint yako iliyosimbwa (hashed fingerprint) katika 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 unayoidhibiti, 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 bridge mbili kwa wakati mmoja.

Nini kitatokea nikibadilisha port ya obfs4 baadaye?

Kila mstari wa bridge uliosambazwa utaacha 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 kuacha. Hali hiyo hiyo hutokea wakati IP ya umma ya seva inapobadilika. Chagua port wakati wa usanidi na usiibadilishe.