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

หน้าที่ของ Tor relay บน VPS

Tor relay คือ Tor daemon ที่ทำงานบนเครื่องซึ่งมี public IP address ทำหน้าที่ส่งต่อทราฟฟิกที่เข้ารหัสให้กับผู้อื่น โดย directory authorities จะประกาศสถานะของ relay นี้ และ Tor clients จะสร้างวงจร (circuit) ผ่าน relay ดังกล่าว ทั้งนี้ guard relay หรือ middle relay จะส่งต่อทราฟฟิกไปยัง relay อื่นเท่านั้น จึงไม่มีการเปิดการเชื่อมต่อกับเว็บไซต์แทนบุคคลอื่น ข้อเท็จจริงนี้เองที่ทำให้ relay ประเภทนี้ไม่ได้รับอีเมลร้องเรียนเรื่องการละเมิด และเป็นเหตุผลว่าทำไมการรัน relay จึงเหมาะสมกับ VPS ทั่วไป

งานที่ต้องทำมีเพียงเล็กน้อย ได้แก่ การติดตั้งหนึ่งแพ็กเกจ, การตั้งค่าคอนฟิกประมาณ 15 บรรทัด, การกำหนดกฎ firewall หนึ่งรายการ และการรีสตาร์ทบริการ ส่วนที่เหลือของคู่มือนี้จะกล่าวถึงจุดที่มักเกิดปัญหา เช่น การคำนวณปริมาณแบนด์วิดท์บนแผนบริการที่มีการจำกัดการใช้งาน และเหตุผลที่ relay ใหม่ซึ่งทำงานปกติทุกอย่างอาจดูเหมือนหยุดทำงานไปในช่วงสัปดาห์แรก

เลือกบทบาท Guard, middle, bridge หรือ exit ก่อนติดตั้ง

daemon ตัวเดียวสามารถทำหน้าที่ได้ทั้ง 4 บทบาท การตั้งค่าของคุณรวมถึง directory authorities จะเป็นตัวกำหนดว่าคุณทำหน้าที่ใด

• Middle relay: รับ traffic จาก guard แล้วส่งต่อไปยัง relay อื่น โดยจะไม่ติดต่อกับเว็บไซต์ปลายทางโดยตรง Relay ใหม่ทุกตัวจะเริ่มต้นที่จุดนี้
• Guard relay: ใช้การตั้งค่าเดียวกันแต่มี flag กำกับเพิ่มเติม Directory authorities จะมอบ flag Guard ให้กับ relay ที่มีความเร็วและเสถียรภาพเพียงพอมาเป็นระยะเวลาหนึ่ง คุณไม่สามารถเลือกบทบาทนี้เองได้ แต่ต้องสร้างความน่าเชื่อถือจนได้รับสิทธิ์ ซึ่งการตั้งค่าด้านล่างนี้คือสิ่งที่ช่วยให้ได้รับ flag ดังกล่าว
• Bridge: relay ที่ถูกเก็บไว้เป็นความลับไม่ให้ปรากฏใน directory สาธารณะ และจะถูกส่งต่อให้ผู้ใช้ในพื้นที่ที่ Tor ถูกบล็อกเป็นการส่วนตัว นี่คือบทบาทที่มีภาระน้อยที่สุดในทั้ง 4 แบบ เนื่องจากใช้ bandwidth ต่ำ ไม่มีการประกาศชื่อต่อสาธารณะ และเป็นจุดเริ่มต้นที่เหมาะสมหากคุณมีทรัพยากรจำกัด
• Exit relay: จุดเชื่อมต่อสุดท้ายที่เปิดการเชื่อมต่อไปยังเว็บไซต์ปลายทาง ทุกคำขอของผู้ใช้จะออกจาก IP address ของคุณ ดังนั้นรายงานการละเมิดและหมายเรียกจากตำรวจจะถูกส่งมายังผู้ที่เป็นเจ้าของ IP นั้น

บทบาท exit ไม่เหมาะสำหรับการรันบน VPS ทั่วไป ควรใช้งาน exit relay บนผู้ให้บริการที่ตกลงยินยอมให้ทำเช่นนั้นล่วงหน้าเท่านั้น โดยต้องใช้ IP address ของตนเองและมีช่องทางติดต่อสำหรับแจ้งเหตุละเมิดที่ชัดเจน ข้อกำหนดการใช้งานของผู้ให้บริการมาตรฐานส่วนใหญ่ไม่อนุญาตให้ทำ exit relay และผลที่ตามมาจากการฝ่าฝืนมักคือการถูกระงับการใช้งานเซิร์ฟเวอร์และสูญเสีย IP address ในขณะที่ guard หรือ middle relay จะส่งผ่าน traffic ของผู้ใช้เช่นกันแต่ไม่มีความเสี่ยงทางกฎหมายเหล่านี้

เนื้อหาด้านล่างนี้เป็นการตั้งค่า guard/middle relay โดยบรรทัด ExitRelay 0 คือส่วนที่กำหนดบทบาทดังกล่าว

สิ่งที่ VPS จำเป็นต้องมีก่อนเริ่มต้น

Tor Project ได้กำหนดข้อกำหนดขั้นต่ำสำหรับการรัน relay ไว้ โดยข้อมูล ณ เดือนสิงหาคม 2026 มีดังนี้: ต้องมี IPv4 สาธารณะหนึ่งหมายเลขสำหรับ relay, มีแบนด์วิดท์อย่างน้อย 10 Mbit/s ในแต่ละทิศทาง (แนะนำที่ 16 Mbit/s), มีปริมาณการรับส่งข้อมูลขาออกอย่างน้อย 100 GB ต่อเดือน และมี RAM อย่างน้อย 512 MB สำหรับความเร็วต่ำกว่า 40 Mbit/s หรือ 1 GB สำหรับความเร็วที่สูงกว่านั้น แม้จะไม่มีกฎเกณฑ์เรื่อง uptime ที่ตายตัว แต่ relay ที่ทำงานน้อยกว่าสองชั่วโมงต่อวันแทบไม่มีประโยชน์ต่อเครือข่าย

ตัวเลข 10 Mbit/s หมายถึงขีดความสามารถของช่องสัญญาณ ไม่ใช่การตั้งค่าซอฟต์แวร์ คุณต้องมีพอร์ตที่รองรับความเร็วระดับนี้ ส่วนปริมาณแบนด์วิดท์ที่คุณจะอนุญาตให้ relay ใช้งานนั้นเป็นการตัดสินใจแยกต่างหาก ซึ่งต้องพิจารณาจากโควตาการรับส่งข้อมูลรายเดือน โปรดตรวจสอบรายละเอียดแพ็กเกจของคุณก่อนเริ่มแก้ไขไฟล์ config หากคุณยังอยู่ในขั้นตอนการเลือกเซิร์ฟเวอร์ ค่าใช้จ่ายจริงของ VPS ต่อเดือน จะอธิบายวิธีการขายโควตาการรับส่งข้อมูล และ การวัดปริมาณการรับส่งข้อมูลเครือข่ายจริงของ VPS จะแสดงวิธีทดสอบประสิทธิภาพของช่องสัญญาณด้วย iperf3 แทนการเชื่อข้อมูลจากหน้าเว็บขายสินค้า

ควรทำการ hardening เครื่องก่อนเสมอ เนื่องจาก relay เป็นบริการสาธารณะที่เปิดเผยหมายเลข IP ซึ่งจะถูกสแกนภายในไม่กี่นาทีหลังจากประกาศตัวบนเครือข่าย การจำกัดสิทธิ์ SSH ให้ใช้เฉพาะคีย์และการตั้งค่า sshd ให้ปลอดภัย ใช้เวลาเพียงสิบนาทีและควรทำก่อนที่จะเปิดใช้งาน relay ไม่ใช่ทำหลังจากนั้น

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

ให้ใช้ apt repository ของ Tor Project โดยตรงแทนการใช้แพ็กเกจจาก distribution เนื่องจากโค้ดของ relay มีการพัฒนาเร็วกว่ารุ่น stable ทำให้การแก้ไขข้อผิดพลาดต่างๆ จะถูกส่งมายัง repository นี้ก่อน ในขณะที่แพ็กเกจของ distribution มักจะล้าหลังกว่าในระหว่างรอบการปล่อยเวอร์ชัน

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

เพิ่ม signing key จากนั้นจึงเพิ่ม repository โดยระบบจะอ่าน codename จากเครื่องโดยอัตโนมัติ ดังนั้นคำสั่งชุดเดียวกันนี้จึงสามารถใช้ได้ทั้งบน Ubuntu 24.04 (noble) และ Debian 13 (trixie)

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
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
tor --version

tor --version จะแสดงเวอร์ชันที่คุณเพิ่งติดตั้ง หาก apt update แสดงข้อผิดพลาด NO_PUBKEY แสดงว่า dearmored key ไม่ได้อยู่ที่ path ที่ระบุในบรรทัด Signed-By: ทำให้ apt ไม่มี key สำหรับตรวจสอบไฟล์ release แพ็กเกจ deb.torproject.org-keyring มีความสำคัญในภายหลัง เนื่องจากแพ็กเกจนี้จะติดตั้ง signing key ในรูปแบบแพ็กเกจปกติ เพื่อให้ apt ยังคงทำงานได้ตามปกติเมื่อมีการหมุนเวียน (rotate) key ดังกล่าว

เปิดใช้งานการอัปเกรดอัตโนมัติ จากนั้นกำหนดค่าให้ระบบรู้จัก origin ใหม่นี้

sudo apt install -y unattended-upgrades apt-listchanges

บน Ubuntu ให้เพิ่ม Tor origin ลงในบล็อก Allowed-Origins ในไฟล์ /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

บน Debian ไฟล์เดียวกันจะใช้ Origins-Pattern โดยบรรทัดที่ต้องเพิ่มคือ "origin=TorProject"; ตรวจสอบผลลัพธ์ด้วย sudo unattended-upgrade --debug --dry-run ซึ่งจะแสดงรายการ origin ที่ระบบจะดำเนินการและไม่เขียนข้อมูลใดๆ ออกมาหากไม่มีข้อผิดพลาด

ไฟล์ torrc ที่สำคัญ

แพ็กเกจจะติดตั้งไฟล์ /etc/tor/torrc ที่มีความยาวและมีคำอธิบายประกอบจำนวนมากมาให้ แต่มีเพียงไม่กี่บรรทัดเท่านั้นที่จำเป็นสำหรับการทำ relay ให้เพิ่มบรรทัดเหล่านี้ไว้ที่ส่วนท้ายของไฟล์

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname ต้องมีความยาว 1 ถึง 19 ตัวอักษร ประกอบด้วยตัวอักษรและตัวเลขเท่านั้น ชื่อนี้ไม่จำเป็นต้องไม่ซ้ำกับ relay อื่นในเครือข่ายและไม่ใช่ตัวระบุตัวตนของคุณ (ตัวระบุตัวตนที่แท้จริงคือ fingerprint) ชื่อนี้ใช้สำหรับค้นหา relay ของคุณในช่องค้นหา ดังนั้นควรเลือกชื่อที่สะกดได้ง่ายเมื่อต้องแจ้งผ่านทางโทรศัพท์

ContactInfo จะถูกเผยแพร่ไว้ใน relay descriptor ซึ่งเป็นเอกสารสาธารณะที่ทุกคนสามารถดาวน์โหลดได้ ดังนั้นที่อยู่อีเมลนี้จะถูกเก็บรวบรวมโดยบอท (scrape) ควรใช้อีเมลที่คุณจะยังคงใช้งานได้ในอีก 2 ปีข้างหน้า และสามารถใช้วิธีพรางที่อยู่ได้หากต้องการ นี่เป็นช่องทางเดียวที่ Tor Project จะใช้แจ้งเตือนคุณหากพบปัญหาเกี่ยวกับ relay ของคุณ

ORPort 9001 คือพอร์ตที่ relay และ client อื่นๆ ใช้เชื่อมต่อเข้ามา พอร์ต 9001 เป็นค่ามาตรฐานที่นิยมใช้ ส่วนพอร์ต 443 เป็นอีกตัวเลือกที่พบบ่อย เนื่องจากเครือข่ายที่มีข้อจำกัดบางแห่งอนุญาตให้เชื่อมต่อขาออกได้เฉพาะพอร์ต 443 เท่านั้น ดังนั้น relay ที่เปิดพอร์ตนี้จึงเข้าถึงได้โดย client จำนวนมากกว่า ให้เลือกใช้พอร์ต 443 ก็ต่อเมื่อไม่มีบริการอื่นบนเครื่องที่จำเป็นต้องใช้พอร์ตนี้

SocksPort 0 ใช้สำหรับปิดการทำงานของ SOCKS proxy ในเครื่อง ซึ่ง relay ไม่จำเป็นต้องใช้ และช่วยลดจำนวน listening socket บนเครื่องลงหนึ่งรายการ ส่วน ExitRelay 0 เป็นการระบุเจตนาลงในไฟล์ว่า relay นี้จะไม่เชื่อมต่อไปยังปลายทางแทนผู้ใช้งาน และช่วยให้ผู้ที่มาอ่านไฟล์ config ในภายหลังไม่ต้องเสียเวลาคาดเดาจากค่าเริ่มต้น

หาก VPS ของคุณมีที่อยู่ IPv6 ให้เพิ่มบรรทัด ORPort บรรทัดที่สอง Tor ไม่สามารถ bind เข้ากับที่อยู่ IPv6 แบบ "any" ได้เหมือนกับ IPv4 ดังนั้นคุณต้องระบุที่อยู่ IPv6 ไว้ในวงเล็บก้ามปู

ORPort 9001
ORPort [2001:db8::1]:9001

บน VPS ขนาด 1 GB ให้เพิ่ม MaxMemInQueues 512 MB เข้าไป Tor จะตัดสินใจกำหนดขีดจำกัดของคิวจากหน่วยความจำที่มองเห็นบนเครื่อง ซึ่งบนเครื่อง shared box ขนาดเล็กนั้นอาจมากกว่าที่คุณต้องการให้มันใช้งาน การกำหนดขีดจำกัดด้วยตนเองจะทำให้ tor ยอมทิ้งข้อมูลในคิว (queued cells) เมื่อเกิดสภาวะโหลดสูง ซึ่ง relay จะยังคงทำงานต่อไปได้ แทนที่จะปล่อยให้หน่วยความจำเพิ่มขึ้นเรื่อยๆ จนกระทั่ง kernel สั่ง kill กระบวนการทำงานทิ้ง

เปิดพอร์ต ORPort ในไฟร์วอลล์

สำหรับการเชื่อมต่อขาเข้า พอร์ต ORPort จะต้องสามารถเข้าถึงได้จากทุกที่บนอินเทอร์เน็ต สำหรับการเชื่อมต่อขาออก ให้ปล่อยให้ relay ทำงานโดยไม่มีข้อจำกัด เนื่องจาก relay จะเปิดการเชื่อมต่อกับ relay อื่นๆ อีกหลายพันรายการผ่านพอร์ตที่หลากหลาย และการกำหนด allowlist สำหรับขาออกจะทำให้ relay ทำงานไม่ได้อย่างเงียบเชียบ

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

จากนั้นให้ตรวจสอบไฟร์วอลล์เครือข่ายของผู้ให้บริการ แผงควบคุมหลายแห่งมีการทำงานของ packet filter อยู่หน้าเครื่อง virtual machine ซึ่งกฎที่คุณเพิ่มผ่าน ufw จะไม่มีผลในส่วนนั้น ส่งผลให้พอร์ตแสดงสถานะว่าเปิดอยู่เมื่อตรวจสอบจากภายในเครื่อง แต่แสดงว่าปิดอยู่เมื่อตรวจสอบจากภายนอก หากคุณยังไม่คุ้นเคยกับ ufw บทความ กฎ ufw ที่ควรมีบนทุก VPS จะอธิบายถึงนโยบายเริ่มต้นและลำดับการจับคู่กฎต่างๆ ไว้ให้แล้ว

กำหนดขนาดแบนด์วิดท์ให้เหมาะสมกับแผนของคุณ

คู่มืออธิบายว่า RelayBandwidthRate คือ token bucket แยกต่างหากที่จำกัด "แบนด์วิดท์ขาเข้าเฉลี่ยสำหรับการรับส่งข้อมูลผ่านโหนดนี้ให้เป็นจำนวนไบต์ต่อวินาทีตามที่ระบุ และจำกัดแบนด์วิดท์ขาออกเฉลี่ยให้เป็นค่าเดียวกัน" โปรดอ่านข้อความนี้ซ้ำอีกครั้ง ขีดจำกัดดังกล่าวใช้แยกกันในแต่ละทิศทาง Relay ที่ตั้งค่าไว้ที่ 1 Mbit/s สามารถรับส่งข้อมูลขาเข้า 1 Mbit/s และขาออก 1 Mbit/s ได้พร้อมกัน และผู้ให้บริการที่คิดค่าบริการทั้งสองทิศทางจะเรียกเก็บเงินจากผลรวมของทั้งสองค่า

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

5 แถวเหล่านั้นเป็นเพียงการคำนวณทางคณิตศาสตร์ ไม่ใช่การวัดผลจริง โดยแสดงให้เห็นว่าอัตราการใช้งานจะมีค่าใช้จ่ายเท่าใดหาก Relay ทำงานต่อเนื่องเต็ม 30 วันในทั้งสองทิศทาง Relay จริงมักจะทำงานต่ำกว่าขีดจำกัดที่ตั้งไว้เกือบตลอดเวลา โดยเฉพาะในช่วงสัปดาห์แรกๆ ให้ใช้ตารางนี้เพื่อตัดตัวเลือกการตั้งค่าที่ไม่เหมาะสมออก ไม่ใช่เพื่อคาดการณ์ยอดเรียกเก็บเงินให้แม่นยำถึงระดับกิกะไบต์

ที่อัตรา 1 Mbit/s ในแต่ละทิศทาง Relay จะรับส่งข้อมูลประมาณ 21.6 GB ต่อวัน ดังนั้นในหนึ่งเดือนที่มี 30 วัน จะใช้ปริมาณข้อมูลที่ถูกคิดค่าบริการประมาณ 648 GB ซึ่งยังอยู่ในขีดจำกัด 1 TB โดยมีพื้นที่เหลือสำหรับการอัปเดตและสำรองข้อมูล หากปรับเพิ่มเป็น 2 Mbit/s ค่าใช้จ่ายรายเดือนจะอยู่ที่ 1,296 GB ซึ่งเกินแผน 1 TB ไปแล้ว ส่วนแถวสุดท้าย 20 Mbit/s ต้องการปริมาณข้อมูล 12,960 GB ต่อเดือน ซึ่งควรใช้กับพอร์ตแบบไม่จำกัดปริมาณข้อมูล (unmetered) หากผู้ให้บริการของคุณคิดค่าบริการเฉพาะขาออก ให้หารตัวเลขทุกตัวด้วยสอง ตรวจสอบให้แน่ใจว่าผู้ให้บริการของคุณคิดค่าบริการอย่างไรก่อนตั้งค่าอัตรา เพราะคำตอบทั้งสองแบบแตกต่างกันถึงสองเท่า

ต่อไปคือการตั้งค่าคอนฟิก ให้ตั้งค่าอัตราจำกัด (rate limit) ก่อน แล้วจึงตั้งค่าโควตา (quota)

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst คือขนาดของ token bucket ซึ่งช่วยให้เกิดการใช้งานพุ่งสูงขึ้นชั่วคราวเหนืออัตราที่กำหนดได้ในขณะที่ค่าเฉลี่ยยังคงอยู่ในเกณฑ์ ค่าที่เหมาะสมคือประมาณสองเท่าของอัตราที่ตั้งไว้

AccountingRule คือบรรทัดที่ผู้ดูแลระบบส่วนใหญ่มักมองข้าม ค่าเริ่มต้นคือ max ซึ่งจะวัดปริมาณข้อมูลจากทิศทางที่มากกว่าระหว่างขาเข้าและขาออกเทียบกับโควตา ด้วยค่าเริ่มต้นนี้ AccountingMax 400 GBytes จะอนุญาตให้รับข้อมูลได้ 400 GB และส่งข้อมูลได้ 400 GB ซึ่งรวมเป็น 800 GB หากผู้ให้บริการนับรวมทั้งสองทิศทาง ส่วน AccountingRule sum จะนับผลรวมของข้อมูลขาเข้าและขาออกเทียบกับโควตาเดียว ซึ่งเป็นวิธีที่การจำกัดปริมาณข้อมูล (transfer allowance) ใช้งานจริง

ให้ระบุ AccountingStart ไว้ด้วยเสมอ ห้ามใส่เฉพาะ AccountingMax เพียงอย่างเดียว โควตาคือตัวเลข และบรรทัดเริ่มต้นคือช่วงเวลาที่จะรีเซ็ตโควตา หากตั้งโควตาโดยไม่มีช่วงเวลา Relay จะเข้าสู่สถานะจำศีล (hibernation) และไม่มีทางกลับมาทำงานได้อีก

การจำศีลเป็นเครื่องมือที่ค่อนข้างรุนแรง เมื่อโควตาหมดลง tor จะบันทึก log และหยุดรับงาน:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

Relay จะไม่ตื่นขึ้นมาทำงานทันทีที่เริ่มรอบใหม่ Tor จะติดตามว่าโควตารอบที่แล้วถูกใช้หมดเร็วแค่ไหน และจะสุ่มเวลาในช่วงเริ่มต้นของรอบใหม่ เพื่อป้องกันไม่ให้ Relay นับพันโหนดกลับเข้าสู่เครือข่ายพร้อมกันในวินาทีเดียว Relay ที่หายไปในช่วงสัปดาห์สุดท้ายของทุกเดือนจะสูญเสียค่าความเสถียร (stability) ที่ directory authorities ใช้ในการวัดผล ดังนั้นควรตั้งค่า RelayBandwidthRate ให้ไม่ถึงขีดจำกัด และใช้ AccountingMax เป็นตัวป้องกันสุดท้ายเพื่อควบคุมค่าใช้จ่ายของคุณ

เริ่มการทำงานของ relay และตรวจสอบว่าสามารถเข้าถึงได้

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

ภายในเวลาไม่กี่นาที log ควรจะปรากฏข้อความนี้:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

ประโยคดังกล่าวหมายความว่า relay อื่นๆ ได้เชื่อมต่อกลับมายัง ORPort ของคุณและสร้างวงจรผ่าน relay ของคุณแล้ว หากข้อความนี้ยังไม่ปรากฏ แสดงว่า relay ของคุณยังไม่อยู่ใน directory และยังไม่มีการรับส่งข้อมูลใดๆ หากเกิดความล้มเหลว ข้อความจะแสดงดังนี้:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

ให้ตรวจสอบตามลำดับดังนี้: ตรวจสอบว่า ORPort ถูกเปิดใช้งานใน ufw แล้วหรือไม่ และตรวจสอบว่ามีการเปิดพอร์ตใน firewall ของผู้ให้บริการแยกต่างหากด้วยหรือไม่ ตรวจสอบว่าที่อยู่ในข้อความนั้นเป็นที่อยู่ที่อินเทอร์เน็ตสามารถเข้าถึงได้จริง ไม่ใช่ที่อยู่ภายใน (private address) จากการตั้งค่า NAT ทดสอบพอร์ตจากเครื่องอื่นด้วย nc -vz 203.0.113.10 9001 ตัว Tor จะทำการทดสอบตัวเองซ้ำโดยอัตโนมัติ ดังนั้นหากแก้ไข firewall แล้วระบบจะตรวจพบได้เองโดยไม่ต้องดำเนินการใดๆ เพิ่มเติม หรือคุณสามารถ restart เพื่อให้ระบบตรวจสอบทันที

ตัวตนถาวรของ relay ของคุณคือ fingerprint:

sudo cat /var/lib/tor/fingerprint

ประมาณสามชั่วโมงหลังจาก descriptor ถูกเผยแพร่ relay ของคุณจะปรากฏบน Relay Search ให้ค้นหาด้วยชื่อเล่น (nickname) หรือวาง fingerprint ลงในช่องค้นหา หน้าเว็บดังกล่าวจะแสดงข้อมูลที่เครือข่ายรับรู้เกี่ยวกับ relay ของคุณ เช่น flag ที่ได้รับ น้ำหนักที่ authorities มอบให้ และเวอร์ชันที่กำลังเผยแพร่ใช้งานอยู่

เหตุใด Tor relay ใหม่จึงแทบไม่มี traffic ผ่านเลย

เนื่องจากเครือข่ายยังไม่ได้วัดผลประสิทธิภาพของ relay นั้น และกระบวนการวัดผลต้องใช้เวลาหลายสัปดาห์ Tor Project ได้อธิบายขั้นตอนการเพิ่มขึ้นของ traffic ไว้เป็น 4 ระยะ ซึ่งผู้ดูแลระบบที่ไม่ได้อ่านข้อมูลส่วนนี้มักสรุปเอาเองว่า relay มีปัญหาและเริ่มเข้าไปแก้ไขการตั้งค่าต่างๆ

ในช่วง 3 วันแรก relay จะยังไม่ถูกวัดผล โดยจะรายงานผลการทดสอบตัวเอง และ directory authorities จะจำกัด bandwidth ที่ประกาศไว้ที่ 20 KB ทำให้ client แทบไม่เลือกใช้งาน relay นี้เลย ตั้งแต่วันที่ 3 ถึงวันที่ 8 bandwidth authorities จะเริ่มวัดผลจริงและค่า weight จะค่อยๆ เพิ่มขึ้น แต่ relay จะถูกใช้เป็นเพียง middle hop เท่านั้น เนื่องจากไม่มี client รายใดต้องการใช้ relay ใหม่เป็น first hop ของตน

เมื่อถึงประมาณวันที่ 8 relay จะมีคุณสมบัติได้รับ Guard flag การได้รับ flag นี้จะทำให้ traffic ลดลง ซึ่งเป็นเรื่องที่น่าประหลาดใจสำหรับทุกคน เนื่องจาก client จะข้าม relay ที่เป็น guard ไปเมื่อต้องเลือก middle hop เพราะสันนิษฐานว่า guard น่าจะยุ่งอยู่แล้ว ส่งผลให้ relay สูญเสีย traffic ในส่วนของ middle hop ไปก่อนที่จะได้รับ traffic ในส่วนของ guard เข้ามาแทนที่ ซึ่ง traffic จะค่อยๆ เพิ่มขึ้นเมื่อ client หมุนเวียนชุด guard ของตนเอง ซึ่งต้องใช้เวลาหลายสัปดาห์ จนกระทั่งถึงประมาณวันที่ 68 relay จึงจะเข้าสู่สภาวะคงที่ (steady state) ซึ่งเป็นจุดที่จำนวน client ที่เลิกใช้งานและจำนวน client ที่เพิ่มเข้ามาใหม่มีความสมดุลกัน

ดังนั้น ความคาดหวังที่เป็นจริงคือ จะไม่มี traffic เลยในช่วง 3 วันแรก จะเริ่มมี traffic บ้างหลังจากผ่านไปหนึ่งสัปดาห์ และจะมี load การใช้งานจริงหลังจากผ่านไปสองเดือน หากคุณปรับเปลี่ยนการตั้งค่าใดๆ ให้รอหนึ่งสัปดาห์เพื่อดูผลลัพธ์ หน้าสถานะ Uptime Kuma ที่โฮสต์เอง พร้อมการตรวจสอบ TCP ที่พอร์ต 9001 เป็นการใช้พลังงานจากความกังวลให้เกิดประโยชน์มากกว่า เพราะมันช่วยตอบคำถามที่คุณสามารถควบคุมได้จริง นั่นคือพอร์ตยังคงตอบสนองอยู่หรือไม่

การตรวจสอบ relay ด้วย nyx

nyx คือเครื่องมือตรวจสอบผ่านเทอร์มินัลสำหรับ relay ที่กำลังทำงานอยู่ โดยจะสื่อสารผ่าน control port ของ tor ดังนั้นคุณต้องเปิดใช้งานพอร์ตนี้ใน torrc ก่อน:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort จะรับฟังเฉพาะที่ 127.0.0.1 เท่านั้น และการยืนยันตัวตนด้วย cookie หมายความว่าโปรแกรมจะต้องอ่านไฟล์ลับก่อนจึงจะสามารถส่งคำสั่งได้ Tor จะเขียน cookie ดังกล่าวลงใน /run/tor/control.authcookie ในฐานะผู้ใช้ debian-tor โดยกำหนดสิทธิ์เป็น 600 เพื่อไม่ให้ผู้อื่นอ่านได้ CookieAuthFileGroupReadable 1 จะเปิดสิทธิ์ให้กลุ่มผู้ใช้เข้าถึงไฟล์นี้ได้ ซึ่งเป็นสิ่งที่ช่วยให้บัญชีผู้ใช้ของคุณสามารถเรียกใช้งาน nyx ได้โดยไม่ต้องใช้ sudo

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

ให้ทำการออกจากระบบแล้วเข้าสู่ระบบใหม่ จากนั้นจึงเรียกใช้งาน nyx การที่ต้องล็อกอินใหม่เนื่องจากกลุ่มผู้ใช้ใหม่จะถูกโหลดเมื่อเริ่มเซสชันการใช้งานเท่านั้น หากคุณเรียกใช้งาน nyx ใน shell เดิมที่เปิดค้างไว้จะเกิดข้อผิดพลาดเรื่องสิทธิ์ในการเข้าถึงไฟล์ cookie แม้ว่าการตั้งค่าจะถูกต้องแล้วก็ตาม nyx จะแสดงข้อมูลแบนด์วิดท์แบบเรียลไทม์, ระยะเวลาการทำงาน (uptime), กระแส log และรายการการเชื่อมต่อ ในช่วงสัปดาห์แรกๆ ตัวเลขที่คุณควรเฝ้าระวังคือกราฟแบนด์วิดท์ว่ายังคงอยู่ภายใต้ค่า RelayBandwidthRate ของคุณหรือไม่

การรัน Relay มากกว่าหนึ่งตัว: MyFamily และ family keys

หากคุณรัน Relay เพียงตัวเดียว ให้ข้ามส่วนนี้ไป หากคุณเป็นผู้ดูแล Relay ตั้งแต่สองตัวขึ้นไป คุณต้องประกาศให้ Relay เหล่านั้นรู้จักกัน เพื่อป้องกันไม่ให้ไคลเอนต์สร้างวงจร (circuit) ที่เข้าและออกจากเครือข่ายผ่านเครื่องของคุณทั้งสองฝั่ง ซึ่งจะทำให้ผู้ดูแลระบบคนเดียวสามารถมองเห็นข้อมูลได้ทั้งต้นทางและปลายทาง

วิธีมาตรฐานที่ใช้กันมานานคือการตั้งค่า MyFamily ในไฟล์ torrc ของ Relay ทุกตัว โดยระบุ fingerprint ของ Relay ตัวอื่นๆ ทั้งหมดไว้ดังนี้:

MyFamily AAAAAAAAAA,BBBBBBBB

เนื่องจาก Relay ทุกตัวต้องระบุ Relay ตัวอื่นทั้งหมด การเพิ่ม Relay ตัวที่สี่จึงหมายถึงการต้องแก้ไขไฟล์ถึงสี่ไฟล์ Tor เวอร์ชัน 0.4.9 ได้เปลี่ยนมาใช้ family key แทน ให้คุณสร้างกุญแจขึ้นมาหนึ่งชุดแล้วแชร์ไปยัง Relay อื่นๆ:

tor --keygen-family myfamily

คำสั่งดังกล่าวจะเขียนไฟล์ myfamily.secret_family_key และแสดงบรรทัด FamilyId ออกมา ให้คัดลอกไฟล์กุญแจไปยัง Relay ทุกตัว โดยวางไว้ในไดเรกทอรีย่อย keys ภายใน DataDirectory (คือ /var/lib/tor/keys บน Debian และ Ubuntu) โดยต้องคงนามสกุลไฟล์เป็น .secret_family_key ไว้ จากนั้นเพิ่มบรรทัด FamilyId ที่แสดงผลออกมาลงในไฟล์ torrc ของแต่ละตัว แล้วทำการ reload ด้วยคำสั่ง sudo systemctl reload tor@default ในระหว่างนี้ให้คงรายการ MyFamily ไว้เช่นเดิมก่อน เนื่องจากไคลเอนต์ที่ยังไม่รองรับ family certificates จะยังคงอ่านรายการแบบเดิมอยู่ และทาง Tor Project จะประกาศให้ทราบอีกครั้งเมื่อสามารถเลิกใช้งานรายการดังกล่าวได้

สิ่งที่อาจขัดข้องหลังจากเริ่มทำงานแล้ว

เวอร์ชันล้าสมัย ระบบ unattended upgrades จะแทนที่แพ็กเกจให้ แต่กระบวนการที่ทำงานอยู่จะยังคงใช้ไฟล์ binary เดิมที่เริ่มทำงานจนกว่าจะมีสิ่งใดไปสั่ง restart ให้เปรียบเทียบค่า tor --version บนเครื่องกับเวอร์ชันที่แสดงบนหน้า Relay Search ของ relay หากค่าไม่ตรงกัน เครือข่ายจะยังคงเห็นเวอร์ชันเก่าอยู่ ดังนั้นให้ทำการ restart บริการ

นาฬิกาเดินไม่ตรง เอกสาร consensus และใบรับรองทั้งหมดมีเงื่อนไขเรื่องเวลา ดังนั้นเครื่องที่นาฬิกาเดินผิดไปมากจะปฏิเสธ consensus และหยุดการเผยแพร่ข้อมูล timedatectl ควรรายงานว่านาฬิกาของระบบมีการซิงโครไนซ์แล้ว หากไม่เป็นเช่นนั้น ให้เปิดใช้งาน systemd-timesyncd หรือติดตั้ง chrony

ที่อยู่ IP เปลี่ยนแปลง descriptor จะระบุที่อยู่เอาไว้ และไคลเอนต์จะไม่สามารถเข้าถึงที่อยู่ที่เปลี่ยนไปได้ หลังจากย้ายผู้ให้บริการหรือเปลี่ยนที่อยู่ ให้ restart tor และคอยสังเกตบรรทัดการทดสอบตัวเอง (self-test) อีกครั้ง

relay ทำงานช้ากว่าที่วางแผนไว้ ระบบเข้ารหัสของ Tor relay มีประสิทธิภาพบนโปรเซสเซอร์สมัยใหม่ โดย Tor Project ประเมินว่า CPU ที่รองรับ AES-NI จะทำความเร็วได้ประมาณ 400 ถึง 450 Mbit/s ในแต่ละทิศทาง ก่อนที่จะถึงขีดจำกัดดังกล่าว คุณจะถูกจำกัดด้วยความเร็วพอร์ตและปริมาณการรับส่งข้อมูลที่ได้รับอนุญาต ซึ่งเป็นเหตุผลว่าทำไมส่วนการจัดการบัญชี (accounting) ด้านบนจึงมีความสำคัญมากกว่าฮาร์ดแวร์

FAQ

Tor relay ใช้แบนด์วิดท์เท่าไร?

ใช้เท่าที่คุณอนุญาตและไม่เกินนั้น RelayBandwidthRate จะจำกัดปริมาณการรับส่งข้อมูลในแต่ละทิศทางแยกกัน ดังนั้น relay ที่ตั้งค่าไว้ที่ 1 Mbit/s จะสามารถรับข้อมูลเข้า 1 Mbit/s และส่งข้อมูลออก 1 Mbit/s ได้พร้อมกัน ซึ่งคิดเป็นประมาณ 21.6 GB ต่อวัน หรือ 648 GB ต่อเดือน (30 วัน) โดยนับรวมทั้งสองทิศทาง คุณสามารถเพิ่ม AccountingMax พร้อมกับ AccountingRule sum เพื่อกำหนดโควตาการใช้งานรายเดือนแบบตายตัวภายใต้ขีดจำกัดดังกล่าวได้

การรัน Tor relay จะทำให้ได้รับอีเมลร้องเรียนเรื่องการละเมิดหรือไม่?

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

ทำไม Tor relay ใหม่ของฉันถึงไม่มีทราฟฟิกเลย?

เนื่องจาก relay ใหม่จะถูกจำกัดความเร็วตามการออกแบบจนกว่าจะได้รับการวัดผล ในช่วง 3 วันแรก directory authorities จะจำกัดน้ำหนัก (weight) ที่ประกาศไว้ที่ 20 KB ทำให้ client แทบไม่เลือกใช้ relay ของคุณ หลังจากนั้นประมาณวันที่ 3 bandwidth authorities จะเริ่มวัดผล และ relay จะมีสิทธิ์ได้รับ Guard flag ในช่วงประมาณวันที่ 8 ซึ่งทราฟฟิกอาจลดลงอีกครั้งเนื่องจาก client จะหลีกเลี่ยงการใช้ Guard relay ในตำแหน่ง middle hop ของวงจร โดยทราฟฟิกจะเข้าสู่ระดับปกติเต็มที่ในช่วงประมาณวันที่ 68 ให้ตรวจสอบว่า log แสดงข้อความ "Self-testing indicates your ORPort is reachable from the outside" แล้วปล่อยให้ระบบทำงานไปตามปกติ

ฉันสามารถรัน Tor relay บน VPS ที่มีโควตาการโอนถ่ายข้อมูล 1 TB ได้หรือไม่?

ได้ ที่ความเร็วประมาณ 1 Mbit/s ในแต่ละทิศทาง ซึ่งคิดเป็น RelayBandwidthRate 125 KBytes โดยจะใช้ข้อมูลประมาณ 648 GB ต่อเดือน หากผู้ให้บริการของคุณนับรวมทั้งสองทิศทาง ซึ่งยังเหลือพื้นที่สำหรับการอัปเดตและสำรองข้อมูล ให้เพิ่ม AccountingMax 400 GBytes พร้อมกับ AccountingRule sum และ AccountingStart month 1 00:00 เพื่อให้ relay เข้าสู่โหมดจำศีล (hibernate) แทนที่จะใช้งานเกินแผนที่กำหนดไว้ หากผู้ให้บริการคิดค่าบริการเฉพาะขาออก คุณสามารถเพิ่มความเร็วได้เป็นสองเท่า

ฉันจำเป็นต้องตั้งค่า MyFamily หรือไม่หากรัน relay เพียงตัวเดียว?

ไม่จำเป็น การประกาศ Family มีไว้เพื่อให้ client หลีกเลี่ยงการสร้างวงจรผ่าน relay สองตัวที่ดำเนินการโดยผู้ดูแลคนเดียวกัน ซึ่งไม่มีผลใดๆ หากคุณมี relay เพียงตัวเดียว ให้ตั้งค่าทันทีที่คุณเพิ่ม relay ตัวที่สอง โดยระบุ fingerprint ของ relay ทุกตัวลงในบรรทัด MyFamily ของ relay แต่ละตัว หรือใช้ family key ที่แนะนำใน Tor 0.4.9 ซึ่งจะใช้เพียง FamilyId เดียวแทนการระบุรายการที่ยาวขึ้นเรื่อยๆ