Цифровой дворник

Цикл «Виды связности и SDN», часть 13. Предыдущая часть: «SD-WAN: связность филиалов, ЦОДов и облаков».

Сводка: диагностика по всем осям.

SDN добавляет удобную абстракцию: логический switch, сеть, policy или service. При аварии приходится аккуратно спускаться обратно к пакетам.

Симптом фиксируем сверху: какой клиент, к какому имени, порту и в какое время не смог подключиться. Искать причину идём снизу вверх: underlay → туннель → маршруты → политики → приложение.

Уровень 1: underlay

Сначала проверяем внешнюю IP-связность конечных точек:

• route lookup;
• ARP/ND до next hop;
• доступность внешнего адреса;
• loss и latency;
• ECMP;
• firewall;
• максимальный пакет без фрагментации;
• проходят ли ICMP Fragmentation Needed и IPv6 Packet Too Big.

Если underlay не доставляет UDP/6081, нет смысла начинать с OVN logical flows.

Уровень 2: туннель

Проверяем:

• создан ли интерфейс;
• локальный и удалённый endpoint;
• VNI или tunnel ID;
• handshake и время последнего обмена;
• счётчики RX/TX и drops;
• прямой путь или relay;
• внешний протокол и порт;
• выбранный MTU.

Дамп на внешнем интерфейсе показывает инкапсулированный поток. Дамп на интерфейсе нагрузки — исходный пакет. Снимать их полезно одновременно.

Уровень 3: forwarding

Для L2 смотрим FDB, MAC learning, ARP/ND и flooding.

Для L3 — RIB/FIB, policy routing, VRF, BGP routes и next hop.

В EVPN проверяем наличие нужного MAC/IP или prefix route и Type 3 для BUM. В Kubernetes — маршруты pod CIDR, endpoint identity и service backend.

Уровень 4: политики

Пакет может быть доставлен до узла и отброшен локальной ACL, NetworkPolicy, eBPF policy или distributed firewall.

Проверяем политики с обеих сторон. В ZeroTier и некоторых mesh-системах правила применяются локально отправителем и получателем. В Kubernetes ingress и egress policies независимы.

Уровень 5: приложение

Только после сети проверяем listener, DNS, сертификат, proxy и само приложение.

Лаборатория

Для сравнения платформ используется один стенд:

• офис за NAT;
• ЦОД с публичным адресом;
• второй ЦОД за CGNAT;
• облачная VM;
• ноутбук, меняющий Wi-Fi/LTE;
• два Kubernetes-узла;
• два контроллера и два relay, где это поддерживается.

Канонический список профилей — в tables/lab-protocol.md. Статья и протокол должны совпадать.

Профили отказа

1. Один публичный узел, второй за обычным NAT.
2. Оба участника за обычным NAT.
3. Оба участника за CGNAT.
4. Hairpin: оба за одним NAT.
5. Address-and-port-dependent mapping с двух сторон.
6. Запрещены все входящие соединения.
7. Полностью запрещён UDP.
8. Разрешены только TCP/80 и TCP/443.
9. Доступ наружу возможен через HTTP-прокси.
10. Недоступен публичный relay.
11. Недоступен собственный relay.
12. Недоступен контроллер.
13. Один узел меняет внешний адрес во время сессии.
14. Между площадками MTU 1400.
15. PMTUD black hole: фильтр ICMP Fragmentation Needed / IPv6 PTB.
16. Один ECMP-путь теряет пакеты.
17. Отозван узел и изменена ACL.
18. Underlay только IPv6.

Что измерять

• время первого соединения;
• прямой или relay путь;
• время failover;
• сохраняется ли открытый SSH;
• открывается ли новый SSH;
• можно ли подключить новый узел;
• применяется ли новая ACL;
• RTT, jitter и loss;
• TCP/UDP throughput;
• CPU;
• рабочий inner MTU.

Почему дата обязательна

Поведение SaaS-контроллеров, публичных relay и операторских сетей меняется. Результат «работает через TCP/443» должен содержать версию, дату, оператора, регион, тип ограничения и фактический транспорт data plane. Без этого таблица быстро превращается в собрание воспоминаний. Чеклист свойств транспорта — в части 7.

Набор инструментов

• ip route get, ip rule, ip neigh;
• bridge fdb;
• ss, conntrack;
• tcpdump/Wireshark;
• tracepath, ping с DF и изменяемым размером;
• iperf3;
• wg show;
• birdc, vtysh, BGP looking glass;
• ovs-vsctl, ovs-ofctl, ovn-trace;
• cilium status, Hubble;
• журналы контроллера, signal и relay.

Можно использовать свой скрипт проверки доступности для регулярной проверки TCP/HTTP/HTTPS endpoints с разных узлов, но она не заменяет анализ конкретного overlay-протокола.

Где это ломается

• Панель зелёная, а смотрели только ICMP.
• Пинг есть — значит «сеть жива», при этом HTTPS рвётся на MTU.
• UDP/443 записали как HTTPS.
• Профиль отказа в статье не совпал с протоколом лаборатории.
• Результат без даты, версии и оператора перенесли в сравнительную матрицу.

Итог цикла

Универсального победителя нет.

Внутри ЦОД разумно смотреть на native routing, EVPN/VXLAN и OVN. В Kubernetes — на возможности underlay и требования к policy/observability. Для удалённых узлов за NAT — на управляемый mesh с хорошим relay. Для сервисного доступа — на identity-based overlay. Для филиалов — на SD-WAN-политику и реальные измерения каналов.

Правильный выбор начинается не с логотипа, а с пяти вопросов: уровень, underlay, управление, топология и граница шифрования.

Предыдущая часть: «SD-WAN: связность филиалов, ЦОДов и облаков»

Оглавление цикла: «SDN без магии: карта видов связности»

Следующая часть: —

симптом фиксируем сверху, причину ищем снизу.

#network #selfhosting