حدّد نطاق قاعدة SNAT الخاصة بـ OpenVPN قبل أن تُعطّل nginx

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

تأكد من أن الحاوية قادرة على إنشاء جهاز tun

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

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

قرّر ما يفعله MASQUERADE على هذه الواجهة

على جهاز افتراضي عادي تكون قاعدة الخروج المعتادة هي POSTROUTING MASQUERADE من الواجهة الرئيسية. في حاوية OpenVZ يكون الجهاز المرئي غالباً venet0، وهي واجهة افتراضية يديرها المضيف لا بطاقة شبكة موجّهة، وMASQUERADE لا يتصرف هناك دائماً كما تفترض الدروس.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

احصر القاعدة في مجموعة واحدة وواجهة واحدة

للعراض الثاني سبب مختلف: قاعدة POSTROUTING بلا قيد مصدر ولا قيد خروج. مثل هذه القاعدة تعيد كتابة كل حزمة تغادر المضيف.

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

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

اجعل القواعد دائمة واعرف من يملكها أيضاً

تختفي القواعد المضافة يدوياً عند إعادة التشغيل، لذا احفظها بـ iptables-save أو أدرها عبر netfilter-persistent حيث يكون مثبتاً. تأكد من أن الاستعادة تعمل قبل بدء OpenVPN. ثم أعد التشغيل مرة واحدة عن قصد بدلاً من اكتشاف الفجوة أثناء حادث.

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

تحقق بالعدادات وبمسار واحد ملتقط

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

على الخادم، اقرأ عدادات الحزم على قاعدتي NAT وFORWARD بـ iptables -t nat -L -v -n وراقب مساراً واحداً في التقاط. إذا ظهر عنوان العميل في الالتقاط ولم يتبع رد، فالثغرة في مسار العودة أو في تصفية المزود لا في ملف تعريف العميل. قارن المصدر الملتقط بالعنوان الذي تترجم إليه القاعدة، لأن عدم التطابق يعني أن قاعدة أخرى طابقت أولاً. مسار واحد مرصود يحسم أكثر من صفحة قراءة إعدادات.

أبقِ المجموعة والعنوان المترجم واسم الواجهة معاً في سجل التغيير. القاعدة الصحيحة لمجموعة واحدة تترجم المجموعة التالية خطأً.