Пинг через определенный шлюз

ping IP -I eth0

А как оно работает, если клиентов несколько? 3 ВПН клиента допустим. Кому уйдет и как указать через кого мне надо. Про флаг I я в курсе, но не понял как указать конкретный шлюз.

у тебя все вышестоящие шлюзы в одной подсети? Или всё таки интерфейсами(виртуальными или реальными) разграничено?
Я после "-I" указываю сетевой интерфейс, а не IP выходной.

не совсем понял вопроса. Но сеть следующая.
Есть главный роутер в офисе. Внутренняя сеть 172.20.0.0/24. Есть Впн сеть 10.89.89.0/24. Адрес впн 10.89.89.1
Есть офис 1 например. Внутренняя сеть 172.20.1.0/24. Шлюз 172.20.1.1. Адрес Впн 10.89.89.100
Есть офис 2 например. Внутренняя сеть 172.20.2.0/24. Шлюз 172.20.2.1. Адрес Впн 10.89.89.101

и т.д.

Я хочу что-то вроде ping 10.89.89.100 8.8.8.8. или ping 10.89.89.101 8.8.8.8.

тогда тебе нужно другое сделать.
Что то типа

ssh user_ping@10.89.89.100 "ping 8.8.8.8"

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

Мне тогда интересно, что делает ping hop1 hop2 ... dst?

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

Отключена без возможности включить обратно?

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

Только учти 2 вещи: это ОЧЕНЬ большая дыра в безопасности; этим никто не пользуется, поэтому никто не знает даже как это включить, а тем более как с этим потом жить.

https://collection.51sec.org/2013/09/ip-source-routing-enabled-and-how-to.html

Красивого способа проверки нет, но source routing - это жуткая дыра, потому что контролировать кому его можно, а кому нет - нельзя. Контроль по-интерфейсно - это не смешно.

Я бы на твоем месте понарожал кучу таблиц маршрутизации в центре и привязал бы их к разным меткам.

например:

ip rule add fwmark 1 table 1
ip route add default via <next_hop_filial_1>
ip rule add fwmark 2 table 2
ip route add default via <next_hop_filial_2>
... и т.д.

Потом поправил файрвол соответствующим образом(чтобы ответные пакеты корректно доходили).

А потом просто тестил бы через ping с центра:

ping -m 1 8.8.8.8
ping -m 2 4.4.4.4

Соответственно первый пакет уйдет через шлюз первого филиала, второй - через шлюз второго.

Если филиалы связаны с центром нормальными туннелям(не чистым IPSec-ом, GRE+IPSEC или IPSec с VTI), то за исключением разрешения трафика со стороны центра через филиальный интернет никаких особых манипуляций проводить на шлюзах в филиале не надо.

Вероятно, проще будет использовать network namespaces или vrf (последний работает поверх network namespaces).

Запускать можно будет так:

ip vrf exec 10.89.89.100 ping 8.8.8.8
или
ping -I vrf-10.89.89.100 8.8.8.8
или
ip netns exec 10.89.89.100 ping 8.8.8.8

Самое простое — использовать обертки типа firejail.

Подобные манипуляции с машрутами мне первое что пришло в голову, но не подходят по двум причинам.
1. Усложнение таблицы маршрутизации. Для тех поддержки надо будет писать что и зачем там настроено. И как все работает.
2. Самое главное. Кроме гугл днс все остальные показали себя в качестве способов проверки не с лучшей стороны. Что Cloud DNS, что Quad Dns, что остальные очень часто бывали в момент проверки недоступны. Из-за чего были ложные срабатывания. К слову текущая делема с проверкой отчасти из-за этого и всплыла, что надо что-то придумать с проверками через 1-2 адреса. Сейчас уже 9 филиалов + еще два местных устройства. В каждом два, а иногда и три прова. Представьте сколько адресов надо раскидать по таблицам маршрутизации. Потом это все где-то надо документировать. И держать в голове, чтоб каждый раз в доки не лезть.

Одним словом это крайний самый вариант.

Пинг через определенный шлюз (комментарий)

Это наименее геморройный вариант. Только я бы его делал не с ping, а с curl.

Спасибо. Интересное решение.

Неясно чем вам решение с network namespace/vrf нравится больше чем с таблицами маршрутизации. Учитывая что по вашим же словам всё равно это документировать(и вышеперечисленные варианты все равно влекут за собой создания дополнительных таблиц маршрутизации :-))

если я правильно прошелся (хоть и поверхностно) по namespace, то я смогу обойтись проверкой пингуя один хост. В вашем же случая мне надо для каждого филиала по 2-3 узла добавлять в отдельную таблицу. Как я уже сказал, все эти Opendns, Quad Dns, CloudFlare DNS дают ошибочные тревоги. С Google DNS по крайней мере этого не наблюдается.

но если я ошибаюсь по поводу namespace и единого узла для проверки, то пардон конечно.

от документирования уже убежать, это точно.

Уже _не_ убежать конечно же. Отредактировать не дает

а в чем идея 2-3 провайдеров на удаленных точках?

и как это связано с тем что пинг на удаленных точках будет проверятся через впн, работающий через одного провайдера?

то есть если по впн вы объединены через одного провайдера и где-то за ним пропал Инет то в чем смысл проверки Инета на точках? если у вас пропал - то и там пропал.

логичнее мониторить на самих точках состояние канала и переключаться на другой. или я не понял?

1. В главном офисе 3 канала. Есть доменное имя, за которым все три внешних. TTL у днс 1 минута. На шлюзе стоит скрипт, проверяющий все три канала, если один упал, то сразу же через апи удаляется у днс хостера из записи ip не работающего канала. В этом плане переключение более менее быстро происходит у филиалов с головным офисом. Тем более с переходом от опенвпн на wireguard простой еще меньше стал. Опенвпн на подобном медленнее отрабатывал.
2. В каждом филиале есть резервирование + балансировка. Отвалился один - впн быстро поднялся на втором.

Можно было бы конечно в головном впереди поставить какой нибудь балансировщик наверное. Но то как в головном офисе все отрабатывает нас полностью устраивает. Вопрос с мониторингом интернета в филиалах.

если я правильно прошелся (хоть и поверхностно) по namespace, то я смогу обойтись проверкой пингуя один хост. В вашем же случая мне надо для каждого филиала по 2-3 узла добавлять в отдельную таблицу.

Ммм... не уверен что ты правильно всё понял. Тебе придется либо реконфигурировать один namespace на конкретный филиал при проверке либо иметь их столько же, сколько у тебя филиалов. Или иметь внутри одного namespace кучу таблиц маршрутизации. Чуть выше сложность, чем у предложенного мною решения, зато никому глаза мозолить не будут выхлопы ip rule в основном системном namespace

С Google DNS по крайней мере этого не наблюдается.

Ну дык можно пинговать ОДИН и тот же 8.8.8.8 в каждом филиале с помощью ping -m. Разные хосты не обязательны, затем и нужны отдельные таблицы маршрутизации, иначе можно было запихать всё в одну и радоваться.

Ну дык можно пинговать ОДИН и тот же 8.8.8.8 в каждом филиале с помощью ping -m

Так мне надо с головного проверять, а не на каждый филиал заходить. Я же говорил, оборудование на данный момент разношерстное (микрот, bsd и linux). На местах один раз настроить маршруты. И больше туда не лезть.

либо иметь их столько же, сколько у тебя филиалов

Из имеющихся вариантов это мне кажется более удобным, потому что если в филиале 3 прова, то мне не надо создавать на шлюзе головного офиса 3 маршрута, через роутер филиала. Мы ведь в namespace создаем маршрут по умолчанию, где шлюзом будет указан например 10.89.89.102. А потом просто тот же Google DNS пинговать используя этот namespace. Разве это не так работает?

Так мне надо с головного проверять, а не на каждый филиал заходить. Я же говорил, оборудование на данный момент разношерстное (микрот, bsd и linux). На местах один раз настроить маршруты. И больше туда не лезть.

Перечитай внимательно мой пост, где я расписывал про ping -m. Все указанные там настройки относятся ТОЛЬКО к шлюзу в центре. На шлюзах филиалов необходимо только разрешить трафик с центрального в филиальный интернет. Больше НИЧЕГО там делать не нужно.

Еще раз - ВСЕ тесты в описанной мною схеме делаются из центра. Как ты и просил.

Так мне надо с головного проверять, а не на каждый филиал заходить. Я же говорил, оборудование на данный момент разношерстное (микрот, bsd и linux). На местах один раз настроить маршруты. И больше туда не лезть.

А, ну если так, то конечно да. Я видимо жопой читал, но как-то упустил тот момент, что у тебя в филиалах несколько интернет провайдеров и нужно тестировать каждого.

2. В каждом филиале есть резервирование + балансировка. Отвалился один - впн быстро поднялся на втором.

все равно не понятна идея проверки до конца. с какой целью мы проверяем доступность Интернета в филиалах.

теоретически может быть три случая:

1. в филиале (или главном офисе) не работает ни один канал, следовательно впн с главном офисом не работает, следовательно проверка из главного не будет работать (пинг по впн просто не пройдет)

2. в филиале все работает

3. гипотетическая ситуация, когда впн между офисами работает через сеть провайдера(-ов), но за провайдером нет остального Интернета или есть частично, но в этом случае факт отсутствия Интернета будет виден и без проверки филиала. так как провайдеры одного города стыкуются перед выходом на магистраль то реально резервирование канала спасает только от неработоспособности собственно провайдера, а не от недоступности сети где-то за ними. да, возможнны варианты, но в общем случае, когда интернет не доступен по причине аварии где-то за пределами провайдеров смысла в переключении на другого мало. я не говорю, что его совсем нет. но хочется понять тот случай, ради которого затевается вся эта проверка и мониторинг наличия инета в филиалах.

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

1.Это уже отдельная проблема, когда в филиале или в главном ничего не работает. Тут и без проверки все понятно. Если филиал не работает, то мы узнаем это так же по мониторингу, мы ведь мониторим не только сам шлюз в филиале, но и сервера в филиалах. Они станут недоступны, как и сам шлюз. Отвал всех трех провайдеров в головном офисе - крайне редкая и маловероятная вещь. 2 из них по оптике. Третий держит узел непосредственно у нас.
2. —
3. Не все провайдеры и не во всех филиалах есть стыкуются, перед выходом. Скорее тут только 2 провейдера в пределах одного города (а это главный офис и один филиал) имеют стык. Остальные точки имеют в лучшем случае где нибудь на уровне самого магистрального, на точке обмена ближайшей, но не у нас в городе. И я хочу проверять ведь пингом до условного гугл днс. Если проблема у магистрала - я об этом как раз и узнаю. Я же не шлюз провайдера буду пинговать.

Что-то пока не вдуплю, что у нас должно быть в namespace 10.89.89.100, чтоб работала команда ip netns exec 10.89.89.100 ping 8.8.8.8. Я так понял на хостовой таблице маршрутизации все равно надо создавать кучу правил

В хостовой таблице не нужно создавать доп. правила, их нужно создавать в каждом namespace отдельно. Нужно создать namespace, прокинуть туда каким-то образом сеть (через ipvlan, например), настроить маршрутизацию, пользоваться.

К сожалению с wireguard ipvlan не хочет прокидывать.