LINUX.ORG.RU
ФорумAdmin

Nftables failover wan

 , ,


1

1

Можно как-то организовать переход на второй wan в случае потери N процента пакетов или отсутствия пинга до определенного узла, и и возврат обратно при восстановлении основного канала?
П.с. Задачка тривиальная - при отвале инета по кабелю переключить офис на gsm, потом вернуть.
В pfsence делается одним кликом но хочется попробовать перенести решение на nft

★★★★

nftables это всего лишь таблицы правил, никаких активных действий они предпринимать не могут. Так что пиши пинговалку на си, которая в зависимости от количества потерь (рекомендую превышения искать за 5-10 сек, а возврат - за хотя бы минуту) будет менять route-таблицы (которые командой route add default gw / route delete default меняются). nftables может и может роутингом заниматься, но незачем.

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

Это называется advanced routing и настраивается средствами iproute2. Про варианты решений можно почитать в крайне полезном HOWTO LARTC.

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

Не знаю, ту простыню читать лень, по по слову ping в ней ничего не нашлось. Я всё же думаю что автоматической отправки пингов для оценки потерь в ядре нет, это должна делать юзерспейсная прога.

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

Ну раз лень то и я не знаю. Ты почему то упоролся в ping, тут классическая XY проблема как мне кажется. Компьютер твой впрочем, решай как хочешь

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

Это не моя тема, но нормальных альтернатив пингам я таки не вижу. Нормальных - это не «сделаем так потому что по-другому в простыне не написано» а «сделаем так потому что это оптимальный вариант».

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

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

Ой блин, ты же не ТС. Извиняюсь, я всё это время с ТС разговаривал. Раннее утро у меня тут, попутал, сорян.

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

nftables это всего лишь таблицы правил, никаких активных действий они предпринимать не могут.

Почему? Они же могут счелкать разные тумблеры по событиям - достижениям квот, кол-ву соединений и т.п., плюс есть встроенный балансировщик т.е. по сути для старта достаточно:

  • собрать балансировщик с весами, где у провода вес 100 а у гсм вес 0
  • сделать счётчик потери пакетов с интервалом самосброса раз в 5 минут, который смотрит только в кабель
  • если процент потери в счётчике на конец интервала больше N то переключить вес в балансировщике с 100/0 на 0/100, если меньше то вернуть 100/0

В теории оно вроде как все поддерживается в нфт но кто бы подсказал как:

  • посчитать потерянные пакеты
  • перещелкнуть вес на лету
rukez ★★★★
() автор топика
Ответ на: комментарий от Jameson

Как по мне первый способ интереснее и гибче, так как пингующий в цикле скрипт не кажется мне изящным решением, но он требует вникания в глубины. Зато второй сильно проще.

У пинга есть объективный плюс - он смотрит реальный линк между двумя сетями и не заставит перейти на гсм если условный юзер Петя начнёт каким-то образом стробить запросы в пустоту

И минус - если лег наш единственный пингуемый сервер то все перешло на гсм. Но считаем что условный яндекс не лежит :-)

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

HOWTO LARTC.

О, спасибо, как раз начинаю вникать в сети :-)

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

И минус - если лег наш единственный пингуемый сервер то все перешло на гсм.

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

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

Так ты сам и ответил. Счётчик потерь - это именно что активное действие, нужно слать пинги, ядро само это делать не будет. Ещё теоретически можно пассивно оценивать (не точно! только приблизительно) потери по tcp-траффику, но подозреваю что такое если и есть то только в драйвере tcp-протокола для динамической подстройки таймингов конкретного tcp-коннекта.

Так что повторю: напиши отправлялку пингов (только не делай это на баше с запуском команды ping - будет костыльно и убого, напиши на си с raw сокетом) с скользящим окном с затуханием статистикой потерь (окна 10 сек и 1минуту). Когда в 10сек окне потери больше 20% - считаешь линк проблемным, когда за минуту стали меньше 1% - исправившимся, переключать можно либо через system() вызовом утилиты либо ioctl() к ядру напрямую там тоже не сложно.

И повторю: не знаю зачем тебе целый файрвольный балансировщик, если задача - переключить default gateway. Это гораздо проще.

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

только не делай это на баше с запуском команды ping - будет костыльно и убого, напиши на си с raw сокетом)

Лучше на асме, хотя не, сразу в hex, так точно будет true. И руление фв тоже, а то вызов nftables это

будет костыльно и убого

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

Так ты сам и ответил. Счётчик потерь - это именно что активное действие, нужно слать пинги,

Процент потерь это кол-во неудачных соединений для tcp - т.е. ядро это формально видит.

Бонусом пришла идея как можно сделать ещё проще - смотреть объём входящего трафика и если он в, например, 1000 раз меньше исходящего (или просто равен нулю в течении некоторого времени при условии что есть исходящий трафик) то wan точно мёртв (с оговоркой что всякое арпо-подобное широковещание не должно ходить наружу чтоб не сгенерить ночью ложняк)

Так что повторю: напиши отправлялку пингов

С отправлялкой пингов ход понятный, просто интригует точно ли нет встроенной педальки для столь простого и распространённого случая в такой навороченной штуке как нфт

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

Не надо преувеличений. Никаких асмов я не предлагаю. Пинговалка на си это весьма тривиальный код, а баш не подходит потому что тут надо реализовывать хоть и простые, но алгоритмы, а не просто «вызвать это вызвать то, может с условием на успех/неуспех» - делать что-то сложнее описанного на шеллах это жуткий изврат.

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

Пинговалка на си это весьма тривиальный код

Который надо будет пересобирать под разные системы и перетаскивать на них.

а баш не подходит потому что тут надо реализовывать хоть и простые, но алгоритмы

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

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

Процент потерь это кол-во неудачных соединений для tcp - т.е. ядро это формально видит.

Соединение может быть неудачным по разным причинам, может ты лежащий сайт пытаешься открыть. Или тебя там забанили по айпи (хотя тут уже смена канала может помочь).

смотреть объём входящего трафика и если он в, например, 1000 раз меньше исходящего

Можно, но оно будет немного кривовато (с одной стороны ложные срабатывания, с другой, если не хочешь их постоянно иметь - придётся дольше ждать чем с пингами, до вынесения вердикта).

просто интригует точно ли нет встроенной педальки для столь простого и распространённого случая в такой навороченной штуке как нфт

Повторю - нфт это всего лишь правила обработки пакетов. Не надо возводить их куда-то. Для переключения гейта есть непосредственно предназначенный для этого инструмент (таблицы маршрутизации).

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

Который надо будет пересобирать под разные системы и перетаскивать на них.

Во-первых, какой ужас, один раз запустить gcc, даже если бы ты был прав. Лечись от си-фобии. Во-вторых, не пиши чушь. Пересобирать надо только под разные ОС (например Linux / FreeBSD) или разные разрядности. В рамках же одного 64-битного линукса, который скорее всего у автора, можно скомпилить один раз (на старой системе) и оно будет везде работать где libc такая же или новее (а скорее всего и на некоторых более старых), в зависимостях ничего кроме libc не будет. А «перетаскивать» что скрипт, что исходник, что бинарник - одинаково.

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

Для НОРМАЛЬНОЙ работы нужно собирать статистику потерь. Но твой подход понятен - сделать абы как лишь бы на первый взгляд работало и не напрягаться. Ненавижу такой софт, им в итоге невозможно пользоваться без опасений что он где-то не накроется рандомно.

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

Для НОРМАЛЬНОЙ работы нужно собирать статистику потерь.

И? Без сишечки прямо ну никак?

А «перетаскивать» что скрипт, что исходник, что бинарник - одинаково.

А вот и нет.

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

И? Без сишечки прямо ну никак?

Если ты извращенец, то можешь писать на шелл-скриптах. Они вроде тьюринг-полные, так что на них всё возможно. Но никаких причин «без си» это делать - нет, так что лучше использовать подходящий инструмент а не костыли.

А вот и нет.

Почему же?

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

Господа, не ссорьтесь, я один фиг не умею в си за пределами мелочей на мк, так что пинговалка будет на (о ужас) яве :-D
Но учитывая что там ещё овердофига всего на яве то пинговалке простительно

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

Если ты извращенец

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

лучше

буду

использовать подходящий инструмент а не

писать свои

костыли.

на каждый чих.

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

Почему же?

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

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

Мда, ты читал вообще что я выше писал?

Компилируешь один раз с каким-нить старым glibc, работать будет везде где он такой же, новее, или даже чуть старее. Дистр не важно какой, главное чтобы в нём glibc был. (А если статиком - то аналогично, только сравнивать надо версии ядер) И нет там никаких нюансов, по крайней мере между мейнстримными дистрами. Скомпилированное на 32-битном debian stretch например прекрасно работает на 64-битном centos 7, ну там разумеется 32-битное glibc поставлено для совместимости, а было бы всё одной разрядности и этого было бы не нужно.

Ну и традиционно баги, а куда же без них, нашли баг обновляй все машинки.

Причём тут это вообще? В шелл-скриптах багфиксы магически сами прилетят?

Хватит чушь писать.

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

Компилируешь один раз...

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

В шелл-скриптах багфиксы магически сами прилетят?

Вероятность допустить ошибку в скрипте существенно ниже, чем в православной сишечке. Я знаю о чем пишу, два года назад в одной софтине обнаружил баг 17 летней давности.

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

Лучше я обновлю бинарник раз в 20 лет, чем буду пользоваться кое-как работающим скриптом, пусть и не требующим обновлений. Багов то же самое касается: баг в бинарнике, найденный через 17 лет, означает что все эти 17 лет он не доставлял неудобств. Скрипт же будет доставлять всякие мелкие противные неудобства сразу, только чинить их не получится, с отмазкой «ну это же скрипт, поэтому давайте попроще» - типа смиритесь что сложный вылизанный до идеала (в т.ч. по жору ресурсов) функционал туда никто и не собирался засовывать.

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

баг в бинарнике, найденный через 17 лет, означает что все эти 17 лет он не доставлял неудобств.

Возможно что и доставлял... а может и нет...

Лучше я обновлю бинарник раз в 20 лет, чем буду пользоваться кое-как работающим скриптом

Браво! Человек пишет о том, что напишет многострочный код на сишечке и без багов, но при этом обязательно накосячит в полутора строках баш лапши. Аплодируем стоя. Премию в студию!

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

И вот в продолжение скрипты vs сишечка. Всё из того же комплекса в котором нашел баг. Скрипты 7 штук: 3 перловых, 4 баш. Из них с детства изменялся один перловый и один баш но я не уверен, что эти изменения связаны с багами, скорее логика работы менялась. А вот в сишечке багов выловлено было... не сосчитать.

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

Да, я напишу код на си без багов, тем более всего лишь пинговалку где всё влезет в несколько страниц. И я не вижу в этом ничего необычного. А писать баш-лапшу - плодить уродства и костыли, я её наверно тоже смогу написать, но это НЕ НУЖНО. У неё нет ни единого плюса по сравнению с хорошей программой на си. А чтобы баш-лапша была так же функциональна как аналогичная си-программа, там придётся писать в 10 раз больше, выглядеть это будет отвратительно, жрать ресурсы будет отвратительно (постоянно форкать новые процессы ради каждой ерунды, хоть на современных компах это и не заметно). Повторю, лечись от си-фобии. Си - не такой страшный и сложный, это хороший инструмент для написания идеально работающего софта, безо всяких компромиссов.

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

У неё нет ни единого плюса по сравнению с хорошей программой на си.

Её можно прочитать и в случае необходимости поправить здесь и сейчас. Уже этого было бы достаточно, но есть ещё KISS.
Похоже насчет вантуза я не ошибся. Это не в обиду, просто такой стиль, так как нет ничего, на каждый чих пишем свой неповторимый велосипед. И вот переезжая на то где «все уже написано до нас», от привычки избавиться не сразу удается.

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

Программу на си можно поправить здесь и сейчас.

В отличие от этого:

Скрипты 7 штук: 3 перловых

переезжая

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

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

Программу на си можно поправить здесь и сейчас.

Поправить да, но вот собрать уже не факт.

но привычка сувать везде скриптоту это ничего хорошего.

Я же сказал вантуз. Из вас категоричность так и прет. Или только белое или только черное, никаких смешений. Но если вы вспомните(если читали) старые, добрые, умные книжки по программированию, то там в начале было «ставим задачу, выбираем инструмент». Можно написать свой sed? Можно. Но зачем?

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

Поправить да, но вот собрать уже не факт.

А ты делай так чтобы собиралось.

Можно написать свой sed? Можно. Но зачем?

Писать свой sed не нужно, он уже есть. А вот когда стоит выбор между «написать скрипт для sed» или «написать программу» - уже итог зависит от того, что именно нужно сделать. «Программа» это не переизобретение sed-а, если что, а хардкод тех действий, которые ты ему скриптом хотел сунуть, с возможностью побайтово их оптимизировать именно под эту конкретную задачу. В зависимости от конкретных нужд второе может оказаться нагляднее и быстрее.

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

А ты делай так чтобы собиралось.

В мозг гцц прошить чтоли?

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

ну я и сказал - велосипедист.

В зависимости от конкретных нужд второе может оказаться нагляднее и быстрее.

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

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

У неё нет ни единого плюса по сравнению с хорошей программой на си

Справедливости ради, плюсов много. Простой баш легко сопровождать, его ненужно компилировать, он не требует никаких библиотек. Переход с одного контрольного хоста для пингования на другой ничего не стоит. Вся логика на ладони.

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

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

Простой баш легко сопровождать, его ненужно компилировать

Это всё страшилки. Сопровождать баш-код проще до тех пор, когда он состоит из последовательного запуск бинарников с редкими if-ами. Когда он становится сложнее - си уже выигрывает в простоте. Ну а насчёт компиляции - у tcc есть даже режим с #!/usr/local/bin/tcc чтобы этот иррациональный страх компилятора побороть.

он не требует никаких библиотек

Хороший код на си требует не больше библиотек чем скрипт. Конкретно в данном случае нужен только libc (ага, найди линукс без него).

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

А, так и я о том же.

то сразу кидаться в си, даже на заглянув в питон, это очевидная глупость.

Может быть питон и сойдёт, но вот как раз питон в плане «нужны всякие библиотеки» гораздо хуже и чем баш и чем си. А си, повторю, не такой страшный. Фразу «кидаться на си» я вообще отрицаю, время от времени пишу и скрипты на нём тоже, это не какое-то тяжёлое решение, просто некоторые иррационально его боятся почему-то.

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

Фразу «кидаться на си» я вообще отрицаю, время от времени пишу и скрипты на нём тоже, это не какое-то тяжёлое решение, просто некоторые иррационально его боятся почему-то.

На C выстрелить в ногу гораздо больше шансов, да и трудозатраты больше.

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

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

firkax ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.