วิธีตั้งค่า Tor bridge ด้วย obfs4 บน VPS อย่างละเอียด

Tor bridge คืออะไรและทำไมจึงต้องมี

Tor bridge คือจุดเชื่อมต่อเข้าสู่เครือข่าย Tor ที่ไม่มีการประกาศที่อยู่ไว้ในรายการ relay สาธารณะ รายการดังกล่าวที่เรียกว่า consensus เป็นเอกสารที่มีการลงลายมือชื่อซึ่งใครก็สามารถดาวน์โหลดได้ และผู้เซ็นเซอร์ก็ดาวน์โหลดได้เช่นกัน การบล็อก Tor จากรายการนี้ใช้เวลาเพียงช่วงบ่าย: เพียงแค่ดึงข้อมูล consensus มา แล้วทำการดร็อปทุกที่อยู่ที่อยู่ในนั้นที่ชายแดนเครือข่าย สาเหตุที่มี bridge อยู่ก็เพราะรายการที่ประกาศไว้นั้นเป็นจุดอ่อน ที่อยู่ของ bridge จะถูกแจกจ่ายออกไปทีละน้อย ดังนั้นการร้องขอเพียงครั้งเดียวจึงไม่สามารถดึงข้อมูลทั้งหมดไปได้

ที่อยู่ที่ไม่ได้อยู่ในรายการเป็นเพียงคำตอบครึ่งเดียวเท่านั้น การตรวจสอบแพ็กเก็ตเชิงลึก (Deep packet inspection หรือ DPI) ซึ่งจำแนกประเภททราฟฟิกตามเนื้อหาแทนที่จะเป็นที่อยู่ สามารถระบุการเชื่อมต่อ Tor ได้จากรูปแบบของ TLS (transport layer security) handshake ผู้เซ็นเซอร์ที่ไม่มีรายการที่อยู่ก็ยังสามารถมองเห็นได้ว่า "นี่ดูเหมือน Tor" แล้วทำการดร็อปการเชื่อมต่อทิ้งไป Pluggable transport จะช่วยกำจัดสัญญาณดังกล่าว โดยจะทำการห่อหุ้มสตรีมของ Tor ไว้ด้วยรูปแบบอื่นที่ฝั่งไคลเอนต์ และ bridge ของคุณจะทำหน้าที่แกะห่อหุ้มนั้นออก

obfs4 เป็น transport ที่ bridge ส่วนใหญ่ใช้งาน มันจะเปลี่ยนสตรีมให้กลายเป็นไบต์ที่ไม่มีส่วนหัวและไม่มี handshake ที่ตายตัว ทำให้ DPI ไม่มีรูปแบบให้ตรวจจับได้ นอกจากนี้ยังมีการยืนยันตัวตนของไคลเอนต์ด้วย ค่า cert= ที่อยู่ในบรรทัดของ bridge คือคีย์ที่ไคลเอนต์ต้องพิสูจน์ว่าตนถือครองอยู่ก่อนที่ bridge จะตอบสนอง ซึ่งช่วยป้องกันการตรวจสอบเชิงรุก (active probing): ผู้เซ็นเซอร์ที่พยายามเชื่อมต่อเข้ามายังที่อยู่ของคุณเพื่อทดสอบว่ามีการสื่อสารด้วย Tor หรือไม่ จะไม่ได้รับคำตอบใดๆ และไม่สามารถเรียนรู้อะไรได้เลย

คุณควรใช้งาน Pluggable Transport แบบใด?

• obfs4 ต้องใช้ VPS 1 เครื่อง, TCP พอร์ต 2 พอร์ต และไม่จำเป็นต้องมีชื่อโดเมน นี่เป็นสิ่งที่ใช้งานได้จริงและติดตั้งง่ายที่สุด ซึ่งเป็นหัวข้อหลักของคู่มือฉบับนี้
• WebTunnel จะซ่อนการเชื่อมต่อไว้ภายในทราฟฟิก HTTPS ปกติที่ส่งไปยังเว็บไซต์จริง Tor Project ระบุข้อกำหนดไว้ว่าต้องมี IPv4 address แบบคงที่, โดเมนที่คุณเป็นเจ้าของ, เว็บเซิร์ฟเวอร์ที่ทำงานได้ปกติ เช่น NGINX หรือ Apache, ใบรับรอง TLS ที่ถูกต้อง และ RAM อย่างน้อย 1 GB (แนะนำที่ 4 GB) วิธีนี้เหมาะสำหรับเครือข่ายที่ทราฟฟิกซึ่งดูผิดปกติจะถูกเพ่งเล็งเป็นพิเศษ เนื่องจากประเทศที่อนุญาตให้เข้าถึงได้เพียงแค่การท่องเว็บทั่วไป ก็ยังคงอนุญาตให้ใช้งาน HTTPS ได้
• Snowflake เป็นการสนับสนุนในรูปแบบที่ต่างออกไป อาสาสมัครจะรัน WebRTC proxy ที่มีอายุการใช้งานสั้น ทำให้จุดเชื่อมต่อเปลี่ยนไปเรื่อยๆ และไม่มีที่อยู่คงที่ให้ผู้เซ็นเซอร์บล็อกได้ คุณไม่จำเป็นต้องดูแลบริดจ์สำหรับ Snowflake แต่คุณสามารถรัน proxy ได้โดยไม่ต้องใช้ที่อยู่แบบคงที่

ให้เริ่มต้นที่ obfs4 คุณสามารถเพิ่ม WebTunnel bridge ในภายหลังได้โดยใช้ที่อยู่อีกชุดหนึ่ง การรันทั้งสองอย่างบน IP เดียวกันจะทำให้หากที่อยู่นั้นถูกบล็อก บริการทั้งสองก็จะใช้งานไม่ได้พร้อมกัน

การรัน 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
  }
]

ณ เดือนสิงหาคม 2026 ทาง Tor Project กำหนดให้ bridge ต้องมีแบนด์วิดท์ขาขึ้นและขาลงอย่างน้อย 1 Mbit/s สำหรับ guard หรือ middle relay จะต้องมีแบนด์วิดท์อย่างน้อย 10 Mbit/s โดยแนะนำที่ 16 Mbit/s ข้อกำหนดเหล่านี้เป็นเกณฑ์ที่ประกาศไว้ ไม่ใช่การวัดผลจริง โดยปกติแล้ว bridge ใหม่มักจะมีปริมาณการใช้งานต่ำกว่าเกณฑ์ขั้นต่ำเป็นเวลาหลายสัปดาห์ หน้าข้อกำหนดเดียวกันยังระบุว่า relay ควรมีปริมาณการรับส่งข้อมูลขาออกอย่างน้อย 100 GByte ต่อเดือน ซึ่งแผนบริการขนาดเล็กที่สุดก็ครอบคลุมส่วนนี้อยู่แล้ว ดังนั้นโปรดอ่าน ค่าใช้จ่ายจริงต่อเดือนของ VPS ขนาดเล็ก ก่อนที่คุณจะเลือกขนาดเซิร์ฟเวอร์ที่ใหญ่กว่านั้น

ความเสี่ยงจากการถูกร้องเรียนเรื่องการใช้งานในทางที่ผิด (abuse) นั้นมีน้อย ซึ่งเป็นจุดที่คนส่วนใหญ่มักเข้าใจผิด bridge ทำหน้าที่เป็นโหนดแรก (first hop) เท่านั้น ข้อมูลที่ออกจากเซิร์ฟเวอร์ของคุณจะถูกส่งต่อไปยัง Tor relay อื่น ไม่ใช่ไปยังเว็บไซต์ที่ผู้ใช้เลือกโดยตรง ดังนั้น IP address ของคุณจะไม่ปรากฏใน log ของเว็บไซต์ปลายทางในฐานะแหล่งที่มาของคำขอ ทำให้คุณจะไม่ได้รับอีเมลร้องเรียนแบบที่ผู้ดูแล exit relay ต้องเผชิญ อย่างไรก็ตาม ควรตรวจสอบนโยบายการใช้งานที่ยอมรับได้ (acceptable use policy) ของผู้ให้บริการของคุณด้วย เนื่องจากผู้ให้บริการบางรายอาจถือว่าบริการ Tor ทุกประเภทเป็นกรณีพิเศษ

สิ่งที่ไม่ควรทำคือการเปลี่ยน public relay ที่มีอยู่เดิมให้กลายเป็น bridge โดยใช้ IP address เดิม คำแนะนำของ Tor Project สำหรับกรณีนี้คือให้เปลี่ยน "IP address, ชื่อ และ fingerprint" เนื่องจาก address เดิมอยู่ในรายการ consensus ที่ผู้เซ็นเซอร์ดาวน์โหลดไปใช้งานแล้ว bridge ที่เคยเป็น public relay เมื่อสัปดาห์ก่อนถือเป็น bridge ที่ติดอยู่ในรายการบล็อกเรียบร้อยแล้ว

ความต่อเนื่องในการทำงาน (uptime) สำคัญกว่าความเร็ว ข้อกำหนดของ relay ระบุว่า "หาก relay ของคุณหยุดทำงานเกิน 2 ชั่วโมงต่อวัน ประโยชน์ในการใช้งานจะลดลง" ซึ่ง bridge จะได้รับผลกระทบมากกว่า relay เนื่องจากผู้ใช้แต่ละรายมีเพียง address เดียวและไม่มีช่องทางสำรอง การรีสตาร์ทแต่ละครั้งจะทำให้ผู้ใช้ทุกคนที่เชื่อมต่ออยู่หลุดทันที ควรตั้งค่า การตรวจสอบ TCP port ใน Uptime Kuma สำหรับพอร์ต obfs4 เพื่อให้คุณทราบทันทีในวันที่มันหยุดตอบสนอง

การติดตั้ง Tor จาก repository ของ Tor Project

แพ็กเกจใน distribution มักจะล้าหลังกว่าเวอร์ชันปัจจุบัน ในขณะที่ 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 โดยบรรทัด Suites: จะต้องระบุ codename ของ release ที่คุณใช้งานอยู่ ดังนั้นให้อ่านค่าจากระบบแทนการพิมพ์เองจากความจำ

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 ไม่มีไฟล์ Release สำหรับ codename ของคุณ แสดงว่า Tor Project ไม่ได้รองรับ release นั้น ให้ลบ /etc/apt/sources.list.d/tor.sources แล้วรัน sudo apt update อีกครั้ง จากนั้นจึงติดตั้งแพ็กเกจ tor ที่มาพร้อมกับ distribution ของคุณ ขั้นตอนหลังจากนี้จะเหมือนกันทั้งหมด

แพ็กเกจ obfs4proxy มาจากตัว Debian และ Ubuntu เอง (เวอร์ชัน 0.0.14 ใน Debian 13 ณ เดือนสิงหาคม 2026) ให้ตรวจสอบว่าไฟล์ binary ถูกติดตั้งไว้ที่ใด เนื่องจากต้องนำ path ไปใช้ในไฟล์ config:

command -v obfs4proxy || command -v lyrebird

ทางต้นน้ำได้เปลี่ยนชื่อโครงการเป็น lyrebird ดังนั้นแพ็กเกจที่ใหม่กว่าอาจติดตั้ง /usr/bin/lyrebird แทน ให้ใช้ path ใดก็ตามที่คำสั่งดังกล่าวแสดงผลออกมา

กำหนดค่า bridge ใน /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

ทุกบรรทัดในไฟล์มีโอกาสเกิดข้อผิดพลาดได้ ดังนั้นควรตรวจสอบทีละบรรทัด

BridgeRelay 1 สั่งให้ tor ส่ง descriptor ไปยัง bridge authority แทนที่จะส่งไปยัง public consensus บรรทัดนี้เพียงบรรทัดเดียวคือสิ่งที่ทำให้ relay ของคุณไม่ปรากฏในรายการสาธารณะ

ORPort คือพอร์ตหลักของ Tor ซึ่งจำเป็นต้องเข้าถึงได้จากอินเทอร์เน็ต เนื่องจาก tor จะทำการทดสอบพอร์ตนี้และปฏิเสธที่จะเผยแพร่ descriptor จนกว่าการทดสอบจะผ่าน

ServerTransportPlugin คือคำสั่งที่ใช้รัน tor โดย tor จะเริ่มการทำงานของ obfs4proxy ในฐานะ child process และสื่อสารผ่าน pipe ดังนั้น obfs4proxy จึงไม่มี service unit ของตัวเองและจะไม่ปรากฏใน systemctl status

ServerTransportListenAddr คือการกำหนดพอร์ตที่ obfs4proxy จะรับฟัง หากละเว้นบรรทัดนี้ obfs4proxy จะสุ่มเลือกพอร์ตว่างเมื่อเริ่มทำงาน และอาจเปลี่ยนพอร์ตใหม่หลังจากการรีสตาร์ทส่วนใหญ่ ส่งผลให้ bridge line ที่คุณแจกจ่ายไปก่อนหน้าชี้ไปยังพอร์ตที่ไม่มีการรับฟังข้อมูล ส่งผลให้ไคลเอนต์เหล่านั้นได้รับข้อผิดพลาดการเชื่อมต่อถูกปฏิเสธและหยุดพยายามเชื่อมต่อ

ExtORPort auto คือการเปิดใช้งาน extended ORPort ซึ่งเป็นช่องทาง loopback ที่ obfs4proxy ใช้ส่งต่อการเชื่อมต่อที่เสร็จสมบูรณ์กลับไปยัง tor พร้อมกับที่อยู่ของไคลเอนต์ คู่มือการติดตั้งของ The Tor Project แนะนำให้ใส่บรรทัดนี้ไว้ใน bridge ทุกตัว เพราะหากไม่มีบรรทัดนี้ transport จะไม่สามารถรายงานที่อยู่ดังกล่าวไปยัง tor ได้

ContactInfo และ Nickname เป็นข้อมูลสาธารณะ ควรใช้ที่อยู่อีเมลที่คุณตรวจสอบเป็นประจำ เนื่องจากเป็นช่องทางที่ The Tor Project จะติดต่อคุณหาก bridge มีปัญหา และเลือกชื่อเล่นที่ไม่ระบุตัวตนหากคุณต้องการความเป็นส่วนตัว

BridgeDistribution คือการเลือกผู้แจกจ่าย (distributor) ที่จะส่งที่อยู่ของคุณให้กับผู้ใช้ ค่าที่ยอมรับได้คือ https, email, telegram, settings, none และ any ให้ใช้ any สำหรับ bridge ตัวแรกและปล่อยให้ระบบเป็นผู้ตัดสินใจ หรือใช้ none สำหรับ bridge ส่วนตัวที่คุณแจกจ่ายด้วยตนเอง ซึ่งจะช่วยป้องกันไม่ให้ที่อยู่ของคุณถูกนำไปเผยแพร่ในระบบสาธารณะโดยสิ้นเชิง

เหตุผลที่การเลือกพอร์ตมีความสำคัญ

หลีกเลี่ยงการใช้ 9001 สำหรับพอร์ตทั้งสองรายการ Tor Project ระบุไว้ชัดเจนว่า 9001 เป็น ORPort แบบดั้งเดิม ซึ่งผู้เซ็นเซอร์มักสแกนอินเทอร์เน็ตเพื่อหาพอร์ตนี้ พอร์ตทั้งสองต้องแตกต่างกันเนื่องจาก tor และ obfs4proxy ต่างก็ผูก listener ของตนเอง

พอร์ตสำหรับ obfs4 ที่ดีที่สุดคือ 443 เนื่องจากพอร์ต 443 ขาออกเปิดใช้งานอยู่เกือบทุกเครือข่ายที่มีข้อจำกัด และการเชื่อมต่อที่ยาวนานผ่านพอร์ตนี้จะดูเหมือนเซสชันเว็บทั่วไป การผูกพอร์ตที่ต่ำกว่า 1024 ต้องมีขั้นตอนเพิ่มเติมเนื่องจาก obfs4proxy ไม่ได้ทำงานในฐานะ root:

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

เพิ่มสองบรรทัดนี้ในโปรแกรมแก้ไขข้อความแต่ละตัวที่เปิดขึ้นมา:

[Service]
NoNewPrivileges=no

ความสามารถ (capability) เพียงอย่างเดียวไม่เพียงพอ NoNewPrivileges ของ systemd จะป้องกันไม่ให้กระบวนการได้รับสิทธิ์ใดๆ ที่กระบวนการแม่ไม่มี และ file capability ก็คือสิทธิ์ดังกล่าว ส่งผลให้ obfs4proxy ไม่สามารถผูกพอร์ต 443 ได้หากยังเปิดการตั้งค่านี้อยู่

หากคุณต้องการข้ามขั้นตอนนี้ ให้เลือกพอร์ตสูงที่ไม่มีความโดดเด่นและจดบันทึกไว้ ไม่ว่าคุณจะเลือกพอร์ตใด ห้ามเปลี่ยนพอร์ต obfs4 ในภายหลัง เนื่องจาก bridge line จะผูกที่อยู่ พอร์ต fingerprint และใบรับรองเข้าด้วยกัน ดังนั้นทุกสำเนาที่อยู่ในเบราว์เซอร์ของผู้ใช้จะใช้งานไม่ได้ทันทีที่พอร์ตเปลี่ยนไป

เปิดพอร์ตบนไฟร์วอลล์ทั้งสองฝั่ง

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

คุณจำเป็นต้องเปิดพอร์ตทั้งสองพอร์ต โดยผู้ให้บริการส่วนใหญ่จะมีไฟร์วอลล์ชั้นที่สองในแผงควบคุม (control panel) ซึ่ง ufw ไม่สามารถรับรู้ได้ กฎที่ตั้งค่าไว้ในเซิร์ฟเวอร์แต่ไม่ได้ตั้งค่าในแผงควบคุมจะทำให้เกิด bridge ที่ไม่สามารถเข้าถึงได้และไม่เผยแพร่ descriptor หากคุณยังไม่คุ้นเคยกับเรื่องนี้ กฎ ufw ที่ VPS ใหม่จำเป็นต้องมี และ พอร์ตที่กำลังฟังอยู่ (listening port) บน Linux คืออะไร จะช่วยอธิบายรายละเอียดให้คุณ ในระหว่างนี้ ควรจำกัดสิทธิ์ SSH ด้วยการใช้คีย์และการตั้งค่า sshd ให้ปลอดภัย เพราะ bridge ที่ไม่ได้ระบุไว้บนเซิร์ฟเวอร์ที่ยังใช้รหัสผ่าน SSH ก็เท่ากับว่าเซิร์ฟเวอร์นั้นยังคงใช้รหัสผ่าน SSH อยู่ดี

เริ่มการทำงานและอ่าน log

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

Debian และ Ubuntu มี unit ให้ใช้งานสองตัว tor.service เป็น wrapper ขนาดเล็ก และ tor@default.service เป็นกระบวนการที่ทำงานจริง นี่คือสาเหตุที่ 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'

บรรทัดแรกหมายความว่าการทดสอบการเข้าถึงผ่านไปได้ด้วยดี และ descriptor ได้ถูกส่งไปยัง bridge authority แล้ว หากข้อความนี้ไม่ปรากฏขึ้น แสดงว่ามีบางอย่างระหว่างอินเทอร์เน็ตกับเซิร์ฟเวอร์ของคุณที่บล็อก traffic ไปยัง ORPort บรรทัดที่สองต้องแสดงพอร์ตที่คุณตั้งค่าไว้ หากแสดงเป็นพอร์ตอื่น หมายความว่า tor ไม่ได้นำ ServerTransportListenAddr ไปใช้ ซึ่งสาเหตุที่พบบ่อยคือชื่อ transport ไม่ตรงกัน โดยชื่อจะต้องระบุเป็น obfs4 ในทั้งสองคำสั่ง

ตรวจสอบว่ามี listener ทั้งสองตัวทำงานอยู่จริง:

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

Bridge line ของฉันอยู่ที่ไหน

obfs4proxy จะเขียนเทมเพลตลงในไดเรกทอรีข้อมูลของ tor:

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

ไดเรกทอรีดังกล่าวเป็นกรรมสิทธิ์ของผู้ใช้ tor และมีโหมด 700 ดังนั้นหากไม่มี sudo คุณจะได้รับ Permission denied ไฟล์นี้จะมีบรรทัดในรูปแบบดังนี้:

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

ให้แทนที่ <IP ADDRESS> ด้วยที่อยู่สาธารณะของเซิร์ฟเวอร์คุณ แทนที่ <PORT> ด้วยพอร์ตของ obfs4 (ไม่ใช่ ORPort) และแทนที่ <FINGERPRINT> ด้วย identity fingerprint ที่ tor เขียนไว้ในไดเรกทอรีข้อมูล:

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

ไฟล์แรกจะเก็บชื่อเล่นและ identity fingerprint ซึ่งเป็นสิ่งที่ต้องอยู่ใน bridge line ส่วนไฟล์ที่สองจะเก็บ hashed fingerprint ซึ่งเป็นสิ่งที่คุณต้องนำไปวางใน Relay Search เพื่อตรวจสอบว่า bridge ของคุณกำลังทำงานอยู่หรือไม่ และมีไคลเอนต์เชื่อมต่อเข้ามาประมาณกี่ราย ทั้งสองไฟล์นี้ไม่สามารถใช้แทนกันได้ หาก bridge line มีค่า hashed fingerprint จะไม่ตรงกับ identity key ที่ bridge ของคุณนำเสนอ ส่งผลให้ไคลเอนต์ปฏิเสธการเชื่อมต่อที่เพิ่งเปิดขึ้นมานั้น

Bridge เข้าถึงผู้ใช้งานได้อย่างไร

คุณไม่จำเป็นต้องส่ง bridge line ให้ใครด้วยตนเอง เมื่อ descriptor ไปถึง bridge authority ระบบการแจกจ่าย (rdsys ซึ่งเป็นระบบที่มาแทนที่ BridgeDB) จะกำหนด bridge ของคุณให้กับผู้จัดจำหน่ายรายหนึ่ง และผู้ใช้งานจะร้องขอ bridge จากผู้จัดจำหน่ายรายนั้น ณ เดือนสิงหาคม 2026 เส้นทางการเข้าถึงมีดังนี้:

• เว็บฟอร์มที่ bridges.torproject.org/options ซึ่งจะแสดง bridge line หลังจากผ่านการตรวจสอบ captcha
• การส่งอีเมลไปที่ bridges@torproject.org จากบัญชี Gmail หรือ Riseup ซึ่งจะได้รับ bridge line ตอบกลับมา ข้อจำกัดเรื่องผู้ให้บริการมีไว้เพื่อป้องกันไม่ให้ผู้เซ็นเซอร์ใช้บัญชีฟรีที่สมัครได้ไม่จำกัดในการไล่ตรวจสอบ bridge ทุกตัว
• Telegram bot ที่ @GetBridgesBot โดยส่งคำสั่ง /start จากนั้นเลือก /obfs4 หรือ /webtunnel
• Tor Browser โดยไปที่ Settings แล้วเลือก Connection จากนั้นใช้ตัวเลือก "Request bridges" เพื่อดึงข้อมูลผ่านช่องทาง moat

Bridge ใหม่จะปรากฏใน Relay Search หลังจากตั้งค่าไปแล้วประมาณ 3 ชั่วโมง แต่สำหรับผู้ใช้งานนั้นต้องใช้เวลานานกว่ามาก โดยทาง Tor Project ระบุว่า "อาจต้องใช้เวลาหลายวันหรือหลายสัปดาห์กว่าที่คุณจะเห็นจำนวนผู้ใช้งานที่สม่ำเสมอ" การที่ไม่มีผู้ใช้งานในช่วงสองสัปดาห์แรกถือเป็นเรื่องปกติ ไม่ใช่ความผิดพลาดของระบบ

การตั้งค่า BridgeDistribution none จะเป็นการยกเลิกการเข้าร่วมระบบแจกจ่ายทั้งหมด ในกรณีนี้ bridge line จะเป็นของคุณโดยสมบูรณ์ ซึ่งคุณสามารถส่งต่อให้ผู้ที่ต้องการใช้งานผ่านช่องทางที่ผู้เซ็นเซอร์ไม่สามารถตรวจสอบได้

เมื่อมีบางอย่างไม่ทำงาน

ไม่มีบรรทัดการทดสอบตัวเองใน log แสดงว่า ORPort ไม่สามารถเข้าถึงได้ ให้ทดสอบจากเครื่องอื่นด้วย nc -vz your.ip 8443 หากค้างแสดงว่าแพ็กเก็ตถูกทิ้ง ให้ตรวจสอบ ufw และแผงควบคุมของผู้ให้บริการ หากถูกปฏิเสธการเชื่อมต่อแสดงว่า tor ไม่ได้เปิดฟังอยู่ ให้ตรวจสอบ ss -lntp และอ่าน log เพื่อดูข้อผิดพลาดในการตั้งค่า

Transport ที่ลงทะเบียนไว้แสดงพอร์ตที่คุณไม่ได้เลือก tor ได้ละเว้น ServerTransportListenAddr ชื่อของ transport ต้องตรงกับที่ระบุใน ServerTransportPlugin อย่างถูกต้อง และทั้งคู่ต้องเป็น obfs4

obfs4proxy ไม่สามารถ bind พอร์ต 443 ได้ ให้ยืนยันความสามารถด้วย getcap /usr/bin/obfs4proxy จากนั้นยืนยันว่าการ override ไปถึง unit แล้วด้วย systemctl show tor@default -p NoNewPrivileges หากคำสั่งแสดงผลเป็น NoNewPrivileges=yes แสดงว่า drop-in ของคุณถูกส่งไปยัง unit ที่ไม่ได้กำลังทำงานอยู่

ไม่มีข้อมูลภายใน /var/lib/tor/pt_state/ tor ไม่เคยเริ่มการทำงานของ transport ซึ่งหมายความว่า path ใน ServerTransportPlugin ไม่ถูกต้อง ให้เปรียบเทียบกับผลลัพธ์ของ command -v obfs4proxy

ไคลเอนต์หยุดเชื่อมต่อหลังจากมีการเปลี่ยนแปลง การเปลี่ยนแปลงใดๆ ต่อที่อยู่หรือพอร์ต obfs4 จะทำให้ bridge line ทุกบรรทัดที่แจกจ่ายไปแล้วใช้งานไม่ได้ ให้ตรวจสอบว่า IP สาธารณะของเซิร์ฟเวอร์มีการเปลี่ยนแปลงด้วยหรือไม่ ซึ่งมักเกิดขึ้นเมื่อมีการสร้างเซิร์ฟเวอร์ใหม่กับผู้ให้บริการบางราย

tor ไม่เริ่มทำงานเลย ให้รัน sudo -u debian-tor tor --verify-config -f /etc/tor/torrc คำสั่งนี้จะตรวจสอบไฟล์ แสดงบรรทัดที่พบปัญหา และไม่ส่งผลกระทบต่อ service ที่กำลังทำงานอยู่

FAQ

ผู้ให้บริการ VPS จะร้องเรียนเรื่อง Tor bridge ของฉันหรือไม่

Bridge เป็นเพียงจุดเริ่มต้นของการเชื่อมต่อ ดังนั้นทราฟฟิกที่ออกจากเซิร์ฟเวอร์ของคุณจะไปยัง Tor relay อื่นๆ เท่านั้น และไม่ได้ไปยังเว็บไซต์ที่ผู้ใช้เลือกเข้าชม ที่อยู่ IP ของคุณจะไม่ปรากฏใน log ของเว็บไซต์ใดๆ ในฐานะแหล่งที่มาของคำขอ ซึ่งเป็นสาเหตุที่ทำให้ผู้ให้บริการ relay แบบ exit ต้องเผชิญกับข้อร้องเรียน อย่างไรก็ตาม กฎการใช้งานยังคงแตกต่างกันไปในแต่ละที่ และผู้ให้บริการบางรายถือว่าบริการ Tor ทุกประเภทเป็นกรณีพิเศษ ดังนั้นโปรดอ่านนโยบายการใช้งานที่ยอมรับได้ (Acceptable Use Policy) ก่อนเริ่มต้น และระบุที่อยู่อีเมลที่คุณตรวจสอบเป็นประจำไว้ใน ContactInfo

Tor bridge ใช้แบนด์วิดท์มากน้อยเพียงใด

ข้อกำหนดขั้นต่ำที่ประกาศไว้คือ 1 Mbit/s สำหรับขาขึ้นและขาลง ซึ่งเทียบกับ 10 Mbit/s สำหรับ guard หรือ middle relay การใช้งานจริงจะเริ่มต้นที่ใกล้ศูนย์ เนื่องจาก bridge ของคุณจะส่งผ่านทราฟฟิกเฉพาะสำหรับผู้ใช้ที่ระบบจัดสรรมาให้เท่านั้น หากคุณต้องการจำกัดเพดานการใช้งาน ให้ตั้งค่า RelayBandwidthRate และ RelayBandwidthBurst ในไฟล์ torrc

ทำไมไม่มีใครเชื่อมต่อกับ bridge ใหม่ของฉันเลย

Bridge จะใช้เวลาประมาณสามชั่วโมงในการปรากฏบน Relay Search และตามคำแนะนำของ Tor Project การจะมีกลุ่มผู้ใช้ที่สม่ำเสมอต้องใช้เวลาหลายวันหรือหลายสัปดาห์ ให้ตรวจสอบว่ามีการประกาศ descriptor แล้ว ซึ่งดูได้จากบรรทัดการทดสอบตัวเองใน journalctl -u tor@default จากนั้นค้นหา hashed fingerprint ของคุณใน Relay Search และยืนยันว่า BridgeDistribution ไม่ได้ถูกตั้งค่าเป็น none

ฉันควรใช้ obfs4 หรือ WebTunnel

หากนี่เป็น bridge แรกของคุณ ให้ใช้ obfs4 ซึ่งใช้เพียงหนึ่ง VPS, สองพอร์ต, ไม่ต้องใช้โดเมน และไม่ต้องใช้ใบรับรอง ส่วน WebTunnel เหมาะสำหรับกรณีที่ทราฟฟิกที่ดูเหมือนสุ่มถูกบล็อก เนื่องจากต้องใช้โดเมนที่คุณควบคุม, เว็บเซิร์ฟเวอร์จริง, ใบรับรอง TLS ที่ถูกต้อง และ RAM อย่างน้อย 1 GB หากคุณต้องการรันทั้งสองอย่าง ให้แยกที่อยู่ IP กัน เพราะหาก IP หนึ่งถูกบล็อก จะทำให้ bridge ทั้งสองตัวใช้งานไม่ได้พร้อมกัน

จะเกิดอะไรขึ้นหากฉันเปลี่ยนพอร์ตของ obfs4 ในภายหลัง

Bridge line ทุกชุดที่แจกจ่ายไปแล้วจะหยุดทำงานทันที เนื่องจาก bridge line จะผูกที่อยู่ IP, พอร์ต, fingerprint และใบรับรองเข้าด้วยกัน ดังนั้นไคลเอนต์ที่ถือ bridge line ชุดเก่าจะพยายามเชื่อมต่อไปยังพอร์ตที่ไม่มีบริการใดๆ รอรับอยู่และจะล้มเหลวในที่สุด กรณีนี้รวมถึงเมื่อที่อยู่ IP สาธารณะของเซิร์ฟเวอร์มีการเปลี่ยนแปลงด้วย ดังนั้นควรเลือกพอร์ตให้เหมาะสมตั้งแต่ขั้นตอนการติดตั้งและไม่ควรเปลี่ยนแปลงหลังจากนั้น