Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • 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
    Удаляем не ответившие TCP-соединения.

    Удаляем не ответившие TCP-соединения.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Удаляем не ответившие TCP-соединения., RouterOS
     
    wirelesswaves
    Guest
    #1
    0
    22.12.2013 10:40:00
    Кто-нибудь уже писал скрипт для периодического удаления не отвечавших подключений из таблицы отслеживания брандмауэра? За последние несколько месяцев я заметил увеличение этой проблемы, сегодня уже более 2500 неотвечавших подключений. И хотя поначалу они могут казаться безобидными, они постоянно мешают установлению новых подключений, пока остаются в таблице.
     
     
     
    adairw
    Guest
    #2
    0
    22.12.2013 21:49:00
    Ты отбрасываешь невалидные соединения в цепочках ввода и вывода? Какая у тебя конфигурация файрвола? Отправлено с моего SCH-I545 через Tapatalk.
     
     
     
    wirelesswaves
    Guest
    #3
    0
    30.12.2013 09:36:00
    Кто-нибудь? Нужна помощь с скриптом, который должен запускаться каждые 5 минут и удалять из таблицы отслеживания все соединения, соответствующие следующим критериям: 1: tcp+(!SA)+(!local network ip’s)+established, где !SA = assured. Или, может, это просто невозможно сделать!
     
     
     
    wirelesswaves
    Guest
    #4
    0
    30.12.2013 11:15:00
    Черт возьми! Не можем ли мы использовать флаги “unreplied” или “!assured”?
     
     
     
    ditonet
    Guest
    #5
    0
    30.12.2013 17:01:00
    Просто из любопытства: почему вы хотите разорвать сложившиеся связи?

    С уважением,
     
     
     
    wirelesswaves
    Guest
    #6
    0
    31.12.2013 09:48:00
    Это происходит периодически, обычно после ночи интенсивного p2p-трафика… Таблица отслеживания соединений разрастается до 5000 соединений, и 4000 из них — “не ответили”. Меня бы это не беспокоило, но кажется, что это связано с жалобами клиентов в течение 24 часов после этого (пока соединения не упадут), когда некоторые телефонные линии кажутся "мёртвыми". Это небольшая проблема, но раздражающая. Те клиенты, на которых это влияет, часто перезагружают свои VoIP ATA-устройства, и тогда ATA восстанавливает SIP-взаимодействие. Мне интересно, почему TCP-соединение может отображаться как "установленное" в таблице отслеживания соединений, но при этом оставаться "не ответившим". Именно эти случайные необъяснимые "не ответившие" соединения, похоже, занимают "пространство портов" и мешают некоторым SIP-взаимодействиям. К сожалению, похоже, что флаг "не ответивший" нельзя использовать в скрипте для периодической очистки этих гадов. Голосую за то, чтобы в версии 7 появилась эта опция.
     
     
     
    ditonet
    Guest
    #7
    0
    31.12.2013 10:29:00
    Попробовали уменьшить TCP SYN-таймауты в настройках conntrack? С уважением,
     
     
     
    wirelesswaves
    Guest
    #8
    0
    31.12.2013 10:55:00
    Да. Разницы никакой.
     
     
     
    ditonet
    Guest
    #9
    0
    31.12.2013 12:02:00
    Поделитесь, пожалуйста, настройками conntrack. Какое максимальное значение параметра 'timeout' для неотвеченных соединений показывает Winbox? С уважением,
     
     
     
    wirelesswaves
    Guest
    #10
    0
    31.12.2013 13:09:00
    v5.25, оказывается, не имеет настройки для тайм-аута для "неотвеченных"!
     
     
     
    ditonet
    Guest
    #11
    0
    31.12.2013 15:27:00
    Я спрашивал насчет отображенных значений:

    С уважением,
     
     
     
    wirelesswaves
    Guest
    #12
    0
    31.12.2013 15:57:00
    Сейчас что-то между 30 минут и 23:40. Забавно, но мой фильтр работает наоборот. Мне приходится фильтровать> Неотвеченные сообщения – нет… не да, как следовало бы!
     
     
     
    ditonet
    Guest
    #13
    0
    31.12.2013 17:42:00
    Эта ошибка была исправлена год назад, в ROS v.6.0rc6, если я правильно помню. Выложи свои настройки conntrack: /ip firewall connection tracking export.

    С уважением,
     
     
     
    wirelesswaves
    Guest
    #14
    0
    31.12.2013 17:51:00
    Они снова вернулись к настройкам по умолчанию. Вы забыли, что это "установленные" TCP-соединения со стандартным временем ожидания в 1 день? Они прошли протокол четырехстороннего рукопожатия, но остаются "без ответа". Я не вижу, как какие-либо изменения значений отслеживания могут что-то изменить, не затронув при этом гарантированно установленные соединения.
     
     
     
    ditonet
    Guest
    #15
    0
    31.12.2013 18:34:00
    Уменьшите ‘tcp-established-timeout’ до 5 минут.

    С уважением,

    P.S. Я иду на новогоднюю вечеринку.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры