Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • 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
    Таймеры отслеживания соединений брандмауэра

    Таймеры отслеживания соединений брандмауэра

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Таймеры отслеживания соединений брандмауэра, RouterOS
     
    pe1chl
    Guest
    #1
    0
    01.07.2015 10:46:00
    У меня типичная настройка файрвола для преимущественно исходящего трафика: есть правило форвардинга, которое разрешает трафик с состоянием соединения Established, Related, и правило, разрешающее исходящий трафик из моей локальной сети (трафик пересылается через VPN). Когда я смотрю страницу Connections в IP Firewall, вижу, что таймер отсчёта снижается до нуля даже при наличии соответствующего трафика.

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

    Так как у меня стоит логирование для финального правила drop, я вижу эти записи в логе. Если же исходящего трафика нет (например, TCP keepalive или просто нажатие клавиши), другая сторона будет пытаться повторить отправку, а потом со временем закроет сессию.

    Это нормальное поведение? Я бы ожидал, что таймер будет сбрасываться на настроенное значение каждый раз, когда по правилу Established, Related проходит трафик, чтобы он никогда не досчитывал до нуля при периодическом трафике в пределах максимального таймаута.

    Можно ли настроить такое поведение на роутере MikroTik и, возможно, есть какая-то настройка для этого?
     
     
     
    pe1chl
    Guest
    #2
    0
    18.07.2015 07:17:00
    После этого я вернул таймаут к одному дню, как было по умолчанию, но на самом деле это лишь немного скрывает настоящую проблему. Я всё ещё иногда теряю ssh-соединения, просто реже. Как можно исправить коренную причину этой проблемы? (Мне кажется, таймеры должны сбрасываться при наличии трафика, чтобы отсчитывать только время бездействия, а не время самой сессии.)
     
     
     
    pukkita
    Guest
    #3
    0
    18.07.2015 10:50:00
    Можешь сделать скриншот этих подключений? Они отображаются как tcp со статусом established и conntrack со статусом Unreplied?
     
     
     
    pe1chl
    Guest
    #4
    0
    18.07.2015 20:24:00
    Они находятся в состоянии TCP established, и статус conntrack — «assured - not unreplied». Это длительные соединения с периодическим трафиком. Проблема, конечно, незаметна для обычного пользователя, который просто сидит в интернете и занимается обычным серфингом. Те же соединения проходят через другой файрвол дальше по сети — там обычная Debian Linux-машина. Когда я выполняю «conntrack -L» на той системе, я вижу такую же информацию и таймер, но когда через одну из сессий проходит трафик, я замечаю, что таймер на той машине поднимается до максимума, а счётчик на MikroTik, наоборот, идёт вниз.
     
     
     
    docmarius
    Guest
    #5
    0
    18.07.2015 20:26:00
    Возможно, эта проблема связана: http://forum.mikrotik.com/t/connection-tracking-counters-wrong/85622/1
     
     
     
    pe1chl
    Guest
    #6
    0
    18.07.2015 20:33:00
    Что ж, согласно протоколам и адресам, которые я вижу, мы на одной и той же сети. Однако то, что я наблюдаю, немного другое. Я не вижу случаев, когда таймеры идут вверх. То, что я вижу, — это временная блокировка в одном направлении, пока не пойдет трафик в противоположную сторону, что соответствует наличию правила ESTABLISHED, RELATED в обоих направлениях и правила NEW в исходящем направлении.
     
     
     
    pe1chl
    Guest
    #7
    0
    19.07.2015 06:55:00
    Интересно, но после того, как я разделил одно правило переадресации с флагами ESTABLISHED и RELATED на два отдельных — одно с ESTABLISHED, другое с RELATED — проблемы перестали появляться. Я заметил, что это настройки по умолчанию в MikroTik и хотел вернуться максимально к стандартным настройкам. Обычно я объединяю эти два флага в одно правило, как всегда делаю в Linux-файрволах и как многие делают без проблем, но, похоже, в MikroTik RouterOS есть что-то особенное, из-за чего при такой комбинации возникают проблемы с таймерами…
     
     
     
    pukkita
    Guest
    #8
    0
    20.07.2015 19:02:00
    Ммм, возможно, выбор обеих опций означает «применять к тем соединениям, которые находятся в состоянии ESTABLISHED И ПРИ ЭТОМ связаны»? Ты видишь соединения в состоянии tcp ESTABLISHED, но с conntrack в состоянии Unreplied?
     
     
     
    jarda
    Guest
    #9
    0
    20.07.2015 20:05:00
    Ой. Я использую устоявшиеся, связанные правила как одно единственное, а не два, как в последних версиях, потому что понял, что оператор отношения состояния tcp — это «ИЛИ». Значит, это неверно?
     
     
     
    pe1chl
    Guest
    #10
    0
    21.07.2015 17:04:00
    Я тоже думаю, что проверка и ESTABLISHED, и RELATED означает «ИЛИ», но в стандартной конфигурации MikroTik это отдельные правила. Может быть, по какой-то причине… я не знаю.
     
     
     
    jarda
    Guest
    #11
    0
    21.07.2015 17:11:00
    Возможно, потому что стандартная конфигурация применима к более старым версиям, где использование нескольких состояний tcp в одном правиле было невозможно. К сожалению, документация не освещает этот момент. Её стоило бы обновить.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры