🪄 Почему просто пробросить порт иногда не работает

Классическая задача: есть сервер за NAT, нужно открыть наружу его сервис. Делаем DNAT:

iptables -t nat -A PREROUTING \
  -p tcp --dport 8443 \
  -j DNAT --to-destination 10.20.0.15:443

И кажется, что все готово. Но клиент подключиться не может. Проблема в том, что NAT в linux тесно связан с conntrack - механизмом отслеживания состояний соединений.

Ядро запоминает:

клиент → внешний IP:8443
              ↓ DNAT
          10.20.0.15:443

И ожидает, что обратный трафик пройдет через тот же NAT-хост.

Если бэкенд отвечает клиенту через другой gateway, получаем асимметричную маршрутизацию:

Client → NAT → Backend
Client ←────── Backend

Клиент отправлял запрос одному адресу, а ответ пришел другим путем. TCP-сессия ломается.

Поэтому вместе с DNAT часто требуется SNAT/MASQUERADE:

iptables -t nat -A POSTROUTING \
  -d 10.20.0.15 \
  -p tcp --dport 443 \
  -j MASQUERADE

Теперь бэкенд отвечает NAT-серверу, а тот корректно выполняет обратную трансляцию.

▪️ Посмотреть состояния conntrack:

conntrack -L

▪️ Отфильтровать нужный порт:

conntrack -L -p tcp --dport 443

▪️ Статистика:

conntrack -S

▪️ Еще одна распространенная проблема - таблица conntrack переполнена. Проверяем:

sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

Если значения почти одинаковые, новые соединения могут начать отбрасываться. В логах при этом можно увидеть:

nf_conntrack: table full, dropping packet

Диагностику проброса порта удобно начинать с tcpdump:

tcpdump -i any -nn port 8443 or port 443

Если SYN приходит на внешний интерфейс, но не уходит к бэкенду - смотрим NAT/firewall. Если уходит, но ответа нет - проверяем бэкенд и его маршрутизацию. Если SYN-ACK возвращается, но клиент его не получает - смотрим обратный NAT и conntrack.

#network #conntrack

🧑‍💻 NetworkAdmin