VPN عبر UDP يتوقف عند الخمول: الجدار الناري نسي مسارك

يتصل الـ VPN ويعمل لبعض الوقت، ثم يتوقف عن تمرير حركة البيانات بينما لا يزال العميل يُظهر جلسة. إعادة الاتصال تُصلح الأمر، وهذا يجعله يبدو كخطأ في العميل. السبب عادةً جدار ناري أو جهاز NAT أسقط تعيين UDP خاملًا وليس لديه أي فكرة عن أن النفق ما زال موجودًا.

العَرَض متسق بما يكفي للتشخيص: يظهر بعد الخمول، لا تحت الحمل.

كيف يبدو التوقف بسبب الخمول

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

كلاهما مرتبط بالخمول، ويحتاجان إلى إصلاحين مختلفين.

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

اعثر على الجهاز الذي نسي

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

لا تفترض أن الإعداد الافتراضي الموثّق هو المهلة على مسارك. إنه افتراضي جهاز واحد.

• موجّه منزلي: غالبًا دقائق، وأحيانًا أقل بكثير.
• NAT سحابي أو موازن حمل: ابحث عن مهلة الخمول الموثّقة الخاصة بـ UDP تحديدًا.
• جدار ناري على المضيف: مؤقتات تتبّع netfilter تنطبق على كل مسار.

تحقّق من المؤقتات على المسار الفعلي

على Linux، مؤقتات تتبّع netfilter مرئية وقابلة للضبط: sysctl net.netfilter.nf_conntrack_udp_timeout و net.netfilter.nf_conntrack_udp_timeout_stream. الثاني ينطبق بمجرد رؤية الحركة في الاتجاهين، ولهذا يمكن لنفق قائم أن يعيش أطول من مجرد فحص بسيط.

RFC 4787 يحدد سلوك NAT لـ UDP والحدود الدنيا الموصى بها. إنه المرجع الذي تستشهد به عندما يبدو افتراضي البائع قصيرًا بشكل غير معتاد.

الإبقاء على الاتصال وإعادة الاتصال أداتان مختلفتان

الإبقاء على الاتصال يحافظ على حياة التعيين؛ وإعادة الاتصال تبني جلسة ميتة من جديد. هما يحلّان أعطالًا مختلفة وليسا إعدادَي سرعة قابلين للتبادل. أداة WireGuard المسماة PersistentKeepalive ترسل حزمة بفاصل ثابت لإبقاء ارتباط NAT مفتوحًا. وخيار OpenVPN المسمى keepalive يؤدي المهمة نفسها بطريقته. لا يساعد أي منهما إذا كان الجهاز في المنتصف قد نسي المسار بالفعل ويُسقط الاتجاهين.

الفحوصات شديدة التكرار تضيف عملًا دون إصلاح الحد الخطأ.

تحقّق بطلب جديد، لا بإعادة تحميل الصفحة

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

إذا استمر التوقف، تحرّك خطوة واحدة للخارج وتحقّق من جدول حالة ذلك الجهاز.