Загрузка

NAT (Network Address Translation) — подробный разбор с практикой (MikroTik + Linux)

Ниже — всё, что нужно знать о NAT: что это, зачем, какие виды бывают, как работает «под капотом», типичные сценарии (port-forward, 1:1, masquerade, hairpin), проблемы (CG-NAT, протоколы с встраиваемыми IP), отладка и лучшие практики. Примеры команд для MikroTik RouterOS и Linux (iptables/nftables) включены.

Коротко: что такое NAT и зачем он нужен

NAT — это замена IP-адресов и/или портов в IP-пакетах на пограничном устройстве (роутере), чтобы:

  • несколько внутренних устройств могли выходить в интернет через один публичный IP (экономия IPv4),

  • обеспечить проброс/доступ внутрь локальной сети (port-forward),

  • скрыть внутреннюю структуру сети (доп. уровень «безопасности»).

NAT обычно выполняется на границе сети (gateway), и чаще всего работает statefully: создаётся запись трансляции (conntrack), по которой возвращённые пакеты правильно маппятся на внутренний хост.

Виды NAT (по назначению)

1) Source NAT (SNAT)

Подмена исходного адреса (src IP) на внешний IP на выходе в интернет.

  • Статический SNAT: конкретная замена (to-addresses = X).

  • Masquerade: динамический вариант SNAT для интерфейсов с меняющимся внешним IP.

MikroTik (masquerade):

/ip firewall nat

add chain=srcnat out-interface=ether1 action=masquerade comment=”маскарадинг на интернет-интерфейс”

 

Linux (iptables, MASQUERADE):

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# или статический SNAT

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT –to-source 203.0.113.10

 

2) Destination NAT (DNAT) / Port Forward (PREROUTING → DNAT)

Перенаправление входящих соединений на внутренние хосты. Используется для проброса портов и публикации серверов.

MikroTik (HTTP → внутренний веб-сервер):

/ip firewall nat

add chain=dstnat dst-address=203.0.113.10 dst-port=80 protocol=tcp action=dst-nat to-addresses=192.168.1.10 to-ports=80 comment=”web”

 

Linux (iptables DNAT):

iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

 

3) 1:1 NAT (static mapping)

Один внешний IP ↔ один внутренний IP (полная подмена src и/или dst по необходимости).
Полезно, если у тебя выделен публичный IP и ты хочешь соответствие 1:1.

MikroTik (пример 1:1, исходящий):

/ip firewall nat

add chain=srcnat src-address=192.168.1.100 action=src-nat to-addresses=203.0.113.10 comment=”1:1 SNAT”

 

4) PAT (Port Address Translation)

Несколько внутренних адресов используют один внешний IP, но с разными портами (типичный MASQUERADE/PAT). Клиенты получают разный внешний порт для уникальной сессии.

Hairpin NAT (NAT Loopback) — доступ к локальному серверу по внешнему IP изнутри сети

Сценарий: у тебя есть DNAT public:80 → internal:80. Внутренний клиент 192.168.1.50 пытается открыть http://203.0.113.10 (публичный IP). Без специальных правил ответ может идти напрямую сервер→клиент и не пройти DNAT/conntrack. Решение — «hairpin» (SNAT internal→MASQUERADE when dst=internal).

MikroTik:

# 1) обычный dstnat правило (снаружи)

add chain=dstnat dst-address=203.0.113.10 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.1.10 

# 2) hairpin: когда источник из LAN обращается к public и попадает на внутренний сервер — меняем исходник на router LAN IP

add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.10 action=masquerade

 

Linux (пример):

# DNAT уже есть

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.10 -j MASQUERADE

 

Важно: при hairpin также могут понадобиться корректные firewall правила разрешения трафика внутри LAN.

Как NAT работает «под капотом» (conntrack)

NAT обычно строится поверх механизма connection tracking (conntrack):

  • При создании исходящего соединения для него формируется запись в таблице conntrack: (src=192.168.1.5:34567 -> dst=8.8.8.8:53), и сопоставление внешнего адреса/порта (203.0.113.10:54321).

  • Ответные пакеты сопоставляются по записи conntrack и перенаправляются/де-натируются обратно.

  • Conntrack имеет таймауты для разных протоколов (TCP ESTABLISHED, UDP state, etc.). Удаление записи завершает трансляцию.

Отсюда:

  • NAT «stateful»: только для соединений, которые прошли и создали запись, сервер отправит ответы обратно.

  • Если внешний NAT (CG-NAT) на стороне провайдера — ждать проблем с входящими соединениями.

NAT и протоколы с встраиваемыми IP (FTP, SIP, RTSP и др.)

Некоторые протоколы передают в теле управления IP/порт (например, FTP PASV, SIP SDP). Простая NAT-трансляция не модифицирует тело, поэтому соединение не установится. Решения:

  • Включить ALG/helper (connection helpers) — анализатор протокола, который смотрит контрольные пакеты и подправляет IP/порты. На Linux это модули nf_conntrack_ftp, nf_conntrack_sip; в RouterOS есть аналоги/настройки (в разных версиях — по-разному).

  • Использовать application proxy (например, FTP proxy).

  • Перевести сервисы на пассивные/безвстраиваемые режимы, или обходиться через VPN.

Важно: ALGs иногда мешают (некорректно работают), поэтому лучше использовать modern протоколы и/или VPN/SSL-терминацию для безопасных сервисов.

NAT и VPN

  • Если хосты за NAT хотят быть доступны извне, проще пробросить порты/использовать reverse proxy на границе.

  • Если у тебя филиалы связаны через VPN (WireGuard/OpenVPN/IPSec), то в большинстве случаев на VPN-сервере делают SNAT/masquerade для трафика, который должен выйти в интернет через VPN-сервер.

  • Если ты используешь WireGuard с туннельными IP: часто проще в AllowedIPs указывать туннельные адреса (см. ваш предыдущий диалог), и тогда сервер видит только туннельную сторону — нет зависимости от локального DHCP IP.

Проблемы провайдерского NAT: CG-NAT / NAT444

  • При CG-NAT у абонента нет публичного IPv4 (он получает частный адрес от провайдера). Тогда проброс портов невозможен, а некоторые VPN/peer-to-peer сервисы не работают.

  • Решения: запросить у провайдера публичный IP (обычно платно), или использовать IPv6, либо организовать исходящий VPN на VPS с публичным IP и пробрасывать сервисы через него.

Практические примеры (типичные кейсы)

1) Клиенты выходят в интернет через роутер (маскарадинг)

MikroTik

/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade

 

2) Публикация веб-сервера (HTTP) на внутреннем хосте

MikroTik

/ip firewall nat

add chain=dstnat dst-address=203.0.113.10 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.1.10

 

И обычно добавить в firewall filter правила, разрешающие этот входящий трафик.

3) Несколько внутренних серверов на одном публичном IP

  • Вариант A: разные порты внешне:

    • public:80 → internal1:80

    • public:8081 → internal2:80

  • Вариант B (когда нужен порт 80 для всех): reverse proxy (Nginx/HAProxy) на внутренней машине — RouterOS DNAT направляет 80/443 на proxy, proxy по Host/SNI распределяет запросы на внутренние серверы.

4) 1:1 NAT (полный статический NAT)

MikroTik

/ip firewall nat

add chain=dstnat dst-address=203.0.113.10 action=dst-nat to-addresses=192.168.1.100

add chain=srcnat src-address=192.168.1.100 action=src-nat to-addresses=203.0.113.10

 

Конфликты и «тонкие места»

a) Дублирующие правила — порядок важен

NAT правила идут по порядку; первое подходящее правило применяется. На RouterOS порядок имеет значение — проверяй /ip firewall nat print.

b) Firewall + NAT

DNAT обычно должен быть ДО фильтрации (PREROUTING/INPUT), но в RouterOS вы пишете NAT отдельно и затем должны быть соответствующие allow/accept правила в filter chain (input/forward) — иначе пакеты могут быть отброшены.

c) MTU / MSS issues

При двойной инкапсуляции/VPN или PPPoE может понадобиться уменьшить MSS (TCP MSS clamp) или MTU. Иначе TCP соединения могут «зависать».

d) Conntrack table overflow

Активные NAT-сессии хранятся в conntrack; на busy systems/under DDoS таблица может заполниться → новые соединения не обрабатываются. Нужны лимиты, rate-limit, защита от DDoS.

Отладка и полезные команды

MikroTik

  • Показать правила NAT:

/ip firewall nat print

 

  • Смотреть активные NAT/connection entries:

/ip firewall connection print

# фильтровать, например:

/ip firewall connection print where src-address~”192.168.1.”

 

  • Просмотр логов (если ведётся логирование NAT/firewall).

Linux

  • Показать NAT таблицу iptables:

iptables -t nat -L -n -v

# или nftables

nft list table nat

 

  • Просмотр conntrack:

sudo conntrack -L # вывести таблицу conntrack (needs conntrack-tools)

sudo ss -tn state established

 

  • Побыстрее проверить DNAT: tcpdump -i eth0 host 203.0.113.10 and tcp port 80

Лучшие практики / рекомендации

  1. Если есть возможность — используйте IPv6 вместо NAT. NAT ломает end-to-end модель и усложняет P2P.
  2. Для публичных веб-сайтов используйте reverse proxy: один public IP → прокси → несколько backend-серверов. Это проще и безопаснее, чем пытаться пробросить один и тот же порт на разные хосты.
  3. Masquerade для динамического WAN, SNAT для статического WAN. Masquerade автоматически подхватит внешний IP.
  4. Ограничивайте входящий трафик firewall-ом; не открывайте ненужные порты.
  5. Логи и мониторинг: следите за conntrack, количеством правил, utilization CPU (нат-операции могут быть затратны).
  6. Hairpin: если пользователи в LAN должны обращаться к public IP — настрой hairpin NAT.
  7. ALGs осторожно: FTP/SIP ALGs могут помочь, но иногда вызывают больше проблем — лучше VPN или современный протокол.
  8. Для VoIP / realtime — выделяйте порты/приоритеты (QoS) и учитывайте, как NAT влияет на SIP/SDP; лучше использовать SBC/Session Border Controller.

Примеры «реальной» конфигурации (MikroTik — сценарий)

Маскарадинг всех клиентов в интернет:

/ip firewall nat

add chain=srcnat out-interface=ether1 action=masquerade comment=”internet outgoing”

 

Публикация 3 внутренних серверов: web, ssh, custom:

/ip firewall nat

add chain=dstnat dst-address=203.0.113.10 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.1.10 to-ports=80 comment=web

add chain=dstnat dst-address=203.0.113.10 protocol=tcp dst-port=22 action=dst-nat to-addresses=192.168.1.11 to-ports=22 comment=ssh-server

add chain=dstnat dst-address=203.0.113.10 protocol=tcp dst-port=8443 action=dst-nat to-addresses=192.168.1.12 to-ports=443 comment=alt-https

 

Hairpin (если внутренние клиенты обращаются по public IP к web):

# DNAT выше + SNAT для internal -> internal hairpin

add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.10 action=masquerade comment=”hairpin for internal access to public”

 

  1. Когда NAT «ломает» приложения и как это решать

  • P2P, SIP, FTP — используйте proxy/ALG или VPN.

  • TLS/SNI — если пробрасываешь 443 на несколько серверов — используй reverse proxy (Nginx) либо разные публичные IP/портов.

  • Игры / консоли — часто используют UPnP/PCP для динамического проброса портов; можно включить, но помнить про безопасность.

  1. Итог (ключевые мысли)

  • NAT — незаменим для IPv4-мира: маскарадинг и DNAT решают практические задачи публикации сервисов и экономии IPv4.

  • Он stateful → опирается на conntrack; при диагностике смотрим таблицу conntrack.

  • Для сложных сценариев (несколько внутренних серверов на одном IP) лучше reverse proxy.

  • CG-NAT — реальная проблема; обход через публичный VPS/VPN или запрос у провайдера публичного IP.

  • IPv6 — аккуратная альтернатива, избавляющая от большинства проблем NAT.