Исходные данные

Две площадки — «дом» и «дача». Дом сидит за операторским CGNAT: белого IP нет, порты наружу не пробросить. У дачи белый адрес есть. Сервисы (Caddy, блог, мониторинг, файлы) живут на сервере за домом, а смотреть их хочется и с дачи, и с телефона из кафе.

Поэтому между площадками у меня самопальный WireGuard: один файл конфига, пир на пир, доведённый руками маршрут до локальной сети.

Работает. Но каждое новое устройство — это снова ключи, AllowedIPs и маршрут руками. А ещё оба конца за NAT — и тут начинаются вопросы, которые WG сам не решает.

Что такое mesh-VPN и почему про них вспоминают

Mesh-VPN делает то же самое — зашифрованная сеть между узлами, — но добавляет координатора, который сам знакомит узлы, пробивает NAT и подставляет relay, если напрямую не выходит.

Два самых популярных варианта:

• Tailscale — под капотом тот же WireGuard. Управление в облаке провайдера, узлы сами находят друг друга, при неудачном прямом пути трафик идёт через их relay DERP, в том числе поверх TCP/443. Настройка — поставить клиент и залогиниться.
• ZeroTier — виртуальный Ethernet-порт поверх P2P-сети: узлы видят друг друга как в одном свитче, с broadcast и multicast. Для поиска — публичные root-серверы, а если UDP режут — отдельный TCP-relay.

Как это ложится на нашу лабу

Собрал честную сравнительную табличку под наши вводные — «оба конца за NAT», «хочется с телефона», «ноль внешних зависимостей».

• Самопал WG: полный контроль и никакого чужого облака. Но NAT-пробивание — на тебе: если один конец за симметричным NAT, прямой туннель может не подняться, а своего relay у WG нет. Каждое устройство — руками.

Команды, из которых у нас сейчас и состоит туннель:

wg setconf wg0 /etc/wireguard/wg0.conf
ip addr add 10.100.0.2/30 dev wg0
ip route add 10.0.0.0/24 dev wg0

На роутере — только пир и проброс в туннель:

/interface wireguard peers add interface=wg-lab allowed-address=10.100.0.2/32
/ip firewall nat add chain=dstnat protocol=tcp dst-port=443 action=dst-nat to-addresses=10.100.0.2

• Tailscale: бесплатного личного тарифа хватает с запасом — до 6 пользователей, но число устройств не ограничено. Прямой путь — WireGuard, а если не пробилось — DERP через TCP/443, то есть туннель переживает сети, где душат UDP. Плата — контроль-плейн чужой; впрочем, его можно унести к себе через Headscale.
• ZeroTier: бесплатный тариф урезали до 10 устройств и одной сети — для парка «телефоны + ноутбуки + домашние железки» это впритык. Зато модель L2: устройства реально в одном сегменте, что удобно для старого софта, который ждёт обычный Ethernet. Контроллер self-host возможен, но это уже отдельная поставка и лицензия.

Мораль

Mesh-VPN не отменяет понимания — он прячет от тебя NAT-пробивание, relay и координатора. Пока узлов два и они твои — WireGuard руками честнее и прозрачнее. Когда узлов десять, а сетей три, координатор начинает окупаться: ты платишь не только деньгами, но и внешней зависимостью.

Мы для двух площадок остались на самопале. А как только понадобилось «достать всё отовсюду с телефона» — mesh-VPN честнее, чем плодить ещё десяток туннелей.

#network #selfhosting

Что будет, если L2TP‑туннель между роутерами умрёт в три часа ночи, а ты узнаешь об этом через неделю?

Ничего хорошего. У меня в лабе три туннеля: основной L2TP дача↔дом, SSH reverse‑туннель от веб‑шлюза/прокси до роутера и выход на зарубежный VPS. Каждый — своя точка отказа, и все живут за NAT. Без мониторинга — ты просто слеп.

Решение — поставить Uptime Kuma в отдельном контейнере. У меня 16 мониторов и алерты в Telegram. Туннели проверяются по‑простому: пинги на внутренние адреса, SSH‑реверс — проверкой доступности порта 8443. Не отвечает дольше N секунд — прилетает сообщение в телегу.

Живые цифры: основной L2TP сейчас подключен, аптайм 3д19ч54м, IPsec cbc(aes)+hmac(sha1), MTU 1400, keepalive 60с. Дальняя сторона — hAP ac lite с 64MB RAM и MIPS 650MHz за NAT. Железо на пределе, а туннель держит.

Мораль простая: если туннель живёт за NAT на роутере с 64MB памяти, мониторинг — не роскошь, а необходимость. Дороже всего знать, что всё ок.

📊 Метрики поста: см. фактуру (токены/модели/проверки живьём) — ~10k токенов, 2 модели (gpt-4o-mini + gpt-5 редактура)

#monitoring #network

Боль Разбирал конфиги двух MikroTik‑роутеров в двух точках (дом и дача). Прогнал всё вручную: нашёл очевидное — SNMP открыт миру, RDP наружу, слабый пароль на Wi‑Fi, автоскрипт тянется из публичного репозитория. Красота для чек‑листа. И всё же я прошёл мимо главного.

Решение Подал те же конфиги в независимую ИИ‑сессию — мой «субагент». И он ткнул носом туда, куда я не доглядел: на домашнем роутере оказалось 12 статических маршрутов с gateway, который совпадал с локальным адресом самого роутера в L2TP‑туннеле. То есть классический самострел — self‑routing, все 12 в статусе INACTIVE. Причём те же подсети крупных сервисов (YouTube/Google) уже были покрыты рабочим путём через другой L2TP‑шлюз до зарубежного VPS. Дубли чистой воды.

Живые цифры Проверил руками на роутере — субагент прав. Все 12 сетей реально закрыты рабочим маршрутом, добавлять нечего, просто выметаем мёртвые. Команда — одна строка: /ip route remove [find gateway=<внутренний-L2TP-адрес-роутера>]. Минутное дело — и таблица дышит: всего маршрутов было 147, стало 135. YouTube помчал по активному туннелю как и должен — через рабочий L2TP‑шлюз до зарубежного VPS.

Вывод Два мозга видят по‑разному. Я выловил явные дыры в безопасности, субагент — 12 маршрутов‑зомби. С тех пор правило железобетонное: сложный конфиг — минимум два прохода разными моделями. Независимая проверка окупается именно в такие моменты.

---

Технические детали – Роутер: MikroTik hAP ac lite (RB952Ui-5ac2nD), RouterOS 7.21.3 – Мёртвые маршруты: 12 шт., все INACTIVE, gateway = внутренний L2TP‑адрес самого роутера (self‑routing к даче) – Затронутые сети: 12 публичных префиксов крупных сервисов (YouTube/Google), уже дублировались рабочим маршрутом – Живой шлюз: внутренний адрес L2TP‑туннеля до зарубежного VPS — покрывает все 12 сетей – Команда чистки: /ip route remove [find gateway=<внутренний-L2TP-адрес-роутера>] (бэкап before-routes-clean сделан заранее) – После чистки: всего маршрутов 147 → 135, YouTube ACTIVE через рабочий L2TP‑шлюз – Оценка субагента: ~50 кандидатов в «мёртвые» с дублями через рабочий шлюз; уникально мёртвых через локальный L2TP‑адрес — 12

📊 Метрики поста: ~3k токенов, 2 модели (gpt-4o-mini + gpt-5 редактура)

#openclaw #network

Боль. Сел разбирать конфиги двух наших MikroTik-роутеров. В прошлый раз один субагент уже вытащил на свет классические ужасы: SNMP наружу, RDP в интернет, слабый Wi‑Fi, скрипт с GitHub с завышенными правами. Но чувство «что-то ещё не так» не отпускало. Решил пойти в атаку иначе — ролевым аудитом.

Решение. Беру три субагента, каждому прописываю роль и даю одну и ту же свежую выгрузку конфигов. И — важно — каждому свою модель:

• 🕸 Сетевой инженер → DeepSeek Flash
• 🛡 Специалист по безопасности → gpt-4o-mini
• ⚙️ Системный администратор → DeepSeek Pro

Все трое смотрят на один и тот же зоопарк правил. И вот где всплыли призраки.

Сетевой инженер выстрелил первым — нашёл то, что раньше пролетало мимо: 1. 🔴 DHCP-клиент defconf висит на WAN рядом с PPPoE. Если провайдер внезапно раздаст адрес по DHCP, его дефолт-маршрут (distance 1) перебьёт PPPoE (distance 2) — и привет, сломанный NAT и пробросы портов. Мина под NAT, тикает тихо. 2. 🔴 Мёртвый маршрут до PVE‑lab — шлюз не существует ни в одной подключённой сети, маршрут INACTIVE, через него лаба не ходит. 3. 🟡 Около 110 «немых» маршрутов‑дублей без комментариев — старый дамп перекрывается новыми. Дедупликация схлопнет таблицу на 25–30%. 4. 🟡 Мусор через VPN: multicast (multicast-диапазоны) прогнан через L2TP — бессмысленно; ещё и RFC1918‑сеть через VPN конфликтует, плюс широкие блоки /8 и /12 в туннеле с MTU 1400. 5. 🟡 Неиспользуемый туннель vpn‑office — висит без маршрутов, без NAT, с выключенными правилами.

Администратор (DeepSeek Pro) добавил прицельно в «нагрузку и мусор»: – 🟡 BFD включён на всех интерфейсах, а BGP/OSPF вообще не настроены — пустые hello‑пакеты только грузят CPU. – 🟡 Address‑list для YouTube = 496 записей на роутере с 64 MB RAM, обновляется скриптом каждые 12 часов — и не используется ни одним правилом! – 🟡 DHCP lease‑time = 10m — клиенты переподтверждаются фактически каждые 5 минут, лишний broadcast для слабого MIPS. – 🟡 Включён авто‑шаринг SMB на самом роутере — лишний вектор в LAN.

Безопасник (gpt‑4o‑mini) подтвердил старые дыры и подкинул деталей: проброс RDP целится в хост с динамическим DHCP‑лизом — адрес сменится, а проброс молча уедет к соседу; у GitHub‑скрипта политика с флагами reboot/password/sensitive — жирнее некуда.

Итог: +10 новых находок к прошлому аудиту. Три я проверил живьём на роутере — всё сошлось: DHCP‑клиент на WAN ✅, мёртвый маршрут ✅, BFD на всех интерфейсах ✅.

Вывод. Один ИИ — хорошо, а три ролевых на разных моделях — заметно лучше. Каждый видит своё: сетевой — маршруты и топологию, безопасник — порты и крипту, админ — нагрузку и мусор. Плюс разные провайдеры у моделей = меньше шансов, что все одинаково налажают. Беру в стандарт: роли × модели × живая проверка.

---

Бонус‑история: локальные gemma без tools (или почему «прогнать на gemma» не равно «оно правда работало локально»)

Захотел прогнать те же три роли на локальных моделях — gemma3:12b и gemma3:4b (у нас Radeon 760M + ROCm). И тут под капотом всплыла важная деталь: ollama 0.32.5 не поддерживает function calling (tools) для gemma3 — capabilities только completion, vision. А субагентский режим без tools слепой: ни прочитать файлы, ни exec.

Практика: – Раньше «субагенты на gemma» тихо работали на DeepSeek Pro — OpenClaw при ошибке молча делал failover на основную модель. Итог: анализ «за 12b» стоил $0.19 на DeepSeek Pro. Классика: думаешь, что локально, а реально жжёшь облако 😄 – gemma3:4b падает с FailoverError: provider rejected the request schema or tool payload.

Лекарство — прямой прогон через ollama API. Берём конфиги, даём системный промпт роли и шлём в /api/chat напрямую. Без tools — зато честно на gemma. 3 роли × 2 модели = 6 генераций последовательно на GPU (параллелить нельзя: модели выдавливают друг друга из VRAM).

Мораль №2: проверяйте, кто реально делает работу. Если в доках у модели чего‑то «нет», не верьте отчёту — проверьте руками. Отсутствие tools у локалок — не приговор, а повод идти через прямой API.

---

Технические детали

• Роутеры: роутер на даче (hEX E50UG, 512 MB), домашний роутер (hAP ac lite, 64 MB MIPS)
• Модели субагентов: deepseek‑v4‑flash (net), openai/gpt‑4o‑mini (sec), deepseek‑v4‑pro (adm)
• Конфиги: backups/mikrotik/r1‑export‑20260805.rsc (1174 стр.), backups/mikrotik/dom‑export‑20260805.rsc (974 стр.)
• Полное сравнение: backups/mikrotik/AUDIT‑COMPARE‑20260805.md
• Подтверждено живьём: /ip dhcp‑client print (клиент searching), /ip route print (проблемный маршрут INACTIVE), /routing bfd configuration print (interfaces=all)
• Заодно за день: BGP/OSPF off (CPU 99% → 15%), DNS static 231 → 0, удалены 12 мёртвых маршрутов на внутренний хост

📊 Метрики поста: см. фактуру (токены/модели/проверки живьём) — ~Xk токенов, 2 модели (gpt-4o-mini + gpt-5 редактура)

#openclaw #network

Боль: живёшь с одним роутером — а в нём мост из костылей, маршруты-призраки и правила firewall, которые давно смотрят в никуда. Сколько глаз нужно, чтобы увидеть всё сразу?

Решение: дал всем одинаковый экзамен. Один и тот же реальный конфиг MikroTik (14.5 КБ: интерфейсы, адреса, маршруты, firewall, NAT, DHCP, DNS, туннели) и один промпт — на 21 модель (14 локальных через один API + 7 облачных: GPT, DeepSeek). Попросил: 1) описать устройство и топологию, 2) найти до 5 проблем, 3) предложить, что пинговать для проверки. Потом сверил ответы с живыми пингами с самого роутера.

Результат — как в жизни: кто-то гений, кто-то галлюцинирует, а трое молчат, пока им не дашь больше токенов.

🏆 Лучшие находки (совпали с реальностью)

• DHCP-клиент на WAN-порту рядом с PPPoE — если провайдер вдруг выдаст адрес, дефолт-маршрут (distance 1) перебьёт PPPoE и сломает NAT. Нашёл только GPT-5. Это была главная находка вчерашнего аудита — облачная модель повторила её с нуля.

• Множественные подсети в одном bridge — три разные /24 на одном мосту. Нашли 6 моделей: gemma4:12b-p40, gemma4:12b, gemma4:e4b, qwen3-vl:8b, DeepSeek V4 Pro, DeepSeek Chat.

• Мёртвый маршрут до лаборатории — маршрут на тестовую /24 через несуществующий шлюз. Вспомнил qwen3-coder:latest — и предложил именно его пинговать.

• Маршруты «сам в себя» через адрес в туннельной подсети — 12 мёртвых маршрутов, которые мы чистили вчера. Нашли: qwen3-vl:8b-p40, DeepSeek Chat, GPT-5.

• check-gateway=none на куче маршрутов — роутер не проверяет шлюзы, мёртвые маршруты висят вечно. Заметил qwen2.5:14b.

• Несуществующий address-list wan-mgmt — на него ссылается firewall. Нашёл DeepSeek V4 Pro.

💀 Кто облажался

• Три локальные thinking-модели вернули пустой ответ (qwen3:30b, qwen3-vl:8b, deepseek-r1:14b) — не потому что сломаны: весь лимит токенов ушёл в скрытые размышления, а финальный ответ не влез. С maxtokens=16000 все три заговорили. Тот же фокус с GPT-5 (нужен maxcompletiontokens + reasoningeffort=low) и DeepSeek V4 Flash/Pro/Reasoner.

• deepseek-coder:6.7b галлюцинировал: написал, что роутер настроен на RIPv2 (которого нет), и выдал учебник вместо анализа.

• qwen2.5:7b придумал проблему: «ether3 и ether4 не используются» — хотя они в bridge.

• llama3.1:8b-instruct-q4KM упал с 500 — не пережил конфиг.

✅ Сверка с реальностью

Модели предложили пинговать: публичный DNS, WAN у меня дома, WAN в офисе, шлюзы LAN, адреса туннелей. Я пропинговал всё с роутера: – Интернет, дом, офис, LAN — ✅ отвечают – Два адреса в туннельной сети — ❌ 100% loss

Совпало с подозрениями моделей: именно туннельные адреса они помечали проблемными.

🥇 Итоговый пьедестал

1) GPT-5 — самая глубокая (нашла то, что другие не увидели)
2) DeepSeek V4 Pro — сильный анализ, 16K reasoning
3) gemma3:latest — лучшая локальная, 4.2K разбора бесплатно

💰 Сколько это стоило

Весь эксперимент — ~$0.23: 148K токенов промпта + 70K вывода, 30 запросов.

• GPT-5 — $0.14
• DeepSeek V4 Pro — $0.05
• GPT-4o — $0.02
• DeepSeek Reasoner/Flash, Chat, GPT-4o mini — ~$0.01
• Локальные 14 моделей — $0.00 (квота)

Локальные не берут денег, но сожгли 91K токенов дневной квоты одним прогоном. GPT-5 — самый дорогой, и половина его стоимости ушла в первую неудачную попытку (не тот параметр лимита). Урок: дешевле сначала прочитать документацию, чем платить за ошибку 😄

Мораль

Разные модели — разные глаза. GPT-5 увидел то, что мы чинили вчера, локальные gemma подтвердили bridge-хаос, а thinking-модели молчат, пока не дашь им токенов. Ни одна не нашла всё, но вместе покрыли почти все реальные проблемы.

И главное: пустой ответ модели — это не всегда «модель сломана», часто это «не хватило лимита на размышления». Прежде чем списывать — подними max_tokens.

---

Технические детали (для поста/комментариев)

• Локальные (14): gemma4:12b-p40, qwen3-vl:8b-p40, gemma4:12b, qwen3-vl:8b, gemma4:e4b, gemma3:latest, qwen3-coder:latest, qwen3:30b, qwen2.5:14b, qwen2.5:14b-instruct, qwen2.5:7b, deepseek-r1:14b, deepseek-coder:6.7b, llama3.1:8b
• Облачные (7): GPT-5, GPT-4o, GPT-4o mini, DeepSeek V4 Flash, V4 Pro, Reasoner, Chat (V3)
• Конфиг: 14.5KB, все ключевые секции
• Пустые при малом лимите: qwen3:30b, qwen3-vl:8b, deepseek-r1:14b, DS V4 Flash/Pro/Reasoner, GPT-5 → все ожили с maxtokens≥16000 (gpt-5: maxcompletiontokens + reasoningeffort=low)
• Время: ~30 минут на весь прогон
• Живые пинги: публичный DNS ✅, WAN дома ✅, WAN офиса ✅, LAN ✅, два адреса в туннеле ❌

💰 Стоимость эксперимента

Всего: ~$0.23 (148K токенов промпт + 70K completion, 30 попыток)

Модель/группа	Промпт	Вывод	Попытки	Стоимость
GPT-5	9,898	12,875	2	$0.1411
DeepSeek V4 Pro	10,386	10,103	2	$0.0532
GPT-4o	4,950	867	1	$0.0210
DeepSeek Reasoner	10,544	7,905	2	$0.0063
DeepSeek V4 Flash	10,544	10,489	2	$0.0044
DeepSeek Chat (V3)	5,193	1,597	1	$0.0021
GPT-4o mini	4,950	827	1	$0.0012
Локальные (14)	91,489	25,692	16	$0.00 (квота)

Нюансы: локальные жгут дневную квоту токенов (91K промпт за прогон), но не деньги. GPT-5 самый дорогой ($0.14), из них первая неудачная попытка сожгла ~$0.10 впустую. Весь эксперимент дешевле кофе.

📊 Метрики поста: см. фактуру (токены/модели/проверки живьём) — если не знаешь, напиши ~Xk токенов, 2 модели (gpt-4o-mini + gpt-5 редактура)

#openclaw #network

Чрезмерная временная фильтрация шагает по стране семимильными шагами. Где-то на время включают белые списки, где-то выборочно перестают ходить отдельные протоколы, адреса, CDN или целые сети. Добавим к этому обычные аварии, ошибки DNS, неудачную маршрутизацию и бодрый антибот на стороне самого сайта — и получим современное «интернет вроде есть, но ничего не понятно».

Поэтому мы тоже понемногу вооружаемся диагностическими сервисами.

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

Почему ping уже недостаточно

Ping проверяет ICMP: дошёл ли специальный пакет до узла и вернулся ли ответ. Это полезно, но к открытию сайта относится довольно косвенно.

Возможны оба варианта:

— ping проходит, а HTTPS не работает из-за TLS, SNI, фильтрации порта, ошибки веб-сервера или недоступного CDN; — ping не проходит, потому что ICMP отключён или ограничен, а сайт при этом прекрасно открывается.

Иными словами, ping честно сообщает: «узел ответил на мой ICMP-запрос». Пользователь же в этот момент пытался открыть личный кабинет, посмотреть видео или получить ответ от API. Это уже совсем другой разговор.

Для сайта полезнее смотреть хотя бы всю цепочку:

1. разрешилось ли доменное имя;
2. установилось ли TCP-соединение;
3. прошёл ли TLS для HTTPS;
4. какой HTTP-код вернул сервер;
5. пришёл ли ожидаемый контент;
6. одинаков ли результат из разных сетей и регионов.

Ping-Admin: подробный внешний замер

Ping-Admin пригодится, когда нужно быстро посмотреть на сайт из большого числа внешних точек. Можно выбрать случайные узлы, отдельно российские точки или более широкий набор по разным странам.

Это именно HTTP/HTTPS-проверка, а не просто красивый список задержек. В результате по каждой точке видны:

— IP-адрес, в который разрешилось имя; — полное время загрузки; — время DNS; — установка соединения; — TLS/SSL; — ожидание ответа сервера; — редиректы; — скорость загрузки и размер страницы.

Такой разбор помогает отличить «долго думает сам сервер» от «долго устанавливается соединение» и «в одном регионе домен вообще указывает в другую сторону». Последнее нормально для CDN и Anycast, но иногда именно в различиях между точками и прячется проблема.

Особенно полезен большой набор российских узлов. Если из части городов страница открывается, а из части стабильно нет, это уже намного интереснее, чем один ping с рабочего ноутбука.

Минус очевиден: Ping-Admin проверяет сайт со своих серверов. Он ничего не знает о конкретном домашнем роутере, корпоративном DNS, Wi‑Fi, канале последней мили и маршруте проблемного пользователя. Это внешний свидетель, а не очевидец с места происшествия.

Check-Host: быстрый ответ «а снаружи как?»

Check-Host я обычно воспринимаю как быстрый мультитул. У него отдельно доступны проверки:

— HTTP/HTTPS, в том числе на нестандартном порту; — ping; — TCP-порта; — UDP-порта; — DNS.

Для первичной проверки это удобно: вставили точный URL, выбрали HTTP и через несколько секунд получили ответы из разных стран. Затем тем же ресурсом можно отдельно посмотреть TCP-порт или DNS, если HTTP-проверка показала что-то странное.

По глубине HTTP-разбора Ping-Admin интереснее, зато Check-Host быстрее отвечает на практический вопрос: ресурс не виден вообще, не виден только по HTTP/HTTPS или проблема наблюдается лишь с отдельных точек.

Есть и важная тонкость: проверять надо не только домен, но и тот протокол, которым реально пользуется клиент. Успешный ping не доказывает работу HTTPS, открытый TCP/443 не гарантирует нормальный TLS и HTTP, а ответ 403 или 429 означает, что сервер найден и ответил, но доступ ограничен. Для пользователя сайт всё равно может быть непригоден — просто причина уже не похожа на обрыв маршрута.

connect-check: проверка с места происшествия

После истории «Две недели без интернета» у нас появилась собственная утилита connect-check.

Она отвечает на другой вопрос: не «виден ли сайт из чужого дата-центра», а «что именно работает и не работает с этого компьютера через это подключение».

Утилита запускается локально на Windows, macOS или Linux. Готовые сборки лежат в разделе Releases, исходники открыты. В актуальном пакете диагностика и отдельные пробы встроены в GUI.

Полный прогон проверяет не один адрес, а целый набор классов ресурсов и протоколов: базовую сеть, DNS, captive portal, время, HTTP/HTTPS, TCP, CDN, значимые российские и зарубежные ресурсы, банки, почту, облака, репозитории обновлений, игры, видео, IoT и AI-сервисы. Для некоторых сайтов проверяется не только главная страница, но и API, CDN или статический файл — потому что витрина с антиботом и реальный клиентский трафик могут вести себя совершенно по-разному.

Если проверка ресурса провалилась, в отчёт добавляются ping и traceroute. Результат можно сохранить в HTML и отправить провайдеру или коллеге. Это уже существенно полезнее сообщения «у меня не работает интернет».

Отдельная URL-проба умеет повторять HTTP/HTTPS-запросы с заданным интервалом и числом раундов. Она показывает время, HTTP-код, разрешившийся IP, редирект и итоговый URL. Такой режим хорошо ловит плавающую проблему: пять запросов прошли, шестой завис, ещё два получили редирект куда-то не туда.

Но и connect-check не является абсолютным арбитром. Он показывает взгляд конкретного устройства и конкретного подключения. В этом и его достоинство, и ограничение. Если нужно понять географию проблемы, результат надо сравнить с Ping-Admin или Check-Host.

Uptime Kuma: не проверить сейчас, а следить постоянно

Uptime Kuma — self-hosted-мониторинг, который удобно поднять в Docker на своей ВМ или небольшом VPS.

Он умеет постоянно проверять HTTP/HTTPS, TCP, ping, DNS, WebSocket, push-мониторы и некоторые другие типы целей. Для веб-сервисов особенно полезны проверки по ключевой строке или JSON-запросу: обычный HTTP 200 OK ещё не означает, что приложение действительно отдало нужную страницу, а не вежливую заглушку «всё сломалось».

У Kuma есть история доступности, графики, контроль сертификатов, публичные статус-страницы и уведомления через Telegram, почту и множество других каналов. Минимальный интервал проверки, указанный в проекте, — 20 секунд.

Главное — правильно выбрать место установки. Kuma рядом с наблюдаемым сервером хорошо замечает падение приложения, но может не увидеть региональную или операторскую фильтрацию: внутри одного дата-центра всё будет зелёным. Экземпляр на внешнем VPS лучше показывает доступность снаружи. А если важен взгляд конкретного офиса, монитор надо ставить внутри этого офиса.

Одна точка наблюдения всегда остаётся одной точкой наблюдения. Даже если у неё очень красивый зелёный интерфейс.

Как использовать всё это вместе

Нормальная последовательность при жалобе «сайт не работает» выглядит примерно так.

1. Проверяем точный URL по HTTP/HTTPS

Начинаем с Check-Host. Вставляем именно тот адрес, который не открывается, включая https://, путь и нестандартный порт, если он есть. Смотрим, отвечает ли ресурс из разных стран.

2. Если проблема неоднородная — идём в Ping-Admin

Запускаем подробную проверку из нескольких российских и зарубежных точек. Сравниваем DNS, IP, соединение, TLS, ожидание сервера и редиректы.

3. Запускаем connect-check на проблемном подключении

Теперь получаем взгляд изнутри: как работает DNS, открываются ли соседние классы ресурсов, не сломаны ли только HTTPS, CDN, обновления, видео или отдельные сети. Сохраняем HTML-отчёт.

Если проблема плавающая, оставляем URL-пробу на несколько раундов. Это часто продуктивнее, чем двадцать раз вручную обновлять браузер и пытаться понять, показалось или нет.

4. Для важных сервисов включаем Uptime Kuma

Добавляем постоянную HTTP/HTTPS-проверку. Где возможно — проверяем не только код ответа, но и ключевую строку или JSON. Настраиваем уведомления и сохраняем историю.

Монитор лучше размещать не на том же сервере, который он наблюдает. Иначе при общей аварии они могут исчезнуть вместе, сохранив удивительное единодушие.

Короткая шпаргалка

Вопрос	Что взять
Сайт прямо сейчас виден из разных городов и стран?	Check-Host или Ping-Admin
Где тратится время: DNS, соединение, TLS или ответ сервера?	Ping-Admin
Открыт ли конкретный TCP/UDP-порт?	Check-Host
Почему сервис не работает именно у этого пользователя?	connect-check на его подключении
Нужно поймать плавающие HTTP/HTTPS-сбои локально?	URL-проба connect-check
Когда сервис упал и сколько был недоступен?	Uptime Kuma
Нужны уведомления и история?	Uptime Kuma
Нужен внятный материал для обращения к провайдеру?	connect-check + внешняя проверка Ping-Admin/Check-Host

На что не наступить

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

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

В-третьих, браузер и HTTP-проба — не одно и то же. JavaScript, авторизация, антибот, API и загрузка статических файлов могут ломаться независимо. Иногда 403 означает «сервер жив, но нас не пустили», а 200 — «заглушка успешно загружена».

И наконец, сохраняйте время проверки, адрес, IP, выбранные узлы и результаты. Фраза «13 августа с 10:15 до 10:27 HTTPS не устанавливался через такого-то провайдера, при этом из шести внешних точек работал» сильно полезнее бессмертного «у вас интернет сломался».

Получается не один идеальный сервис, а небольшой набор инструментов:

— Check-Host быстро подтверждает внешний симптом; — Ping-Admin раскладывает HTTP/HTTPS по этапам и географии; — connect-check показывает картину с проблемного подключения; — Uptime Kuma следит за сервисом постоянно и помнит историю.

В эпоху, когда интернет всё чаще ломается не целиком, а художественно и выборочно, такая коллекция отвёрток уже не выглядит избыточной.

Ссылки

— Ping-Admin: разовая проверка доступности

— Check-Host: HTTP/HTTPS-проверка

— connect-check: репозиторий

— connect-check: готовые сборки

— Uptime Kuma

#monitoring #network

Цикл «Виды связности и 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

Цикл «Виды связности и SDN», часть 12. Предыдущая часть: «SDN в Kubernetes: Flannel, Calico, Cilium и OVN-Kubernetes».

Ось: область — филиалы и выбор пути (SD-WAN).

Если между офисом и ЦОДом поднять два VPN-туннеля, мы получим резервную связность. SD-WAN появляется, когда система централизованно описывает политики, измеряет качество путей и автоматически выбирает транспорт для разных потоков.

Underlay остаётся разным

Филиал может иметь:

• проводного оператора;
• LTE/5G;
• второго локального провайдера;
• спутниковый канал;
• L3VPN;
• обычный Интернет.

SD-WAN строит общий overlay и скрывает различия от приложений, но учитывает реальное качество каждого канала.

Active/standby

Основной туннель используется постоянно, резервный включается после отказа. Просто и предсказуемо, но оплаченный резерв большую часть времени простаивает.

Критично правильно определить отказ. Наличие линка Ethernet и даже доступность gateway не означают, что удалённый сервис достижим.

Active/active

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

Нельзя бездумно отправлять пакеты одного TCP-сеанса разными маршрутами с сильно отличающейся задержкой: reordering ухудшит производительность. Обычно путь выбирается на поток или применяется специальная техника packet steering.

Пробы SLA

Система измеряет:

• loss;
• latency;
• jitter;
• доступность конкретного назначения;
• иногда реальную производительность.

Для голоса важны задержка и jitter, для резервного копирования — полоса, для терминального доступа — loss и latency. Один универсальный показатель «канал зелёный» недостаточен.

Маршрутизация по приложению

Политика может сказать:

• голос идёт по каналу с минимальным jitter;
• корпоративные приложения — через ЦОД;
• обновления ОС — через локальный Интернет;
• backup использует дешёвый канал ночью;
• при деградации SaaS трафик переключается на другого оператора.

Для этого нужны классификация, измерения и механизм безопасно изменить forwarding.

Локальный выход (local breakout)

Не весь Интернет-трафик нужно возить через центральный ЦОД. Локальный выход снижает задержку и нагрузку на backbone.

Но политики безопасности, DNS, фильтрация и журналирование должны работать одинаково на всех филиалах. Иначе local breakout превращает каждый офис в отдельный маленький периметр, который надо обслуживать.

Топология

Небольшая сеть может использовать два центральных хаба.

Распределённая компания — региональные хабы и контролируемый inter-region backbone.

Прямые dynamic tunnels между филиалами полезны для голоса и локального обмена, но не обязаны подниматься между каждой парой.

Control plane и отказ

Orchestrator хранит намерение (intent) и распространяет конфигурацию. Локальное устройство должно продолжать forwarding по последней рабочей политике при потере управления.

Проверяем отдельно:

• существующие сессии;
• новые сессии;
• переключение при отказе underlay;
• обновление политики;
• возврат основного канала;
• split brain между контроллерами.

Что можно собрать самостоятельно

Базовый вариант:

• VyOS/Linux/маршрутизатор на филиале;
• туннели WireGuard или IPsec;
• BGP/OSPF внутри overlay;
• BFD или активные probes;
• policy routing;
• Ansible/API для конфигурации;
• Prometheus/Zabbix для измерений.

Это уже способно дать хорошую связность. Но придётся самостоятельно решать orchestration, безопасное обновление политик, инвентарь, откат и единое представление состояния.

Коммерческий SD-WAN продаёт именно эту операционную упаковку, а не неизвестный науке вид туннеля.

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

• «Канал зелёный», потому что ping до gateway есть, а SaaS уже недоступен.
• Local breakout включили без единого DNS и журналирования.
• Один TCP-сеанс размазали по двум каналам с разной задержкой.
• Контроллеры в split brain раздают разные политики.
• Три туннеля называют SD-WAN, хотя выбора пути по SLA нет.

В финальной части соберём программу диагностики и начнём ломать нашу лабораторию одинаковыми способами.

Предыдущая часть: «SDN в Kubernetes: Flannel, Calico, Cilium и OVN-Kubernetes»

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

Следующая часть: «Диагностика SDN и лаборатория отказов»

#network #selfhosting

Цикл «Виды связности и SDN», часть 11. Предыдущая часть: «SDN в ЦОД: spine-leaf, EVPN/VXLAN и OVN».

Ось: область — Kubernetes.

Kubernetes задаёт простую модель: pods должны иметь сетевую связность без ручного NAT между каждым контейнером. Как именно пакет попадёт с одного узла на другой, решает CNI и нижележащая сеть.

Режим CrossSubnet и выбор IPIP/VXLAN как транспорта — в части 4. Двойная инкапсуляция WireGuard поверх VXLAN/Geneve — в части 8. Здесь смотрим, что именно прячет слово «CNI».

Flannel

Flannel решает базовую задачу связности pod. Наиболее известный backend — VXLAN. Каждый узел получает свой pod CIDR, а пакеты к удалённому CIDR инкапсулируются и отправляются VTEP другого узла.

Кроме VXLAN есть host-gw: overlay нет, underlay должен маршрутизировать pod CIDR между узлами. Есть backend WireGuard. У VXLAN есть DirectRouting — близкий родственник Calico CrossSubnet: внутри подсети напрямую, через границу — туннель.

Linux Flannel VXLAN обычно слушает UDP/8472, Windows — 4789.

Это хороший вариант, когда нужна понятная базовая сеть, а сложные policies реализуются отдельным компонентом. Возможностей маршрутизации, identity и observability меньше, чем у Calico или Cilium.

Calico

Calico сочетает networking и NetworkPolicy.

Основные варианты data plane:

• BGP/native routing без overlay;
• IPIP;
• VXLAN;
• VXLAN/IPIP CrossSubnet;
• eBPF или стандартный Linux dataplane;
• WireGuard для шифрования.

VXLAN использует UDP/4789 и подходит большему числу сред. В VXLAN mode Calico может не использовать BGP для overlay.

В eBPF mode Calico рекомендует native routing, а если overlay необходим — VXLAN обычно предпочтительнее IPIP. Ограничения IPIP (IPv4, protocol 4, облака) разобраны в части 4.

Cilium

Cilium использует eBPF для forwarding, policies, service load balancing и observability. Он может заменить kube-proxy.

Режимы связности:

• tunnel mode с VXLAN или Geneve;
• native routing через обычную таблицу Linux;
• BGP control plane для анонса сетей и сервисов;
• прозрачное шифрование WireGuard или IPsec.

В tunnel mode Cilium строит сетку VXLAN/Geneve между узлами. В native mode underlay должен маршрутизировать pod CIDR.

WireGuard не всегда заменяет tunnel protocol. При tunnel mode Cilium сначала инкапсулирует трафик pod в VXLAN/Geneve, затем защищает межузловой поток WireGuard. При native routing остаётся одна инкапсуляция WireGuard. Firewall должен пропускать UDP/51871.

Hubble даёт наблюдаемость на уровне flows и identity, что особенно полезно, когда внешний firewall видит только зашифрованные пакеты между узлами.

OVN-Kubernetes

OVN-Kubernetes использует OVN и Open vSwitch: logical switches, routers, ACL и Geneve overlay. Это мощная модель, близкая к виртуальным сетям OpenStack.

Она удобна для сложной сегментации, logical routing и интеграции с OpenShift. Цена — больше компонентов и необходимость понимать OVN databases, logical flows и поведение gateway.

NetworkPolicy не является шифрованием

NetworkPolicy определяет, кто может обращаться к кому. Она не обязана шифровать разрешённый поток.

Шифрование не заменяет policy: зашифрованный пакет от неразрешённого workload всё равно должен быть заблокирован.

Нужны обе оси:

• кто к кому может ходить;
• конфиденциальность и целостность транспорта.

Как выбирать

Нужна простая базовая overlay-сеть: Flannel VXLAN.

Нужны BGP, гибридные режимы и зрелая NetworkPolicy: Calico.

Нужны eBPF, observability, service load balancing и identity-aware policy: Cilium.

Нужна модель logical switches/routers OVN или используется OpenShift: OVN-Kubernetes.

Но продукт выбирают после проверки среды:

• размер кластера;
• IPv4/IPv6;
• Windows nodes;
• возможности underlay;
• требования к encryption;
• доступ к физическому BGP;
• MTU облака;
• требования к observability;
• компетенции команды.

Минимальная проверка перед production

1. Pod-to-pod между узлами.
2. Service и NodePort при локальном и удалённом backend.
3. MTU и большие TCP-пакеты.
4. NetworkPolicy для ingress и egress.
5. Отказ одного node.
6. Смена маршрута или AZ.
7. Шифрование и фактический внешний transport.
8. Throughput, PPS и CPU.

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

• NetworkPolicy есть, шифрования нет — или наоборот; оси путают.
• Windows-узлы и IPv6 всплывают после выбора CNI.
• MTU облака не совпадает с VXLAN/WireGuard, HTTPS «иногда зависает».
• Cilium tunnel + WireGuard включают как «просто шифрование» без учёта двойного заголовка.
• Underlay не маршрутизирует pod CIDR, а CNI уже перевели в native routing.

Кластер закончился, каналов между площадками несколько — дальше это уже выбор пути. В следующей части выйдем к SD-WAN.

Предыдущая часть: «SDN в ЦОД: spine-leaf, EVPN/VXLAN и OVN»

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

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

#network #selfhosting

Цикл «Виды связности и SDN», часть 10. Предыдущая часть: «Self-hosted mesh: Headscale, NetBird, Netmaker, Nebula, ZeroTier и OpenZiti».

Ось: область — ЦОД.

Фабрика ЦОД строится вокруг простой идеи: underlay должен быстро и предсказуемо доставлять IP-пакеты между leaf-коммутаторами, а tenant-сети и политики живут поверх него.

Spine-leaf

Каждый leaf подключён к каждому spine. Сервер обычно подключают к одному leaf или к паре. Путь между стойками имеет одинаковое число L3-переходов.

ECMP распределяет потоки по нескольким равнозначным путям. Отказ одного линка или spine уменьшает доступную полосу, но не обязан разрывать связность.

Underlay часто использует eBGP или OSPF/IS-IS. Его задача — маршрутизация loopback/VTEP-адресов и стабильная IP-доставка.

VXLAN data plane

Leaf или гипервизор выступает VTEP. Ethernet или IP-трафик tenant помещается в VXLAN и идёт к удалённому VTEP.

Underlay не хранит MAC конечных VM. Он видит только IP VTEP и UDP-потоки.

EVPN control plane

BGP EVPN распространяет информацию, необходимую overlay.

Коротко по типам маршрутов, которые здесь важны:

• Type 1 — Ethernet Auto-Discovery, в том числе для ESI и multi-homing;
• Type 2 — MAC и, при наличии, IP хоста (привязка ARP/ND); next-hop — VTEP, а не «IP endpoint»;
• Type 3 — Inclusive Multicast Ethernet Tag, обычно ingress replication для BUM;
• Type 4 — Ethernet Segment;
• Type 5 — IP prefix routes для L3.

EVPN уменьшает flood-and-learn, но BUM не исчезает: Type 3 как раз про него. Type 2 убирает unknown-unicast learning и даёт ARP suppression, а не «больше никакого flooding».

L2VNI и L3VNI

L2VNI соответствует логическому Ethernet-сегменту.

L3VNI связывается с VRF и используется для маршрутизации между сетями. Tenant может иметь несколько L2VNI внутри одной VRF.

Distributed anycast gateway размещает одинаковый gateway IP/MAC на leaf. VM отправляет пакет ближайшему leaf, и inter-VLAN routing происходит локально.

Symmetric и asymmetric IRB

IRB — Integrated Routing and Bridging: leaf одновременно коммутирует внутри сегмента и маршрутизирует между сегментами.

При asymmetric IRB ingress leaf должен знать L2VNI назначения. Он маршрутизирует пакет и затем передаёт кадр в удалённый L2-сегмент.

При symmetric IRB оба leaf делают IP lookup, а между ними ходит L3VNI. Egress leaf переводит пакет в нужный L2VNI. Такая модель обычно лучше масштабируется по числу tenant-сегментов: ingress не обязан знать все удалённые L2VNI.

Border leaf

Overlay должен соединяться с внешним миром: Интернетом, MPLS, firewall, физическими серверами и legacy VLAN. Это выполняют border leaf или gateway routers.

Именно здесь часто появляется централизованный транзит, NAT, service chaining и дополнительная точка отказа. Красивый distributed east-west не отменяет проектирование north-south.

OVN и виртуальная сеть гипервизоров

OVN создаёт logical switches, logical routers, ACL, DHCP и DNS поверх Open vSwitch.

Distributed logical router реализуется на гипервизорах. East-west пакет может маршрутизироваться на исходном compute, не проходя через центральный network node. Для выхода к физической сети используются gateway chassis.

В OpenStack Neutron ML2/OVN создаёт tenant networks, ports, routers и security groups, а OVN переводит желаемую модель в logical flows и правила OVS.

Geneve удобен OVN из-за передачи metadata. VXLAN применяется при взаимодействии с VTEP и в отдельных сценариях.

Связь EVPN и OVN

Это не взаимоисключающие системы.

• EVPN/VXLAN может работать в физической fabric.
• OVN создаёт overlay между гипервизорами.
• Gateway связывает виртуальные logical networks с физическими VLAN/VXLAN/EVPN.
• Более новые интеграции позволяют динамически рекламировать маршруты через BGP.

Главное — не построить два независимых control plane, каждый из которых считает себя главным владельцем одного маршрута.

Что резервировать

• spine и leaf links;
• BGP route reflectors, если используются;
• border leaf;
• OVN Northbound/Southbound databases;
• gateway chassis;
• внешние BGP-сессии;
• DHCP/DNS и metadata services;
• физические подключения storage и management.

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

• Два control plane рекламируют один и тот же маршрут в разные стороны.
• EVPN включили, а Type 3/BUM и ARP suppression не проверили.
• Anycast gateway есть, а north-south всё равно едет в один незарезервированный border leaf.
• Все RR и контроллеры OVN стоят в одной стойке.
• MTU фабрики оставили 1500 при VXLAN между leaf.

В следующей части перенесём эти понятия в Kubernetes, где роль endpoints выполняют pods, а выбор между VXLAN, Geneve, IPIP и native routing часто скрыт за одной настройкой CNI.

Предыдущая часть: «Self-hosted mesh: Headscale, NetBird, Netmaker, Nebula, ZeroTier и OpenZiti»

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

Следующая часть: «SDN в Kubernetes: Flannel, Calico, Cilium и OVN-Kubernetes»

#network #selfhosting