هل يتأثر WireGuard Site-to-Site بحجب UDP؟ نعم، والمشكلة ليست دائمًا في المنفذ

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

«السيرفر في المكتب الرئيسي اختفى.»

لدينا شبكتان صغيرتان بينهما نفق WireGuard site-to-site. في المكتب الرئيسي توجد ملفات وخدمات داخلية، وفي الفرع أجهزة تحتاج الوصول إليها طوال اليوم. الإعداد كان مستقرًا لدرجة أنني بالكاد أفكر فيه.

ذلك الصباح كان الإنترنت في الفرع طبيعيًا.

المواقع تفتح. البريد يعمل. الخدمات السحابية تعمل.

لكن أي شيء خلف شبكة المكتب الرئيسي أصبح غير قابل للوصول.

فتحت حالة WireGuard.

لا يوجد handshake حديث.

أعدت تشغيل النفق، راجعت العناوين والمفاتيح والمسارات، ثم حاولت مرة أخرى.

لا شيء.

وهنا تغير السؤال. إذا كان الإنترنت نفسه يعمل، فلماذا اختفى الطريق الوحيد الذي يربط المكتبين؟

WireGuard يعتمد على UDP أكثر مما كنت أفكر فيه

في إعداد site-to-site من السهل التركيز على العناوين، AllowedIPs، قواعد التوجيه والمفاتيح. لكن كل ذلك يأتي بعد خطوة أبسط: يجب أن تصل حزم WireGuard بين الطرفين أصلًا.

WireGuard يستخدم UDP. لا يوجد بداخله زر يحوله ببساطة إلى TCP عندما تصبح الشبكة أكثر تقييدًا. (WireGuard)

وهذا لا يتغير لأن الاستخدام site-to-site بدل اتصال جهاز واحد. حتى أمثلة الربط بين مكتبين في توثيق MikroTik تعتمد على منفذ UDP وقاعدة تسمح بوصوله. (WireGuard)

فجأة أصبح غياب الـhandshake أهم من كل الإعدادات الداخلية التي كنت أراجعها.

ربما الشبكتان سليمتان.

ربما الطريق بينهما هو الذي اختفى.

وكان أول شيء جربته هو الحل الذي يخطر عادةً على البال: تغيير المنفذ.

وضعت WireGuard على 443… ولم يتغير شيء

نقلت الاتصال إلى المنفذ 443.

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

انتظرت handshake جديدًا.

لم يظهر.

والسبب الذي كنت أتجاهله بسيط: UDP 443 ليس TCP 443.

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

وهنا توقفت عن تغيير الأرقام.

احتجت إلى اختبار مختلف فعلًا.

أردت أولًا معرفة هل UDP كله هو المشكلة

كان لدي لابتوب إدارة داخل الفرع. بدل الاستمرار في تعديل النفق، فتحت عليه OnlydogVPN^[1] واخترت الوضع المخصص للشبكات المقيدة.

اتصل.

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

هذه كانت أول نتيجة مفيدة منذ بدء المشكلة.

الخدمة تستخدم نقلًا مبنيًا على HTTP/3 مع تمويه إضافي للحركة. وHTTP/3 يعتمد على QUIC فوق UDP. لذلك نجاح هذا الاتصال من الشبكة نفسها أخبرني بشيء مهم جدًا: UDP لم يكن مغلقًا بالكامل.

هذا اختصر نصف التشخيص.

لم أعد بحاجة إلى التصرف كما لو أن مزود الإنترنت أسقط كل حركة UDP. أصبحت المشكلة أضيق: WireGuard أو مساره أو الطريقة التي يظهر بها للشبكة.

لا أستطيع رؤية قواعد التصفية الداخلية لدى مزود الإنترنت وتحديد القاعدة التي أوقفت النفق حرفيًا. لكنني لم أعد بحاجة إلى ذلك كي أعرف أن تغيير منفذ WireGuard للمرة الخامسة ليس أفضل خطوة تالية.

هنا ظهر الفرق بين «UDP محجوب» و«WireGuard لا يمر»

الفرق يبدو صغيرًا، لكنه يغير الحل بالكامل.

إذا كان UDP كله محجوبًا، فأحتاج إلى مسار خارجي لا يعتمد عليه.

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

ومشروع WireGuard واضح في هذه النقطة: البروتوكول لا يحاول أن يكون أداة تمويه، ومقاومة الفحص أو إخفاء شكله تحتاج إلى طبقة إضافية. (WireGuard)

هذا جعلني أعيد النظر في سبب اختياري له أصلًا.

اخترت WireGuard لأنه سريع ونظيف وبسيط.

وهذه ما تزال نقاط قوة ممتازة.

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

تجارب المستخدمين أكدت أن شكل العطل ليس غريبًا

وجدت أيضًا تجارب لمستخدمي WireGuard يصفون الحالة نفسها تقريبًا: الإنترنت يعمل، إعداد النفق يبدو سليمًا، لكن حركة UDP أو الـhandshake لا يعودان بالشكل المتوقع. (Reddit)

لم أحتج إلى قصة أطول من ذلك.

كانت فائدتها فقط أنها منعتني من العودة إلى تعديل AllowedIPs للمرة العاشرة.

عندما لا يصل الـhandshake أصلًا، يجب أن أفكر في الطريق قبل أن أفكر في ما يحدث داخل النفق.

وهنا أصبحت فائدة الاتصال الثاني أكبر: بينما كنت أصلح WireGuard، لم يعد الفرع معزولًا تمامًا عن أدواتي.

OnlydogVPN^[1] لم يستبدل site-to-site، وهذا تحديدًا ما جعل دوره واضحًا

لم أحاول تحويل التطبيق إلى بديل دائم لنفق يربط شبكتين كاملتين. هذه ليست وظيفته.

لكن في لحظة العطل، كنت أحتاج شيئين مختلفين:

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

الخدمة أعطتني الاثنين.

استطعت استخدام جهاز الفرع للوصول إلى ما أحتاجه بدل انتظار عودة النفق، وفي الوقت نفسه أثبت الاتصال المبني على HTTP/3 أن هناك مسار UDP قابلًا للاستخدام.

وبذلك تحول التطبيق من «VPN احتياطي» إلى أداة تشخيص مفيدة جدًا.

لو كنت أستخدم VPN ثانيًا يعتمد على النمط نفسه ويفشل بالطريقة نفسها، لما تعلمت شيئًا جديدًا.

أما هنا، فاختلاف طريقة النقل هو الذي جعل النتيجة ذات قيمة.

وماذا لو فشل HTTP/3 أيضًا؟

عندها يصبح التشخيص أسرع.

WireGuard يعتمد على UDP.

HTTP/3 يعتمد على UDP أيضًا.

إذا فشلا معًا على الشبكة بينما يستمر HTTPS العادي في العمل، يصبح وجود مسار TCP/443 حقيقي أكثر أهمية من تجربة منفذ UDP جديد.

ولهذا ظهرت حلول تبني طبقة إضافية حول WireGuard أو تستخدم relay عندما يتعذر الاتصال المباشر. eduVPN، مثلًا، يدعم تشغيل WireGuard عبر مسار TCP للتعامل مع الشبكات التي تمنع UDP، بينما تستطيع Tailscale الرجوع إلى relay عبر HTTPS/TCP 443 عندما لا ينجح مسار WireGuard المباشر. (WireGuard) (WireGuard)

بالنسبة لي لا تحتاج الفكرة إلى تفاصيل أكثر:

إذا اختفى الطريق، أحتاج طريقًا مختلفًا فعلًا، لا رقم منفذ مختلفًا للطريق نفسه.

وهذا هو الشيء الذي لم يكن موجودًا في تصميمي الأول.

حتى PersistentKeepalive لم يعد يبدو لي كزر إصلاح

كان PersistentKeepalive ضمن الأشياء التي راجعتها أثناء العطل.

وهو مفيد عندما تكون هناك مشكلة NAT أو تحتاج إلى إبقاء حالة الاتصال حية.

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

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

بحلول هذه النقطة أصبحت الصورة أبسط بكثير:

الإنترنت يعمل.

WireGuard لا يحقق handshake.

تغيير منفذ UDP لم يساعد.

اتصال HTTP/3 المموّه خرج من الشبكة بنجاح.

إذن لم أعد أتعامل مع «UDP محجوب» باعتباره التشخيص الرئيسي.

وأصبح لدي وقت لإصلاح المسار الحقيقي بدل إعادة بناء إعداد كان يعمل بالفعل.

الشيء الذي كنت سأغيره في التصميم منذ البداية

عندما بنيت الربط بين المكتبين، كان معي معيار واحد تقريبًا: أريد نفقًا سريعًا وبسيطًا.

WireGuard كان اختيارًا منطقيًا.

لكنني اليوم أضيف سؤالًا ثانيًا:

ماذا يحدث إذا توقف هذا النوع من النقل عن المرور؟

هذا السؤال أهم من امتلاك أربعة منافذ احتياطية لـWireGuard نفسه.

أريد مسارًا مختلفًا بالفعل.

قد يكون relay.

قد يكون TCP/443.

وقد أريد أيضًا على أجهزة الإدارة خيارًا مستقلًا ومموّهًا مثل OnlydogVPN^[1] حتى لا يتحول تعطل site-to-site إلى فقدان كامل لقدرتي على الوصول والعمل من الفرع.

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

لم أكن أريد ألف وجهة.

كنت أريد طريقًا ثانيًا لا يكرر نقطة الفشل نفسها.

إذن، هل يتأثر WireGuard Site-to-Site بحجب UDP؟

نعم.

WireGuard site-to-site ما زال WireGuard، وإذا لم تصل حركة UDP بين الطرفين فلن يقوم النفق بعمله مهما كانت إعدادات الشبكتين الداخلية صحيحة.

لكن العطل علمني ألا أخلط بين فشل WireGuard وحجب UDP بالكامل.

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

وهذا غيّر معي معيار تصميم النسخة الاحتياطية.

في WireGuard site-to-site، الطريق الاحتياطي الحقيقي ليس منفذ UDP آخر؛ بل اتصال يستخدم طريقة مختلفة بما يكفي ليظل مفيدًا عندما يتوقف WireGuard نفسه عن العبور.