Доброго времени суток Всем Есть задача организовать l2 туннель между офисом и датацентром Датацентр один статический белый IP Офис - Основной канал статический белый IP - Резервный канал - роутер со стабильным внутренним IP в роли шлюза второго канала с модемом - серый динамический IP с неизвестным видом тунеля и пробросами и ограничениями от провайдера телефонии (Tele2) На сейчас - работает IPIP+IPsec +EoIP поверх между основным каналом и датацентром - все стабильно и без проблем т.к. оба IP белые и стационарные Пробовал поднять для резервного канала SSTP соединение - SSTPсервер на стороне датацентра - и SSTP клиент на стороне офиса через резервный канал (и через него в дальнейшем поднимать EoIP и далее по схеме) - с одного канала схема работает и переключение меня устраивает (Оба EoIP тунеля включены в бриджи и на обоих сторонах включен RSTP и для резервного туннеля выбрана Path-Cost больше чем для основного, т.е резервирование и переключение каналов возложено на L2 и RSTP) При реализации Multi Wan опирался на то, что было изложено в докладе Ильи Князева пинги по каналам для проверки ходят как и ожидается с одного канала на один с другого на другой, при отключения канала в основную таблицу роутинга не уходят, разделение доступа куда для проверки пускать трафик работает через /ip Route Rules Все хорошо когда адреса разные НО для SSTP у которого я не могу управлять адресом источника эта метода не работает я не могу в Rules по получателю переключить работу на резервный канал т.к это затронет и основной канал у которого тот же адрес получателя пакетов. Какие меры воздействия есть на выбор канала с которого будут уходить запросы из системных процессов (к которым относится туннель SSTP клиента ) ? я осознаю что в пиковом случае можно запросить у датацентра еще один адрес и пустить резервный канал на него и в route-rules прописать маршрут к нему на который сработает SSTP клиент - НО хотелось обойтись без доп. расходов и телодвижений на стороне датацентра и в другом месте где нужна схожая схема работы такой опции у меня нет ... Пробовал управлять через Mangle в цепочке Output маркировать соединение как ISP2 в таблице установленных соединений канал числится с маркировкой ISP2 но адрес с которого он поднимается - адрес основного канала Эпизодически по непонятной мне схеме ситуация меняется и канал поднимается с резервого канала и маркировкой ISP2 Но потом меняется снова на основной канал Стабильности Нет ... и это проблема (не микротика а моя ... )
Т.к. никто не смог помочь с ответом на вопрос опишу то, чего удалось добиться самому вдруг кому-то этот опыт окажется полезным Добиться предсказуемого и управляемого поведения от туннеля SSTP мне не удалось, несмотря на все мои попытки управлять процессом установления связи, маршрут строился на базе основной таблицы маршрутизации и с использованием маршрута по умолчанию что в моем случае не подходило (нужно было чтоб SSTP клиент выходил в мир с адреса резервного канала всегда - НЕ Удалось) Для решения рабочего вопроса заказал у провайдера в датацентрре еще один IP который оказался в том-же диапазоне адресов рядом с основным каналом и шлюз по умолчанию для обоих адресов один и тот-же - что сильно упростило задачу. 1. Просто добавил на микротик в датацентре на внешний интерфейс еще один адрес (задача - принимать тунель SSTP на этом адресе и более ничего) 2. На офисном микротике перестроил тунель SSTP на новый адрес 3. В разделе Route Rules добавил правило указывающее в явном виде что общение с этим IP только через резервный канал (LookUP - in This Table Only- toISP2) Это правило запрещает общение с адресом для установки туннеля всем кроме резервного канала, блокируя использование для этого основной таблицы маршрутизации) Итого - между офисом и датацентром поднято 2 туннеля (IPIP+IPSec - через ISP1) и (SSTP- черезISP2) каждый может ходить в датацентр только через своего провайдера интернета 4. Поверх туннелей подняты EoIP туннели и оба туннеля заведены в бридж вместе с локальной сетью датацентра и локальной сетью офиса Оба туннеля в сущности образуют Ehternet петлю т.к. оба начинаются и заканчиваются в одних и тех же бриджах и между бриджами образуется 2 независимых маршрута что не есть правильно и грозит проблемой 5. Для того чтоб управлять петлей из двух EoIP туннелей в бриджах были изменены настройки и включен механизм RSTP 5.1 чтоб оба бриджа не боролись друг с другом за право главенствования - тот что в датацентре был директивно(мной) назначен главным из двух для этого был уменьшен показатель Priority c 8000-> 7000 Hex выбор главного у того у кого меньший показатель из обоих 5.2 Чтоб указать какой из маршрутов для меня является основным а какой резервным я так-же поменял на резервном туннеле в разделе Bridge-Ports PRIORITY с 80 на 90 HEX PathCost с 10 на 20 HEX Internal Path Cost с 10 на 20 HEX сделал это на обоих маршрутизаторах в офисе и датацентре После этих манипуляций трафик приоритетно ходит через EoIP туннель построенный по основному маршруту и при отключении очень быстро перестраивается на резервный маршрут т.к. оба туннеля подняты одновременно то при падении только одного из провайдеров (например основного ) в работу вступает уже поднятый туннель через резервного а время переключения RSTP позволяет потерять не более 1 пинга на переключении маршрута канала что по тестам пока вполне устраивает меня (как эта схема покажет себя в реальной работе - узнаю позже) После восстановления основного канала - сначала восстанавливается маршрутизация и трафик через основной канал из офиса, затем поднимаются туннели IPIP затем EoIP ( Но все время, пока все оживает и включается, пока не поднимется EoIP туннель основного канала, трафик спокойно без перерыва идет через резервный туннель не обрывая сеанса, затем RSTP быстро обнаруживает петлю и переключает работу с резервного EoIP на основной вот тут и теряется 1-2 пинга что приемлемо для моих задач)
