Короткий ответ

Если у 10.0.10.10 интернет есть, у 10.0.10.50 нет, при живом шлюзе 10.0.10.1 — часто NAT не ловит этот source: узкий prefix в masquerade, exclude list, отдельный mark, или хост идёт мимо этого шлюза. С клиента докажите путь на 10.0.10.1, на шлюзе — правило srcnat и conntrack. Не включайте masquerade на весь 0.0.0.0/0 inbound.

Симптомы и как отличить

  • Одинаковый VLAN, разный успех TCP/443 наружу;
  • ping шлюза у всех есть;
  • на WAN tcpdump виден только один внутренний source.

Отличия: нет default — шлюз/DNS. Только одна сеть целиком — сайт из одной сети. Публичный IP изнутри — hairpin. Асимметрия WAN — асимметрия.

Возможные причины

  1. masquerade 10.0.10.0/25, хост .200 вне.
  2. ip saddr != 10.0.10.50 исключение (старый «сервер без NAT»).
  3. Policy routing: этот хост в таблицу без NAT.
  4. Второй шлюз без NAT (DHCP option 3 чужой).
  5. FastTrack/offload обходит правило (на RouterOS; на nft — flowtable).
  6. FORWARD drop для этого IP при живом NAT для других.
  7. IPv6 у проблемного хоста, IPv4 NAT не при чём, приложение берёт AAAA.

Диагностика

1. Клиент: шлюз тот?

Get-NetIPConfiguration
Find-NetRoute -RemoteIPAddress 1.1.1.1
ping -n 4 10.0.10.1
Test-NetConnection 1.1.1.1 -Port 443
tracert -d 1.1.1.1
ip route
ip route get 1.1.1.1
ping -c 4 10.0.10.1

Next-hop не 10.0.10.1 — сначала DHCP/VPN, не NAT.

2. Правила NAT на Ubuntu-шлюзе

sudo nft list ruleset
sudo nft list chain inet nat postrouting
sudo conntrack -L | grep 10.0.10.50

Ожидание при попытке выхода: запись 10.0.10.50:ephemeral -> WAN_IP. Нет записи при DROP в forward — сначала filter. Есть запись, снаружи RST — уже WAN/провайдер.

iptables-наследие:

sudo iptables -t nat -L -n -v
sudo iptables -L FORWARD -n -v

3. Сравнение двух хостов

Снимите ip route get и conntrack для .10 и .50. Разница в mark/iif — PBR. В masquerade prefix — маска правила.

4. tcpdump WAN

sudo tcpdump -n -i eth-wan host 1.1.1.1

Из рабочего хоста виден WAN_IP. Из проблемного — внутренний 10.0.10.50 на WAN (NAT не сработал) или тишина (forward drop).

Решение

Сценарий A. Узкий prefix

Расширьте до 10.0.10.0/24 (или ваш реальный). Не добавляйте /16, если там чужие сети.

Пример nft:

sudo nft add rule inet nat postrouting ip saddr 10.0.10.0/24 oifname "eth-wan" masquerade

Правило конкретное: oifname WAN, не все интерфейсы.

Сценарий B. Исключение

Найдите ip saddr 10.0.10.50 return / ! masquerade. Уберите, если серверу тоже нужен выход. Если сервер должен ходить с белым IP — отдельный SNAT, не «дырка в masquerade без маршрута».

Сценарий C. FORWARD

Разрешите ct state established,related и ip saddr 10.0.10.0/24 oif WAN ct state new. Не disable ufw/nft навсегда.

Сценарий D. Два шлюза

Верните option 3 на 10.0.10.1. Хосты с .3 без NAT останутся «без интернета».

Сценарий E. Flowtable/offload

Если пакеты минуют NAT из-за offload-бага — точечно исключить, обновить ядро. Не отключайте firewall.

6. Два хоста, один tcpdump WAN

Рабочий .10 и плохой .50 должны иметь одинаковый default 10.0.10.1 по Find-NetRoute. Если нет — сначала DHCP/VPN. Если да — на шлюзе conntrack во время Test-NetConnection 1.1.1.1 -Port 443 с .50. Нет SNAT — правило не матчит (prefix, exclude, iif, mark). Есть SNAT, на WAN виден белый — проблема уже не NAT (фильтр провайдера, DNS). RFC1918 на WAN с .50 — курите masquerade. Не лечите permit any. Backup nft list ruleset до правки. Flowtable/offload: если после добавления правила счётчик не растёт, пакеты могут обходить цепочку — смотрите offload, не «nft сломан». ICS на соседнем ПК как «NAT для избранных» вынесите из схемы. IPv6 у .50 при мёртвом IPv4 NAT: браузер может казаться «работающим» по AAAA, диагностика IPv4 будет врать. Проверка: оба хоста дают conntrack SNAT, с WAN нет 10.0.10.0/24, рабочий хост не отвалился. Чек-лист новой VLAN обязан содержать строку NAT, иначе статья повторится.

Для серверов, которым нужен собственный белый, делайте явный SNAT, не дырку в masquerade без маршрута возврата. Иначе получите асимметрию. Документируйте exclude list: кто без NAT и почему.

На клиенте .50 снимите ipconfig /all и tracert -d 1.1.1.1. Если первый hop не 10.0.10.1, NAT этого шлюза ни при чём. Если hop верный и дальше тишина — смотрите FORWARD drop vs отсутствие masquerade по tcpdump WAN. Счётчики nft -v до/после попытки: не растут — не то правило или offload. Не меняйте сразу и NAT, и ACL: не поймёте, что помогло. Для диагностики ICMP до 8.8.8.8 может быть разрешён отдельно от TCP; опирайтесь на Test-NetConnection. Сохраните conntrack -L рабочего и плохого в тикет.

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

С бывшего «плохого» хоста:

Test-NetConnection 1.1.1.1 -Port 443
nslookup example.com 10.0.10.2
tracert -d -h 5 1.1.1.1

На шлюзе conntrack с SNAT на WAN_IP. Рабочий хост не потерял выход. RFC1918 на WAN нет.

Если не помогло

  • Только UDP/VPN — отдельная цепочка.
  • CGNAT за вашим WAN — все хосты одинаково «странно», не «не все узлы».
  • Source-based routing в второй ISP без NAT.
  • Клиентский firewall исходящий (редко отличается по хостам без политики).

Профилактика

  • NAT-правило = список внутренних префиксов из IPAM.
  • При добавлении VLAN — строка NAT в чек-листе.
  • Мониторинг: счётчик masquerade, алерт RFC1918 на WAN.
  • Ревью exclude раз в квартал.

FAQ

Почему ping 8.8.8.8 у плохого хоста есть, HTTPS нет?

ICMP может идти другим правилом. Смотрите TCP conntrack. Или ping есть до шлюза, не до 8.8.8.8 — перечитайте вывод.

SNAT на фиксированный IP vs masquerade?

Masquerade удобен при смене WAN DHCP. SNAT — белый фиксированный. Для «не всех узлов» важнее match source, не тип.

Нужно ли NAT для доступа к 10.0.20.0/24?

Нет, это маршрутизация между RFC1918. NAT только на границе в интернет (и hairpin/особые случаи).

Windows ICS вместо шлюза компании?

Часть ПК может выходить через ICS. Выглядит как «NAT не для всех». Выключите ICS.

Можно ли any-any NAT «чтобы заработало»?

Нет. Утечка внутренних сетей и обход политик. Только нужные prefix и выходной интерфейс.