SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-28

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

เรียนรู้วิธีติดตั้ง Tor relay บน Linux VPS พร้อมการตั้งค่าไฟล์ torrc การจำกัด Bandwidth สำหรับแพ็กเกจเน็ตจำกัด และการตรวจสอบสถานะด้วย nyx รวมถึงวิธีรับมือช่วง slow consensus

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

Tor relay คือ Tor daemon ที่รันอยู่บนเครื่องที่มี public IP address ทำหน้าที่ส่งต่อทราฟฟิกที่เข้ารหัสให้กับผู้อื่น โดย directory authorities จะประกาศ relay ของคุณให้เป็นที่รู้จัก และ Tor clients จะสร้างวงจร (circuit) ผ่าน relay นี้ ทั้งนี้ guard หรือ middle relay จะส่งต่อทราฟฟิกไปยัง relay อื่นเท่านั้น จึงไม่เคยเปิดการเชื่อมต่อกับเว็บไซต์โดยตรงในนามของผู้อื่น ข้อเท็จจริงนี้เองที่ทำให้ relay ไม่ได้รับอีเมลร้องเรียนเรื่องการละเมิด (abuse mail) และเป็นเหตุผลว่าทำไมการรัน relay จึงเหมาะสมกับ VPS ทั่วไป เนื่องจาก relay ทำหน้าที่เพียงส่งต่อทราฟฟิกของผู้อื่นและไม่ได้เผยแพร่เนื้อหาของตนเอง หากคุณต้องการนำเว็บไซต์ของตนเองเข้าสู่เครือข่ายแทนที่จะเป็นเพียงตัวกลางส่งผ่านข้อมูล การรัน v3 onion service หลัง nginx จะเป็นงานที่แตกต่างออกไปแม้จะใช้ Tor daemon ตัวเดียวกันก็ตาม นอกจากนี้ การรัน relay ไม่ได้ช่วยเพิ่มความเป็นส่วนตัวในการท่องเว็บของคุณ ซึ่งเป็นปัญหาแยกต่างหากที่มีขอบเขตจำกัดกว่าที่หลายคนคาดคิด โดย สิ่งที่การ self-host SearXNG ปิดบังได้จริง เป็นตัวชี้วัดที่ดีว่าการย้ายบริการมาไว้บน VPS ของคุณเองนั้นช่วยได้มากน้อยเพียงใด

งานที่ต้องทำมีเพียงเล็กน้อย ได้แก่ การติดตั้งหนึ่งแพ็กเกจ, การตั้งค่าคอนฟิกประมาณสิบห้าบรรทัด, การเพิ่มกฎ 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 ต่ำ ไม่มีการแสดงชื่อในรายการสาธารณะ และเป็นก้าวแรกที่เหมาะสมหากคุณมีทรัพยากรจำกัด นอกจากนี้ยังต้องรัน obfs4 proxy ควบคู่ไปกับ daemon และใช้ชุดคำสั่งใน torrc ที่แตกต่างออกไป ซึ่ง การตั้งค่า obfs4 bridge บน VPS ราคาประหยัด จะอธิบายขั้นตอนทั้งหมด รวมถึงวิธีการส่ง bridge line ให้ผู้ใช้ในตอนท้าย
  • Exit relay: จุดเชื่อมต่อสุดท้ายที่เปิดการเชื่อมต่อกับเว็บไซต์ปลายทาง ทุกคำขอที่ผู้ใช้ทำจะออกจาก IP address ของคุณ ดังนั้นรายงานการละเมิดและหมายเรียกจากตำรวจจะถูกส่งไปยังผู้ที่เป็นเจ้าของ IP นั้น

Exit relay เป็นบทบาทเดียวที่ไม่ควรใช้งานบน VPS ทั่วไป คุณควรใช้งาน exit relay เฉพาะกับผู้ให้บริการที่ตกลงยินยอมล่วงหน้าว่าจะรับอีเมลแจ้งเตือนการละเมิด โดยต้องใช้ IP address ของตนเองและมีช่องทางติดต่อสำหรับแจ้งเหตุละเมิดที่ชัดเจน ข้อกำหนดการใช้งานของโฮสติ้งส่วนใหญ่ไม่อนุญาตให้ทำเช่นนี้ และผลลัพธ์ที่มักเกิดขึ้นหากเพิกเฉยคือเซิร์ฟเวอร์ถูกระงับและสูญเสีย IP address หากคุณยังต้องการทำหน้าที่นี้ สิ่งที่ต้องทำจริงในการรัน exit relay จะครอบคลุมถึงการหาโฮสต์ที่รองรับ exit relay, การเขียน exit policy และ reverse DNS รวมถึงการตอบกลับอีเมลเมื่อมีรายงานเข้ามา ส่วน guard หรือ middle relay จะส่งผ่าน traffic ของผู้ใช้เช่นเดียวกันโดยไม่มีความเสี่ยงเหล่านี้

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

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

Tor Project ได้กำหนดข้อกำหนดขั้นต่ำสำหรับ relay ไว้ โดยข้อมูล ณ เดือนสิงหาคม 2026 มีดังนี้: ต้องมีที่อยู่ IPv4 สาธารณะ 1 หมายเลขสำหรับ 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 ต่อเดือน จะอธิบายวิธีการขายโควตาการรับส่งข้อมูล และ การวัด throughput ของเครือข่าย VPS จริง จะแสดงวิธีตรวจสอบประสิทธิภาพของช่องสัญญาณด้วย iperf3 แทนการเชื่อข้อมูลจากหน้าเว็บขายสินค้า

ควรเสริมความปลอดภัยให้กับเครื่องก่อนเป็นอันดับแรก เนื่องจาก relay เป็นบริการสาธารณะบนที่อยู่สาธารณะ ซึ่งที่อยู่ดังกล่าวจะถูกสแกนภายในไม่กี่นาทีหลังจากประกาศออกไป การ จำกัดการเข้าถึง 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 ยังคงทำงานได้ตามปกติเมื่อมีการหมุนเวียน 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 ซึ่งเป็นเอกสารสาธารณะที่ใครก็สามารถดาวน์โหลดได้ ดังนั้นที่อยู่อีเมลนี้จะถูกบอทเก็บข้อมูลไปใช้ ควรใช้อีเมลที่คุณจะยังคงใช้งานได้ในอีก 2 ปีข้างหน้า และคุณสามารถใช้วิธีเขียนแบบ obfuscate หากต้องการ นี่เป็นช่องทางเดียวที่ 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 address ให้เพิ่มบรรทัด ORPort บรรทัดที่สอง Tor ไม่สามารถ bind เข้ากับ "ทุก" IPv6 address ได้เหมือนกับ IPv4 ดังนั้นคุณต้องระบุ address นั้นไว้ในวงเล็บก้ามปู

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

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

เปิดใช้งาน ORPort ในไฟร์วอลล์

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

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

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

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

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

ChartMonthly traffic at a sustained relay rate, both directions, 30 days
The data behind this chart
[
  {
    "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) หากผู้ให้บริการของคุณคิดค่าบริการเฉพาะขาออก ให้หารตัวเลขทุกตัวด้วยสอง ตรวจสอบให้แน่ใจว่าผู้ให้บริการของคุณคิดค่าบริการอย่างไรก่อนตั้งค่าอัตรา เพราะคำตอบทั้งสองแบบแตกต่างกันถึงสองเท่า

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

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

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

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

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

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

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

Relay จะไม่ตื่นขึ้นมาทำงานทันทีที่เริ่มรอบใหม่ Tor จะติดตามว่า quota รอบที่แล้วถูกใช้หมดไปเร็วแค่ไหน และจะสุ่มเวลาในช่วงรอบใหม่ เพื่อป้องกันไม่ให้ 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

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

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

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

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

เมื่อถึงประมาณวันที่ 8 relay จะมีคุณสมบัติได้รับ Guard flag การได้รับ flag นี้จะทำให้ traffic ลดลง ซึ่งเป็นเรื่องที่น่าประหลาดใจสำหรับทุกคน เนื่องจาก client จะข้าม 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 ในเซสชันเดิมจะเกิดข้อผิดพลาดเรื่องสิทธิ์ในการเข้าถึงไฟล์ cookie แม้ว่าการตั้งค่าจะถูกต้องแล้วก็ตาม nyx จะแสดงข้อมูลแบนด์วิดท์แบบเรียลไทม์, ระยะเวลาการทำงาน (uptime), กระแส log และรายการการเชื่อมต่อ ในช่วงสัปดาห์แรกๆ ตัวเลขที่ควรเฝ้าระวังคือกราฟแบนด์วิดท์ซึ่งควรจะอยู่ในระดับที่ไม่เกิน RelayBandwidthRate ของคุณ

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

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

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

MyFamily AAAAAAAAAA,BBBBBBBB

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

tor --keygen-family myfamily

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

สิ่งที่อาจขัดข้องหลังจากระบบทำงานไปแล้ว

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

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

ที่อยู่ IP เปลี่ยนแปลง descriptor จะระบุที่อยู่เอาไว้ และไคลเอนต์จะไม่สามารถเข้าถึงที่อยู่เดิมที่ถูกย้ายไปแล้วได้ หลังจากมีการย้ายผู้ให้บริการหรือเปลี่ยนที่อยู่ IP ให้รีสตาร์ท 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 list เป็นครั้งคราว เนื่องจากที่อยู่ IP ของคุณถูกระบุว่าเป็น relay ในฐานข้อมูลสาธารณะ ส่วน exit relay คือกลุ่มที่ได้รับอีเมลร้องเรียนและหมายศาล ซึ่งจำเป็นต้องใช้ผู้ให้บริการที่ตกลงยอมรับการจัดการเรื่องเหล่านี้ไว้ล่วงหน้า โปรดอ่านข้อกำหนดของผู้ให้บริการก่อนเริ่มรัน relay ทั้งสองประเภท

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

เนื่องจาก relay ใหม่จะถูกจำกัดความเร็วตามการออกแบบจนกว่าจะผ่านการวัดผล ในช่วง 3 วันแรก directory authorities จะจำกัดน้ำหนัก (weight) ที่ประกาศไว้ที่ 20 KB ทำให้ client แทบไม่เลือกใช้ relay ของคุณ จากนั้น bandwidth authorities จะเริ่มวัดผลตั้งแต่วันที่ 3 เป็นต้นไป และ 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 เพียงชุดเดียวแทนการระบุรายการที่ยาวขึ้นเรื่อยๆ

#tor#relay#bandwidth#privacy#self-hosting#free-speech