Сети

Из чего состоит сеть

Сеть - это совокупность устройств, соединённых между собой каналами связи для обмена данными. Любая сеть строится из трёх основных компонентов:

Конечные устройства (хосты) - компьютеры, серверы, принтеры, телефоны
Промежуточные устройства - коммутаторы, маршрутизаторы, точки доступа, межсетевые экраны
Среда передачи данных - медные кабели (витая пара), оптоволокно, радиоволны (Wi-Fi)

Типы сетей

Тип	Описание	Масштаб
LAN	Локальная сеть (Local Area Network)	Офис, здание
WAN	Глобальная сеть (Wide Area Network)	Города, страны
MAN	Городская сеть (Metropolitan Area Network)	Город
WLAN	Беспроводная LAN	Зона покрытия Wi-Fi

Топологии сети

Звезда
все
Кольцо - каждое устройство соединено с двумя соседями, образуя замкнутый цикл
Шина - все устройства на одном общем кабеле (устаревшая)
Полносвязная (mesh) - каждое устройство связано с каждым. Используется в WAN и дата-центрах

Сетевые устройства

Важно!

Понимание различий между хабом, коммутатором и маршрутизатором - одна из базовых вещей для любого DevOps/сетевого инженера.

Хаб (Hub) - уровень 1 OSI

Многопортовый повторитель. Получает сигнал на один порт и ретранслирует его на все остальные. Не анализирует содержимое - работает только с электрическими сигналами. Все устройства делят одну полосу пропускания, один коллизионный домен, работа в half-duplex. Устаревшая технология.

Коммутатор (Switch) - уровень 2 OSI

Интеллектуальное устройство, читающее MAC-адреса в заголовках Ethernet-фреймов. Ведёт таблицу MAC-адресов (CAM table), перенаправляет фреймы только на нужный порт. Каждый порт - отдельный коллизионный домен, full-duplex. Поддерживает VLAN для сегментации broadcast-доменов и STP для защиты от петель. L3-коммутаторы дополнительно умеют маршрутизировать.

Позволяет соединить несколько хостов в одну локальную сеть (LAN).

Маршрутизатор (Router) - уровень 3 OSI

Работает с IP-пакетами, соединяет разные сети. Снимает L2-заголовок, читает IP-адрес назначения, определяет маршрут по таблице маршрутизации, формирует новый L2-заголовок для следующего сегмента. Разделяет broadcast-домены. Может выполнять NAT, фильтрацию (ACL), QoS.

Поскольку маршрутизатор подключён к нескольким сетям, ему назначают по одному IP-адресу от каждой сети. Для хостов в сети маршрутизатор является шлюзом (gateway) - точкой выхода во внешний мир.

Межсетевой экран (Firewall)

Фильтрует трафик на основе правил (ACL). Может работать на уровнях 3-7 OSI. Бывает аппаратным и программным (iptables, nftables, firewalld).

Характеристика	Hub	Switch	Router
Уровень OSI	L1	L2	L3
Адресация	Нет	MAC	IP
Обработка	Broadcast всем	Forwarding на порт	Routing между сетями
Duplex	Half	Full	Full
Коллизионный домен	Один общий	Отдельный на порт	Отдельный на порт
Broadcast-домен	Один общий	Один (или по VLAN)	Отдельный на интерфейс

Модель OSI

Важно!

Модель OSI - фундаментальная концепция. Знание уровней и их функций необходимо для диагностики сетевых проблем.

OSI (Open Systems Interconnection) - эталонная модель из 7 уровней, разработанная ISO в 1984 году. Определяет, как данные передаются по сети от приложения на одном хосте к приложению на другом. В реальном мире полная реализация не появилась, но модель используется повсеместно как теоретический фундамент.

#	Уровень	PDU	Протоколы	Устройства
7	Application (Прикладной)	Данные	HTTP, FTP, SMTP, DNS, SSH, SNMP	Proxy, WAF
6	Presentation (Представления)	Данные	SSL/TLS, JPEG, MPEG, ASCII, GZip	-
5	Session (Сеансовый)	Данные	NetBIOS, RPC, PPTP, SIP	-
4	Transport (Транспортный)	Сегмент/Датаграмма	TCP, UDP, SCTP	-
3	Network (Сетевой)	Пакет	IP, ICMP, IGMP, IPSec	Router, L3-switch
2	Data Link (Канальный)	Кадр (Frame)	Ethernet, PPP, ARP, 802.1Q	Switch, Bridge
1	Physical (Физический)	Биты	Ethernet (физ.), Wi-Fi, DSL, Fiber	Hub, Repeater

Уровни подробнее

L1 - Physical - передача необработанного потока битов через физическую среду. Определяет электрические, оптические и радиохарактеристики: напряжение, частоту, модуляцию, тип разъёмов и кабелей.

L2 - Data Link - передача данных между узлами в пределах одного сегмента. Подуровни: LLC (управление потоком, мультиплексирование) и MAC (управление доступом к среде, MAC-адресация). Коммутатор запоминает MAC на портах и перенаправляет фреймы только на нужный порт.

L3 - Network - логическая адресация и маршрутизация пакетов между разными сетями. Маршрутизатор читает IP-заголовки, определяет лучший путь.

L4 - Transport - сквозная доставка данных между конечными узлами. Сегментация, управление потоком, контроль ошибок. Использует порты для мультиплексирования.

L5 - Session - управление сеансами: установка, поддержание и завершение сессий.

L6 - Presentation - преобразование данных: кодирование, сжатие, шифрование (JPEG, TLS).

L7 - Application - интерфейс между сетевыми сервисами и приложениями (HTTP, SMTP, DNS).

Инкапсуляция

При отправке данных каждый уровень добавляет свой заголовок (header). PDU верхнего уровня становится полезной нагрузкой для нижнего:

[Application Data]
[TCP Header | Application Data]              -> Segment
[IP Header | TCP Header | Application Data]  -> Packet
[Eth Header | IP Header | TCP ... | FCS]     -> Frame
01101001011010...                             -> Bits

При получении происходит обратный процесс - декапсуляция: каждый уровень снимает свой заголовок и передаёт данные вверх.

Модель TCP/IP

Важно!

На практике используется именно модель TCP/IP, а не OSI. Однако терминология OSI (уровни) применяется повсеместно.

Практическая модель, лежащая в основе Интернета. Разработана DARPA в 1970-х. В отличие от OSI, привязана к конкретным протоколам.

TCP/IP	Уровни OSI	Протоколы
Application (Прикладной)	5, 6, 7	HTTP, DNS, SMTP, FTP, SSH, TLS
Transport (Транспортный)	4	TCP, UDP
Internet (Межсетевой)	3	IP, ICMP, ARP
Network Access (Сетевой доступ)	1, 2	Ethernet, Wi-Fi, PPP

Ключевые различия:

OSI - теоретическая (7 уровней), TCP/IP - практическая (4 уровня)
OSI не привязана к протоколам, TCP/IP определяет конкретные
OSI используется для обучения и стандартизации, TCP/IP - для реальной работы

Почему обе модели важны

OSI даёт точный язык для описания сетевых проблем (“проблема на L2”, “фильтрация на L4”). TCP/IP описывает реальный стек протоколов, с которым работает инженер.

Ethernet

Важно!

Ethernet - доминирующая технология канального уровня в LAN. Понимание структуры кадра и MAC-адресов обязательно.

MAC-адрес

48-битный (6 байт) физический адрес сетевого интерфейса. Записывается в hex: AA:BB:CC:DD:EE:FF.

Структура:

Первые 3 байта - OUI (Organizationally Unique Identifier) - идентификатор производителя
Последние 3 байта - уникальный идентификатор устройства

Типы адресов:

Unicast - младший бит первого октета = 0, адресация одному устройству
Multicast - младший бит первого октета = 1 (01:00:5E:xx:xx:xx)
Broadcast - FF:FF:FF:FF:FF:FF, адресация всем в сегменте

Структура кадра Ethernet II

+-----------+-----------+-----------+---------+-----------------------+---+
| Preamble  | Dest MAC  | Src MAC   | Type    | Payload (46-1500 B)   |FCS|
| 7+1 bytes | 6 bytes   | 6 bytes   | 2 bytes |                       |4B |
+-----------+-----------+-----------+---------+-----------------------+---+

Preamble (7 байт) + SFD (1 байт) - синхронизация приёмника
EtherType (2 байта) - тип протокола (0x0800 = IPv4, 0x0806 = ARP, 0x86DD = IPv6)
FCS (4 байта) - контрольная сумма CRC-32

Минимальный размер фрейма - 64 байта, максимальный - 1518 байт (1522 с 802.1Q). Jumbo-фреймы поддерживают payload до 9000 байт.

Типы кабелей

Стандарт	Скорость	Кабель	Макс. длина
100BASE-TX	100 Мбит/с	Cat 5 UTP	100 м
1000BASE-T	1 Гбит/с	Cat 5e/6 UTP	100 м
10GBASE-T	10 Гбит/с	Cat 6a/7 UTP	100 м
1000BASE-SX	1 Гбит/с	MMF (многомод. оптика)	550 м
1000BASE-LX	1 Гбит/с	SMF (одномод. оптика)	5 км
10GBASE-SR	10 Гбит/с	MMF	400 м
10GBASE-LR	10 Гбит/с	SMF	10 км

IP-адресация

Важно!

Знание IP-адресации, масок подсети и CIDR - абсолютно необходимый навык для DevOps.

IPv4

32-битный адрес, записывается в виде четырёх десятичных октетов: 192.168.1.1. Состоит из двух частей: сетевой (network) и хостовой (host). Разделение задаётся маской подсети.

Маска подсети

Определяет границу между сетевой и хостовой частью. Единицы слева - сетевая часть, нули справа - хостовая:

IP:     192.168.1.100  = 11000000.10101000.00000001.01100100
Mask:   255.255.255.0  = 11111111.11111111.11111111.00000000
                         |----- Network -----|---- Host ----|
Net:    192.168.1.0    = 11000000.10101000.00000001.00000000
Bcast:  192.168.1.255  = 11000000.10101000.00000001.11111111

Классы сетей (устаревшая классификация)

Класс	Диапазон	Маска	Сетей	Хостов
A	1.0.0.0 - 126.255.255.255	/8	126	~16.7 млн
B	128.0.0.0 - 191.255.255.255	/16	16 384	65 534
C	192.0.0.0 - 223.255.255.255	/24	~2.1 млн	254
D	224.0.0.0 - 239.255.255.255	-	Multicast	-
E	240.0.0.0 - 255.255.255.255	-	Зарезервирован	-

Частные (RFC 1918) адреса

Важно!

Эти диапазоны не маршрутизируются в интернете и используются в локальных сетях за NAT.

Диапазон	Маска
10.0.0.0 - 10.255.255.255	/8
172.16.0.0 - 172.31.255.255	/12
192.168.0.0 - 192.168.255.255	/16

CIDR (Classless Inter-Domain Routing)

Бесклассовая маршрутизация. Префикс /N указывает количество бит сетевой части. Позволяет выделять блоки произвольного размера.

CIDR	Маска	Хостов
/32	255.255.255.255	1
/30	255.255.255.252	2
/28	255.255.255.240	14
/27	255.255.255.224	30
/26	255.255.255.192	62
/25	255.255.255.128	126
/24	255.255.255.0	254
/16	255.255.0.0	65 534
/8	255.0.0.0	16 777 214

Формула: количество хостов = 2^(32-prefix) - 2 (минус адрес сети и broadcast).

Supernetting (суперсети) - объединение нескольких подсетей в одну запись таблицы маршрутизации. Пример: 172.16.16.0/21 вместо восьми записей /24.

Специальные адреса

Адрес	Назначение
127.0.0.0/8	Loopback (localhost)
169.254.0.0/16	Link-local (APIPA, при отсутствии DHCP)
0.0.0.0	”Все интерфейсы” или “адрес не назначен”
255.255.255.255	Limited broadcast

IPv6

128-битный адрес, записывается в hex через двоеточие: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Правила сокращения:

Ведущие нули в группе можно опустить: 2001:db8:85a3:0:0:8a2e:370:7334
Одну последовательность нулевых групп заменяют на ::: 2001:db8:85a3::8a2e:370:7334
:: можно использовать только один раз

Тип	Префикс	Описание
Global Unicast	`2000::/3`	Аналог публичных IPv4, маршрутизируемый
Link-Local	`fe80::/10`	Автоконфигурация, только в пределах линка
Unique Local	`fc00::/7`	Аналог RFC 1918 (частные адреса)
Multicast	`ff00::/8`	Замена broadcast (в IPv6 нет broadcast)
Loopback	`::1`	Аналог 127.0.0.1

Основные отличия от IPv4:

Адресное пространство: 2^128 вместо 2
Нет broadcast - вместо него multicast
Встроенная поддержка IPSec
Автоконфигурация через SLAAC (без DHCP)
Упрощённый заголовок пакета
NAT не нужен - достаточно адресов

ARP (Address Resolution Protocol)

Важно!

ARP связывает IP-адреса с MAC-адресами в локальной сети. Без ARP невозможна коммуникация на канальном уровне.

Протокол разрешения адресов - связывает IP (L3) с MAC (L2) в пределах одного broadcast-домена. Необходим, потому что Ethernet-фреймы требуют MAC-адрес получателя, а приложения знают только IP.

Процесс работы

1. Host A хочет отправить пакет на 192.168.1.20
   Проверяет ARP-кэш -> записи нет

2. Host A отправляет ARP Request (broadcast)
   Src MAC: AA:AA:AA:AA:AA:AA
   Dst MAC: FF:FF:FF:FF:FF:FF
   "У кого IP 192.168.1.20? Ответьте AA:AA:AA:AA:AA:AA"

3. Все хосты в сегменте получают запрос
   Только хост с IP 192.168.1.20 отвечает

4. Host B отправляет ARP Reply (unicast)
   Src MAC: BB:BB:BB:BB:BB:BB
   "192.168.1.20 это BB:BB:BB:BB:BB:BB"

5. Host A обновляет ARP-кэш
   192.168.1.20 -> BB:BB:BB:BB:BB:BB (TTL ~60-300 сек)

Важные детали

Если получатель в другой подсети, ARP разрешает MAC шлюза (default gateway), а не конечного получателя
Gratuitous ARP (GARP) - хост сам объявляет свою привязку IP-MAC, используется при смене IP, для обнаружения дубликатов и при failover
В IPv6 вместо ARP используется NDP (Neighbor Discovery Protocol)

Безопасность ARP

ARP не имеет встроенной аутентификации - уязвим для ARP spoofing (подмена MAC).

Защита:

Dynamic ARP Inspection (DAI) на коммутаторах
Статические ARP-записи для критичных хостов
DHCP Snooping как база для DAI
Сегментация сети через VLAN

Просмотр: ip neigh show или arp -a

VLAN (Virtual LAN)

Важно!

VLAN - ключевая технология сегментации сети. Используется повсеместно в корпоративных и облачных сетях.

VLAN позволяет разделить один физический коммутатор на несколько логических сегментов (виртуальных сетей). Хосты в разных VLAN не видят друг друга, даже если подключены к одному свитчу.

Зачем нужны VLAN

Сегментация broadcast-доменов - уменьшение broadcast-трафика
Безопасность - изоляция отделов (бухгалтерия, разработка, серверы)
Гибкость - логическая группировка без привязки к физической топологии
Упрощение администрирования - политики на уровне VLAN, а не портов

Типы портов

принадлежит
Trunk - передаёт трафик нескольких VLAN по одному линку. Кадры маркируются тегом 802.1Q. Используется для соединения коммутаторов между собой или с маршрутизатором

802.1Q (dot1q)

Стандарт тегирования кадров. В Ethernet-фрейм вставляется 4-байтовый тег между Source MAC и EtherType:

+----------+----------+------+----------+---------+-----+-----+
| Dst MAC  | Src MAC  | TPID | TCI      | EthType | ... | FCS |
| 6 bytes  | 6 bytes  | 2B   | 2 bytes  | 2 bytes |     | 4B  |
+----------+----------+------+----------+---------+-----+-----+
                       |      |
                   0x8100   PCP(3) + DEI(1) + VID(12)

TPID (Tag Protocol Identifier) - 0x8100, признак 802.1Q фрейма
PCP (Priority Code Point) - 3 бита, приоритет QoS (0-7)
DEI (Drop Eligible Indicator) - 1 бит, маркер для сброса при перегрузке
VID (VLAN ID) - 12 бит, номер VLAN (1-4094)

Native VLAN - трафик передаётся по trunk без тега (по умолчанию VLAN 1). Native VLAN должен совпадать на обоих концах trunk-линка, иначе возможен VLAN hopping (атака).

Inter-VLAN Routing

Для маршрутизации между VLAN нужен L3-устройство:

Router-on-a-stick - один физический интерфейс маршрутизатора с subinterfaces (interface fa0/0.101, encapsulation dot1Q 101)
L3-коммутатор - маршрутизация через SVI (Switch Virtual Interface)

TCP и UDP

Важно!

TCP и UDP - два основных транспортных протокола. DevOps должен понимать разницу для настройки сервисов, файрволов и диагностики.

Порты

16-битное число (0-65535), идентифицирующее приложение/сервис на хосте:

Диапазон	Название	Примеры
0-1023	Well-known	22 (SSH), 53 (DNS), 80 (HTTP), 443 (HTTPS)
1024-49151	Registered	3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 8080 (HTTP alt)
49152-65535	Dynamic/Ephemeral	Временные порты для клиентских соединений

TCP (Transmission Control Protocol)

Надёжный, ориентированный на соединение протокол.

Three-way handshake (установление соединения):

Client                    Server
  |                         |
  |---- SYN (seq=x) ------>|   1. Клиент инициирует, отправляя SYN с ISN
  |                         |
  |<-- SYN-ACK (seq=y, -----|   2. Сервер подтверждает и отвечает своим ISN
  |    ack=x+1)             |
  |                         |
  |---- ACK (ack=y+1) ---->|   3. Клиент подтверждает, соединение установлено

Завершение соединения (four-way):

Client → FIN → Server
Client ← ACK ← Server
Client ← FIN ← Server
Client → ACK → Server

Механизмы надёжности:

Sequence numbers - нумерация каждого байта для сохранения порядка
Acknowledgments (ACK) - подтверждение получения
Retransmission - повторная передача при отсутствии ACK
Flow control - скользящее окно (Sliding Window), защита от переполнения буфера
Congestion control - адаптивное управление скоростью (Slow Start, Congestion Avoidance)

UDP (User Datagram Protocol)

Лёгкий, без установки соединения. Не гарантирует доставку, порядок, отсутствие дубликатов. Минимальные накладные расходы.

Используется для: DNS (53), DHCP (67/68), VoIP/RTP, потоковое видео, VPN (WireGuard, OpenVPN в UDP-режиме), игры.

Сравнение

Характеристика	TCP	UDP
Соединение	Connection-oriented	Connectionless
Надёжность	Гарантированная доставка	Best-effort
Порядок	Гарантирован (seq numbers)	Не гарантирован
Заголовок	20-60 байт	8 байт
Скорость	Медленнее (overhead)	Быстрее
Flow control	Есть (Sliding Window)	Нет

DNS (Domain Name System)

Важно!

DNS - одна из важнейших сетевых служб. Проблемы с DNS - одна из самых частых причин недоступности сервисов.

Иерархическая распределённая система, преобразующая доменные имена в IP-адреса. Работает преимущественно по UDP/53 (TCP/53 для zone transfer и больших ответов).

Иерархия и компоненты

                    . (root)
                   / | \
              .com  .org  .ru
              /       |      \
         google    wikipedia  yandex
           |          |         |
         www        en         mail

DNS Resolver (рекурсивный) - промежуточный сервер, выполняет запросы от имени клиента (8.8.8.8, 1.1.1.1)
Root Name Servers - 13 корневых серверов (a.root-servers.net - m.root-servers.net)
TLD Name Servers - серверы доменов верхнего уровня (.com, .org, .ru)
Authoritative Name Servers - хранят фактические записи для конкретного домена

Типы запросов

Рекурсивный - клиент просит резолвер найти окончательный ответ. Резолвер делает всю работу.

Итеративный - сервер возвращает лучший известный ответ или ссылку (referral) на другой сервер.

На практике: клиент делает рекурсивный запрос к резолверу, а резолвер выполняет серию итеративных запросов по иерархии.

Процесс резолвинга

1. Клиент -> Рекурсивный резолвер: "A-запись для www.example.com?"
2. Резолвер -> Root NS: "Кто отвечает за .com?"
3. Root NS -> Резолвер: referral на TLD NS для .com
4. Резолвер -> .com TLD NS: "Кто отвечает за example.com?"
5. .com TLD NS -> Резолвер: referral на NS для example.com
6. Резолвер -> Authoritative NS: "A-запись для www.example.com?"
7. Authoritative NS -> Резолвер: "93.184.216.34"
8. Резолвер -> Клиент: "93.184.216.34" (кэширует с TTL)

Порядок разрешения на Linux: /etc/nsswitch.conf (поле hosts). По умолчанию: сначала файлы (/etc/hosts), затем DNS.

Типы записей DNS

Тип	Описание	Пример
A	Имя → IPv4	`example.com -> 93.184.216.34`
AAAA	Имя → IPv6	`example.com -> 2606:2800:220:1:...`
CNAME	Алиас на другое имя	`www.example.com -> example.com`
MX	Почтовый сервер (с приоритетом)	`example.com -> mail.example.com (10)`
NS	Авторитетный DNS-сервер	`example.com -> ns1.example.com`
PTR	IP → Имя (reverse DNS)	`34.216.184.93 -> example.com`
TXT	Произвольный текст	SPF, DKIM, DMARC, верификация
SOA	Start of Authority, метаданные зоны	Serial, Refresh, Retry, Expire
SRV	Сервис (порт, протокол, хост)	`_sip._tcp.example.com`
CAA	Разрешённые CA для выпуска сертификатов	`example.com -> letsencrypt.org`

DNS Security

DNS cache poisoning - подмена записей в кэше резолвера
DNSSEC - криптографическая подпись DNS-записей
DoH (DNS over HTTPS) - шифрование DNS через HTTPS
DoT (DNS over TLS) - шифрование через TLS

DHCP (Dynamic Host Configuration Protocol)

Важно!

DHCP автоматизирует назначение IP-адресов. Без понимания DHCP сложно диагностировать проблемы с подключением.

Автоматическое назначение сетевых параметров. Работает по UDP (сервер - порт 67, клиент - порт 68).

Процесс DORA

Client (0.0.0.0)           DHCP Server
  |                              |
  |--- DISCOVER (broadcast) ---->|  1. "Есть ли DHCP-сервер?"
  |    dst: 255.255.255.255      |
  |                              |
  |<--- OFFER -------------------|  2. "Предлагаю IP и параметры"
  |     IP: 192.168.1.10         |
  |                              |
  |--- REQUEST (broadcast) ----->|  3. "Принимаю этот IP"
  |                              |
  |<--- ACKNOWLEDGE -------------|  4. "Подтверждаю, lease 86400s"
  |     mask, gw, dns, lease     |

Продление аренды (Lease Renewal)

T1 (50% lease time) - клиент отправляет unicast DHCP Request серверу
T2 (87.5% lease time) - если T1 не удался, broadcast DHCP Request любому серверу
По истечении lease - адрес освобождается, DORA заново

Что выдаёт DHCP

IP-адрес, маска, default gateway, DNS-серверы, lease time. Опционально: NTP-сервер, WINS, domain name, PXE boot server.

DHCP Relay Agent - если DHCP-сервер в другой подсети, маршрутизатор с ip helper-address перенаправляет broadcast unicast’ом.

HTTP/HTTPS

HTTP (HyperText Transfer Protocol)

Протокол прикладного уровня для передачи гипертекста. Модель запрос-ответ поверх TCP (порт 80).

Версии:

HTTP/1.0 - отдельное TCP-соединение на каждый запрос
HTTP/1.1 - keep-alive, pipelining, chunked transfer
HTTP/2 - мультиплексирование потоков, сжатие заголовков (HPACK), server push
HTTP/3 - поверх QUIC (UDP), устраняет head-of-line blocking TCP

Методы: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS

Коды ответов:

1xx - информационные
2xx - успех (200 OK, 201 Created, 204 No Content)
3xx - перенаправление (301, 302, 304)
4xx - ошибка клиента (400, 401, 403, 404)
5xx - ошибка сервера (500, 502 Bad Gateway, 503 Service Unavailable)

HTTPS и TLS

Важно!

HTTPS = HTTP + TLS. Все современные сервисы обязаны использовать HTTPS.

HTTPS = HTTP поверх TLS (Transport Layer Security). Порт 443. Обеспечивает шифрование, аутентификацию сервера и целостность данных.

TLS 1.2 Handshake:

Client                          Server
  |                                |
  |--- ClientHello --------------->|  Версии TLS, cipher suites,
  |    (ciphers, client random)    |  client random
  |                                |
  |<-- ServerHello + Certificate --|  Выбранный cipher,
  |    + ServerHelloDone           |  server random, сертификат X.509
  |                                |
  |  [Проверка сертификата через CA chain]
  |                                |
  |--- ClientKeyExchange --------->|  Pre-master secret
  |--- ChangeCipherSpec ---------->|  (зашифрован публичным ключом)
  |--- Finished ------------------>|
  |                                |
  |<-- ChangeCipherSpec -----------|
  |<-- Finished -------------------|
  |                                |
  |==== Encrypted Data ============|  Симметричное шифрование

Из client random, server random и pre-master secret обе стороны вычисляют master secret, из которого генерируются симметричные ключи сессии.

TLS 1.3 - handshake за 1 RTT вместо 2 (0-RTT при повторном подключении), убраны устаревшие алгоритмы, все сообщения после ServerHello зашифрованы.

Типы шифрования

Асимметричное (RSA, ECDHE) используется только для обмена ключами. Данные шифруются быстрым симметричным шифром (AES-256-GCM, ChaCha20-Poly1305).

Маршрутизация

Таблица маршрутизации

Каждая запись содержит:

Сеть назначения и маску
Next hop (IP следующего маршрутизатора) или выходной интерфейс
Метрику (стоимость маршрута)
Административную дистанцию (приоритет источника)

Выбор маршрута:

Longest prefix match - самый специфичный маршрут (/28 выигрывает у /24)
Если prefix одинаковый - сравнивается Administrative Distance
Если AD одинаковый - сравнивается метрика

# Linux: просмотр таблицы маршрутизации
ip route show
 
# Добавление статического маршрута
ip route add 172.16.0.0/16 via 10.0.0.1
 
# Маршрут по умолчанию (default gateway)
ip route add default via 10.0.0.1

Administrative Distance

Важно!

AD определяет, какому источнику маршрута доверять больше. Меньше - лучше.

Источник	AD
Connected	0
Static	1
eBGP	20
EIGRP	90
OSPF	110
IS-IS	115
RIP	120
iBGP	200

Статическая маршрутизация

Маршруты задаются вручную. Не реагирует на изменения топологии. Применение: небольшие сети, default route, stub-сети.

Плюсы: простота, предсказуемость, минимальная нагрузка на CPU. Минусы: не масштабируется, не адаптируется.

Route summarization - объединение маршрутов: вместо восьми записей /24 один суммированный ip route 172.16.16.0 255.255.248.0 172.16.2.2.

Динамическая маршрутизация

Протоколы автоматически обмениваются информацией о сетях и строят таблицу маршрутизации.

Протокол	Тип	Алгоритм	Метрика	AD	Область
RIP	Distance Vector	Bellman-Ford	Hop count (max 15)	120	Малые сети
OSPF	Link State	Dijkstra (SPF)	Cost (bandwidth)	110	Средние/крупные
EIGRP	Hybrid	DUAL	Composite (bw, delay)	90	Cisco
BGP	Path Vector	Best path	AS Path, attributes	20 (eBGP)	Интернет
IS-IS	Link State	Dijkstra	Cost	115	Провайдеры

OSPF (Open Shortest Path First)

Самый распространённый IGP. Строит карту топологии (Link-State Database) и вычисляет кратчайшие пути алгоритмом Дейкстры (SPF).

Ключевые понятия:

Area - зона (Area 0 - backbone, обязательна)
Router ID - уникальный идентификатор (рекомендуется Loopback /32)
Hello-пакеты - обнаружение и поддержание соседства
LSA - Link-State Advertisements
DR/BDR - Designated Router в broadcast-сегментах

Требования для соседства:

Hello Interval - должен совпадать (default 10 сек)
Dead Interval - должен совпадать (default 40 сек)
Subnet - одна подсеть
Area - одинаковый номер зоны
Router ID - уникальный
MTU - идентичный

Состояния OSPF: DOWN → INIT → TWO WAY → EXSTART → EXCHANGE → LOADING → FULL

NAT (Network Address Translation)

Важно!

NAT позволяет множеству устройств в приватной сети выходить в интернет через один или несколько публичных IP. Используется повсеместно.

Терминология

Inside Local - частный IP хоста в локальной сети
Inside Global - публичный IP, подставляемый вместо частного
Outside Local - IP внешнего хоста, каким его видит внутренняя сеть
Outside Global - реальный IP внешнего хоста

Типы NAT

Static NAT - фиксированная привязка 1:1. Двунаправленный. Для серверов, доступных извне.

Dynamic NAT - трансляция из пула публичных адресов. Привязка 1:1, но временная. Если пул исчерпан - новые соединения отклоняются.

PAT (Port Address Translation) / NAT Overload - самый распространённый. Множество внутренних IP транслируются в один публичный через разные порты:

192.168.1.10:45000 -> 203.0.113.1:10001 -> 8.8.8.8:53
192.168.1.11:45001 -> 203.0.113.1:10002 -> 8.8.8.8:53
192.168.1.12:45002 -> 203.0.113.1:10003 -> 1.1.1.1:443

Тип	Mapping	Направление	Применение
Static NAT	1:1, постоянный	Bi-directional	Серверы
Dynamic NAT	1:1, временный	Outbound	Ограниченные задачи
PAT	N:1, по портам	Outbound	Домашние/офисные сети

Port Forwarding (проброс портов)

# Linux: iptables
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

Firewall и ACL

Важно!

Настройка файрвола - одна из главных задач DevOps/SysAdmin. Знание iptables/nftables обязательно.

Типы файрволов

Stateless (packet filter) - анализирует каждый пакет независимо по заголовкам. Быстрый, но не отслеживает соединения
Stateful - отслеживает состояние TCP-соединений. Пропускает ответные пакеты автоматически
Application-level (proxy/WAF) - анализирует данные на уровне приложения (HTTP, DNS)
Next-Generation Firewall (NGFW) - объединяет stateful inspection, IPS, application awareness, DPI

ACL (Access Control Lists)

Упорядоченный набор правил permit/deny. Обрабатываются сверху вниз, до первого совпадения. В конце неявное deny all.

Standard ACL - фильтрует только по source IP (ближе к назначению)
Extended ACL - фильтрует по source/dest IP, портам, протоколам (ближе к источнику)

Wildcard маски

Инвертированные маски подсети: нули - фиксированные биты, единицы - произвольные. Расчёт: 255 - октет маски.

Сеть /24 → wildcard 0.0.0.255
Один хост → wildcard 0.0.0.0

iptables (Linux)

Важно!

iptables - основной файрвол в Linux. Знание цепочек и таблиц необходимо.

Таблицы:

filter - основная фильтрация (INPUT, FORWARD, OUTPUT)
nat - трансляция адресов (PREROUTING, POSTROUTING)
mangle - модификация заголовков
raw - обход connection tracking

# iptables: разрешить SSH, HTTP, HTTPS, остальное запретить
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP
 
# nftables (современная замена)
nft add rule inet filter input tcp dport {22, 80, 443} accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input drop

STP (Spanning Tree Protocol)

STP предотвращает петли (loops) на канальном уровне, отключая избыточные линки и оставляя древовидную топологию. Без STP broadcast-шторм может парализовать сеть.

Принцип работы

Выбор корневого коммутатора (Root Bridge) - побеждает наименьший Bridge ID (приоритет + MAC)
На каждом некорневом свитче выбирается Root Port - порт с наименьшей стоимостью пути до Root Bridge
На каждом сегменте выбирается Designated Port - порт, пересылающий кадры к Root Bridge
Остальные порты блокируются (Alternate/Backup)

Состояния портов (802.1D)

Blocking → Listening → Learning → Forwarding (каждый переход ~15 сек)

Варианты STP

Вариант	Стандарт	Сходимость	Особенность
STP	802.1D	30-50 сек	Классический
RSTP	802.1w	~1-3 сек	Быстрая сходимость (Proposal/Agreement)
PVST+	Cisco	30-50 сек	Отдельный STP на каждый VLAN
MSTP	802.1s	~1-3 сек	Группировка VLAN в инстансы

VPN (Virtual Private Network)

Классификация VPN

По уровню OSI:

L2 VPN - VLAN, MPLS L2VPN, VPLS, Pseudo-wire
L3 VPN - GRE, IPSec, MPLS L3VPN, WireGuard, OpenVPN

По архитектуре:

Site-to-Site - соединение двух офисных сетей
Remote Access - подключение удалённого сотрудника
Hub-and-Spoke - центральный узел и филиалы (DMVPN)
Mesh - все со всеми

GRE (Generic Routing Encapsulation)

Простейший туннельный протокол. Инкапсулирует оригинальный пакет в новый IP-пакет с GRE-заголовком. Не обеспечивает шифрования. Поддерживает multicast и динамическую маршрутизацию.

IPSec

Важно!

IPSec - стандартный протокол для шифрованных VPN между площадками.

Три компонента:

ESP (Encapsulating Security Payload) - шифрование + аутентификация
AH (Authentication Header) - только аутентификация и целостность
IKE (Internet Key Exchange) - согласование параметров и обмен ключами

Два режима:

Tunnel Mode - шифрует весь пакет, добавляет новый IP-заголовок (site-to-site)
Transport Mode - шифрует только payload, сохраняет оригинальный IP-заголовок (host-to-host)

GRE over IPSec - GRE обеспечивает туннелирование и динамическую маршрутизацию, IPSec добавляет шифрование.

DMVPN (Dynamic Multipoint VPN)

Cisco-технология, решающая проблему масштабирования hub-and-spoke (full mesh = m*(m-1)/2 туннелей):

Hub с static IP, spokes могут иметь динамические адреса
NHRP (Next-Hop Resolution Protocol) для динамического обнаружения spoke-адресов
Прямая связь spoke-to-spoke без транзита через hub
Поддержка NAT Traversal

WireGuard

Важно!

WireGuard - современный VPN-протокол, активно используемый в DevOps. Встроен в ядро Linux с версии 5.6.

Кодовая база: менее 4000 строк (vs ~100K для OpenVPN)
Криптография: ChaCha20, Curve25519, BLAKE2s, SipHash24
Работает как модуль ядра Linux (минимальный overhead)
Connectionless design - UDP-инкапсуляция
Быстрое переподключение при смене сети (роуминг)

# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <private_key>
Address = 10.0.0.1/24
ListenPort = 51820
 
[Peer]
PublicKey = <peer_public_key>
AllowedIPs = 10.0.0.2/32
Endpoint = peer.example.com:51820

OpenVPN

Open-source VPN на базе SSL/TLS. Работает в userspace. Режимы: TCP (надёжный) и UDP (быстрый). Гибкая конфигурация, сертификатная аутентификация. Может работать через порт 443, обходя файрволы.

Сравнение VPN

Характеристика	IPSec	OpenVPN	WireGuard
Уровень OSI	L3	L7 (TLS)	L3
Скорость	Средняя	Средняя	Высокая
Кодовая база	Большая	Большая	~4K строк
Настройка	Сложная	Средняя	Простая
Аудит	Сложно	Сложно	Легко
Best for	Site-to-site, enterprise	High-security, гибкость	Скорость, мобильные

BGP (Border Gateway Protocol)

Важно!

BGP - протокол маршрутизации интернета. DevOps необходимо понимать основы BGP для работы с провайдерами, анонсами сетей и anycast.

Единственный используемый EGP (External Gateway Protocol). Обеспечивает обмен маршрутной информацией между автономными системами (AS). Относится к типу Path Vector.

Основные понятия

AS (Autonomous System) - группа IP-сетей под единым административным управлением с единой политикой маршрутизации. Уникальный ASN (16 или 32 бита), назначаемый через IANA → RIR → LIR
eBGP (External) - между разными AS. AD = 20
iBGP (Internal) - внутри одной AS. AD = 200. Требует full-mesh или Route Reflectors

eBGP vs iBGP

Различие	eBGP	iBGP
Предотвращение петель	AS-Path (отбрасывает маршруты со своим ASN)	Full mesh + Split Horizon
Next-Hop	Меняет на свой адрес	Не меняет (указывает точку выхода из AS)
Соседство	Обычно прямое соединение	Через промежуточные устройства (Loopback)

Установление сессии

BGP работает поверх TCP (порт 179). Состояния FSM:

IDLE → CONNECT → ACTIVE → OPEN SENT → OPEN CONFIRM → ESTABLISHED

BGP Best Path Selection

Highest LOCAL_PREF (предпочтения оператора)
Shortest AS_PATH (меньше промежуточных AS)
Lowest ORIGIN type (IGP < EGP < Incomplete)
Lowest MED (подсказка от соседа)
eBGP over iBGP
Lowest IGP metric to next hop
Lowest Router ID

AS-Path - главный механизм предотвращения петель: маршрут, содержащий собственный AS-номер, отбрасывается.

BGP для DevOps

Anycast DNS/CDN - один IP анонсируется из нескольких точек присутствия
DDoS mitigation - перенаправление трафика через scrubbing center
Multi-homing - подключение к нескольким провайдерам для отказоустойчивости
Cloud networking - BGP peering с AWS Direct Connect, GCP Cloud Interconnect, Azure ExpressRoute
Kubernetes - Calico и MetalLB используют BGP для анонса сервисных IP

BGP Security

RPKI (Resource Public Key Infrastructure) - криптографическая проверка, что AS имеет право анонсировать префикс
ROA (Route Origin Authorization) - подписанная запись, связывающая префикс с ASN
BGP hijacking - злоумышленник анонсирует чужие префиксы, перехватывая трафик
Route filtering - ACL на принятие/анонс маршрутов

MPLS (Multiprotocol Label Switching)

MPLS - технология коммутации пакетов по меткам вместо анализа IP-заголовков. Работает как “Layer 2.5” между канальным и сетевым уровнями. Широко используется провайдерами.

Терминология

Термин	Определение
Label	Значение 0-1048575, используемое для forwarding
Label Stack	Стек меток на пакете, forwarding по верхней (LIFO)
FEC	Forwarding Equivalence Class - классы трафика для LSP
LSP	Label Switched Path - однонаправленный путь от Ingress к Egress
LSR	Label Switch Router - любой маршрутизатор с label-операциями
LER	Label Edge Router - граничные маршрутизаторы (Ingress/Egress)
LIB	Label Information Base - таблица меток
LFIB	Label Forwarding Information Base - быстрая таблица пересылки

Операции с метками

Операция	Где	Действие
Push	Ingress LSR	Добавить метку к пакету
Swap	Transit LSR	Заменить метку на другую
Pop	Egress LSR	Снять верхнюю метку

MPLS Header (32 бита)

Поле	Бит	Назначение
Label	20	Значение метки
TC (Traffic Class)	3	Приоритет QoS
S (Bottom of Stack)	1	S=1 - последняя метка
TTL	8	Защита от петель

Применение

MPLS L2VPN - Pseudowire, VPLS (эмуляция L2-сервисов)
MPLS L3VPN - изолированные VPN через VRF, Route Targets, MP-BGP
Traffic Engineering - управление путями через RSVP-TE и CSPF

Иерархическая модель сети

Классическая архитектура корпоративной сети из трёх уровней:

Core (Ядро)

Высокопроизводительные устройства, главное назначение - быстрый транспорт данных. Минимум фильтрации, максимум пропускной способности.

Distribution (Распределение)

Применение политик безопасности, QoS, агрегация VLAN и маршрутизация между ними. Определяет границы broadcast-доменов.

Access (Доступ)

L2-коммутаторы, к которым подключаются конечные устройства. Тегирование QoS, предотвращение петель (STP), защита от broadcast-штормов, PoE.

Spine-Leaf (Clos) - дата-центры

В современных дата-центрах используется архитектура Spine-Leaf:

Spine - транзитный уровень (аналог Core)
Leaf - уровень подключения серверов (аналог Access)
Каждый Leaf подключён к каждому Spine (full mesh)
ECMP для балансировки нагрузки

Сетевая диагностика в Linux

Важно!

Инструменты сетевой диагностики - ежедневный инструментарий DevOps-инженера.

ip - управление интерфейсами (iproute2)

ip addr show                    # IP-адреса и маски
ip link show                    # состояние интерфейсов (up/down)
ip route show                   # таблица маршрутизации
ip neigh show                   # ARP-таблица (соседи)
 
ip addr add 192.168.1.100/24 dev eth0   # добавить IP
ip link set eth0 up                      # поднять интерфейс
ip route add 10.0.0.0/8 via 192.168.1.1 # добавить маршрут
ip link add link eth0 name eth0.100 type vlan id 100  # VLAN-интерфейс

ping / traceroute / mtr

ping -c 4 8.8.8.8                    # ICMP echo
ping -s 1472 -M do 8.8.8.8           # проверка MTU
 
traceroute -I 8.8.8.8                # через ICMP
traceroute -T -p 443 8.8.8.8         # через TCP (обходит файрволы)
mtr 8.8.8.8                          # интерактивный traceroute + ping

DNS-диагностика

dig example.com                       # A-запись
dig @8.8.8.8 example.com MX          # конкретный тип через конкретный DNS
dig +short example.com                # короткий ответ
dig +trace example.com                # трассировка всего пути
dig -x 8.8.8.8                        # reverse DNS
dig +dnssec example.com               # проверка DNSSEC
nslookup example.com                  # только DNS (не /etc/hosts)

ss - статистика сокетов

ss -tulpn                             # все слушающие TCP/UDP порты с PID
ss -tlnp sport = :443                 # фильтр по порту
ss state established                  # установленные соединения
ss -ti                                # подробно (таймеры, congestion)
ss -s                                 # общая статистика

Проверка портов и соединений

lsof -i -P -n                        # открытые сетевые файлы
curl -v https://example.com           # HTTP с деталями и TLS handshake
curl --resolve example.com:443:93.184.216.34 https://example.com  # через конкретный IP
curl --connect-timeout 5 --max-time 10 https://example.com        # с таймаутами
nc -zv host 80                        # netcat проверка порта
telnet host 3306                      # проверка TCP-порта

tcpdump - захват пакетов

tcpdump -i eth0 tcp port 443                    # TCP на порт 443
tcpdump -i eth0 host 192.168.1.1                # трафик хоста
tcpdump -i eth0 -w capture.pcap                 # запись для Wireshark
tcpdump -i eth0 udp port 53                     # DNS-запросы
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'  # только SYN-пакеты
tcpdump -i eth0 -c 100 -A -vv                   # 100 пакетов с ASCII

nmap - сканирование

nmap 192.168.1.1                      # top 1000 портов
nmap -p 22,80,443 192.168.1.1         # конкретные порты
nmap -sn 192.168.1.0/24               # обнаружение хостов в подсети
nmap -O -sV 192.168.1.1               # определение ОС и версий сервисов
nmap -sS 192.168.1.1                  # TCP SYN scan (stealth)
nmap --script vuln 192.168.1.1        # скрипты на уязвимости

Алгоритм устранения проблем

1. ip a / ip l          -> Интерфейс поднят? IP назначен?
2. ip r                 -> Маршрут есть? Default gateway?
3. ping gateway         -> Связь до шлюза?
4. ping 8.8.8.8         -> Связь до Интернета (L3)?
5. dig example.com      -> DNS работает?
6. curl https://...     -> HTTP/HTTPS работает?
7. ss -tlnp             -> Сервис слушает порт?
8. tcpdump              -> Что происходит на уровне пакетов?
9. iptables -L -n       -> Правила файрвола?
10. traceroute          -> Где теряются пакеты?

CNI (Container Network Interface) в Kubernetes

CNI - это спецификация и набор библиотек для настройки сетевых интерфейсов Linux-контейнеров. Kubernetes делегирует всю сетевую конфигурацию pod’ов CNI-плагину.

Спецификация CNI

CNI определяет контракт между container runtime и сетевым плагином. Runtime вызывает плагин как исполняемый файл с передачей конфигурации через stdin и переменные окружения.

Жизненный цикл операций:

Операция	Когда вызывается	Что делает
ADD	Создание pod	Создаёт veth pair, назначает IP, настраивает маршруты
DEL	Удаление pod	Удаляет интерфейс, освобождает IP
CHECK	Периодически	Проверяет корректность сетевой конфигурации
VERSION	При инициализации	Возвращает поддерживаемые версии CNI

Kubernetes network model требует от CNI-плагина:

Каждый pod получает уникальный IP-адрес
Pod’ы на одной ноде общаются без NAT
Pod’ы на разных нодах общаются без NAT
Агенты на ноде общаются с pod’ами без NAT

Flannel

Простейший overlay-сетевой плагин. Создаёт VXLAN-туннели между нодами, инкапсулируя pod-трафик в UDP-пакеты.

Как работает:

Flanneld на каждой ноде получает подсеть из общего CIDR
Создаёт VXLAN-интерфейс (flannel.1)
Настраивает bridge (cni0) для локальных pod’ов
Маршруты между нодами через VXLAN overlay

# Установка Flannel
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
 
# Проверка работы
kubectl get pods -n kube-flannel
kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'

Ограничения:

Нет поддержки NetworkPolicy
Только VXLAN и host-gw backend
Минимальный функционал, нет L7-фильтрации
Ограниченная observability

Calico

Полноценное сетевое решение с поддержкой BGP routing, IPIP/VXLAN overlay и NetworkPolicy enforcement.

Режимы работы:

BGP routing - прямая маршрутизация без overlay, максимальная производительность
IPIP overlay - IP-in-IP инкапсуляция для сетей без BGP
VXLAN overlay - L2 over L3, совместимость с облачными провайдерами
eBPF dataplane - замена iptables на eBPF-программы для ускорения обработки пакетов

# Calico NetworkPolicy - запретить весь ingress, разрешить только порт 8080
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-8080
  namespace: production
spec:
  selector: app == 'web'
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 8080
  egress:
    - action: Allow
 
---
# GlobalNetworkPolicy - блокировка трафика между namespace'ами
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-cross-namespace
spec:
  namespaceSelector: environment == 'production'
  ingress:
    - action: Allow
      source:
        namespaceSelector: environment == 'production'
    - action: Deny

Felix и BIRD

Calico состоит из двух ключевых компонентов: Felix (агент на каждой ноде, управляет iptables/eBPF правилами и маршрутами) и BIRD (BGP daemon, распространяет маршруты между нодами).

Cilium

Сетевой плагин нового поколения, построенный на eBPF. Обеспечивает сетевую связность, безопасность и observability на уровнях L3/L4/L7.

Ключевые возможности:

eBPF dataplane - обработка пакетов в ядре без iptables
L7 policy - фильтрация по HTTP-методам, путям, заголовкам, gRPC-методам
Hubble - встроенная система наблюдаемости за сетевыми потоками
Service Mesh - sidecar-free mesh через eBPF
ClusterMesh - связь pod’ов между разными кластерами

# Cilium L7 Network Policy - разрешить только GET /api/v1/users
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-api-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/users"
              - method: GET
                path: "/api/v1/health"

# Установка Cilium через Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.15.0 \
  --namespace kube-system \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true
 
# Проверка статуса
cilium status
cilium connectivity test
 
# Hubble - наблюдение за потоками
hubble observe --namespace production
hubble observe --verdict DROPPED

Weave Net

Mesh-сетевой плагин с автоматическим обнаружением нод и опциональным шифрованием трафика (NaCl encryption). Простая установка, но уступает Calico и Cilium по производительности и функциональности.

Сравнение CNI-плагинов

Характеристика	Flannel	Calico	Cilium	Weave Net
Network Model	Overlay (VXLAN)	BGP / IPIP / VXLAN	eBPF	Mesh overlay
NetworkPolicy	Нет	Да + GlobalNetworkPolicy	Да + L7 policy	Да (базовая)
eBPF dataplane	Нет	Да (опционально)	Да (по умолчанию)	Нет
Encryption	Нет	WireGuard	WireGuard / IPSec	NaCl
Service Mesh	Нет	Нет	Да (sidecar-free)	Нет
Observability	Минимальная	Prometheus metrics	Hubble (flows, DNS, HTTP)	Weave Scope
Производительность	Средняя	Высокая (BGP)	Высокая (eBPF)	Средняя
Сложность настройки	Низкая	Средняя	Средняя-высокая	Низкая
Best for	Dev/test, простые кластеры	Production, multi-tenant	Production, L7 security	Небольшие кластеры

Рекомендация по выбору

Для production-кластеров выбирайте Calico или Cilium. Flannel подходит для dev/test окружений, где не нужны NetworkPolicy. Cilium предпочтительнее при необходимости L7-фильтрации и sidecar-free service mesh.

Cloud Networking

VPC Peering

VPC Peering создаёт прямое сетевое соединение между двумя VPC. Трафик маршрутизируется по приватной сети провайдера, не проходя через интернет.

Настройка:

Создание peering connection (инициатор + акцептор)
Обновление route tables в обоих VPC
Настройка Security Groups / NACLs для разрешения трафика

# Terraform - VPC Peering между двумя VPC
resource "aws_vpc_peering_connection" "app_to_db" {
  vpc_id        = aws_vpc.app.id
  peer_vpc_id   = aws_vpc.database.id
  peer_region   = "eu-west-1"
  auto_accept   = false
 
  tags = {
    Name = "app-to-database"
  }
}
 
resource "aws_route" "app_to_db" {
  route_table_id            = aws_route_table.app.id
  destination_cidr_block    = "10.1.0.0/16"
  vpc_peering_connection_id = aws_vpc_peering_connection.app_to_db.id
}

Ограничения VPC Peering:

Non-transitive - если VPC-A связан с VPC-B и VPC-B с VPC-C, VPC-A не видит VPC-C
CIDR не должны пересекаться
Один peering на пару VPC
DNS resolution требует отдельного включения

Transit Gateway

Hub-and-spoke архитектура для соединения множества VPC и on-premises сетей через единую точку.

        VPC-A ──┐
        VPC-B ──┤
        VPC-C ──┼── Transit Gateway ──── On-Premises (VPN/DX)
        VPC-D ──┤
  Shared Svc ──┘

Преимущества перед VPC Peering:

Транзитивная маршрутизация - все VPC видят друг друга через TGW
Централизованное управление маршрутами через route tables
Attachments - VPC, VPN, Direct Connect, peering с другим TGW
Масштабируется до тысяч VPC

resource "aws_ec2_transit_gateway" "main" {
  description                     = "Central TGW"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  dns_support                     = "enable"
 
  tags = {
    Name = "main-tgw"
  }
}
 
resource "aws_ec2_transit_gateway_vpc_attachment" "app" {
  subnet_ids         = aws_subnet.private[*].id
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.app.id
}

PrivateLink и VPC Endpoints

Доступ к AWS-сервисам и сервисам третьих сторон через приватную сеть, без выхода в интернет.

Тип	Протокол	Применение
Gateway Endpoint	Маршрутизация	S3, DynamoDB (бесплатно)
Interface Endpoint	ENI + PrivateLink	Все остальные сервисы (SQS, SNS, ECR, KMS)

# Gateway Endpoint для S3
resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.eu-west-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = [aws_route_table.private.id]
}
 
# Interface Endpoint для ECR
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.eu-west-1.ecr.api"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpce.id]
  private_dns_enabled = true
}

VPN - Site-to-Site и Client VPN

Site-to-Site VPN - IPSec-туннели между облаком и on-premises. Два туннеля для HA, подключение через Virtual Private Gateway или Transit Gateway.

Client VPN - OpenVPN-совместимый VPN для удалённого доступа сотрудников. Поддерживает сертификатную и AD-аутентификацию.

Direct Connect / Interconnect

Выделенное физическое соединение между дата-центром и облачным провайдером. Стабильная latency, высокая пропускная способность (1/10/100 Gbps), не проходит через интернет.

Провайдер	Сервис	Скорости
AWS	Direct Connect	1, 10, 100 Gbps
GCP	Cloud Interconnect	10, 100 Gbps (Dedicated)
Azure	ExpressRoute	1, 2, 5, 10, 100 Gbps

Выбор между VPN и Direct Connect

VPN подходит для быстрого старта и небольших объёмов трафика. Direct Connect нужен при требованиях к стабильной latency, высокой пропускной способности или передаче больших объёмов данных. Часто используют оба варианта - Direct Connect как основной канал, VPN как backup.

DNS в Kubernetes

CoreDNS

CoreDNS - DNS-сервер по умолчанию в Kubernetes. Работает как Deployment в namespace kube-system, обычно с 2 репликами. Каждый pod получает /etc/resolv.conf с адресом CoreDNS ClusterIP.

Архитектура CoreDNS основана на plugin chain. Запрос проходит через цепочку плагинов, определённых в Corefile.

# Corefile - конфигурация CoreDNS
.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
        max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}

Основные плагины:

Плагин	Назначение
kubernetes	Обслуживает DNS-записи для Services и Pods
forward	Пересылает запросы upstream DNS-серверам
cache	Кэширует DNS-ответы
rewrite	Переписывает DNS-запросы
log	Логирование запросов для отладки
prometheus	Метрики на :9153
health	Healthcheck на :8080/health
ready	Readiness на :8181/ready

# Добавить rewrite правило в CoreDNS ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
        }
        rewrite name legacy-api.company.com api-service.production.svc.cluster.local
        forward . 8.8.8.8 8.8.4.4
        cache 30
        loop
        reload
        loadbalance
    }

Service Discovery через DNS

Kubernetes создаёт DNS-записи для каждого Service автоматически.

Формат A-записи для ClusterIP Service:

<service-name>.<namespace>.svc.cluster.local

Примеры:

# Из pod'а в том же namespace
curl http://api-service:8080/health
 
# Из pod'а в другом namespace
curl http://api-service.production.svc.cluster.local:8080/health
 
# SRV-запись (порт и протокол)
dig _http._tcp.api-service.production.svc.cluster.local SRV

Headless Service - Service без ClusterIP (clusterIP: None). DNS возвращает IP-адреса всех pod’ов напрямую. Используется для StatefulSet, где нужен доступ к конкретным pod’ам.

apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: production
spec:
  clusterIP: None
  selector:
    app: postgres
  ports:
    - port: 5432
---
# DNS-записи для StatefulSet pod'ов:
# postgres-0.postgres.production.svc.cluster.local
# postgres-1.postgres.production.svc.cluster.local
# postgres-2.postgres.production.svc.cluster.local

External-DNS

External-DNS автоматически создаёт DNS-записи во внешних DNS-провайдерах на основе Kubernetes-ресурсов.

Поддерживаемые провайдеры: Route53, CloudFlare, Google Cloud DNS, Azure DNS, DigitalOcean и другие.

# Установка External-DNS для Route53
apiVersion: apps/v1
kind: Deployment
metadata:
  name: external-dns
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: external-dns
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      serviceAccountName: external-dns
      containers:
        - name: external-dns
          image: registry.k8s.io/external-dns/external-dns:v0.14.0
          args:
            - --source=service
            - --source=ingress
            - --domain-filter=example.com
            - --provider=aws
            - --policy=upsert-only
            - --aws-zone-type=public
            - --registry=txt
            - --txt-owner-id=my-cluster
 
---
# Ingress с аннотацией для External-DNS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    external-dns.alpha.kubernetes.io/hostname: api.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

ndots и DNS Resolution Performance

По умолчанию Kubernetes устанавливает ndots:5 в /etc/resolv.conf pod’а. Это означает, что любое имя с менее чем 5 точками сначала будет искаться через search domains.

# /etc/resolv.conf внутри pod'а
nameserver 10.96.0.10
search production.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Проблема: запрос к api.external-service.com (2 точки, < 5) генерирует 4 лишних DNS-запроса:

1. api.external-service.com.production.svc.cluster.local  -> NXDOMAIN
2. api.external-service.com.svc.cluster.local             -> NXDOMAIN
3. api.external-service.com.cluster.local                  -> NXDOMAIN
4. api.external-service.com.                               -> OK

Оптимизация:

# Вариант 1: уменьшить ndots в pod spec
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"
  containers:
    - name: app
      image: myapp:1.0.0

# Вариант 2: использовать FQDN с точкой на конце в коде
# Вместо: api.external-service.com
# Писать: api.external-service.com.
# Это говорит резолверу: имя абсолютное, не добавляй search domains

Влияние на производительность

В высоконагруженных системах лишние DNS-запросы создают заметную нагрузку на CoreDNS. Снижение ndots до 2 или использование FQDN с trailing dot может сократить DNS-трафик в 4-5 раз для внешних доменов.

TLS и Certificate Management

Cert-Manager

Cert-Manager - контроллер Kubernetes для автоматического выпуска и обновления TLS-сертификатов. Поддерживает Let’s Encrypt, HashiCorp Vault, Venafi и self-signed CA.

# Установка cert-manager
helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true

Ключевые CRD:

CRD	Scope	Назначение
Issuer	Namespace	Выпускает сертификаты в одном namespace
ClusterIssuer	Cluster	Выпускает сертификаты в любом namespace
Certificate	Namespace	Запрос на выпуск сертификата
CertificateRequest	Namespace	Внутренний запрос (создаётся автоматически)

Let’s Encrypt - автоматические сертификаты

# ClusterIssuer для Let's Encrypt production
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: devops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      # HTTP-01 challenge - требует доступный из интернета Ingress
      - http01:
          ingress:
            ingressClassName: nginx
      # DNS-01 challenge - для wildcard-сертификатов и приватных кластеров
      - dns01:
          route53:
            region: eu-west-1
        selector:
          dnsZones:
            - "example.com"
 
---
# Certificate для домена
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
  namespace: production
spec:
  secretName: api-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
    - "*.api.example.com"
  duration: 2160h    # 90 дней
  renewBefore: 360h  # обновить за 15 дней до истечения
 
---
# Ingress с автоматическим TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

Типы challenge:

Challenge	Механизм	Wildcard	Приватный кластер
HTTP-01	Файл на /.well-known/acme-challenge/	Нет	Нет
DNS-01	TXT-запись _acme-challenge.domain	Да	Да

Self-signed и CA сертификаты

# Self-signed CA для внутренних сервисов
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
 
---
# Корневой CA-сертификат
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: internal-ca
  secretName: internal-ca-secret
  duration: 87600h  # 10 лет
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
 
---
# ClusterIssuer на базе internal CA
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-ca-issuer
spec:
  ca:
    secretName: internal-ca-secret

mTLS (Mutual TLS)

Стандартный TLS аутентифицирует только сервер. mTLS добавляет аутентификацию клиента - обе стороны предъявляют сертификаты.

Когда использовать mTLS:

Межсервисная коммуникация в микросервисной архитектуре
Zero-trust networking - не доверять сети, проверять каждый запрос
API между организациями
Замена API-ключей и токенов на сертификатную аутентификацию

Реализации в Kubernetes:

Istio - автоматический mTLS между sidecar-прокси
Linkerd - автоматический mTLS без конфигурации
Cilium - mTLS через eBPF без sidecar’ов
Ручная настройка через cert-manager + NGINX/Envoy

# Istio PeerAuthentication - обязательный mTLS для namespace
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT

mTLS overhead

mTLS добавляет latency на TLS handshake при установке соединения. Service mesh решают это через connection pooling и persistent connections между sidecar’ами. Cilium минимизирует overhead, работая в ядре через eBPF.

Практические сценарии troubleshooting

Сценарий 1: Pod не может достучаться до другого сервиса

Симптомы: HTTP timeout, connection refused, connection reset при попытке обращения pod’а к другому сервису внутри кластера.

Диагностика:

# 1. Проверить, что целевой Service существует и имеет endpoints
kubectl get svc api-service -n production
kubectl get endpoints api-service -n production
 
# Если endpoints пусто - selector не совпадает с labels pod'ов
kubectl get pods -n production --show-labels | grep api
 
# 2. Проверить DNS-резолвинг из pod'а-источника
kubectl exec -it client-pod -n production -- nslookup api-service
kubectl exec -it client-pod -n production -- nslookup api-service.production.svc.cluster.local
 
# 3. Проверить сетевую доступность
kubectl exec -it client-pod -n production -- curl -v http://api-service:8080/health
kubectl exec -it client-pod -n production -- nc -zv api-service 8080
 
# 4. Проверить NetworkPolicy
kubectl get networkpolicies -n production
kubectl describe networkpolicy -n production
 
# 5. Проверить, что target pod слушает правильный порт
kubectl exec -it api-pod -n production -- ss -tlnp
kubectl exec -it api-pod -n production -- curl localhost:8080/health
 
# 6. Проверить readiness probe целевого pod'а
kubectl describe pod api-pod -n production | grep -A5 Readiness
kubectl get pods -n production -o wide

Решение:

Причина	Решение
Endpoints пусто	Исправить selector в Service или labels в pod
DNS не резолвится	Проверить CoreDNS (сценарий 2)
Connection refused	Pod не слушает порт или containerPort неверный
Connection timeout	NetworkPolicy блокирует, или pod на другой ноде недоступен
Readiness probe fails	Pod не готов принимать трафик, проверить логи

Сценарий 2: DNS не резолвится в Pod

Симптомы: nslookup возвращает NXDOMAIN или timeout. Внутренние и внешние домены не резолвятся.

Диагностика:

# 1. Проверить /etc/resolv.conf внутри pod'а
kubectl exec -it my-pod -- cat /etc/resolv.conf
# Должен содержать nameserver <CoreDNS ClusterIP>
 
# 2. Проверить, что CoreDNS pods работают
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50
 
# 3. Проверить CoreDNS Service
kubectl get svc kube-dns -n kube-system
# ClusterIP должен совпадать с nameserver в resolv.conf
 
# 4. Проверить CoreDNS ConfigMap (Corefile)
kubectl get configmap coredns -n kube-system -o yaml
 
# 5. Тестировать DNS напрямую
kubectl exec -it my-pod -- dig @10.96.0.10 kubernetes.default.svc.cluster.local
kubectl exec -it my-pod -- dig @10.96.0.10 google.com
 
# 6. Запустить debug pod если в целевом pod'е нет dig/nslookup
kubectl run dns-debug --image=nicolaka/netshoot --rm -it -- bash
dig @10.96.0.10 api-service.production.svc.cluster.local

Решение:

Причина	Решение
CoreDNS pods в CrashLoopBackOff	Проверить логи, часто ошибка в Corefile
Неверный nameserver в resolv.conf	Проверить kubelet —cluster-dns flag
Upstream DNS недоступен	Проверить forward в Corefile, network connectivity нод
Corefile loop detection	Убрать loop-ссылки (forward на самого себя)

Сценарий 3: Внешний трафик не доходит до приложения

Симптомы: при обращении к публичному URL приложения - 502, 503 или timeout.

Диагностика (от внешнего к внутреннему):

# 1. Проверить DNS внешнего домена
dig api.example.com
# IP должен указывать на Load Balancer / Ingress Controller
 
# 2. Проверить Ingress resource
kubectl get ingress -n production
kubectl describe ingress api -n production
# Проверить: host, path, backend service, TLS
 
# 3. Проверить Ingress Controller
kubectl get pods -n ingress-nginx
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100
 
# 4. Проверить Service
kubectl get svc api-service -n production
kubectl get endpoints api-service -n production
 
# 5. Проверить targetPort - частая ошибка
kubectl get svc api-service -n production -o yaml | grep -A5 ports
# targetPort должен совпадать с containerPort в Deployment
 
# 6. Проверить, что pod отвечает
kubectl port-forward svc/api-service -n production 8080:8080
curl localhost:8080/health
 
# 7. Проверить LoadBalancer Service (если используется)
kubectl get svc -n ingress-nginx
# EXTERNAL-IP не должен быть <pending>

Чеклист от внешнего к внутреннему:

DNS → LoadBalancer → Ingress Controller → Ingress Rule → Service → Endpoints → Pod

Сценарий 4: Потеря пакетов между нодами

Симптомы: периодические таймауты при обращении к pod’ам на других нодах. Pod’ы на одной ноде работают нормально.

Диагностика:

# 1. Проверить MTU - частая проблема с overlay сетями
# VXLAN добавляет 50 байт overhead, IPIP - 20 байт
kubectl exec -it pod-on-node1 -- ping -s 1450 -M do <pod-ip-on-node2>
# Если пакеты теряются, уменьшить размер до прохождения
 
# 2. Проверить состояние CNI на нодах
kubectl get pods -n kube-system -o wide | grep -E "calico|cilium|flannel"
kubectl logs -n kube-system <cni-pod-on-affected-node> --tail=100
 
# 3. Проверить сетевые интерфейсы на нодах
# На ноде:
ip link show
ip addr show flannel.1    # или tunl0 для IPIP, cilium_host для Cilium
ip route show
 
# 4. Проверить iptables/nftables на нодах
iptables -L -n -v | head -50
iptables -t nat -L -n -v | head -50
 
# 5. Проверить межнодовую связность на уровне underlay
# С ноды 1 пингуем IP ноды 2
ping <node2-ip>
traceroute <node2-ip>
 
# 6. Захват пакетов на overlay-интерфейсе
tcpdump -i flannel.1 -c 100 host <target-pod-ip>

Решение:

Причина	Решение
MTU mismatch	Настроить MTU на CNI (overlay MTU = underlay MTU - overhead)
CNI pod не работает	Перезапустить CNI DaemonSet, проверить логи
iptables rules конфликтуют	Проверить custom rules, kube-proxy mode
Cloud Security Group	Разрешить протокол overlay (VXLAN UDP 8472, IPIP protocol 4)
Node network issue	Проверить underlay сеть, NIC errors, cable

Общий подход к сетевому troubleshooting в Kubernetes

Всегда идите от простого к сложному: DNS, Service, Endpoints, Pod, NetworkPolicy, CNI, underlay. Используйте debug pod с netshoot для диагностики (kubectl run debug --image=nicolaka/netshoot --rm -it -- bash). Проверяйте каждый слой сетевого стека последовательно.

Источники

linkmeup - Сети для самых маленьких

linkmeup.ru - СДСМ

linkmeup - Коммутация

linkmeup - ACL и NAT

linkmeup - Динамическая маршрутизация

linkmeup - VPN

linkmeup - BGP

linkmeup - MPLS

Base

Проводник

Сети

Из чего состоит сеть

Типы сетей

Топологии сети

Сетевые устройства

Хаб (Hub) - уровень 1 OSI

Коммутатор (Switch) - уровень 2 OSI

Маршрутизатор (Router) - уровень 3 OSI

Межсетевой экран (Firewall)

Модель OSI

Уровни подробнее

Инкапсуляция

Модель TCP/IP

Ethernet

MAC-адрес

Структура кадра Ethernet II

Типы кабелей

IP-адресация

IPv4

Маска подсети

Классы сетей (устаревшая классификация)

Частные (RFC 1918) адреса

CIDR (Classless Inter-Domain Routing)

Специальные адреса

IPv6

ARP (Address Resolution Protocol)

Процесс работы

Важные детали

Безопасность ARP

VLAN (Virtual LAN)

Зачем нужны VLAN

Типы портов

802.1Q (dot1q)

Inter-VLAN Routing

TCP и UDP

Порты

TCP (Transmission Control Protocol)

UDP (User Datagram Protocol)

Сравнение

DNS (Domain Name System)

Иерархия и компоненты

Типы запросов

Процесс резолвинга

Типы записей DNS

DNS Security

DHCP (Dynamic Host Configuration Protocol)

Процесс DORA

Продление аренды (Lease Renewal)

Что выдаёт DHCP

HTTP/HTTPS

HTTP (HyperText Transfer Protocol)

HTTPS и TLS

Маршрутизация

Таблица маршрутизации

Administrative Distance

Статическая маршрутизация

Динамическая маршрутизация

OSPF (Open Shortest Path First)

NAT (Network Address Translation)

Терминология

Типы NAT

Port Forwarding (проброс портов)

Firewall и ACL

Типы файрволов

ACL (Access Control Lists)

Wildcard маски

iptables (Linux)

STP (Spanning Tree Protocol)

Принцип работы

Состояния портов (802.1D)

Варианты STP

VPN (Virtual Private Network)

Классификация VPN

GRE (Generic Routing Encapsulation)

IPSec

DMVPN (Dynamic Multipoint VPN)

WireGuard

OpenVPN