Nftables failover wan

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

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

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

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

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

https://www.linuxquestions.org/questions/linux-networking-3/easy-way-to-autom...

И? Там пинги из юзерспейса и шлют как я и говорил.

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

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

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

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

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

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

• посчитать потерянные пакеты
• перещелкнуть вес на лету

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

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

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

HOWTO LARTC.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот и нет.

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

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

А вот и нет.

Почему же?

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

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

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

лучше

буду

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

писать свои

костыли.

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

Почему же?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

переезжая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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