Резервирование каналов передачи и уведомление пользователей о переключении на резевного провайдера

Резервирование каналов передачи и уведомление пользователей о переключении на резевного провайдера, Андрей Сычев (www.mikrotik.net.ua, Украина). Доклад основан на реальном пректе, а именно есть несколько удаленных офисов
имеющих два подключения - проводное и через 3G модем.
При работе основного провайдера пользователи имеют выход в Интернет и доступ к
базе данных в центральном офисе через SSTP туннель.
Для проверки работоспособности провайдеров используется check-gateway хоста в
Интернет через recurcive next-hop.
При падении основного канала происходит перестроение туннеля через 3G модем, но
при этом скорость ниже и доступ в Интернет не предоставляется. Пользователи
начинают нервничать и звонить в техподдержку, это напрягает и я сделал
следующее - настроил web-proxy и завернул трафик с помощью redirect на него.
Теперь пользователь при обращении на веб страницу переадресовывается на
страницу с информацией о том что у нас технические проблемы, мы их решаем, но
работать с базой данных и звонить по телефону можно, для особо нетерпеливых
есть телефон техподдержки провайдера и инструкция что им говорить.
При восстановлении канала все возвращается обратно. В результате имеем снижение
непродуктивных обращений в техподдержку.
В конце расскажу как отлаживать такую систему фильтруя ICMP запросы к тестовым
хостам в таблице output.
Если это сильно просто и обрыв связи на 20-30 секунд критичен, можно построить
два туннеля через основного и резервного провайдера и балансировать трафик с
помощью OSPF или средствами статической маршрутизации.
. PDF: mum.mikrotik.co....

[@kprohorow]

Ситуация на 5:00 так знакома ...

[@abrakadabra99able]

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

[@vkhasper148]

как вы собираетесь делать редирект с 443 порта ?

[@ЮраДулебо]

А зачем редиректить с 443? Достаточно только 80. Все что по 443 просто не работает.