Изходящ 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 и изключенията, защото редът има значение и новият ред не винаги печели. А страницата за изходящ NAT не е страницата за филтриране.

Преведеният източник не е разрешение да достигате до всяка дестинация. Клиентите все още се нуждаят от маршрут през тунела и правило на защитната стена, което допуска трафика им, а избраният изход се нуждае от работещ обратен път. Дръжте достъпа само до LAN отделно от разрешението за изход към интернет.

Докажете трансформацията на нова връзка

След одобрена промяна тествайте с нова упълномощена връзка, вместо да използвате отново съществуваща, защото установените състояния запазват предишната си трансформация. Потвърдете адреса на източника, който действително напуска WAN, и че отговорът се връща през същото състояние. Не изчиствайте цялата таблица на състоянията като първа стъпка; това скрива кое правило е променило резултата. Запишете режима, правилото, пула и изхода в заявката за промяна.

Този пример обхваща само изход по IPv4. Той не казва нищо за трансформация или политика за филтриране на IPv6 и проект, който се нуждае от нея, трябва да го посочи отделно. Завършеният запис изброява разрешения клиентски трафик, интерфейса, който го носи, и причината източникът изобщо да се пренаписва.