Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    VRRP и переключение на резервного интернет-провайдера?

    VRRP и переключение на резервного интернет-провайдера?

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    VRRP и переключение на резервного интернет-провайдера?, RouterOS
     
    mhenriques
    Guest
    #1
    0
    04.12.2021 21:37:00
    Привет, ребята! Меня попросили добавить второй Mikrotik в качестве шлюза для обеих внутренних LAN, используя и VRRP, и резервирование ISP, согласно сетевой схеме ниже. Есть советы, как это реализовать? Спасибо за любую помощь. Маурицио
     
     
     
    mhenriques
    Guest
    #2
    0
    19.01.2022 17:23:00
    Я тестирую описанный ниже сценарий с помощью GNS3, и, похоже, всё работает. Есть какие-нибудь комментарии перед проверкой в реальных условиях? Спасибо за вашу помощь. Mauricio
     
     
     
    ConnyMercier
    Guest
    #3
    0
    20.01.2022 13:13:00
    Всё, кажется, в порядке! Удачи =)
     
     
     
    alexv305
    Guest
    #4
    0
    09.02.2024 21:41:00
    Дорогая ConnyMercier, этот небольшой гайд помог мне настроить VRRP, спасибо за это. Но у меня странная проблема. В любом направлении — от Router A к Router B или от Router B к Router A — во время переключения отказа правило фаервола, которое сбрасывает пакеты со статусом INVALID в цепочке forward, блокирует прохождение трафика. Я могу пинговать любые IP в интернете, но когда пытаюсь что-то открыть в браузере, в логах фаервола вижу, как грузятся записи об сбросе INVALID-пакетов. Как только отключаю это правило, переключение отказа работает идеально в любом направлении. Есть идеи, что может быть причиной? Вот правило фаервола: /ip firewall filter add action=drop chain=forward connection-state=invalid
     
     
     
    sindy
    Guest
    #5
    0
    10.02.2024 08:51:00
    Отвечу, хотя я явно не @ConnyMercier. Stateful firewall отслеживает состояние соединений по нескольким причинам — чтобы большинство пакетов проходили через минимальный набор правил фаервола, чтобы обеспечить NAT и так далее. Если синхронизация состояния соединений не была активирована в настройках VRRP (а это возможно только в RouterOS 7), то модуль отслеживания соединений на фаерволе в маршрутизаторе, через который изначально было установлено соединение, — единственный, кто знает об этом соединении. Поэтому, если трафик начнёт идти через другой роутер, пакеты на нём не будут распознаны как часть существующего соединения.

    В случае UDP, где в заголовках протокола нет информации о состоянии соединения, пакет, не принадлежащий ни одному существующему соединению, воспринимается как начальный пакет нового соединения и обрабатывается соответственно. В случае TCP, заголовки TCP содержат информацию, позволяющую определить роль пакета в соединении. Только пакет с флагом SYN и без флага ACK может создать новое отслеживаемое соединение в фаерволе (по крайней мере, если включена строгая проверка заголовков TCP). Другие TCP-пакеты, не относящиеся к существующим соединениям, маркируются как connection-state invalid. Таким образом, отключая это правило, вы даёте возможность существующим TCP-сессиям пережить переключение VRRP, но одновременно открываете дорогу некоторым TCP-атакам (предполагаю, что то же самое относится к SCTP, хотя он довольно редко используется в интернете).

    Так что первый вопрос — используете ли вы RouterOS 7 на обоих физических маршрутизаторах и, если да, активирована ли синхронизация отслеживания соединений с активного на резервный.
     
     
     
    alexv305
    Guest
    #6
    0
    10.02.2024 17:53:00
    Я включил отслеживание соединений на интерфейсе VRRP1 у RTR1. Ситуация повторяется: когда у RTR1 основной маршрут по умолчанию переключается на резервный (то есть на RTR2), правило drop INVALID на RTR1 блокирует трафик к RTR2. Если отключить правило drop INVALID на RTR1, трафик идет как надо.
     
     
     
    sindy
    Guest
    #7
    0
    13.02.2024 07:33:00
    Тем временем я тоже попробовал — запустил 7.13.4 на паре CHR и получил те же результаты (да еще, как и несколько месяцев назад, роутер, работающий в роли VRRP master, грузит процессор на 100%). Значит, с этой функцией всё еще есть проблемы — если хотите использовать её в продакшене, открывайте заявку в поддержку Mikrotik и следуйте их инструкциям (первым требованием будет предоставить supout.rif с обеих машин). Дальше обсуждать это на форуме бесполезно. Да, по причинам и с недостатками, описанными раньше. Боюсь, обходных путей, которые не снижали бы защиту от TCP-спуфинга — а именно для этого и нужна правило “drop invalid”, — не существует.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры