http://mikrotik.moscow Новое в теме Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sun, 02 Aug 2026 18:43:31 -0400 Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). RouterOS в форуме RouterOS.
Абсолютно нормально видеть такое, вот почему NAT — это отстой. Каждая реализация NAT имеет своё представление о том, когда соединение «завершено», и это не совпадает с тем, как работают операционные системы при общении.
01.08.2022 13:20:00, R1CH.]]> http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379900 http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379900 Mon, 01 Aug 2022 13:20:00 -0400 RouterOS Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). RouterOS в форуме RouterOS.
Спасибо за ответ! Твой ответ логичен. Если это снова меня будет беспокоить, я углублюсь в вопрос позже. А пока кажется, что это слишком много возни, и я могу просто продолжать игнорировать, как делал это почти год.
01.08.2022 07:53:00, ishanjain.]]> http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379899 http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379899 Mon, 01 Aug 2022 07:53:00 -0400 RouterOS Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). RouterOS в форуме RouterOS.
Возможных причин несколько, и для точного выяснения придётся провести анализ трафика с помощью пакетного сниффера. Во-первых, протокол TCP не требует, чтобы после отправки одним из участников FIN другой сразу же отвечал FIN — передача данных может продолжаться в одном направлении, когда одна сторона уже сказала всё, что хотела, и просто ждёт ответ. Такое сейчас встречается нечасто, поскольку использование одного TCP-сеанса для нескольких разговоров оказалось удобнее, но всё же возможно. Во-вторых, эти потерянные пакеты могут быть повторно отправленными или задержанными, которые пришли уже после завершения сеанса.
01.08.2022 05:15:00, sindy.]]> http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379898 http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379898 Mon, 01 Aug 2022 05:15:00 -0400 RouterOS Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). RouterOS в форуме RouterOS.
См. 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.
31.07.2022 19:23:00, tdw.]]> http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379897 http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379897 Sun, 31 Jul 2022 19:23:00 -0400 RouterOS Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). RouterOS в форуме RouterOS.
Привет, поднимаю эту тему. У меня наблюдаются похожие проблемы. Пакеты с флагами 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.
31.07.2022 18:49:00, ishanjain.]]> http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379896 http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379896 Sun, 31 Jul 2022 18:49:00 -0400 RouterOS Трафик, который кажется легитимным, блокируется (из-за таблицы conntrack?). RouterOS в форуме RouterOS.
Привет! Недавно я переехал и после настройки сети заметил, что у меня отбрасывается много трафика, который, кажется, вполне легитимный. Когда я работал с моим 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)
17.07.2022 16:48:00, MagicMicky.]]> http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379895 http://mikrotik.moscow/forum/forum57/83765-trafik_-kotoryy-kazhetsya-legitimnym_-blokiruetsya-_iz_za-tablitsy-conntrack_./message379895 Sun, 17 Jul 2022 16:48:00 -0400 RouterOS