Резервный канал по LTE

Обсуждение оборудования и его настройки
xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Erik_U писал(а): 26 авг 2020, 15:54 Если есть 2 оператора на 2-х разных микротиках - то есть и 2 фаервола, 2 ната. Откуда могут быть проблемы с фаерволами?
Вот именно что их два, и при асимметричном роутинге (а оно так и получится, шлюз то у клиентов не изменится), один из firewall'ов начнет откидывать пакеты как invalid, например при доступе снаружи (был недавно похожий случай на офф форуме).
В данных условиях этого наверное не произойдет, но тем не менее лучше все изначально делать future-proof and fool-proof.
Erik_U писал(а): 26 авг 2020, 15:54 Между микротиками - локальная сеть. Ее бить на подсети нет необходимости. Через эту одинаковую сеть микротики в один инстанс OSPF соберутся.
В свойствах инстанса OSPF есть строка Redistribute Default Route, и значение "всегда", или "когда активен".
На интерфейсы в сторону операторов (или dhcp клиенты на них) полезно поставить Add Default Route с разными Distance, чтобы дефолтный маршрут падал вместе с интерфейсом. И поднимался вместе с ним, что тут же отражалось бы в OSPF. Включать Keepalive Timeout, где он есть тоже полезно.
Но если интерфейс не падает, а просто деградирует, то у OSPF логика подразумавает в случае неполучения ASK отправлять пакет другим маршрутом.
Это все понятно.
Вопроса как передать по OSPF дефолтный маршрут нет.
Только деградировать то будет не связь между двумя роутерами инстанса.
А шлюз провайдера будет доступен, дефолтный маршрут через провайдера будет доступен, но где-то дальше у провайдера будет какая-то засада. А тот маршрут, который получен по OSPF, так и будет висеть неактивным.
Я об этом.
Использование OSPF никак не избавляет от необходимости держать netwatch, пингующий гугл, или какой-то другой механизм, чтобы мониторить именно основной канал.


Telegram: @thexvo
Erik_U
Сообщения: 1752
Зарегистрирован: 09 июл 2014, 12:33

xvo писал(а): 26 авг 2020, 16:17
Erik_U писал(а): 26 авг 2020, 15:54 Если есть 2 оператора на 2-х разных микротиках - то есть и 2 фаервола, 2 ната. Откуда могут быть проблемы с фаерволами?
Вот именно что их два, и при асимметричном роутинге (а оно так и получится, шлюз то у клиентов не изменится), один из firewall'ов начнет откидывать пакеты как invalid, например при доступе снаружи (был недавно похожий случай на офф форуме).
В данных условиях этого наверное не произойдет, но тем не менее лучше все изначально делать future-proof and fool-proof.
Клиенты - внутри.
Они идут через один маршрут, и соответственно через один фаервол, пока их оспф не переключит на другой. Как переключит - пойдут через другой.
У разных микротиков у разных операторов разные IP. Поэтому канал, установленный через одного на второй никак не перебросится. На втором будет новый канал с целью взаимодействия.


Erik_U
Сообщения: 1752
Зарегистрирован: 09 июл 2014, 12:33

xvo писал(а): 26 авг 2020, 16:17 Только деградировать то будет не связь между двумя роутерами инстанса.
А шлюз провайдера будет доступен, дефолтный маршрут через провайдера будет доступен, но где-то дальше у провайдера будет какая-то засада. А тот маршрут, который получен по OSPF, так и будет висеть неактивным.
Я об этом.
Использование OSPF никак не избавляет от необходимости держать netwatch, пингующий гугл, или какой-то другой механизм, чтобы мониторить именно основной канал.
Насколько я помню, ospf следит за получением ask от dst.
У меня проблем нет, которые вы описываете. Никаких нетвачей не требуется.

ps. похоже наврал. Не следит он за ask от dst.
Последний раз редактировалось Erik_U 26 авг 2020, 16:36, всего редактировалось 1 раз.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Erik_U писал(а): 26 авг 2020, 16:27 Клиенты - внутри.
Они идут через один маршрут, и соответственно через один фаервол, пока их оспф не переключит на другой. Как переключит - пойдут через другой.
Вот тут вы не правы. Клиенты про OSPF ничего не знают. И про то, какой у роутера дефолтный маршрут активен тоже. У них есть шлюз по-умолчанию и все.

Так что получится такая ситуация: при падении основного канала, клиенты будут продолжать слать пакеты на свой шлюз (микротик1), тот будет слать их на микротик2, тот наружу. Обратный пакет будет приходить на микротик2, но тот будет слать их напрямую клиентам - они же в одной подсети.
И вот этот треугольник - потенциальное место словить тяжело диагностируемые проблемы - ведь firewall микротика1 вообще не видит обратных пакетов.
Можно гадать, где и в какой момент это что-то сломает (или не сломает), а можно вынести маршрутизаторы в свою подсеть, клиентов в свою, и быть спокойным.
Последний раз редактировалось xvo 26 авг 2020, 16:40, всего редактировалось 2 раза.


Telegram: @thexvo
xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Erik_U писал(а): 26 авг 2020, 16:30 Насколько я помню, ospf следит за получением ask от dst.
У меня проблем нет, которые вы описываете. Никаких нетвачей не требуется.

ps. похоже наврал. Не следит он за ask от dst.
Ни за чем в сторону провайдера он следить не может - для него это вообще external маршрут, который он просто забирает из основной таблицы, если его об этом попросить.


Telegram: @thexvo
Erik_U
Сообщения: 1752
Зарегистрирован: 09 июл 2014, 12:33

xvo писал(а): 26 авг 2020, 16:36
Erik_U писал(а): 26 авг 2020, 16:27 Клиенты - внутри.
Они идут через один маршрут, и соответственно через один фаервол, пока их оспф не переключит на другой. Как переключит - пойдут через другой.
Вот тут вы не правы. Клиенты про OSPF ничего не знают. И про то, какой у роутера дефолтный маршрут активен тоже. У них есть шлюз по-умолчанию и все.

Так что получится такая ситуация: при падении основного канала, клиенты будут продолжать слать пакеты на свой шлюз (микротик1), тот будет слать их на микротик2, тот наружу. Обратный пакет будет приходить на микротик2, но тот будет слать их напрямую клиентам - они же в одной подсети.
И вот этот треугольник - потенциальное место словить тяжело диагностируемые проблемы - ведь firewall микротика1 вообще не видит обратных пакетов.
Можно гадать, где и в какой момент это что-то сломает (или не сломает), а можно вынести маршрутизаторы в свою подсеть, клиентов в свою, и быть спокойным.
шлюз по умолчанию у клиента - это микротик.
Который передает пакет дальше уже в соответствии с настройкой своей маршрутизации. Если это OSPF, то по таблице OSPF. И в описываемом вами случае делается редирект пакетов между микротиками, и фаервол первого ничего не ждет, потому, что запросов наружу не посылал.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Erik_U писал(а): 26 авг 2020, 16:51 И в описываемом вами случае делается редирект пакетов между микротиками, и фаервол первого ничего не ждет, потому, что запросов наружу не посылал.
Происходит стандартный IP forwarding. Тот факт, что следующий роутер находится в той же подсети, что и изначальный клиент, на этом этапе роли не играет. Ethernet-фрейм все равно разбирается (потому как предназначен микротику1) и лежащий внутри него пакет проходит через firewall. И уже после пакуется в новый фрейм уже в сторону микротика2.

В общем не охота придумывать тот гипотетический сценарий, который данная схема точно сломает. И спорить тоже не хочется: я сразу сказал, что в данном случае оно как-то работать будет, и скорее всего никто никогда никаких проблем из-за этого не увидит. Да, возможно соединения не будут помечаться, как established, и каждый пакет будет прогоняться через весь firewall, в том числе мимо fasttrack'а. Но речь про резервный канал - who cares.

Тем не менее, в более сложных сетях так лучше не делать.


Telegram: @thexvo
Erik_U
Сообщения: 1752
Зарегистрирован: 09 июл 2014, 12:33

Мне тоже не хочется спорить. У меня эта схема несколько лет уже работает. Претензии только к версиям ROS ветки stable. Через раз все переставало работать. Перешел на Long-Term и все ок.


Ответить