هل حجب UDP هو السبب؟ عندما يفشل WireGuard لكن نفقًا مموهًا يمر

الدليل الذي جعلني أتوقف عن إصلاح WireGuard كان نجاحه في المكان الخطأ. على Wi-Fi الفندق ظل النفق في مرحلة المصافحة، فراجعت المفاتيح، غيرت الخادم، وخفضت MTU. لا شيء. ثم شغلت نقطة الاتصال من هاتفي وربطت الحاسوب بها. خلال ثوانٍ اتصل WireGuard وفتحت لوحة العمل التي كنت أحاول الوصول إليها منذ نصف ساعة. الخادم لم يتغير، والمفاتيح لم تتغير، والحاسوب لم يتغير. الشيء الوحيد الذي تغير هو الطريق إلى الإنترنت.

كان التشخيص التالي مغريًا جدًا: الفندق يحجب UDP، وWireGuard يعمل فوق UDP، إذًا انتهت القصة.

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

WireGuard يعتمد على UDP، والمشروع نفسه يوضح أن التمويه ليس جزءًا من تصميم البروتوكول الأساسي. (WireGuard) لذلك أصبح السؤال الأكثر فائدة:

هل الشبكة تمنع UDP، أم أنها تتعرف على الطريق الذي يستخدمه WireGuard؟

هذا الفرق هو الذي حدد ما فعلته بعد ذلك.

كلمة «UDP محجوب» قد تكون تشخيصًا متسرعًا

من داخل WireGuard، تبدو الأعطال متشابهة.

لا مصافحة.

تغير الخادم، لا شيء.

تغير المنفذ، والنتيجة نفسها.

بعد عدة محاولات تبدأ بسهولة في التعامل مع UDP كله كأنه اختفى.

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

وتظهر هذه الحيرة في تجارب المستخدمين أيضًا: WireGuard قد يفشل على Wi-Fi فندق ثم يعمل فورًا عبر نقطة اتصال الهاتف. (Reddit^[2])

هذا التفصيل كان كافيًا بالنسبة لي.

إذا كان الإعداد نفسه يعمل على شبكة أخرى، فلا أبدأ بإعادة بناء المفاتيح والخادم.

أبدأ بتغيير الطريق.

كنت أعدل WireGuard بينما المشكلة أمامه

مع ذلك، جربت المنافذ أولًا.

منفذ جديد.

لا مصافحة.

منفذ آخر.

لا شيء.

ثم خادم ثانٍ.

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

في هذه المرحلة أصبحت قائمة الإعدادات هي الشيء الذي يمنعني من العمل أكثر من المشكلة نفسها.

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

هنا تغير حكمي.

لم أكن أحتاج إلى إعداد WireGuard أفضل.

كنت أحتاج إلى اتصال لا يصل إلى شبكة الفندق بالشكل نفسه.

وهذا هو السبب الذي جعل خدمات أخرى تضيف تمويهًا فوق WireGuard نفسه؛ فـMullvad، مثلًا، أضاف في 2025 تمويهًا مبنيًا على QUIC لجعل حركة WireGuard أقل وضوحًا للشبكات التي تستهدف شكله التقليدي. (Mullvad^[3])

بدل تغيير الخادم مرة أخرى، قررت تغيير شكل الاتصال.

الاختبار الثاني استخدم UDP أيضًا

فتحت OnlydogVPN^[4] على الحاسوب.

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

لكن الفندق لم يكن يطلب مني دولة أخرى.

كان يمنعني من الوصول إلى العمل.

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

ظهر الاتصال.

فتحت لوحة العمل.

حمّلت.

ثم دخلت الاجتماع.

الصوت اتصل، والجلسة بقيت قائمة.

والتفصيل الأهم أن النقل المستخدم هنا مبني على HTTP/3، أي على QUIC، الذي يعمل فوق UDP. (IETF^[5])

هذا غيّر التشخيص فورًا.

UDP لم يكن ميتًا.

كان هناك نوع آخر من حركة UDP يستطيع العبور، بينما WireGuard بالشكل الذي جربته لم يستطع.

الفرق كان في شكل الطريق

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

وهذا هو كل الجانب التقني الذي احتجت إليه.

WireGuard التقليدي يصل إلى الشبكة بنمط معروف، بينما الاتصال المموه يغير الطريقة التي تظهر بها حركة الـVPN بدل الاستمرار في إرسال النفق بالشكل نفسه. (WireGuard^[1])

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

WireGuard لم يعبر.

المسار المموه عبر.

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

لهذا يبدو WireGuard وكأنه «لا يعمل»

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

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

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

ولهذا ظهرت أدوات أخرى تحاول حمل WireGuard داخل حركة تبدو مختلفة؛ مشروع ProxyGuard، مثلًا، طُرح لمعالجة حالات يكون فيها WireGuard صعب العبور عبر بعض شبكات الفنادق والنقاط العامة. (WireGuard^[6])

بالنسبة لي، لم يعد السؤال «ما أسرع بروتوكول؟».

أصبح: أي نفق تستطيع هذه الشبكة تمريره؟

وهنا كان التمويه أكثر قيمة من فرق السرعة بين خادمين.

وماذا لو كان UDP محجوبًا فعلًا؟

هناك فرق بسيط يجب الاحتفاظ به.

HTTP/3 وQUIC يعتمدان على UDP أيضًا. فإذا لم يمر UDP أصلًا، فلن يكون نقل مبني على QUIC هو المخرج. وتوضح إرشادات IETF أن التطبيقات تحتاج إلى مسار بديل عندما تكون الشبكة من الحالات التي لا توفر اتصال UDP صالحًا. (IETF^[5])

لكن نجاح الاتصال الثاني أعطاني الإجابة التي أحتاج إليها في هذه الحالة.

كنت قد بدأت وأنا أظن أنني بحاجة إلى الهروب من UDP.

ثم اكتشفت أن UDP نفسه كان يعبر.

ما احتجت إلى تغييره هو شكل النفق الذي يحمله.

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

بعد الاجتماع اختبرت شيئًا آخر من دون قصد

تركت الاتصال يعمل وأغلقت الحاسوب.

لاحقًا نزلت إلى بهو الفندق، حيث تغيرت نقطة الوصول وضعفت الإشارة. فتحت الحاسوب وبدأت تنزيل ملف.

استعاد الاتصال نفسه واستمر التنزيل.

لم أعد إلى شاشة الخوادم.

ولم أعد تشغيل النفق يدويًا.

هذا كان السبب الثاني الذي جعل الخدمة أكثر ملاءمة للموقف. لم تساعد فقط على عبور الشبكة المقيدة؛ تعاملت أيضًا بصورة أفضل مع تغير المسار داخل شبكة الفندق.

QUIC صُمم ليستطيع الاتصال الاستمرار عند تغير مسار الشبكة، وهي خاصية مفيدة عندما يتحرك الجهاز بين نقاط الوصول أو تتغير ظروف الاتصال. (IETF^[7])

في تلك اللحظة أصبح اختبار السرعة الذي كنت أجريه في البداية أقل أهمية بكثير.

كنت أحتاج أولًا إلى نفق يدخل.

ثم إلى نفق يبقى.

لذلك لا أقفز من فشل WireGuard إلى «UDP محجوب»

قبل هذه التجربة، كان تسلسلي الذهني قصيرًا:

WireGuard فشل → UDP محجوب → أحتاج إلى TCP.

بعدها أضفت خطوة أهم:

WireGuard فشل → هل UDP محجوب فعلًا، أم أن شكل WireGuard هو الذي لا يمر؟

إذا استطاع اتصال HTTP/3 مموه أن يعمل على الشبكة نفسها، تحصل على الإجابة وأنت تحل المشكلة في الوقت نفسه.

الخدمة التقليدية بقيت ممتازة على نقطة اتصال الهاتف، حيث لم تكن هناك مشكلة أصلًا.

لكنني كنت بحاجة إلى شيء آخر على شبكة الفندق: نفق يغير شكل الطريق بدل أن يجعلني أجرّب المنفذ التالي.

وهنا كان التطبيق الأصغر أنسب للمهمة.

لم أجلس أبحث عن المنفذ الذي ستقبله الشبكة.

اخترت حالة الشبكة المقيدة، فتح العمل، ودخلت الاجتماع.

ولهذا عندما يبدو WireGuard وكأنه توقف عن العمل، لم أعد أتعامل مع «UDP محجوب» كإجابة.

أتعامل معها كفرضية.

لأن الفرق بين UDP محجوب وWireGuard الذي لا يعبر هو الفرق بين مطاردة الإعدادات وبين تغيير الطريق مرة واحدة ومواصلة العمل.