# Стратегия доказательства сетевого бага Nubes — v2

> ⚠️ **ПОМЕТКА: анализ от DeepSeek V4 Pro (основная модель) в НОВОМ чате — НЕ Соннет.**
> Пользователь задал тот же вопрос в новом чате DeepSeek V4 Pro.
> Сохранено 2026-08-15. Сравнение с планом DeepSeek V4 Flash — в HISTORY
> и в конце этого файла.

## Стратегия доказательства

Доказывается изоляцией слоёв. Каждый тест исключает один слой пути:

```
клиент (локальная машина) → интернет → шлюз платформы (VIP 185.247.187.151)
→ kube-vip → NodePort 32391 → kube-proxy → nginx-ingress → Cilium → под shared-sqs
```

«Виновата платформа» доказано, если ВСЕ три условия:
1. Таймауты воспроизводятся на пути БЕЗ нашего кода (сырой TCP, эхо) с тем же паттерном.
2. tcpdump фиксирует потерю сегмента клиент↔кластер при том, что под/nginx
   ответил за миллисекунды (по логам).
3. Потери коррелируют с MTU-порогом (~1448) или платформенным таймером
   (conntrack/RST), а не с логикой приложения.

## 1. Эхо или сырые TCP

Делать ОБА, в порядке: сырые TCP, потом эхо.

**Сырые TCP на 185.247.187.151:32391** — бесплатный первый тест. Покрывает
путь до nginx-пода без HTTP и без нашего кода. Отправлять сегменты 512, 1380,
1448, 1488+ байт. Критерий доставки — TCP ACK, не HTTP-ответ (nginx на мусор
ответит 400/RST — нормально).

**Эхо-сервис** — второй шаг, ~20 строк Go, Deployment + Service с отдельным
NodePort (без ingress). Параметризуемый размер тела ответа (`?bytes=512|1400`) —
большие POST тестируют прямой путь, большие ОТВЕТЫ — обратный. Гонять тем же
клиентом. Таймауты воспроизвелись → nginx-ingress и наше приложение исключены.

## 2. Как поймать таймаут

tcpdump на клиенте: `tcpdump -i any -s 0 -w /tmp/cap.pcap host 185.247.187.151 and tcp port 32391`

| Симптом | Что смотреть |
|---|---|
| 51-с зависание большого POST | ACK на сегмент с полным MSS? ретрасмиты и интервалы? чем сессия завершилась (RST/FIN, кто первый) |
| 30-с ReadTimeout на 512 байт | запрос отправлен полностью? ACK получен? ответ не пришёл? RST после idle (conntrack)? keep-alive пул? |
| MTU-гипотеза | ICMP type 3 code 4 (Fragmentation Needed)? Не приходят → PMTUD сломан → механизм зависаний |

Замечание: 51 с не похоже на TCP-backoff Linux (tcp_retries2=15 → сотни секунд).
Скорее прикладной таймер (~50–60 с клиента/nginx/шлюза). Точный интервал в pcap
покажет, чей таймер.

Серверный захват — только через kubectl: `kubectl debug -it <pod> --image=<tcpdump-образ>`
(нужны NET_RAW/NET_ADMIN — на managed может быть запрещено). Если запрещено —
роль серверного захвата выполняют nginx access log и эхо-А/Б.

Ключевой приём: двусторонний захват, корреляция по TCP seq/ack (не по времени):
- запрос ушёл с клиента, не появился у пода → потеря на прямом пути;
- ответ ушёл из пода, клиент не получил → потеря на обратном;
- в обоих случаях приложение исключено.

## 3. kube-vip / NodePort / nginx через kubectl

nginx access log + `$request_time $upstream_response_time $status $bytes_sent`:

| В логе | Вывод |
|---|---|
| 499 + большой request_time | клиент ушёл до ответа |
| 200 + малый upstream, клиент без ответа | потеря между nginx и клиентом |
| записи нет | потеря до nginx (kube-vip/NodePort/шлюз) |

kube-vip: `kubectl get pods -A | grep -i vip`, логи (ARP/BGP-анонсы, флап VIP),
сопоставить ноду-держателя VIP с реально принимающей нодой.

kube-proxy/NodePort: `kubectl get ds -n kube-system kube-proxy`, логи;
`externalTrafficPolicy: Cluster` → лишний хоп + SNAT; iptables/conntrack ноды
не видны (нет доступа к нодам) — debug-под с hostNetwork+privileged+nodeSelector
или тикет.

Cilium: `kubectl exec -n kube-system <cilium-pod> -- cilium monitor --type drop`
(в cilium-под, НЕ в operator). Дроп с причиной — прямое доказательство.

Ограничение: внешний шлюз (VIP, MSS=1448) из kubectl не виден. Если кластерные
точки чистые, а снаружи потери есть — виноват шлюз/underlay, оформляется тикет.

## 4. Пошаговый план: дешевле → дороже

1. Инвентаризация логов: nginx access/error за тестовый период (499, request_time
   30+/51), логи приложения (фактическое время обработки). Параллельно открыть
   тикет Nubes.
2. PMTU-зонд с клиента: `ping -M do -s 1372/1422/1460/1472` до VIP (пороги MTU
   1400/1450/1488/1500); при запрете ICMP — `mtr --tcp -P 443`, tcptraceroute.
   MSS=1448 → сегменты 1488 при underlay 1450 — шлюз анонсирует неверный MSS.
3. Второй клиент из другого сегмента (VPS/другой ISP): тот же скрипт.
   Воспроизвелось → исключены ISP и локальная сеть пользователя.
4. Сырые TCP на 32391 с обеих точек: потери на больших сегментах без HTTP →
   исключены HTTP и приложение.
5. kubectl port-forward с ВМ на shared-sqs (localhost:4100): чистый тест →
   приложение и под исправны (в обход шлюза через API-туннель).
6. tcpdump на клиенте + сверка с nginx access log: классификация таймаутов.
7. Эхо-сервис NodePort без ingress: А/Б 512/1400 тем же клиентом. Остались
   таймауты → nginx и приложение исключены; исчезли → завести эхо через ingress
   и повторить (изоляция nginx).
8. Захват в кластере: debug-контейнеры tcpdump, cilium monitor drop, логи
   kube-vip/kube-proxy; двусторонняя корреляция по seq.
9. Матрица размеров (опционально): 100–1500 байт на эхо и на 32391. Резкий
   порог 1380–1448 → MTU; плавный рост → шлюз/перегрузка.

## Итог: что считается доказательством

| Наблюдение | Вывод |
|---|---|
| Таймауты на эхо-NodePort (без ingress) с тем же паттерном | исключены nginx и наш код — виноват kube-vip/NodePort/шлюз/underlay |
| nginx: 200 + upstream <100 мс, клиент без ответа | потеря между nginx и клиентом |
| нет записи в access log | потеря до nginx |
| pcap: сегмент не дошёл до пода / ответ не дошёл до клиента | потеря в сетевом пути |
| ping -M do: резкий порог размера | MTU-дефект пути |
| cilium monitor показывает drop | внутрикластерная потеря |
| port-forward чистый, внешний IP таймаутит | виноват шлюз/NodePort/kube-vip |

Итоговая цепочка для тикета: pcap с клиента + access log nginx (200/upstream
малый) + воспроизведение на эхо без нашего кода + PMTU-порог ≈1448.

---

## Сравнение с планом DeepSeek V4 Flash (основной агент)

Flash: силён декомпозицией по nginx-логам, но с ошибкой (cilium monitor через
cilium-operator), переоценён echo, нет PMTU-зонда, нет порога ping -M do, нет
port-forward, нет второго ISP.

Pro (этот план): сильнее методологически — сырые TCP с критерием ACK,
PMTU-зонд ping -M do, второй клиент, port-forward, таблица «что считается
доказательством». Грубых ошибок нет.

Синтез (рекомендация): дешёвые тесты обоих планов + финал echo.
Порядок: nginx-логи → PMTU-зонд → сырые TCP → port-forward → tcpdump клиента →
второй ISP (если есть) → cilium monitor → echo → тикет.