Shadowsocks و Xray: عندما يتم حظر VPN
جدول المحتويات
أتعامل كثيراً مع VPN في عملي. ليس كموضوع نظري، بل كعمل يومي عملي: ربط الفروع، منح العملاء وصولاً إلى شبكة الشركة، إبقاء الخوادم قابلة للوصول، ضبط firewalls، تجديد الشهادات، تثبيت IPsec tunnels، تتبّع مشاكل SSL VPN clients، وفهم سبب انقطاع موقع ما فجأة.
عادة يكون هذا عملاً شبكياً ثابتاً ومملاً قليلاً. وهذا بالضبط ما نريده.
لكن توجد حالات لا يكفي فيها VPN صحيح تقنياً. مع عملاء من بلدان ذات Internet منظّم أو مقيّد بشدة، مثل China أو Russia، نرى أحياناً بروتوكولات VPN التقليدية تُحظر أو تُبطّأ أو تُكتشف بشكل موجّه. وبما أنني أعمل في دبي مع عملاء دوليين جداً، فهذا ليس موضوعاً مجرداً. السؤال التشغيلي هو: كيف نحافظ على وصول شرعي إلى البنية التحتية عندما تُفلتر الوصلة في الطريق؟
هنا تظهر أسماء مثل Shadowsocks و ShadowsocksR و V2Ray و Xray-core و VLESS و Trojan و REALITY و XHTTP. في البداية تبدو كمزيج مربك من مشاريع و forks واختصارات. وبصراحة، جزء من ذلك صحيح.
عندما لا يفشل VPN عند تسجيل الدخول، بل يفشل أصلاً أثناء عبوره الشبكة، فلا يكفي الحديث عن التشفير؛ يجب الحديث أيضاً عن قابلية التعرّف.
لماذا ظهر Shadowsocks أصلاً
لم يأت Shadowsocks من عالم VPN المؤسسي التقليدي. لم يُصنع ليكون حلاً أجمل لـ site-to-site، ولا لأن IPsec كان معقداً أكثر من اللازم. الأصل كان مباشراً: في عام 2012 أراد مطوّر باسم مستعار clowwindy طريقة خفيفة للخروج من شبكة شديدة التصفية إلى الإنترنت المفتوح.
هذا يفسر التصميم. كان يجب أن يكون Shadowsocks خفيفاً وسريعاً وعملياً: ليس VPN client ثقيلاً، وليس gateway كبيراً، وليس منصة remote access فيها identity management و compliance reporting. الفكرة كانت local SOCKS5 proxy يشفّر traffic ويرسله إلى server خارج منطقة الحجب.
الحاجة لم تكن “ميزات أمنية مؤسسية أكثر”، بل “أحتاج مسار خروج يعمل من شبكة تصفي بروتوكولات ووجهات معينة”. لذلك يبقى Shadowsocks مهماً، لكنه أيضاً يُساء فهمه بسهولة. هو مكوّن transport نحيف، وليس VPN مؤسسياً كاملاً تلقائياً.
في 2015 أصبحت القصة سياسية أكثر: كتب clowwindy على GitHub أن الشرطة زارته وأن عليه إيقاف العمل. بعد ذلك استمر التطوير عبر forks وتنفيذات أخرى. أدوات كهذه تبدأ غالباً من ألم تقني محدد جداً، ثم تصبح جزءاً من سباق أوسع بين المستخدمين والمطورين وبنى التصفية.
لماذا يظهر VPN
عند الحديث عن VPN يفكر كثيرون أولاً في التشفير. هذا صحيح، لكنه جزء فقط من القصة.
لا يحتاج censor أو provider أو firewall وطني كبير إلى قراءة محتوى اتصال مشفّر كي يزعجه. غالباً يكفي أن يتعرّف على الغلاف. IPsec و SSL VPN و WireGuard و OpenVPN لها سمات نموذجية: ports، أحجام packets، أنماط handshake، سلوك الشهادات، timing، سلوك UDP، retries، أخطاء، أو عناوين server IP معروفة.
التشبيه المفيد هو الظرف لا الرسالة. محتوى الرسالة مشفّر، لكن الظرف له حجم ولون وختم ومرسل يتكرر. من يفرز الظروف لا يحتاج إلى قراءة النص ليقول: هذا النوع أعرفه، يذهب إلى فحص خاص.
Traffic الشبكة مشابه. Deep Packet Inspection و Traffic Classification لا تنظران إلى ports فقط، بل تحللان patterns. في TLS قد تظهر Client Hello fingerprints أو SNI أو certificate chains أو ALPN. وفي البروتوكولات المشفّرة بالكامل قد تصبح العشوائية الظاهرة في الحزم الأولى إشارة بحد ذاتها. أبحاث Great Firewall أظهرت أن packet lengths و entropy و printable ASCII في الحزم المبكرة مهمة أيضاً.
النقطة غير المريحة: “كل شيء يبدو عشوائياً” لا يعني تلقائياً أنه غير لافت. أحياناً هذا بالضبط ما يثير الشك.
ماذا تُظهر الأبحاث
النقطة المهمة ليست فقط أن أنظمة الرقابة تستطيع “اكتشاف VPN”. هذا معروف بشكل عام. المثير هو أن كثيراً من الاكتشافات تبدأ تقنياً بطريقة غير درامية.
مدخل جيد هو عمل GFW Report الذي عُرض في 2020 في ACM Internet Measurement Conference. GFW Report ليس منتجاً ولا vendor، بل مشروع بحث وقياس حول Great Firewall.
الخلاصة: لم يكن هذا هجوم فك تشفير سحرياً. Great Firewall جمعت بين passive observation و active probing. أولاً يصبح الاتصال مشبوهاً بسبب طول و entropy أول data packet. ثم تأتي active probes: يتصل censor بنفسه بالـ server المشتبه به، يعيد تشغيل packets قديمة أو معدلة، ويرى هل يتصرف الطرف الآخر مثل Shadowsocks server.
بالنسبة للمديرين، هذا يكشف طبقتين دفاعيتين:
- يجب ألا يبدو traffic لافتاً جداً عند المراقبة السلبية.
- يجب ألا يرد server على الاختبارات النشطة كأنه proxy.
في 2023 أظهرت دراسة GFW أخرى أن traffic المشفّر بالكامل يمكن حظره بحدسيات بسيطة. إذا كان أول TCP payload لا يبدو كـ TLS ولا HTTP ولا نص قابل للطباعة، بل ككتلة بيانات عشوائية، فقد يكون ذلك إشارة. لذلك “أقصى عشوائية” ليست دائماً أفضل هدف camouflage.
في 2024 أضافت أبحاث encapsulated TLS handshakes نقطة أخرى: حتى إذا كان tunnel الخارجي مشفّراً ومموهاً، قد يظهر TLS handshake داخلي كنمط داخل protocol stack متداخل. Random padding يساعد بشكل محدود؛ stream multiplexing يبدو واعداً أكثر، لكنه لا يحل المشكلة تلقائياً إذا بقي في النهاية application stream واحد مرئياً.
Timing و cross-layer RTTs مهمان أيضاً. Proxy يزحزح transport sessions و application sessions بالنسبة لبعضها. هذه الفروق الزمنية قد تكون قابلة للقياس سواء كان client قريباً من proxy أو بعيداً. لا يمكن إزالتها فقط بتغيير header.
النتيجة: ليست تسمية البروتوكول هي الحاسمة، بل سلوك setup بالكامل.
Shadowsocks ليس VPN تقليدياً
غالباً يوضع Shadowsocks في نفس خانة VPN. في الكلام اليومي هذا مفهوم، لكنه غير دقيق تقنياً.
Shadowsocks هو encrypted proxy مبني بشكل فضفاض على SOCKS5. يعمل client محلي ويقدّم proxy للتطبيقات، ثم يشفّر traffic ويرسله إلى Shadowsocks server بعيد. يقوم server بفك الطلب، يتصل بالوجهة الحقيقية، ويعيد الرد عبر المسار المشفّر.
هذا أخف من VPN كامل. Shadowsocks لا يدخل نظام التشغيل كله تلقائياً في tunnel. هو أداة لإرسال traffic محدد عبر مسار آخر. حسب client والنظام والمكوّنات الإضافية يمكن بناء سلوك قريب من VPN، لكن الفكرة الأساسية تبقى proxy لا site-to-site VPN.
للمديرين، هذا يصحح التوقعات:
- Shadowsocks لا يستبدل site-to-site IPsec نظيفاً.
- Shadowsocks ليس حماية سحرية من كل detection.
- Shadowsocks مفيد عندما نحتاج encrypted proxy بسيطاً وسريعاً من شبكة مقيّدة.
تقنياً تطور Shadowsocks كثيراً. الإعدادات القديمة ذات stream ciphers لا ينبغي أن تكون معيار اليوم. deployments الحديثة تنتمي إلى عالم AEAD، و Shadowsocks 2022 يضيف pre-shared symmetric key base و BLAKE3-based derivation و replay protection وتصحيحات أخرى. لكن القيد مهم: specification لا توفر Forward Secrecy. إذا انكشف المفتاح، فـ rotation النظيفة إلزامية.
shadowsocks-rust تنفيذ حديث يمكن تشغيله أيضاً عبر Docker. على server يمكن تشغيل ssserver، وعلى client يمكن استخدام sslocal. المطلوب ليس أي password، بل secrets مولدة جيداً، port قابل للوصول، ciphers حديثة، وقرار واضح حول TCP أو UDP أو كليهما.
لماذا Xray-core فئة مختلفة
Xray-core ليس فقط “Shadowsocks أحدث”. هو أقرب إلى framework لسيناريوهات proxy و tunnel.
يمكن لـ Xray الجمع بين inbound و outbound protocols مثل VLESS و VMess و Trojan و Shadowsocks و WireGuard و Hysteria و SOCKS و HTTP. فوقها توضع transports مثل RAW و WebSocket و gRPC و XHTTP أو Hysteria، مع TLS أو REALITY أو XTLS Vision. VMess يظهر في setups قديمة، لكنه أقرب إلى legacy في deployments الجديدة؛ غالباً يكون VLESS في مركز Xray الحديث.
Shadowsocks هو مفك سريع. Xray هو صندوق أدوات. يمكن بناء setup بسيط، أو سلسلة يستقبل فيها client محلي SOCKS/TUN traffic، يرسله عبر VLESS مع REALITY إلى server، ثم يخرج إلى الإنترنت عبر outbound freedom.
VLESS ليس camouflage بحد ذاته. هو proxy protocol خفيف مع UUID authentication. السرية والتخفي الحقيقيان يأتيان من طبقة transport/security أسفله، مثل TLS أو REALITY أو XTLS Vision.
REALITY مثير لأنه لا يقوم فقط بـ “TLS مرة أخرى”. من الخارج يستعير server TLS handshake لموقع HTTPS حقيقي تابع لطرف ثالث. للمراقب لا يبدو ذلك كشهادة proxy مصنوعة محلياً، بل كشهادة حقيقية لموقع حقيقي. فقط client المصرّح له يتعرف عبر key material المهيأ أنه يتحدث مع Xray server الخاص به.
هذا يعالج أساساً server-side TLS fingerprint و active probing. uTLS يساعد client side على تقليد browser Client Hellos. مع ذلك Xray ليس عباءة اختفاء: timing و packet sizes و ALPN و server behavior و nested TLS patterns قد تبقى إشارات. XTLS Vision و XHTTP مكونات مهمة، وليست ضماناً. قليل من padding لا يكفي إذا بقي النمط الأساسي للـ traffic مرئياً.
الأساليب المعتمدة على UDP مثل Hysteria أو QUIC قد تكون سريعة، لكنها في الشبكات المقيّدة كثيراً ما تُبطّأ أو تُحظر أسهل من TCP/443 الصادر. لذلك يحتاج Xray إلى انضباط: pin versions، اختبار التغييرات، قراءة release notes وعدم نسخ نصائح المنتديات بلا فهم.
الالتباس حول forks والأسماء
من يبدأ البحث يصل سريعاً إلى مقالات قديمة و GitHub forks و clients نصف مُصانة. هذا جزء من تاريخ هذه الأدوات.
Shadowsocks هو protocol و ecosystem له عدة implementations. shadowsocks-rust اختيار طبيعي اليوم لـ server حديث. implementations أقدم مثل shadowsocks-libev ما زالت معروفة، لكنها بحسب حالة المشروع قد تكون legacy أو bugfix-oriented.
ShadowsocksR كان fork تاريخياً مع أفكار obfuscation إضافية. SSR يظهر في أدلة قديمة كثيرة. اليوم سأكون حذراً: ليس لأن كل installation قديم سيئ، بل لأن client و server و crypto و updates و community تحتاج فحصاً دقيقاً.
Xray-core خرج من بيئة V2Ray، لكنه تطور مستقلاً. لذلك من الخطر نقل tutorials قديمة من V2Ray إلى Xray بلا مراجعة. بعض المفاهيم متشابهة، لكن configurations و features و recommendations تغيرت.
V2Fly ما زال مهماً كمشروع community أكثر تحفظاً حول V2Ray. Xray-core أسرع في features مثل REALITY و XTLS Vision و XHTTP. وهناك sing-box كمنصة حديثة تجمع بروتوكولات كثيرة. هنا أبقي التركيز على Xray، لكن في lab سأنظر أيضاً إلى sing-box.
نصيحتي العملية:
- للإعدادات الجديدة البسيطة: Shadowsocks بتنفيذ حديث.
- للشبكات الأصعب: Xray-core بتصميم نظيف وحديث.
- لأدلة SSR أو V2Ray القديمة: افحص حالة المشروع والأمان أولاً.
- لبيئات العملاء الإنتاجية: لا تنسخ setup دون فهمه.
ما المطلوب في الجانبين
أي setup بسيط له جانبان.
في الجانب البعيد نحتاج server خارج الشبكة المقيّدة: VPS صغير، server خاص في datacenter، أو بنية تحتية مسيطر عليها في منطقة يمكن الوصول إليها من موقع العميل. يجب أن يكون server hardened و patched و monitored و documented. إنشاء instance رخيصة ثم نسيانها يصنع خطراً طويل الأمد.
في جانب client نحتاج برنامجاً مناسباً. مع Shadowsocks يكون غالباً local SOCKS client أو تطبيق يضبط system proxy. مع Xray قد يكون Xray client، TUN mode، router setup، أو تطبيقاً يستورد profiles.
وبينهما نحتاج:
- هدفاً واضحاً
- authentication نظيفاً
- software versions حديثة
- DNS resolution مسيطراً عليه
- logging بلا بيانات عملاء غير ضرورية
- monitoring للوصول
- خطة rotation للـ servers و ports و secrets
- مراجعة قانونية وتعاقدية
النقطة الأخيرة ليست زينة. في بعض البلدان قد يكون استخدام هذه الأدوات مشكلة قانونية. وفي سياق الشركات يجب أيضاً فهم ما إذا كنا نفتح أنظمتنا، أو نشغّل شبكات عملاء، أو نوفر Internet access عاماً للموظفين.
DNS غالباً يُستهان به. إذا كان browser أو OS ما زال يحل domain عبر provider المحلي، فالتunnel يساعد نصف الطريق فقط. قد يمر المحتوى عبر proxy، لكن DNS query تكشف الوجهة. لذلك يجب اختبار DNS path و IPv6 وسلوك انقطاع tunnel.
Logging حساس أيضاً. للتشخيص نريد معرفة هل tunnel حي؛ وللخصوصية نريد حفظ أقل قدر. setup جيد يجمع technical states و latency و error rates و volume indicators، لا قوائم اتصال كاملة. Debug logs و TLS keylogs و unmasked access logs لا مكان لها دائماً في production.
Monitoring يجب أن يختبر path حقيقياً عبر tunnel، و DNS الصحيح، وحظر مناطق معينة، والفرق بين الرؤية من البلد المتأثر ومن المكتب.
كيف أصنفه تشغيلياً
بالنسبة لي، Shadowsocks أو Xray ليس بديلاً عن firewall architecture أو Zero Trust أو MFA أو segmentation نظيفة. هو transport tool لحالات خاصة.
نهج شركة منطقي:
- أولاً اختبار SSL VPN أو IPsec أو WireGuard.
- إذا حُظرت، قياس DNS و port و protocol و server IP و TLS fingerprint و UDP throttling.
- بعدها اختبار transport بديل مثل Shadowsocks أو Xray-core.
- استخدام tunnel فقط للوجهات المطلوبة.
- تقييد الخدمات الداخلية المتاحة من جهة server.
- بناء monitoring حتى لا نسمع عن الحظر أولاً من العميل.
- وجود fallback: exit ثانٍ، provider آخر، region آخر، protocol آخر.
- فصل secrets و profiles لكل موقع أو مستخدم.
- بناء logs و metrics تكفي للتشغيل دون أثر زائد.
عندما يفقد العميل الوصول، من المغري اعتبار “عاد يعمل” نجاحاً. هذا مفهوم. لكن بعد ذلك يجب التنظيف والتوثيق. وإلا يتحول workaround مؤقت إلى production path غير مرئي.
لماذا تلحق الحواجز لاحقاً
الطرف الآخر يطوّر detection باستمرار.
إذا استخدم كثيرون نفس Docker Compose ونفس port ونفس TLS fingerprint ونفس domain strategy ونفس VPS provider، يصبح pattern واضحاً. لا يُحظر “Xray” أو “Shadowsocks” كمفهوم مجرد، بل pattern محدد: handshakes، packet sizes، IP ranges، clients نمطية، fallbacks سيئة أو error responses مريبة.
Camouflage ليس feature داخل tool فقط. Camouflage هو operation: نفس الأدوات مع domains مختلفة و providers مختلفة و client profiles مختلفة و traffic patterns مختلفة قد تبدو مختلفة جداً عملياً.
لذلك أتعامل بحذر مع وعود المشاريع. إذا قال tool إنه غير قابل للاكتشاف، فهذا claim من المشروع. إذا أظهر paper أن ميزة معينة اكتُشفت في شبكة حقيقية، فهذا دليل من نوع آخر. عملياً نحتاج الاثنين: سرعة ابتكار المشاريع ورصانة البحث.
تقييمي
Shadowsocks منطقي عندما نحتاج encrypted proxy خفيفاً وسريعاً وبسيطاً نسبياً: اختبارات أولى، وصول مؤقت، وبيئات لا تعمل فيها detection شديدة جداً.
Xray-core منطقي عندما تكون الشبكة أصعب، أو نحتاج transports متعددة، أو نريد العمل بوعي مع VLESS و REALITY و WebSocket و gRPC و XHTTP. لكنه يتطلب فهماً أكبر، ومرونته تسمح بأخطاء configuration أكثر.
في بيئات العملاء لن أبيع أياً منهما كـ “بديل VPN”. سأصفه كمسار transport بديل للوصول الشرعي. هذا أقل إثارة، لكنه أصدق.
الفرق الأهم ليس Shadowsocks ضد Xray. الفرق هو: هل أفهم المشكلة التي أحلها؟ إذا كانت remote access عادية، أستخدم VPN عادية. إذا كانت المشكلة protocol detection من دولة أو provider، فيجب الحديث عن recognizability و fingerprints و operational strategy. وإذا لم أستطع شرح ذلك بوضوح، فلا ينبغي تشغيله في production للعملاء.
الخلاصة
Shadowsocks و Xray-core أدوات من عالم لا تكون فيه الاتصالات الشبكية فقط “تعمل” أو “لا تعمل”. أحياناً تُصنّف، تُبطّأ، تُختبر بنشاط أو تُحظر. من يخدم عملاء دوليين سيواجه هذه الحقيقة عاجلاً أو آجلاً.
يعجبني هذا الموضوع لأنه يجعل الشبكات ملموسة جداً: encryption و patterns و fingerprints و routing و DNS و operations و law و responsibility، وحقيقة أن tunnel يعمل لا يعني تلقائياً design جيداً.
خطوتي التالية واضحة: أريد تجربة Shadowsocks و Xray-core في lab صغير. ليس لتجاوز الرقابة بلا تفكير، بل لفهم لماذا تظهر VPN الكلاسيكية أحياناً، وأي بدائل يمكن تشغيلها بجدية تقنية.
إلى اللقاء في المرة القادمة،
Joe
