umnybot: tg+rustdesk поддомены через основной NPM — DNS, Basic Auth ACL, LE-серты

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-11 23:40:57 +03:00
parent a1e8fd4312
commit bf83c01324
131 changed files with 8271 additions and 3 deletions
--- a/decisions/2026-06-04-deapple-migration-roadmap.md
+++ b/decisions/2026-06-04-deapple-migration-roadmap.md
@@ -0,0 +1,72 @@
+---
+дата: 2026-06-04
+тема: Деамериканизация личного цифрового стека (уход от Apple)
+статус: в работе (roadmap)
+теги: [privacy, deapple, degoogle, nextcloud, grapheneos, linux, миграция]
+---
+
+# Уход от Apple — план миграции
+
+## Мотивация
+Олег принял решение убрать зависимость личного цифрового стека от американских
+big-tech. Драйверы:
+- **Геополитический риск отключения** — санкции, нет официальной поддержки Apple в РФ,
+  реальный риск блокировки Apple ID / App Store / iCloud.
+- **Приватность** — недоверие к тому, что данные уходят в США через сервисы Apple
+  (телеметрия, iCloud, подчинение Apple законам США).
+- **Личное** — триггер: телефонные мошенники обманули и обокрали мать (накопления за
+  7,5 лет). Принципиальное нежелание зависеть от чего-либо американского.
+
+## Ключевой принцип (чтобы не сделать хуже)
+**Уход от Apple ≠ уход на Google.** Голый Android = Google = та же юрисдикция США и
+более жёсткий сбор данных. Цель — **degoogled + self-hosted**, а не смена одного
+US-вендора на другого.
+
+## Threat model — три разные угрозы (раньше слиплись в одну)
+1. **Телефонное мошенничество (мать)** — НЕ решается сменой телефона. Решение: банковский
+   антифрод + блокировка звонков + обучение. Отдельный человеческий трек.
+2. **Риск отключения сервисов санкциями** — решается уходом от единого гейткипера:
+   Android умеет sideload (APK напрямую, без регионального аккаунта — убирает старую
+   возню с TJ/US Apple ID), на десктопе Linux.
+3. **Утечка данных в США** — решается degoogled-ОС + своими сервисами вместо облака.
+   Здесь главный козырь уже есть: **Nextcloud AIO на dttb.ru.**
+
+## Треки
+
+### 1. iCloud → Nextcloud (СТАРТ — бесплатно, безрисково, не зависит от железа)
+Увести с iCloud на свой Nextcloud: контакты (CardDAV), календарь (CalDAV), фото
+(автозагрузка), файлы, заметки. Работает при любом телефоне.
+- [ ] Обследовать NC: версия, свободное место, приложения Contacts/Calendar/Photos
+- [ ] Контакты: экспорт vCard из iCloud → импорт в NC Contacts, настроить CardDAV на устройстве
+- [ ] Календарь: экспорт .ics → NC Calendar, CalDAV
+- [ ] Фото: оценить объём медиатеки, автозагрузка в NC
+- [ ] Файлы/заметки
+- Открытые вопросы: включён ли Advanced Data Protection в iCloud; объём медиатеки (ГБ);
+  что из iCloud реально критично.
+
+### 2. Антифрод для матери (человеческий приоритет, параллельно)
+Защита от повторения. НЕ про смену техники.
+- [ ] Банковские лимиты + подтверждение операций, антифрод банка
+- [ ] Блокировщик звонков / определитель, белый список контактов
+- [ ] Разговор о схемах социнженерии
+- Открытые вопросы (нужны от Олега): банк матери; тип телефона (кнопочный/смартфон,
+  Android/iPhone); кто физически рядом помогает настроить.
+
+### 3. Телефон → degoogled Android
+Кандидаты: Pixel + GrapheneOS (максимум приватности) либо /e/OS. Российские/Аврора для
+daily driver пока сыро.
+- [ ] **RESEARCH до покупки:** РФ-банковские приложения, Mir Pay, NFC-оплата на GrapheneOS
+  без GMS — работает или стоп-фактор? (Play Integrity / push без GMS)
+- [ ] Выбор модели и ОС
+- [ ] План переноса: мессенджеры, банки (APK с сайтов), 2FA, Госуслуги
+- Открытые вопросы: бюджет; нужен ли NFC-платёж; критичные приложения.
+
+### 4. Mac → Linux (последним, осторожно)
+Самый высокий риск сломать рабочий процесс. Mac держим как fallback на переходный период.
+- [ ] Выбор дистрибутива
+- [ ] Перенос: knowledge-base (rclone-bisync + Stop-hook), Claude Code CLI, NetBird, тулинг
+- Открытые вопросы: модель Mac (Apple Silicon → Asahi Linux? или отдельное x86-железо);
+  готовность держать переходный период.
+
+## Принцип миграции
+Ничего не выбрасываем, пока новое не проверено в бою. Параллельные периоды на каждом треке.
--- a/decisions/2026-06-04-lipki-deco-p9-powerline-degradation.md
+++ b/decisions/2026-06-04-lipki-deco-p9-powerline-degradation.md
@@ -0,0 +1,75 @@
+---
+date: 2026-06-04
+type: decision
+status: pending-visit
+tags: [lipki, deco-p9, powerline, homeplug, mesh, visit-required]
+project: lipki
+---
+
+# Липки — деградация Deco P9 mesh (гипотеза: главный в фильтре/UPS)
+
+## Симптом
+
+Клиент **Антон** (Липки, Звенигород) сообщил, что **«ничего не работает»**. Раньше работало стабильно.
+
+## Диагностика 2026-06-04
+
+**Роутер `OpenWrt_Lipki` (100.70.35.234) — чист:**
+- Uptime 7д, load 0.17
+- WAN eth0 5.101.135.71, default gw отвечает
+- Internet (1.1.1.1, 77.88.8.8) — 0% loss
+- DNS через подкоп `127.0.0.42` — резолвит ya.ru, google.com
+- NetBird Connected, peers 34/63
+- Память 219MB free, swap 0
+- dnsmasq, sing-box, netbird, hostapd — все процессы живы
+
+**LAN — прогрессирующая деградация Deco P9 mesh:**
+
+| IP | Имя | 11:21 | 12:42 (через 1ч) |
+|---|---|---|---|
+| 192.168.1.35 | deco-master | ❌ | ❌ |
+| 192.168.1.67 | deco-2 | ✅ | ✅ |
+| 192.168.1.173 | deco-3 | ✅ | ❌ |
+| 192.168.1.80 | deco-4 | ✅ | ✅ |
+| 192.168.1.179 | HiTEPRO (терминал) | ✅ | ❌ |
+| 192.168.1.192 | Ajax-сигнализация | ❌ | ❌ |
+| 192.168.1.201 | client | ✅ | ❌ |
+
+За час отвалились ещё 3 устройства (deco-3, HiTEPRO, .201). 2 из 4 Deco-узлов мёртвых.
+
+## Гипотеза (вероятная причина)
+
+**Главный Deco P9 (192.168.1.35) подключён к удлинителю / сетевому фильтру / UPS.**
+
+Deco P9 использует **HomePlug AV2 (Powerline)** как mesh-backbone между узлами — не WiFi-mesh. Любой сетевой фильтр / стабилизатор / источник бесперебойного питания **глушит сигнал HomePlug**, потому что:
+- В фильтрах стоят LC-цепи, отсекающие ВЧ-помехи (а HomePlug — это и есть ВЧ-сигнал поверх 50 Гц).
+- В UPS — импульсные преобразователи, ставят сильный шум в той же полосе.
+- Удлинители с защитой от перенапряжения — то же самое.
+
+Раньше работало → значит изначально было воткнуто напрямую в стенную розетку. **Что-то изменилось** (переставили, добавили фильтр, заменили удлинитель, добавили UPS на щиток).
+
+## Что нельзя сделать удалённо
+
+- У Deco P9 **нет SSH/Telnet/USB-консоли** — через ОС не оживить.
+- TP-Link app в режиме AP (Deco работают как точки доступа за OpenWrt) — функция Reboot узла часто не работает.
+- Даже если cloud-команда дойдёт до главного — она пойдёт дальше по powerline до мёртвых узлов. А backbone и сломан.
+
+ARP-spam, flush DHCP leases, restart dnsmasq на стороне OpenWrt — пробовал, на зависший WiFi-radio / powerline не действуют.
+
+## План на визит (запланирован: завтра-послезавтра)
+
+1. **Найти главный Deco (192.168.1.35) и проверить во что он воткнут.**
+   - Если в фильтр / удлинитель / UPS — **перевоткнуть напрямую в стенную розетку**.
+   - То же для всех остальных узлов Deco (.67, .80, .173).
+2. **Power-cycle всех узлов** — выдернуть-воткнуть на 30 секунд каждый.
+3. Проверить, что HiTEPRO (терминал, .179) и Ajax-хаб (.192) подключены **напрямую в LAN-порт OpenWrt или в живой Deco**, а не висят на powerline через мёртвый узел.
+4. Зафиксировать в README текущий расклад: какой узел где стоит, во что воткнут, в каком помещении.
+
+## Долгосрочно
+
+Заменить Deco P9 (Powerline-mesh) на нормальный WiFi-mesh — например **Deco X-серия** (X20/X50/X60) или **Asus ZenWiFi**. Powerline всегда лотерея — зависит от качества электропроводки и набора потребителей в розетках, к которым со временем добавляется хлам с импульсными БП.
+
+## Связанные
+
+- [[../projects/lipki/README]]
+- [[../claude-memory/feedback_lipki_deco_powerline]] (если будет создана)
--- a/decisions/2026-06-05-benelux-blackout-fw4-recovery.md
+++ b/decisions/2026-06-05-benelux-blackout-fw4-recovery.md
@@ -0,0 +1,82 @@
+---
+date: 2026-06-05
+type: decision
+tags: [benelux, openwrt, firewall, fw4, nftables, blackout, recovery, alex-bot]
+status: closed
+severity: critical
+---
+
+# Бенелюкс — после blackout вся LAN без интернета: `fw4` не строит `forward` chain
+
+## Симптомы (поверхностные)
+
+- Александр пожаловался: «после отключения электричества интернет не работает»
+- В `unifi.ui.com` UniFi-консоль (UCK G2 Plus `Benelyuks`, `192.168.1.199`) показана **Offline** с прошлого дня — у неё часы отстали почти на 19 часов (NTP не достучался)
+- Mac, телефоны, IoT — Wi-Fi видят, IP получают, но «без интернета»
+- При этом **сам Cudy роутер** (`100.70.207.97` через NetBird) полноценно работает, ping `8.8.8.8` от него = 0% loss
+
+## Корневая причина
+
+После blackout-перезагрузки Cudy пакет `firewall4` (v2024.12.18, OpenWrt 24.10.3) не смог собрать ruleset, потому что **новый `nftables v1.1.1` отказался парсить старый синтаксис в `/etc/nftables.d/*.nft`**:
+
+```nft
+chain dstnat {       # ← UNEXPECTED '{', expecting string or last
+  iifname "wt0" tcp dport ... dnat ip to ...
+}
+chain printer_dnat_pre {       # ← Chain of type "nat" is not supported
+  type nat hook prerouting priority dstnat; policy accept;
+  ...
+}
+```
+
+Файлы, написанные раньше, использовали **chain-with-type-hook** или **add-rules-to-existing-chain-via-block** — оба синтаксиса в v1.1.1 либо не поддерживаются вообще, либо требуют точное соответствие имени уже существующего chain в `table inet fw4`.
+
+Поскольку парсер падал на каждом из этих файлов, **fw4 откатывался** и **не создавал `forward` и `dstnat` chains вообще** → весь LAN-форвардинг через NAT отсутствовал → ни одно устройство в `192.168.1.0/24` не могло выйти наружу. UCK не достукался до облака Ubiquiti → UI cloud = Offline. Параллельно с этим её время отстало (NTP UDP/123 режется провайдером «Умные сети») — это две **независимые** проблемы.
+
+## Что сделал в восстановлении
+
+1. **Поставил время UCK вручную** через SSH (`date -u -s "..."; hwclock -w`)
+2. **Диагностика nft**: ядро (`nft_chain_nat`, `nf_nat`, `nft_ct`) и userspace (`v1.1.1`) на месте, ручные команды через arg работают, но `nft -f file` со стандартным fw4-output падает на пользовательских includes
+3. **Случайно усугубил**: `opkg install --force-reinstall firewall4` без `opkg update` — opkg сначала удалил пакет, потом не смог скачать (репозиторий блокировался). `fw4` исчез. Скачал `.ipk` с Mac → `scp -O` (legacy режим, потому что Cudy без sftp-server) → `opkg install /tmp/firewall4.ipk` ✓
+4. **Отключил все user-`.nft`-файлы** (`mv → .disabled-20260605-syntax`), оставил только `10-custom-filter-chains.nft` (дефолтный шаблон от пакета) → `fw4 reload` поднял базовый ruleset с `forward`/`dstnat`/`srcnat` chains → LAN-форвардинг заработал
+5. **Подкоп**: создал зону `awg` через UCI (`uci add firewall zone` + `device='awg0'` + `masq=1` + forwarding `lan → awg`) → подкоп заработал (`api.telegram.org` HTTP 302 за 0.27s)
+6. **Удалил принтер-файлы окончательно** (Олег сказал не нужны)
+
+## Что временно отключено (`.disabled-20260605-syntax`)
+
+| Файл | Назначение | Что внутри |
+|---|---|---|
+| `00-emergency-block.nft` | input drop SSH с WAN | Дубликат wan-zone drop, **не критично** |
+| `51-awg0-masq.nft` | masquerade `awg0` для LAN | **Заменено UCI-зоной `awg`** (см. выше) |
+| `99-incident-20260520.nft` | output drop SMTP/SSH + forward drop SSH | Бот Алекс `alex-secwatch.sh` через `nft insert rule` восстановит SSH-блок каждые 15 мин; SMTP-output на роутере и так не нужен |
+
+## Что узнал про бота Алекса
+
+Подозревал что бот деплоит битые `.nft` файлы → проверил. **Бот невиновен**, его архитектура **правильная**:
+
+- `/opt/assistant/alex-secwatch.sh` (крон `*/15`) использует **`nft insert rule inet fw4 input iifname "eth0" tcp dport 22 counter drop comment "..."`** — это **runtime-вставка через arg-синтаксис**, который **поддерживается в nft v1.1.1**
+- Никаких записей в `/etc/nftables.d/` бот не делает
+- Битые .nft файлы создал я (Claude) в предыдущих сессиях, не бот
+
+## Правило на будущее: как добавлять firewall-правила на Бенелюксе (и любом OpenWrt 24.10+)
+
+| Цель | Как делать | Что НЕ делать |
+|---|---|---|
+| Persistent через ребут | **UCI**: `uci add firewall rule/redirect/zone/forwarding`, потом `uci commit firewall; fw4 reload` | НЕ писать `/etc/nftables.d/*.nft` с `chain xxx { type ... hook ... }` или с `chain xxx { ... }` блоком |
+| Runtime, временно | `nft insert rule inet fw4 <chain> <expression>` через SSH (как делает бот Алекс) | — |
+| DNAT (port forward) | `uci add firewall redirect; uci set firewall.@redirect[-1].target='DNAT'; uci set ...src_dport ...dest_ip ...dest_port; uci commit; fw4 reload` | НЕ писать вручную `chain printer_dnat_pre { type nat hook prerouting ... }` |
+| Masquerade-зона для нового интерфейса (`awg0`, `wt0` и др.) | `uci add firewall zone; uci set ...device='awg0' masq='1'; uci add firewall forwarding; uci set ...src=lan dest=awg; uci commit; fw4 reload` | — |
+
+## Открытое для бота Алекса
+
+Если в будущем бот должен деплоить какие-то правила (например автоматический проброс принтера или DNAT для нового сервиса):
+- использовать `uci add firewall redirect ...` через SSH к Cudy (persistent),
+- или `nft insert rule` (временно, как уже делается для SSH-блока).
+
+**Никогда** не писать в `/etc/nftables.d/*.nft` с `chain xxx { ... }` синтаксисом — оно работало на старом nft (v1.0.x), но в v1.1.1 OpenWrt 24.10.3 ломает весь fw4.
+
+## TODO
+
+- [ ] При следующем доступе на Cudy — перепроверить что `alex-secwatch.sh` через `nft insert` восстановил SSH-WAN-блок (должно произойти через 15 мин от 09:30 UTC)
+- [ ] Долгосрочный фикс времени UCK: включить ntpd-сервер на Cudy (`uci set system.ntp.enable_server=1`) и в UI UCK Network → System → NTP прописать `192.168.1.1` (см. [[../projects/benilux/credentials#известная-проблема-ntp-не-работает]])
+- [ ] Удалить файлы `*.disabled-20260605-syntax` с роутера через 1-2 недели когда подтвердим что ничего не сломалось
--- a/decisions/2026-06-08-finland-vless-happ-dns-diag.md
+++ b/decisions/2026-06-08-finland-vless-happ-dns-diag.md
@@ -0,0 +1,67 @@
+---
+date: 2026-06-08
+type: incident
+tags: [vpn, finland, vless, happ, xray, reality, dns, podkop]
+aliases: [finland5870 vless не работает, Happ DNS 8.8.8.8]
+status: in-progress
+---
+
+# Finland5870 VLESS «не работает» — диагностика (продолжить завтра)
+
+Жалоба Олега: vless на `202.71.12.186` не работает (общий сервер для всех клиентов, не только Сергей).
+Симптом проявился на Mac Олега через клиент **Happ** (профиль «🇫🇮Финляндия»).
+
+## Что установлено ТВЁРДО
+
+### Сервер исправен
+- `202.71.12.186` = **finland5870.com**, ISP **Hostkey AS57043 Helsinki**, биллинг/панель **AdminVPS** (`my.adminvps.ru`). НЕ Singapore (у Сергея в README гео ошибочно — поправить).
+- Доступ: только **root, key-only, через jump** = code-server. Рабочая схема:
+  `ssh root@100.70.92.138` (Mac-ключ id_ed25519) → оттуда `ssh root@202.71.12.186` (ключом code-server).
+  Прямой `ssh -J` с Mac НЕ работает (на target лежит ключ code-server, не Mac). Прямой вход с Mac запрещён by design.
+- `amnezia-xray` **running**, Restarts=0, слушает **:9443** (НЕ :443!). Сервер ребутался 2026-06-07 ~20:43 UTC, всё поднялось (restart=always).
+- На `:443` ничего нет и не было (нет haproxy/nginx/контейнера) — клиентские конфиги на :443 битые в принципе.
+
+### Актуальные Reality-параметры (server.json + *.key)
+| Поле | Значение |
+|---|---|
+| Порт | `9443` |
+| pbk (publicKey) | `WxwIoiVyCkAoQ05xHEcRnTCTvK0uXfEmaGB-C7wPPBw` |
+| sid (shortId) | `2721326dfa367e20` |
+| dest / SNI | `www.googletagmanager.com` |
+| flow | `xtls-rprx-vision` |
+| UUID (4 шт) | `20cb0525-057f-4976-b876-4c257f214d1d`, `c22b6e34-ceca-4977-97a0-2b1e6b4035a7`, `1e70e2a1-da17-4f7a-b835-56e9b37c600b`, `a2deaa61-9645-4d77-b5f7-8a1978da690d` |
+
+Старые (битые) параметры, гулявшие у клиентов: порт `443`, pbk `duDwOkEDWQUnY_oMjDGlUFvUFBdCSxo5fiudmGL4XgQ`, sid `cc75ad57d3b0bb9b` — сменились при пересборке xray в конце апреля (после malware-инцидента 24.04, см. [[2026-04-24-finland-vps-malware-cleanup]]).
+
+### Reality из РФ проходит — РКН НЕ душит
+- e2e через code-server (xray-клиент, актуальные параметры) → выход `202.71.12.186` FI/HOSTKEY. ✅
+- openssl с Mac (РФ, без VPN) → `202.71.12.186:9443`, SNI googletagmanager: TCP 20ms, отдаёт **Google-сертификат** `*.google-analytics.com`, Verify OK. ✅
+- → фрагментация для обхода DPI НЕ нужна.
+
+## КОРЕНЬ проблемы на Mac (Happ)
+
+1. **Фрагментация Happ ломала канал.** В конфиге было `outbound proxy → sockopt.dialerProxy="antifilter"` → socks `127.0.0.1:10810`. Фрагментатор на 10810 мёртв (история крашей `tag=antifilter ping ... io: read/write on closed pipe`). Весь vless заворачивался в мёртвый 10810.
+   → **СДЕЛАНО: Настройки Happ → Туннель → «Использовать фрагментирование» = ВЫКЛ.** (Reality и так проходит, фрагментация лишняя.)
+
+2. **DNS-замок (главный нерешённый).** Happ резолвит домены через DoH `https://8.8.8.8/dns-query` (Google). Логи Happ забиты:
+   `[Error] app/dns: failed to retrieve response for www.google.com > Post "https://8.8.8.8/dns-query": context deadline exceeded`
+   → все резолвы валятся → Happ считает `all outbound return -1` → рвёт туннель (после старта порты 108xx гаснут).
+   - Google DoH `8.8.8.8` **заблокирован из РФ напрямую** (проверено: пусто).
+   - DoH 8.8.8.8 в конфиге маршрутизируется через proxy (vless), но всё равно timeout даже после отключения фрагментации.
+   - При этом в `access.log` 21:50 были УСПЕШНЫЕ `socks-in >> proxy` (vless-data из РФ ходил) — значит канал способен работать, спотыкается именно DNS.
+
+## TODO завтра
+1. **Сменить DNS-резолвер в Happ** (routing-набор «RoscomVPN» задаёт DoH 8.8.8.8 + 77.88.8.8). Google 8.8.8.8 из РФ дохлый. Варианты:
+   - Yandex DoH правильным endpoint (`77.88.8.8/dns-query` отдаёт «Not Found» — путь неверный; проверить `https://common.dot.dns.yandex.net/dns-query`).
+   - Cloudflare `https://1.1.1.1/dns-query` через proxy.
+   - Или plain `1.1.1.1`/`8.8.8.8:53` через proxy вместо DoH.
+2. После DNS-фикса проверить: подключить Happ → `lsof 10808` живёт → `curl --socks5-hostname 127.0.0.1:10808 https://api.ipify.org` + youtube.
+3. Решить раздачу остальным клиентам (Сергей/Бенелюкс/Знаменское/Lipki): у кого конфиг на `:443`/старый pbk — перевыпустить на `9443`/`WxwIoi`/`2721326`.
+4. Поправить КБ: гео finland5870 (Сергей README: Singapore→Finland), старые vless-ссылки на :443 в notes/snippets, путаница Hostkey vs AdminVPS.
+
+## Рабочая vless-ссылка (актуальная, проверена e2e)
+```
+vless://20cb0525-057f-4976-b876-4c257f214d1d@202.71.12.186:9443?type=tcp&security=reality&fp=chrome&sni=www.googletagmanager.com&pbk=WxwIoiVyCkAoQ05xHEcRnTCTvK0uXfEmaGB-C7wPPBw&sid=2721326dfa367e20&flow=xtls-rprx-vision&encryption=none#Finland-9443
+```
+
+Связано: [[../projects/dttb/finland-hostkey-vps]], [[../projects/sergey/README]], [[2026-04-24-finland-vps-malware-cleanup]]