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

Проблема решена!!!
Посмотрел трафик на порту коммутатора, куда включен шлюз провайдера.
Оказалось, что шлюз провайдера после переключения 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

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

Проблема решена!!!
Посмотрел трафик на порту коммутатора, куда включен шлюз провайдера.
Оказалось, что шлюз провайдера после переключения 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

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

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


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

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

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

Синхронизация файлов с локального ПК на VPS Debian?

Я бы предложил syncthing https://syncthing.net
Есть клиенты под все основные ОС

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

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 порта моего шлюза и снять на другую машину полный дамп сетевой активности. Но для этого нужно физически добраться до места. Пока такой возможности нет.

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

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 проблемы.

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

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

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

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

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

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 на интерфейс не знал. Спасибо!
Сейчас попробую на тестовой машине, а ночером проверю на шлюзе.

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

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

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

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

Благодарю за оперативный ответ.
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-адреса.
Т.е. проблема именно в маршрутизации внутри моего шлюза.