استثناء UFW للـ VPN عند تغيّر عنوان نقطة النهاية

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

النفق يعيد الاتصال، ثم لا يخرج شيء

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

تثبيت العنوان الذي يعيده بحث عام يجعل اليوم يعمل ويترك الغد معطلاً. ذلك تعديل لمرة واحدة، لا سياسة صيانة.

صِف الاستثناء الذي تقصده فعلاً

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

الأمر أدناه يبيّن الشكل لنقطة نهاية IPv4 UDP واحدة على وصلة سلكية. استبدل القيمتين بالقيم التي تحققت منها مقابل النشر.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

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

حدّثه كسير عمل واحد

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

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

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

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

اسحب الإذن القديم عن قصد

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

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

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