Страх и ненависть в 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 адрес получателя и номера порта получателя, искусственно введенных для обеспечения функционирования устройства. В этом и заключается сущность сетевых соединений глазами роутера. Чтобы всё основательно встало на свои места, мы разберём практическую задачу, но это уже будет в следующей части.
Syn sent mikrotik что это
Fri Mar 19, 2010 8:16 am
i have no idea what is happening with this client.
frequently the latency goes high & ping drops
You do not have the required permissions to view the files attached to this post.
MikroTik Support
Posts: 6263 Joined: Tue Feb 14, 2006 9:46 am Location: Riga, Latvia
Re: what is syn sent
Fri Mar 19, 2010 9:02 am
it looks more like spammer connecting to possible ip addresses and scans for open port 80.
«Syn sent» means, that first packet is sent but there where no repsonse from other end (no ack).
Пропадает подключение по определённым адресам на роутере Mikrotik
С недавних пор некоторые адреса (абсолютно случайные) перестали отвечать на подключения из под домашней сети (с роутером Mikrotik). Висит статус syn_sent, дальше подключение не идёт. Причём такое случается только при подключении по 443 порту (по 80 и всему остальному спокойно проходит). Провайдер пишет, что проблема не на их стороне. В чём может быть проблема?
UPD: на сервере есть настроенный wireguard peer. Если через него перенаправлять неработающий адрес, то всё идёт нормально
alexvim
20.05.22 22:56:41 MSK
- Ответить на это сообщение
- Ссылка
Introduction
There are several ways to see what connections are making their way through the router.
In the Winbox Firewall window, you can switch to the Connections tab, to see current connections to/from/through your router. It looks like this:
Properties
All properties in the connection list are read-only
- «established»
- «time-wait»
- «close»
- «syn-sent»
- «syn-received»
Connection tracking settings
/ip firewall connection tracking
Properties
| Property | Description |
|---|---|
| enabled (yes | no | auto; Default: auto) | Allows to disable or enable connection tracking. Disabling connection tracking will cause several firewall features to stop working. See the list of affected features. Starting from v6.0rc2 default value is auto. This means that connection tracing is disabled until at least one firewall rule is added. |
| loose-tcp-tracking (yes; Default: yes) | Disable picking up already established connections |
| tcp-syn-sent-timeout (time; Default: 5s) | TCP SYN timeout. |
| tcp-syn-received-timeout (time; Default: 5s) | TCP SYN timeout. |
| tcp-established-timeout (time; Default: 1d) | Time when established TCP connection times out. |
| tcp-fin-wait-timeout (time; Default: 10s) | |
| tcp-close-wait-timeout (time; Default: 10s) | |
| tcp-last-ack-timeout (time; Default: 10s) | |
| tcp-time-wait-timeout (time; Default: 10s) | |
| tcp-close-timeout (time; Default: 10s) | |
| udp-timeout (time; Default: 10s) | Specifies the timeout for UDP connections that have seen packets in one direction |
| udp-stream-timeout (time; Default: 3m) | Specifies the timeout of UDP connections that has seen packets in both directions |
| icmp-timeout (time; Default: 10s) | ICMP connection timeout |
| generic-timeout (time; Default: 10m) | Timeout for all other connection entries |
Read-only properties
Max amount of entries that the connection tracking table can hold. This value depends on the installed amount of RAM.
Note that the system does not create a maximum-size connection tracking table when it starts, it may increase if the situation demands it and the system still has free ram, but size will not exceed 1048576
Features affected by connection tracking
- NAT
- firewall:
- connection-bytes
- connection-mark
- connection-type
- connection-state
- connection-limit
- connection-rate
- layer7-protocol
- new-connection-mark
- tarpit
- Нет меток