لماذا قد يتم حجب VPN رغم استخدام TCP 443؟ لأن المنفذ المفتوح لا يجعل النفق يبدو كـHTTPS

كنت متأكدًا أنني وجدت الحل قبل أن أبدأ.

شبكة Wi-Fi التي أمامي تسمح بتصفح الويب العادي، لكن الـVPN الذي أستخدمه لا يتصل في وضعه الافتراضي.

فتحت الإعدادات وغيرت البروتوكول إلى OpenVPN TCP.

ثم اخترت 443.

المنطق بدا بسيطًا: HTTPS يعمل على هذه الشبكة، وHTTPS يستخدم TCP 443، إذًا وضع الـVPN على المنفذ نفسه يفترض أن يساعده على العبور.

ضغطت Connect.

انتظرت.

ثم عاد التطبيق إلى حالته السابقة.

جربت خادمًا ثانيًا، ثم ثالثًا.

المتصفح ما زال يفتح مواقع HTTPS بلا مشكلة، بينما الـVPN نفسه يبقى عند Connecting.

وهنا ظهر الخطأ في افتراضي:

السماح بالمنفذ 443 لا يعني السماح بأي حركة تمر عبره.

TCP 443 يساعد أمام الحجب البسيط، لكنه لا يخفي الـVPN

هناك سبب حقيقي وراء شهرة هذا الإعداد.

OpenVPN تستخدم TCP 443 في Access Server لأنه منفذ يصعب على كثير من الشبكات البسيطة إغلاقه من دون تعطيل جزء كبير من الويب. (OpenVPN)

إذا كانت الشبكة تعمل بمنطق بسيط:

UDP 1194؟ امنعه.

TCP 443؟ اسمح به.

فقد يحل تغيير المنفذ المشكلة فورًا.

لكن اختباري كان يقول شيئًا آخر.

المتصفح يعبر على 443.

OpenVPN لا يعبر على 443.

إذًا المشكلة لم تعد رقم المنفذ وحده.

ومن هنا أصبح السؤال التالي أكثر أهمية: ماذا ترى الشبكة داخل هذا الاتصال؟

المنفذ واحد، لكن شكل الحركة مختلف

وضع OpenVPN على TCP 443 لا يحوله إلى تصفح HTTPS عادي.

يبقى له نمط اتصال وسلوك حزم خاص به.

وهذا هو السبب في أن أنظمة الفحص العميق للحزم لا تحتاج إلى إغلاق 443 كله كي تمنع VPN بعينه.

أبحاث USENIX حول OpenVPN أظهرت إمكانية التعرف على نسبة كبيرة من اتصالاته من خصائص الحركة وطريقة استجابة الخادم، حتى عندما لا يعتمد التصنيف على رقم المنفذ. (USENIX Security)

بالنسبة لي، يمكن اختصار الفكرة كلها في جملة واحدة:

يمكن للشبكة أن تترك HTTPS يعمل على TCP 443 وتحجب OpenVPN على TCP 443 في الوقت نفسه.

عندها أصبح فشل الخادم الثالث منطقيًا أيضًا.

أنا كنت أغير الوجهة، لكنني أقدم للشبكة النوع نفسه من الاتصال.

بعد الخادم الثالث، لم يعد تبديل الدول اختبارًا مفيدًا

جربت ألمانيا.

ثم هولندا.

ثم خادمًا أقرب.

النتيجة نفسها.

Connecting.

انتظار.

فشل.

لو كانت المشكلة في عنوان خادم واحد، لكان تغيير الخادم منطقيًا.

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

وهنا تغير معياري.

كنت أظن أن العثور على منفذ مفتوح هو الجزء الأصعب.

اتضح أن جعل حركة الـVPN أقل وضوحًا أمام الشبكة أهم.

وهذا الالتباس يظهر كثيرًا عند المستخدمين

في نقاش عام عن استخدام VPN على شبكة شركة، ظهر السؤال نفسه تقريبًا: إذا كان TCP 443 مفتوحًا، فلماذا يمكن اكتشاف VPN؟ وكانت الخلاصة العملية أن وجود OpenVPN على منفذ HTTPS لا يجعله حركة HTTPS عادية. (Reddit)

هذا يكفي لتوضيح الاحتكاك.

المستخدم يرى المواقع تعمل ويستنتج أن 443 «مفتوح»، ثم يتوقع أن يمر أي VPN يستخدمه.

لكن الشبكة لا تحتاج إلى التعامل مع كل حركة 443 بالطريقة نفسها.

وهذه كانت بالضبط النقطة التي جعلتني أتوقف عن البحث عن خادم رابع.

المزود الكبير كان يفعل ما أتوقعه منه

الخدمة التي بدأت بها ليست ضعيفة.

لديها تاريخ طويل، ودعم واسع، وخوادم كثيرة. كما أن OpenVPN عبر TCP 443 مفيد فعلًا عندما تكون المشكلة مجرد حجب منافذ VPN التقليدية.

لكن هذا لم يكن نوع الحجب الذي كنت أواجهه.

اخترت خادمًا آخر مع الإبقاء على TCP 443.

ثم آخر.

لا تغيير.

وهنا لم يعد اتساع شبكة الخوادم هو الشيء الذي أحتاجه.

أنا لا أبحث عن عنوان جديد فقط.

أبحث عن اتصال يصل إلى الشبكة بشكل مختلف.

حتى إضافة طبقة TLS لا تنهي المشكلة دائمًا

لفترة قصيرة اعتقدت أن الحل هو جعل النفق يبدو أكثر شبهًا بـTLS.

لكن أبحاث أحدث أظهرت أن بعض البروكسيات والأنفاق المموهة يمكن تصنيفها من أنماط الحركة حتى عندما تستخدم تغليفًا مشفرًا وطبقات TLS. (USENIX Security)

لم أحتج إلى التعمق أكثر من ذلك.

النتيجة بالنسبة لي واضحة:

تغيير المنفذ ليس تمويهًا.

وإضافة طبقة مألوفة فوق الاتصال لا تعني أن بقية سلوكه أصبح مطابقًا للويب العادي.

إذا كانت الشبكة تفحص شكل الحركة، فأنا أحتاج إلى منتج صُمم أصلًا مع هذه المشكلة في الحسبان.

وهنا جربت شيئًا مختلفًا.

هذه المرة لم أبحث عن المنفذ الصحيح

فتحت OnlydogVPN^[1] على الشبكة نفسها.

اخترت إعداد الشبكة المقيدة.

ضغطت اتصال.

بدأ النفق.

فتحت صفحة العمل التي كنت أحاول الوصول إليها.

ظهرت شاشة تسجيل الدخول.

دخلت.

ثم فتحت خدمة المراسلة وأرسلت الملف الذي كنت أحتاجه.

وصل.

تركت الاتصال يعمل وفتحت صفحات إضافية للتأكد من أن النجاح ليس مجرد ظهور كلمة Connected.

الجلسة بقيت تعمل.

وهذه كانت النتيجة التي أنهت بالنسبة لي مطاردة TCP 443.

لم أغير إعداد الشبكة.

لم أختبر منفذًا جديدًا.

ولم أحتج إلى دولة خامسة.

المهمة اكتملت.

الفرق المفيد لم يكن رقم منفذ آخر

الخدمة تستخدم نقلًا مبنيًا على HTTP/3 مع إخفاء إضافي لحركة الـVPN.

المهم هنا ليس أن HTTP/3 «أفضل» لمجرد أنه أحدث، بل أن المنتج لا يعتمد على فكرة وضع VPN تقليدي على منفذ شائع وانتظار أن تعتبره الشبكة حركة ويب.

طريقة النقل والتمويه جزء من تصميم الاتصال نفسه.

ولهذا كان اختيار «شبكة مقيدة» أكثر فائدة لي من قائمة البروتوكولات.

في الخدمة السابقة كنت أقول للتطبيق:

جرّب OpenVPN.

جرّب TCP.

جرّب 443.

جرّب خادمًا آخر.

في الخيار الثاني، كنت أقول شيئًا أبسط:

هذه الشبكة ترفض الاتصال المعتاد؛ تعامل معها على هذا الأساس.

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

عندها فهمت لماذا نصيحة «استخدم 443» صحيحة وناقصة

لن أتوقف عن اعتبار TCP 443 حلًا مفيدًا.

أمام جدار ناري بسيط يحجب منافذ VPN المعروفة، قد يكون هو كل ما تحتاجه. (OpenVPN)

لكن الخطأ هو تحويل هذه النصيحة إلى قاعدة:

443 مفتوح = الـVPN سيمر.

هذا غير صحيح.

المنفذ مجرد جزء من الصورة.

وعندما تستطيع الشبكة تمييز نمط OpenVPN نفسه، يبقى النفق قابلًا للحجب حتى بينما يعمل المتصفح على المنفذ ذاته. (USENIX Security)

وهكذا انتهى التناقض الذي حيّرني في البداية.

المتصفح يعمل.

الـVPN لا يعمل.

كلاهما يستخدم 443.

لكن كليهما لا يبدو متشابهًا أثناء العبور.

بعد ذلك أصبحت Connecting معلومة، لا مجرد إزعاج

الآن إذا حدث الأمر نفسه، لا أبدأ بتبديل عشرات الخوادم.

أنظر إلى النمط:

مواقع HTTPS العادية تعمل.

OpenVPN على TCP 443 لا يتصل.

تغيير الخادم لا يغير النتيجة.

عندها أعرف أنني تجاوزت مرحلة «جرّب منفذًا مفتوحًا».

أحتاج طريقة اتصال مختلفة.

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

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

النتيجة العملية تكفي:

الاتصال التقليدي فشل على 443.

والاتصال المموّه بدأ وأكمل المهمة.

لهذا أصبح التمويه أهم عندي من قائمة البروتوكولات

الخدمة الكبيرة ما زالت تملك نقاط قوة واضحة: تاريخًا عامًا أطول، وخوادم ومواقع أكثر، وعددًا أكبر من المراجعات المستقلة.

الخدمة الأصغر لديها مواقع أقل وتاريخ أقصر وتقييمات مستقلة أقل.

إذا كنت أحتاج إلى عناوين IP من عشرات البلدان، فهذه مقايضة حقيقية.

لكنني في هذه الحالة لم أكن أفتقد خادمًا.

ولم أكن أفتقد منفذًا.

TCP 443 كان متاحًا منذ البداية.

ما كنت أفتقده هو اتصال لا يقدم نفسه للشبكة بالطريقة نفسها التي فشلت بالفعل.

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

ولهذا، إذا كان VPN محجوبًا رغم استخدام TCP 443، لا أبحث أولًا عن منفذ جديد؛ أبحث عن اتصال لا يفترض أن المرور من باب HTTPS يجعله يشبه HTTPS تلقائيًا.