SSD Nodes Learn Hosting plans →
الأدلة Matt Connorبقلم Matt Connor · آخر تحديث في 2026-08-24

كيف تشغّل Tor relay على VPS لينكس؟

ثبّت Tor relay للحراسة أو الترحيل الأوسط على VPS لينكس، واضبط torrc وحساب النطاق في الخطة المحدودة، وراقبه عبر nyx وافهم بطء consensus.

ما الذي يفعله Tor relay على VPS

Tor relay هو daemon لـTor يعمل على جهاز يملك عنوان IP عاماً، ويمرر حركة مرور مشفّرة لأشخاص آخرين. تنشره سلطات الدليل، ويبني عملاء Tor دوائر عبره. لا يمرر guard relay أو middle relay حركة المرور إلا إلى relay آخر، لذلك لا يفتح اتصالاً بموقع ويب نيابةً عن شخص غريب. هذه الحقيقة وحدها تفسر سبب عدم تلقيه رسائل إساءة استخدام، وسبب ملاءمته كإسهام لخادم VPS عادي. يمرر relay حركة مرور الآخرين ولا ينشر شيئاً خاصاً به. لذلك، إذا كان هدفك وضع موقعك على الشبكة بدلاً من تمرير الحزم نيابةً عنه، فإن تشغيل onion service من الإصدار v3 خلف nginx مهمة مختلفة باستخدام daemon tor نفسه. كما أن تشغيل relay لا يحسن خصوصية تصفحك أنت. هذه مشكلة منفصلة، ونتيجتها أقل مما يتوقعه معظم الناس: يوضح ما الذي يخفيه SearXNG المستضاف ذاتياً فعلياً مقدار الفائدة التي يحققها نقل خدمة إلى VPS تملكه.

العمل المطلوب بسيط: حزمة واحدة، و15 سطراً من الإعدادات، وقاعدة واحدة في الجدار الناري، وإعادة تشغيل واحدة. أما بقية هذا الدليل فتتناول مواضع الفشل. ستتناول حساب استهلاك النطاق الترددي في خطة محسوبة التكلفة، وسبب ظهور relay جديد وسليم تماماً كأنه متوقف لمدة أسبوع.

الحارسة أو الوسطى أو الجسر أو الخروج: اختر قبل التثبيت

يشغّل daemon واحد الأدوار الأربعة كلها. تحدد إعداداتك، إلى جانب سلطات الدليل، الدور الذي ستؤديه.

  • الترحيل الأوسط. يستقبل traffic من حارسة ويمرّره إلى ترحيل آخر. لا يتصل أبداً بالموقع الوجهة. يبدأ كل ترحيل جديد بهذا الدور.
  • ترحيل الحارسة. الإعداد نفسه، مع flag إضافية. تمنح سلطات الدليل ترحيلاتٍ سريعة ومستقرة مدة كافية flag الحارسة. لا تختارها بنفسك. تكتسبها بمرور الوقت، والإعداد أدناه هو ما يساعدك على اكتسابها.
  • الجسر. ترحيل يُستبعد عمداً من الدليل العام، ويُسلَّم بشكل خاص إلى المستخدمين في الأماكن التي يُحظر فيها Tor. وهو أقل الأدوار الأربعة التزاماً: bandwidth منخفض، ولا يظهر في قائمة عامة، وهو الخطوة الأولى المناسبة إذا كانت خطتك صغيرة. ويحتاج أيضاً إلى proxy من نوع obfs4 يعمل إلى جانب daemon، وإلى مجموعة مختلفة من أسطر torrc. يشرح إعداد جسر obfs4 على VPS رخيص واحد ذلك بالتفصيل، بما في ذلك طريقة تسليم سطر الجسر إلى المستخدمين في النهاية.
  • ترحيل الخروج. هو القفزة الأخيرة التي تفتح الاتصال بالموقع الوجهة. يغادر كل طلب يجريه مستخدم من عنوان IP الخاص بك، لذلك تصل بلاغات إساءة الاستخدام واستفسارات الشرطة إلى مالك ذلك العنوان.

دور الخروج هو الدور الوحيد الذي لا ينبغي تشغيله على VPS عام الاستخدام. شغّل ترحيل خروج فقط لدى مزوّد وافق مسبقاً على استلام تلك الرسائل، مع عنوان IP خاص به وعنوان اتصال منشور للإبلاغ عن إساءة الاستخدام. تحظر شروط الاستضافة المعتادة ذلك، والنتيجة المعتادة لتجاهل هذا الحظر هي تعليق الخادم وفقدان عنوان IP. إذا كان هذا هو الدور الذي تريده رغم ذلك، يشرح ما يتطلبه تشغيل ترحيل خروج فعلياً كيفية العثور على مضيف مناسب لتشغيل الخروج، وكتابة سياسة الخروج وreverse DNS، والرد على الرسائل عند وصولها. ينقل ترحيل الحارسة أو الترحيل الأوسط traffic المستخدم نفسه من دون كل هذا الانكشاف.

يبني كل ما يلي ترحيل حارسة/أوسط. ExitRelay 0 هو السطر الذي يجعله كذلك.

ما يحتاجه VPS قبل أن تبدأ

ينشر Tor Project المتطلبات الصارمة للمرحّلات. اعتباراً من August 2026، تشمل هذه المتطلبات: عنوان IPv4 عاماً واحداً للمرحّل، وعرض نطاق لا يقل عن 10 Mbit/s في كل اتجاه، مع التوصية بـ16 Mbit/s، وحركة مرور صادرة لا تقل عن 100 GB شهرياً، و512 MB من RAM عندما تكون السرعة أقل من 40 Mbit/s، أو 1 GB عندما تتجاوزها. لا توجد قاعدة ثابتة لمدة التشغيل، لكن المرحّل الذي يعمل أقل من ساعتين يومياً لا يقدّم فائدة كبيرة للشبكة.

تصف قيمة 10 Mbit/s سرعة الخط، لا الإعداد. تحتاج إلى منفذ يستطيع توفير هذه السرعة. أما مقدار السرعة التي تسمح للمرحّل باستخدامها فهو قرار منفصل، ويُتخذ بالاستناد إلى حصة النقل الشهرية. اقرأ خطتك قبل تعديل الإعدادات. إذا كنت لا تزال تختار خادماً، فتوضح التكلفة الشهرية الفعلية لـ VPS كيفية بيع حصص النقل، وتوضح قياس معدل النقل الشبكي الفعلي لـ VPS كيفية معرفة أداء الخط باستخدام iperf3 بدلاً من الاعتماد على صفحة المبيعات.

أمِّن الجهاز أولاً. المرحّل خدمة عامة على عنوان عام، ويبدأ فحص العنوان خلال دقائق من نشره. يستغرق تقييد SSH باستخدام المفاتيح وإعدادات sshd المحسّنة أمنياً عشر دقائق، ويجب تنفيذه قبل تشغيل المرحّل، لا بعده.

تثبيت Tor من مستودع Tor Project

استخدم مستودع apt الخاص بـTor Project بدلاً من حزمة التوزيعة. تتحرك شيفرة Relay بوتيرة أسرع من الإصدارات المستقرة، لذلك تصل الإصلاحات إلى هذا المستودع أولاً، بينما تتأخر حزمة التوزيعة بين الإصدارات.

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

أضف مفتاح التوقيع، ثم أضف المستودع. يُقرأ 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 بدلاً من ذلك، فهذا يعني أن المفتاح المحوَّل باستخدام dearmor ليس موجوداً في المسار المحدد في السطر Signed-By:، ولذلك لا يملك apt مفتاحاً للتحقق من ملف الإصدار به. وتهم حزمة deb.torproject.org-keyring لاحقاً؛ فهي توفّر مفتاح التوقيع كحزمة عادية، لذلك يستمر apt في العمل عند تدوير ذلك المفتاح.

فعّل التحديثات التلقائية، ثم عرّف المصدر الجديد لها.

sudo apt install -y unattended-upgrades apt-listchanges

على Ubuntu، أضف مصدر Tor إلى الكتلة 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، الذي يطبع المصادر التي سيعمل عليها ولا يكتب أي شيء.

ملف torrc المهم

يثبّت الحزمة ملف /etc/tor/torrc طويلاً يحتوي على تعليقات كثيرة. لا يهم الترحيل سوى عدد قليل من الأسطر. أضفها في نهاية الملف.

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

يجب أن يتكوّن Nickname من 1 إلى 19 محرفاً، وأن يقتصر على الأحرف والأرقام. لا يكون هذا الاسم فريداً على مستوى الشبكة، ولا يمثل هويتك؛ فالبصمة هي التي تمثل هويتك. ستستخدم الاسم للعثور على الترحيل الخاص بك في مربع البحث، لذلك اختر اسماً تستطيع تهجئته عبر الهاتف.

يُنشر ContactInfo داخل واصف الترحيل، وهو مستند عام يمكن لأي شخص تنزيله، ولذلك سيُجمع العنوان آلياً. استخدم عنواناً ستظل تقرأه بعد عامين، ويمكنك إخفاءه جزئياً إذا أردت. هذه هي القناة الوحيدة التي يملكها Tor Project لتحذيرك من مشكلة في الترحيل.

يحدد ORPort 9001 المنفذ الذي تتصل به الترحيلات والعملاء الآخرون. المنفذ 9001 هو الخيار التقليدي. والمنفذ 443 خيار شائع آخر، لأن بعض الشبكات المقيّدة لا تسمح إلا بالاتصالات الصادرة إلى 443، ولذلك يكون الترحيل الذي يستمع عليه متاحاً لعدد أكبر من العملاء. اختر 443 فقط إذا لم تكن هناك خدمة أخرى على الخادم تحتاج إليه.

يعطّل SocksPort 0 وكيل SOCKS المحلي، الذي لا يستخدمه الترحيل، ويزيل مقبساً مستمعاً من الجهاز. يوضح ExitRelay 0 النية داخل الملف: لن يتصل هذا الترحيل أبداً بوجهة نيابةً عن مستخدم، ولن يضطر أي شخص يقرأ الإعداد لاحقاً إلى استنتاج ذلك من القيمة الافتراضية.

إذا كان لدى VPS عنوان IPv6، فأضف سطراً ثانياً من ORPort. لا يستطيع Tor الربط بأي عنوان IPv6 بالطريقة التي يستخدمها مع IPv4، لذلك اكتب العنوان بين قوسين مربعين.

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

على VPS بسعة 1 GB، أضف MaxMemInQueues 512 MB. يحدد Tor حد قائمة الانتظار بناءً على الذاكرة التي يراها على الجهاز، وتكون هذه الذاكرة في الخادم المشترك الصغير أكبر مما تريد أن يستخدمه. يتيح ضبط الحد يدوياً لـ tor إسقاط الخلايا الموجودة في قائمة الانتظار عند الضغط، فيستمر الترحيل في العمل، بدلاً من زيادة الاستخدام حتى تنهي النواة العملية.

افتح ORPort في جدار الحماية

يجب أن يكون ORPort قابلاً للوصول من أي مكان على الإنترنت بالنسبة للاتصالات الواردة. أما الاتصالات الصادرة، فاترك relay بلا قيود. فهو يفتح اتصالات مع آلاف relays الأخرى عبر منافذ مختلفة، وستؤدي قائمة السماح للاتصالات الصادرة إلى تعطيله تدريجياً دون أن يكون ذلك واضحاً.

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

بعد ذلك، افحص جدار الحماية الشبكي الخاص بالمزوّد. تشغّل العديد من لوحات التحكم مرشحاً للحزم أمام الآلة الافتراضية. ولا يكون للقاعدة التي أضفتها باستخدام ufw أي تأثير هناك. لذلك قد يظهر المنفذ مفتوحاً على الخادم ومغلقاً من الخارج. إذا كانت ufw جديدة عليك، يشرح قواعد ufw التي يجب وضعها على كل VPS السياسة الافتراضية وترتيب مطابقة القواعد.

حدّد سعة النطاق بما يناسب خطتك

يصف الدليل RelayBandwidthRate بأنه حاوية رموز منفصلة تحدّ «متوسط استخدام النطاق الترددي الوارد لحركة المرور المرحّلة على هذه العقدة إلى العدد المحدد من البايتات في الثانية، ومتوسط استخدام النطاق الترددي الصادر إلى القيمة نفسها». اقرأ ذلك مرتين. ينطبق الحد على كل اتجاه بشكل منفصل. يمكن لترحيل مضبوط على 1 Mbit/s نقل 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 حسابات رياضية وليست قياساً: فهي توضّح تكلفة معدل معيّن إذا حافظ المرحّل عليه لمدة 30 يوماً كاملاً في الاتجاهين. يبقى المرحّل الحقيقي دون حده الأقصى معظم الوقت، وخصوصاً خلال الأسابيع الأولى. استخدم الجدول لاستبعاد الإعدادات التي لا يمكن أن تناسب ميزانيتك، لا للتنبؤ بفاتورة محسوبة بالغيغابايت.

عند 1 Mbit/s في كل اتجاه، ينقل المرحّل نحو 21.6 GB يومياً، لذلك يستهلك شهر مدته 30 يوماً نحو 648 GB من حركة المرور المحسوبة. وهذا يندرج ضمن سماح قدره 1 TB مع بقاء سعة للتحديثات والنسخ الاحتياطية. عند الانتقال إلى 2 Mbit/s، يستهلك الشهر 1,296 GB، وهو ما يتجاوز بالفعل خطة 1 TB. أما الصف الأخير، 20 Mbit/s، فيحتاج إلى 12,960 GB شهرياً، ولذلك يناسب منفذاً غير محسوب. إذا كان مزوّد الخدمة يحاسب على حركة المرور الصادرة فقط، فاقسم كل قيمة على اثنين. تحقّق من نوع المحاسبة لديك قبل ضبط المعدل، لأن النتيجتين تختلفان بمعامل اثنين.

والآن ننتقل إلى الإعداد. اضبط حد المعدل أولاً، ثم الحصة.

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

تمثل RelayBandwidthBurst حجم حاوية الرموز، ولذلك تسمح بارتفاعات قصيرة فوق المعدل ما دام المتوسط ثابتاً. وتُعد قيمة تساوي ضعف المعدل تقريباً مناسبة.

السطر AccountingRule هو السطر الذي يفوّته معظم المشغّلين. القيمة الافتراضية هي max، وهي تقيس الاتجاه الأكبر بين الاتجاهين مقابل الحصة. مع القيمة الافتراضية، تسمح AccountingMax 400 GBytes بـ400 GB واردة و400 GB صادرة، أي 800 GB في عدّاد يحسب الاتجاهين. أما AccountingRule sum فتحسب القراءة والكتابة معاً مقابل حصة واحدة، وهذا هو ما تقيسه فعلياً سماحة نقل البيانات.

اكتب AccountingStart أيضاً، ولا تكتب AccountingMax وحدها. الحصة هي الرقم، وسطر البدء هو الفترة التي تُعاد عندها تهيئتها. تؤدي الحصة التي لا تحدد فترة إلى إبقاء المرحّل في وضع السبات من دون ما يعيده إلى العمل.

السبات أداة صلبة وغير دقيقة. عند نفاد الحصة، يسجل tor ذلك ويتوقف عن قبول العمل:

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

لا يستيقظ المرحّل عند البداية الدقيقة للفترة التالية أيضاً. يتتبع Tor سرعة استهلاك الحصة السابقة ويختار نقطة عشوائية داخل الفترة الجديدة، حتى لا تعود آلاف المرحّلات إلى الشبكة في الثانية نفسها. يفقد المرحّل الذي يختفي خلال الأسبوع الأخير من كل شهر الاستقرار الذي تقيسه سلطات الدليل له باستمرار. اضبط RelayBandwidthRate بحيث لا يتم بلوغ الحد أبداً، وأبقِ AccountingMax كوسيلة حماية احتياطية للفاتورة.

شغِّل الـrelay وتحقّق من إمكانية الوصول إليه

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

خلال بضع دقائق، يجب أن يحتوي السجل على السطر التالي:

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

تعني هذه الجملة أن relays أخرى اتصلت مجدداً بـORPort لديك وأنشأت circuit عبره. إلى أن يظهر هذا السطر، لا يكون الـrelay موجوداً في الدليل ولا يمرر أي حركة مرور على الإطلاق. يظهر الفشل بالشكل التالي:

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؟ هل هو مفتوح أيضاً في جدار الشبكة المنفصل لدى مزود الخدمة؟ هل العنوان الوارد في تلك الرسالة هو العنوان الذي يوجّه الإنترنت الاتصالات إليه فعلياً، وليس عنواناً خاصاً ناتجاً عن إعداد NAT؟ اختبر المنفذ من جهاز آخر باستخدام nc -vz 203.0.113.10 9001. يعيد Tor إجراء الاختبار الذاتي تلقائياً، لذلك سيكتشف مشكلة جدار ناري تم إصلاحها دون تدخل إضافي، وتؤدي إعادة التشغيل إلى ظهور النتيجة فوراً.

الهوية الدائمة للـrelay هي بصمته:

sudo cat /var/lib/tor/fingerprint

بعد نحو ثلاث ساعات من نشر الوصف، يظهر الـrelay في البحث عن Relay. ابحث باستخدام اللقب أو الصق البصمة. تعرض هذه الصفحة نظرة الشبكة إلى الـrelay لديك: العلامات التي يحملها، والوزن الذي تمنحه له السلطات، والإصدار الذي ينشره.

لماذا لا يمرّ عبر Tor relay جديد أي قدر يُذكر من حركة الشبكة؟

لأن الشبكة لم تقس أداءه بعد، وتستغرق عملية القياس أسابيع. يصف Tor Project مراحل زيادة الاستخدام في أربع مراحل، لكن المشغّل الذي لم يقرأ هذا الوصف يستنتج أن relay معطّل ويبدأ بتغيير الإعدادات.

خلال الأيام الثلاثة الأولى، لا يكون relay مقاساً. ويعلن نتيجة الاختبار الذاتي، لكن سلطات الدليل تحدد الوزن المنشور عند 20 KB على أي حال، لذلك نادراً جداً ما يختاره العملاء. من اليوم الثالث تقريباً إلى اليوم الثامن، تقيسه سلطات النطاق الترددي فعلياً ويزداد وزنه، لكنه يُستخدم فقط كـmiddle hop، لأن لا عميلاً مستعداً لجعل relay جديد تماماً هو القفزة الأولى.

في اليوم الثامن تقريباً، يصبح relay مؤهلاً للحصول على Guard flag. يؤدي الحصول على هذا العلم إلى انخفاض حركة الشبكة، وهذا يفاجئ الجميع: يتجاوز العملاء الـguards عند اختيار middle hops، بافتراض أن guard مشغول بالفعل، لذلك يفقد relay حركة middle قبل أن يكتسب حركة guard. ولا يستعيد هذه الحركة إلا مع تدوير العملاء لمجموعات guard الخاصة بهم، وتستغرق هذه العملية أسابيع. وبحلول اليوم 68 تقريباً، يصل إلى حالة مستقرة، حيث يتوازن عدد العملاء الذين يزيلونه مع عدد العملاء الذين يضيفونه.

لذلك، التوقع الواقعي هو عدم وجود شيء خلال ثلاثة أيام، وظهور بعض الحركة بعد أسبوع، وبلوغ حمل فعلي بعد شهرين. غيّر إعداداً واحداً، ثم انتظر أسبوعاً لمعرفة أثره. صفحة حالة Uptime Kuma مستضافة ذاتياً مع فحص TCP على المنفذ 9001 أفضل لاستثمار القلق: فهي تجيب عن السؤال الذي يمكنك التحكم فيه فعلاً، وهو ما إذا كان المنفذ لا يزال يستجيب.

راقب الـrelay باستخدام nyx

nyx هو برنامج المراقبة الطرفي لـrelay قيد التشغيل. ويتصل بمنفذ التحكم الخاص بـ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 معدل نقل البيانات المباشر، ومدة التشغيل، وتدفق السجل، وقائمة الاتصالات. خلال الأسابيع الأولى، راقب بقاء مخطط معدل نقل البيانات تحت RelayBandwidthRate.

تشغيل أكثر من Relay: مفاتيح MyFamily والعائلة

تجاوز هذا القسم إذا كان لديك Relay واحد. يجب على اثنين أو أكثر من Relay التي يديرها المشغّل نفسه التصريح ببعضها، حتى لا ينشئ العملاء دائرة تدخل وتخرج عبر أجهزتك، ما قد يتيح لمشغّل واحد رؤية طرفيها.

الطريقة المعتمدة منذ مدة طويلة هي MyFamily في ملف torrc لكل Relay، مع إدراج بصمات جميع Relay الأخرى:

MyFamily AAAAAAAAAA,BBBBBBBB

يُدرج كل Relay جميع Relay الأخرى، لذلك تتطلب إضافة Relay رابع تعديل أربعة ملفات. استبدل Tor 0.4.9 ذلك بمفتاح عائلة. أنشئ مفتاحاً واحداً، ثم شاركه:

tor --keygen-family myfamily

يكتب ذلك myfamily.secret_family_key ويطبع سطراً بصيغة FamilyId. انسخ ملف المفتاح إلى كل Relay، وضعه في الدليل الفرعي keys ضمن DataDirectory (/var/lib/tor/keys في Debian وUbuntu)، مع الإبقاء على اللاحقة .secret_family_key. أضف السطر المطبوع FamilyId إلى كل ملف torrc، ثم أعد التحميل باستخدام sudo systemctl reload tor@default. أبقِ قائمة MyFamily موجودة أيضاً في الوقت الحالي. ما زال العملاء الذين لا يفهمون شهادات العائلة يقرؤون القائمة القديمة، وسيعلن Tor Project عندما يصبح حذفها ممكناً.

ما الذي يتعطل بعد تشغيله

يصبح الإصدار قديماً. تستبدل الترقية التلقائية الحزمة، لكن العملية قيد التشغيل تواصل استخدام الملف الثنائي الذي بدأت به إلى أن يُعاد تشغيلها. قارن ناتج tor --version على الخادم بالإصدار الظاهر في صفحة Relay Search الخاصة بالمرحل. إذا اختلفا، فما تزال الشبكة ترى الإصدار القديم، ولذلك أعد تشغيل الخدمة.

تتأخر الساعة. تكون مستندات الإجماع والشهادات مرتبطة بالوقت، ولذلك ترفض الآلة التي تنحرف ساعتُها كثيراً الإجماع وتتوقف عن النشر. يجب أن يبيّن timedatectl أن ساعة النظام متزامنة. إذا لم يحدث ذلك، فعّل systemd-timesyncd أو ثبّت chrony.

يتغير عنوان IP. يتضمن الوصف العنوان، ولا يستطيع العملاء الوصول إلى عنوان تغيّر موضعه. بعد أي انتقال بين مزوّدي الخدمة أو تغيير في العنوان، أعد تشغيل tor وراقب ظهور سطر الاختبار الذاتي مرة أخرى.

يصبح المرحل أبطأ من الحد المسموح به في الخطة. تستخدم تشفيرات Tor الخاصة بالمرحلات المعالجات الحديثة بكفاءة، ويقدّر Tor Project أن المعالج الذي يدعم AES-NI يحقق نحو 400 إلى 450 Mbit/s في كل اتجاه. قبل بلوغ هذا الحد بوقت طويل، ستصبح سرعة المنفذ وحدّ النقل العاملين المقيّدين لك، ولهذا يهم قسم المحاسبة أعلاه أكثر من العتاد.

FAQ

ما مقدار النطاق الترددي الذي يستخدمه مرحّل Tor؟

يستخدم المقدار الذي تسمح به، ولا يتجاوزه. يحد RelayBandwidthRate حركة المرور المُرحَّلة في كل اتجاه بشكل منفصل، لذلك يمكن لمرحّل مضبوط على 1 Mbit/s أن ينقل 1 Mbit/s للداخل و1 Mbit/s للخارج في الوقت نفسه. يعادل ذلك نحو 21.6 GB يومياً، أو 648 GB خلال شهر مدته 30 يوماً، مع احتساب الاتجاهين. أضف AccountingMax مع AccountingRule sum كحصة شهرية صارمة أدنى من ذلك المعدل.

هل سيؤدي تشغيل مرحّل Tor إلى تلقي شكاوى إساءة استخدام؟

يمرّر مرحّل Guard أو المرحّل الأوسط حركة المرور إلى مرحّلات Tor أخرى فقط، ولا يتصل بموقع ويب نيابةً عن مستخدم. لذلك تُرسل الشكاوى المتعلقة بما فعله شخص عبر Tor إلى مشغّل مرحّل الخروج، وليس إليك. قد ترى عمليات فحص، وقد يظهر عنوان IP أحياناً في قوائم السمعة، لأن العنوان مُدرج علناً بوصفه مرحّلاً. مرحّلات الخروج هي التي تتلقى رسائل إساءة الاستخدام والإشعارات القانونية، وتحتاج إلى مزوّد وافق مسبقاً على التعامل معها. اقرأ شروط مزوّدك قبل تشغيل أي من النوعين.

لماذا لا يتلقى مرحّل Tor الجديد لدي أي حركة مرور؟

لأن المرحّلات الجديدة تُقيَّد سرعتها عمداً إلى أن تُقاس. خلال الأيام الثلاثة الأولى، تحد سلطات الدليل الوزن المنشور عند 20 KB، لذلك نادراً جداً ما يختار العملاء المرحّل. تقيسه سلطات النطاق الترددي ابتداءً من اليوم الثالث تقريباً، ويصبح مؤهلاً للحصول على راية Guard حول اليوم الثامن، ثم تنخفض حركة المرور مجدداً في تلك المرحلة لأن العملاء يتجنبون مرحّلات Guard عند اختيار القفزات الوسطى. يصل الحمل الكامل تقريباً حول اليوم 68. تأكد من أن السجل يعرض "Self-testing indicates your ORPort is reachable from the outside"، ثم اتركه يعمل دون تدخل.

هل يمكنني تشغيل مرحّل Tor على VPS بسعة نقل تبلغ 1 TB؟

نعم، بمعدل يقارب 1 Mbit/s في كل اتجاه، وهو ما يعادل RelayBandwidthRate 125 KBytes. يصل ذلك إلى نحو 648 GB شهرياً إذا كان مزوّدك يحسب الاتجاهين، مع ترك سعة احتياطية للتحديثات والنسخ الاحتياطية. أضف AccountingMax 400 GBytes مع AccountingRule sum وAccountingStart month 1 00:00 لكي يدخل المرحّل في وضع السكون بدلاً من تجاوز الخطة. إذا كان المزوّد يحاسب على حركة المرور الصادرة فقط، يمكنك مضاعفة المعدل.

هل أحتاج إلى ضبط MyFamily إذا كنت أشغّل مرحّلاً واحداً فقط؟

لا. وُجدت تعريفات العائلة لكي يتجنب العملاء إنشاء دائرة تمر عبر مرحّلين يملكهما المشغّل نفسه، وهذا غير ذي معنى عند وجود مرحّل واحد. اضبطها فور إضافة مرحّل ثانٍ: أدرج بصمة كل مرحّل في سطر MyFamily الخاص بكل مرحّل، أو استخدم مفتاح العائلة الذي قدمه Tor 0.4.9، والذي يوزّع FamilyId واحداً بدلاً من قائمة متزايدة باستمرار.