جدار Proxmox لسيرفر WireGuard: القواعد والترتيب الآمن

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

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

افهم المستويات أولاً

يعمل جدار Proxmox على ثلاثة مستويات، ولكل منها وظيفة:

نقطتان مهمتان هنا. قواعد الـNode تخص العقدة، ولا تحمي الـVM. وقواعد الـVM لا تعمل إلا بثلاثة شروط معاً: تفعيل الجدار في Datacenter، وتفعيله في الـVM، وظهور firewall=1 على بطاقة الشبكة.

القفل الذاتي: الفخ الأول

حين تفعّل الجدار في Datacenter، تتغير قواعد الدخول إلى العقد أيضاً. فإذا كانت سياسة الدخول DROP، وأنت تدير السيرفر عبر عنوان عام، فقد يُغلق عليك منفذ 8006 ومنفذ SSH في اللحظة نفسها.

لذلك اتبع هذا الترتيب بدقة:

1. تأكد أن لديك وصولاً بديلاً، مثل وحدة تحكم خارج النطاق توفر الشاشة.
2. أضف أولاً قاعدة السماح لعنوانك الإداري في Datacenter أو Node.
3. لا تفعّل الجدار قبل مراجعة السياسة الافتراضية.
4. فعّل، ثم افتح جلسة جديدة دون إغلاق القديمة، وتأكد أنك تدخل.

# /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -source <ADMIN_IP> -p tcp -dport 8006 -log nolog
IN ACCEPT -source <ADMIN_IP> -p tcp -dport 22 -log nolog

ضع قاعدتي الإدارة قبل كتابة enable: 1. وإذا كان لديك عقد متعددة، فتأكد من بقاء اتصالها ببعضها، فإن Proxmox يسمح عادة بالحركة الأساسية بين العقد، لكن راجعها بعد التفعيل.

قواعد VM سيرفر WireGuard

الهدف هنا: UDP للنفق من أي مكان، وSSH من عنوان الإدارة فقط، ورفض ما عدا ذلك.

# /etc/pve/firewall/<VMID>.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -p udp -dport 51820 -log nolog
IN ACCEPT -source <ADMIN_IP> -p tcp -dport 22 -log nolog
IN Ping(ACCEPT) -log nolog

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

ثم فعّل الجدار على البطاقة وتحقق:

# أبقِ MAC والخيارات الحالية كما هي، وأضف firewall=1
qm config <VMID> | grep ^net0
qm set <VMID> --net0 virtio=<MAC_ADDRESS>,bridge=vmbr0,queues=4,firewall=1

pve-firewall status
pve-firewall compile | head -40

ما لا يراه جدار Proxmox: حركة داخل النفق

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

لذلك تُضبط قواعد ما بعد التشفير داخل الـVM. مثلاً، إذا كنت لا تريد أن يتحدث العملاء مع بعضهم:

iptables -I FORWARD 1 -i wg0 -o wg0 -j DROP

وإذا أردت مجموعة تصل إلى سيرفر داخلي واحد فقط، فاسمح بها صراحة ثم ارفض الباقي:

# الأمر الثاني يوضع فوق الأول، فيُفحص قبله
iptables -I FORWARD 1 -i wg0 -d <INTERNAL_NET> -j DROP
iptables -I FORWARD 1 -i wg0 -s 10.66.66.2/32 -d <INTERNAL_SERVER_IP> -j ACCEPT

لاحظ استعمال -I لا -A. فالقواعد تُفحص بالترتيب، ولو أضفتها إلى نهاية السلسلة لسبقتها قاعدة السماح العامة التي كتبناها في PostUp، ولما كان لها أثر. وأضفها إلى PostUp بعد تلك القاعدة حتى تبقى بعد إعادة التشغيل.

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

راجع ما يعمل داخل الـVM

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

ss -tulpn

امنع انتحال العناوين

يوفر Proxmox خيار ipfilter في إعدادات الـVM، وهو يمنعها من إرسال حزم بعنوان غير العناوين المسموحة لها. وهذا مفيد إن اختُرقت الـVM، إذ لا تستطيع انتحال عنوان جار. لكن راجع قائمة العناوين المسموحة قبل التفعيل.

# في قسم [OPTIONS] من ملف الـVM
ipfilter: 1

لا تكسر MTU بجدارك

كثيرون يرفضون ICMP كله. لكن رسائل «الحزمة كبيرة» جزء من ICMP، وحجبها يسبب توقف الصفحات والملفات الكبيرة. وبما أن الجدار يتتبع الاتصالات، فهذه الرسائل تُقبل عادة كحركة مرتبطة باتصال قائم. لكن لا تضف قواعد تعطل ذلك.

أما قبول ping فليس ضرورياً، لكنه يسهّل التشخيص. والقرار لك.

انتبه لجدول conntrack

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

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# ابحث عن رسالة امتلاء الجدول
journalctl -k | grep -i "table full"

إذا اقترب العدد من الحد الأعلى، فارفعه بإعداد دائم في /etc/sysctl.d/، مع مراعاة الذاكرة المتاحة. وراقب هذا الرقم على العقدة وعلى الـVM معاً، فلكل منهما جدوله.

وإذا أقفلت نفسك فعلاً؟

ادخل عبر وحدة التحكم، وأوقف خدمة الجدار مؤقتاً، ثم صحح القاعدة وأعد التشغيل:

pve-firewall stop

# بعد تصحيح القاعدة
pve-firewall start

وللتحقيق في حزمة مرفوضة، فعّل السجل على القاعدة بتغيير -log nolog إلى -log info، وراجع الملف /var/log/pve-firewall.log. أعد القاعدة إلى حالتها بعد الانتهاء، حتى لا تتضخم السجلات على سيرفر مزدحم.

قائمة فحص بعد التفعيل

• افتح جلسة إدارة جديدة قبل إغلاق القديمة.
• اختبر من خارج شبكتك أن المنافذ غير المسموحة مغلقة فعلاً.
• تأكد من نجاح مصافحة عميل بعد تفعيل الجدار.
• اختبر نقل ملف كبير عبر النفق، لا ping فقط.
• احفظ نسخة من ملفات .fw قبل أي تعديل.

اكتب قواعدك كما تكتب التوثيق

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

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

الخلاصة

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

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