أمر ufw allow 443 لم يفعل شيئًا لخدمة وراء الشبكة الافتراضية

ينجح ping من عميل VPN، بينما تنتهي مهلة خدمة TCP، ولا يغيّر ufw allow 443/tcp شيئًا على الإطلاق. عندما يعمل التطبيق على مضيف خلف البوابة لا على البوابة نفسها، يكون ذلك التصريح قد كُتب لمسار حركة خاطئ. الحزمة ليست موجّهة إلى جدار الحماية ولا تُسلَّم إلى عملية محلية، لذلك لا تراها قواعد الإدخال أبدًا. الإصلاح هو قاعدة مسار تستهدف التدفق المُمرَّر، والدليل عليها موجود في السجل بالفعل.

حدّد ما إذا كانت الوجهة محلية أم مُمرَّرة

اقرأ الحزمة كما يراها النواة. الحركة التي تُسلَّم إلى خدمة على البوابة هي إدخال محلي. الحركة التي تمرّرها البوابة إلى مضيف آخر تكون مُمرَّرة، ويحتفظ UFW بمجموعتَي قواعد منفصلتين للمسارين. ويُحسم التمييز بعنوان الوجهة وبحث التوجيه، لا بواجهة الشبكة التي وصلت عبرها الحزمة.

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

اقرأ الحجب قبل إضافة أي قاعدة

أعِد إنتاج محاولة اتصال مصرّح بها واحدة وسجّل مصدرها ووجهتها وبروتوكولها ومنفذ الوجهة كما سجّلتها البوابة. قارن هذه القيم الأربع بمدخل السجل وبالموقع الفعلي للخدمة. نجاح ping سابق يثبت فقط أن تبادله هو المسموح، وقد يعامل جدار الحماية حزمة TCP SYN المتجهة إلى تطبيق معاملة مختلفة تمامًا.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

يعرض الأمر الأول الحكم مع حقوله، ويعرض الثاني ما هو محمّل بالفعل وبأي ترتيب. اقرأ الاثنين قبل تحرير أي شيء، لأن حجبًا سابقًا فوق قاعدتك يفسّر العَرَض نفسه دون أي قاعدة ناقصة.

اكتب أضيق قاعدة مسار تناسب الحالة

في هذا العرض التوضيحي يصل العملاء عبر tun0 من 172.20.8.0/24، وتستمع الخدمة على 10.30.0.15 عند المنفذ 8443، وتخرج البوابة عبر ens5. وقد اختيرت هذه القيم لتبدو مختلفة تمامًا عن القيمة الافتراضية 10.0.0.0/16 في سحابة VPC أو 192.168.0.0/16 في شبكة منزلية، ويُبقي 8443 المثال بعيدًا عن مستمع 443 الخاص بالبوابة.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

أبقِ مسار العودة معتمدًا على الحالة

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

تحقّق مما لا يستطيع UFW فرضه نيابةً عنك

القاعدة الصحيحة تحتاج أيضًا إلى تمرير النواة وإلى مسار يبلغ الخدمة. تحقّق من الاثنين قبل أن تلوم جدار الحماية مرة ثانية.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

اختم باختبار اتصال جديد وجدار الحماية مُفعّل، من مصدر مسموح وآخر غير ذي صلة. تعطيل UFW يزيل العَرَض ويهدم الدليل في الأمر نفسه، ولهذا ينبغي أن يكون التجربة الأخيرة لا الأولى.