Спасибо. Щас соберусь и буду пробовать

а можно ли как то в Linux изменить поведение при трассировке ?

Чтобы сервер отвечал с интерфейса где получил пакет, а не с того, где клиент и который ближе к клиенту.

Не совсем понятно что имеется в виду, но трассировка не что инное как закидывание пекета ICMP на destinationIP с последовательным изменением TTL от 1 до maxhop.

Если это поможет...

ну у меня тут спрашивают

Предположим что с браса трассируешь хост в инете

Циски ответят с интерфейсов где ромбики, т.е. ты увидишь как шел пакет

Линукс ответит с интерфейсов которые ближе к клиенту (пятиугольники)

А циска отвечает с тех где приняла исходный пакет.

А линукс отправит с того интерфейса через которого ближе клиент

С чего это?

а какой профит?

я кстати долго с этим экспериментировал

пока не знаю, но вот так у коллеги.

Там чистые интерфейсы? ВЛАНов нет? На кошках нет неадресованных интерфейсов, где маршрутится через лупбеки?

и тут ещё было

отсюда говорят: https://habr.com/en/post/329244/

Поведение Linux и Mikrotik объясняется пунктом из RFC 1812. Этот пункт указывает, что source-адресом ICMP-сообщения должен являться адрес интерфейса, через который должен быть передан данный ICMP-пакет.

В это же время такие гиганты индустрии, как Cisco и Juniper, позволяют себе игнорировать указание RFC, очевидно полагаясь при этом на свой не дюжий опыт. И действительно, наблюдать в трассировке IP-адреса интерфейсов, через которые должен пройти оригинальный пакет, как по мне, видится более правильным решением, чем обнаруживать в той же трассировке IP из подсетей, строго говоря не имеющих к реальному пути пакета никакого прямого отношения.

Странна, у меня линух нормально трассируется и не подсовывает левые адреса, хотя у него их там полно, а вот кошка сует   ip совсем с другого влана

Парни, почитал я хабр, что выше. Первое - автор ошибся. Второе - как раз для циско и джуна вижу логику.

По порядку...
В первом примере трассировки, ICMP должен идти "вертикально". Как я писал выше, это пакеты с увеличивающимися TTL. Каждый узел, на котором истек TTL, сообщает источнику об этом. Обращаем внимание как настроен OSPF. Обратный маршрут к PC1 идет через свич. Так вот Линуксовые ответы идут не от исходящего к получателю (PC2) интерфейса, как сказано в RFC , а от интерфейса, который согласно маршрутизации, смотрит в сторону источника. Считаю это не совсем правильно, но согласно маршрутизации к источнику выбор маршрута правильный и только. А как иначе добраться к PC1 ? Смоделирована ведь специально ассиметрия.
Второе. Лично я считаю не логичным отрабатывать RFC (от интерфейса, который смотрит в сторону следующего хопа). И вот почему. Пакет пришел на входящий интерфейс. TTL иссяк. Зачем этот пакет пропускать еще через форвардинг если уже понятно, что он туда не пойдет? Вот от адреса интерфейса, через который пришел пакет и закончил TTL, и нужно отвечать, но, опять же через интерфейс согласно настроенной маршрутизации.

Как-то так. Может запутанно это все описал.

https://habr.com/ru/post/108690/
Пункт "Доступность сервера через несколько аплинков". Настройки iproute2.

Скорее всего это демон маршрутизации отрабатывает.

Народ, что дает разграниченин радиусов на акаунтинг и авторизацию?