Современная Packet Flow Diagram

Для разбора диаграммы в качестве примера возьмем ситуацию, когда некое наше устройство (PC-01) отправляет трафик через наш роутер (CRS109) в какой-нибудь ресурс, например, для выхода в интернет (SkyNet) (Рис. 31.2).

Предположим, что наше устройство (PC-01) имеет некий адрес 192.168.88.254/24, CRS109 имеет адрес 192.168.88.1/24 , а внешний ресурс SkyNet – 1.1.1.1. Значит, в заголовках пакетов на L3 Source адрес (src addr) будет указан 192.168.88.254, Destination адрес (dst addr) — 1.1.1.1. В то время, как на втором уровне L2 будет иная ситуация, Source mac-адрес (srcmac) это адрес компьютера, а Destination mac-адрес (dstmac) это адрес шлюза CRS109.

Вернемся к Packet-Flow Diagram и рассмотрим прохождение трафика применительно к приведенному примеру (Рис. 31.3).

При отправке трафика с PC-01 в SkyNet на вопрос, “In interface bridge port” ответ будет да:
Physical In-interface / In-interface bridge port? / Yes / A (Bridging Decision).

Далее нужно понять, куда Bridging Decision отправит трафик, т.к. Bridging Decision работает именно с L2 уровнем OSI, а в заголовке кадра будет находиться mac-адрес микротика (Рис. 31.2), поэтому трафик пойдет по цепочке Input:
A / Input / B

После этого происходит декапсуляция кадров в пакеты, т.к. MPLS у нас нет, мы попадаем на следующий вопрос: “IPv4 or IPv6 Traffic?”. Мы выбрали IPv4 трафик, поэтому попадаем в Routing Decision:
B / MPLS Traffic? / No / IPv4 or IPv6 Traffic? / Yes / I (Routing Decision)

В Routing Decision определяется цепочка, по которой пойдет трафик согласно указанному адресу, т.к. в разделе IP Addresses адреса 1.1.1.1 нет (Рис. 31.4). Соответственно, трафик попадет в цепочку Forward, т.е. трафик попадает на какой-то маршрут ip route, и, следовательно, роутер передает этот трафик дальше. Далее определяется MPLS трафик или нет (нет):
I / Forward / MPLS Traffic? / No /Out-Interface Bridge port?

И является ли out-interface бриджем, т.к. выход в интернет происходит через физический интерфейс (оптика, Ethernet), то не является:
Out-Interface Bridge port? / No / Encapsulate?

Далее проверка на инкапсуляцию трафика, если выходной интерфейс не VPN-туннель, то не инкапсулируем трафик:
Encapsulate? / No / Interface HTB

Следующая проверка связана с деревьями очередей (есть ли QoS?). В данном случае очередей нет, поэтому трафик выходит наружу:
Interface HTB / Physical Out-Interface

Стоит обратить внимание на то, что на большой схеме Рис. 31.1 не отображены некоторые моменты, а именно наличие ссылок на доп. схемы. Ссылки в виде букв A-K указывают на то, что нужно перейти на другую схему и посмотреть, что происходит внутри. В данном случае нас будет интересовать буква I (Рис. 31.5).

Буква I отвечает за роутинг – что будет происходить, когда трафик попадает в роутинг. Рассмотрим процедуры, происходящие с трафиком, после попадания в I:
I / Prerouting

В цепочке Prerouting (Рис. 31.6) нас интересует лишь Connection Tracking – система отслеживания соединений. Мы уже решили, что направление трафика (Routing Decision) будет цепочкой Forward:
I / Prerouting / Routing Decision / Forward

В цепочке Forward (Рис. 31.6) нас интересует наличие разрешения на выход в интернет трафика (есть ли правила, запрещающие выход в интернет) Filter Forward. Так же при прохождении цепочки Forward, происходит изменение значения TTL в заголовке пакета: TTL = TTL — 1. Связанных с Mangle правил у нас нет, поэтому этот блок нас не интересует:
I / Prerouting / Routing Decision / Forward / Postrouting

Последнее, что происходит, это цепочка Postrouting (Рис. 31.6), отвечающая за изменение в заголовке пакета адреса источника SRC-NAT. Соответствующее правило можно найти в настройках mikrotik (Рис. 31.7):
I / Prerouting / Routing Decision / Forward / Postrouting / L

Тем самым, попадая в точку L, происходит выход с уже измененным в заголовке пакета адресом источника. Так же стоит отметить, что происходит замена TTL и пересчет контрольной суммы.