Настройка NAT при наличии двух интернет-каналов требует корректной обработки исходящего и входящего трафика для предотвращения асимметричной маршрутизации. Основная сложность заключается в привязке сессий к конкретному интерфейсу, чтобы пакеты ответов возвращались через того же провайдера, через которого пришли. Без правильной конфигурации политики трансляции адресов соединения будут сбрасываться, а доступ к внутренним ресурсам извне станет нестабильным.
Принципы работы Policy Based Routing и NAT
Для корректной работы двух провайдеров недостаточно просто указать два маршрута по умолчанию. Ядро системы должно понимать, какой интерфейс использовать для конкретного типа трафика. Использование Source NAT (SNAT) в сочетании с политиками маршрутизации (PBR) позволяет принудительно направлять трафик от определенных локальных подсетей или сервисов через конкретного провайдера.
Совет: При настройке NAT для двух провайдеров всегда используйте механизм маркировки пакетов (Connection Marking), чтобы гарантировать, что все пакеты одной сессии будут проходить через один и тот же шлюз, независимо от таблиц маршрутизации.
Маркировка соединений и маршрутизация ответов
Чтобы избежать проблем с обратным путем пакета, необходимо реализовать механизм отслеживания состояния соединения. Если запрос пришел через интерфейс ISP1, ответ должен уйти именно через него, даже если в системе настроен другой маршрут по умолчанию.
- Маркируйте входящие соединения на внешних интерфейсах: при поступлении пакета на интерфейс ISP1 присвойте соединению уникальную метку (connection mark).
- Создайте правило маршрутизации, которое перехватывает пакеты с этой меткой и направляет их на шлюз соответствующего провайдера.
- Настройте правило NAT (src-nat) для каждого интерфейса отдельно, чтобы подменять IP-адрес источника на адрес текущего внешнего интерфейса.
Настройка трансляции адресов для входящих запросов
При использовании двух белых IP-адресов проброс портов (Destination NAT) требует учета того, через какой интерфейс пришел запрос. Если вы настроите обычный проброс портов без привязки к интерфейсу, система может попытаться отправить ответ через шлюз по умолчанию, что приведет к отбросу пакета на стороне провайдера из-за проверки IP-адреса источника (uRPF).
Особенности настройки Destination NAT
- Указывайте входящий интерфейс (in-interface) в правилах dst-nat. Это исключает конфликты, если порты на обоих провайдерах идентичны.
- Добавьте правило src-nat для каждого проброса, чтобы пакеты, уходящие обратно, имели адрес именно того внешнего интерфейса, на который пришел запрос.
- Используйте статические маршруты для специфических хостов, если требуется обеспечить доступ к локальному серверу строго через одного провайдера.
Типичные ошибки конфигурации
Распространенная проблема — попытка использовать один общий пул NAT для обоих провайдеров. При такой схеме пакеты могут уходить через интерфейс, адрес которого не принадлежит текущей сессии, что вызывает срабатывание систем защиты провайдера.
- Отсутствие маскарадинга для конкретных интерфейсов: если забыть указать out-interface в правиле src-nat, пакеты могут уходить в «чужой» канал.
- Игнорирование проверки доступности шлюза (Gateway Check): если основной канал пропадает, NAT продолжает попытки отправлять трафик в неактивный интерфейс.
- Конфликты таблиц маршрутизации: использование одной таблицы для двух провайдеров приводит к тому, что система выбирает маршрут только по метрике, игнорируя реальное состояние канала.
Для отладки используйте трассировку пакетов (packet sniffer) на обоих WAN-интерфейсах одновременно. Если вы видите входящий запрос на ISP1, но ответ уходит через ISP2 — значит, политика маршрутизации не перехватывает пакеты обратного потока.