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 چیزی نمی‌گوید، و طرحی که به آن نیاز دارد باید جداگانه آن را بیان کند. رکورد نهایی ترافیک مجاز کلاینت، رابطی که آن را حمل می‌کند، و دلیل نیاز منبع به بازنویسی را فهرست می‌کند.