LINUX.ORG.RU
решено ФорумAdmin

2 канала инета, скрипт автопереключения на резервный и обратно

 ,


4

4

Тут есть подобные темы, но «боевых» вариантов так и не нашёл, поэтому можете кидаться яйцами и помидорами, но добавлю свои 3 копейки.

Начальные данные:

- основной канал со статическим ip, имя интерфейса ens19

- резервный канал динамический, имя интерфейса wwx0c5b8f279a64 (да, это модем)

- метрика роута для основного канала по умолчанию 100

- метрика роута для резервного канала по умолчанию 700

Что делаем в цикле:

- последовательно добавляем, проверяем и удаляем маршруты до тестируемых узлов, это сделано потому, что при поднятии резервного канала пакеты даже при указании ping -I «net» не пойдут через основной канал

- если все 9 пакетов icmp потерялись, то включаем роут через резервный канал с метрикой 50 и присваиваем переменной gw2 значение off

- если хоть до одного из 3 узлов все ответы пришли, то проверяем переменную gw2, если она on, то на паузу и далее по кругу. Если она off, то удаляем маршрут с метрикой 50 и присваиваем переменной gw2 значение on и далее на круг

Пауза проверки основного канала 20+9, основного (при включенном резервном) 300+9 (сек)

Сам скрипт (/etc/auto_net_switch.sh):

#!/bin/bash

# Основные переменные
# gw2 - шлюз резервного канала, состояние on или off, default=off
# net1 - имя сетевого интерфейса основного канала
# net2 - имя сетевого интерфейса резервного канала
# net1_gw_ip - ip адрес шлюза основного канала
# net2_gw_ip - ip адрес шлюза резервного канала динамический, поэтому определяем его каждый цикл
# net2_ip - ip адрес сетевой карты резервного канала динамический, поэтому определяем его каждый цикл
# ip[1-3] - ip адреса узлов для проверки соединения основного канала

# Изменить нужно только эти 5 переменных:
net1=ens19
net2=wwx0c5b8f279a64
ip1="1.1.1.1"
ip2="2.2.2.2"
ip3="3.3.3.3"

# Далее переменные менять не надо
gw2=off
net1_gw_ip=`ip route | awk '/'$net1'.*static/ { print $3 }'`

# Файл логов
logfile=/var/log/net_switch.log
echo `date +%Y.%m.%d__%H:%M:%S`' Скрипт автопереключения канала запущен' >> ${logfile}
# бесконечный цикл
while [ true ]; do
    net2_gw_ip=`ip route | awk '/default.*'$net2'/ { print $3 }'`
    net2_ip=`ifconfig | grep $net2 -A1 | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | awk '{ print $2 }' | cut -f2 -d:`
    route add $ip1 gw $net1_gw_ip
    result1=$(ping -c 3 -I ${net1} -W 1 ${ip1} 2<&1| grep -icE 'unknown|expired|unreachable|time out|100% packet loss')
    route del $ip1
    route add $ip2 gw $net1_gw_ip
    result2=$(ping -c 3 -I ${net1} -W 1 ${ip2} 2<&1| grep -icE 'unknown|expired|unreachable|time out|100% packet loss')
    route del $ip2
    route add $ip3 gw $net1_gw_ip
    result3=$(ping -c 3 -I ${net1} -W 1 ${ip3} 2<&1| grep -icE 'unknown|expired|unreachable|time out|100% packet loss')
    route del $ip3
    if [[ $result1 == 0 && $result2 == 0 && $result3 == 0 ]]; then
        if [[ $gw2 == on ]]; then
	    	route del -net default gw $net2_gw_ip metric 50 dev $net2
	    	ip route flush cache
	    	real_ip=`wget -q -O /dev/stdout http://checkip.dyndns.org/ | awk '{ print $6 }' | cut -d \< -f1`
	    	echo `date +%Y.%m.%d__%H:%M:%S`' Основной канал активирован, внешний ip' $real_ip >> ${logfile}
	    	gw2=off
	fi
	sleep 20
    else
	if [[ $gw2 == off ]]; then
	    	route add -net default gw $net2_gw_ip metric 50 dev $net2
	    	ip route flush cache
	    	real_ip=`wget -q -O /dev/stdout http://checkip.dyndns.org/ | awk '{ print $6 }' | cut -d \< -f1`
	    	echo `date +%Y.%m.%d__%H:%M:%S`' Основной канал деактивирован, включен резевный канал, внешний ip' $real_ip >> ${logfile}
	    	gw2=on
	fi
	sleep 300
    fi
done

Даём права на исполнение и закидываем в автозагрузку крона

sudo chmod 700 /etc/auto_net_switch.sh
sudo sh -c 'echo "@reboot root sleep 120; /etc/auto_net_switch.sh" >> /etc/crontab'



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

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

Смотрите у ТС это роутер. Понятно что должны быть и еще другие правила. Однако рассматривать задачу надо частями. Изначально рассматриваем как отдельно стоящую машинку которой надо при падении пров1 переключиться на пров2. Для проверки работоспособности провов используем пинг через них. Все, задача на этом решена.
А маркировки пакетов и другие радости мы уж используем для дальнейших задач.
Т.е. одно не отменяет другое. Например у меня правила с fwmark стоят по приоритету выше, чем from $IP_PROVX, они и используются для кастоматизации.

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

У утилиты ping есть возможность указать чем заполненять icmp-пакеты. Этот вариант я часа два назад только что придумал. В статье я просто рассматривал вариант с двумя проверочными хостами. Ну и в третьих, у вас и так будет 2 локальных адреса как минимум — ведь это разные каналы, ну и третий - локалку тоже можно натить.

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

Я не говорил, что надо убирать default route из таблице main. Когда приложение устанавливает соедиение с хостом из инета, и не указало src-адрес (не прибиндило сокет), то этот адрес назначается на основании default маршрута в таблице main. И без default маршрута в main придётся во всех командах на маршрутизаторе (допустим wget) указывать с какого адреса идти.

Зачем?

Чтобы к провайдеру не пошли пакеты с «левым» с его точки зрения src-адресом.

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

Для проверки работоспособности провов

Ну надо же, как же я не догадался... А это ничего, что вот тут 2 канала инета, скрипт автопереключения на резервный и обратно (комментарий) в третьем абзаце разжевано:

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

Я не говорил, что надо убирать default route из таблице main.

Не говорили. Это я за вас предположил, что предлагаете такой вариант. Звиняйте тогда мой вариант лучше.

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

И без default маршрута в main придётся во всех командах на маршрутизаторе (допустим wget) указывать с какого адреса идти.

Это решается тем же rule, если переключили прова, поменяли rule, from all lookup $TB_PROVX

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

Но бывает, что ping не проходит, а http/https работают. Скрипт переключил канал на резервный, провайдер основного канала утверждает что всё работает, тогда можно проверить telent'ом.

Если на резервном канале адрес динамический, то скрипт правит ip rule, а админ помнит только 192.168.199.2.

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

Это я за вас предположил, что предлагаете такой вариант. Звиняйте тогда мой вариант лучше.

Да ладна. Само переключение через default mail — почему бы и нет? Всё равно текущий канал для пользователей уже неработоспособен, нат надо перестраивать, соединения отвалятся.

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

Ну и причем тут это? Зачем жертвы? Мы вроде обсуждаем вариант без жертв и максимально простой.

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

Чем лучше? Тем что у вас на маршрутизаторе перестанет работать wget и пр.? То, что в каждой таблице свой default маршрут это пожалуйста, то, что мы локалку маршрутизируем не через main, тоже пожалуйста. Но чем помешал default в таблице main?

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

Если на резервном канале адрес динамический

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

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

Я писал про админа, что это ему удобнее, а не скриптам. Удобнее для ручной проверки, когда возникают ситуации, непрописаные в логике скрипта.

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

Там рассматривался вариант, когда нам надо оба канала для произвольного количества сервисов/клиентов. А если у нас один канал из двух для работы и только спец-рутинг для проверок о жизнескопсобности соседнего канала, то менять default — намного проще.

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

А rule поменять просто писец как сложно. И кстати не надо флушить кэш роута. Да и зачем сразу делать «не правильно» сегодня оно «очень просто», завтра как обычно начинает обрастать костылями. Не проще все сразу по фэншую сделать и не парить мозг?

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

Я писал про админа

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

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

А rule поменять просто писец как сложно.

Оно вроде не умеет замены, только удалить+добавить. А с правилами вы же вон сами url дали с пространственными разъяснениями, что default он прост как 5 копеек, а правил придётся рисовать много, если локальная сеть иерархична.

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

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

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

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

Опять 25. Где вы увидели в моём алгоритме переключения для тыканья?

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

Оно вроде не умеет замены, только удалить+добавить.

Эт очень сложно? В рамках задачи ТС. Два правила первое по приоритету выше, упал пров1, удалили правило, поднялся пров1 добавили с тем же приоритетом

а правил придётся рисовать много, если локальная сеть иерархична.

Глупость пишите. Не так и много. Вы прочитали внимательно о чем речь?
Именно поэтому куча народа и плодит простыни в iptables в виде -s SRCIP -d ! DSTIP -j MARK, потом простыни начинают разрастаться и следить за этими -j MARK становиться все тяжелее.

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

Эт очень сложно?

Это не идеально.

Вы прочитали внимательно о чем речь?

Представьте себе - да. Куча правил с src<->dst пояляется в том описании vel-а от кучи сервисов. У вас будет ровно две записи — для проверок. В зависимости от результатов тех проверок меняем default main и вуаля. А вы похоже вообще только спорите и не представляли себе во что оно выливается при правилах.

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

Эт очень сложно?

Это не идеально.

Я дополнил, скорее всего не успели прочитать. Повторю на всякий случай:
Эт очень сложно? В рамках задачи ТС. Два правила первое по приоритету выше, упал пров1, удалили правило, поднялся пров1 добавили с тем же приоритетом

А вы похоже вообще только спорите и не представляли себе во что оно выливается при правилах.

Как не странно представляю. И как раз вариант без defroute в main удобнее. Вообще о чем вы спорите? В рамках задачи, вот у нас два прова, создали два defroute в отдельных таблицах, создали два правила from all lookup $TB_PROVX с разным приоритетом? Ну и чем оно отличается от двух defroute с разной метрикой?

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

Проверять первой таблицу main это шило на мыло. Туда попадают все подсети. Допустим провайдер выдал мне «белый» адрес из сети /24. Компы из это сети физически не воткнуты в один свич, а размазаны по городу, поэтому когда оборвётся оптика до моего здания, из интернета исчезнет мой ip и ещё пара-тройка, а остальные 250 адресов могли бы быть доступны через резервный канал. По мне лучше дублировать маршруты, первой просматривая только таблицу с адресами локальной сети (сетей).

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

Вообще о чем вы спорите? В рамках задачи, вот у нас два прова, создали два defroute в отдельных таблицах, создали два правила from all lookup $TB_PROVX с разным приоритетом? Ну и чем оно отличается от двух defroute с разной метрикой?

А вы прочитайте ещё раз ваш же URL. Понимаете, from all отправляет ВСЁ. А default main - отправляет по дефолту, то есть если никуда более не задано. Потому второе — проще по определению, особенно если локалок много.

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

В каком вашем алгоритме?

Этот вариант я часа два назад только что придумал.

или

вариант с двумя проверочными хостами.

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

Если вы сделаете src-рутинг, вы запретите работать с тем хостом от указанного адреса с любыми протоколами по одному из каналов. И именно это и было сказано ранее.

Теперь объясните, что в этом плохого?

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

Я пишу, что удобно иметь возможность одной командой с консоли работать по произвольному протоколу с любым ip-адресом по любому желаемому каналу

Я против чтоли? Только вы попробуйте включить не образное, а логическое полушарие. Вы как объясните машине, что вы хотите проверить канал номер N? По src-IP? Дык наздоровье. У вас два src-IP, одного и другого канала.

, а не по тому каналу, который выбрал скрипт

это какой-то образ без внятного обхяснения, что и как оно само магически выбрало. Если вы про автомат — так он детерминирован, он обязан что-то вначале выбрать для своей работы. Он вот проверяет по двум хостам, вы по фазе Луны, ну так и что?

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

Проверять первой таблицу main это шило на мыло. Туда попадают все подсети. Допустим провайдер выдал мне «белый» адрес из сети /24. Компы из это сети физически не воткнуты в один свич, а размазаны по городу, поэтому когда оборвётся оптика до моего здания, из интернета исчезнет мой ip и ещё пара-тройка, а остальные 250 адресов могли бы быть доступны через резервный канал.

Аргумент! Согласен, ваш пример хороший. Когда «наоборот» костылять придется. Сам не сталкивался, но опять-таки это можно сделать всего двумя правилами, которые будут выше main, и при поднятии пров1 их удалить.

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

Не это вы перечитайте. Вот у вас куча сетей с разными маршрутами и и более того разные сервисы должны ходить по разным маршрутам. Повторюсь и вот начинаем костылять, -s $NET1 -s $NET2 -j ACCEPT, -s $HOST7 -d $NET9 -j ACCEPT, -s $HOST3 --dport 10 -j ACCEPT когда вот этих $NETX, $HOSTX становиться много, в этой простыне ковыряться становиться все сложнее.

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

Я задал простой вопрос, а вместо ответа от вас какой-то понос про полушарии и фазы луны?

Понятно, что автомат работает по алгоритму, который совершенен не на 99,9%. И его нужно проверять и улучшать.

Если вы это признаёте:

УПо src-IP? Дык наздоровье. У вас два src-IP, одного и другого канала.

То, почему для вас моё исходное предложение использовать для проверочного ping'а по основному каналу при работающем резервном именно src-IP, вместо ″route add $ip1/route del″

Простите, но это какая-то ерунда.

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

Вот у вас куча сетей с разными маршрутами

И как тут default им может помешать? Он наоборот самый удобный способ отправить всё что не по «разным маршрутам» именно туда, где остальные всемирные маршруты.

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

Это точно по задачу этого топика?

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

Я задал простой вопрос, а вместо ответа от вас какой-то понос про полушарии и фазы луны?

Да, я попытался встать на ваш уровень объяснения окружающего мира.

И его нужно проверять и улучшать.

Ерунда. Алгоритм надо выработать предсказуемым и надёжным. И на этом остановиться.

вместо ″route add $ip1/route del″

Хватит врать. Я всегда рассматривал все варианты. Если вы думаете, что сделав ip rule вместо route add вы тем самым для этого проверочного IP сделаете другое поведение вашего скрипта, то у меня дл вас плохие новости.

Простите, но это какая-то ерунда

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

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

И как тут default им может помешать? Он наоборот самый удобный способ отправить всё что не по «разным маршрутам» именно туда, где остальные всемирные маршруты.

Мдя. Читать вы не умеете (vel правильно написал, что еще добавлять?). Вот mky выше аргументировано описал возможную проблему. Вы же не привели ни одного аргумента.
Писать правда тоже не особо умеете (хоть я и сам ранее плюсанул вашу статью, норм, только тяжело описано).

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

Вот mky выше аргументировано описал возможную проблему.

Он вообще скатился в другую задачу: «обход блокировок». Стоит только выяснить такому админу, что провайдер A не работает с ресурсом X, а провайдер B — с Y, так эта задача вообще превращается в задачу одновременной работы по двум каналам с проблемой как решить финансовый вопрос по поводу нежелательности работы с резервом.

Вы же не привели ни одного аргумента.

Ложь. Аргмент там был прост как 5 копеек: для простых случаев дефолт вполне рабочее решение. Заметьте, я не говорил, что — единственное.

И вообще, знаете, почему я уже стараюсь уменьшать количетво аргументов, а пытаюсь жевать одно и тоже? Потому что наЛОРе не принято вчитываться и принято обижаться на любое возражение, не смотря на то, что оно высказано в обоснованной и с кучей реварансов с доброжелательностью форме. Вот у вас получилось последнее. Вы уже скатились в откровенное вранье с передергиванием.

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

вместо ″route add $ip1/route del″

Хватит врать. Я всегда рассматривал все варианты. Если вы думаете, что сделав ip rule вместо route add вы тем самым для этого проверочного IP сделаете другое поведение вашего скрипта, то у меня дл вас плохие новости.

Теперь при ping -I $IP_PROVX 8.8.8.8 в зависимости от $IP_PROVX пойдет или через первого или через второго.

Когда я что-то спорил с этим?

Хватит врать.
Когда я что-то спорил с этим?
Хватит врать.

Ну и кто врет?

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

Ну и кто врет?

Я уже прям теряюсь. А может быть вы не в курсе, что маршрутизатор и будет работать с сервисами с этими внешними IP? И потому для него разницы и не будет, если вы завернули либо правилом либо талицей main: он по дургому каналу по всем протоколам с этим проверочными IP работать не сможет. Потому я и предложил сделать особые правила, не нарушающие работу никаких сервисов для проверочных хостов. Это как обычно тут на ЛОРе вызвало батхерт, как же, кто-то осмелился возразить. А ручную проверку блокировок я никогда никому не запрещал.

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

Ложь. Аргмент там был прост как 5 копеек: для простых случаев дефолт вполне рабочее решение.

Не спорю, но так же выше описал, что лучше сразу сделать «по уму», а то вдруг еще чего потом появиться? Но повторюсь, минусы такого решения привел именно mky а не вы. Такое конечно редкость, но то же может быть.

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

но то же может быть.

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

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

А моё «по уму» ни разу даже не рассмотрели, создавая ощущение, что либо нихрена не поняли, либо отторжение чисто из-за спора.

То что не ответили, что ваш вариант тоже имеет место быть, не значит что «чисто из-за спора». mky вам выше ответил что менее удобно править правила в iptables. А я так же спросил в чем разница?
Предлагаю не ходить по кругу. Каждое решение имеет место быть на своем месте.

anc ★★★★★
()

Да ёж маё!!!
Сколько стоит циска/микротика/длинка, которая может в два провика?

У вас тут дискуссия уж на 100и500 сообщений, а толку не видно аж никак.

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

править правила в iptables.

Правила я предлагал сделать ровно два для автомата. Делать ручную проверку со всей необходимой предварительной обвязкой я не запрещал. Для унификации предложив сделать вообще одним скриптом с опциями — автомат/ручная проверка. (Опять придётся жевать: я это предложил не как необходимость, а как само-собой вытекающее из шутливого понимания что такое настоящий админ).

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

Сколько стоит циска/микротика/длинка, которая может в два провика?

можно подумать, они это делают лучше. Всё ровно тоже, либо AS+BGP, либо тот же наколенный мониторинг и переключение маршрутов. А раз так, то универсальная ОС намного удобнее, так как позволяет наворотить какие угодно хотелки.

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

Да ёж маё!!!
Сколько стоит циска/микротика/длинка, которая может в два провика?

И что «оно» как-то «эмпирическим» путем все решит? Сильно сомневаюсь.

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

Видимо, вы не в состоянии читать больше пары абзацев. Ещё раз повторю вопрос:

Если вы сделаете src-рутинг, вы запретите работать с тем хостом от указанного адреса с любыми протоколами по одному из каналов. И именно это и было сказано ранее.

Теперь объясните, что в этом плохого? Или это было ваше очередное высказывание в стиле «лошадь кушает овёс»?

Простите, но это какая-то ерунда. Пакеты идут не «через», а с адреса интерфейса

Это и так все знают, что "с адреса интерфейса" это какая-то ерунда, зачем про это писать?

так эта задача вообще превращается в задачу одновременной работы по двум каналам с проблемой как решить финансовый вопрос по поводу нежелательности работы с резервом.

Чего, какой финансовый вопрос? Простые варианты походу вобще не в вашем мире. У провайдера работают люди, и они бывало ошибаются, иногда звонок в техподдержку к внятным объяснением проблемы реально помогает. Допустим, наружу DNS провадера даёт неправильную PTR-запись вашего ip-адреса, через второй канал это легко увидеть...

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

О, боже, вы всё не успокоитесь.

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

А у меня сложилось мнение такое о вас.

Теперь объясните, что в этом плохого?

И как такое заявление не назвать глупостью? Вам предложен был алгоритм без этого недостатка. Но как обычно включается режим ЛОРа, а именно подросткового нигилизма: зачем рассматривать, проще нагородить бреда с оскорблениями.

Это и так все знают, что «с адреса интерфейса» это какая-то ерунда, зачем про это писать?

Зачем лишний раз демонстрировать свои детские обиды? Написали ерунду - получите исправление.

Чего, какой финансовый вопрос?

Что, тупость не позволяет понять, что это было один из вариантов в виде «например»?

Допустим, наружу DNS провадера даёт неправильную PTR-запись вашего ip-адреса, через второй канал это легко увидеть...

Я уже сбился со счёта узнать у вас, где я вам запретил что-то там увидеть?

Ладно. Последний китайский раз. Я предложил вариант, при котором скрипт по переключению каналов не ломает ни один сервис на маршрутизаторе. Это достигается всего двумя спец правилами, которые позволяют и скрипту выполнить свои функции и продолжать работать всем сервисам, которые не в курсе о переключении каналов и потому забинденные на 0.0.0.0:порт всё равно выбирают локальный адрес правильно, то есть делают соединения с src адресом ядром исходя из интерфейса дефолта (между прочим это ваша идея, мне много стоило этот спор с anc по поводу простоты получаемой конструкции, где даже nat не нужен).

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

По себе людей не судят, ваши «опять 25», «о боже» и пр. показывает, что эмоции кипят у вас. Это вот ваше поведение:

Потому что наЛОРе не принято вчитываться и принято обижаться на любое возражение,

но зачем переносить его на других?

что это было один из вариантов в виде «например»?

Как-то слова «например» там не было, было однозначное утверждение:

Он вообще скатился в другую задачу: «обход блокировок»... превращается в задачу одновременной работы по двум каналам

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

Это достигается всего двумя спец правилами, которые позволяют и скрипту выполнить свои функции и продолжать работать всем сервисам

И с вашей точки зрения два спец правила (в iptables, как я понимаю) это проще, чем ноль спец правил в iptables. Так бы сразу и сказали.

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

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

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

и скрипт мог пользоваться тем же механизмом, что и админ для отправки ping, tcpping и т.д.

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

И с вашей точки зрения два спец правила (в iptables, как я понимаю) это проще,

Нет, ничерта вы не понимаете. Правила нужны для обеспечения работы скрипта. А простота там была в методе обеспечения работы сервисов. Или... погодите. Вы может не в курсе, что рутинг по маркировке и src-полиси-рутинг можно совместить?

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

Вас что, под дулом пистолета заставили отвечать, если для вас этот топик тупняк?

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

Два правила в iptables для обеспечения работы скрипта это ненужная зависимость. Маршрутизатор не выжигается на ПЗУшке, админ правит правила iptables (обычное дело) и может по ошибке или вобще удалить их, или просто нарушить их работу, так что будет неправильная маркировка. И всплыть это может не скоро, так как при нормальном провайдере переключения не часто.

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

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

Вас что, под дулом пистолета заставили отвечать, если для вас этот топик тупняк?

А может вы за собой лучше будете следить? Вот это «Ещё раз повторю вопрос» «Теперь объясните» и прочие это что, по вашему риторические вопросы?

И с этой точки зрения лучше, если скрипт пользует тот же механизм, что и админ.

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

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

Скрипт не мешает админу. И тот и другой отправляет icmp пакет командой ″ping -I ip-адрес″. По «ip rule» пакет попадает в соотв. таблицу маршрутизации и по ней уходит через соотв. интерфейс. Я пишу про механизм отправки пакета по заданному каналу, а не про алгоритм переключения.

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

И тот и другой отправляет icmp пакет командой ″ping -I ip-адрес″. Я пишу про механизм отправки пакета по заданному каналу, а не про алгоритм переключения.

А я вам миллионый раз талдычу, что если для отправки пакетов по текущему каналу указание "-I IP" необходимо, значить хост — сломан. Я даже думаю, что вы с anc даже не догадываетесь почему это необходимо и какой IP адрес будет выбирать хост, так как даже не представляете теоретически проблему, не то что практически.

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