.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
حاوياتك تخرج إلى الإنترنت الآن، لكنها ما زالت غير مرئية من الخارج. وهذا صحيح أمنياً، غير أنك ستحتاج حتماً الوصول إليها: SSH إلى سيرفر لينكس، أو RDP إلى ويندوز، أو منفذ خاص لخدمة معيّنة.
الحل هو تمرير المنافذ (Port Forwarding): تحجز منفذاً على عنوانك العام وتربطه بمنفذ داخل حاوية. في هذا الجزء ننفّذه، والأهم — نحدّد بدقّة متى يكون الحل الصحيح ومتى يكون خطأ.
كل ما في هذه السلسلة مُنفَّذ فعلاً. بنينا المختبر على سيرفر Proxmox VE 9.2 بعنوان عام واحد، وأنشأنا عليه شبكة خاصة 10.10.10.0/24 وأربع حاويات، ونشرنا ثلاثة نطاقات فرعية حقيقية بشهادات Let's Encrypt. كل لقطة وكل مخرج أمر في هذه المقالات من ذلك المختبر — والعناوين في الصور حقيقية وقت التنفيذ.
الفكرة في جملة
في NAT العادي، المضيف يترجم ما يخرج. وفي تمرير المنافذ يترجم ما يدخل: أي طلب يصل إلى العنوان العام على منفذ محدّد، يُعاد توجيهه إلى عنوان ومنفذ داخليَّين.
| ما يطلبه المستخدم | إلى أين يذهب فعلاً | الخدمة |
|---|---|---|
| 82.39.115.50:2201 | 10.10.10.11:22 | SSH لحاوية ووردبريس |
| 82.39.115.50:2202 | 10.10.10.12:22 | SSH لحاوية الأتمتة |
| 82.39.115.50:33891 | 10.10.10.30:3389 | RDP لجهاز ويندوز |
لاحظ النمط: المنفذ الخارجي مختلف لكل خدمة، والداخلي هو المنفذ القياسي نفسه. هذا هو جوهر تمرير المنافذ — وهو أيضاً حدّه الأكبر.
التنفيذ
قاعدة واحدة لكل تمرير، في سلسلة PREROUTING (أي قبل قرار التوجيه):
# SSH إلى حاوية 10.10.10.11 عبر المنفذ 2201
iptables -t nat -A PREROUTING -d 82.39.115.50 -p tcp --dport 2201 \
-j DNAT --to-destination 10.10.10.11:22
# SSH إلى حاوية 10.10.10.12 عبر المنفذ 2202
iptables -t nat -A PREROUTING -d 82.39.115.50 -p tcp --dport 2202 \
-j DNAT --to-destination 10.10.10.12:22
# RDP إلى جهاز ويندوز داخلي
iptables -t nat -A PREROUTING -d 82.39.115.50 -p tcp --dport 33891 \
-j DNAT --to-destination 10.10.10.30:3389وثبّتها في ملف الشبكة كما فعلنا مع قاعدة MASQUERADE:
post-up iptables -t nat -A PREROUTING -d 82.39.115.50 -p tcp --dport 2201 -j DNAT --to-destination 10.10.10.11:22
post-down iptables -t nat -D PREROUTING -d 82.39.115.50 -p tcp --dport 2201 -j DNAT --to-destination 10.10.10.11:22
الاختبار — من جهاز خارجي لا من المضيف
فخّ يقع فيه الجميع: إن اختبرت من داخل المضيف نفسه (curl http://82.39.115.50:2201) فسيفشل غالباً، وتظنّ أن القاعدة خاطئة. السبب أن الحزم الصادرة من المضيف تمرّ بسلسلة OUTPUT لا PREROUTING. اختبر دائماً من جهاز آخر.
# من جهازك الشخصي
ssh -p 2201 [email protected]
nc -zv 82.39.115.50 2201متى يكون تمرير المنافذ هو الحل الصحيح؟
| الحالة | الحكم | لماذا |
|---|---|---|
| SSH إلى حاويات | ✅ مناسب | بروتوكول غير ويب، ولا يفهم أسماء النطاقات |
| RDP إلى ويندوز | ✅ مناسب | السبب نفسه |
| خادم لعبة أو تطبيق بمنفذ خاص | ✅ مناسب | لا بديل عملي |
| موقع ويب واحد | ⚠️ يعمل لكن لا تفعل | ستحتاج شهادة SSL يدوياً، وستفقد المرونة لاحقاً |
| عشرة مواقع ويب | ❌ خطأ | ستحتاج عشرة منافذ غريبة، ولن يكتب زائر :8081 في متصفحه |
| قاعدة بيانات | ❌ خطر | نشر MySQL أو PostgreSQL على الإنترنت دعوة مفتوحة للاختراق |
الأمان: ثلاث قواعد غير قابلة للتفاوض
1) لا تستعمل المنافذ القياسية
المنفذ 22 المفتوح على الإنترنت يتلقّى آلاف محاولات الدخول يومياً من روبوتات آلية. نقله إلى 2201 لا يجعله آمناً، لكنه يقلّل الضجيج بنسبة هائلة.
2) قيّد المصدر متى استطعت
# اسمح فقط من عنوان مكتبك
iptables -t nat -A PREROUTING -s 203.0.113.25 -d 82.39.115.50 \
-p tcp --dport 2201 -j DNAT --to-destination 10.10.10.11:22هذه القاعدة وحدها تُلغي 99.9% من محاولات الاختراق.
3) مفاتيح لا كلمات مرور
# داخل الحاوية
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshالأفضل من هذا كله: لا تمرّر منفذ SSH إطلاقاً، بل ادخل إلى المضيف ثم انتقل منه إلى الحاويات بـpct enter. أو استعمل VPN. تمرير المنافذ حلّ عملي، لكنه يوسّع مساحة هجومك بكل منفذ تفتحه.
بديل أنيق: النفق عبر SSH بلا فتح أي منفذ
إن كان لديك وصول SSH إلى المضيف، فأنت لا تحتاج فتح منافذ للحاويات أصلاً:
# من جهازك: اربط منفذك المحلي 8080 بخدمة داخلية
ssh -L 8080:10.10.10.11:80 [email protected]
# ثم افتح في متصفحك
http://localhost:8080الخدمة الداخلية تصبح متاحة على جهازك أنت فقط، وبلا أي منفذ مفتوح على الإنترنت. هذه أفضل طريقة للوصول إلى لوحات الإدارة وقواعد البيانات.
أخطاء شائعة وحلولها
| العَرَض | السبب | الحل |
|---|---|---|
| القاعدة موجودة والاتصال يفشل | تختبر من المضيف نفسه | اختبر من جهاز خارجي |
| الاتصال يعلّق بلا ردّ | الخدمة لا تستمع أصلاً داخل الحاوية | pct exec 202 -- ss -ltnp |
| connection refused فوراً | لا توجد خدمة على المنفذ الداخلي | تحقّق من رقم المنفذ الداخلي |
| يعمل ثم يختفي بعد إعادة التشغيل | القواعد غير مثبَّتة | ضعها في post-up |
| حزم SSH تصل للحاوية الخطأ | قاعدتان بالمنفذ نفسه | iptables -t nat -S PREROUTING واحذف المكرّر |
| المنفذ 80 ممرَّر ولا يعمل | خدمة على المضيف تستمع عليه | ss -ltnp | grep :80 |
أسئلة شائعة
كم منفذاً أستطيع تمريره؟
عملياً 65535 منفذاً. لكن كل منفذ مفتوح مسؤولية أمنية — والسؤال ليس «كم أستطيع» بل «كم أحتاج فعلاً».
هل أستطيع تمرير مدى منافذ دفعة واحدة؟
نعم: --dport 20000:20010 مع --to-destination 10.10.10.11:20000-20010. مفيد لخوادم الألعاب وFTP السلبي.
ولماذا لا أستعمل جدار Proxmox الرسومي؟
جدار Proxmox ممتاز للسماح والمنع، لكنه لا يوفّر DNAT بواجهة رسومية. التمرير يبقى بـiptables في ملف الشبكة.
هل يعمل التمرير مع UDP؟
نعم، استبدل -p tcp بـ-p udp. ضروري لـWireGuard وخوادم الألعاب.
وماذا لو أردت عشرة مواقع؟
هنا يتوقّف تمرير المنافذ عن كونه حلاً — وهذا بالضبط موضوع الجزء التالي.
الخطوة التالية
في الجزء الخامس نشرح لماذا لا يصلح تمرير المنافذ للويب، وكيف يحلّ الوسيط العكسي المشكلة بمنفذين اثنين فقط مهما بلغ عدد مواقعك.
هذه المقالة جزء من سلسلة «من IP واحد إلى عشرات الخدمات» — عشرة أجزاء بُنيت كلها على سيرفر Proxmox حقيقي: ١. لماذا يكفي عنوان واحد · ٢. الشبكة الخاصة · ٣. إعداد NAT · ٤. تمرير المنافذ · ٥. الـReverse Proxy · ٦. Nginx Proxy Manager · ٧. النطاقات الفرعية · ٨. Cloudflare والشهادات · ٩. مقارنة الحلول · ١٠. سحابة صغيرة كاملة
