montana/Node/External-Audit/INCIDENT-HELSINKI-2026-05-19.md

# Инцидент Helsinki — 2026-05-19. Пост-мортем + план предотвращения

## Краткая хронология

| Время (UTC) | Событие |
|---|---|
| ~19:00 | xray на FI/FRA/US получил единый Reality-ключ через cargo deploy |
| ~19:09 | DNS-upstream в xray переключён на AdGuard DoH (`https+local://94.140.14.14/dns-query`) на всех 3 узлах |
| ~19:50 | xray под нагрузкой делает HTTPS-handshake к AdGuard на каждый DNS-запрос пользователя |
| ~20:00 | Автор сообщил «ВПН не грузит» на Helsinki |
| ~20:00+ | SSH к 91.132.142.42:22 принимает TCP, но banner exchange таймит (sshd завис) |
| ~20:01 | Reality :443 на FI ещё формально отвечает на TLS handshake (kernel-level), но xray внутри тоже залип |
| ~20:01 | DNS на FRA и US откачен на чистый 1.1.1.1 удалённо — оба работают |
| ~20:02 | FI остался недоступен, требуется reboot через хостинг-панель |

## Корневая причина

**AdGuard DoH как DNS-upstream xray под нагрузкой.** Каждый DNS-запрос пользователя превращался в полноценный HTTPS-handshake к 94.140.14.14:443. При активном использовании (десятки запросов в секунду на узел) ресурсы упёрлись:
- file descriptors xray.service (~50 одновременных HTTPS-connections к AdGuard)
- conntrack table (каждое TCP-соединение туда — отдельная запись)
- CPU на ECDHE-handshake'ах

Когда xray упёрся в лимит, kernel начал отвергать новые TCP-fork'и. sshd не смог fork'ать child-процесс на новый коннект → banner timeout. Reality :443 продолжал «жить» на kernel-уровне для уже установленных коннектов.

## Усугубляющие факторы

| Фактор | Цена |
|---|---|
| Раскатил AdGuard DoH **сразу на все 3 узла** без A/B | Если бы только на FRA — заметил бы за 1 час, не повлияло бы на FI |
| Нет хостинг-API в Keychain для emergency reboot | Не могу удалённо перезагрузить — нужен ручной шаг автора |
| Нет resource limits в `xray.service` (FD, memory) | xray смог сожрать столько FDs что system отказал sshd |
| Нет sshd-watchdog (cron-based local restart) | Узел остался в зомби-состоянии до ручного reboot |
| Нет мониторинга узла (load/FD/conntrack) | Не было раннего alert «load > 5» или «FDs > 80%» |
| Нет per-node canary тестов после изменения | Изменение применено вслепую, без baseline сравнения |

## План предотвращения — приоритизированный

### P0 (сразу после возвращения FI)

#### P0-1. Resource limits в `xray.service`
В drop-in `/etc/systemd/system/xray.service.d/40-resources.conf`:
```ini
[Service]
LimitNOFILE=1048576
TasksMax=10000
MemoryMax=2G
MemoryHigh=1.5G
OOMScoreAdjust=500
```
**Эффект:** xray умрёт раньше чем заберёт ресурсы у sshd. systemd `Restart=always` поднимет.

#### P0-2. sshd защита от OOM + локальный watchdog
- `OOMScoreAdjust=-900` на `ssh.service` — kernel OOM-killer убивает xray, не sshd.
- Cron `*/1 * * * * timeout 5 bash -c '</dev/tcp/127.0.0.1/22' || systemctl restart ssh` — если sshd завис, локальный root-cron его перезапустит через минуту.

#### P0-3. DNS-upstream без DoH
- Откатить на UDP DNS `1.1.1.1` + `8.8.8.8` (как FRA/US сейчас).
- Adblock — позже через отдельный путь (см. P2-2).

### P1 (в ближайшую неделю)

#### P1-1. Out-of-band доступ
- Получить API tokens хостингов (THE.Hosting для FI/US, Timeweb для FRA/MSK), сохранить в Keychain:
  - `the-hosting-api / token`
  - `timeweb-api / token`
- CLI `montana-reboot <node>` — делает reboot через API. Лежит в `Montana/Node/External-Audit/scripts/`.
- Документация в [OPERATIONS.md](OPERATIONS.md).

#### P1-2. Hosting-side watchdog
- Если узел не отвечает на TCP :22 **с двух разных монитор-узлов** в течение 5 минут → orchestrator делает auto-reboot через хостинг API.
- Реализация: расширение watchdog-thread в `montana-orchestrator`.

#### P1-3. Canary rollout
Скрипт `Montana/Node/External-Audit/scripts/vpn-rollout.sh <change-script>`:
1. Применяет изменение **только на FRA** (canary).
2. Ждёт 30 минут.
3. Health-check FRA через `/uptime` + сравнение `samples_24h` с baseline.
4. При зелёном — раскатывает на FI и US с интервалом 5 мин.
5. При красном — `rollback FRA` и stop.

### P2 (в течение месяца)

#### P2-1. Метрики node exporter + alerts
- Node Exporter на каждом узле, scrape с Moscow.
- Метрики: `load1`, `node_filefd_allocated`, `node_nf_conntrack_entries`, `xray_open_connections`.
- Alert порог `load1 > 4` ИЛИ `FDs > 60% от LimitNOFILE` → Telegram уведомление.

#### P2-2. AdBlock без overhead
Если в перспективе нужен adblock — **не через DoH в xray**, а через:
- AdGuard Home (DNS-only daemon) **локально на каждом узле** на 127.0.0.1:53.
- xray смотрит на 127.0.0.1:53 (UDP — fast).
- AdGuard Home сам берёт upstream и применяет фильтры.
- Никаких HTTPS-handshake'ов на DNS-resolve.

#### P2-3. State snapshot перед изменением
- `montana-config-snapshot` — копирует `/usr/local/etc/xray/config.json` + `/etc/systemd/system/xray.service.d/*` в `/var/lib/montana/snapshots/<timestamp>/`.
- Auto-snapshot перед каждым изменением через `vpn-rollout.sh`.
- `montana-config-restore <timestamp>` — откат.

### P3 (долгосрочно)

#### P3-1. Полная независимость management plane от Moscow
- Перенос orchestrator + сайта `montana.quest` на отдельный мелкий VPS в EU (не VPN-узел).
- Сейчас Moscow IP опубликован в публичных артефактах, что делает его уязвимым.

#### P3-2. Multi-region orchestrator
- Активный orchestrator + standby на другом узле.
- При падении основного — standby перехватывает через DNS-failover (cdn-orch.montana.quest multi-A с watchdog).

## Что НЕ надо делать снова

1. **Не раскатывать изменения сразу на все узлы.** Всегда canary FRA → 30мин → остальные.
2. **Не использовать DoH в xray внутри.** Любые HTTPS-upstream создают O(n) connections на каждый запрос пользователя.
3. **Не оставлять xray без `LimitNOFILE` и `MemoryMax`.** xray должен умирать первым, не утягивая sshd.
4. **Не делать массовых SSH-операций** на узел из одного скрипта без backoff. Collector гнал ~60 SSH/мин — могло триггерить fail2ban либо просто load.
5. **Не считать что Reality :443 живой = узел рабочий.** Reality может работать на kernel-уровне даже если xray внутри залип. Реальная проверка — end-to-end HTTP запрос через VPN.

## Checklist при восстановлении FI

1. Узел загрузился, sshd отвечает.
2. `systemctl is-active xray` = active.
3. `ss -tlnp | grep :443` — слушает.
4. `reality probe` от внешнего хоста → Verification: OK.
5. **Реальный** end-to-end тест: `curl --proxy socks5h://localhost:1090 https://google.com` через локальный xray-клиент → 200 OK.
6. Применить P0-1, P0-2, P0-3.
7. Записать в `OPEN-RISKS.md` как закрытый риск `R-old-N`.

## Тайминг
- P0 — **в течение 1 часа** после возвращения FI.
- P1 — **до 2026-05-26.**
- P2 — **до 2026-06-19.**
- P3 — **в плане роадмапа.**