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

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

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

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

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

Оставим лирическое отступление и вернёмся к предмету разговора. На оборудовании 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 ^[2]. Он визуализирует сетевые соединения, однако существует теоретический риск, что соединение может существовать и быть не отражено в нём, вследствие короткого времени существования. На самом деле это не так, и далее я представлю объяснение. Именно с этими соединениями и работают правила «золотого сечения», с которых всегда начинается классическая настройка 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 можно почитать в официальной документации ^[3]. Ещё раз повторю, что они не равны в полной мере существующим сетевым соединениям, проходящим через роутер. Интуитивно это можно объяснить и так, что маршрутизатор ведь ничего не знает о содержании передающихся через него пакетов, он не устанавливает эти соединения, не проходит процедуры рукопожатий и т.д. Его дело их пропускать далее по сети. Это очень грубо и не отражает суть понятия сетевое соединение глазами маршрутизатора. Объясню на примере работы транспортных протоколов TCP и UDP.

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

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

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

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

Примерно такой же механизм реализован в ядре операционной системы маршрутизатора. Однако в 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 ^[8] атаки можно попытаться наоткрывать пустых соединений. Все они попадут в Connection tracking.

▍ Заключение

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

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