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 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, налаштованим власником.