[2026-09-23] eagle: family/projects/watchlist-automation.md personal/plans/lampac-watched-to-watchlist.md personal/tech/home-network-config.md

personal/tech/home-network-config.md

@@ -50,13 +50,26 @@ route -n get 192.168.2.197     # на Mac: какой gateway?
 
 | Узел | Доступ | Статус 2026-09-23 |
 |---|---|---|
-| Кра́кен `192.168.1.15` | `ssh kraken` (через `~/.ssh/config`) | ✅ работает |
+| Кра́кен `192.168.1.15` | ~~`ssh kraken`~~ | 🔴 **СЛОМАНА**: DNS отдаёт `.15` (wlan0, metric 600) → порт 22 открыт, но sshd рвёт на `banner exchange`. Рабочий адрес — `192.168.1.14` |
+| Кра́кен `192.168.1.14` | `ssh kraken@192.168.1.14` | ✅ **работает** именно так (eth0, активный) |
 | ASUS `192.168.1.1` | ~~`ssh -i ~/.ssh/id_rsa admin@192.168.1.1`~~ | ❌ **НЕ работает**: `Permission denied` → `Connection closed`. `nc -z 192.168.1.1 22` → closed. Маршруты — только веб-UI |
 | HTPC `192.168.1.86` | `ssh -i ~/.ssh/id_rsa bazzite@192.168.1.86` | (не проверялся в этой сессии) |
 | TrueNAS | `ssh truenas_admin@mallexxx.duckdns.org` | ✅ работает |
 | OpenWrt `192.168.2.2` | `ssh root@192.168.2.2` (прямой, по ключу) | (не проверялся в этой сессии) |
 
-⚠️ **У Кра́кена ДВА IP** — `.14` (eth0, активный default metric 100) и `.15` (wlan0, metric 600). `~/.ssh/config` резолвит `kraken` на `.15`. При построении маршрутов учитывать оба.
+⚠️ **У Кра́кена ДВА IP** — `.14` (eth0, активный default metric 100) и `.15` (wlan0, metric 600). **Работать через `.14`.**
+
+🔴 **`ssh kraken` (голый хостнейм) НЕ РАБОТАЕТ с 2026-09-23.** Причина — proxy-команда в `~/.ssh/config`:
+```
+if ifconfig | grep -q 10.99.0.2; then nc 10.99.1.2 22; else nc kraken 22; fi
+```
+На Mac интерфейса с `10.99.0.2` **нет** (WG-туннель до Кра́кена не поднят) → ветка `else` → `nc kraken 22` → DNS отдаёт мёртвый `.15` → `kex_exchange_identification: Connection closed by remote host`.
+
+**Обход:** всегда `ssh kraken@192.168.1.14` (или `ssh -o ... kraken@192.168.1.14`).
+**Проверка живости:** `nc -z -w 5 192.168.1.14 22 && echo OK`.
+**Заодно:** `ssh kraken` идёт через proxy, поэтому тяжёлые команды и длинные `jq` рвут соединение заметно чаще — дробить команды.
+
+🔴 **Симптом-ловушка:** обрыв SSH выглядит как «хост упал» / «контейнеры лежат». **Сначала проверить адрес и `ping`/`nc`**, а не лезть в `docker ps`. В этой сессии так и было: хост пинговался и был жив, load 0.02, `uptime 6:27` — сломан был только маршрут ssh.
 
 ## Прочие заметки из skill (краткая выжимка)