Что такое NAT и почему сервер за ним не пингуется и не открывается снаружи

Дома всё работает: NAS открывается, камера показывает, ping идёт. Из интернета — таймаут, «внешний IP не пингуется». Чаще всего виноват не сервер, а NAT: свой, провайдерский или оба сразу. Разбираем, что NAT делает с пакетами, как отличить серый адрес от белого, как пробросить порт в iptables, nftables и MikroTik, как обойти CGNAT туннелем на VPS и как проверить, виден ли сервис из интернета, а не только из локалки.

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

Как работает NAT и почему он пропускает трафик только в одну сторону

NAT-роутер ведёт таблицу трансляций и создаёт запись в ней только по исходящему пакету. Когда ноутбук 192.168.1.10 с порта 51234 обращается к сайту 203.0.113.5:443, роутер переписывает источник на свой внешний адрес и свободный порт — 198.51.100.7:40001 — и запоминает соответствие; ответ сайта приходит на 40001 и по записи возвращается на 192.168.1.10:51234. Пакет, пришедший снаружи на 198.51.100.7:80 без такой записи и без правила проброса, роутеру некому отдать — он отбрасывается.

Причина существования NAT — дефицит адресов IPv4: их около 4,3 млрд. RFC 1918 (февраль 1996) зарезервировал частные диапазоны для любых сетей без согласования, а RFC 3022 (январь 2001) описал два механизма: Basic NAT (один частный адрес ↔ один публичный) и NAPT (много частных через один публичный за счёт подмены портов). Сегодня под NAT почти всегда имеют в виду NAPT. В Linux таблица трансляций живёт в conntrack:

# Записи трансляций на Linux-шлюзе (пакет conntrack-tools)
$ sudo conntrack -L -p tcp --dport 443 | head -1
# пример вывода, одна запись перенесена: слева пакет изнутри,
# справа — как его видит интернет
tcp 6 431999 ESTABLISHED src=192.168.1.10 dst=203.0.113.5
    sport=51234 dport=443
    src=203.0.113.5 dst=198.51.100.7 sport=443 dport=40001
    [ASSURED] mark=0 use=1

Число 431999 в записи — оставшийся таймаут в секундах: установленное TCP-соединение Linux помнит 5 суток. Про таймауты и почему из-за них рвутся долгие соединения — ниже.

Какие адреса частные и почему до них нельзя достучаться из интернета

Частные диапазоны не маршрутизируются в интернете: пакет на 192.168.1.20 из другой сети отбросит первый же провайдерский маршрутизатор. Таких диапазонов несколько, и по адресу WAN-интерфейса роутера видно, какой NAT стоит между вами и интернетом.

Какие бывают типы NAT

Все виды NAT сводятся к двум операциям: подмене источника у исходящих пакетов (SNAT) и подмене назначения у входящих (DNAT). Остальное — частные случаи и уровни, на которых они выполняются.

Серый или белый IP: как понять, что вы за CGNAT

Белый IP — публичный адрес назначен непосредственно WAN-интерфейсу вашего роутера; серый — на WAN стоит адрес из 100.64.0.0/10, 10.0.0.0/8 или 172.16.0.0/12, а публичный принадлежит NAT провайдера и делится между абонентами. Проверка занимает минуту: сравнить адрес WAN с тем, что видит интернет.

# На роутере или сервере, подключённом к провайдеру напрямую
$ ip -4 addr show dev eth0 | grep inet
# пример вывода: адрес WAN из 100.64.0.0/10 — вы за CGNAT
    inet 100.71.23.148/22 brd 100.71.23.255 scope global dynamic eth0

# Каким вас видит интернет (то же покажет 2ip.ru или «мой IP» в поиске)
$ curl -4 ifconfig.me
5.18.204.77

# Адреса не совпали — между вами и интернетом ещё один NAT.
# Совпали — IP белый, дальше вопрос к правилам вашего роутера.

На домашнем роутере адрес WAN виден на странице состояния, на MikroTik — /ip address print; косвенный признак — второй хоп в traceroute из 100.64.0.0/10. Мобильные операторы держат абонентов за CGNAT почти всегда, у проводных белый адрес обычно подключается как отдельная услуга. Белый, но динамический адрес меняется при переподключении — для него нужен DDNS.

Почему сервер за NAT не пингуется и не открывается снаружи

Ping из интернета доходит в лучшем случае до WAN-интерфейса роутера, а не до сервера за ним: у ICMP нет портов, «пробросить ping» на конкретное устройство нельзя. Поэтому «внешний IP не пингуется» говорит о роутере и провайдере, а не о сервере, а «открывается дома, но не снаружи» — одна из шести причин ниже.

Порядок диагностики: отключите Wi-Fi на телефоне и проверьте по LTE — телефон в домашнем Wi-Fi ничего не доказывает. Затем проверьте снаружи порт, а не ping: как это сделать без своего сервера — в статье «Как проверить, открыт ли порт». Почему хост может быть жив и при этом молчать на ICMP, разобрано в материале про ping.

Как пробросить порт: iptables, nftables и MikroTik

Проброс — правило DNAT в цепочке PREROUTING плюс разрешение в FORWARD: первое переписывает адрес назначения, второе пропускает переписанный пакет через шлюз. Без второго DNAT сработает, а пакет умрёт на политике DROP.

# Linux-шлюз: внешний 8443 на eth0 → 192.168.1.20:443 в LAN (br0)
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8443 \
  -j DNAT --to-destination 192.168.1.20:443
sudo iptables -A FORWARD -i eth0 -o br0 -p tcp -d 192.168.1.20 \
  --dport 443 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
# Исходящий masquerade, если его ещё нет
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Проверка: правило на месте и по нему идут пакеты (pkts > 0)
$ sudo iptables -t nat -L PREROUTING -n -v
# пример вывода
Chain PREROUTING (policy ACCEPT 812 packets, 61K bytes)
 pkts bytes target  prot opt in   out  source     destination
   37  2220 DNAT    tcp  --  eth0 *    0.0.0.0/0  0.0.0.0/0
             tcp dpt:8443 to:192.168.1.20:443

# То же в nftables
sudo nft add table ip nat
sudo nft add chain ip nat prerouting \
  '{ type nat hook prerouting priority -100; }'
sudo nft add chain ip nat postrouting \
  '{ type nat hook postrouting priority 100; }'
sudo nft add rule ip nat prerouting iif eth0 tcp dport 8443 \
  dnat to 192.168.1.20:443
sudo nft add rule ip nat postrouting oif eth0 masquerade
sudo nft list ruleset

Если pkts в строке DNAT остаётся нулём после проверки снаружи — пакеты до роутера не доходят: CGNAT или фильтрация провайдера. Растёт, а сервис не открывается — ищите на сервере: файрвол или привязку к 127.0.0.1. На MikroTik то же делается одной строкой; вторая нужна для hairpin — доступа по внешнему адресу из своей же локалки:

# RouterOS: проброс 8443 с ether1 (WAN) на 192.168.88.20:443
/ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp \
  dst-port=8443 action=dst-nat to-addresses=192.168.88.20 to-ports=443

# Hairpin NAT: обращение из своей LAN по внешнему адресу
/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 \
  dst-address=192.168.88.20 protocol=tcp dst-port=443 \
  out-interface=bridge action=masquerade

/ip firewall nat print

Как обойти CGNAT: WireGuard-туннель на VPS

За CGNAT проброс на роутере бесполезен — входящий пакет не доходит даже до него. Рабочая схема: домашний сервер сам поднимает исходящее соединение к VPS с белым адресом, а VPS пробрасывает свой порт внутрь туннеля. Исходящие соединения NAT пропускает всегда, поэтому это работает через любой CGNAT и мобильный интернет.

Клиент из интернета ──▶ VPS 203.0.113.10:8443 (белый IP)
                              │ DNAT 8443 → 10.8.0.2:443 в wg0
                              ▼ WireGuard, UDP 51820 — туннель поднят
                              │ ИЗНУТРИ, поэтому CGNAT его пропускает
               CGNAT (100.64.x.x) ──▶ роутер ──▶ сервер wg0 = 10.8.0.2

# VPS: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <приватный ключ VPS>
PostUp = sysctl -w net.ipv4.ip_forward=1
# плюс правила из раздела выше: DNAT dport 8443 → 10.8.0.2:443
# и MASQUERADE на выход в wg0

[Peer]
PublicKey = <публичный ключ домашнего сервера>
AllowedIPs = 10.8.0.2/32

# Домашний сервер за CGNAT: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.2/24
PrivateKey = <приватный ключ сервера>

[Peer]
PublicKey = <публичный ключ VPS>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24
# Держит запись в таблицах NAT живой; 25 с — рекомендация wireguard.com
PersistentKeepalive = 25

MASQUERADE на wg0 обязателен: без него домашний сервер увидит запрос от публичного адреса клиента и ответит через свой шлюз по умолчанию, а не в туннель — соединение зависнет. Если наружу нужен только HTTP(S), поверх того же туннеля ставят обратный прокси: nginx или Caddy на VPS с proxy_pass на 10.8.0.2, TLS-сертификат тогда живёт на VPS.

Какое решение выбрать для доступа снаружи

Выбор зависит от одного вопроса: белый у вас адрес или серый. С белым хватит проброса и DDNS, с серым нужен либо белый адрес от провайдера, либо точка с публичным адресом где-то ещё — обычно VPS.

Почему за NAT рвутся долгие соединения и какие таймауты у трансляций

Запись в таблице NAT живёт, пока по ней ходят пакеты; молчащее соединение NAT забывает, и следующий пакет от сервера некому доставить — SSH-сессия или WebSocket «зависает» без ошибки. Лечение одно: слать что-нибудь чаще, чем истекает таймаут, — keepalive.

Отсюда и STUN с TURN в видеозвонках: STUN-сервер (RFC 8489) сообщает клиенту его внешний адрес и порт, чтобы два абонента за NAT соединились напрямую; если один за symmetric NAT — трафик идёт через ретранслятор TURN (RFC 8656). Смежная тема — MTU: туннель WireGuard забирает у пакета 60 байт заголовков IPv4, и без снижения MTU большие ответы через него теряются — подробнее в статье про MTU, MSS и фрагментацию.

Как убедиться, что сервис виден из интернета, а не только из локалки

Единственный честный способ — проверка с чужого адреса: изнутри сети NAT, hairpin и локальный DNS маскируют любую из шести причин выше. Разовая проверка с телефона отвечает на вопрос «сейчас», но не ловит смену динамического IP ночью, слетевший проброс после обновления прошивки или перевод абонента за CGNAT без предупреждения.

Пруфен выполняет проверку ping и проверку TCP-порта с интервалом от 2 минут из 20 точек мониторинга — 17 в России, а также Минск, Астана и Испания. Для сервера за NAT их стоит держать парой: сочетание результатов подсказывает, где искать.

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

Как узнать, серый у меня IP или белый?

Сравните адрес WAN на странице состояния роутера с тем, что показывает 2ip.ru или curl ifconfig.me. Совпали — адрес белый. Не совпали, и на WAN что-то из 100.64.0.0/10, 10.0.0.0/8 или 172.16.0.0/12 — вы за CGNAT. Если на WAN 192.168.x.x — перед вашим роутером стоит ещё один, обычно модем провайдера; смотрите адрес WAN уже на нём.

Почему сайт открывается дома, а с телефона по LTE нет?

Дома вы попадаете на сервер по локальному адресу или через hairpin NAT роутера, минуя всё, что стоит между роутером и интернетом. По LTE запрос идёт снаружи и упирается в CGNAT провайдера, отсутствие проброса или файрвол сервера. Проверьте по порядку: адрес WAN роутера, счётчик pkts в правиле DNAT, ss -ltn на сервере. И убедитесь, что на телефоне выключен Wi-Fi.

Нужен ли NAT в IPv6?

Нет: адресов IPv6 хватает, чтобы каждое устройство получило глобальный, и классический NAT там не применяется. Но «нет NAT» не значит «всё открыто»: роутер по умолчанию блокирует входящие соединения файрволом, и для доступа снаружи нужно явно разрешить порт к адресу конкретного устройства. Для локальной адресации есть ULA fc00::/7 (RFC 4193), на стыке с IPv4 — NAT64 (RFC 6146), но это трансляция протоколов, а не экономия адресов.

Что такое двойной NAT?

Две последовательные трансляции: модем провайдера раздаёт 192.168.0.x, а за ним ваш роутер — 192.168.1.x. Ваш роутер плюс CGNAT провайдера — тоже двойной NAT, только второй уровень вам не подконтролен. Проброс нужен на каждом уровне, который вы контролируете, а лучше убрать лишний: перевести модем в режим моста или свой роутер — в режим точки доступа.