iptables: اسمح لعملاء VPN بالوصول إلى مضيف واحد دون سواه

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

أي سلسلة تجيب عن سؤالك

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

سمِّ السؤال أولًا: من يجوز له الوصول إلى الخادم، أم إلى أين يجوز للعملاء الذهاب. معظم الشبكات تحتاج الإجابتين، في سلسلتين مختلفتين.

الحالة أولًا، ثم الإذن، ثم الرفض

لا تعمل قائمة السماح إلا إذا كانت الإباحة المحددة أعلى من الرفض العام، وإذا كانت حركة العودة مسموحة فوق الاثنين. أدخل القواعد في مواضع صريحة، ثم اطبع السلسلة باستخدام iptables -S FORWARD ليكون الترتيب مرئيًا لا مفترضًا.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

تفصيلان يحددان ما إذا كانت هذه القاعدة ستصمد أمام حركة فعلية. بدون قاعدة الحالة، فإن الردود على الاتصالات التي سمحت بها للتو تُقيَّم هي نفسها مقابل الرفض وتُسقَط. قاعدة LOG بلا تقييد قد تستهلك قسمًا صغيرًا من القرص في أول فحص يصيبه، لذا أضف -m limit --limit 10/min قبل أن تواصل التسجيل. يُرجع REJECT خطأً فورًا، وهو أرحم أثناء ضبط القائمة؛ أما DROP فيتجاهل بصمت، فتظهر كل خطأ كخطر انتهاء مهلة. اختر واحدًا عن قصد واكتب اختيارك في سجل التغيير.

التوجيه و NAT يجب أن يعملا مسبقًا

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

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

حجب البريد ينتمي إلى سلسلة مجاورة

حجب المنفذ 25 في INPUT يوقف فقط البريد الموجَّه إلى خادم VPN. العميل المخترق الذي يرسل بريدًا عبر النفق يُوجَّه، لذا يجب أن يكون الحجب في FORWARD بجوار 465 و 587. وإذا كان أحد التطبيقات يمرر البريد بشكل مشروع، فضع وجهته ومنفذه أعلى تلك القاعدة.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

اترك عداد الرفض يعمل أسبوعًا قبل أن تشدد أي شيء آخر. الرقم الذي يتوقف عن الارتفاع هو التدفق المشروع الذي كسرته للتو.

اقرأها مرة أخرى، ثم أثبتها من عميل

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

اختم بالاختبار من عميل داخل المجموعة وآخر خارجها. القاعدة التي تعمل فقط من الجهاز الذي كتبتها عليه ليست سياسة.