Update 02.md

chapters/02.md

@@ -28,7 +28,7 @@
 
 При обратном пакете (от ресурса к абоненту) source и destination меняются местами.
 
-<img width="1024" height="1225" alt="image" src="https://github.com/user-attachments/assets/d4b641db-783f-41de-b94b-3211ec2767a3" />
+<img width="1024" alt="image" src="https://github.com/user-attachments/assets/d4b641db-783f-41de-b94b-3211ec2767a3" />
 
 ### Инкапсуляция на стыке оператора
 
@@ -150,6 +150,8 @@
 
 Канал связи оператора физически разрывается и заводится на байпас. Байпас обеспечивает защиту канала: в случае аварии он замыкает линки напрямую, минуя остальное оборудование ТСПУ. В штатном режиме (Inline) байпас прозрачно пропускает трафик дальше — в сторону балансировщика.
 
+<img width="1024" alt="image" src="https://github.com/user-attachments/assets/4879b23b-1602-4cce-90da-44840b7616ce" />
+
 Подробнее о режимах работы байпаса — в [разделе 3](03.md).
 
 ### Этап 2: Балансировщик — фильтрация служебного трафика
@@ -165,6 +167,8 @@
 
 В принципе, с таким трафиком на фильтрах ничего плохого не произойдёт, но лучше его не трогать — это снижает нагрузку и исключает потенциальное влияние на служебные протоколы оператора.
 
+<img width="1024" alt="image" src="https://github.com/user-attachments/assets/e1640f7b-7bfa-4e79-abc5-0bc126f66b3a" />
+
 ### Этап 3: Балансировщик — распределение по фильтрам
 
 Трафик, не попавший под правила байпаса, отправляется в **группу балансировки**. В этой группе подключены все фильтры площадки. Балансировщик распределяет пакеты по фильтрам на основе **хэш-суммы**, вычисляемой по трём параметрам:
@@ -187,40 +191,6 @@
 
 Пакет, попавший на фильтр, проходит через цепочку проверок:
 
-```text
-  Пакет
-    │
-    ▼
-┌──────────────────┐     Нет
-│  IP-пакет?       │──────────► Прозрачный пропуск
-└────────┬─────────┘
-         │ Да
-         ▼
-┌──────────────────┐     Нет
-│  Попал в ACL?    │──────────► Прозрачный пропуск
-│  (привязка к     │
-│   пулу)          │
-└────────┬─────────┘
-         │ Да
-         ▼
-┌──────────────────┐     Нет
-│  Попал в         │──────────► Прозрачный пропуск
-│  DPI-лист?       │
-│  (IP-подсети)    │
-└────────┬─────────┘
-         │ Да
-         ▼
-┌──────────────────┐
-│  Движок DPI      │
-│  (анализ и       │
-│  решение)        │
-└────────┬─────────┘
-         │
-    ┌────┴────┐
-    ▼         ▼
- Пропустить   Заблокировать
-              (drop)
-```
 
 1. **Проверка: IP-пакет или нет.** Если пакет не является IP-пакетом (например, служебный keep-alive от балансировщика), он прозрачно пропускается через парный порт обратно в сеть оператора.
 
@@ -232,6 +202,8 @@
 
 Фильтр работает на уровне **L2** — он не изменяет Ethernet-кадр и не участвует в маршрутизации. С точки зрения сети оператора, фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т.д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ, после чего пакет (в случае пропуска) передаётся дальше в неизменном виде.
 
+<img width="1024" alt="image" src="https://github.com/user-attachments/assets/350122b7-0550-4b28-8dc5-acb2bf06319e" />
+
 ### Особенность: HTTP-редирект и TCP Reset при наличии MPLS
 
 Особый случай возникает, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** при блокировке HTTPS-ресурса.