pfSense, исходящий NAT: сначала прочитайте созданные правила

Откройте 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, и проект, которому это нужно, должен указать это отдельно. Готовая запись перечисляет разрешённый клиентский трафик, интерфейс, который его несёт, и причину, по которой источник вообще нужно переписывать.