+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблемы с корректным соединением при сбросе недопустимых пакетов в межсетевом экране

Проблемы с корректным соединением при сбросе недопустимых пакетов в межсетевом экране, RouterOS

kmadac

Guest

17.03.2016 20:10:00

Привет! У меня есть два роутера CRS125-24G с RouterOS 6.33.3 — по одному аплинку и 23 порта работают как свич на каждом устройстве. Я столкнулся с странной проблемой при маршрутизации между сетями.

У меня две сети: Device A — 192.168.10.0/24 и Device B — 192.168.100.0/24.
(SSH клиент 192.168.10.18) — (192.168.10.1 Роутер A) — (192.168.10.11 Роутер B 192.168.100.1) — (SSH сервер 192.168.100.10)

На Router A есть статический маршрут, который направляет трафик из 192.168.10.0/24 в 192.168.100.0/24 через Router B:

Flags: X - отключён, A - активный, D - динамический, C - подключённый, S - статический, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - недоступен, P - запрещён
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
8 A S 192.168.100.0/24 192.168.10.11 1

Я заметил, что когда у меня включено правило фаервола, которое сбрасывает пакеты с состоянием invalid (недействительные соединения), проблемы возникают и с валидными пакетами. Вот это правило:

9 ;;; сбросить недействительные соединения
chain=forward action=drop connection-state=invalid log=yes log-prefix="INVALID"

Когда оно включено, подключение по SSH с 192.168.10.18 к 192.168.100.10 занимает 7 секунд. Если выключить это правило — подключение к SSH-серверу происходит сразу.

В логах при включенном сбросе invalid-пакетов я вижу вот такие записи о сброшенных пакетах:

20:31:49 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK), 192.168.10.18:46888->192.168.100.10:22, len 52
20:31:49 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK,PSH), 192.168.10.18:46888->192.168.100.10:22, len 95
20:31:50 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK,PSH), 192.168.10.18:46888->192.168.100.10:22, len 95
20:31:50 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK,PSH), 192.168.10.18:46888->192.168.100.10:22, len 95
20:31:50 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK,PSH), 192.168.10.18:46888->192.168.100.10:22, len 95
20:31:50 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK), 192.168.10.18:46888->192.168.100.10:22, len 52
20:31:51 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK,PSH), 192.168.10.18:46888->192.168.100.10:22, len 95
20:31:52 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK), 192.168.10.18:46888->192.168.100.10:22, len 52
20:31:53 firewall,info INVALID forward: in:bridge out:bridge, src-mac c4:85:08:dd:94:42, proto TCP (ACK,PSH), 192.168.10.18:46888->192.168.100.10:22, len 95

Я сделал трассировку пакетов и вижу множество повторных и дублирующихся пакетов. Странно, что соединение инициируется с задержкой, а все последующие пакеты в том же соединении идут без тормозов.

У меня включён connection tracking, и я вижу это соединение в таблице отслеживания.

Похоже, валидные пакеты ошибочно срабатывают на правило сброса invalid.

В чём может быть причина такого поведения? Это баг или косяк в моей конфигурации?

mizeraj

Guest

22.06.2016 08:00:00

Привет, у меня такая же проблема. Но надо добавить, что это происходит только на компьютерах с Windows, которые пытаются попасть в сеть 192.168.100.0 через ssh или sftp, добавленную простой статической маршрутизирующей записью. С сетью 192.168.0.0, настроенной самим Mikrotik, проблем с подключением нет. Помогает только отключение правила «drop invalid», его переставка не даёт результата (по сути, оно уже в самом низу списка правил).

nethor

Guest

07.08.2019 06:07:00

Есть какие-то сдвиги по этой теме? Кто-нибудь нашёл причину проблемы? У меня такая же ситуация с двумя MikroTik Routerboard, настроенными с активной конфигурацией OSPF. Также замечаю задержку около 7 секунд, но только для некоторых протоколов (например, REST-запросы). Это происходит только при подключении к устройствам, которые подключены к router2 (в то время как router1 работает в качестве шлюза). При прямом подключении через router2 такой задержки нет. По логам видно, что стандартное правило firewall forward «drop invalid» на router1 отбрасывает пакеты, точно так же, как писал kamadac. Если добавить своё правило с белым списком, разрешающее invalid-пакеты для этого соединения, запросы проходят быстро, без задержек. Но это как-то костыль, хотелось бы понять, почему пакеты считаются invalid. Я копался в настройках MTU на разных устройствах, так как есть VPN, но пока это не дало результата.

sindy

Guest

07.08.2019 10:39:00

Не уверен насчёт твоей ( @nethor ) настройки, но в исходном посте 2016 года интерфейс Router B, который смотрел в сторону SSH-клиента, был в той же подсети, что и клиент. Поэтому, пока пакеты запросов от клиента шли к Router A (потому что 192.168.10.1 был настроен как шлюз по умолчанию или, по крайней мере, была маршрутизация к 192.68.100.0/24) и оттуда пересылались на Router B, а затем к назначению, ответы сервера обходили Router A, так как Router B отправлял их клиенту напрямую. Из-за этого фаервол Router A видел начальный SYN от клиента, но не видел SYN,ACK от сервера, и любые последующие пакеты от клиента считались недействительными. При этом правило accept established или related, даже если оно первое в цепочке, не срабатывает на недействительных пакетах, поэтому этот совет не помогал. Твоя ситуация может полностью отличаться, так что, если это к тебе не подходит, приложи свою схему сети.

pgh321 Guest	#5 0 07.08.2019 19:04:00 У меня похожие проблемы http://forum.mikrotik.com/t/tcp-ack-connections-in-firewall-log/131899/2 Что может случиться, если просто убрать правило, сбрасывающее недопустимые пакеты?

sindy

Guest

07.08.2019 19:14:00

Как я уже писал всего одним постом выше — удаление правила drop invalid не заставит недействительные пакеты чудесным образом приниматься правилом accept established,related. Так что, если цепочки вашего файрвола не заканчиваются правилом drop the rest, удаление drop invalid может помочь соединениям работать, но если это так, то это лишь свидетельство того, что файрвол пропускает дыры.

pgh321

Guest

10.08.2019 09:09:00

Извините, я ошибался, мои пакеты просто сбрасываются последним правилом «drop and log everything else». Эти соединения кажутся «сиротскими», как в http://forum.mikrotik.com/t/what-is-dropped-packets-tcp-ack-psh-on-port-1075/2800/1
DROP: input: in:ether01-gateway out:(unknown 0), src-mac XXX, proto TCP (ACK,PSH), 151.101.X.Y:443->MIK_WAN, len 110, где src-mac — это роутер tplink vdsl перед mikrotik (делающий NAT на него), а MIK_WAN — внешний интерфейс mikrotik, тот, что подключен к tplink.
IP 151.101 принадлежит CDN, я заметил, что это связано с использованием reddit на моем смартфоне, так что, похоже, ничего опасного… Не уверен, стоит ли как-то менять тайм-ауты пакетов, может, эти соединения открыты слишком мало или слишком долго, из-за чего и возникает такое поведение… Во всяком случае, это не происходит «всегда», потому что приложения на телефоне и похожие вещи работают нормально, но раньше я такого не замечал, так что, наверное, это связано именно с этим телефоном. Раньше у меня не было android-телефона, были только планшеты с wifi, так что возможно из-за разных соединений с телефоном возникают проблемы в моей сети…
P.S. Я нашёл более наглядный пример моей проблемы. Я видел такие логи, когда телефона не было дома, микротик «искал мой телефон», но он не был найден в сети, и пакеты сбрасывались. Очевидно, что с ПК или планшетами, которые всегда дома и подключены к одной сети, такого не происходит.
Это нормальное поведение? Можно как-то это избежать? Я немного запутался, и, несмотря на долгие поиски в интернете, не нашёл вразумительной информации…

pe1chl

Guest

10.08.2019 09:50:00

Что обычно происходит с телефонами: ваш телефон все время поддерживает соединения с разными сервисами. Это открытые TCP-соединения. Потом вы выходите из дома и внезапно теряете WiFi без возможности аккуратно их закрыть. В итоге роутер и сервис по-прежнему думают, что эти соединения открыты. Через некоторое время роутер удаляет запись об открытом соединении (один из таймеров в отслеживании соединений истек). Но сервис на другой стороне все еще видит «бездействующее» соединение и либо пытается отправить данные по нему, либо шлёт пакет «keep alive». В этот момент такой пакет считается недействительным и отбрасывается. Поскольку с другой стороны не приходит ответ, сервис продолжит попытки еще какое-то время.

Вы можете помочь, добавив правило, которое отклоняет TCP-пакеты со статусом соединения «invalid» с опцией «reject-with: tcp-reset». Это сразу даст понять другой стороне, что от этого конкретного TCP-соединения больше ничего ждать не стоит. (Конечно, таких соединений может быть несколько, поэтому это может повторяться пару раз, но не больше одного раза на каждое соединение.)

pgh321

Guest

12.08.2019 13:40:00

Есть кое-что, чего я не понимаю. Правило, блокирующее недопустимые пакеты, здесь первое и без логирования. Если я вижу пакеты в логе, их должны блокировать последние правила (drop all the rest). Так как же тогда попасть на эти пакеты? Прямо перед правилом «drop all», но как? Пробовать отбрасывать с сбросом только по 3-4 адресам, которые часто попадают в лог, кажется непрактичным. Может, ключ в «out: unknown 0»??? Извините, если я новичок.

sindy

Guest

#10

12.08.2019 20:06:00

Звучит логично. out: unknown означает, что роутер не смог направить эти пакеты куда-либо, потому что они пришли на его WAN IP, но так как не было отслеживаемого соединения, с которым они совпали бы, их нельзя было «разнатить по исходному адресу», поэтому роутер обработал их как входящие, а не как пересылаемые пакеты — а у входящих пакетов нет исходящего интерфейса.

Однако TCP-пакеты, относящиеся к мертвым соединениям, помечаются с connection-state=invalid только если loose-tcp-tracking в /ip firewall connection tracking установлен в no; в противном случае они считаются connection-state=new.

Так что добавь log=yes к правилу «drop invalid» с каким-нибудь заметным log-prefix, чтобы убедиться, что оно ничего не логирует, а потом сделай /ip firewall connection tracking set loose-tcp-tracking=yes; после этого ты должен видеть, что они логируются правилом «drop invalid».

И чтобы было понятно, речь идет о цепочке chain=input, хотя соединения, вызвавшие появление этих пакетов, обрабатывались цепочкой chain=forward.

pgh321 Guest	#11 0 16.08.2019 13:35:00 Привет, loose tcp tracking уже был включен... При логировании недопустимых пакетов я начал видеть только массу RST-пакетов, все они отбрасывались по правилу invalid, и не только для адреса телефона, но и для других устройств... Потом я попробовал отключить правило «drop invalid», и эти RST-пакеты стали отбрасываться правилом «final drop» в самом конце... Например, этот пакет сначала отбрасывался как invalid, а если бы не он, то был бы отброшен в конце так или иначе: input: in:ether1-gateway out:(unknown 0), src-mac TPLINK_WAN, proto TCP (RST), 216.58.205.74:443->MIK_WAN:39508, len 40.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры