كيفية تشغيل جسر Tor مع obfs4 على خادم VPS

ما هو Tor bridge، ولماذا يُستخدم

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

العنوان غير المدرج ليس سوى نصف الحل. يتعرّف الفحص العميق للحزم (DPI)، الذي يصنّف حركة الشبكة وفق محتواها بدلاً من عنوانها، على اتصال Tor من شكل مصافحة TLS (أمان طبقة النقل). ويمكن لجهة رقابة لا تملك القائمة أن ترى أن «هذا يبدو كأنه Tor» ثم تحجب الاتصال. يزيل pluggable transport هذه الإشارة. فهو يغلّف تدفق Tor بشيء آخر على جانب العميل، ثم يفك bridge هذا التغليف.

يُعد obfs4 وسيلة النقل التي تشغّلها معظم الجسور. فهي تحوّل التدفق إلى وحدات بايت بلا ترويسة وبلا مصافحة ثابتة، لذلك لا يجد DPI نمطاً يطابقه. كما أنها تتحقق من هوية العميل. إن قيمة cert= داخل سطر bridge هي مفتاح يجب على العميل إثبات امتلاكه قبل أن يجيب bridge على الإطلاق. ويمنع ذلك الفحص النشط: فإذا اتصلت جهة رقابة بعنوانك لاختبار ما إذا كان يتحدث Tor، فلن تتلقى أي رد ولن تعرف شيئاً.

ما وسيلة النقل القابلة للتوصيل التي ينبغي تشغيلها؟

• تحتاج obfs4 إلى VPS واحد ومنفذين TCP، ولا تحتاج إلى اسم نطاق. وهي أبسط خدمة مفيدة يمكنك تشغيلها، ولذلك يركّز عليها هذا الدليل.
• تخفي WebTunnel الاتصال داخل حركة HTTPS عادية إلى موقع ويب حقيقي. يذكر Tor Project أن متطلباتها هي عنوان IPv4 ثابت، واسم نطاق تتحكم فيه، وخادم ويب عامل مثل NGINX أو Apache، وشهادة TLS صالحة، وذاكرة RAM بسعة 1 GB على الأقل، مع التوصية بسعة 4 GB. تناسب هذه الوسيلة الشبكات التي تثير فيها حركة البيانات العشوائية الشك بحد ذاتها، لأن الدولة التي لا تسمح إلا بقدر محدود من تصفح الويب تظل تسمح باتصالات HTTPS.
• تمثل Snowflake مساهمة مختلفة. يشغّل المتطوعون وكلاء WebRTC قصيرة العمر، لذلك تتغير نقاط الدخول باستمرار ولا يوجد عنوان ثابت يمكن لجهة الرقابة حجبه. لا تشغّل bridge لها. بل تشغّل proxy، ولا يحتاج إلى عنوان ثابت.

ابدأ باستخدام obfs4. يمكنك إضافة bridge من نوع WebTunnel لاحقاً على عنوان ثانٍ. يؤدي تشغيلهما على عنوان 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
  }
]

اعتباراً من August 2026، يطلب Tor Project من bridge توفير نطاق ترددي للرفع والتنزيل لا يقل عن 1 Mbit/s. ويُطلب من guard أو middle relay توفير 10 Mbit/s، مع التوصية بـ 16 Mbit/s. هذه متطلبات منشورة وليست قياسات فعلية. عادةً ما يبقى bridge جديداً دون الحد الأدنى الخاص به لأسابيع. وتطلب صفحة المتطلبات نفسها من relay توفير حركة مرور صادرة لا تقل عن 100 GByte شهرياً، وهو مقدار تغطيه الخطط الأصغر بالفعل. لذلك راجع التكلفة الشهرية الفعلية لـ VPS صغير قبل أن تختار حجماً أكبر.

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

لا تفعل شيئاً واحداً: لا تحوّل relay عاماً قائماً إلى bridge على العنوان نفسه. تنص إرشادات Tor Project لهذه الحالة على تغيير "IP address, name and fingerprint"، لأن العنوان القديم موجود بالفعل في consensus الذي ينزّله الرقيب. bridge كان relay عاماً في الأسبوع الماضي هو bridge موجود بالفعل في قائمة حظر.

التوافر أهم من السرعة. تنص متطلبات relay على أنه "if your relay is not running for more than 2 hours a day its usefulness is limited"، ويكون bridge في وضع أسوأ من relay هنا، لأن لكل عميل عنواناً واحداً ولا يوجد عنوان احتياطي. يؤدي كل restart إلى قطع الاتصال عن كل مستخدم متصل به. أعد إعداد فحص منفذ TCP في Uptime Kuma على منفذ obfs4 حتى تعرف في يوم توقفه عن الاستجابة.

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

تتأخر حزم التوزيعات، والجسر برنامج أمني يجب أن يكون محدثاً. أضف مستودع المشروع الخاص أولاً.

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

اكتب الآن ملف المصدر. يجب أن يحتوي السطر Suites: على الاسم الرمزي لإصدارك، لذا اقرأه من النظام بدلاً من إدخاله من الذاكرة.

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 بأن المستودع لا يحتوي على ملف Release لإصدارك، فهذا يعني أن Tor Project لا يوفر حزمته لذلك الإصدار. احذف /etc/apt/sources.list.d/tor.sources، وشغّل sudo apt update مرة أخرى، وثبّت حزمة tor التي توفرها توزيعتك. كل ما يلي مطابق.

تأتي حزمة obfs4proxy من Debian وUbuntu نفسيهما (الإصدار 0.0.14 في Debian 13، اعتباراً من أغسطس 2026). تحقّق من مكان تثبيت الملف الثنائي، لأن مساره سيُستخدم في الإعداد:

command -v obfs4proxy || command -v lyrebird

أعاد المشروع upstream تسمية المشروع إلى lyrebird، لذلك قد تثبّت حزمة أحدث /usr/bin/lyrebird بدلاً منها. استخدم المسار الذي يطبعه ذلك الأمر.

إعداد الجسر في /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 بإرسال واصفه إلى سلطة الجسور بدلاً من الإجماع العام. هذا السطر وحده هو ما يجعل المرحّل غير مدرج.

ORPort هو منفذ Tor الفعلي. يجب أن يكون قابلاً للوصول من الإنترنت، لأن tor يختبره ويرفض نشر واصف إلى أن ينجح هذا الاختبار.

يمنح ServerTransportPlugin ‏tor الأمر الذي يجب تشغيله. يبدأ tor تشغيل obfs4proxy كعملية فرعية ويتواصل معه عبر pipe، لذلك لا يملك obfs4proxy وحدة خدمة خاصة به ولا يظهر مطلقاً في systemctl status.

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

يفتح ExtORPort auto ‏ORPort الموسّع، وهو قناة loopback يستخدمها obfs4proxy لإعادة الاتصالات المكتملة إلى tor مع عنوان العميل. يتضمنه دليل إعداد Tor Project في كل جسر، لأن وسيلة النقل لا تستطيع من دونه إبلاغ tor بذلك العنوان.

ContactInfo وNickname معلنان للعامة. استخدم عنواناً ستقرأه، لأن Tor Project تتواصل معك من خلاله بشأن أي جسر معطّل. واختر اسماً مستعاراً لا يحدد هويتك إذا كنت تفضّل عدم لفت الانتباه.

يحدد BridgeDistribution الموزّع الذي يسلّم عنوانك إلى المستخدمين. القيم المقبولة هي https وemail وtelegram وsettings وnone وany. استخدم any للجسر الأول، ودع النظام يقرر. استخدم none لجسر خاص توزعه بنفسك، ما يُبقي العنوان خارج التوزيع العام بالكامل.

لماذا يهم اختيار المنفذ

تجنّب استخدام 9001 للمنفذين معاً. يذكر Tor Project ذلك صراحةً، لأن 9001 هو ORPort التقليدي، ولأن الجهات التي تفرض الرقابة تفحص الإنترنت بحثاً عنه. يجب أن يختلف المنفذان أيضاً، لأن tor وobfs4proxy يربط كل منهما المستمع الخاص به.

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

فتح المنافذ في جدارَي الحماية

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

يجب فتح كلا المنفذين. يشغّل معظم مزوّدي الخدمة جدار حماية ثانياً في لوحة التحكم، ولا يعرف عنه ufw شيئاً. تؤدي القاعدة الموجودة على الخادم وغير الموجودة في لوحة التحكم إلى إنشاء bridge لا يمكن الوصول إليه ولا ينشر descriptor. إذا كان أي من الجزأين جديداً عليك، فراجع قواعد ufw التي يحتاج إليها VPS جديد والمقصود فعلياً بمنفذ يستمع على Linux. وأثناء ذلك، أمِّن SSH باستخدام المفاتيح واضبط إعدادات sshd بتقوية مناسبة. يظل bridge غير المدرج على خادم يستخدم SSH بكلمة مرور خادماً يستخدم SSH بكلمة مرور.

شغّله، ثم اقرأ السجل

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

توفّر Debian وUbuntu وحدتين. tor.service عبارة عن غلاف صغير، بينما tor@default.service هي العملية التي تنفّذ العمل. لذلك تبدو journalctl -u tor شبه فارغة، في حين يوجد السجل الذي تريده ضمن 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'

يعني السطر الأول نجاح اختبار الوصول وإرسال الواصف إلى سلطة الجسر. إذا لم يظهر مطلقاً، فهناك مكوّن بين الإنترنت وخادمك يحظر حركة الشبكة إلى ORPort. يجب أن يعرض السطر الثاني المنفذ الذي ضبطته. ظهور منفذ مختلف يعني أن tor لم يطبّق ServerTransportListenAddr. والسبب المعتاد هو عدم تطابق اسم النقل؛ إذ يجب أن يكون obfs4 في كلا التوجيهين.

تأكد من وجود المستمعين الاثنين:

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

أين يوجد سطر الجسر الخاص بي؟

يكتب obfs4proxy قالباً في دليل بيانات tor:

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

هذا الدليل مملوك للمستخدم tor ووضعه 700، لذلك تحصل على Permission denied من دون sudo. يحتوي الملف على سطر بهذا الشكل:

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

استبدل <IP ADDRESS> بالعنوان العام لخادمك، و<PORT> بمنفذ obfs4 وليس ORPort، و<FINGERPRINT> ببصمة الهوية التي كتبها tor في دليل بياناته:

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

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

كيف يصل الجسر فعلياً إلى المستخدمين؟

لا ترسل سطر الجسر إلى أي شخص. بعد وصول الوصف إلى سلطة الجسور، يعيّن نظام التوزيع (rdsys، خليفة BridgeDB) جسرك إلى موزّع واحد، ويطلب المستخدمون الجسور من ذلك الموزّع. اعتباراً من August 2026، المسارات هي التالية:

• النموذج الويب في bridges.torproject.org/options، الذي يعرض أسطر الجسور بعد اجتياز اختبار captcha.
• إرسال بريد إلكتروني إلى bridges@torproject.org من عنوان Gmail أو Riseup، لتصلك رسالة تتضمن أسطر الجسور. يوجد تقييد مزوّد الخدمة لأن الحسابات المجانية غير المحدودة كانت ستتيح لجهة رقابية حصر جميع الجسور.
• روبوت Telegram ‏@GetBridgesBot. أرسل /start، ثم /obfs4 أو /webtunnel.
• متصفح Tor نفسه، من Settings ثم Connection، حيث يجلب الخيار "Request bridges" الجسور عبر قناة moat.

يظهر الجسر الجديد في Relay Search بعد نحو ثلاث ساعات من إعداده. أما وصول المستخدمين فيستغرق وقتاً أطول بكثير؛ إذ تنص صياغة Tor Project نفسها على أن "قد يستغرق الأمر عدة أيام أو أسابيع قبل أن ترى مجموعة مستقرة من المستخدمين." لذلك فإن قلة المستخدمين خلال أول أسبوعين أمر طبيعي، وليست عطلاً.

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

عند تعذّر عمل شيء ما

لا يظهر سطر الاختبار الذاتي في السجل. لا يمكن الوصول إلى ORPort. اختبره من جهاز آخر باستخدام nc -vz your.ip 8443. يعني عدم استجابة الأمر إسقاط الحزم، لذلك افحص ufw ولوحة تحكم مزود الخدمة. ويعني الرفض أن tor لا يستمع، لذلك افحص ss -lntp واقرأ السجل بحثاً عن خطأ في الإعداد.

يعرض transport المسجّل منفذاً لم تختره. تجاهل tor قيمة ServerTransportListenAddr. يجب أن يطابق اسم transport الاسم الموجود في ServerTransportPlugin تماماً، ويجب أن تكون القيمتان obfs4.

لن يربط obfs4proxy المنفذ 443. تحقّق من القدرة باستخدام getcap /usr/bin/obfs4proxy، ثم تحقّق من وصول التجاوز إلى الوحدة باستخدام systemctl show tor@default -p NoNewPrivileges. إذا طبع الأمر NoNewPrivileges=yes، فقد أضفت drop-in إلى وحدة غير قيد التشغيل.

لا يوجد شيء داخل /var/lib/tor/pt_state/. لم يبدأ tor الـtransport، ما يعني أن المسار في ServerTransportPlugin غير صحيح. قارنه بمخرجات command -v obfs4proxy.

توقّف العملاء عن الاتصال بعد إجراء تغيير. يؤدي أي تغيير في العنوان أو منفذ obfs4 إلى إبطال كل bridge line موزّع مسبقاً. تحقّق مما إذا كان عنوان IP العام للخادم قد تغيّر أيضاً، إذ يحدث ذلك عند إعادة البناء لدى بعض مزودي الخدمة.

لن يبدأ tor إطلاقاً. شغّل sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. يحلّل الأمر الملف، ويطبع السطر الذي يعترض عليه، ويترك الخدمة قيد التشغيل من دون تغيير.

FAQ

هل سيعترض مزود VPS لديّ على تشغيل جسر Tor؟

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

ما مقدار عرض النطاق الترددي الذي يستخدمه جسر Tor؟

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

لماذا لم يتصل أحد بجسري الجديد؟

يستغرق ظهور الجسر في Relay Search نحو ثلاث ساعات، وتفيد إرشادات Tor Project بأن وصول مجموعة ثابتة من المستخدمين يستغرق عدة أيام أو أسابيع. تحقق من نشر الوصف، وهو سطر الاختبار الذاتي في journalctl -u tor@default، وابحث عن البصمة المجزأة الخاصة بك في Relay Search، وتأكد من أن BridgeDistribution غير مضبوط على none.

هل ينبغي أن أشغّل obfs4 أم WebTunnel؟

شغّل obfs4 إذا كان هذا أول جسر لك: VPS واحد، ومنفذان، ومن دون نطاق أو شهادة. شغّل WebTunnel عندما تكون حركة الشبكة التي تبدو عشوائية محظورة بحد ذاتها، لأنه يحتاج إلى نطاق تتحكم فيه، وخادم ويب فعلي، وشهادة TLS صالحة، و1 GB على الأقل من RAM. استخدم عنوانين منفصلين إذا شغّلتهما معاً، لأن حظر عنوان IP واحداً سيؤدي otherwise إلى إزالة جسرين في الوقت نفسه.

ماذا يحدث إذا غيّرت منفذ obfs4 لاحقاً؟

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