كيف تشغّل Tor bridge مع obfs4 على VPS

ما هو Tor bridge ولماذا يوجد

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

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

يُعد obfs4 وسيلة النقل التي تعمل بها معظم bridges. فهو يحوّل التدفق إلى وحدات بايت من دون ترويسة أو مصافحة ثابتة، لذلك لا يجد DPI نمطاً يطابقه. كما يصادق على العميل. وتكون قيمة cert= داخل bridge line مفتاحاً يجب على العميل إثبات حيازته قبل أن تستجيب 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
  }
]

اعتباراً من أكتوبر 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 كحالة خاصة. يشبه bridge وonion service صورتين متعاكستين من هذه الناحية: لا يكون bridge مفيداً إلا لأن عنوانه يمكن الوصول إليه ثم توزيعه، بينما يمكن لـ خدمة onion من الإصدار v3 على النوع نفسه من VPS إبقاء عنوان IP العام الخاص بك مخفياً تماماً.

هناك أمر يجب ألا تفعله: تحويل 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 هنا، لأن العميل لا يعرف إلا أسطر bridge التي حصل عليها. يقبل Tor Browser عدة أسطر، سطراً واحداً في كل مرة، لكن عندما تتوقف جميعها عن الاستجابة، يجب على المستخدم طلب أسطر جديدة. تؤدي إعادة تشغيل خادمك إلى فصل كل مستخدم متصل به. أعد إعداد فحص منفذ TCP في Uptime Kuma على منفذ obfs4 لكي تعرف في اليوم نفسه الذي يتوقف فيه عن الاستجابة.

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

تتأخر حزم التوزيعة عن الإصدارات الحديثة، والـbridge برنامج أمني يجب أن يبقى محدثاً. أضف مستودع المشروع أولاً.

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

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

command -v obfs4proxy || command -v lyrebird

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

إعداد 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 كعملية فرعية ويتواصل معه عبر pipe، لذلك لا تملك obfs4proxy وحدة خدمة مستقلة. لكنها تظهر في systemctl status tor@default، ضمن CGroup الخاص بهذه الوحدة إلى جانب tor نفسه.

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

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

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

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

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

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

أقوى منفذ لـ obfs4 هو 443. يكون المنفذ 443 الصادر مفتوحاً في جميع الشبكات المقيّدة تقريباً، لذلك يظل مفتوحاً أمامه حتى المرشح الذي لا يسمح إلا بقدر ضئيل يتجاوز منافذ الويب. لا يخفي المنفذ البروتوكول: تظل حركة obfs4 شبيهة ببيانات عشوائية بدلاً من HTTPS، ومهمة جعل الاتصال يبدو كأنه وصول إلى موقع ويب تقع على WebTunnel. يتطلب الربط بمنفذ أقل من 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 العنوان والمنفذ وfingerprint والشهادة معاً، لذلك تتعطل كل نسخة موجودة مسبقاً في متصفح المستخدم لحظة تغيير المنفذ.

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

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. لذلك، من دون sudo، تحصل على Permission denied. يحتوي الملف على سطر بهذا الشكل:

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) جسرك إلى موزّع واحد، ويطلب المستخدمون الجسور من ذلك الموزّع. اعتباراً من October 2026، المسارات هي التالية:

• موقع الجسور على bridges.torproject.org/options، حيث يعرض الخيار "Just give me bridges!" أسطر obfs4 فوراً. لا توجد captcha؛ أزالها Tor Project عندما حلّ rdsys محل BridgeDB، وهو تغيير أعلنه في December 2024.
• إرسال بريد إلكتروني إلى 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 على تشغيل bridge لـTor؟

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

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

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

لماذا لم يتصل أحد بـbridge الجديد؟

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

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

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

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

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