LINUX.ORG.RU
ФорумAdmin

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

 , ,


1

1

Есть задача мониторить каналы на удаленных точках. На каждой точке по 2-3 провайдера. НА местах настроены маршруты вида

ip rule add to 8.8.8.8 table PV1
ip rule add to 8.8.4.4 table PV2

Устройства на концах разные. (пока есть фрагментация, в дальнейшем придем к единому). Opnsense/Pfsense, Микротики и Linux машины. Но выше указанные правила маршрутов есть везде. Можно конечно пинговать просто внешние адреса. Но это не всегда правильно, потому что в головном офисе и филиалах +/- одни провайдеры, и пинг внешнего адреса может идти по внутренней сети прова. То есть как бы внешний доступен, а по факту инета нет, потому что магистральный провайдер сломался. Поэтому хочется из головного офиса проверять интернет в филиалах. И тут решил посмотреть что можно сделать, не трогая таблицу машрутизации у себя в головном. man ping говорит о
ping hop1 hop2 ... hopN dst


Но я не смог заставить работать. Делаю например
ping 10.89.89.100 8.8.8.8

tcpdump показывает, что на интерфейс впн приходят пакеты от 10.89.89.1 (адрес сервера в головном) с назначением 10.89.89.100 (адрес филиала). А дальше тишина. Форвард и маскарад разрешен. Но пакеты теряются. Наверняка надо какой-нибудь параметр в sysctl изменить. Но не понял какой.

Если есть какой-то иной и более красивый способ проверки - буду только рад услышать. Можно конечно скриптами, где сперва добавляется маршрут до условного 8.8.8.8 через 10.89.89.100, но это костыль.

★★

Ответ на: комментарий от Atlant

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

as_lan ★★ ()
Ответ на: комментарий от as_lan

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

Atlant ★★★★★ ()
Последнее исправление: Atlant (всего исправлений: 1)
Ответ на: комментарий от Atlant

не совсем понял вопроса. Но сеть следующая.
Есть главный роутер в офисе. Внутренняя сеть 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.

as_lan ★★ ()
Последнее исправление: as_lan (всего исправлений: 1)
Ответ на: комментарий от as_lan

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

ssh user_ping@10.89.89.100 "ping 8.8.8.8"

Где для «user_ping» сделан ssh-вход по ключу.

В альтернативном варианте тебе тогда нужно делать на VPN-шлюзе маршрут для конкретных внешних адресов через шлюзы-филиалов, а на шлюзах филиалов разрешить пропуск твоего трафика через их собственный интернет. Этот вариант реализуется дольше, да и смысла в нём будет мало.

Atlant ★★★★★ ()
Последнее исправление: Atlant (всего исправлений: 1)
Ответ на: комментарий от Atlant

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

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

as_lan ★★ ()
Ответ на: комментарий от as_lan

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

anto215 ★★ ()
Ответ на: комментарий от as_lan

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

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

anto215 ★★ ()

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)

Вероятно, проще будет использовать 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.

ValdikSS ★★★★★ ()
Последнее исправление: ValdikSS (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

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

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

as_lan ★★ ()
Ответ на: комментарий от as_lan

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

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

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

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

as_lan ★★ ()
Последнее исправление: as_lan (всего исправлений: 1)

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

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

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

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

nerve ★★ ()
Ответ на: комментарий от nerve

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

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

as_lan ★★ ()
Ответ на: комментарий от as_lan

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

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

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

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

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

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

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

as_lan ★★ ()
Ответ на: комментарий от as_lan

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

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

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

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от as_lan
  1. В каждом филиале есть резервирование + балансировка. Отвалился один - впн быстро поднялся на втором.

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

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

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

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

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

nerve ★★ ()
Ответ на: комментарий от nerve

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

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

as_lan ★★ ()
Ответ на: комментарий от ValdikSS

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

as_lan ★★ ()
Последнее исправление: as_lan (всего исправлений: 1)
Ответ на: комментарий от as_lan

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

ValdikSS ★★★★★ ()