كيف حجبت مصر ديسكورد قبل أن تعيده مرة أخرى للحياة؟

أطلق ناشطون على جروب باسم GenZ002 داخل تطبيق ديسكورد استفتاءً إلكترونيًا بعنوان "الاستفتاء الشعبي لعزل السيسي"، يدَّعي قياس رأي المصريين حول عزل الرئيس، تجاوز عدد المشاركين فيه 330 ألفًا. بالتزامن، انتشر على السوشيال ميديا هاشتاج #عزل_السيسي.

ورغم أن هذا الاستفتاء لا يحصر التصويت على المصريين فقط ولا الشباب فقط، وبالتالي لا يقدم نتائج محكمة، ولا يترتب عليه أي أثر؛ شكا مستخدمون لديسكورد من عدم تمكنهم من الدخول للتطبيق من داخل مصر يومي 11 و12 يناير/كانون الثاني الحالي، بينما قال مَنْ استخدموا VPN إنهم نجحوا في الوصول.

فهل حجبت مصر ديسكورد أم كان هذا مجرد عطل فني؟

في هذا التحقيق، وثّقت المنصة ومؤسسة مسار، تعطيلًا واسع الأثر طال ديسكورد داخل مصر يومي 11 و12 يناير، قبل عودة القدرة على الوصول له بصورة طبيعية قرب منتصف ليل 12 يناير. وخلال ساعات الرصد، ظلَّ التطبيق في حالة محاولة اتصال مستمرة، أو توقف عند مرحلة تحميل لا تكتمل.

اعتمد التوثيق على قياسات تقنية على شبكات اثنين من مزودي خدمة الإنترنت في مصر؛ وي وفودافون. وركّزت على نطاقين أساسيين داخل منظومة ديسكورد، لكل منهما دور مختلف. الأول هو gateway.discord.gg بوصفه بوابة الاتصال اللحظي المسؤولة عن تشغيل المحادثات الحية وتبادل الرسائل real time، والثاني هو discord.com بوصفه نطاق الموقع والخدمات الأساسية المرتبطة به.

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

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

يُرجّح هذا النمط وجود تدخل انتقائي في بداية تأمين الاتصال، عبر آلية تفحص بيانات الاتصال قبل اكتمال التشفير ثم تمنع استمرارها عندما تكون الوجهة ديسكورد، وهو ما يتسق مع تقنيات الفحص العميق للحزم/DPI أو ما يقوم بوظيفتها.

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

كيف وثّقنا الحجب؟

اعتمد توثيق حجب ديسكورد على منهج مبني على أكثر من طبقة، بحيث يدعم كل مسار نتائج المسار الآخر، وبحيث تظل الاستنتاجات قابلة للمراجعة والتدقيق. في الطبقة الأولى، استخدمنا قياسات معيارية عبر أداة OONI (قياسات النطاقين الأول والثاني)، وهي أداة شائعة الاستخدام لرصد أنماط الرقابة وتعطيل الخدمات على الشبكات.

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

بالتوازي، أجرينا اختبارات يدوية لإعادة إنتاج سلوك الاتصال خارج تطبيق ديسكورد نفسه، والتحقق من النتائج من خلال أدوات تشخيص معروفة في مجال الشبكات مثل OpenSSL، وcurl، وnc، وtcpdump، وذلك لفهم طريقة بدء الاتصال وتقدمه خطوة بخطوة، وتحديد لحظة التوقف. خلال ذلك، راعينا عدم اعتماد النتائج على أداة واحدة ولا طريقة قياس واحدة، بهدف تقليل احتمالات الخطأ الناتج عن قيود أداة بعينها، وعدم الاعتماد على قراءة واحدة للمشهد.

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

ماذا يخبرنا OONI؟

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

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

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

لتجنب الخلط بين تعطيل محلي وتوقف عالمي للخدمة، يعتمد OONI على ما يمكن وصفه بـ "مقارنة مرجعية من خارج الشبكات محل الرصد". أي أنه لا يكتفي باختبار الاتصال من داخل شبكة محلية، مثل وي وفودافون، ويقارن النتيجة باختبار مماثل يُجرى من بيئة إنترنت مختلفة لا تخضع لظروف الشبكة الجاري رصدها.

والهدف من هذه المقارنة هو إجابة سؤال "هل ديسكورد متعطل في كل مكان؟". وعندما ينجح الاتصال بالخدمة من خارج الشبكات المحلية بينما يفشل من داخلها، فهذا يعني أن الخدمة تعمل، وأن المشكلة مرتبطة بمسار الوصول داخل الشبكات المحلية.

في حالة gateway.discord.gg نجحت المقارنة الخارجية في الوصول إلى الخادم واستلام استجابة برمز 404، وهو ما يؤكد وصول الاتصال إلى وجهته وأن الخادم رد، ولا يعني ذلك وجود عطل في الخدمة. وذلك لأن طبيعة هذا النطاق تختلف عن مواقع الوِب المعتادة؛ فهو مخصص لقناة اتصال لحظي يعتمد عليها التطبيق لتبادل البيانات بصورة مستمرة، وليس لتقديم صفحات يمكن تصفحها بالطريقة التقليدية. 

وفي حالة discord.com نجحت المقارنة الخارجية أيضًا واستلمنا استجابة برمز 200، بما يشير إلى أن الموقع والخدمات الأساسية يعملان بصورة طبيعية خارج الشبكات محل القياس.

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

نتيجة القياسات اليدوية

دعمت الاختبارات اليدوية نتائج قياسات OONI عبر إعادة إنتاج سلوك الاتصال خارج أداة القياس نفسها، باستخدام أدوات تشخيص شائعة تساعد على تتبع ما يحدث خطوة بخطوة. بدأ التحقق بأداة netcat (nc)، وهي أداة بسيطة تختبر قدرة الجهاز على فتح اتصال أولي مع خادم عبر منفذ محدد.

هنا أظهرت النتائج أن الجهاز ينجح في إنشاء اتصال مع خوادم النطاقين عبر المنفذ المعتاد الذي تعتمد عليه غالبية الخدمات على الإنترنت (نجحت مرحلة TCP connect على 443 لكلا النطاقين)، ما يستبعد تفسير التعثر على أنه غلق للمنفذ أو منع للاتصال من الأصل. لكن نجاح هذه الخطوة وحدها لا يكفي لتشغيل ديسكورد، لأنه لا يعتمد على اتصال مفتوح فقط، بل يحتاج تحويله إلى اتصال آمن قبل تبادل البيانات؛ الانتقال من TCP إلى TLS.

بعد ذلك استخدمنا أداة curl التي تساعد على تتبّع تقدّم محاولة الاتصال. وأظهرت النتائج أن المستخدم يبدأ الاتصال بصورة طبيعية ويصل إلى خوادم الخدمة (resolve + connect على 443)، ثم يتوقف عند المرحلة التي يفترض أن يتحول فيها الاتصال إلى تواصل آمن يسمح بتبادل البيانات، فلا يصل ردّ من خادم ديسكورد لبدء تشغيل التطبيق بصورة طبيعية، وتفشل المحاولة بعد انتظار. تتوقف المحاولة عند إرسال TLS ClientHello وتنتهي بـ SSL connection timeout.

وأكدت أداة OpenSSL s_client النتيجة نفسها بطريقة أخرى. إذ أظهرت أن محاولة الاتصال تتوقف عند تأمين الاتصال، فلا يحصل الجهاز على الاستجابة التي يفترض أن يتلقاها كي يبدأ التواصل الآمن، وتنتهي المحاولة بعد مهلة انتظار دون أن يكتمل الاتصال (لا تصل ServerHello ولا تظهر شهادة الخادم، وتنتهي العملية بـ timeout/exit code 124).

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

وبعد تثبيت هذه العوامل، ركّزنا على ما يتغير فعليًا. ففي بداية أي اتصال آمن بخدمة على الإنترنت يرسل الجهاز تعريفًا بالخدمة التي يريد الوصول إليها، أي يذكر اسم الموقع أو الخدمة التي يحاول فتحها، لأن الجهة المقابلة (الخوادم) تحتاج أن تعرف أي خدمة يقصدها المستخدم كي ترد بالطريقة المناسبة (قيمة SNI داخل TLS ClientHello). وعندما حاولنا الوصول إلى ديسكورد، توقفت المحاولة مبكرًا ولم يصل الرد الذي يسمح ببدء الاتصال الآمن، فظل التطبيق غير قادر على العمل (SNI=gateway.discord.gg أو discord.com ⇒ timeout).

 وفي المقابل، عندما قدّم الجهاز التعريف على أنه يطلب خدمة أخرى باسم مختلف، اكتملت مرحلة الاتصال الآمن على الخادم نفسه وتحت الظروف نفسها (SNI=cloudflare.com ⇒ CONNECTION ESTABLISHED، كما يظهر أيضًا نجاح الاتصال عند غياب SNI). 

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

ماذا تكشف حزم البيانات؟

في تجربة استخدام فعلية لديسكورد، أظهرت سجلات الاتصال (PCAP) أن التطبيق يبدأ محاولة الاتصال بشكل طبيعي ويصل إلى خوادم الخدمة عبر بوابة الاتصال اللحظي (gateway.discord.gg)، ثم ينتقل إلى المرحلة التي يفترض أن تتحول فيها المحاولة إلى اتصال آمن يسمح للتطبيق بالعمل وتبادل البيانات (فتح اتصال TCP على 443 يكتمل أولًا عبر تسلسل SYN ثم SYN/ACK ثم ACK). 

عند هذه المرحلة يرسل التطبيق رسالة البداية التي تعلن أنه يريد فتح جلسة آمنة مع ديسكورد (TLS ClientHello مع SNI=gateway.discord.gg)، لكن السجلات لا تُظهر وصول الرد اللازم من الخوادم لبدء هذا الاتصال الآمن (غياب TLS ServerHello؛ فلتر Wireshark: tls.handshake.type == 2 لا يعثر على حزم). 

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

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

تكرر النمط نفسه عند محاولة الوصول إلى نطاق ديسكورد الأساسي discord.com. بدأ الاتصال بصورة طبيعية (TCP SYN/SYN-ACK/ACK على 443)، ثم حاول التطبيق الانتقال إلى الاتصال الآمن (TLS ClientHello مع SNI=discord.com)، ثم توقفت العملية عند الخطوة نفسها من دون أن يظهر الرد المطلوب لبدء التشغيل (لا يظهر ServerHello داخل التدفق)، ثم انتهت المحاولة بإغلاق قسري بعد انتظار يقارب دقيقة (RST/ACK من جهة الخادم). 

تكرار المشهد في نقطتين أساسيتين من منظومة ديسكورد يعني أن المشكلة لا ترتبط بجزء واحد فقط من الخدمة، بل تظهر في أكثر من مسار رئيسي يحتاجه التطبيق لكي يعمل.

وفي الوقت نفسه، قدَّمت السجلات دليلًا على أن المشكلة ليست عطلًا عامًا في الإنترنت أو في قدرة الموبايل على إنشاء اتصالات آمنة. إذ أنه داخل جلسة الاستخدام نفسها، ظهرت اتصالات أخرى مرتبطة بخدمات مساندة يستخدمها التطبيق عادة، ونجحت هذه الاتصالات في الانتقال إلى الوضع الآمن بصورة طبيعية، واستمرت في تبادل البيانات من دون تعثّر (مثال: اتصال إلى sentry.io يعمل بشكل طبيعي). 

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

الحجب باستخدام الفحص العميق للحزم

ترجّح نتائج الرصد استخدام آلية تعتمد على فحص جزء من الاتصال قبل أن يبدأ التشفير الكامل، وهو ما يتسق مع تقنيات الفحص العميق للحزم/DPI أو ما يقوم بوظيفتها، وهي تجهيزات وسيطة تستطيع قراءة أجزاء من الاتصال قبل التشفير الكامل، ثم تتخذ قرارًا بالمنع بناءً على مؤشرات مثل اسم الخدمة الذي يعلنه الجهاز في بداية الاتصال. 

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

وتزداد قوة هذا الترجيح لأن التعطيل يبدو انتقائيًا مرتبطًا باسم ديسكورد نفسه، لا بعنوان خادم بعينه. في اختبارات مقارنة، ظل الخادم والمنفذ والشبكة ثابتين، لكن تغيير الاسم المُعلن في بداية الاتصال غيّر النتيجة: عندما لا يكون الاسم ديسكورد ينجح بدء الاتصال الآمن، وعندما يكون الاسم gateway.discord.gg أو discord.com يتوقف الاتصال في المرحلة نفسها. 

كما تُظهر ملفات الالتقاط أثناء الاستخدام الفعلي النمط ذاته داخل جلسات التطبيق نفسها، مع إغلاق قسري لاحقًا للاتصال (RST/ACK) رغم أن اتصالات آمنة أخرى داخل البيئة نفسها تكتمل بصورة طبيعية.

هذا لا يعني أن القياسات تكشف الجهاز المستخدم أو موقعه داخل الشبكة أو الجهة التي تديره، لأن ذلك يحتاج قياسات إضافية أدق لتحديد ما إذا كانت الشبكة تُسقِط رد الخادم أو ترسل إشارة إغلاق قسري أو تستخدم آلية أخرى.

الخلاصة العملية تُرجّح أن التعطيل لا يمنع الوصول إلى الإنترنت ولا يغلق المنفذ ولا يقطع الاتصال من البداية، لكن يعرقل ديسكورد عند بداية الاتصال الآمن بطريقة انتقائية مرتبطة باسم الخدمة، وهو نمط يتسق بقوة مع تدخل قائم على الفحص العميق للحزم/DPI أو آليات تؤدي الوظيفة نفسها.