Cara Pasang Tor Bridge obfs4 di VPS Sendiri

Apakah itu Tor bridge, dan mengapa ia wujud

Tor bridge ialah titik masuk ke dalam rangkaian Tor yang alamatnya tidak diterbitkan dalam senarai relay awam. Senarai tersebut, yang dipanggil consensus, merupakan dokumen bertandatangan yang boleh dimuat turun oleh sesiapa sahaja, termasuk pihak penapis. Menyekat Tor daripada senarai itu hanya mengambil masa satu petang: muat turun consensus, kemudian sekat setiap alamat di dalamnya pada sempadan rangkaian. Bridge wujud kerana senarai yang diterbitkan itu merupakan titik kelemahan. Alamat bridge diberikan sedikit demi sedikit, jadi tiada permintaan tunggal yang akan mendedahkan keseluruhan set alamat tersebut.

Alamat yang tidak tersenarai hanyalah separuh daripada penyelesaian. Deep packet inspection (DPI), yang mengelaskan trafik berdasarkan kandungannya dan bukannya alamat, dapat mengecam sambungan Tor daripada bentuk jabat tangan TLS (transport layer security) miliknya. Pihak penapis yang tidak mempunyai senarai masih boleh melihat "ini kelihatan seperti Tor" lalu menggugurkan sambungan tersebut. Pluggable transport menghapuskan isyarat itu. Ia membungkus aliran Tor dengan sesuatu yang lain pada sisi klien, dan bridge anda akan membukanya semula.

obfs4 ialah transport yang dijalankan oleh kebanyakan bridge. Ia menukarkan aliran tersebut kepada bait tanpa header dan tanpa jabat tangan tetap, jadi DPI tiada corak untuk dipadankan. Ia juga mengesahkan klien. Nilai cert= di dalam baris bridge ialah kunci yang mesti dibuktikan oleh klien sebelum bridge memberikan sebarang jawapan. Ini menangkis active probing: pihak penapis yang menyambung ke alamat anda untuk menguji sama ada ia menggunakan Tor tidak akan mendapat balasan dan tidak akan mengetahui apa-apa.

Pluggable transport yang manakah perlu anda jalankan?

• obfs4 memerlukan satu VPS, dua port TCP, dan tiada nama domain. Ini adalah perkara paling mudah dan berguna yang boleh anda jalankan, serta merupakan subjek panduan ini.
• WebTunnel menyembunyikan sambungan di dalam trafik HTTPS biasa ke laman web sebenar. Tor Project menyenaraikan keperluannya sebagai alamat IPv4 statik, domain yang anda kawal, pelayan web yang berfungsi seperti NGINX atau Apache, sijil TLS yang sah, dan sekurang-kurangnya 1 GB RAM dengan 4 GB disyorkan. Ia sesuai untuk rangkaian di mana trafik yang kelihatan rawak dianggap mencurigakan, kerana negara yang hanya membenarkan pelayaran web masih membenarkan HTTPS.
• Snowflake adalah sumbangan yang berbeza. Sukarelawan menjalankan proksi WebRTC jangka pendek, jadi titik masuk sentiasa berubah dan tiada alamat stabil untuk disekat oleh penapis. Anda tidak mengendalikan bridge untuknya. Anda menjalankan proksi, dan ia tidak memerlukan alamat tetap.

Mulakan dengan obfs4. Anda boleh menambah bridge WebTunnel kemudian, pada alamat kedua: menjalankan kedua-duanya pada satu IP bermakna satu alamat yang disekat akan melumpuhkan kedua-duanya.

Apakah kos menjalankan sebuah 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
  }
]

Setakat Ogos 2026, Tor Project menetapkan keperluan lebar jalur sekurang-kurangnya 1 Mbit/s untuk muat naik dan muat turun bagi sebuah bridge. Bagi relay jenis guard atau middle, keperluan yang ditetapkan ialah 10 Mbit/s, dengan saranan 16 Mbit/s. Ini merupakan keperluan yang diterbitkan, bukannya ukuran sebenar. Bridge baharu biasanya beroperasi jauh di bawah tahap minimum tersebut selama beberapa minggu. Halaman keperluan yang sama menetapkan sekurang-kurangnya 100 GByte trafik keluar sebulan bagi setiap relay, yang mana pelan VPS paling kecil sudah pun memenuhinya. Oleh itu, baca kos sebenar VPS kecil setiap bulan sebelum anda memilih saiz pelayan yang lebih besar.

Permukaan risiko penyalahgunaan adalah kecil, dan ini adalah bahagian yang sering disalah faham. Bridge merupakan hop pertama. Trafik yang keluar dari pelayan anda akan menuju ke relay Tor yang lain, bukan ke laman web yang dipilih oleh pengguna. Alamat IP anda tidak akan muncul dalam log web pihak ketiga sebagai sumber permintaan, jadi e-mel aduan yang biasanya diterima oleh pengendali exit relay tidak akan sampai ke sini. Walau bagaimanapun, semak polisi penggunaan yang boleh diterima (acceptable use policy) pembekal anda, kerana sesetengah hos menganggap sebarang servis Tor sebagai kes khas. Bridge dan onion service adalah cerminan antara satu sama lain dalam aspek ini: bridge hanya berguna kerana alamatnya boleh dicapai dan akhirnya diberikan kepada pengguna, manakala v3 onion service pada jenis VPS yang sama hanya berguna selagi alamat IP awam anda tidak didedahkan.

Satu perkara yang tidak patut dilakukan: menukar relay awam sedia ada kepada bridge pada alamat yang sama. Nasihat Tor Project untuk kes tersebut adalah untuk menukar "alamat IP, nama dan fingerprint", kerana alamat lama sudah pun berada dalam konsensus yang dimuat turun oleh pihak penapis. Bridge yang merupakan relay awam pada minggu lepas adalah bridge yang sudah pun berada dalam senarai sekat (blocklist).

Uptime lebih penting daripada kelajuan. Keperluan relay menyatakan bahawa "jika relay anda tidak berjalan lebih daripada 2 jam sehari, kegunaannya adalah terhad", dan bridge lebih terjejas dalam hal ini kerana setiap klien hanya mempunyai satu alamat dan tiada sandaran. Setiap kali pelayan dimulakan semula, semua pengguna akan terputus sambungan. Sediakan semakan port TCP dalam Uptime Kuma pada port obfs4 supaya anda mengetahui hari ia berhenti berfungsi.

Memasang Tor daripada repositori Tor Project

Pakej pengedaran sering ketinggalan, sedangkan bridge ialah perisian keselamatan yang perlu sentiasa terkini. Tambahkan repositori projek tersebut terlebih dahulu.

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

Sekarang, tulis fail sumber. Baris Suites: mesti mengandungi kod nama keluaran anda, jadi baca kod tersebut daripada sistem dan bukannya menaipnya daripada ingatan.

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

Jika apt update melaporkan bahawa repositori tersebut tidak mempunyai fail Release untuk kod nama anda, bermakna Tor Project tidak menyokong keluaran tersebut. Padam /etc/apt/sources.list.d/tor.sources, jalankan sudo apt update sekali lagi, dan pasang pakej tor yang disediakan oleh pengedaran anda. Segala arahan di bawah adalah sama.

Pakej obfs4proxy datang daripada Debian dan Ubuntu sendiri (versi 0.0.14 dalam Debian 13, setakat Ogos 2026). Sahkan lokasi binari tersebut, kerana laluannya akan dimasukkan ke dalam konfigurasi:

command -v obfs4proxy || command -v lyrebird

Pihak hulu (upstream) telah menamakan semula projek ini kepada lyrebird, jadi pakej yang lebih baharu mungkin memasang /usr/bin/lyrebird sebagai gantinya. Gunakan mana-mana laluan yang dipaparkan oleh arahan tersebut.

Konfigurasi bridge dalam /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

Setiap baris tersebut mempunyai risiko kegagalan yang berkaitan, jadi telitilah satu demi satu.

BridgeRelay 1 mengarahkan tor untuk menghantar deskriptornya kepada pihak berkuasa bridge dan bukannya konsensus awam. Baris tunggal ini menjadikan relay anda tidak tersenarai.

ORPort ialah port Tor yang sebenar. Ia mestilah boleh dicapai dari internet, kerana tor akan mengujinya dan enggan menerbitkan deskriptor sehingga ujian tersebut berjaya.

ServerTransportPlugin memberikan arahan untuk dijalankan oleh tor. tor memulakan obfs4proxy sebagai proses anak dan berkomunikasi dengannya melalui pipe, jadi obfs4proxy tidak mempunyai unit servisnya sendiri dan tidak akan muncul dalam systemctl status.

ServerTransportListenAddr menetapkan port yang didengar oleh obfs4proxy. Jika baris ini ditinggalkan, obfs4proxy akan memilih port bebas semasa permulaan, dan port yang berbeza selepas kebanyakan proses but semula, menyebabkan setiap baris bridge yang telah anda berikan akan menghala ke port yang tidak mempunyai sebarang servis. Pelanggan tersebut akan menerima sambungan yang ditolak dan berhenti mencuba.

ExtORPort auto membuka ORPort lanjutan, iaitu saluran loopback yang digunakan oleh obfs4proxy untuk menyerahkan sambungan yang telah selesai kembali kepada tor bersama-sama dengan alamat pelanggan. Panduan penyediaan The Tor Project menyertakannya pada setiap bridge, kerana tanpanya pengangkutan tersebut tidak dapat melaporkan alamat itu kepada tor.

ContactInfo dan Nickname kedua-duanya adalah awam. Gunakan alamat yang anda akan baca, kerana itulah cara The Tor Project menghubungi anda mengenai bridge yang rosak, dan pilih nama samaran yang tidak mengenal pasti diri anda jika anda lebih suka kekal tidak dikenali.

BridgeDistribution memilih pengedar yang memberikan alamat anda kepada pengguna. Nilai yang diterima ialah https, email, telegram, settings, none dan any. Gunakan any untuk bridge pertama dan biarkan sistem membuat keputusan. Gunakan none untuk bridge peribadi yang anda berikan sendiri, yang memastikan alamat tersebut tidak diedarkan secara awam sama sekali.

Mengapa pemilihan port adalah penting

Elakkan penggunaan 9001 untuk kedua-dua port. Tor Project menyatakan perkara ini secara langsung, kerana 9001 merupakan ORPort tradisional dan penapis internet mengimbas rangkaian untuk mencari port tersebut. Kedua-dua port juga mestilah berbeza antara satu sama lain, memandangkan tor dan obfs4proxy masing-masing mengikat pendengar (listener) sendiri.

Port obfs4 yang paling kukuh ialah 443. Trafik keluar 443 dibuka pada hampir setiap rangkaian yang disekat, dan sambungan jangka panjang ke port tersebut kelihatan seperti sesi web biasa. Pengikatan di bawah 1024 memerlukan satu langkah tambahan, kerana obfs4proxy tidak dijalankan sebagai root:

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

Tambahkan dua baris ini dalam setiap editor yang dibuka:

[Service]
NoNewPrivileges=no

Keupayaan (capability) itu sahaja tidak mencukupi. NoNewPrivileges dalam systemd menghalang sesuatu proses daripada memperoleh sebarang keistimewaan yang tidak dimiliki oleh induknya, dan keupayaan fail adalah perkara tersebut, jadi obfs4proxy gagal untuk mengikat 443 selagi tetapan itu kekal aktif.

Jika anda lebih suka melangkau langkah tersebut, pilih port tinggi yang tidak menarik perhatian dan catatkannya. Walau apa pun pilihan anda, jangan ubah port obfs4 kemudian hari. Baris bridge menyatukan alamat, port, fingerprint dan sijil, jadi setiap salinan yang sudah ada dalam pelayar pengguna akan terputus sebaik sahaja port ditukar.

Buka port pada kedua-dua firewall

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

Kedua-dua port perlu dibuka, dan kebanyakan penyedia perkhidmatan menjalankan firewall kedua dalam panel kawalan mereka yang tidak dikesan oleh ufw. Peraturan yang wujud pada pelayan tetapi tidak dalam panel menghasilkan jambatan yang tidak boleh dicapai dan tidak pernah menerbitkan deskriptor. Jika mana-mana bahagian ini baharu bagi anda, peraturan ufw yang diperlukan oleh VPS baharu dan apa itu port yang mendengar (listening port) pada Linux menerangkannya. Sementara anda berada di sana, kunci SSH dengan kunci (keys) dan konfigurasi sshd yang diperketatkan. Jambatan yang tidak disenaraikan pada kotak yang menggunakan kata laluan SSH masih merupakan kotak dengan kata laluan SSH.

Mulakan servis, kemudian baca log

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian dan Ubuntu membekalkan dua unit. tor.service ialah pembalut (wrapper) kecil dan tor@default.service ialah proses yang melakukan kerja tersebut, itulah sebabnya journalctl -u tor kelihatan hampir kosong manakala log yang anda perlukan berada di bawah tor@default.

Dua baris menunjukkan ia berjaya:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

Baris pertama bermaksud ujian kebolehcapaian telah lulus dan deskriptor telah dihantar kepada pihak berkuasa bridge. Jika ia tidak muncul, sesuatu antara internet dan pelayan anda sedang menyekat trafik ke ORPort. Baris kedua mesti menunjukkan port yang anda konfigurasi. Port yang berbeza di situ bermaksud tor tidak menggunakan ServerTransportListenAddr, dan punca lazimnya ialah nama pengangkutan yang tidak sepadan: ia mestilah tertulis obfs4 pada kedua-dua arahan.

Sahkan kedua-dua pendengar (listener) wujud:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

Di manakah talian bridge saya?

obfs4proxy menulis templat ke dalam direktori data tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Direktori tersebut dimiliki oleh pengguna tor dan mempunyai mod 700, jadi tanpa sudo anda akan mendapat Permission denied. Fail tersebut mengandungi satu talian dalam bentuk ini:

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

Gantikan <IP ADDRESS> dengan alamat awam pelayan anda, <PORT> dengan port obfs4 dan bukannya ORPort, dan <FINGERPRINT> dengan cap jari identiti yang ditulis oleh tor ke dalam direktori datanya:

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

Fail pertama mengandungi nama samaran dan cap jari identiti yang perlu diletakkan dalam talian bridge. Fail kedua mengandungi cap jari yang telah di-hash, iaitu apa yang anda tampal ke dalam Relay Search untuk melihat sama ada bridge anda sedang berjalan dan anggaran bilangan klien yang mencapainya. Kedua-duanya tidak boleh ditukar ganti. Talian bridge yang membawa nilai hash tidak sepadan dengan kunci identiti yang dibentangkan oleh bridge anda, jadi klien akan menolak sambungan yang baru dibuka itu.

Bagaimanakah jambatan (bridge) sebenarnya sampai kepada pengguna?

Anda tidak perlu memberikan talian jambatan anda kepada sesiapa. Sebaik sahaja deskriptor sampai kepada pihak berkuasa jambatan, sistem pengedaran (rdsys, pengganti kepada BridgeDB) akan menetapkan jambatan anda kepada salah satu pengedar, dan pengguna akan meminta jambatan daripada pengedar tersebut. Setakat Ogos 2026, laluan-laluan tersebut adalah seperti berikut:

• Borang web di bridges.torproject.org/options, yang memberikan talian jambatan selepas melengkapkan captcha.
• E-mel kepada bridges@torproject.org daripada alamat Gmail atau Riseup, yang akan membalas dengan talian jambatan. Sekatan penyedia ini wujud kerana akaun percuma tanpa had akan membolehkan pihak penapis menyenaraikan setiap jambatan.
• Bot Telegram @GetBridgesBot. Hantar /start, kemudian /obfs4 atau /webtunnel.
• Tor Browser itu sendiri, di bawah Settings kemudian Connection, di mana "Request bridges" akan mendapatkannya melalui saluran moat.

Jambatan baharu akan muncul dalam Relay Search kira-kira tiga jam selepas penyediaan. Pengguna mengambil masa yang lebih lama: menurut kenyataan rasmi Tor Project, "Ia boleh mengambil masa beberapa hari atau minggu sehingga anda melihat set pengguna yang konsisten." Tempoh dua minggu pertama yang sunyi adalah perkara biasa, bukan satu kerosakan.

Tetapan BridgeDistribution none akan membatalkan penyertaan daripada semua kaedah di atas. Talian jambatan tersebut kemudiannya menjadi milik anda untuk diberikan kepada mereka yang memerlukannya, melalui saluran yang tidak dipantau oleh pihak penapis.

Apabila sesuatu tidak berfungsi

Tiada baris ujian kendiri dalam log. ORPort tidak boleh dicapai. Uji port tersebut daripada mesin lain dengan nc -vz your.ip 8443. Jika sambungan tergantung, ini bermakna paket digugurkan; semak ufw dan panel kawalan pembekal pelayan anda. Jika sambungan ditolak, ini bermakna tor tidak mendengar pada port tersebut; semak ss -lntp dan baca log untuk mencari ralat konfigurasi.

Transport yang didaftarkan menunjukkan port yang tidak anda pilih. tor mengabaikan ServerTransportListenAddr. Nama transport mestilah sepadan dengan nama dalam ServerTransportPlugin, dan kedua-duanya mestilah obfs4.

obfs4proxy tidak dapat mengikat port 443. Sahkan keupayaan tersebut dengan getcap /usr/bin/obfs4proxy, kemudian sahkan bahawa override telah sampai ke unit dengan systemctl show tor@default -p NoNewPrivileges. Jika arahan tersebut mencetak NoNewPrivileges=yes, fail drop-in anda diletakkan pada unit yang tidak sedang berjalan.

Tiada apa-apa di dalam /var/lib/tor/pt_state/. tor tidak memulakan transport tersebut, yang bermakna laluan dalam ServerTransportPlugin adalah salah. Bandingkan laluan tersebut dengan output daripada command -v obfs4proxy.

Klien berhenti menyambung selepas perubahan dibuat. Sebarang perubahan pada alamat atau port obfs4 akan membatalkan setiap baris bridge yang telah diedarkan. Semak sama ada IP awam pelayan turut berubah, yang sering berlaku semasa proses bina semula (rebuild) dengan sesetengah pembekal.

tor tidak mahu bermula langsung. Jalankan sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Arahan ini akan menghuraikan fail konfigurasi, mencetak baris yang menyebabkan ralat, dan tidak akan mengganggu servis yang sedang berjalan.

FAQ

Adakah penyedia VPS saya akan membuat aduan tentang bridge Tor?

Bridge ialah titik masuk, jadi trafik yang keluar dari pelayan anda pergi ke relay Tor lain dan bukan ke tapak yang dipilih oleh pengguna. Alamat IP anda tidak muncul dalam log web sesiapa sebagai sumber permintaan, dan itulah yang menyebabkan aduan yang dihadapi oleh pengendali exit relay. Peraturan pengehosan masih berbeza-beza, dan sesetengah penyedia melayan mana-mana servis Tor sebagai kes khas, jadi baca polisi penggunaan yang boleh diterima sebelum anda bermula dan masukkan alamat yang anda baca ke dalam ContactInfo.

Berapakah lebar jalur yang digunakan oleh bridge Tor?

Minimum yang diterbitkan ialah 1 Mbit/s untuk muat naik dan muat turun, berbanding 10 Mbit/s untuk guard atau middle relay. Penggunaan sebenar bermula hampir sifar, kerana bridge anda hanya membawa trafik untuk pengguna yang dihantar oleh pengedar kepadanya. Jika anda mahukan had maksimum yang tetap, tetapkan RelayBandwidthRate dan RelayBandwidthBurst dalam torrc.

Mengapa tiada sesiapa yang menyambung ke bridge baharu saya?

Bridge mengambil masa kira-kira tiga jam untuk muncul dalam Relay Search, dan panduan Tor Project menyatakan bahawa set pengguna yang konsisten mengambil masa beberapa hari atau minggu. Semak sama ada deskriptor telah diterbitkan, iaitu baris ujian kendiri dalam journalctl -u tor@default, cari hashed fingerprint anda dalam Relay Search, dan sahkan BridgeDistribution tidak ditetapkan kepada none.

Patutkah saya menjalankan obfs4 atau WebTunnel?

Jalankan obfs4 jika ini adalah bridge pertama anda: satu VPS, dua port, tiada domain, tiada sijil. Jalankan WebTunnel di mana trafik yang kelihatan rawak disekat, kerana ia memerlukan domain yang anda kawal, pelayan web sebenar, sijil TLS yang sah, dan sekurang-kurangnya 1 GB RAM. Letakkannya pada alamat yang berasingan jika anda menjalankan kedua-duanya, kerana satu IP yang disekat akan menyebabkan dua bridge hilang sekaligus.

Apakah yang berlaku jika saya menukar port obfs4 kemudian?

Setiap baris bridge yang telah diedarkan akan berhenti berfungsi. Baris bridge mengikat alamat, port, fingerprint dan sijil bersama-sama, jadi pelanggan yang memegang baris lama akan membuka sambungan ke port yang tidak mempunyai pendengar dan akan berputus asa. Perkara yang sama berlaku apabila IP awam pelayan berubah. Pilih port semasa penyediaan dan jangan ubahnya.