wiki(ingest): vds-kzntsv network-stack mismatch RCA + ifupdown anti-pattern

Incident 2026-05-28 ~05:45–13:52 MSK на vds-kzntsv. ~2.5ч активного outage
+ ~5.5ч на эфемерной статике до окончательного fix хостером.

Revised RCA: наш netplan+systemd-networkd конфликтовал с provider's expected
ifupdown stack. Их start/ipadd procedure ожидает чистый ifupdown и не может
auto-recover когда networkd «держит» eth0. 8 дней работало потому что
networkd сам тянул DHCP. Когда что-то на стороне Rusonyx разорвало
DHCP-binding — auto-recovery не сработала.

Fix: systemctl mask netplan + systemd-networkd* (на running system без stop —
IP и SSH сохранились), Rusonyx ребутнул VM и положил чистый
/etc/network/interfaces.d/ifcfg-eth0 через свой start/ipadd. Netmask /18,
gw 89.253.192.1, чистый ifupdown.

Wiki:
- NEW concepts/vds-kzntsv-dhcp-outage-2026-05-28 — full RCA + recovery
  runbook (эфемерная статика + permanent-fix via ifupdown) + diagnostic
  dot-graph + revised lessons-learned + anti-pattern
- NEW sources/vds-kzntsv-incident-2026-05-28 — timeline 05:25 backup OK →
  08:43 statics → 13:52 final reset; provider's ifcfg-eth0 content; ticket
  text reference
- UPDATE entities/vds-kzntsv — mask /18, ifupdown stack, kernel cmdline
  net.ifnames=0 объясняет eth0 naming, hypervisor hw80, pass-store путь,
  Known issues §
- UPDATE concepts/rusonyx-vps-onboarding-quirks — quirk #9 переписан про
  /18 layout + canonical ifcfg, quirk #10 NEW про ifupdown vs netplan
  stack choice + bootstrap mask commands
- UPDATE index.md + log.md

Tasks:
- STATUS header: incident RESOLVED summary
- NEXT_SESSION: следующая сессия — cleanup netplan-artifacts (optional),
  registry GC (~20G pending), board-viewer-build unhealthy разбор

Memory (out-of-repo): vds-kzntsv-rusonyx-network-recovery переписан с
revised RCA — canonical bootstrap step «mask netplan/networkd» для всех
Rusonyx Ubuntu VDS.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.wiki/concepts/rusonyx-vps-onboarding-quirks.md

@@ -81,6 +81,84 @@ OpenSSH for Windows **не имеет** `-pw` flag (как `plink`/PuTTY) или
 
 См. также: support-ticket draft в [`vds-kzntsv-bootstrap-2026-05-20`](../sources/vds-kzntsv-bootstrap-2026-05-20.md) с конкретными suggestions для Rusonyx.
 
+## 9. Сеть = /18, не /24. Gw в той же subnet
+
+Rusonyx прописывает VM в **/18** (`netmask 255.255.192.0`), не в /24. Адреса `89.253.192.0 – 89.253.255.255` — это один большой L2 broadcast domain, gateway `89.253.192.1` сидит **внутри** него.
+
+Каноническая ifupdown-конфигурация (то что прописывает их `start/ipadd` procedure):
+
+```
+auto eth0
+allow-hotplug eth0
+iface eth0 inet static
+        address 89.253.255.94
+        netmask 255.255.192.0
+        post-up ip ro add 169.254.0.0/16 dev eth0 metric 400
+        post-up ip ro add 89.253.192.1 dev eth0 metric 400
+        post-up ip ro add default via 89.253.192.1 dev eth0 metric 400
+        post-up ip ro add 89.253.192.0/18 via 89.253.192.1 dev eth0 src 89.253.255.94 metric 400
+        post-up ip ro del 89.253.192.0/18 dev eth0 proto kernel scope link src 89.253.255.94
+```
+
+Тонкость: их post-up сначала добавляет 89.253.192.0/18 **через gw** (routed), потом удаляет автоматически добавленный kernel-route (directly attached). То есть весь трафик внутри /18 идёт **через gw**, не L2-broadcast — типичный hosting-pattern для изоляции клиентов друг от друга (`proxy-ARP` / routed-on-host).
+
+Эфемерная статика для recovery (если конфиг утерян):
+
+```bash
+sudo ip addr add 89.253.255.94/18 dev eth0       # /18 — gw сам в подсети, link-route не нужен
+sudo ip route add default via 89.253.192.1 dev eth0
+```
+
+Если по какой-то причине /18 не приемлем — fallback с /24 и link-route к gw:
+
+```bash
+sudo ip addr add 89.253.255.94/24 dev eth0
+sudo ip route add 89.253.192.1 dev eth0          # link-scope route к gw
+sudo ip route add default via 89.253.192.1
+```
+
+DNS resolvers: `89.253.252.30`, `89.253.252.31`.
+
+Как обнаружить gw/netmask для конкретной VM:
+
+1. **Соседний VPS у того же хостера** — `ip route` + `ip addr` покажут.
+2. **`/etc/network/interfaces.d/ifcfg-<iface>`** на самой VM (если конфиг present) — provider's canonical setup.
+3. Cached DHCP lease (если уцелел): `cat /run/systemd/netif/leases/*` → поле `ROUTER=`.
+4. Активационное письмо при выдаче VPS.
+5. Support ticket — последний resort.
+
+Подробный кейс где это пригодилось — [`vds-kzntsv-dhcp-outage-2026-05-28`](vds-kzntsv-dhcp-outage-2026-05-28.md).
+
+## 10. Network stack: ifupdown (NOT netplan)
+
+Rusonyx provisioning ожидает **`ifupdown` + `networking` service**, не netplan/systemd-networkd. Их `start/ipadd/ipdel` procedure (вызывается при start VM / IP add-remove / network reset) кладёт `/etc/network/interfaces.d/ifcfg-<iface>` и ребутает networking.
+
+Header в их `/etc/network/interfaces`:
+
+```
+# Autoconfigured by Provider's start/ipadd/ipdel procedure.
+# !!! DO NOT MANUALLY EDIT OR DELETE THIS FILE !!!
+```
+
+**Проблема**: Ubuntu 24.04 base ships netplan + systemd-networkd. cloud-init часто оставляет `/etc/netplan/50-cloud-init.yaml` с `dhcp4: true`. После первого boot оба стека активны параллельно. 
+
+Скорее всего **8 дней работает потому что DHCP сам всё резолвит**. Но если что-то на стороне хостера разорвёт DHCP-binding (rare, но случается — см. инцидент 2026-05-28), **их auto-recovery `start/ipadd` не сможет применить static config**, потому что networkd «держит» eth0. → VM лежит до тикета.
+
+**Канон setup после bootstrap для Rusonyx Ubuntu VDS:**
+
+```bash
+sudo systemctl disable systemd-networkd.service systemd-networkd.socket systemd-networkd-wait-online.service
+sudo systemctl mask    systemd-networkd.service systemd-networkd.socket systemd-networkd-wait-online.service
+sudo systemctl mask    netplan        # preventive
+# leave networking enabled (default)
+```
+
+**Безопасно на running system** — `disable`/`mask` без `stop` не убивают текущий процесс. Изменение вступает только при следующем boot.
+
+**Anti-pattern:** прописывать persistent статику через `/etc/netplan/*.yaml`. Использовать ifupdown (`/etc/network/interfaces.d/*`), а лучше — попросить хостера через тикет «настройте дефолтную конфигурацию» — они через `start/ipadd` пропишут это сами.
+
+Подробный кейс — [`vds-kzntsv-dhcp-outage-2026-05-28`](vds-kzntsv-dhcp-outage-2026-05-28.md).
+
 ## Когда применять
 
 - Любой новый Rusonyx VDS (Astra Облако).