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

    Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?).

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?)., RouterOS
     
    MagicMicky
    Guest
    #1
    0
    17.07.2022 16:48:00
    Привет! Недавно я переехал и после настройки сети заметил, что у меня отбрасывается много трафика, который, кажется, вполне легитимный. Когда я работал с моим mikrotik hap ac2 (перерабатывал VLANы), добавил правила логирования для отбрасываемого трафика. В логах я увидел несколько моментов, которые заставляют задуматься, всё ли в порядке с моим устройством и/или настройкой.

    Моя сеть состоит из нескольких VLANов, которые роутятся в интернет через mikrotik с NAT. Mikrotik подключён к интернету через PPPoE, используя оптоволоконный модем Telekom (немецкий оператор).

    В основном я вижу следующие вещи:

    **Dropped Input SYN from INPUT**  
    Это, скорее всего, нормально. Думаю, это просто сканеры, вот примеры:  
    [input] input: in:telekom-pppoe out:(unknown 0), proto TCP (SYN), 14.135.120.222:53950->my.public.ip:195, len 52
    [input] input: in:telekom-pppoe out:(unknown 0), proto TCP (SYN), 193.201.8.121:42141->my.public.ip:6392, len 44

    **Dropped ACK,FIN или ACK,FIN,PSH from INPUT**  
    Это объяснить не могу. Кажется, что всегда приходит от легитимного трафика (google, amazon…), но похоже, что роутер «забыл», кому нужно отправить эти пакеты?  
    [input] input: in:telekom-pppoe out:(unknown 0), src-mac ec:13:db:77:aa:6b, proto TCP (ACK,FIN,PSH), 35.190.80.1:443->my.public.ip:57053, len 181
    [input] input: in:telekom-pppoe out:(unknown 0), src-mac ec:13:db:77:aa:6b, proto TCP (ACK,FIN,PSH), 3.67.35.217:443->my.public.ip:57046, len 154
    [input] input: in:telekom-pppoe out:(unknown 0), src-mac ec:13:db:77:aa:6b, proto TCP (ACK,FIN), 172.217.19.67:80->my.public.ip:57048, len 52
    [input] input: in:telekom-pppoe out:(unknown 0), src-mac ec:13:db:77:aa:6b, proto TCP (ACK,FIN,PSH), 8.8.8.8:443->my.public.ip:57047, len 181
    [input] input: in:telekom-pppoe out:(unknown 0), src-mac ec:13:db:77:aa:6b, proto TCP (ACK,FIN), 172.217.16.78:80->my.public.ip:57029, len 52

    **Invalid RST, ACK,RST или ACK,FIN на Forward**  
    Похоже, что иногда я отбрасываю на форварде трафик, который роутер считает некорректным. Это RST-пакеты и ACK,FIN, судя по всему. Иногда между VLANами, иногда — нет.  
    [invalid] forward: in:Trusted VLAN out:telekom-pppoe, src-mac b0:e5:f9:bc:c1:96, proto TCP (ACK,FIN), 10.42.10.17:51793->172.217.16.74:443, len 52
    [invalid] forward: in:Homelab VLAN - 30 out:IoT VLAN, src-mac 00:42:cb:e4:66:f4, proto TCP (RST), 10.42.30.11:43546->10.42.20.13:8443, len 40
    [invalid] forward: in:Trusted VLAN out:telekom-pppoe, src-mac b0:e5:f9:bc:c1:96, proto TCP (RST), 10.42.10.17:60856->92.122.77.247:443, len 40
    [invalid] forward: in:Trusted VLAN out:telekom-pppoe, src-mac b0:e5:f9:bc:c1:96, proto TCP (ACK,RST), 10.42.10.17:51750->142.250.147.188:5228, len 40

    В целом, похоже, что это в основном FIN и RST пакеты, поэтому предполагаю, что их отбрасывание — не проблема, что это результат либо конфигурации, либо самого устройства, оптимизирующего нагрузку на процессор, чтобы раньше очищать соединения из таблицы состояния, и поэтому не получается сделать NAT обратно к источнику. Но это всё равно не объясняет «некорректные» пакеты между VLANами.

    Кто-нибудь может лучше объяснить, почему эти пакеты отбрасываются? Это нормальное поведение? Может ли это вызвать проблемы в моей сети?

    Спасибо,  
    Mickael

    cleaned_router.rsc (20.4 KB)
     
     
     
    ishanjain
    Guest
    #2
    0
    31.07.2022 18:49:00
    Привет, поднимаю эту тему. У меня наблюдаются похожие проблемы. Пакеты с флагами ACK, PSH, ACK,RST, ACK,FIN, PSH и RST просто отбрасываются. По прочитанным здесь же другим темам я понял, что mikrotik (или, может, linux?) стирает таблицу соединений, когда получает пакет с установленным флагом FIN. В TCP некоторые устройства посылают FIN,ACK, а Windows, например, иногда отправляет RST для закрытия соединения и так далее. Поскольку Mikrotik удаляет соединение из таблицы при первом же таком пакете, все последующие пакеты считаются недействительными. Я увеличил время закрытия соединения (close wait) до 30 секунд, но проблема всё равно часто повторяется. Не знаю, может, я что-то упускаю? Мне кажется, что Mikrotik должен корректно обрабатывать это, пропуская пакеты с RST, ACK,RST и FIN,ACK. Но как бы я ни пытался понять, откуда берётся ошибка с пакетом ACK,PSH — никак не могу. В логах постоянно вижу вот такое: ipv4-invalid forward: in:vlan-20 out:pppoe-out1, connection-state:invalid src-mac 08:25:25:x:y:z, proto TCP (ACK,PSH), 10.0.20.23:38530->45.248.24.18:443, len 688.
     
     
     
    tdw
    Guest
    #3
    0
    31.07.2022 19:23:00
    См. http://forum.mikrotik.com/t/nat-only-nating-99-of-packets/158358/5  

    Dropped Input SYN from INPUT — скорее всего, это нормально. По моим догадкам, это в основном сканеры, например:  
    input: in:telekom-pppoe out:(unknown 0), proto TCP (SYN), 14.135.120.222:53950->my.public.ip:195, len 52  
    input: in:telekom-pppoe out:(unknown 0), proto TCP (SYN), 193.201.8.121:42141->my.public.ip:6392, len 44  

    Да, поскольку это цепочка input, а не forward, такие пакеты адресованы самому Mikrotik.
     
     
     
    sindy
    Guest
    #4
    0
    01.08.2022 05:15:00
    Возможных причин несколько, и для точного выяснения придётся провести анализ трафика с помощью пакетного сниффера. Во-первых, протокол TCP не требует, чтобы после отправки одним из участников FIN другой сразу же отвечал FIN — передача данных может продолжаться в одном направлении, когда одна сторона уже сказала всё, что хотела, и просто ждёт ответ. Такое сейчас встречается нечасто, поскольку использование одного TCP-сеанса для нескольких разговоров оказалось удобнее, но всё же возможно. Во-вторых, эти потерянные пакеты могут быть повторно отправленными или задержанными, которые пришли уже после завершения сеанса.
     
     
     
    ishanjain
    Guest
    #5
    0
    01.08.2022 07:53:00
    Спасибо за ответ! Твой ответ логичен. Если это снова меня будет беспокоить, я углублюсь в вопрос позже. А пока кажется, что это слишком много возни, и я могу просто продолжать игнорировать, как делал это почти год.
     
     
     
    R1CH
    Guest
    #6
    0
    01.08.2022 13:20:00
    Абсолютно нормально видеть такое, вот почему NAT — это отстой. Каждая реализация NAT имеет своё представление о том, когда соединение «завершено», и это не совпадает с тем, как работают операционные системы при общении.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры