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)

Жуть какая. Лучше бы использовали policy based routing, чтобы не добавлять/удалять маршруты. А сейчас, если эти ip-адреса будут из списка серверов майл-рушечки или вконтактика, то у юзверей при проверке будут паузы по 3 с.

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

Подбираются ip, которые по работе не востребованы. Найти 3 таких узла вообще не проблема. Так вк/ок/фб и надо долбить - на работе же надо работать ))) Можно дописать и на основе политик policy based routing с флагом и транспарантами ;)

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

Мало того, у юзверей эти 3сек задержки появляются только на резервном канале, что бывает раз 10 в год по несколько минут. Так что всё в пределах погрешности :)

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

Лучше бы использовали policy based routing, чтобы не добавлять/удалять маршруты

Policy based хороши для балансировки стабильных каналов. Как только один из них накрывается, все вообще работать перестает. Так что без скрипта регулярной проверки доступности шлюзов задачу резервирования, IMHO, не решить (если, конечно, своей AS нет).

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

Не, это действительно ужас. Добавление удаление роутов для пига, парсинг выхлопа самого пинга вообще жесть. Зачем все это?

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

Да, но не такими варварскими методами.

anc ★★★★★
()

В части пинга, вот вам древняя наколенная поделка

TRYCOUNT=4
function PingHost()
{
 HOST=$1
 TRY=1
 ERR=1
 while [ $TRY -le $TRYCOUNT ]; do
  if ping -c 1 $HOST 1>/dev/null 2>&1; then
   ERR=0
  fi
  TRY=$(($TRY+1))
 done
 return $ERR
}

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

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

Не, это действительно ужас. Добавление удаление роутов для пига, парсинг выхлопа самого пинга вообще жесть. Зачем все это?

Прошу прощения, сам скрипт я не смотрел.

Просто меня удивило заявление, что policy routing решит все проблемы с резервированием.

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

Просто меня удивило заявление, что policy routing решит все проблемы с резервированием.

Я такого не увидел, mky написал:

Лучше бы использовали policy based routing, чтобы не добавлять/удалять маршруты.

И он прав.
имхо при использовании более одного прова, продолжать рулить default route в таблице main как-то «не очень удобно».

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

имхо при использовании более одного прова, продолжать рулить default route в таблице main как-то «не очень удобно».

Согласен, собственно говоря, выше и написал, что для балансировки - самое то :). Может, конечно, я не так понял, но мне показалось, что mky предложил policy-routing вместо скрипта... Хотя, сейчас перечитал, возможно, я и не прав, предлагалось в скрипте этот инструмент задействовать...

Serge10 ★★★★★
()

Еще дополнение в этой части

real_ip=`wget -q -O /dev/stdout http://checkip.dyndns.org/ | awk '{ print $6 }' | cut -d \< -f1`
Сам только недавно узнал curl ifconfig.co будет попроще.

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

Сам только недавно узнал curl ifconfig.co будет попроще.

Это смотря чем. Если на рутере, то там может не оказаться этого вполне себе толстого curl. Вот вам на ash:

fn=0 echo -e "GET /ip HTTP/1.1\nHOST:ifconfig.co\nConnection:close\n\n" | nc ifconfig.co 80 | while read l; do if [ ${#l} -le 1 ]; then fn=1; continue; fi; [ $fn -eq 1 ] && echo "$l"; done

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

Нет, не вместо скрипта. Если прописать для каждого интерфейса (ip-адреса) свою таблицу со своим default маршрутом, то ping'у указывается ″-I ip-адрес″ и icmp-пакет идут именно через этот интерфейс и нет нужды менять маршруты для ping'а.

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

Нет, не вместо скрипта. Если прописать для каждого интерфейса (ip-адреса) свою таблицу со своим default маршрутом, то ping'у указывается ″-I ip-адрес″ и icmp-пакет идут именно через этот интерфейс и нет нужды менять маршруты для ping'а.

Ясно, спасибо.

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

Всё верно, ip rule хороший и подходящий инструмент, глядишь скоро на просторах инета и с ним появится готовое решение ;)

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

А почему нельзя так:

if ping -c 3 -I ${net1} -W 1 ${ip1} 2>&1; then
  result=0
 else
  if ping -c 3 -I ${net1} -W 1 ${ip2} 2>&1; then
    result=0
  else
    if ping -c 3 -I ${net1} -W 1 ${ip3} 2>&1; then
     result=0
    else
     result=1
    fi
  fi
fi

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

Если бы я помнил почему именно так. Толи при определенных условиях с -c возвращал ошибку несмотря на то что хотя бы один пакет пролетал, толи раньше у ping такое поведение было. Это «творение» я написал не позднее 2006-го года.
Сейчас посмотрел наискосок ваш вариант, вроде работает.

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

Если на рутере, то там может не оказаться этого вполне себе толстого curl

Согласен.

А сам скрипт проверяли? :) намек на fn=0 которая будет совсе не 0 уже после |

Если уж на то пошло, то вот так имхо проще

echo -e "GET /ip HTTP/1.1\nHOST:ifconfig.co\nConnection:close\n\n" | nc ifconfig.co 80 | tail -n 1

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

А сам скрипт проверяли? :) намек на fn=0 которая будет совсе не 0 уже после |

Ну для надёжности можно и fn=0;

Если уж на то пошло, то вот так имхо проще

Можно на одном fork+pipe сэкономить, и даже на двух, если надо не только вывести, но и запомнить, извращения без башизмов:

while read line; do
        IP=$line
done << EOF
`echo -e "GET /ip HTTP/1.1\nHOST:ifconfig.co\nConnection:close\n\n" | nc ifconfig.co 80`
EOF

echo $IP

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

Там весь скрипт был без башизмов. Если уж исправлять, то по делу, скажем этот TRY надо бы local.

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

Ну для надёжности можно и fn=0;

[ $fn -eq 1 ]
Вот здесь будет ошибку выдавать в вашем первом варианте. Но можно на вариант текстового сравнения заменить, тогда будет без ошибок [ "$fn" = "1" ]

Можно на одном fork+pipe сэкономить, и даже на двух, если надо не только вывести, но и запомнить, извращения без башизмов:

Так а чем вариант с tail не тоже самое?

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

Вот здесь будет ошибку

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

Так а чем вариант с tail не тоже самое?

Нет, конечно. Я заменил «| tail» на встроенное while read, потому fork+pipe пропадает. А если еще и это надо запомнить в переменную, то пропадает еще один fork+pipe, который у вас был бы в IP=$(вот это всё)

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

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

Можно по подробнее плиз. Реально интересно.

Я заменил «| tail» на встроенное while read, потому fork+pipe пропадает.

Только в этом разница (но не в результате)? Тогда согласен.

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

Можно по подробнее плиз. Реально интересно.

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

но не в результате

Ну так результат тот же самый и делается, просто tail программируется в текущем скрипте на shell-е.

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

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

Эт еще почему? В пайпе она уже не определена. И совсем не 0(ноль)

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

и icmp-пакет идут именно через этот интерфейс и нет нужды менять маршруты для ping'а.

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

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

В пайпе она уже не определена.

Вы натурально не понимаете. Смотрите:

$ fn=0; fn=x env | grep '^fn=' | (read p; echo "pipe1: $p pipe2: fn=$fn")
pipe1: fn=x pipe2: fn=0
Первая команда устанавливает переменную fn для всего скрипта, для любого pipe, но можно сделать как в этом примере — первый pipe имеет свою установку переменной окружения.

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

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

Не знаю чего там добиваются, я пишу конкретно вот про этот кусок скрипта:

    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
Если сделать отдельную таблицу маршрутизации и ip rule, то можно пускать пинг через ens19 без ″route add/route del″ независимо от того, какой сейчас канал используется — основной или резервный.

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

Не знаю чего там добиваются,

Плохо.

независимо от того, какой сейчас канал используется — основной или резервный

Еще раз. Зачем нужен такой резерв, если им нельзя пользоваться (пинги не идут)? А если идут — то невозможно определить когда надо переходить обратно на основной канал.

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

route add $ip1 gw $net1_gw_ip
ping -c3 ...

Ну да, ну да. Типичное тутошнее предложение — по циклу берем и отрубаем себе на 6 секунд раз в минуту доступ как обычно на гугловскую сеть. :)

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

Вот в самом начале же написал, что «бить» и прерывать невостребованные узлы, да хоть на построянку их отрубать )) А 3+3+3 это на всякий пожарный, мало ли.

mky имеет в виду то, что в ip rule прописываются правила, например для ip сервера запросы по списку ip[1-3] идут через основного провайдера, а вот для всех остальных уже в зависимости от активного канала. ip route такой гибкостью не обладает.

Если уж на то пошло, то можно ещё 3 узла для проверки резервного канала допилить с соответствующими правилами и 2 резервный канал намутить для утешения паранойи ))

На самом деле ip rule вариант тоже тестировал, но так и не добился стабильного решения. То одно падало, то второе, в очередной раз это всё окончательно достало, достал «топор» и получился боевой вариант в топике.

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

ip route такой гибкостью не обладает.

Вы так уверенно пишите, как будто мне лекцию читаете. Ладно бы понимали... Смешно же. Вы не поверите, но именно route и делает то что вы хотите — назначает для сетей/хостов маршрут. rule позволяет сделать src-routing или по маркерам. Да да, я это и имел в виду, если вы можете пожертвовать некоторыми хостами для одного из типов канала (основного или запасного) то ip rule тут вообще не нужен.

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

Не доказали.

Вам? И не собирался. А вообще, я с того и начал, что напомнил о своей статье, посвященной этой проблеме.

Чисто route сможете реализовать скрипт

Вы даже не пытаетесь понять технические возражения, а просто спорите наугад. Именно так: route добавляет маршрут на тестовый хост. А ip rule выбирает строку рутинга в зависимости от правила. Что тут не понятно?

без этого куска?

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

И вообще, чего это я бисер мечу...

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

Зачем нужен такой резерв, если им нельзя пользоваться (пинги не идут)?

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

Я вот тут целую статью публиковал на эту тему.

Коментов в новости мало, вы ещё тут желаете похвалы? Ок. «Чугунный утюг в стиле я открываю мир» — стиль тяжёлый, предложения длинные, упор на частный случай, скрипты без названия файлов где они должны лежать, непонятный ″${a}6″. Новички ищут готовое решение, а не полуфабрикат.

Типичное тутошнее предложение

Я приводил кусок скрипта ТС, и в своём первом коменте писал, что это не очень удачное решение. Но, ТС в курсе, и советовал выбирать ip, на которых нет нужных сотрудникам фирмы ресурсов. Поэтому не надо перевирать мою позицию, не надо приплетать «гугловскую сеть».

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

А ip rule выбирает строку рутинга

Не строку, а таблицу. Но вобще вы правы, лучше не мечите бисер.

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

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

Нет. Рутинг про пинг ничего не знает, потому надо определиться, либо вы наворачиваете фильтром метки на трафик от конкретных пингов до конкретного хоста, либо вообще делаете два хоста недоступными для одного и другого каналов соответственно. Вы видели в этих примерах, что тут предлагают эти навороты? Я — нет. Я вижу только магию: примените ip rule и всё заработает. Ну да, ну да.

Новички ищут готовое решение

И что?

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

ip rule может выбирать по src адресу. В скрипте ping'у указывается ″-I ip-адрес″, для этого адреса назначена таблица маршрутизации с default-маршрутом через основной канал и таким образом всегда проверяется осовной канал, независимо от того, что прописано в main таблице маршрутизации. И при этом не нужно наворачивать фильтром метки.

Я вижу только магию: примените ip rule и всё заработает.

Я чётко писал про policy-routing: «Нет, не вместо скрипта». И я рассматриваю исходный скрипт, который простой (примитивный), но понятный ТС.

И что?

То, что новичкам ваша статья не интерестна, нет смысла советовать её ТС'у.

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

В скрипте ping'у указывается ″-I ip-адрес″

Я то не слепой, а вот вы...

И при этом не нужно наворачивать фильтром метки.

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

То, что новичкам ваша статья не интерестна

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

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

Вам жалко ip-адресов? Могу отдать всю сетку 192.168.199.0/24.

Я на них не ориентировался.

Тогда накой вы трясёте той статьёй в этом топике?

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

Вы прочитали что изначально написал mky
?

Если прописать для каждого интерфейса (ip-адреса) свою таблицу со своим default маршрутом, то ping'у указывается ″-I ip-адрес″ и icmp-пакет идут именно через этот интерфейс и нет нужды менять маршруты для ping'а.

Т.е. В таблице main нет defroute. Создали две таблицы для провов. В них прописали defroute. Создали rule вида from $IP_PROV1 table $TB_PROV1. Теперь при ping -I $IP_PROVX 8.8.8.8 в зависимости от $IP_PROVX пойдет или через первого или через второго.

Вы же предлагаете

либо вы наворачиваете фильтром метки на трафик от конкретных пингов до конкретного хоста, либо вообще делаете два хоста недоступными для одного и другого каналов соответственно.

Разницу видим?

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

Я сюда добавлю, что $IP_PROVX может быть вобще любым, не обязательно совпадающем с адресом на интерфейсе к провайдеру. На выходе всё одно лучше «подправлять» адрес SNAT'ом.

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

Вам жалко ip-адресов?

Очень остроумно... Особенно с претензиями на критику содержания статьи.

Тогда накой вы трясёте той статьёй в этом топике?

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

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

На выходе всё одно лучше «подправлять» адрес SNAT'ом.

Зачем?

PS Ну если уж «пошла такая пьянка», это я просто процитировал вас. А вообще достаточно ping -I $IF_NAME

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

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

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

Разницу видим?

А вы? Я то эту разницу и так и сяк уже разжевал, что уже тошно, до последней тупицы должно дойти.

Ну хорошо. Попробую ещё раз. Наилучшим вариантом для проверки является не default по другой таблице, а по метке. Метка ставится фильтром, который отлавливает ICMP на нужный хост (scr не так важен, локальный и достаточно) и метит. Какой хост для этого использовать — это объяснять долго, но эти пространные объяснения сделал я в статье по поводу переключалки.

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

Наилучшим вариантом для проверки является не default по другой таблице, а по метке. Метка ставится фильтром, который отлавливает ICMP на нужный хост (scr не так важен, локальный и достаточно) и метит.

Можно без отсылки к статьи, почему это «наилучший вариант» ? Точнее в чем недостаток предложенного mky ?

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

Можно без отсылки к статьи, почему это «наилучший вариант» ?

Я не говорил, что объяснение «лучшести» там вообще было.

А почему мне не нравится ваши варианты, я тут, именно в этом топике раз 5 сказал. Потому что рутингу пофиг icmp это или tcp. Вы можете полностью оставить возможность работы со всеми хостами, по всем протоколам. Ведь правило установки метки можно сделать не только по протоколу icmp, а даже по содержимому наполнения этих icmp-пакетов. Это то точно 99.(9)% будет гарантировать что ничему не помешает.

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

Но когда вам нужно будет вручную понять, что не так с основным канало при активном резервном, ваши фильтры, ставящие метки, будут неудобны. Консольные утилиты (ping, telnet, dig и пр.) позволяют задать src-адрес, поэтому, назначив, что от 192.168.199.1 идёт в основной канал, а от 192.168.199.2 идёт в резерный, можно спокойно вручную изучать что с каналами, указывая адрес в командной строке, не добавля что-то в iptables.

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