NAT الصادر في pfSense: اقرأ القواعد المُنشأة أولاً

افتح Firewall، ثم NAT، ثم Outbound، واقرأ الوضع قبل إضافة أي شيء. في وضع Automatic يُنشئ pfSense قواعد لواجهات WAN، ومن بينها قواعد لشبكات VPN للوصول عن بُعد، لذا فالمجمّع الذي أنت على وشك إضافته غالبًا ما يكون مغطّى أصلًا. غياب صف مكتوب يدويًا ليس دليلًا على غياب الترجمة. الترتيب أدناه يمنعك من تحويل الجدار الناري بالكامل إلى Manual لحل مجمّع واحد.

يحدّد الوضع من يتولى صيانة الترجمة لكل شبكة أخرى على الجهاز، وهذا قرار أكبر من استثناء VPN واحد.

وضع Automatic يغطّي مجمّع VPN أصلًا

لكل وضع مالك متمايز. يُنشئ Automatic قواعد لواجهات WAN ويُدرج شبكات VPN للوصول عن بُعد ضمن مصادره. ويُبقي Hybrid تلك القواعد المُنشأة ويتيح لك إضافة قواعد يدوية بجانبها. أما Manual فيتوقف عن إنشاء أي شيء، فيصبح كل ترجمة على الجدار الناري مسؤوليتك، بما في ذلك الترجمات التي لم تكتبها. وهناك إعداد رابع يعطّل NAT الصادر كليًا. والصف الذي يبدو مكتوبًا يدويًا لا يُثبت شيئًا حتى تعرف الوضع النشط.

في Automatic وHybrid تعرض الصفحة القواعد المُنشأة أيضًا. اقرأها قبل أن تستنتج أن مجمّع VPN بلا ترجمة: ابحث عن شبكة المجمّع في عمود المصدر وعن واجهة WAN في عمود الواجهة.

اختر Hybrid فقط لاستثناء تمت مراجعته

لا يزال الاستثناء الموثّق ممكنًا عندما تختلف سياسة الخروج فعليًا. تخيّل خادمًا يوزّع 10.90.0.0/24، حيث ينبغي أن يوفّر الجدار الناري خروجًا إلى إنترنت IPv4 وأن تختار عملية التوجيه WAN بالفعل. التحويل المتوقع هو إعادة كتابة المصدر 10.90.0.23 إلى عنوان WAN. تحقّق مما إذا كانت قاعدة مُنشأة تفعل ذلك بالفعل على ذلك المخرج؛ وإن لم تفعل، يحافظ Hybrid على التغطية التلقائية مع إضافة قاعدتك المراجَعة.

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

لا تحوّل الجدار الناري بالكامل إلى Manual من أجل مجمّع واحد. ذلك القرار يعيد إسناد الصيانة لكل شبكة داخلية ولكل تغيير مستقبلي في WAN.

NAT لا يختار المخرج

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

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

أثبت التحويل على اتصال جديد

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

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