В статье рассмотрено понятие «соединение» для TCP и UDP протоколов в ядре операционной системы Linux на примере работы оборудования MikroTik. Дополнительно рассматриваются особенности работы технологии NAT в указанном контексте. Материалы носят в основном теоретический характер и предназначены для людей, тонко настраивающих Firewall, Qos и маршрутизацию, где им придётся непосредственно работать с рассматриваемыми connections.
В этой части статьи подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В практической части закрепим информацию в результате рассмотрения работы прикладного протокола DNS через подсистемы RouterOS. В заключительной части речь пойдёт о диаграмме потока пакетов, при работе с которой важно понимать сущность рассматриваемого сетевого соединения, а также о не документированной в явном виде особенности работы NAT. Материала достаточно много, и чтобы читатель не потерял смысловую нить к концу статьи, она разделена на 3 части: теория, практика и особенность NAT.
Цикл статей не предназначен для новичков и может их только запутать. Полагаю, что читатель хорошо знаком с предметом разговора.
Начнём с того, что разграничим сетевое соединение в ядре операционной системы маршрутизатора и реально существующее клиент-серверное соединение, передающееся насквозь через него. То, соединение, о котором речь пойдёт в статье, существует только в контексте роутера, ровно также, как маркировка трафика. RouterOS построена на базе операционной системы Linux и поэтому имеет высокое сходство с ней. Подсистема обработки сетевых пакетов на оборудовании MikroTik унаследована от ядра Linux (постулат подтверждён обращением в компанию, номер обращения SUP-65046). Это может быть одним из аргументов в сторону изучения работы RouterOS, так как полученные знания легко адаптивны под работу непосредственно с Linux. Так, совсем недавно на Хабре была опубликована статья, посвящённая маршрутизации, в которой достаточно ясно прослеживается указанная взаимосвязь.
Оставим лирическое отступление и вернёмся к предмету разговора. На оборудовании 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 адрес получателя и номера порта получателя, искусственно введенных для обеспечения функционирования устройства. В этом и заключается сущность сетевых соединений глазами роутера. Чтобы всё основательно встало на свои места, мы разберём практическую задачу, но это уже будет в следующей части.
Автор:
olegtsss
