Syn sent mikrotik что это

Обнаружена блокировка рекламы: Наш сайт существует благодаря показу онлайн-рекламы нашим посетителям. Пожалуйста, подумайте о поддержке нас, отключив блокировщик рекламы на нашем веб-сайте.

IP-> Firewall-> Connections -> — tcp-state —

Обсуждение ПО и его настройки

2 сообщения • Страница 1 из 1

hitman Сообщения: 38 Зарегистрирован: 29 апр 2017, 23:20

Доброго времени суток!
Хочу разобраться со значениями tcp-state в разделе — Connections — Firewall —
На сколько я понял, значения могут быть такими:
«established»
«time-wait»
«close»
«syn-sent»
«syn-received»
Хотелось бы узнать, что означает каждый параметр на русском языке. Поиск в инете не дало мне результатов.
Расскажите пожалуйста, кто знает. или укажите на источник.
а вопрос возник, когда увидел такую строку.. и что же это означает.. на этот адрес порт 80 точно открыт.

11 SAC s tcp 10.20.30.5:60249 89.104.77.11:80 close 8s 8.8kbps 364.8kbps

MikroTik.by

For every complex problem, there is a solution that is simple, neat, and wrong.

Список форумовФорум по операционной системе MikroTik RouterOSМаршрутизация, коммутация
Поиск

[РЕШЕНО через костыль] Перестаёт работать dst-nat

RIP, OSFP, BGP, MPLS/VPLS
22 сообщения • Страница 1 из 1
Sir_Prikol Сообщения: 560 Зарегистрирован: 14 апр 2018, 15:21 Откуда: СССР Контактная информация:

[РЕШЕНО через костыль] Перестаёт работать dst-nat

Сообщение Sir_Prikol » 23 сен 2018, 18:29

Доброго времени суток.
Имеем следующую конфигурацию:

Входящий RB3011, за ним стоит RB2011 (остальные в данной проблеме не важны и не участвуют)
Имеем WAN — 123.123.123.123
LAN 192.168.0.0/24
RB3011 — LAN — 192.168.0.1
RB2011 — 192.168.0.2

На RB2011 подняты sstp, l2tp,pptp серверы
На RB3011 подняты dst-nat на RB2011 по портам этих серверов и находятся в самом верху правил (без passrouth)

В фаерволе что на RB3011, что на RB2011 разрешены gre и даныые порты серверов и подняты на самый верх

Ситуация — связка работает, авторизация проходит на RB2011, но через некоторое время (иногда час иногда 3-е суток) dst-nat прекращает работать и, хоть счётчик пакетов увеличивается, пакеты до RB2011 не долетают.
В логах RB3011 — видно что правило отработало, в логах RB2011 девственная чистота.
После ребута RB3011 всё становится нормально, но опять до какого-то времени.

Часть настроек участвующих в данной реализации
RB3011

/ip firewall nat add action=dst-nat chain=dstnat comment=PPtP dst-address=123.123.123.123 dst-port=1723 to-addresses=192.168.0.2 to-ports=1723 disabled=no add action=dst-nat chain=dstnat comment=SStP dst-address=123.123.123.123 dst-port=12443 to-addresses=192.168.0.2 to-ports=12443 disabled=no add action=dst-nat chain=dstnat comment=L2TP dst-address=123.123.123.123 dst-port=1701 to-addresses=192.168.0.2 to-ports=1701 disabled=no

/ip firewall filter add action=accept chain=input disabled=no dst-port=1723 protocol=tcp add action=accept chain=input disabled=no dst-port=12443 protocol=tcp add action=accept chain=input disabled=no protocol=gre

Эти головняки начались начиная с 6.42.6, как я и говорил, тенденция
Куда копать?
Последний раз редактировалось Sir_Prikol 26 окт 2018, 00:30, всего редактировалось 1 раз.
Дома: CCR2004 (7-ISP(GPON)белый IP)
Chupaka Сообщения: 3915 Зарегистрирован: 29 фев 2016, 15:26 Откуда: Минск Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Chupaka » 23 сен 2018, 21:19

Sir_Prikol писал(а): ↑ 23 сен 2018, 18:29 через некоторое время (иногда час иногда 3-е суток) dst-nat прекращает работать и, хоть счётчик пакетов увеличивается, пакеты до RB2011 не долетают.
В логах RB3011 — видно что правило отработало, в логах RB2011 девственная чистота.

В первую очередь — понять, куда девается пакет. Например, добавив правило типа

/ip firewall filter add chain=forward dst-address=192.168.0.2 action=passthrough log=yes

Смотреть в лог, на какой интерфейс улетает пакет — мало ли, другая конфигурация на это может влиять.

Или Tools -> Torch подтвердить, что пакет действительно улетает с 3011 на 2011. Посмотреть, что он на 2011 не появляется тем же Torch’ем. Роутеры соединены патчкордом порт в порт?

Sir_Prikol Сообщения: 560 Зарегистрирован: 14 апр 2018, 15:21 Откуда: СССР Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Sir_Prikol » 23 сен 2018, 21:48

RB3011

RB2011

Но все сервера молчат
192.168.7.2=192.168.0.2

Дома: CCR2004 (7-ISP(GPON)белый IP)
Sir_Prikol Сообщения: 560 Зарегистрирован: 14 апр 2018, 15:21 Откуда: СССР Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Sir_Prikol » 23 сен 2018, 21:57

UPD: на 2011 появились после ребута 2011. но sstp сервер молчит, и это будет продолжаться до ребута 3011

Дома: CCR2004 (7-ISP(GPON)белый IP)
Chupaka Сообщения: 3915 Зарегистрирован: 29 фев 2016, 15:26 Откуда: Минск Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Chupaka » 23 сен 2018, 22:03

Log для NAT не показывает out-interface, поэтому я и писал про filter forward. Но тут проблема может быть с обратным пакетом, раз до 2011 SYN’ы долетают. В общем, Torch и log=yes в помощь — смотреть полный путь пакета от клиента к 3011, 2011 и обратно. А вот где пакет пропадёт — там и смотреть, почему.

Sir_Prikol Сообщения: 560 Зарегистрирован: 14 апр 2018, 15:21 Откуда: СССР Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Sir_Prikol » 23 сен 2018, 22:17

Вот и я думаю что проблема именно с обраткой, но в моей маршрутизации такого наверчено, что без бутылки новую добавить — не совсем можно. Проще нетмапом сделать А ещё проще выдать белый ip на тот самый 2011 и забыть как страшный сон, но сам принцип.
В общем фигнёй страдает именно RB3011, так как с 3011 на 2011 спокойно проходит авторизация, а снаружи, через 3011, нифига. И с любого другого устройства внутри сети — работает

Re: Перестаёт работать dst-nat

Сообщение Chupaka » 24 сен 2018, 10:58

Sir_Prikol писал(а): ↑ 23 сен 2018, 22:17 В общем фигнёй страдает именно RB3011, так как с 3011 на 2011 спокойно проходит авторизация, а снаружи, через 3011, нифига. И с любого другого устройства внутри сети — работает

Не факт, не факт. Тем более в свете упоминания навороченной маршрутизации Может и в 2011 причина быть. В общем, как я и сказал, надо отследить пакет — вдруг станет понятнее. На 3011 в forward’е, на 2011 — в output’е.

Sir_Prikol Сообщения: 560 Зарегистрирован: 14 апр 2018, 15:21 Откуда: СССР Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Sir_Prikol » 24 сен 2018, 11:06

Пакет отслежен, он теряется в OSPF. А вот тут засада. Сам по себе OSPF начинает мозг компосировать, если я ему прописываю /24 маршрутизацию, а по sstp выдаю /30, меняю в OSPFна /30, маршрутизация ложится вообще. Сегодня донапишу отказ от OSPF. Перелопачу полную маршрутизацию руками. Проще рутинг марками сделать, нежели на автомат полагаться.

UPD: Вся эта хрень начинает корректно работать на дефолтных маршрутах, вот осталось заставить понимать пакет, чтоб он уходил туда-же откуда пришёл. Или, как вариант, всё-таки выделить отдельный IP и отдельный канал для этих соединений, что реально, так как три канала аплинка, один отдать под sstp,l2tp,pptp и будет счастье

Re: Перестаёт работать dst-nat

Сообщение Chupaka » 24 сен 2018, 14:19

Вообще ничего не понял

Что значит «теряется в OSPF»? OSPF строит таблицу маршрутизации, он ничего с пакетами сам не делает.

Что значит «на дефолтных маршрутах»? «чтоб он уходил туда-же откуда пришёл» — это Policy Routing в помощь.

Sir_Prikol Сообщения: 560 Зарегистрирован: 14 апр 2018, 15:21 Откуда: СССР Контактная информация:

Re: Перестаёт работать dst-nat

Сообщение Sir_Prikol » 24 сен 2018, 14:48

Вот как раз PBR и глючит на 3011, на нём единственном, идентичная конфа на 1100 — работает на ура, на 1009 то-же. Очередной косяк именно с RB3011, это уже не первый раз когда на этом маршрутизаторе выявляются косяки не свойственные для другой модели. Есть желание увидеть как там и что — могу дать доступ Но на этом маршрутизаторе уже побывало 5 человек, с серификатами ибез, и ответ один — всё должно работать А оно отрубается

Re: Перестаёт работать dst-nat

Сообщение Sir_Prikol » 24 сен 2018, 17:36

Как я и предупреждал, не отрабатывает arp на RB3011, в связи с этим шлюз кажется доступным, а пакеты теряются Решил эту проблему по другому, через cname и /ip cloud

Так как у меня везде белая сеть, то через CNAME просто привязал ddns микротика на свой поддомен, и коннектится можно по имени, а не по ip

Сделал простейший скрипт, который обновляет в /ip cloud нужный мне аплинк и дальше простым нетмапом.

Кому интересен скрипт —

#variable to store the IP address of the Primary gateway you wish to use to update the MikrotikCloud DDNS :local PrimaryGW "" #variable to store the IP address of the Secondary gateway you wish to use to update the CloudIP DDNS :local SecondaryGW "" #The url of the Mikrotik Cloud DDNS (for ipv4) if need ipv6 use cloud2.mikrotik.com :local cloudIPDDNS "cloud.mikrotik.com" #resolve the ip address :resolve $cloudIPDDNS #Delete any routes that already exist with distance 30 and 31 /ip route remove [find distance="30"] /ip route remove [find distance="31"] #Add the new default routes to the Mikrotik Cloud DDNS :foreach aRecord in=[/ip dns cache all find where (name=$cloudIPDDNS && type=”A”)] do= < /ip route add dst-address=[/ip dns cache all get $aRecord data] gateway=$PrimaryGW distance=”30″; >:foreach aRecord in=[/ip dns cache all find where (name=$cloudIPDDNS && type=”A”)] do= < /ip route add dst-address=[/ip dns cache all get $aRecord data] gateway=$SecondaryGW distance=31; >

Далее простой нетмап на нужный ip тоже скриптом
Вот как-то так

З.Ы. Странность с маршрутами была ещё следующая, чек маршрутов через пинг и арп были сделаны по разному (признаю, мой косяк) арп был сделан на pppoe клиентов (2шт) а пинг был сделан на физический интерфейс. Может из-за этого глючило, не знаю, сейчас RB3011 был в ребуте, соответственно всё поднялось, когда отрубится — буду искать дальше.
В принципе, у меня задача стоит выделить для sstp один единственный канал, остальные это выход в мир. Сделано это из-за того, чтобы можно было закконектится в любом случае, даже при падении промежуточных каналов связи. Аплинк для sstp,l2tp,pptp — магистральный, у него аптайм гарантирован, всместе со скоростью

Страх и ненависть в RouterOS: что такое сетевое соединение в ядре Linux (часть 1 — теория)

В статье рассмотрено понятие «соединение» для TCP и UDP протоколов в ядре операционной системы Linux на примере работы оборудования MikroTik. Дополнительно рассматриваются особенности работы технологии NAT в указанном контексте. Материалы носят в основном теоретический характер и предназначены для людей, тонко настраивающих Firewall, Qos и маршрутизацию, где им придётся непосредственно работать с рассматриваемыми connections.

В этой части статьи подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В практической части закрепим информацию в результате рассмотрения работы прикладного протокола DNS через подсистемы RouterOS. В заключительной части речь пойдёт о диаграмме потока пакетов, при работе с которой важно понимать сущность рассматриваемого сетевого соединения, а также о не документированной в явном виде особенности работы NAT. Материала достаточно много, и чтобы читатель не потерял смысловую нить к концу статьи, она разделена на 3 части: теория, практика и особенность NAT.

Цикл статей не предназначен для новичков и может их только запутать. Полагаю, что читатель хорошо знаком с предметом разговора.

Начнём с того, что разграничим сетевое соединение в ядре операционной системы маршрутизатора и реально существующее клиент-серверное соединение, передающееся насквозь через него. То, соединение, о котором речь пойдёт в статье, существует только в контексте роутера, ровно также, как маркировка трафика. RouterOS построена на базе операционной системы Linux и поэтому имеет высокое сходство с ней. Подсистема обработки сетевых пакетов на оборудовании MikroTik унаследована от ядра Linux (постулат подтверждён обращением в компанию, номер обращения SUP-65046). Это может быть одним из аргументов в сторону изучения работы RouterOS, так как полученные знания легко адаптивны под работу непосредственно с Linux. Так, совсем недавно на Хабре была опубликована статья, посвящённая маршрутизации, в которой достаточно ясно прослеживается указанная взаимосвязь. Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik.

Оставим лирическое отступление и вернёмся к предмету разговора. На оборудовании MikroTik, сетевые соединения в Firewall можно увидеть так:

/ip firewall connection print Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat # PR.. SRC-ADDRESS DST-ADDRESS TCP-STATE TIMEOUT ORIG-RATE REPL-RATE 0 SAC s tcp 10.0.0.254:1587 13.33.246.32:443 established 23h36m38s 0bps 0bps 1 SAC s udp 10.0.0.254:28397 64.233.165.147:443 48s 0bps 0bps 2 SAC tcp 192.168.1.17:44227 194.67.200.124:1200 established 23h59m54s 0bps 0bps 3 SAC s tcp 10.0.0.254:2069 2.16.103.120:80 close 3s 0bps 0bps 4 C udp 10.0.0.254:65274 10.0.0.255:20561 9s 7.2kbps 0bps 5 SAC s udp 10.0.0.254:16641 64.233.165.147:443 48s 0bps 0bps 6 SAC s udp 10.0.0.254:10493 142.251.1.100:443 1m52s 0bps 0bps 7 SAC s tcp 10.0.0.254:1066 173.194.73.188:5228 established 23h59m37s 0bps 0bps 8 SAC s udp 10.0.0.254:55243 64.233.165.147:443 1m53s 0bps 0bps 9 SAC s udp 10.0.0.254:15947 64.233.165.147:443 2m48s 0bps 0bps 10 SAC s udp 10.0.0.254:63933 64.233.165.147:443 2m48s 0bps 0bps 11 S C udp 192.168.1.17:35622 1.1.1.1:53 1s 0bps 0bps

В Winbox это будет выглядеть более наглядно, однако окно дополнительной информации не содержит:

Показанный инструмент называется Connection tracking. Он визуализирует сетевые соединения, однако существует теоретический риск, что соединение может существовать и быть не отражено в нём, вследствие короткого времени существования. На самом деле это не так, и далее я представлю объяснение. Именно с этими соединениями и работают правила «золотого сечения», с которых всегда начинается классическая настройка Firewall на MikroTik:

/ip firewall filter add action=accept chain=input comment="Accept established,related" connection-state=established,related add action=drop chain=input comment="Drop invalid" connection-state=invalid add action=accept chain=forward comment="Accept established,related" connection-state=established,related add action=drop chain=forward comment="Drop invalid" connection-state=invalid

Они обеспечивают прохождение пакетов уже установленных соединений, а также связанных с ними, минуя нижестоящие правила Firewall, чем высвобождают ресурсы центрального процессора маршрутизатора. Подробнее, какие соединения являются new, established, related, untracked и invalid можно почитать в официальной документации. Ещё раз повторю, что они не равны в полной мере существующим сетевым соединениям, проходящим через роутер. Интуитивно это можно объяснить и так, что маршрутизатор ведь ничего не знает о содержании передающихся через него пакетов, он не устанавливает эти соединения, не проходит процедуры рукопожатий и т.д. Его дело их пропускать далее по сети. Это очень грубо и не отражает суть понятия сетевое соединение глазами маршрутизатора. Объясню на примере работы транспортных протоколов TCP и UDP.

Начнём по порядку. Каждое реально существующее TCP соединение имеет уникальный (случайный) Sequence number, который генерируется после трёхстороннего handshakes:

Можно было бы предположить, что каждый Sequence number является уникальным соединением в операционной системе маршрутизатора. Теперь взглянем на заголовок UDP протокола, в котором никакого номера соединения вообще нет:

Однако в роутере существуют и TCP и UDP соединения. Для объяснения происходящего воспользуемся методом аналогии. Откроем в Wireshark дамп обычного сетевого трафика и посмотрим, что содержат заголовки реально существующих пакетов, а не серые картинки с RFC:

Слева представлен заголовок для TCP пакета, справа для UDP пакета. Sequence number уже знакомый параметр, а вот описание Stream index ранее мы не встречали. И как не сложно догадаться, их нет в протоколах. На самом деле Stream index – это параметр, введённый в отображение заголовков пакетов непосредственно программой Wireshark, для удобства работы с трафиком. Он присваивается каждой паре сокетов, начиная с единицы, и инкрементально увеличивается отдельно для каждого типа протоколов. Здесь появляется новый термин – сокет. Под ним понимается совокупность пар: IP адрес отправителя и номер порта отправителя, а также IP адрес получателя и номера порта получателя. Если вы выполните экспорт только конкретных выбранных (выделенных) пакетов из дампа, то, открыв их, обнаружите, что Stream index будет пересчитан заново, начиная с единицы. Когда выбирается меню Follow -> TCP Stream, то как раз Wireshark и отобразит пакеты, имеющие одинаковое значение Stream index.

Примерно такой же механизм реализован в ядре операционной системы маршрутизатора. Однако в Connection tracking увидеть параметр, аналогичный Stream index в Wireshark, не получится:

Далее по тексту статей я буду нарочно использовать термин Stream index применительно к MikroTik, хотя это и не корректно. Получается, что ядро операционной системы маршрутизатора работает с набором виртуальных сокетов. Встаёт вопрос, каково время их жизни? RouterOS позволяет легко управлять этими параметрами, однако не рекомендую менять их значения по умолчанию, если вы не до конца понимаете, с чем ~~развлекаетесь~~ работаете:

/ip firewall connection tracking print enabled: auto tcp-syn-sent-timeout: 5s tcp-syn-received-timeout: 5s tcp-established-timeout: 1d tcp-fin-wait-timeout: 10s tcp-close-wait-timeout: 10s tcp-last-ack-timeout: 10s tcp-time-wait-timeout: 10s tcp-close-timeout: 10s tcp-max-retrans-timeout: 5m tcp-unacked-timeout: 5m loose-tcp-tracking: yes udp-timeout: 10s udp-stream-timeout: 3m icmp-timeout: 10s generic-timeout: 10m max-entries: 88016 total-entries: 9

Ранее по тексту было опровергнуто утверждение, что теоретически некоторые соединения могут быть не отражены в Connection tracking. Как видно выше, значения по умолчанию задают достаточно длинные таймауты, что гарантирует визуализацию всех сетевых соединений, ~~даже случайно пролетающих через маршрутизатор~~. В результате DOS атаки можно попытаться наоткрывать пустых соединений. Все они попадут в Connection tracking.

▍ Заключение

Теоретический материал подошёл к концу. Представленной информации должно хватить для того, чтобы у знакомого с темой читателя сложилось понимание, что такое сетевое соединение в роутере MikroTik, а также других устройствах, работающих под управлением операционной системе, в основу которой положен Linux. Внутри RouterOS понятие сетевое соединение не идентично клиент-серверному соединению, что необходимо для её работы с пакетами. Это важно понимать и знать, ведь работа с этими соединениями не ограничивается только Firewall-ом, но также присутствует в приоритизации трафика (Qos) и маршрутизации. Защита маршрутизатора от DOS атак на L3 уровне также базируется на правилах обработки сетевых соединений.

MikroTik работает с виртуальными сокетами, под которыми следует понимать совокупность пар IP адрес отправителя и номер порта отправителя, а также IP адрес получателя и номера порта получателя, искусственно введенных для обеспечения функционирования устройства. В этом и заключается сущность сетевых соединений глазами роутера. Чтобы всё основательно встало на свои места, мы разберём практическую задачу, но это уже будет в следующей части.

Пропадает подключение по определённым адресам на роутере Mikrotik

С недавних пор некоторые адреса (абсолютно случайные) перестали отвечать на подключения из под домашней сети (с роутером Mikrotik). Висит статус syn_sent, дальше подключение не идёт. Причём такое случается только при подключении по 443 порту (по 80 и всему остальному спокойно проходит). Провайдер пишет, что проблема не на их стороне. В чём может быть проблема?
UPD: на сервере есть настроенный wireguard peer. Если через него перенаправлять неработающий адрес, то всё идёт нормально

alexvim
20.05.22 22:56:41 MSK
Последнее исправление: alexvim 20.05.22 22:59:12 MSK (всего исправлений: 1)

Ответить на это сообщение
Ссылка

Syn sent mikrotik что это