NAT: что такое трансляция сетевых адресов и как она работает

NAT (Network Address Translation) — механизм, при котором маршрутизатор или сервер подменяет IP-адрес в пакетах при их передаче между сетями. Позволяет множеству устройств с приватными IP выходить в интернет через один публичный IP.

Типы NAT

Тип	Направление	Применение
SNAT (Source NAT)	Изнутри наружу	Выход в интернет из LAN
DNAT (Destination NAT)	Снаружи внутрь	Port forwarding, проброс портов
Masquerade	Изнутри наружу	SNAT с динамическим IP
Full-cone NAT	Обе стороны	P2P, VoIP, игры

Как работает NAT (пример)

Устройство (192.168.1.5:12345) → Роутер → Интернет (1.2.3.4:12345)
   Роутер видит: src=192.168.1.5:12345, dst=8.8.8.8:53
   Меняет на:    src=1.2.3.4:12345,    dst=8.8.8.8:53
   Запоминает в таблице: 1.2.3.4:12345 ↔ 192.168.1.5:12345
   Ответ: src=8.8.8.8:53, dst=1.2.3.4:12345
   Роутер переводит обратно: 1.2.3.4:12345 → 192.168.1.5:12345

Настройка NAT в iptables (Linux-роутер)

# Включить IP forwarding
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# Постоянно: /etc/sysctl.conf → net.ipv4.ip_forward=1

# MASQUERADE — NAT для выхода в интернет (eth0 = WAN)
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# DNAT — проброс порта (80 → внутренний сервер)
sudo iptables -t nat -A PREROUTING -p tcp --dport 80     -j DNAT --to-destination 192.168.1.10:80

# Сохранить правила
sudo netfilter-persistent save

Когда NAT на VPS мешает

Некоторые хостинги размещают VPS за shared NAT-адресом:

Почтовый сервер — PTR-запись не совпадает с IP, письма отклоняются
VPN-сервер — протоколы IPSec/WireGuard требуют публичный IP без NAT
Game server — игроки не могут подключиться напрямую
DDoS-защита — сложнее настроить правила под shared IP

💡 ZevsHost VDS: Все VDS-серверы ZevsHost получают выделенный публичный IPv4-адрес без NAT. Это обязательно для почтовых серверов, VPN и игровых серверов.

Разбор типичных ошибок NAT

DNAT настроен, но извне порт всё равно недоступен — почти всегда причина в том, что правило MASQUERADE/SNAT для обратного трафика отсутствует, либо firewall (UFW/firewalld) блокирует пакет уже после трансляции адреса.

sudo iptables -t nat -L PREROUTING -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:192.168.1.10:80

# Но во FORWARD трафик блокируется:
sudo iptables -L FORWARD -n
Chain FORWARD (policy DROP)

DNAT в таблице nat меняет адрес назначения, но пакет всё равно проходит через цепочку FORWARD в таблице filter. Если её политика по умолчанию DROP, нужно явно разрешить проброшенный трафик: iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -j ACCEPT.

Сервер за NAT получает соединения с одним и тем же исходным IP для всех клиентов — типичный симптом carrier-grade NAT (CGNAT) у мобильных операторов или дешёвых хостингов: за одним публичным адресом скрыты сотни клиентов.

# В логах веб-сервера один IP делает тысячи запросов
203.0.113.7 - - "GET / HTTP/1.1" 200
203.0.113.7 - - "GET / HTTP/1.1" 200
203.0.113.7 - - "GET / HTTP/1.1" 200

Блокировка такого IP по rate-limit ударит по всем пользователям за CGNAT одновременно — здесь нужны более точные признаки (User-Agent, куки, поведенческие метрики), а не просто IP.

Типы NAT: расширенное сравнение

Тип	Симметричность порта	Проблемы с P2P/VoIP	Типичное место применения
Full-cone NAT	Один и тот же порт для всех адресатов	Минимальные	Домашние роутеры, VPN-серверы
Restricted cone NAT	Один порт, но фильтр по IP отправителя	Умеренные, нужен STUN	Корпоративные firewall
Port-restricted cone NAT	Один порт, фильтр по IP и порту	Заметные, часто нужен TURN	Более строгие firewall
Symmetric NAT	Новый порт для каждого адресата	Сильные, P2P почти невозможен без TURN	CGNAT операторов, публичные Wi-Fi

Когда NAT в принципе не подходит

Нужен входящий VoIP/SIP-трафик без посредников — протокол SIP хранит IP-адрес прямо в теле пакета, и NAT его не подменяет, что ломает обратную связь; нужен либо ALG на роутере, либо публичный IP.
Развёрнут сервер IPSec для site-to-site VPN — большинство реализаций IPSec плохо проходят через NAT без NAT-T (NAT Traversal), и часть функций (AH-режим) вообще с NAT несовместимы.
Компания обязана предоставлять клиентам стабильный исходящий IP для whitelisting на стороне партнёра — за NAT исходящий IP общий с другими клиентами хостинга, и партнёр не сможет разграничить трафик.

Проверка результата

Проверьте, что IP forwarding включён: cat /proc/sys/net/ipv4/ip_forward должен вернуть 1.
Проверьте таблицу трансляций в реальном времени: sudo conntrack -L | grep 192.168.1.10 должен показывать активные сессии через NAT.
С внешнего хоста проверьте проброшенный порт: curl -v http://ВАШ_ПУБЛИЧНЫЙ_IP:80 должен подключиться к внутреннему серверу.
Убедитесь, что правила переживут перезагрузку: sudo netfilter-persistent save && sudo reboot, затем повторите проверку.

NAT тесно связан с адресацией IPv4 и масками подсети — см. статью про IPv4 и расчёт CIDR, а для настройки самой маршрутизации — статью про ip route.

Частые вопросы

Стоит ли просто заблокировать адрес, если выяснилось, что он принадлежит carrier-grade NAT оператора?

Блокировать такой адрес целиком не стоит: за одним адресом carrier-grade NAT скрываются сотни разных клиентов оператора, и блокировка ударит по всем сразу, включая обычных пользователей. Для различения абьюзера от соседей по NAT нужны более точные признаки запроса — заголовки браузера, куки, поведенческие метрики, — а не просто исходный IP-адрес соединения.

Мешает ли NAT обычным исходящим соединениям вроде веб-сёрфинга, или только входящим извне?

Нет, обычные исходящие соединения, которые инициирует устройство изнутри сети, NAT пропускает прозрачно через SNAT или Masquerade без дополнительной настройки. Сложности возникают, когда снаружи кто-то должен дозвониться до вас первым — входящий VoIP-вызов, пир по VPN или игрок, подключающийся напрямую, — и именно для таких сценариев нужен публичный адрес без NAT.

Почему VoIP-звонок по SIP устанавливается, а звука всё равно нет, хотя сигнал соединения через NAT проходит?

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

Если у VPS уже есть выделенный публичный IP вместо shared NAT, значит ли это, что настраивать NAT на самом сервере вообще не придётся?

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