قواعد إعادة توجيه المنافذ الشاملة قد تبتلع مستمع WireGuard لديك
قد تبتلع قاعدة إعادة توجيه واسعة مستمعي WireGuard وSSH الخاصين بالبوابة. اختر قواعد ضيقة أو عنوانًا عامًا منفصلًا، ثم اختبر مسار التحكم.
تشغّل بوابة عامة بالفعل WireGuard على UDP 51820 وSSH على 22 وتطبيقًا واحدًا يجب أن يكون قابلًا للوصول من الإنترنت. القاعدة المغرية تعيد توجيه كل منفذ إلى النظير وتعتبر الأمر منتهيًا. على بوابة WireGuard قد تلتقط تلك القاعدة النقل الخاص بالنفق نفسه وتحجب عنك الجهاز الذي ينهي النفق. النشر قرار توجيه مع استثناء في مستوى التحكم، وليس سطر DNAT واحدًا.
الدخول العام أم دخول النفق: اختر واحدًا
نشر خدمة ينشئ نقطة دخول جديدة إلى الإنترنت. وهو ليس مثل منح عضوية VPN لنظير، لأن الزائر لا ينضم إلى النفق أبدًا وتصبح البوابة الوجه العام للخادم الخلفي. هذا التمييز يحدد جمهور القاعدة وشهادتها.
نادرًا ما تنتمي واجهات الإدارة إلى ذلك الموضع. صفحة إدارية يصل إليها عملاء VPN المصرح لهم تُبقي سطح الهجوم داخل النفق وتتجنب تعريض نموذج تسجيل الدخول لمسح عشوائي. ما زالت نقاط نهاية التطبيقات العامة تحتاج إلى شهادة TLS خاصة بها ومصادقة وتحديد لمعدل الطلبات؛ فقفزة WireGuard المشفرة لا تحمي ساق الزائر إلى البوابة.
إذا كان يجب أن تكون الخدمة عامة فعلًا، فاكتب اسم المضيف والشهادة التي تغطيه ونطاقات الزوار التي ينبغي أن تصل إليه. تلك الحقائق الثلاث تحدد شكل القاعدة وسياسة التصفية لاحقًا. وأي شيء خارجها هو توسع في النطاق على مستمع عام.
منفذ واحد للداخل، وخادم خلفي واحد للخارج
استخدم منفذًا عامًا واحدًا وخدمة خلفية واحدة. في هذا المثال تحمل eth0 العنوان العام 198.51.100.20، وعنوان النفق للبوابة هو 10.200.0.1، ويشغّل النظير التطبيق على 10.200.0.7. يُربط TCP 9443 العام بـ TCP 8443 عند النظير:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1تطابق قاعدة SNAT الخادم الخلفي المترجَم والوجهة العامة الأصلية، لذا يبقى أي اتصال آخر بنفس الخدمة الخلفية خارج هذا التعيين. وهي تخفي أيضًا عنوان الزائر عن النظير، وهذا هو المقايض الذي يجعل العودة الموجَّهة الحافظة للمصدر تصميمًا منفصلًا. ومرجع امتدادات iptables يوثّق كلا الهدفين وخيارات المطابقة الخاصة بهما.
لا يزال التمرير بحاجة إلى تمكين، وسلسلة التصفية تحتاج إلى سماح بالوجهة والمنفذ المترجمين إضافة إلى الردود القائمة. سلسلة FORWARD ترى الوجهة المترجمة بعد DNAT، لذا لا تطابق قاعدة مكتوبة على العنوان العام الحزمة الممرَّرة. اكتب السماح على مجموعة الخادم الخلفي، لا على المجموعة العامة.
يجب أن يقبل النظير اتصال الخدمة من عنوان النفق للبوابة وأن يعيد الرد عبر النفق. ويجب أن يسمح AllowedIPs الخاص به بالمصدر الذي يستقبله فعليًا، وهو في ظل ترجمة المصدر عنوان النفق للبوابة، ولا حاجة في هذا التصميم إلى إدخال شامل 0.0.0.0/0 على كل نظير. ما يُسقط حركة العودة هو نظير تُغفل قائمته ذلك العنوان، أو تصميم حافظ للمصدر يمرّر عنوان الزائر نفسه بدلًا منه، لذا تحقق من المصدر الذي يراه النظير فعلًا لا من المصدر الموجود في قاعدتك.
أبقِ مستمعي البوابة نفسها خارج القاعدة
استبدل مطابقة المنفذ بقاعدة تغطي كل وجهة TCP وUDP، فيقع مقبس WireGuard الخاص بالبوابة داخلها. ترجمة الوجهة تحدث قبل أن تقرر الآلة أن الحزمة محلية، لذا قد ينتهي UDP 51820 عند النظير بدلًا من العملية التي تحتفظ بكل اتصالات النظير. تُحمَّل القاعدة بنجاح ويموت النفق، وهو عطل يصعب قراءته من جهة النظير.
SSH ووكلاء المراقبة وأي خدمة أخرى مستضافة على البوابة تواجه التعرض نفسه. القاعدة التي تمرر كل شيء لا تميز مستوى التحكم عن التطبيق المنشور، وأول إعادة تشغيل بعد التغيير هي لحظة ظهور الإغلاق. القاعدة الشاملة لا تحذر من الخدمة التي تتولى أمرها بصمت. تكتشفها عندما يفشل الاتصال التالي.
إذا احتجت إلى تمرير واسع فعلًا، فاحجز منافذ التحكم قبل القاعدة الشاملة أو استخدم عنوانًا عامًا منفصلًا للنشر. الخيار الثاني أنظف لأن عنوان التحكم يحتفظ بسياساته، لكن على المزود أن يوفر ذلك العنوان؛ فإضافة سجل DNS لا تخصص واحدًا.
التمرير الواسع لـ TCP وUDP ليس كل البروتوكولات أيضًا. ICMP وIPv6 وتغذية راجعة لمسار MTU والنقل الخارجي لـ VPN تحتاج إلى سياساتها الخاصة، والقاعدة التي تغطي TCP وUDP تترك تلك الحالات للسلسلة الافتراضية.
اختر النموذج قبل كتابة القواعد
أربعة أشكال تغطي معظم منشورات البوابة، ويعتمد الاختيار على عدد الخدمات التي تشغلها ومقدار مخاطر مستوى التحكم التي يمكنك تحملها. والجدول أدناه يرتبها من الأضيق إلى الأوسع.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
ابدأ بالنموذج الضيق حتى إذا كنت تتوقع خدمات أكثر لاحقًا. فهو الأسهل في التدقيق، وتحويل مجموعة قواعد ضيقة إلى قاعدة شاملة مُراجَعة أبسط من اكتشاف المستمع الذي التقطته قاعدة واسعة. وأي نموذج تختاره، فأبقِ القواعد لدى مالك الجدار الناري. إن تطبيق أسطر iptables بجوار إعداد UFW أو nftables يدير السلسلتين نفسيهما ينتج سياسة تتغير حسب ترتيب الإقلاع.
أثبت النشر ومسار التحكم معًا
اختبر من عميل خارجي مصرح له باستخدام اسم المضيف المعتمد وشهادة صالحة له. تأكد من الخادم الخلفي الذي أجاب، ثم تحقق من بقاء المنافذ العامة غير ذات الصلة مرفوضة. تعطيل فحص الشهادة ليس اختبار HTTPS ناجحًا، والاتصال الذي يصل إلى الخادم الخلفي الخطأ أسوأ من اتصال فاشل.
بعد ذلك تحقق من البوابة نفسها: وصّل نظير WireGuard وافتح جلسة SSH وتأكد من أن المراقبة ما زالت تُبلغ. يمكن أن تعمل الخدمة المنشورة بينما مستوى التحكم معطل، لذا ينتمي الفحصان إلى نافذة التغيير نفسها. أعد التشغيل مرة واحدة لتثبت أن القواعد تُطبَّق من جديد بالترتيب المتوقع، ثم أزل النشر وتأكد من أن الإزالة تطابق الإضافة فعلًا. ومجموعة كبيرة من الإضافات عند الإقلاع مع إزالة غير مكتملة هي الطريقة التي يصبح بها اختبار مؤقت ثغرة دائمة.