Перейти к содержанию

NAT и роль маршрутизатора в НАЙС.ОС

NAT преобразует адреса пакетов при прохождении через сервер. Чаще всего необходим, когда частная подсеть должна обращаться к внешней сети через адрес шлюза. В НАЙС.ОС CLOUD настройка выполняется через iptables с использованием таблицы nat, совместно с маршрутизацией ядра и цепочкой FORWARD. Сам NAT не заменяет политику фильтрации.

Высокорисковая операция

Изменение NAT и ip_forward на действующем сервере меняет пути трафика. На узле с Docker цепочки уже могут создаваться самим Docker. Не применяйте новые правила без схемы соединений, резервной консоли и полного сохранения существующих правил.

Учебная схема

Клиенты 198.51.100.0/24 ---[lan0: 198.51.100.1] НАЙС.ОС [ens3: публичная сеть]--- Интернет

Здесь 198.51.100.0/24 — учебный диапазон TEST-NET-2. В настоящей конфигурации используйте собственную выделенную подсеть. Реальные имена сетевых устройств, gateway и ограничения гипервизора выясняются по месту.

1. Проверьте текущую конфигурацию

ip -br addr
ip -4 route
sysctl net.ipv4.ip_forward
iptables -S FORWARD
iptables -t nat -S
iptables -L FORWARD -n -v --line-numbers
iptables -t nat -L POSTROUTING -n -v --line-numbers

Если адресация отсутствует, настройте её заранее через systemd-networkd, а не через временные ip addr add без постоянного профиля.

2. Маршрутизация на уровне ядра

Для роли маршрутизатора требуется net.ipv4.ip_forward=1. В НАЙС.ОС есть штатный профиль усиления безопасности, который может задавать иное значение. Отдельный профиль роли узла должен быть согласован с ним.

Пример файла после проверки необходимости:

# /etc/sysctl.d/60-niceos-router.conf
net.ipv4.ip_forward = 1

Затем используйте точечное применение sysctl -w net.ipv4.ip_forward=1 в окне обслуживания и проверьте sysctl net.ipv4.ip_forward. Постоянное значение после reboot зависит также от других файлов /etc/sysctl.d/, /usr/lib/sysctl.d/ и порядка их обработки.

3. Фильтрация FORWARD

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

# Пример правил для отдельного шлюза, не предназначен для вставки без аудита.
iptables -A FORWARD -i lan0 -o ens3 \
  -s 198.51.100.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o lan0 \
  -d 198.51.100.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Эти правила должны стоять раньше терминальных DROP/REJECT. Они не учитывают существующие DOCKER/DOCKER-USER и роли других подсетей. Сначала просмотрите iptables -S, а затем рассчитывайте точку вставки.

4. MASQUERADE

Если внешний адрес динамический, типовое правило преобразования источника выглядит так:

# ИЛЛЮСТРАЦИЯ для специально выделенного шлюза
iptables -t nat -A POSTROUTING -s 198.51.100.0/24 \
  -o ens3 -j MASQUERADE

Если внешний адрес статический, часто применяют SNAT --to-source <адрес>. Не включайте одновременно разные правила SNAT/MASQUERADE для одной и той же подсети без схемы порядка обработки.

5. Проверяем путь пакета

  1. У клиента есть маршрут по умолчанию через шлюз.
  2. net.ipv4.ip_forward=1.
  3. Фильтр FORWARD пропускает начальное и возвратное соединение.
  4. POSTROUTING осуществляет преобразование адреса.
  5. OUTPUT/INPUT самого шлюза также разрешают требуемые локальные операции.
  6. Внешняя сеть корректно возвращает пакеты на адрес шлюза.
iptables -L FORWARD -n -v --line-numbers
iptables -t nat -L POSTROUTING -n -v --line-numbers
ip route get 1.1.1.1

Для диагностики с тестовым клиентом используйте tcpdump на двух интерфейсах и контролируйте счётчики. Служебная проверка ping может быть запрещена политикой ICMP, поэтому оценивайте и TCP.

6. Контейнеры, IPv6 и откат

Docker может самостоятельно управлять таблицей nat. Предложенные правила применимы к выделенному сетевому шлюзу, но не к произвольному Docker-хосту. Читайте Docker и iptables. В IPv6 нормальной отправной точкой является маршрутизация без NAT66 и отдельные правила ip6tables; не переносите IPv4-NAT автоматически на IPv6.

Перед экспериментами сделайте архив правил через iptables-save и обеспечьте проверенный способ возврата. Удаление конкретного ошибочного правила лучше полной очистки всех цепочек. Порядок постоянного сохранения определяется установленным iptables.service и ещё требует проверки SourceN.

Источники: Core/iptables/SPECS/iptables.spec, официальные действия после установки.