إعداد Tor bridge مع obfs4 على خادم VPS

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

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

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

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

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

زمن التشغيل أهم من السرعة. تنص متطلبات relay على أنه "إذا لم تكن relay قيد التشغيل لأكثر من ساعتين يومياً، فستكون فائدتها محدودة". ويكون bridge في وضع أسوأ من relay هنا، لأن لكل عميل عنواناً واحداً ولا يوجد عنوان بديل. يؤدي كل restart إلى فصل جميع المستخدمين المتصلين به. أعد إعداد فحص منفذ TCP في Uptime Kuma مقابل منفذ obfs4 لكي تعرف في اليوم الذي يتوقف فيه عن الاستجابة.

ثبّت Tor من مستودع مشروع Tor

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

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

تأتي حزمة obfs4proxy من Debian وUbuntu نفسيهما (الإصدار 0.0.14 في Debian 13، اعتباراً من August 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 إرسال واصف الجسر إلى مرجعية الجسور بدلاً من الإجماع العام. هذا السطر هو ما يجعل relay غير مُدرج.

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

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

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

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

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

يحدد BridgeDistribution الموزّع الذي يسلّم عنوانك إلى المستخدمين. القيم المقبولة هي https وemail وtelegram وsettings وnone وany. استخدم any لأول bridge ودَع النظام يقرر. استخدم 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

لا تكفي هذه الإمكانية وحدها. تمنع NoNewPrivileges في systemd العملية من اكتساب أي امتياز لم يكن متاحاً للعملية الأصلية، وإمكانية الملف هي من هذا النوع تحديداً. لذلك يفشل obfs4proxy في الربط بالمنفذ 443 ما دام هذا الإعداد مفعّلاً.

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

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

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

يجب فتح كلا المنفذين. ويشغّل معظم مزوّدي الخدمة جدار حماية ثانياً في لوحة التحكم، ولا يعرف ufw شيئاً عنه. تؤدي قاعدة موجودة على الخادم وليست موجودة في اللوحة إلى إنشاء bridge لا يمكن الوصول إليه ولا ينشر descriptor. إذا كان أي من هذين الجانبين جديداً عليك، فراجع قواعد ufw التي يحتاج إليها VPS جديد والمقصود فعلياً بالمنفذ الذي يستمع إليه Linux. وأثناء ذلك، أمّن SSH باستخدام المفاتيح وإعداد hardened لـ 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 واحداً سيؤدي خلاف ذلك إلى إزالة جسرين في الوقت نفسه.

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

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