NAT и проброс портов на Linux: настройка iptables/nftables

Почему NAT рвёт соединения при пробросе портов

Проброс портов на Linux — это не одно правило, а два независимых преобразования. Входящий пакет получает новый адрес назначения, ответный — новый адрес источника. Пока оба направления проходят через один узел с одним набором правил, соединение живёт; как только симметрия нарушается, ответ уходит в обход таблицы состояний, и клиент видит обрыв.

Первый типовой сценарий — смена внешнего адреса: резервный канал, второй провайдер, динамическая адресация. Соединение в таблице состояний привязано к паре адресов, и при переключении линии ответ приходит уже с другого — NAT не может сопоставить его с исходным потоком. Короткие запросы это переживают, длинные сессии рвутся на середине.

Асимметричный ответ ломает доступ тише: внутренний хост отвечает через шлюз, отличный от того, куда пришёл запрос, и уходит наружу с внутренним адресом источника. Внешняя сторона отбрасывает такой пакет, а в логах видно лишь «соединение установлено» без полезной нагрузки.

Пересекающиеся подсети добавляют своё: при совпадении диапазонов офиса и облака проброс попадает не на тот хост, и правкой одного правила это не лечится. Отдельная категория — потеря правил после перезагрузки: iptables/nftables хранят набор в памяти ядра, и до применения сохранённой конфигурации узел либо открыт наружу, либо закрыт для своих.

Ниже — как каждый сценарий закрывается схемой адресации, постоянным хранением правил и контролем состояния соединений.

Что меняется после наведения порядка в правилах

Порядок начинается с того, что правила трансляции адресов перестают быть слоем накопленных правок. Каждый сервис получает свой набор с описанным назначением, а цепочки собираются в предсказуемом порядке обхода. Новый сервис добавляется одним блоком по шаблону — без поиска места, куда вклиниться между старыми записями.

Ввод нового сервиса сокращается с нескольких часов до десятков минут. Раньше смена адреса или порта требовала правок в нескольких местах, и каждую проверяли на стенде; теперь конфигурация собирается из описания сервиса, и расхождение видно сразу, а не на этапе приёмки.

Отдельно закрывается самый неприятный класс отказов — асимметричная трансляция. Если правило для входящего трафика есть, а обратное преобразование описано иначе, соединение устанавливается и рвётся на первом ответе: снаружи это выглядит как «работает через раз». Стабильность соединений держится не на удаче, а на согласованности обоих направлений, и единый источник правил убирает саму возможность такого расхождения.

Время восстановления сервиса измеряется чтением, а не поиском: журнал сбросов и счётчики на цепочках показывают, на каком шаге пакет отбрасывается. Смена внешнего адреса перестаёт быть событием — правила привязаны к интерфейсу и роли, а не к конкретному значению, поэтому переезд занимает минуты.

Обращений в поддержку становится меньше не потому, что их фильтруют, а потому что исчезает повод: типовое «порт не открывается» закрывается проверкой конфигурации до того, как дойдёт до дежурного.

Режимы NAT: сравнение подходов и ограничений

Режим трансляции определяет, что видит внешняя сторона и насколько предсказуемо ведёт себя соединение при росте нагрузки. Ниже — четыре варианта, между которыми реально выбирают при настройке iptables или nftables, с их сильными сторонами и границами применимости.

Разница проявляется не при первичной настройке, а при первой смене топологии: один режим переживает переезд сервиса правкой одной строки, другой требует пересборки правил целиком.

Общее ограничение для всех вариантов — трансляция работает с адресами и портами, но не различает смысл трафика: фильтрация по содержимому запроса и защита от прикладных атак остаются на самом сервисе. Поэтому режим выбирают вместе с политикой фильтрации, иначе проброс открывает наружу больше, чем предполагалось.

Порядок работ: сбор правил NAT, проверка, передача

Правила трансляции адресов почти никогда не собирают с нуля: на живой машине уже есть цепочки, часть добавлена вручную и нигде не описана. Поэтому мы сначала фиксируем фактическую топологию и текущий набор правил и только потом проектируем целевую схему — иначе первое же изменение ломает чужой трафик.

1. Разбор топологии. Какие интерфейсы смотрят наружу, где шлюз по умолчанию, какие сервисы должны быть доступны извне, а какие — только внутри сети.
2. Аудит правил. Выгружаем действующие цепочки iptables или nftables вместе со счётчиками пакетов: правила без трафика, дубли, пересечения, «временные» записи, которые живут годами. Итог — таблица «правило — назначение — владелец».
3. Схема трансляции адресов. Разделяем, где нужна подмена адреса источника, а где — проброс входящего порта на внутренний узел, и разводим потоки по отдельным цепочкам, чтобы правка одного сервиса не задевала соседние.
4. Проверка правил на стенде. Повторяем топологию в тестовом контуре и прогоняем целевые правила: нужные соединения проходят, лишние закрыты. Конфигурацию сохраняем в репозиторий.
5. Контрольное переключение. Применяем на боевом узле с прописанным откатом по таймеру: не прошли согласованные проверки — конфигурация возвращается к прежней автоматически, без ручной работы.
6. Наблюдение. Первые сутки следим за счётчиками, журналами и числом установленных соединений, сверяем с прогнозом и отдельно проверяем поведение при пиковой нагрузке.
7. Передача конфигурации. Отдаём файл правил под контролем версий, схему трансляции, карту портов и инструкцию по откату, разбираем с вашей командой порядок дальнейших правок.

Пакет передачи: конфигурации, схемы, регламенты

Пакет передачи — это не набор скриншотов из консоли, а рабочие конфигурации в репозитории заказчика. Каждый артефакт рассчитан на человека, который через полгода будет править правило, не писал его сам: он должен понять назначение строки, найти владельца сервиса и откатить изменение без ночного разбора.

• Файлы правил с комментариями — разбиты по зонам: внешний периметр, публичный сегмент, внутренние сети. У каждого набора указано, какой трафик он пропускает, почему правила стоят именно в таком порядке и что сломается при их перестановке.
• Схема сетевых потоков — таблица трансляции адресов, пробросы, инициаторы соединений и обратные пути. Позволяет за минуту ответить, откуда пришёл трафик и куда он уходит после преобразования.
• Политики доступа — матрица «сервис → источник → порт → обоснование». По умолчанию закрыто всё, что в матрице не описано, а каждое исключение имеет владельца и срок пересмотра.
• Регламент дежурства — сроки реакции на обрыв связи и подозрительную активность, порядок эскалации, окна плановых изменений и тот, кто подтверждает правку периметра.
• Инструкции по типовым операциям — добавить или снять проброс, проверить счётчики правил, снять дамп трафика, восстановить набор из резерва. С командами, ожидаемым выводом и признаками того, что пошло не так.
• Резервное копирование конфигураций и проверенная процедура отката: восстановление прогоняется на стенде, а не описывается «на словах».
• Карта ответственности — соответствие «правило → сервис → владелец», чтобы согласование не упиралось в одного инженера.

Пакет устроен так, чтобы правки вносились силами вашей команды, без обращения к нам за каждой строкой. При передаче проходим по каждому документу на живом стенде и отвечаем на вопросы по ходу.

Кейс: обрывы соединений после перестройки сети

Сервис работал ровно, пока сеть не перестроили: добавили второй внешний канал и вынесли часть подсетей за отдельный шлюз. В пиковые часы до 4% обращений заканчивались ошибкой соединения, а каждая перезагрузка правил NAT на шлюзе рвала уже установленные сессии. Окно простоя при плановом изменении растягивалось на 30–40 минут — часть соединений не восстанавливалась сама, и клиенты приходили с повторами.

Что нашли

Причина оказалась в одной общей таблице отслеживания соединений на два внешних интерфейса: ответные пакеты возвращались не через тот канал, с которого уходил запрос, и ядро помечало соединение недействительным. Второй слой — полная перезагрузка правил: старый набор снимался целиком, вместе с ним терялась таблица соединений и весь активный трафик.

Что изменили

Перешли на атомарное применение набора правил: новая конфигурация загружается одной операцией, старые сессии живут, поэтому плановое изменение перестало быть простоем. Развели отслеживание соединений по контурам, подняли предельный размер таблицы и запас по хеш-корзинам, выровняли таймауты под реальный профиль трафика. Маскарадинг выходного трафика настроен со случайным выбором порта — это сняло коллизии при двух каналах.

Что получилось

После перевода доля неуспешных обращений в пик снизилась с 4% до 0,15%, плановые изменения шлюза проходят без разрыва активных сессий, а инцидентов с вызовом дежурного стало ноль–один в месяц вместо семи–девяти. Решение воспроизводимо на любом шлюзе: логика одинакова и для старых наборов правил, и для нового стека (Netfilter).

Чем маскарадинг отличается от статического преобразования адресов?

Разница в том, откуда берётся подставляемый адрес. Маскарадинг — динамическое преобразование источника: ядро само берёт адрес того интерфейса, через который пакет уходит наружу, а правило работает в цепочке после маршрутизации. Статическое преобразование адресов оперирует явно заданной парой «внутренний — внешний», и эта пара не меняется при смене маршрута или перезапуске шлюза.

Маскарадинг закрывает только сценарий, где инициатива соединения изнутри: сессию открывает клиент за шлюзом, а обратные пакеты возвращаются по таблице состояний. Начать соединение снаружи нельзя — запись появляется только от исходящего пакета. Статическое преобразование это ограничение снимает: проброс публикует внутренний сервис, и входящее соединение устанавливается независимо от исходящего трафика.

По сопровождению режимы расходятся сильнее. Маскарадинг не привязан к конкретному адресу и переживает его смену на внешнем интерфейсе без правки правил, но скрывает реальный источник: для внешней стороны все клиенты выглядят одним узлом. Статическая схема читаема по адресам, зато каждая смена внешней адресации требует синхронного обновления правил и маршрутов.

Ломаются режимы тоже по-разному. Маскарадинг упирается в таблицу состояний: при множестве одновременных соединений к одному внешнему узлу свободных портов-источников не хватает, новые сессии отбрасываются, а причина видна только в счётчиках ядра. Статический вариант отказывает при асимметричном маршруте и при обращении к внешнему адресу изнутри той же сети. Выбор режима сводится к одному: нужен лишь исходящий доступ и внешний адрес не зафиксирован — маскарадинг; сервис должен принимать соединения снаружи или адрес постоянен — статическое преобразование.

Спорные моменты: двойная трансляция, асимметрия, журналы

Двойная трансляция, асимметричные ответы и конфликт правил — три случая, где NAT ведёт себя не так, как на схеме. Ниже — короткие ответы на вопросы, которые обычно всплывают на приёмке и в первый месяц эксплуатации.

Ответ не вернулся — асимметричная маршрутизация

Пакет ушёл через один канал, а ответ пришёл через другой: состояние соединения не совпало, и запрос молча сбрасывается, хотя правило на месте. Выравниваем маршруты — один вход и один выход для трафика, а политика маршрутизации для резервных каналов учитывает таблицу соединений.

Где смотреть, какое правило сработало

Счётчики пакетов показывают, какие правила совпали, но не порядок обхода цепочек. На время разбора ставим логирующее правило перед терминальным — оно фиксирует пакет до вердикта, и конфликт двух соседних цепочек виден сразу. Логирование ограничиваем по частоте, чтобы отладка не забила диск, и снимаем после разбора.

Обсудим задачу: пришлите схему сети и текущие правила

Чем точнее вводные, тем меньше допущений в оценке работ. Разбор схемы сети и текущего набора правил занимает меньше времени, чем восстановление логики по обрывкам конфигураций на сервере — поэтому просим ровно то, что снимает неопределённость.

• Схему сети или список подсетей: кто с кем должен видеться, где шлюзы, какие сегменты изолированы, где сейчас рвётся связность.
• Текущие правила в виде дампа: таблицы фильтрации, трансляции и маршрутизации целиком, а не фрагмент — часть проблем живёт на стыке цепочек и видна только в полном выводе.
• Чем управляется конфигурация: iptables или nftables, есть ли поверх обёртка вроде firewalld или ufw, сохраняется ли состояние после перезагрузки.
• Формулировку задачи: проброс порта наружу, трансляция для выхода в интернет, публикация сервиса за балансировщиком или доступ из филиала.
• Как правила применяются сегодня: руками по инструкции, через систему управления конфигурациями, шаблоном или юнитом при загрузке.
• Ограничения: допустимое окно изменений, требование к откату, кто имеет доступ к узлам и есть ли резервный канал.
• Симптомы и журналы: что именно не работает, воспроизводится ли сбой постоянно или под нагрузкой, что пишет ядро и службы в момент отказа.

С этим набором мы возвращаемся с планом внедрения и оценкой работ: порядок правок, точки проверки после каждого шага и способ вернуть прежнее состояние за одну команду. Опишите задачу и приложите то, что уже есть под рукой — остальное уточним в переписке.