В чем может быть причина странного поведения NAT в Debian 11?

Question

[Максим]

Имею от провайдера белую подсеть /29
В текущей конфигурации:
.209 - шлюз провайдера
.210 - мой шлюз в локальную сеть организации
.211 - MAIL сервер
.212, .213 - не используются
.214 - WEB сервер

При обновлении почтовика (железо и софт) решил его убрать за мой шлюз в DMZ
Кладу внешний сетевой интерфейс почтовика.
На шлюзе для wan интерфейса настраиваю доп ip:

# Addition WAN IP
auto enp1s0:1
iface enp1s0:1 inet static
	address x.x.x.211/29
auto enp1s0:2
iface enp1s0:2 inet static
	address x.x.x.212/29

В iptables настраиваю NAT. Если прописываю так:

-A PREROUTING -d x.x.x.211/32 -j DNAT --to-destination 172.17.210.211
-A POSTROUTING -s 172.17.210.211/32 -j SNAT --to-source x.x.x.211

(172.17.210.211 - IP нового почтовика в DMZ)
PING'и на внешние интерфейсы шлюза и web-сервера идут, на ip провайдерского шлюза нет.
Снаружи новый почтовик не доступен.

Если меняю настройки вот так:

-A PREROUTING -d x.x.x.212/32 -j DNAT --to-destination 172.17.210.211
-A POSTROUTING -s 172.17.210.211/32 -j SNAT --to-source x.x.x.212

PING'и начинают ходить до любого узла в Интернет.
Снаружи новый почтовик становится доступным.

Предположил, что проблема в провайдерском шлюзе.
Поднял виртуалку с белым ip x.x.x.211 . Так PING'и бегают в обе стороны, значит где-то косяк в настройках моего шлюза.

Оставил бы второй вариант NAT, но изменить обратную зону DNS у провайдера - это целый квест.
Необходимо лично явиться к ним в офис с официальным письмом от юр. лица с кем заключен договор. Изменения вносятся в течении 2-х суток.

Comments

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента. Также обратите внимание на п.3.4

[Valentin Barbolin]

> -A POSTROUTING -s 172.17.210.211/32 -j SNAT --to-source x.x.x.211
Возможно есть какое-то вышестоящее правило NAT.

[Максим]

Valentin Barbolin,
В цепочке POSTROUTING - это первое правило.

[Valentin Barbolin]

Максим, Попробуй со шлюза пропингать с указанием источника
ping -c4 -I x.x.x.211 8.8.8.8

[Максим]

Valentin Barbolin,
По совету hint000 ушел от алиасов:

# ip a
.....
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
   .........
    inet x.x.x.210/29 brd x.x.x.215 scope global enp1s0
       valid_lft forever preferred_lft forever
   inet x.x.x.213/29 scope global secondary enp1s0
       valid_lft forever preferred_lft forever
   inet x.x.x.211/29 scope global secondary enp1s0
       valid_lft forever preferred_lft forever
    .........

Внешний интерфейс старого почтовика погасить не забыл.
Ping'и с .211 моего шлюза не идут ни во внешний мир, ни на шлюз провайдера.

root@:~
# ping -c4 -I x.x.x.211 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from x.x.x.211 : 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3063ms

root@:~
# ping -c4 -I x.x.x.211 x.x.x.209
PING x.x.x.209 (x.x.x.209) from x.x.x.211 : 56(84) bytes of data.

--- x.x.x.209 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3071ms

Внешний интерфейс web-сервера не сразу, но через секунд 30 стал отвечать
Видимо, как обновилась MAC-таблица.

root@:~
# ping -c4 -I x.x.x.211 x.x.x.214
PING x.x.x.214 (x.x.x.214) from x.x.x.211 : 56(84) bytes of data.
64 bytes from x.x.x.214: icmp_seq=1 ttl=64 time=0.389 ms
64 bytes from x.x.x.214: icmp_seq=2 ttl=64 time=0.227 ms
64 bytes from x.x.x.214: icmp_seq=3 ttl=64 time=0.213 ms
64 bytes from x.x.x.214: icmp_seq=4 ttl=64 time=0.235 ms

--- x.x.x.214 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3079ms
rtt min/avg/max/mdev = 0.213/0.266/0.389/0.071 ms

При этом с этого же интерфейса моего шлюза, но с другого IP ping проходит:

root@:~
# ping -c4 -I x.x.x.210 x.x.x.209
PING x.x.x.209 (x.x.x.209) from x.x.x.210 : 56(84) bytes of data.
64 bytes from x.x.x.209: icmp_seq=1 ttl=255 time=4.53 ms
64 bytes from x.x.x.209: icmp_seq=2 ttl=255 time=5.58 ms
64 bytes from x.x.x.209: icmp_seq=3 ttl=255 time=3.61 ms
64 bytes from x.x.x.209: icmp_seq=4 ttl=255 time=3.65 ms

--- x.x.x.209 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 3.606/4.343/5.584/0.805 ms
root@:~

# ping -c4 -I x.x.x.210 8.8.8.8
PING 8.8.8.8 (8.8.8.8 from x.x.x.210 : 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=15.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=16.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=15.9 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 15.810/16.833/19.414/1.498 ms

Интересно, что с тестовой машины с этим IP ping проходит:


Подумал, что провайдерский роутер блокирует пакеты у которых разные IP, но один MAC?
Но с IP .212 и .213 ping'и идут. Только с .211 проблемы.

Думаю перегрузить по питанию провайдерский роутер.
Но пользователей просить об этом стремно, нужно самому на месте в это время быть.

Может есть еще какие идеи?

[Valentin Barbolin]

Максим, Покрайней мере ты выяснил, что NAT тут не причем.

роутер блокирует пакеты у которых разные IP, но один MAC?

Проблема где-то тут. Я бы позвонил провайдеру и уточнил этот момент.

[Максим]

Valentin Barbolin,
Сейчас на моем шлюзе поднято на WAN интерфейсе 3 IP:
.210 - основной
.212, .213 - прописаны для дальнейшего использования
Со всех трех и на все три ping'и идут во/с внешний мир.
Т.е. роутер провайдера разные IP с одинаковым MAC не блокирует.

Поднятая тестовая машина с IP .211 также получила выход во внешний мир.
Её MAC отличается и от MAC моего шлюза и почтовика.
Получается, что на шлюзе провайдера также нет привязки IP .211 к MAC почтовика.

Проблема возникает только когда .211, я прописываю на своем шлюзе.
При этом внутри подсети ping'и идут ( Ping'и между моим шлюзом и web-сервером, так же имеющим белый IP .214), а вот шлюз провайдера на ping'и от этого адреса с моего шлюза не отвечает, и пакеты во внешний мир не маршрутизирует.

Поэтому ответ на вопрос: виновником проблемы является шлюз провайдера или мой шлюз, для меня пока совсем не очевиден.

Думаю, что виновника удалось бы установить, если сделать зеркалирование на коммутаторе wan порта моего шлюза и снять на другую машину полный дамп сетевой активности. Но для этого нужно физически добраться до места. Пока такой возможности нет.

[Valentin Barbolin]

Максим, Шлюз является GW для почтовика в локальной сети?

[Максим]

Не очень понял вопрос, поэтому отвечу графически. Надеюсь будет наглядно.
Cтарый почтовик имеет белый IP.
Маршрутизация такая:


Пытаюсь сделать так:

У нового почтовика серый IP, транслируемый в белый IP старого почтовика.

Ответил на Ваш вопрос?

[Максим]

Проблема решена!!!
Посмотрел трафик на порту коммутатора, куда включен шлюз провайдера.
Оказалось, что шлюз провайдера после переключения IP на новый почтовик продолжает отвечать на ping'и, используя MAC старого почтовика в адресе получателя.
Т.е. он игнорирует изменение MAC у отправителя.

При обращении к провайдеру, тот ответил, что со шлюзом всё нормально и MAC-таблица на шлюзе обновляется... но, оказывается, не в этом случае.
Принудительный сброс MAC-таблицы провайдером на своём шлюзе решил проблему.
Но сработало это только, когда я сначала выключил старый почтовик и включил новый почтовик.
Сброс таблицы перед сменой почтовиков результата не давал.

Мой итог.
1) Шлюз провайдера обновляет свою MAC-таблицу, если MAC для него новый.
(мой эксперимент с тестовой виртуалкой, выставленной в WAN-сеть с IP .211 )
2) Шлюз обновляет свою MAC-таблицу, если MAC в таблице есть, но появлется новый IP
(добавление на мой шлюз новых IP .212 и .213)
3) Шлюз не обновляет свою MAC-таблицу, если IP уже есть в его таблице и MAC уже присутсвует с другим IP.
(у шлюза в таблице присутствует запись по строму почтовику и запись MAC'а моего шлюза с IP .210 )

Если что, шлюз провайдера: ZTE F660

[Максим]

Проблема решена!!!
Посмотрел трафик на порту коммутатора, куда включен шлюз провайдера.
Оказалось, что шлюз провайдера после переключения IP на новый почтовик продолжает отвечать на ping'и, используя MAC старого почтовика в адресе получателя.
Т.е. он игнорирует изменение MAC у отправителя.

При обращении к провайдеру, тот ответил, что со шлюзом всё нормально и MAC-таблица на шлюзе обновляется... но, оказывается, не в этом случае.
Принудительный сброс MAC-таблицы провайдером на своём шлюзе решил проблему.
Но сработало это только, когда я сначала выключил старый почтовик и включил новый почтовик.
Сброс таблицы перед сменой почтовиков результата не давал.

Мой итог.
1) Шлюз провайдера обновляет свою MAC-таблицу, если MAC для него новый.
(мой эксперимент с тестовой виртуалкой, выставленной в WAN-сеть с IP .211 )
2) Шлюз обновляет свою MAC-таблицу, если MAC в таблице есть, но появлется новый IP
(добавление на мой шлюз новых IP .212 и .213)
3) Шлюз не обновляет свою MAC-таблицу, если MAC уже присутсвует с другим IP.
(у шлюза в таблице присутствует запись MAC'а моего шлюза с IP .210)

Если что, шлюз провайдера: ZTE F660

Answer 1

[AUser0]

Может дело в MAC-адресе .211-го интерфейса? Или в роутере, в который включаются все сервера?

P.S. Смотрите tcpdump-ом трафик .211, может он вообще на этот gateway не приходит.

Comments

[Максим]

Благодарю за оперативный ответ.
1) Не очень понял МАС адрес какого именно интерфейса (какой железки?) имеется в виду.
Нарисовал блок схему сетевой коммутации ( на том что под рукой, так что не пинайте )


2) Tcpdump'ом посмотрел на портах своего gw.
На wan-интерфейсе:
# tcpdump -n -i enp1s0:1 icmp
На dmz-интерфейсе:
# tcpdump -n -i enp2s0 icmp
Но уже после отправки сюда вопроса. Ступил, не записал дамп в файл, поэтому результаты показать не могу. Повторно смогу запустить только после 22 вечера.
Могу только сказать, что при исходной настройке NAT не видно ответных пакетов на ping'и.

3) Блокировки по MAC адресу на провайдерском шлюзе нет.
На том же сервере виртуализации, где поднят новый почтовик, запустил ещё одну виртуалку, присвоил ей IP .211 и прокинул её по VLAN в wan-сеть. Связь с внешним миром получил.
Попробовал этой же тестовой виртуалке присвоить IP из DMZ и выставить ее через мой шлюз. Результат такой же как с новым почтовиком.
У всех машин (старый почтовик, новый почтовик, wan-интерфейс моего шлюза, тестовая машина) разные MAC-адреса.
Т.е. проблема именно в маршрутизации внутри моего шлюза.

[AUser0]

Максим, ну, поскольку это gateway, глупо спрашивать про ip_forwarding, он однозначно включён. Тогда остаётся только поэтапно, по цепочке отслеживать интерфейсы, через которые ping уходит, и приходит ответ. Явно где-то какая-то блокировка, или правило, и т.д....

Answer 2

[hint000]

Может быть и не связано с проблемой, но всё же процитирую свой ответ 2-летней давности https://qna.habr.com/q/1000141 (периодически напоминаю об этом, но, как обычно, всем пофиг).

Алиасы интерфейсов устарели.
https://www.kernel.org/doc/html/latest/networking/...

IP-aliases are an obsolete way to manage multiple IP-addresses/masks per interface. Newer tools such as iproute2 support multiple address/prefixes per interface, but aliases are still supported for backwards compatibility.

2014 год: Алиасы интерфейсов устарели. https://unix.stackexchange.com/questions/119592/su...

ens160:0 is also obsolete syntax. There is no more aliases usage. IP addresses are applied to the same interface (please see ip a s command output).

2007 год: Алиасы интерфейсов устарели.
https://linux.debian.user.narkive.com/jH7FZrwF/ip-...

The docs I'm reading recommend using "secondary ips" instead of aliases. It
says that IP Aliases are deprecated in favor of "secondary ips"

2007 год! 14 лет 16 лет назад нам говорили прекращать использовать IP-алиасы. 14 лет 16 лет назад, Карл!

Debian консервативный дистрибутив, но не настолько же. Вполне приемлемо, когда ради стабильности на пару лет притормаживают включение в репозитории свежих версий тех или иных пакетов. Но продолжать использовать конфигурацию, которую Debian 16 лет назад рекомендовал больше не использовать - это немного чересчур.

А так поддерживаю ответ AUser0 как насчёт диагностики tcpdump-ом, так и версию насчёт MAC, который может иметь привязку на оборудовании провайдера (позвонить в техподдержку, спросить о наличии привязки, при её наличии попросить сбросить для x.x.x.211). Факт, что для x.x.x.212 всё работает правильно как бы очень сильно намекает в пользу привязки, которая у провайдера сработала автоматически при первом использовании x.x.x.212.

Кроме того, есть вариант настроить без использования NAT. Например, использовать обычный свитч, в который воткнуты .209 (провод от провайдера), .210, .211 (и .212, .213, .214 при необходимости).
Минус в децентрализации контроля трафика - при необходимости контролировать почту через iptables нужно использовать iptables на самом почтовом сервере. Разумеется, это вопрос администрирования (даже не вкусовщина и не предмет для споров). Что для одного админа здорово, то для другого админа - смерть. Просто технически такой вариант возможен.

Comments

[Максим]

Спасибо за оперативный ответ.
Частично на Ваши замечания написал в ответе выше.
Использование алиасов, скорее дело привычки и не знания других вариантов решения задачи.
Если не затруднит, киньте ссылки, где можно почитать, как моя задача может быть решена через iproute2. Сам конечно тоже поспрашаю у "Яши с Гошей"

Ваше последнее предложение, как раз и реализовано на текущий момент.
В предыдущем ответе вставил рисунок текущей сетевой коммутации.
Хотел бы от него уйти в силу нескольких причин. Одну из них Вы назвали.
Ещё одна, желание отвязать белый ip сервиса (почты) от конкретной железки.
Упрощается обновление сервера и/или переезд на другого провайдера.
Но тут, как Вы правильно заметили дело вкуса конкретного человека.

[hint000]

Максим, посмотрел на свежую голову ещё раз на правила

-A PREROUTING -d x.x.x.211/32 -j DNAT --to-destination 172.17.210.211
-A POSTROUTING -s 172.17.210.211/32 -j SNAT --to-source x.x.x.211

и появился вопрос... а как насчёт forward?

-A FORARD -s 172.17.210.211 -j ACCEPT
-A FORARD -d 172.17.210.211 -j ACCEPT

что-то подобное есть в направлении "наружу" и "внутрь"? ну или forward разрешен всем (что наврядли)?

как моя задача может быть решена через iproute2

вместо создания IP-алиаса enp1s0:1 просто добавляется второй (третий, четвёртый,..) IP-адрес тому же сетевому интерфейсу. Команда ip address add x.x.x.211/29 dev enp1s0 или можно сокращенно ip a a x.x.x.211/29 dev enp1s0
А в конфигурационных файлах можно сразу назначать несколько адресов. Просто сейчас развелась куча способов, через что конфигурировать. Одни через NetworkManager, другие через systemd-networkd. Я на Убунте, так что пришлось привыкнуть к поделке под названием netplan (парсер сетевого конфиг-файла). Если используете /etc/network/interfaces, то можно так:

auto enp1s0
iface enp1s0 inet static
  address x.x.x.210/29
  gateway x.x.x.209

iface enp1s0 inet static
  address x.x.x.211/29

iface enp1s0 inet static
  address x.x.x.212/29

[Максим]

hint000,
forward конечно настроен:
Первые 2 цепочки относятся ко всей маршрутизации и нареканий на их работу
нет. Чтобы не загромождать вывод сами цепочку приводить не буду. Но если актуально, приведу и их.

-A FORWARD -p tcp -j bad_TCP  # цепочка с проверкой корректности соединений
-A FORWARD -p icmp -j good_ICMP # цепочка ограничения icmp 
.....
-A FORWARD -s 172.17.210.208/28 -j from_dmz
.......
-A FORWARD -d 172.17.210.211/32 -j to_mail
-A FORWARD -d 172.17.210.208/28 -j to_dmz
.......
-A from_dmz -j ACCEPT  # пока открыт полный свободный выход для машин из DMZ
.......
-A to_mail -p tcp -m multiport --dports 25,443,587,636,993,1163 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
#-A to_mail -j LOG --log-prefix " ### TO MAIL ### "
-A to_mail -j DROP
............
-A to_dmz -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
..........

Про возможность так добавлять дополнительные IP на интерфейс не знал. Спасибо!
Сейчас попробую на тестовой машине, а ночером проверю на шлюзе.