mmfb/lionart-1c: SSH + фикс efsaveragent + накопленный backlog vault-а

Сегодня (mmfb / LionART 1C): - projects/mmfb/lionart-1c.md — новый файл: VM 100 на pve LionART (WIN-70M2VEJIKEF, 10.253.1.240, Win Server 2022, 1С+SQL+Effector Saver), SSH-доступ claude/Kl@udeD1ag!2026 заведён, RDP под Администратор + 2FA. - projects/mmfb/proxmox-inventory.md — hostname WIN-70M2VEJIKEF в VM 100. - decisions/2026-05-28-mmfb-effector-saver-locked-admin.md — диагноз цикла 7038 (SCM-пароль разъехался с .\Администратор) + lockout учётки, и пошаговое решение (disable службы → ADSI unlock → LogonUser-проверка → sc.exe config password= → start auto). Накопившийся backlog (без отдельной правки в эту сессию): - decisions/: buzharovo (recon, migration-plan, 1c-licensing), sergey (instagram iPhone fakeip), amneziavpn macOS v1/v2 incompat, benelux compromise 2026-05-20, glavtorg autologon off, omni domain+update. - projects/: benilux README, buzharovo README+server1c, dttb (nextcloud-talk-bot, npm-proxy-hosts, proxmox-inventory, vpn-clients), glavtorg, sergey README, projects/_index. - claude-memory/: benelux, omniroute. - snippets/mac-dictation/groq-dictate.sh. - notes/claude/: ~80 авто-сохранённых транскриптов сессий за май. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-28 21:56:35 +03:00
parent e994661bd7
commit bf565f1392
269 changed files with 9466 additions and 74 deletions
--- a/decisions/2026-05-05-mac-dictation-groq-hammerspoon.md
+++ b/decisions/2026-05-05-mac-dictation-groq-hammerspoon.md
@@ -31,6 +31,8 @@

 5. **ffmpeg avfoundation `:0`** = default mic. Если нужен другой — `ffmpeg -f avfoundation -list_devices true -i ""`.

+6. **PATH в Hammerspoon** при автозапуске пустой — `ffmpeg: command not found`. Симптом: после перезагрузки Mac диктовка не работает, в логе `command not found`. Лечится `export PATH="/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin"` в начале скрипта. ВАЖНО: doctor использует mой shell PATH и потому видит ffmpeg — НЕ показатель что Hammerspoon тоже видит. Проверять через `env -i HOME=$HOME bash -c 'PATH=/usr/bin:/bin ~/bin/groq-dictate.sh'`.
+
 ## Стоимость
 - Hammerspoon бесплатный
 - Groq бесплатный (14400 req/day, ~120 минут диктовки в день — намного больше нужного)
--- a/decisions/2026-05-07-buzharovo-migration-plan.md
+++ b/decisions/2026-05-07-buzharovo-migration-plan.md
@@ -0,0 +1,310 @@
+---
+date: 2026-05-07
+type: decision
+tags: [buzharovo, 1c, migration, plan]
+status: approved
+target_stack: windows-mssql
+related:
+  - "[[decisions/2026-05-07-buzharovo-recon]]"
+  - "[[projects/buzharovo/server1c]]"
+  - "[[projects/buzharovo/migration-prompt-2026-05-07]]"
+  - "[[decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash]]"
+---
+
+> **Решение по стеку (07.05.2026):** идём на **Windows Server VM + MSSQL** (Вариант W).
+> Linux/PostgreSQL отложен на потом. Причина выбора: простая миграция через нативный SQL `.bak` → `RESTORE`, без переобучения 6 терминальных юзеров (они продолжают работать через RDP), без отдельного термсервера. На масштаб ~6 юзеров и ~гигабайтной БД разница в скорости с Linux незаметна.
+>
+> **Лицензионная часть** (1С Server, клиентские, Windows Server) — за Олегом, обрабатывается отдельно. План описывает только техническую миграцию.
+
+# План миграции 1С Бужарово → HomeLab Proxmox
+
+**Цель:** перенести 1С с физического Server1C (Win 2012 R2, бытовая мать ASUS, без ИБП, 24+ крашей в день) на VM на HomeLab Proxmox (10.0.0.250), сохранив работу 6 терминальных юзеров и двух ПК-касс KASSA3/KASSIRULICA2.
+
+**Базис:** `decisions/2026-05-07-buzharovo-recon.md` (отчёт разведки 07.05.2026).
+
+## Критерии успеха
+
+1. ✅ Все 4 инфобазы 1С восстановлены и доступны для пользователей
+2. ✅ 6 RDP-юзеров (АртемК, ГорячевАЕ, Павел, ПальмановаН, ФирсовС, dttb) работают в 1С через RDP к новой VM
+3. ✅ KASSA3 (192.168.1.18) и KASSIRULICA2 (192.168.1.99) пробивают чеки через новую инфраструктуру (TCP до 1С-сервера через NetBird)
+4. ✅ Время простоя при cutover ≤ 4 часов (вечер пятницы или ночь субботы)
+5. ✅ Откат за ≤ 30 минут (старый Server1C остаётся включённым в Бужарово до недели после миграции)
+
+---
+
+## Архитектура: Вариант A (приоритетный)
+
+```
+                    Интернет
+                        │
+   ┌────────────────────┼─────────────────────────┐
+   │                    │                         │
+   ↓                    ↓                         ↓
+[Бужарово офис]    [сельский WISP/РТК?]    [HomeLab Москва]
+192.168.1.0/24                              10.0.0.0/24
+                                                │
+   ┌─────────────┐                              │
+   │  KASSA3     │                              ↓
+   │  192.168.   │     NetBird VPN              ┌────────────────┐
+   │  .1.18      ├──────────────────────────────│  Proxmox PVE   │
+   │  KASSIRUL2  │     (~96 ms RTT)             │  10.0.0.250    │
+   │  192.168.   │                              │                │
+   │  .1.99      │                              │  ┌──────────┐  │
+   │             │                              │  │ VM 1Cnew │  │
+   │  6× RDP-    │                              │  │ Win22/25 │  │
+   │  юзеров     │     RDP 3389 + 1С 1541       │  │ + 1С 8.3 │  │
+   │  (тонкие    │←─────────────────────────────│  │ + MSSQL  │  │
+   │  клиенты)   │                              │  │ 8 vCPU   │  │
+   │             │                              │  │ 32GB RAM │  │
+   │  Router-    │                              │  │ 200GB SSD│  │
+   │  Office     │                              │  └──────────┘  │
+   │ (NetBird    │                              │                │
+   │  + advertise│                              └────────────────┘
+   │  192.168.1/ │
+   │  24)        │
+   └─────────────┘
+```
+
+### Ключевые элементы
+- **Целевая VM:** новая на Proxmox 10.0.0.250 (имя `vm-1c-buzharovo` или подобное), Win Server 2022 или 2025, 8 vCPU, 32GB RAM, 200GB SSD (LVM/qcow на NVMe пуле)
+- **1С:** 8.3.27.1606 (тот же билд для совместимости), x64, **только одна** служба `1C:Enterprise 8.3 Server Agent (x86-64)` Auto
+- **MSSQL:** 2019 или 2022 (Express если суммарный объём всех 4 БД ≤ 10GB; Standard если больше — нужно подтвердить размер!)
+- **NetBird-агент** на VM с advertise-route 10.0.0.0/24 (или подключение к существующему "Dom" route group)
+- **NetBird на офисном роутере в Бужарово** с advertise 192.168.1.0/24 — это позволит KASSA3/KASSIRULICA2 общаться с новой VM прозрачно
+
+### Почему Вариант A, а не B
+- Сейчас ИДЕНТИЧНАЯ схема уже работает: 6 юзеров через RDP в Server1C запускают 1С локально на сервере → переезд просто меняет адрес сервера
+- 1С↔MSSQL остаются в одной локалке VM (latency 0.1ms внутри Proxmox), как сейчас
+- RDP толерантен к 96ms; толстый клиент 1С через NetBird тормозил бы при открытии справочников
+- Касса KASSA3 уже общается с 1С через TCP (порт 1560) → меняется только адрес, протокол сохраняется
+
+---
+
+## Фазы и эстимейты
+
+### Фаза 0: Pre-flight (1 час, до миграции)
+**Кто:** Олег + Claude Code
+**Что:** ответы на 8 открытых вопросов из `recon.md`:
+
+| # | Вопрос | Action |
+|---|---|---|
+| 1 | `sa`-пароль MSSQL? | Олег → 1Password / память / создать SQL-login |
+| 2 | Лицензия 1С: пинкоды? | Олег → ЛК на portal.1c.ru |
+| 3 | Имена 4 инфобаз | Олег → проверить через 1С-клиент или v8i-ярлык на ПК пользователя |
+| 4 | ПО на KASSA3/KASSIRULICA2 | Удалёнкой через RDP/AnyDesk на 192.168.1.18 |
+| 5 | Провайдер в Бужарово | Олег → договор / счёт |
+| 6 | Окно простоя | Олег + бизнес → согласовать |
+| 7 | Бюджет на ИБП / альтернатива «починить на месте» | Олег |
+| 8 | AnyDesk оставлять? | Олег |
+
+**Также:** определить SQL backup-метод (FULL+DIFF или COPY_ONLY backup → restore).
+
+### Фаза 1: Подготовка целевой VM (2-4 часа)
+
+**Шаги:**
+1. **Создать VM на Proxmox 10.0.0.250:**
+   - VM ID: например 112 (или соседний свободный)
+   - OS: Win Server 2022 RU (или 2025; ISO у Олега есть, ставился на VM 111)
+   - vCPU: 8 (с host-passthrough cpu-type)
+   - RAM: 32 GB (можно ballooning)
+   - Disks: 1 OS-disk 100GB qcow2 на быстром пуле + 1 data-disk 200GB для БД
+   - Сеть: vmbr0 → 10.0.0.0/24 (статический IP, например 10.0.0.197)
+2. **Базовая настройка Windows:**
+   - Hostname: `s1c-buzharovo` (или согласуем)
+   - Локаль: Russian
+   - Network: статика 10.0.0.197/24, gw 10.0.0.1, DNS 10.0.0.250
+   - Firewall: разрешить in 3389 (RDP), 1540-1591 (1С), 1433 (SQL только из NetBird-подсетей)
+   - Обновления Windows
+3. **Установка MSSQL:**
+   - Express или Standard (зависит от размера БД)
+   - Default instance MSSQLSERVER
+   - Mixed Mode auth, sa-пароль strong
+   - SQL Browser: Disabled (нам не нужен)
+4. **Установка 1С Предприятие 8.3.27.1606:**
+   - Server (x64), administrator components
+   - Создать 1 службу: `1C:Enterprise 8.3 Server Agent (x86-64)` — Automatic
+   - Ничего лишнего: ни 8.3.18, ни RagentServer_xxx
+5. **Настройка ОС:**
+   - Crash Dump: `CrashDumpEnabled=3`, pagefile фикс 8GB на C: (как на старом сервере)
+   - Performance: `Set-MpPreference -DisableRealtimeMonitoring $false` (или установить полноценный AV)
+   - Time zone: МСК
+6. **NetBird:**
+   - Установить netbird-агент
+   - Подключить к нашему tenant
+   - Проверить ping к Server1C (100.70.75.103) и доступ из NetBird-сети
+7. **RDP-юзеры:**
+   - Создать локальные учётки: `АртемК, ГорячевАЕ, Павел, ПальмановаН, ФирсовС, dttb`
+   - Добавить в `Remote Desktop Users` (для RDP) и `Users`
+   - Пароли на временных, потом сменить
+8. **WinRM 5985 / 5986** для нашей автоматизации (basic auth, Private network).
+
+**Артефакт фазы:** живая VM на 10.0.0.197, доступна по RDP/WinRM из NetBird.
+
+### Фаза 2: Тестовая миграция данных (3-5 часов)
+
+**Шаги:**
+1. **Бэкап SQL на Server1C** (вне рабочего времени!):
+   ```sql
+   BACKUP DATABASE [<db1>] TO DISK = 'D:\backup\<db1>.bak' WITH COPY_ONLY, COMPRESSION;
+   -- повторить для всех 4 БД
+   ```
+   - Размер бэкапов оценим сразу; время — зависит от размера, при 39GB может быть 30-60 мин
+2. **Передача .bak на HomeLab:**
+   - Через NetBird SMB (Server1C → s1c-buzharovo) или scp/rsync
+   - 39GB через 96ms NetBird ≈ зависит от throughput; реалистично 1-3 часа
+   - Альтернатива: бэкапить на USB на Server1C, привезти физически
+3. **Восстановление на новой VM:**
+   ```sql
+   RESTORE DATABASE [<db1>] FROM DISK='C:\restore\<db1>.bak' WITH MOVE ...;
+   ```
+4. **Регистрация инфобаз в 1С на новой VM:**
+   - Через `1cv8.exe` админ-консоль или ручной ввод
+   - 4 инфобазы → подключение к локальному `s1c-buzharovo:1541`
+5. **Smoke-тест:**
+   - Запустить тонкий клиент 1С на VM локально, открыть каждую базу
+   - Проверить: журнал регистрации, последние документы, базовые отчёты
+   - Сверить контрольные суммы / счётчики документов с боевой
+6. **Лицензия 1С:**
+   - Активировать программную лицензию через PIN (получить от Олега)
+   - Если резервных PIN нет — заявка в 1С-Партнёр на восстановление
+
+**Артефакт фазы:** на новой VM работают все 4 инфобазы (read-only тест).
+
+### Фаза 3: Тест с кассой (1-2 часа)
+
+**Шаги:**
+1. На одном ПК `KASSA3` (192.168.1.18):
+   - Поднять временный VPN/proxy до новой VM (либо через NetBird-агент на самой кассе, либо через NetBird на офисном роутере)
+   - В настройках кассового ПО изменить адрес сервера 1С (или v8i базы)
+   - Открыть тестовую копию рабочей базы
+   - Сделать тестовый чек: товар → пробить → ответ от ОФД
+2. То же самое для `KASSIRULICA2` если есть time
+3. Откатить изменения на касса-ПК (вернуть на боевой Server1C)
+
+**⚠ Важно:** не работать с боевой БД! Создать тестовую копию инфобазы для проверки чеков. Иначе двойной чек в ОФД.
+
+**Артефакт фазы:** подтверждение что новая инфраструктура совместима с кассой.
+
+### Фаза 4: Cutover (3-4 часа, окно простоя)
+
+**Окно:** вечер пятницы 18:00 → 22:00 МСК (после рабочего дня) или ночь сб → вс.
+
+**Шаги:**
+1. **Заранее (за день):** уведомить юзеров и кассиров о времени простоя
+2. **T-0:00** Объявить начало миграции, остановить работу пользователей
+3. **T+0:05** На Server1C финальный бэкап SQL (FULL + последний DIFF):
+   ```sql
+   BACKUP DATABASE [<db>] TO DISK='D:\backup\<db>_final.bak' WITH COPY_ONLY, COMPRESSION;
+   ```
+4. **T+0:30** Перенести `_final.bak` на новую VM через SMB
+5. **T+1:00** Восстановить на новой VM поверх тестовой копии
+6. **T+1:30** Smoke-test: 1С запускается, контрольные суммы совпадают
+7. **T+1:45** Перенаправить пользователей и кассу:
+   - RDP-юзеры: новый ярлык RDP к 10.0.0.197 (или через NetBird FQDN)
+   - KASSA3 / KASSIRULICA2: новый адрес 1С-сервера
+8. **T+2:00** Тестовая транзакция от первого юзера и первой кассы
+9. **T+2:30** ✅ Миграция завершена, пользователи возобновляют работу
+10. **T+3:00** Лог финального состояния, обновить vault
+
+**На Server1C в Бужарово:** НЕ выключать! Оставить работать ещё неделю как backup (можно перевести в read-only режим в 1С — отключить пишущие фоновые задания).
+
+### Фаза 5: Стабилизация (неделя)
+
+- Мониторинг: rmngr CPU на новой VM (watchdog уже есть на LXC 137)
+- Сбор обратной связи от пользователей
+- Бэкапы: настроить ежедневные на Proxmox-уровне (snapshot) + еженедельный SQL FULL backup
+- Через 7 дней без проблем — можно гасить старый Server1C
+
+---
+
+## Risk Register
+
+| # | Риск | Вероятн. | Импакт | Митигация |
+|---|---|---|---|---|
+| R1 | Лицензия 1С не активируется на новой VM (нет PIN, HWID-привязка) | Средняя | **Критичный** | Pre-flight: получить пинкоды от Олега; запасной план — обращение в 1С-Партнёр |
+| R2 | Размер SQL БД >10GB → нужен MSSQL Standard (платный) | Неизвестна | Средний | Pre-flight: получить sa-пароль, измерить размер; иметь готовую лицензию SQL Standard |
+| R3 | Касса KASSA3/KASSIRULICA2 не общается с новой 1С (firewall, COM, специфический протокол) | Низкая | Высокий | Фаза 3 — тест ДО cutover; держать резервный туннель на Server1C |
+| R4 | Канал в Бужарово упал в момент миграции → юзеры не могут переключиться | Низкая | Высокий | Cutover ночью; держать резерв (мобильный 4G) |
+| R5 | Бэкап повреждён или RESTORE с ошибкой | Низкая | **Критичный** | Сначала FULL+DIFF, проверка восстановлением до cutover; держать оригинал |
+| R6 | rmngr-loop повторится на новой VM (баг 8.3.27.1606) | Низкая | Средний | Watchdog уже работает; в крайнем случае — даунгрейд до 8.3.26 |
+| R7 | Production crash во время Phase 4 backup'а на Server1C | Высокая | Низкий | Бэкап быстрый (COMPRESSION), краш просто откатит наш cutover на 4 часа |
+| R8 | Юзеры не находят свои документы / сбит порядок (если несколько ИБ перепутали) | Средняя | Средний | Маппинг GUID→имя ИБ зафиксировать в pre-flight; дублирующие тесты с реальными документами |
+| R9 | Закрытие RDP в Интернет на старом Server1C преждевременно — юзер не сможет подключиться | Средняя | Низкий | Закрывать только после полного cutover + 1 неделя стабильности |
+| R10 | Касса в офисе работает с особым ПО (1С Розница нестандартного билда) | Низкая | Высокий | Phase 0: проверить через AnyDesk что стоит на 192.168.1.18 |
+
+---
+
+## План отката (≤ 30 минут)
+
+Если после cutover (Фаза 4) обнаружили блокирующий баг:
+
+1. **T-rollback+0:00:** объявить откат
+2. **T+0:05:** На клиентских ПК и кассах вернуть старый адрес сервера (1С: 100.70.75.103 / 192.168.1.249; кассы: 192.168.1.249)
+3. **T+0:15:** На Server1C запустить службу 1С (она и так работает в RO-режиме)
+4. **T+0:25:** Smoke-test от пары юзеров
+5. **T+0:30:** ✅ Откат завершён, работа на старом
+
+Условие отката: производственный блокер, не косметический.
+
+---
+
+## Чек-лист готовности к Phase 4 (Cutover)
+
+```
+[ ] sa-пароль SQL получен (#1)
+[ ] Лицензия 1С: пинкоды известны или есть онлайн-активация (#2)
+[ ] Маппинг GUID → имя инфобазы зафиксирован (#3)
+[ ] Кассовое ПО изучено (#4) и протестировано в Phase 3
+[ ] Канал в Бужарово протестирован (#5), резерв есть
+[ ] Окно простоя согласовано с бизнесом (#6)
+[ ] Решение по AnyDesk (#8): убрать или оставить
+[ ] Phase 1: VM s1c-buzharovo живая, RDP/WinRM/NetBird работают
+[ ] Phase 2: тестовая миграция данных прошла, 4 инфобазы открываются
+[ ] Phase 3: касса прошла тест чека через новую инфраструктуру
+[ ] Бэкап Server1C перед cutover есть и проверен restore'ом
+[ ] План отката известен команде, контакты Олега для эскалации
+[ ] Юзеры уведомлены за >24 часа до простоя
+```
+
+---
+
+## Альтернатива: «починить на месте»
+
+Если миграция отложена, минимальная починка Server1C в Бужарово:
+1. **Купить ИБП** (Eaton/APC, ~10000-15000 ₽) на 1500ВА для покрытия 5-10 минут просадок и корректного shutdown
+2. **Заменить мать на серверную** (с ECC, IPMI) — сложно/дорого, лучше тогда уж VM
+3. **Watchdog** уже есть (LXC 137 → rac.exe restart-service при rmngr-loop)
+4. **Бэкапы:** настроить ежедневный Veeam Free / Native SQL Backup → внешний диск + копия в HomeLab Nextcloud
+
+**Не отменяет миграцию**, но снижает срочность. Хорошая идея сделать ИБП параллельно с подготовкой VM — уменьшит крашы пока VM готовится.
+
+---
+
+## Open для обсуждения
+
+- ⚖ **Кто администратор новой VM** — Олег (как сейчас Server1C) или предложить более ограниченную модель (отдельный admin-аккаунт)?
+- ⚖ **Public IP / порт RDP** на HomeLab — нет; всё через NetBird. Согласовано?
+- ⚖ **Версия Win Server** — 2022 (стабильнее, дольше поддержка) или 2025 (новее, current на VM 111)?
+- ⚖ **Версия MSSQL** — оставить 2012 (max совместимость с 8.3.27, но EOL) или прыгнуть на 2019/2022 (поддерживается, может быть несовместимость с конфигурациями 1С)?
+
+---
+
+## Дефолтные параметры новой VM (для запуска Phase 1)
+
+| Параметр | Значение |
+|---|---|
+| **Proxmox host** | 10.0.0.250 |
+| **VM ID** | 112 (если свободен; иначе ближайший свободный) |
+| **Имя** | `s1c-buzharovo` |
+| **OS** | Windows Server 2022 Standard RU |
+| **vCPU** | 8 (host-passthrough) |
+| **RAM** | 32 GB |
+| **OS-диск** | 100 GB qcow2 |
+| **Data-диск** | 200 GB (для SQL БД) |
+| **Сеть** | vmbr0, статический IP `10.0.0.197/24`, gw 10.0.0.1, DNS 10.0.0.250 |
+| **MSSQL** | 2019 Standard (если БД >10GB) или 2019 Express (если ≤10GB — пока неизвестно) |
+| **1С платформа** | 8.3.27.1606 (та же что на старом) |
+| **NetBird** | агент установлен, подключён к нашему tenant |
+| **WinRM 5985** | для автоматизации |
+
+Если параметры устраивают — начинаем Phase 1 с этими дефолтами.
--- a/decisions/2026-05-07-buzharovo-recon.md
+++ b/decisions/2026-05-07-buzharovo-recon.md
@@ -0,0 +1,405 @@
+---
+date: 2026-05-07
+type: decision
+tags: [buzharovo, 1c, migration, recon]
+status: complete
+related:
+  - "[[projects/buzharovo/server1c]]"
+  - "[[projects/buzharovo/migration-prompt-2026-05-07]]"
+  - "[[decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash]]"
+---
+
+# Бужарово 1С: разведка перед миграцией на HomeLab
+
+**Дата:** 2026-05-07
+**Метод:** WinRM (basic, через NetBird) с LXC 137 (openclaw) на Server1C 100.70.75.103. Read-only WMI/PowerShell/sqlcmd/ping.
+**Цель:** собрать факты для плана миграции 1С с физического Server1C в Бужарово на HomeLab Proxmox 10.0.0.250.
+
+---
+
+## TL;DR
+
+| Тема | Факт |
+|---|---|
+| Hardware | ASUS PRIME Z690M-PLUS D4 + i5-12400 (6c/12t) + 64GB DDR4 + 3×Samsung 980 PRO 500GB NVMe |
+| OS | Windows Server 2012 R2 (build 9600), русский интерфейс |
+| 1С | 8.3.27.1606, x64, ровно одна рабочая служба `1C:Enterprise 8.3 Server Agent (x86-64)` |
+| MSSQL | SQL Server 2012 SP2 (11.2.5058) — **EOL с 2022-07-12** |
+| Кластер 1С | 1 кластер `Server1C:1541` GUID `473f3f9e-...8700c7`, 4 инфобазы |
+| Размер ИБ (на сервере) | 4 каталога в `srvinfo/reg_1541`: 7.3 / 4.8 / 15.2 / 12.0 GB (это **служебные данные кластера**, не SQL БД!) |
+| Размер SQL БД | **НЕИЗВЕСТЕН** — `dttb` не имеет SQL-логина, `sa`-пароль не подобран. Нужен у Олега. |
+| Касса | **Сетевые ПК-кассы** `KASSA3` (192.168.1.18) и `KASSIRULICA2` (192.168.1.99). USB-фискальников на сервере НЕТ. |
+| Лицензии 1С | HASP-ключа нет (служба `hasplms` Disabled), `.lic`-файлы не найдены → **программная онлайн-лицензия с привязкой к HWID** (риск!) |
+| Активные сеансы | ~5 уникальных удалённых клиентов через 1С + терминальные RDP-юзеры |
+| Сеть в офисе | 192.168.1.0/24, gw 192.168.1.1, 13 хостов |
+| Канал | ping 1.1.1.1 = 3ms (отличный), ping 8.8.8.8 = 15ms |
+| Latency до HomeLab (NetBird) | 96–99ms стабильно |
+| ИБП | **НЕТ** (`Win32_Battery` пуст) |
+| Краши | 24 «грязных ребута» 04.05.2026 (Kernel-Power 41 + 6008), все Bug=0/Power=0 → отключение питания |
+
+**Главные следствия для миграции:**
+1. Касса не привязана к серверу физически → пробрасывать USB не нужно. Кассы перенаправят на новый IP 1С-сервера через NetBird.
+2. Лицензия 1С — программная онлайн → перепривязка к новой VM сделается через 1С (PIN), но требует подготовки.
+3. SQL БД на старой 2012 — нужен экспорт/импорт; новая VM может ставить MSSQL 2019/2022.
+4. Нет ИБП + бытовая мать → крашы будут продолжаться, миграция оправдана.
+
+---
+
+## 1. Hardware и OS
+
+### Платформа
+```
+Manufacturer:    ASUSTeK COMPUTER INC.
+Product:         PRIME Z690M-PLUS D4
+BIOS:            AMI v1620, 2022-08-12
+Computer model:  ASUS / "System Product Name" (DIY-сборка, не серверный SKU)
+RAM:             64 GB DDR4 (2 модуля по 32GB), без ECC
+CPU:             12th Gen Intel(R) Core(TM) i5-12400 — 6 ядер / 12 потоков @ 2.5 GHz
+Disks (NVMe):    3× Samsung SSD 980 PRO 500GB (NVMe), статус OK
+                 SerialNumbers: 0025_38B2_31B4_8512 / _8508 / _84FE
+```
+
+**Вывод:** железо современное (12-е поколение Intel, NVMe), но **бытовое**:
+- нет ECC RAM → необнаруженные битовые ошибки в памяти могут вызывать крашы
+- нет IPMI/iLO/iDRAC → удалённого управления питанием нет
+- нет ИБП в системе (`Win32_Battery` пуст)
+- сертифицировано для Workstation, не для 24/7 server-нагрузки
+
+### OS
+```
+OS:        Microsoft Windows Server 2012 R2 Standard
+Build:     9600 (6.3.9600)
+PowerShell: 5.1.14409.1018
+Локаль:    Русская
+Hostname:  Server1C
+Uptime:    3h 51min на момент разведки (последний boot 09:56:42 после краша 09:05)
+```
+
+**Срок поддержки:** Windows Server 2012 R2 EOL **2023-10-10**. Без расширенных Security Updates. Серьёзная причина для миграции на 2022/2025.
+
+### Локальные пользователи
+```
+SERVER1C\dttb            — основной admin (наш WinRM-юзер)
+SERVER1C\Администратор   — встроенный admin
+SERVER1C\RemoteAdm       — для удалённого доступа (AnyDesk?)
+SERVER1C\АртемК          — RDP-юзер (1С)
+SERVER1C\ГорячевАЕ       — RDP-юзер (1С)
+SERVER1C\Павел           — RDP-юзер (1С)
+SERVER1C\ПальмановаН     — RDP-юзер (1С)
+SERVER1C\ФирсовС         — RDP-юзер (1С)
+SERVER1C\БольшаковаЕН    — RDP-юзер, отключён
+SERVER1C\Гость           — встроенный, без пароля
+```
+**6 активных юзеров-сотрудников** работают через RDP. Это значит сейчас сервер **работает в терминальном режиме**: люди ходят по RDP в Server1C и запускают там 1С-клиент. Это упрощает миграцию по варианту A (терминальная VM на HomeLab).
+
+### Удалённые доступы
+- **RDP (3389)** — открыт публично на 185.13.47.2:3389 (видны established с 176.62.183.186, 176.215.183.37)
+- **AnyDesk** — процесс запущен в системе
+- **NetBird** — `netbird.exe` v0.68.3, FQDN `server1c.netbird.cloud`, IP 100.70.75.103/16, peers 31/58 connected
+
+⚠ **RDP открыт в Интернет** — security risk. После миграции закрыть и оставить только NetBird.
+
+---
+
+## 2. 1С:Предприятие
+
+### Версия и службы
+```
+Версия 1С:    1C:Предприятие 8 (x86-64) 8.3.27.1606
+Издатель:     1С-Софт
+
+Службы (Win32_Service):
+  1C:Enterprise 8.3 Server Agent          — Stopped, Disabled (8.3.18, x86, бинарника нет)
+  1C:Enterprise 8.3 Server Agent (x86-64) — Running, Auto    ★ рабочая
+    PATH: "C:\Program Files\1cv8\8.3.27.1606\bin\ragent.exe" -srvc -agent
+          -regport 1541 -port 1540 -range 1560:1591
+          -d "C:\Program Files\1cv8\srvinfo"
+  RagentServer_8327                        — Stopped, Disabled (orphan)
+```
+
+Конфликт служб уже решён 2026-04-16 (см. `projects/buzharovo/server1c.md`). Сейчас одна корректная служба + два Disabled-дубликата.
+
+### Кластер и инфобазы
+```
+1cv8wsrv.lst:
+  cluster: 473f3f9e-4aea-43bc-ac45-ec98da8700c7
+  name:    "Локальный кластер"
+  port:    1541
+  server:  Server1C
+```
+
+Инфобазы (по содержимому `C:\Program Files\1cv8\srvinfo\reg_1541\`):
+
+| GUID (короткий) | Размер служебных данных |
+|---|---|
+| 00d417ca | 7 355 MB |
+| 426d93c8 | 4 793 MB |
+| 688e50c3 | **15 178 MB** (самая большая) |
+| 9e258b8f | 11 953 MB |
+| **Итого** | **~39.3 GB** |
+
+⚠ Это **не размер SQL БД**, а служебные данные кластера 1С (полнотекстовые индексы `1Cv8FTxt`, журналы, кэш). Реальный размер БД в SQL не получен (см. секцию 3).
+
+Файла `1CV8Reg.lst` в корне `reg_1541` нет — только `1CV8Clst.lst` (3962 байта, обновляется каждую секунду — это live-state кластера).
+
+**Имена инфобаз → ⚠ ПРОБЕЛ:** только GUID. Нужно либо узнать через рабочий `rac.exe` (rmngr-loop ломает), либо спросить у Олега, либо посмотреть подключения юзеров через 1С.
+
+### Активная нагрузка
+```
+ragent     PID=4048   CPU=    19s   WS=  94 MB   Threads=44     # service master
+rmngr      PID=3876   CPU= 7421s    WS= 378 MB   Threads=104    # cluster manager — high CPU (rmngr-loop)
+rphost     PID=2884   CPU= 1056s    WS=1827 MB   Threads=60     # working process
+
+rphost connections:
+  Established: 26
+  Unique remote: 5  → ~5 активных удалённых клиентов сейчас
+  Listening on: 1540 (rmngr), 1541 (regport), 1560 (rphost extra)
+
+Внешние подключения (не localhost):
+  192.168.1.18:12228 → :1560  (KASSA3 — постоянный коннект к 1С!)
+```
+
+**rmngr CPU=7421s за uptime 3h51min** = `7421/(3*3600+51*60) ≈ 53.4%` среднего одного ядра. Это **активный rmngr-loop**, рецепт лечения через `Restart-Service` уже задокументирован (см. `projects/buzharovo/server1c.md`).
+
+### Лицензии 1С — ⚠ КРИТИЧНО
+```
+HASP/Sentinel hardware-ключ:  Сервис hasplms — Stopped, Disabled
+                              USB HASP/SafeNet/Aladdin устройств нет
+
+Программные .lic файлы:
+  C:\Users\**\*.lic       — не найдено
+  C:\ProgramData\1C\**    — папки license нет
+  C:\Program Files\1cv8\srvinfo\**\*.lic — не найдено
+
+Реестр:
+  HKLM:\SOFTWARE\1C       — нет
+  HKLM:\SOFTWARE\Wow6432Node\1C — нет
+```
+
+**Гипотеза:** лицензия 1С — **программная с активацией через 1С (PIN-код)**, привязанная к HWID (CPU/мать/диск). Это значит:
+- При переносе на новую VM лицензия **отвалится** → нужен повторный ввод PIN или резервный комплект пинкодов
+- **Комплект пинкодов** хранится в личном кабинете 1С-Партнёра / у Олега — **нужно убедиться что есть доступ к пинкодам**
+
+**Альтернативная гипотеза:** лицензия в облачном сервисе ИТС/КОРП (Activator) — тогда привязка через интернет, миграция проще.
+
+⚠ **Action item:** уточнить у Олега, как активирована лицензия 1С и есть ли резервные пинкоды/доступ к ЛК 1С.
+
+---
+
+## 3. MSSQL Server
+
+### Версия
+```
+Microsoft SQL Server 2012 (64-бит, русская версия)
+Build:        11.2.5058.0 (SP2 + KB2958429)
+Instance:     MSSQL11.MSSQLSERVER (default)
+Tools:        SQL Server 2012 Management Studio (x64+x86)
+              SQL Server 2008 Object Management Tools (legacy)
+
+Службы:
+  MSSQLSERVER  — Running, Automatic
+  SQLBrowser   — Stopped, Disabled
+```
+
+⚠ **Mainstream support EOL: 2017-07-11. Extended support EOL: 2022-07-12.** Без security updates 4-й год.
+
+### Listening
+```
+TCP listening:
+  0.0.0.0:1433   ← MSSQL (на всех интерфейсах, включая 100.70.75.103!)
+  0.0.0.0:1540   ← 1С rmngr
+  0.0.0.0:1541   ← 1С regport (где живёт кластер)
+  0.0.0.0:1560   ← 1С rphost
+```
+
+⚠ **MSSQL слушает на NetBird-IP** (100.70.75.103:1433) — то есть из любого NetBird-пира можно попытаться подключиться к SQL. Не критично пока пароль `sa` не известен, но при миграции нужно ограничить.
+
+### БД 1С — ⚠ ПРОБЕЛ
+SQL Auth не получили:
+```
+Win Auth (SERVER1C\dttb):  Login failed (нет SQL-логина)
+sa без пароля:             Login failed
+sa / 1qaz!QAZ:             Login failed
+sa / Sa12345:              Login failed
+```
+
+Файлы `*.mdf` / `*.ldf` через `Get-ChildItem -Recurse C:\,D:\,E:\` не нашлись за 50 секунд — либо ACL блокирует, либо они в нестандартном месте, либо файлы 1С хранятся в файловом, а не SQL формате (маловероятно для версии 8.3 с MSSQL-инстансом).
+
+⚠ **Action item:** получить от Олега `sa`-пароль (или создать SQL-логин для `dttb`). Без этого размер БД и план бэкапа неполный.
+
+### SQL Backup история — ПРОБЕЛ (тот же auth-issue)
+
+---
+
+## 4. Касса и фискализация
+
+**Установленный софт (поиск по реестру uninstall):**
+```
+Из паттерна 'Атол|Штрих|Atol|Shtrih|Evotor|Касс|Drv|Fiscal|ОФД|Меркурий':
+  → НИЧЕГО не установлено
+
+Sentinel LDK License Manager — есть служба (Disabled), но это для других программ
+```
+
+**USB-устройства (Win32_PnPEntity, классы Ports/USB/HIDClass):**
+```
+HID-compliant vendor-defined device  (Asus mobo HID)
+Microsoft ACPI/UEFI/SMBIOS интерфейсы
+Microsoft IPv4/IPv6 Transition Adapter Bus
+Microsoft XPS Document Writer
+Адаптеры 6to4 / ISATAP
+
+→ Ни одного USB-фискальника, COM-порта (кроме материнского COM1), драйвера ККТ.
+```
+
+**Реестр касс/фискальников:**
+```
+HKLM:\SOFTWARE\Atol            — нет
+HKLM:\SOFTWARE\Shtrih-M        — нет
+HKLM:\SOFTWARE\Drv             — нет
+HKLM:\SOFTWARE\1C\Драйвер ККТ  — нет
+HKCR\AddIn.DrvFR               — нет
+```
+
+**ARP-таблица 192.168.1.0/24:**
+```
+192.168.1.1     — gateway (router)
+192.168.1.2     — ?
+192.168.1.3     — ?
+192.168.1.4     — ?
+192.168.1.18    — KASSA3            ★ касса 1
+192.168.1.53    — DESKTOP-JSS8L05   рабочий ПК
+192.168.1.99    — KASSIRULICA2      ★ касса 2
+192.168.1.127   — ?
+192.168.1.139   — Nadezhda          рабочий ПК
+192.168.1.200   — ?
+192.168.1.249   — Server1C (сам)
+```
+
+**Активный TCP в момент разведки:**
+```
+192.168.1.18:12228  ←→  Server1C:1560  (rphost) ESTABLISHED
+```
+
+### Вывод
+
+**Кассы НЕ привязаны к серверу через USB.** Это **отдельные ПК-кассы** в локальной сети:
+- `KASSA3` (192.168.1.18) — активно общается с 1С на rphost-порту 1560 (это значит запущена 1С на самой кассе ИЛИ внешняя компонента 1С DCOM)
+- `KASSIRULICA2` (192.168.1.99) — вероятно вторая касса, не активна в момент разведки
+
+**Это огромный плюс для миграции** — серверу не нужно физически передавать USB-устройства. Касса продолжает работать локально на своём ПК, а к 1С обращается по сети. После миграции достаточно изменить IP/имя сервера 1С в её настройках на новый адрес (через NetBird или публичный IP HomeLab).
+
+⚠ **Не выяснено:** какое ПО на самих ПК-кассах (1С Розница? собственная программа? драйвер какого ККТ?). Это нужно увидеть на месте — уточнить у Олега или удалёнкой через RDP/AnyDesk на 192.168.1.18.
+
+---
+
+## 5. Сеть и провайдер
+
+### LAN
+```
+Description:    Семейство адаптеров Realtek PCIe GBE
+IP:             192.168.1.249/24
+Gateway:        192.168.1.1
+DNS:            192.168.1.1
+MAC:            00:E0:4C:68:9E:34
+IPv6:           fe80::2d5c:849d:c9ad:3409 (link-local)
+```
+
+13 хостов в подсети (см. ARP выше) — это весь офис.
+
+### Канал
+```
+ping 1.1.1.1:        3 ms     ← очень близкий апстрим у провайдера
+ping 8.8.8.8:        15 ms
+ping LXC 137 (NetBird HomeLab): 96–99 ms
+
+Внешний IP:          api.ipify.org timeout — определить не удалось
+                     (либо firewall блокирует ipify, либо канал в момент проверки моргнул)
+```
+
+⚠ **Action item:** уточнить у Олега провайдера (предположительно местный сельский WISP или РТК), скорость download/upload, наличие резервного канала и тип последней мили.
+
+### NetBird
+```
+Daemon version:   0.68.3
+Profile:          default
+FQDN:             server1c.netbird.cloud
+NetBird IP:       100.70.75.103/16
+Management:       Connected
+Signal:           Connected
+Relays:           1/4 Available
+Peers count:      31/58 Connected
+```
+
+NetBird работает стабильно, RTT до HomeLab 96-99ms.
+
+---
+
+## 6. Безопасность сервера
+
+```
+Антивирус:           НЕ установлен (Kaspersky/Defender/ESET/etc — пусто)
+Windows Updates:     не проверяли явно, но Win 2012 R2 EOL уже с 2023
+Public RDP:          ОТКРЫТ на 185.13.47.2:3389
+Активные RDP login (4624, 7 дней):
+  2026-05-07 09:53  SERVER1C\dttb from 176.62.183.186
+  2026-05-07 09:53  SERVER1C\dttb from 176.62.183.186  (sweb hosting? — наш rclone?)
+SQL Server:          0.0.0.0:1433 (доступен по NetBird, не только localhost)
+AnyDesk:             запущен (parallel remote channel, без аудита)
+```
+
+⚠ **Привести в порядок при миграции:**
+- Закрыть RDP в Интернет, оставить только через NetBird
+- Решить: AnyDesk нужен или нет (двойной канал = двойной риск)
+- MSSQL bind на 127.0.0.1 + явный TCP-route через NetBird, не на 0.0.0.0
+- Поставить Defender или другой АВ
+- Включить регулярные Win Updates (если новая VM на 2022/2025 — само собой)
+
+---
+
+## 7. Краши — подтверждённый паттерн
+
+Из v2-разведки за последние 30 дней:
+
+**Kernel-Power 41 (грязные ребуты):**
+- 2026-05-07 09:07 (1 раз)
+- **2026-05-04: 24 раза** между 08:36 и 12:13 (!!) — катастрофа дня
+- 2026-05-03: 2 раза (08:40, 09:27)
+- 2026-05-02: 1 раз (08:41)
+- 2026-05-01: 1 раз (08:34)
+- 2026-04-30: 2 раза (11:56, 11:59)
+
+Все события: `BugcheckCode=0`, `PowerButtonTimestamp=0`, `SleepInProgress=False` → классическое **отключение питания / brownout**, не BSOD, не overheating, не sleep.
+
+**EventID 6008 (unexpected shutdown)** идут парой к каждому Kernel-Power 41 — подтверждает что система не успевала корректно завершиться.
+
+⚠ **Концентрация во времени:** утренние крашы 8:30–12:00 (рабочее время в Бужарово) → совпадает с тем что нагрузка на сельскую сеть растёт утром (включаются плиты/обогреватели/насосы).
+
+Подтверждение что миграция нужна.
+
+---
+
+## Открытые вопросы для Олега (action items)
+
+| # | Вопрос | Зачем |
+|---|---|---|
+| 1 | `sa`-пароль MSSQL? Или создать SQL-login для миграции? | Размер БД, бэкап, миграция данных |
+| 2 | Лицензия 1С: программная или ключ? Где пинкоды для перепривязки? | Активировать на новой VM |
+| 3 | Имена 4 инфобаз (по GUID): что в `00d417ca`, `426d93c8`, `688e50c3`, `9e258b8f`? | Маппинг при миграции |
+| 4 | Что за ПО на KASSA3 / KASSIRULICA2? (драйвер ККТ, 1С Розница, собственный софт?) | Подтверждение совместимости |
+| 5 | Провайдер в Бужарово, скорость канала, резервный канал? | Оценка устойчивости RDP/NetBird |
+| 6 | Окно простоя для миграции (вечер пятницы? выходные?) | Планирование cutover |
+| 7 | Бюджет на ИБП и на сетевое железо в Бужарово? | Альтернативно — починить «на месте», а не мигрировать |
+| 8 | AnyDesk нужен в новой схеме или убираем? | Сужение attack surface |
+
+---
+
+## Дополнительно собранные артефакты (на LXC 137)
+
+- `/tmp/recon_server1c.py` — v1 (оригинальный)
+- `/tmp/recon_v2.py`, `/tmp/recon_v3.py`, `/tmp/recon_v4b.py`, `/tmp/recon_v5.py` — последовательные итерации
+- Все логи v1–v5 на Mac в `/tmp/recon_*_output.txt` (на момент сессии)
+
+---
+
+См. далее: `decisions/2026-05-07-buzharovo-migration-plan.md`.
--- a/decisions/2026-05-08-buzharovo-1c-licensing-options.md
+++ b/decisions/2026-05-08-buzharovo-1c-licensing-options.md
@@ -0,0 +1,60 @@
+---
+date: 2026-05-08
+type: decision
+status: draft
+tags: [buzharovo, 1c, licensing, plan]
+related:
+  - "[[decisions/2026-05-07-buzharovo-recon]]"
+  - "[[decisions/2026-05-07-buzharovo-migration-plan]]"
+---
+
+# Бужарово 1С — варианты легализации
+
+## Контекст
+На Server1C в Бужарово установлена **пиратская 1С** (через patches20 patcher — модифицирован `frame.dll`, подменён `techsys.dll`). Дистрибутив 1С 8.3.27.1606 оригинальный (LLC 1C-Soft signed). Подробности audit'а — `decisions/2026-05-07-buzharovo-recon.md`.
+
+Реальный масштаб использования (уточнено 2026-05-08):
+- **1 рабочая инфобаза** — RitmUl (на платформе **1С:Розница**, ~3.8 GB)
+- **5 одновременных юзеров** (бухгалтерия + кассиры суммарно)
+- Маркировка товаров (Честный знак) — **в скором времени обязательна**
+- 2 ПК-кассы: KASSA3 (192.168.1.18), KASSIRULICA2 (192.168.1.99)
+
+## Варианты (цены 2026)
+
+### A. Файловая 1С (рекомендую)
+| Позиция | Цена |
+|---|---|
+| Клиентские ПРОФ на 5 мест | 27 400 ₽ |
+| 1С:Розница ПРОФ (если ещё не куплена) | 22 000 ₽ |
+| 1С:ИТС ПРОФ — год (обязательно для маркировки) | ~12 000 ₽/год |
+| ЭДО (Контур.ЭДО / СБИС / Такском) | 36-50 000 ₽/год |
+| КЭП для оператора | 2-5 000 ₽/год |
+| **Первый год** | **~80-100 000 ₽** |
+| **Со 2-го года** | **~50-60 000 ₽/год** |
+
+**Плюсы:** не нужна серверная 1С (-127k), не нужен MSSQL. 5 юзеров файловая отлично тянет. Размер 3.8 GB далеко от лимита (~10-15 GB).
+
+### B. Клиент-серверная (старый паттерн)
+126 800 ₽ к варианту A на 1С Server PROF (x86-64). **Не оправдано** на масштабе 5 юзеров и 3.8 GB БД.
+
+### C. 1С Облако (1С:Fresh)
+~2 000 ₽/мес × 5 = 10 000 ₽/мес = 120 000 ₽/год. Без локального сервера, поддержка от 1С. На длинной дистанции дороже A.
+
+### D. Программа «1С:Старт» для МСП
+До 50% скидка от партнёра в регионе. Может сделать вариант A за ~50-60k ₽ в первый год. **Стоит уточнить у местного партнёра** (тот же кто RitmUl делал в Ульяновске?).
+
+## Кассы и маркировка
+- Кассы должны быть **ФФД 1.2** — проверить через X-отчёт на каждой
+- Если ФФД 1.05 — перепрошивка ~3-5k ₽ × устройство, либо замена
+- После обновления через ИТС в 1С:Розница появится поддержка Честного знака
+
+## Что НЕ нужно
+- ❌ Server PROF 1С (126 800 ₽) — лишний для масштаба
+- ❌ MSSQL Standard — файловая ИБ не использует SQL
+- ❌ 1С:Бухгалтерия отдельно — Accounting инфобаза не используется по словам Олега
+
+## Action items
+1. Зайти на **portal.1c.ru** под учёткой организации — посмотреть существующие покупки лицензий
+2. Связаться с **местным 1С-партнёром** (Ульяновск, RitmUl) — узнать про «1С:Старт»
+3. **Проверить ФФД 1.2** на кассах
+4. Уточнить какие категории товаров маркируются и **дедлайн** введения
--- a/decisions/2026-05-12-sergey-instagram-iphone-fakeip.md
+++ b/decisions/2026-05-12-sergey-instagram-iphone-fakeip.md
@@ -0,0 +1,84 @@
+---
+date: 2026-05-12
+type: decision
+status: applied
+tags: [openwrt, podkop, fakeip, amneziawg, iphone, doh, instagram, sergey]
+aliases: [Sergey Instagram, OpenWrt_Sergey Instagram, iPhone DoH FakeIP]
+---
+
+# 2026-05-12 — Sergey: «Инста не работает» — диагноз и фикс
+
+## Кейс
+
+Сергей (объект [[../projects/sergey/README|OpenWrt_Sergey]], Одинцово, Cudy TR3000 v1, 100.70.110.164) пожаловался Олегу — на телефоне **не открывается Instagram** через его роутер. Стек обхода: podkop v0.7.14 + sing-box 1.12.12 + AmneziaWG (kmod) до VLESS-Singapore endpoint `202.71.12.186`, community_lists = `russia_inside`, `telegram`, `meta`.
+
+## Что проверил (на роутере)
+
+| Проверка | Результат |
+|---|---|
+| AmneziaWG `awg0` handshake | свежий (1:37 назад), 11.5 GiB rx |
+| Sing-box процесс | running PID 11491 |
+| nft mangle + tproxy 127.0.0.1:1602 | 108k TCP / 2598 UDP пакетов прошли |
+| FakeIP для `www.instagram.com` через `192.168.1.1` (dnsmasq роутера) | `198.18.0.17` ✅ |
+| FakeIP для `i.instagram.com` | `198.18.0.6` ✅ |
+| FakeIP для `scontent.cdninstagram.com` | `198.18.0.27` ✅ |
+| `curl --interface awg0 https://www.instagram.com/` с роутера | HTTP/2 200 ✅ |
+| WAN exit IP без VPN | `217.73.118.172` (NetByNet, РФ) |
+| WAN exit IP через `awg0` | `202.71.12.186` (Singapore) ✅ |
+| `podkop list_update` | прошёл 09:13 сегодня без ошибок |
+| DNS 8.8.8.8 / 1.1.1.1 не режется провайдером | подтверждено nslookup'ом |
+
+**На стороне роутера всё исправно.** Никаких правок инфраструктуры не нужно.
+
+## Реальная причина
+
+В DHCP-leases роутера активен ровно **один клиент** — `192.168.1.102`, MAC `2e:7f:8c:ce:07:8a` (рандомизированный — бит `02` в первом октете), т.е. iPhone/Android с приватным Wi-Fi-MAC. Все маркеры указывают на **iPhone, который обходит роутерный DNS**:
+
+1. **iCloud Private Relay** — целиком тоннелирует трафик Safari + системные DNS через Apple-серверы (`mask.icloud.com`), минуя локальный dnsmasq. FakeIP не успевает подменить IP.
+2. **Encrypted DNS** в Safari / приложении Instagram / Chrome (DoH к `1.1.1.1:443` или `dns.google:443` по TCP) — те же симптомы.
+3. **Кастомный DNS-профиль** в настройках Wi-Fi сети — устройство просто игнорирует роутерный DNS.
+
+В любом из трёх случаев клиент получает **реальный IP** `157.240.x.x` от внешнего DoH-резолвера, и DPI провайдера (`NetByNet`) блочит TLS handshake по SNI `instagram.com`.
+
+## Фикс — клиент-сайд (приоритет)
+
+Скажи Сергею выключить на iPhone в таком порядке:
+
+1. **Настройки → имя сверху → iCloud → Частный узел → ВЫКЛ**
+2. **Настройки → Wi-Fi → ⓘ его сети → Настройка DNS → Автоматически**
+3. **Safari → Конфиденциальность и безопасность → Скрывать IP-адрес → ВЫКЛ**
+4. Если ходит через **Chrome**: `chrome://settings/security` → DNS через HTTPS → **ВЫКЛ**
+5. Wi-Fi выкл/вкл на телефоне (сбросить кэш DNS клиента)
+
+Этих действий достаточно в **80%+ случаев** для подобных сетапов.
+
+## Фикс — роутер-сайд (если клиентский путь не помог)
+
+В podkop v0.7.14 **нет встроенной опции** "force DNS / block DoH" — делать вручную через nft. Опционально — у домашнего OpenWrt Олега это уже сделано (`projects/dttb/openwrt-router.md`: «DNS Hijack: перехватывает порт 53 → 10.0.0.1»).
+
+Шаги для Сергея (если потребуется):
+
+```sh
+# 1) Принудительный редирект исходящего DNS:53 на роутер
+nft 'add rule inet fw4 dstnat iifname "br-lan" meta l4proto { tcp, udp } th dport 53 dnat ip to 192.168.1.1:53'
+
+# 2) Drop DoH/DoT к публичным резолверам (TCP/443 + TCP/853)
+nft 'add set inet fw4 doh_servers { type ipv4_addr; flags interval; elements = { 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 149.112.112.112 } }'
+nft 'add rule inet fw4 forward iifname "br-lan" ip daddr @doh_servers tcp dport { 443, 853 } reject with tcp reset'
+
+# 3) Закрепить в /etc/firewall.user или uci
+```
+
+Также можно поднять AdGuard Home (как у Олега в HomeLab) — он по умолчанию форсит свой `:53` и фильтрует DoH-домены. Сейчас у Сергея AGH **не установлен** — стек чисто `dnsmasq → 127.0.0.42 (sing-box) → upstream`.
+
+## Что НЕ является проблемой
+
+- **Шум в логе sing-box** — `ERROR ... {GUID}-netseer-ipaddr-assoc.xy.fbcdn.net: empty result`. Это Meta NetSeer probes (anti-CDN-detection), штатное поведение Meta. Игнорировать.
+- **`check_fakeip` показывает 217.73.118.172** — это российский WAN IP роутера. Тестовый домен (`ip.podkop.fyi`) не в community-listах, идёт direct через WAN — это норма для проверки.
+
+## Связанное
+
+- [[../projects/sergey/README]] — полный recon роутера
+- [[../snippets/podkop-fakeip-diagnostics]] — типовой playbook для диагностики любого подкоп-роутера
+- [[../projects/dttb/openwrt-router]] — домашний OpenWrt Олега, где DNS-hijack уже включён
+- [[2026-04-30-openwrt-homelab-agh-podkop-chain]] — стек AGH+podkop у Олега дома (как референс)
--- a/decisions/2026-05-20-amneziavpn-macos-v1-v2-incompat.md
+++ b/decisions/2026-05-20-amneziavpn-macos-v1-v2-incompat.md
@@ -0,0 +1,84 @@
+---
+date: 2026-05-20
+type: decision
+tags: [vpn, amnezia, amneziawg, macos, finland, server, incompatibility]
+status: open
+severity: medium
+---
+
+# AmneziaVPN macOS-клиент несовместим с v1 AmneziaWG-сервером
+
+## TL;DR
+
+macOS-клиент AmneziaVPN (текущей версии на 2026-05) умеет только новый **AmneziaWG v2** handshake-формат. На **v1**-серверах (старые `amnezia-awg` контейнеры) — handshake silently дропается, клиент видит `ErrorCode 305 — Тайм-аут подключения к серверу`. iOS-клиент, Windows-клиент и Linux-kernel-module `wireguard-go-amneziawg` шлют в v1-совместимом формате — продолжают работать.
+
+## Симптомы
+
+Mac-клиент при попытке Connect:
+- На v1-сервере: шлёт **только junk-преамбулу (96-байтовые UDP-пакеты)**, реальный handshake_init (148+ байт) не уходит. Таймаут 305.
+- На v2-сервере: handshake проходит, туннель поднимается, всё работает.
+
+В tcpdump на v1-сервере видно множество одинаковых 96-байтных UDP-пакетов от Mac-клиента и **ноль ответных**. На v2-сервере — пакеты разных размеров (handshake → data 1452 байт).
+
+## Подтверждённые случаи (2026-05-20)
+
+| Клиент | Сервер | Контейнер | Версия | Результат |
+|---|---|---|---|---|
+| Mac Олега | `78.17.4.225` (НИИКН) | `amnezia-awg2` | v2 | ✓ работает |
+| Mac Олега | `202.71.12.186` (finland5870) | `amnezia-awg` (7 мес) | v1 | ✗ ErrorCode 305 |
+| Mac Александра (Бенелюкс) | `202.71.12.186` | v1 | v1 | ✗ ErrorCode 305 |
+| iPhone Александра | `202.71.12.186` | v1 | v1 | ✓ работает |
+| Win 2012R2 1С Бужарово | `78.17.4.225` | v2 | v2 | ✓ работает |
+| Cudy TR3000 (kernel-mod) | `202.71.12.186` | v1 | v1 | ✓ работает |
+
+## Как опознать v1 vs v2 на сервере
+
+```bash
+ssh root@<server> 'docker ps | grep amnezia-awg'
+```
+- `amnezia-awg` — v1
+- `amnezia-awg2` — v2
+
+В `wg0.conf` v2-конфиг включает поля `I1..I5` (после `H1..H4`), в v1 — нет:
+```bash
+docker exec <amnezia-awg|amnezia-awg2> awk '/^\[Interface\]/,/^\[Peer\]/' /opt/amnezia/awg/wg0.conf
+```
+
+## Конфиги клиентов
+
+В `vpn://`-ключе AmneziaPanel оба формата выглядят почти одинаково (поля `I1..I5` присутствуют пустыми и в v1-конфигах). Реальная привязка к версии — на стороне сервера + версия клиентского `wireguard-go-amneziawg`.
+
+## Решение (выбрано Олегом)
+
+**Не трогаем v1-сервер finland5870** — там 84 активных peer (iOS/Windows/Linux/kernel-WG), которые работают. Риск перевыпуска всех конфигов перевешивает пользу.
+
+Mac-юзерам, кто жалуется на 305, выдаём:
+- Конфиг от v2-сервера `78.17.4.225` (НИИКН), либо
+- Конфиг от **любого** v2-сервера в инфре Олега.
+
+Александру (Бенелюкс) — выпущен новый конфиг от НИИКН-сервера.
+
+## Что не сделано (отложено)
+
+- **Параллельный v2-контейнер на finland5870** на другом UDP-порту (например `37210`) — старые v1-клиенты продолжают на `37209`, новые/Mac — на v2 `37210`. Без вмешательства в текущий контейнер, риск минимальный. Откладывается пока не накопится критическая масса Mac-юзеров.
+- **Полная миграция finland5870 v1 → v2** — массовый перевыпуск 84 конфигов. Только в плановое окно даунтайма.
+
+## Диагностика для будущих случаев
+
+Чтобы не разбирать с нуля, чек-лист:
+
+1. **Mac жалуется на ErrorCode 305 или тайм-аут к AmneziaVPN.**
+2. Проверь — **iOS-клиент / Windows-клиент того же пользователя на том же сервере работают?** Если да — гипотеза macOS-v1-баг сильно правдоподобна.
+3. **Какая версия контейнера на сервере** — `docker ps | grep amnezia` → если `amnezia-awg` (без `2`) — это v1. Если `amnezia-awg2` — v2.
+4. Если v1 — выдай Mac-юзеру конфиг от v2-сервера. Не пытайся "починить" v1-контейнер.
+
+## Снэпшот серверов на момент решения (2026-05-20)
+
+- **finland5870.com** `202.71.12.186`: `amnezia-awg` (v1, создан ~2025-10), 84 peer, port 37209/udp. Используется как основной endpoint для роутерных podkop-туннелей: Бенелюкс, Сергей, Знаменское, НИИКН-роутер, Lipki, Михуринец и др.
+- **finlandit5870.com** `78.17.4.225`: `amnezia-awg2` (v2, создан 2026-05-18), `amnezia-panel-web` (управляющая PHP-панель), полный VPN-стек (xray, shadowbox, socks5, mtproto, WA-proxy). Олег управляет конфигами отсюда через AmneziaApp.
+
+## Связанные
+
+- [[../projects/dttb/finland-hostkey-vps]] — карточка finland5870
+- [[../projects/dttb/vpn-clients]] — клиентский реестр
+- [[2026-05-20-benelux-compromise]] — параллельная история инцидента с роутером Бенелюкса
--- a/decisions/2026-05-20-benelux-compromise.md
+++ b/decisions/2026-05-20-benelux-compromise.md
@@ -0,0 +1,159 @@
+---
+date: 2026-05-20
+type: decision
+tags: [security, incident, benelux, openwrt, ssh, firewall]
+status: closed
+severity: high
+---
+
+# Бенелюкс OpenWrt — взлом через SSH brute-force на WAN
+
+## Что произошло
+
+В ходе плановой проверки в **15:38 MSK** на `OpenWrt Benelux` (Cudy TR3000, NetBird `100.70.207.97`, WAN `45.143.21.60`) обнаружена активная компрометация:
+
+- **LA = 4.0** на 4-ядерном MT7981, CPU 82% idle (нагрузка не на CPU, а на сеть+OOM-loop)
+- **19 параллельных SSH-сессий** от чужих IP: `185.244.183.107` (RU), `51.77.53.0/24` и `51.38.148.97` (OVH FR), `108.181.123.93`, `51.75.55.2`
+- Каждая сессия рассылала **спам через SMTP 25/465/587** на сотни IP (десятки соединений на момент анализа)
+- Также параллельно — попытки на **Docker API 2375** (поиск открытых демонов для распространения)
+- Cron `@reboot /tmp/.2424` (тело уже самоудалилось)
+- `/root/.bash_history` и `.ash_history` отсутствуют — следы зачищены
+
+## Вектор атаки
+
+**SSH-сервер слушал на WAN (eth0)**, пароль `root:1qaz!QAZ` — общий по всей инфраструктуре. WAN IP `45.143.21.60` публичный → brute force с открытого интернета. После взлома атакующие держали постоянные авторизованные сессии и из своих shell-ов запускали спам напрямую.
+
+> Ранняя гипотеза о malware-процессах под именами `systemd`/`sshd` оказалась ложной — это были обычные процессы атакующих в их собственных dropbear-shell. На OpenWrt нет ни systemd, ни sshd; имена `dropbear` в `netstat` — это родительские SSH-сессии злоумышленников.
+
+## Что сделано (без ребута)
+
+| Шаг | Команда / артефакт |
+|---|---|
+| 1. Заблокировать спам | `nft insert rule inet fw4 output oifname eth0 tcp dport {25,465,587,2375} drop` (+ `forward`) |
+| 2. Заблокировать вход SSH с WAN | `nft insert rule inet fw4 input iifname eth0 tcp dport 22 drop` |
+| 3. Убить 19 атакующих сессий | `kill -9` всех `dropbear` PID с не-NetBird foreign IP |
+| 4. Положить ключ | `/etc/dropbear/authorized_keys` = mac-ed25519 (см. `~/.ssh/id_ed25519.pub`) |
+| 5. Поменять пароль root | новый — в auto-memory (НЕ в vault) |
+| 6. Удалить вредоносную крон-запись | `@reboot /tmp/.2424` вычищено, осталось только `13 9 * * * /usr/bin/podkop list_update` |
+| 7. Persist firewall | `/etc/nftables.d/99-incident-20260520.nft` + `fw4 reload` |
+
+После `fw4 reload` роутер автоматически ребутнулся (вероятно watchdog отреагировал на reload в момент OOM-loop). После ребута: правила подхватились из `/etc/nftables.d/`, ключ сработал, новый пароль активен, cron чистый.
+
+## Результат
+
+| Метрика | До | После |
+|---|---|---|
+| Load average | 4.04 | 0.15 |
+| Free RAM | ~250 MB (с OOM-loop) | 307 MB available |
+| Dropbear процессов | 21 | 2 (listener + моя сессия) |
+| Outbound SMTP-соединений | 30+ | 0 |
+| Counter `incident_block_in 22` | — | растёт (атакующие тыкаются) |
+
+## Постоянные правила (`/etc/nftables.d/99-incident-20260520.nft`)
+
+```nft
+chain incident_block_in {
+  type filter hook input priority -100; policy accept;
+  iifname "eth0" tcp dport 22 counter drop comment "incident-20260520-no-ssh-from-wan"
+}
+chain incident_block_out {
+  type filter hook output priority -100; policy accept;
+  oifname "eth0" tcp dport { 25, 465, 587, 2375 } counter drop comment "incident-20260520-block-spam"
+  oifname "eth0" tcp dport 22 counter drop comment "incident-20260520-block-ssh-brute"
+}
+chain incident_block_fwd {
+  type filter hook forward priority -100; policy accept;
+  oifname "eth0" tcp dport { 25, 465, 587, 2375 } counter drop comment "incident-20260520-block-spam"
+  oifname "eth0" tcp dport 22 counter drop comment "incident-20260520-block-ssh-brute"
+}
+```
+
+SSH доступ остался только через:
+- LAN (`192.168.1.0/24`, `br-lan`)
+- NetBird (`100.70.207.97`, `wt0`)
+
+## Расширение масштаба: Unifi + NetBird-mesh
+
+Бенелюкс — **не изолированный объект**. Cudy за время взлома имел два открытых вектора в чужие сети:
+
+1. **LAN Бенелюкса (192.168.1.0/24)** — здесь живёт **Unifi-сегмент**: 3 AP/Switch (`70:a7:41:79:ef:29`, `70:a7:41:9a:9e:92`, `70:a7:41:c1:33:0a`). Атакующие, сидя на Cudy под root, имели L2 ко всей подсети — могли сниффить broadcasts, ARP, DHCP. К какому контроллеру эти устройства adopted — на момент расследования не выяснено: inform-трафика ни к LXC 116 НИИКН (`100.70.138.234`), ни к UDM-Pro Знаменского нет. Одно из устройств (`192.168.1.199`, hostname `Benelyuks`) стучится в `192.168.28.34:8381` — это IP не из NetBird, пакеты уходят в default-шлюз провайдера без ответа. Похоже на orphaned-сегмент, см. [[projects/benilux/README#unifi-сегмент-за-cudy]].
+
+2. **NetBird-mesh через wt0** — Cudy получает по NetBird маршруты в:
+   - `10.0.0.0/24` (через openclaw — это вся домашняя dttb-инфра)
+   - `10.253.1.0/24` + `2.63.246.0/24` + `87.250.251.0/24` + `95.167.245.0/24` (через pve-LionART — ММФБ)
+   - `192.168.1.0/24` (через pve-niikn — НИИКН; конфликт с локальной подсетью)
+   - `192.168.2.0/24` (Переделки), `192.168.8.0/24`, `192.168.88.0/24`
+
+   Атакующие, имея root на Cudy с активным NetBird agent, теоретически могли достучаться до любого хоста в этих сетях. На практике для этого надо знать топологию (которой у них не было) и проводить активную разведку (не видно в коротких SMTP-сессиях). Но риск ненулевой — особенно для **LXC 116 unifi-controller** (`100.70.138.234:8443`) и **Proxmox НИИКН** (`pve-niikn 100.70.120.229`), которые видны напрямую.
+
+**Что проверить отдельно** (не в этом фиксе):
+- Логи Docker LXC 116 unifi-controller (на pve-niikn, `/opt/unifi/config/logs/`) на попытки входа / сессии с `100.70.207.97` за 2026-05-20 13:00–15:45 MSK
+- NetBird access policy для группы `OpenWRT VPN` — какие пиры/подсети разрешены этой группе
+
+## Что НЕ сделано (на твоё решение)
+
+1. **Полный wipe / sysupgrade -n.** Малварь была memory-resident (`/tmp/.2424` уже не существовало), бэкдоров на диске не найдено (find -mtime -7 чист в `/etc /lib /sbin /usr/sbin /opt`). Но 100% гарантии чистоты после взлома `root` без переустановки нет. Рекомендую перезалить роутер в течение недели в окно даунтайма.
+2. **Жёсткое ограничение dropbear на интерфейсы.** Сейчас он слушает на всех (`0.0.0.0:22`), правило отбрасывает только `iifname eth0`. Можно дополнительно через `uci set dropbear.@dropbear[0].Interface=lan` ограничить bind. Не делал — риск разрыва.
+3. **Audit прочих хостов с тем же паролем.** `1qaz!QAZ` фигурирует в инфраструктуре много где (Proxmox, Gitea-WebUI, NPM, Nextcloud, openclaw-LXC, server1c, MikroTik и др.). Также UDM-Pro использует похожий `1qaz!QAZ!QAZ`. **Если хоть один публично-доступный хост с этим паролем существует — он тоже скомпрометирован.** Нужен аудит.
+4. **Уведомление abuse.** `45.143.21.60` рассылал спам несколько часов (минимум) — стоит ожидать blocklist-листинги (Spamhaus CSS/XBL, abuseipdb).
+5. **Чистка `/var/log/dropbear`** (если есть) — для удаления fingerprint атакующих, но это удалит и улики.
+
+## SMTP forward разблокирован (2026-05-20 ~17:00 MSK)
+
+Александр пожаловался что почта перестала работать — это побочный эффект моего forward-drop для 25/465/587. Снял **forward** chain для этих портов (`/etc/nftables.d/99-incident-20260520.nft`), оставил только output-drop (с самого роутера — там SMTP-клиента быть не должно) + forward-drop для 22 (защита от LAN→WAN SSH-брута, если в сети окажется скомпрометированное устройство). Apple Mail/Outlook у LAN-клиентов снова работает.
+
+## Постоянный фикс (2026-05-20 16:30 MSK)
+
+После исходной изоляции выявлено в UCI: `firewall.@rule[9].name='Allow-SSH-WAN'` — **корневая причина инцидента**, явное разрешение SSH с интернета. Также включён парольный auth: `dropbear.main.PasswordAuth=on`, `RootPasswordAuth=on`. Применено:
+
+```
+# backup
+cp /etc/config/firewall      /etc/config/firewall.bak.incident-20260520
+cp /etc/config/dropbear      /etc/config/dropbear.bak.incident-20260520
+cp /etc/dropbear/authorized_keys /etc/dropbear/authorized_keys.bak.incident-20260520
+
+# второй ключ в authorized_keys (recovery, если Mac отвалится)
+cat >> /etc/dropbear/authorized_keys <<'KEY'
+ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKlYObrWNTPQbR+WXMURscQ85Xc5HTLZa+wC8sf8WU72 claude-code@code-server
+KEY
+
+# удалить дырявые UCI-правила
+uci delete firewall.@rule[<idx>]  # Allow-SSH-WAN
+uci delete firewall.@rule[<idx>]  # Allow-IPSec-ESP
+uci delete firewall.@rule[<idx>]  # Allow-ISAKMP
+
+# key-only
+uci set dropbear.main.PasswordAuth='off'
+uci set dropbear.main.RootPasswordAuth='off'
+
+uci commit firewall && uci commit dropbear
+fw4 reload && /etc/init.d/dropbear restart
+```
+
+**Verify:** вход по ключу — ОК; вход по паролю — `Permission denied (publickey)` (dropbear даже password-prompt не показывает).
+
+## NetBird route — NIIKN остаётся в mesh (2026-05-20 16:50 MSK)
+
+Изначально планировалось убрать route `192.168.1.0/24` от pve-niikn для устранения конфликта. По решению Олега — NIIKN-route в mesh нужен, оставлен (новый id после re-create: `d86ug0rl0ubs73djq120`, peer `cqrj61bl0ubs73dkhq70` pve-niikn).
+
+Сейчас тот же `192.168.1.0/24` анонсируют два пира:
+- `d86ug0rl0ubs73djq120` — peer **pve-niikn**, network_id="NIIKN"
+- `d7kkgtbl0ubs73du6560` — peer **nbgw-glavtorg**, network_id="Glavtorg-LAN"
+
+Какой именно будет выбран на каждом client-peer — определяется NetBird's внутренней логикой metric/peer-status. Для надёжной работы по конкретному объекту с конфликтующим /24 — ходи по NetBird-IP пира, не по LAN-IP (для Бенелюкса: `100.70.207.97`, для LXC 116 unifi-controller: `100.70.138.234`).
+
+## Улики
+
+Локально на mac: `/tmp/benelux-evidence/`
+- `recon.txt` — ps/netstat/dmesg/cron на момент обнаружения
+- `lockdown.txt` — лог изоляции (kill 19 сессий)
+- `harden.txt` — установка ключа, чистка cron
+- `new_password.txt` (chmod 600) — новый root пароль
+- `recon.sh`, `lockdown.sh`, `harden.sh`, `finalize.sh` — исполненные скрипты
+
+## Open questions для Олега
+
+- [ ] Audit паролей на других хостах (особенно публично-доступных) — выше
+- [ ] Когда планируем wipe+sysupgrade Бенелюкса?
+- [ ] Сообщить ли Александру (клиент в КП Бенелюкс) — на объекте только podkop для обхода блокировок, бизнес-сервисов нет, утечки клиентских данных не было; вопрос косметический
+- [ ] Кто сделал WAN-SSH публичным изначально? (по умолчанию OpenWrt блокирует ssh на wan)
--- a/decisions/2026-05-23-glavtorg-autologon-off.md
+++ b/decisions/2026-05-23-glavtorg-autologon-off.md
@@ -0,0 +1,51 @@
+---
+date: 2026-05-23
+project: glavtorg
+tags: [glavtorg, security, windows, vmware, autologon]
+---
+
+# Glavtorg: отключение AutoLogon без потери автозапуска VM
+
+## Контекст
+Клиент Ярослав (Главторг) пожаловался: после ребута сервера (Win 2012 R2, 100.70.195.47) пользователь сам автоматически логинится в console-сессию, экран не блокируется. Любой у монитора/iLO/KVM получает залогиненный рабочий стол админа сервера 1С.
+
+AutoLogon был включён 2026-04-25 ради автостарта двух VMware Workstation VM (`nbgw` 192.168.1.50 — NetBird gateway, `Ubuntu` 192.168.1.51 — Amnezia VPN), которые поднимаются скриптом `C:\Scripts\start-vms.bat` через Task Scheduler `VMware AutoStart`.
+
+## Проверка: нужен ли AutoLogon для VM?
+На рабочем сервере:
+- `vmrun list` — 2 VM running
+- `Get-Process vmware-vmx` показал **SessionId=0** (System session, не интерактивная сессия Ярослава)
+- `schtasks /Query /TN 'VMware AutoStart' /V`: `LogonType=Password`, `Last Result=0`, отработало после ребута 22.05.2026 13:17
+
+Вывод: Task Scheduler стартует `vmrun ... nogui` со stored password, VM процессы живут в Session 0 как обычные сервисные процессы — интерактивная сессия для них **не требуется**.
+
+## Решение
+Снять AutoLogon полностью, оставив Task Scheduler как единственный механизм автозапуска VM.
+
+### Что изменено в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
+| Параметр | Было | Стало |
+|---|---|---|
+| AutoAdminLogon | 1 | 0 |
+| ForceAutoLogon | 1 | 0 |
+| AutoLogonCount | 999988 | (удалён) |
+| DefaultPassword | (отсутствует, был только LSA secret) | — |
+| DefaultUserName | Ярослав | Ярослав (оставлен — preselect на logon screen) |
+| DefaultDomainName | glavtorg | glavtorg (оставлен) |
+
+LSA secret `HKLM\SECURITY\Policy\Secrets\DefaultPassword` (создан Sysinternals Autologon) физически остаётся, но без флага `AutoAdminLogon=1` Winlogon его не читает. Полностью стереть можно через `Autologon64.exe /accepteula /delete` (бинарник не установлен — при необходимости скачать).
+
+## Бэкап и rollback
+- Бэкап Winlogon ветки: `C:\Scripts\winlogon-backup-20260523-125613.reg`
+- Rollback-скрипт: `C:\Scripts\rollback-autologon.cmd` — импортирует бэкап + инструкция как вернуть пароль через Autologon64.exe если потребуется
+- Для срочного возврата AutoLogon Ярославу достаточно запустить rollback-скрипт от админа и (если LSA secret был стёрт когда-нибудь позже) скачать Autologon с https://learn.microsoft.com/sysinternals/downloads/autologon
+
+## Проверка после следующего ребута
+1. После ребута сервер должен встать на logon screen (без автоматического входа)
+2. `vmrun list` от Ярослава после RDP-логина должен показать обе VM running
+3. `schtasks /Query /TN 'VMware AutoStart' /V /FO LIST` — `Last Result: 0`
+4. NetBird-маршрутизация в 192.168.1.0/24 работает (доступ к Юрию Витальевичу/другим клиентам через nbgw)
+5. Если что-то из этого не сработало — запустить `C:\Scripts\rollback-autologon.cmd`, ребутнуться, разбираться отдельно
+
+## Связанные
+- [[projects/glavtorg/README]]
+- [[feedback_vmware_workstation_session]] — общая память про VMware Workstation и сессии (logoff роняет VM в interactive session; в нашем случае VM в Session 0, так что это про другой сценарий)
--- a/decisions/2026-05-26-omni-domain-and-update.md
+++ b/decisions/2026-05-26-omni-domain-and-update.md
@@ -0,0 +1,45 @@
+---
+date: 2026-05-26
+type: decision
+tags: [omniroute, npm, kiro, lxc-132]
+---
+
+# OmniRoute: домен omni.dttb.ru и апдейт 3.8.3
+
+## Что сделано
+
+### Обновление OmniRoute 3.8.2 → 3.8.3
+- Бэкап `.env`: `/root/OmniRoute/.env.bak-20260526-065731`
+- `cd /root/.npm/_npx/cb5891f90ae65d14 && npm install omniroute@latest`
+- `systemctl restart omniroute` → active, `/v1/models` → 200
+- Node 22.22.2, требуется ≥22.22.3 — warning, но работает
+
+### Proxy Host #29 omni.dttb.ru
+- В NPM: `omni.dttb.ru → http://10.0.0.179:20128`, WSS включён, SSL ❌
+- HTTP доступен из локалки/NetBird (резолвится в 10.0.0.195 через ns spaceweb)
+
+### Let's Encrypt — выпущен после добавления DNS
+Первая попытка дала NXDOMAIN — публично у Spaceweb для `omni.dttb.ru` записи не было.
+Я добавил через Spaceweb API: `POST https://api.sweb.ru/domains/dns` с `editMain action=add name=omni type=A value=176.62.183.186` (один вызов, чтобы не зацепить [[feedback_spaceweb_dns]]).
+Подождал **10 минут** negative-cache LE Boulder (TTL=600), повторный запрос — успех.
+
+**Cert ID 114**, expires 2026-08-24, привязан к Proxy Host #29 через `PUT /api/nginx/proxy-hosts/29 {certificate_id:114, ssl_forced:true, http2_support:true}`.
+
+Проверка: `https://omni.dttb.ru/` → 200, title "OmniRoute — AI Gateway", CN=omni.dttb.ru issued by Let's Encrypt E8.
+
+## Кир (kr/*) — бесплатные модели на 2026-05-26
+Всего 11, появились новинки:
+- `kr/claude-opus-4.7` ⭐ — теперь есть Opus 4.7 у Кира тоже
+- `kr/claude-sonnet-4.6` ⭐
+- `kr/claude-opus-4.6`, `kr/claude-sonnet-4.5`, `kr/claude-haiku-4.5`
+- `kr/deepseek-3.2`, `kr/minimax-m2.5`, `kr/minimax-m2.1`
+- `kr/glm-5`, `kr/qwen3-coder-next`
+- `kr/auto-kiro`
+
+Алиас `kiro/*` идентичен. Это резерв для Антошки если `cc/claude-opus-4-7` (Max OAuth) свалится в billing-ошибку.
+
+## Связанные
+
+- [[omniroute]] — клод-память про OmniRoute
+- [[2026-05-06-openclaw-opus-4-7-via-max-cliproxy]] — текущий primary Антошки на cc/, fallback chain
+- [[feedback_spaceweb_dns_desync]] — Spaceweb DNS показывает 10.0.0.195 для существующих *.dttb.ru записей; для несуществующих — NXDOMAIN
--- a/decisions/2026-05-28-mmfb-effector-saver-locked-admin.md
+++ b/decisions/2026-05-28-mmfb-effector-saver-locked-admin.md
@@ -0,0 +1,72 @@
+---
+title: MMFB — Effector Saver Agent не стартует, .\Администратор залочен
+date: 2026-05-28
+tags: [mmfb, lionart, effector-saver, windows-service, decision]
+status: resolved
+---
+
+# MMFB / LionART 1C — Effector Saver Agent не стартует, `.\Администратор` залочен
+
+## Контекст
+[[../projects/mmfb/lionart-1c|VM 100 pve LionART]] (`WIN-70M2VEJIKEF`, 10.253.1.240, Win Server 2022). Служба `efsaveragent` (Effector Saver Agent, `C:\Program Files\Effector Saver\fagent.exe`) в Stopped/Auto, не стартует.
+
+## Диагноз
+Цепочка Event Log → SCM:
+
+```
+7038  Службе "efsaveragent" не удалось войти в систему с именем ".\Администратор"
+       и текущим паролем, поскольку произошла ошибка
+7000  Сбой при запуске службы "Effector Saver Agent"
+```
+
+Это повторялось каждую минуту в течение последних минут. SCM хранит пароль учётки отдельно от LSA — пароль `.\Администратор` менялся (или Effector ставили со старой парой), а SCM-секрет не обновили.
+
+Дополнительно: попытки SCM × мои WinRM-пробы залочили учётку.
+
+```powershell
+# Через LogonUser API:
+LogonUser SERVICE     : False  (err=1909)   # ERROR_ACCOUNT_LOCKED_OUT
+LogonUser INTERACTIVE : False  (err=1909)
+LogonUser NETWORK     : False  (err=1909)
+
+# Через ADSI:
+$u = [ADSI]"WinNT://./Администратор,user"
+$u.IsAccountLocked  → True
+$u.BadPasswordAttempts → 10
+```
+
+## Решение (порядок важен)
+
+```powershell
+# 1. Заглушить SCM, чтобы он перестал каждую минуту ломиться с неверным паролем
+sc.exe config efsaveragent start= disabled
+sc.exe stop efsaveragent
+
+# 2. Разблокировать учётку (Set-LocalUser не имеет lockout-поля → через ADSI)
+$u = [ADSI]"WinNT://./Администратор,user"
+$u.IsAccountLocked = 0
+$u.SetInfo()
+
+# 3. Проверить пароль через LogonUser(LOGON32_LOGON_SERVICE=5) — тот же путь, что использует SCM.
+#    Если False — не пиши пароль в SCM, иначе сразу опять залочишь.
+#    Если True — пароль валидный, прошиваем:
+
+sc.exe config efsaveragent obj= ".\Администратор" password= "<актуальный_пароль>"
+sc.exe config efsaveragent start= auto
+sc.exe start efsaveragent
+```
+
+После старта:
+- `efsaveragent` в Running, PID 9104, fagent.exe, 28 MB
+- Новых 7038/7000 — нет
+- Аккаунт остаётся разлоченным
+
+## Уроки
+- При **7038** не паникуй с lockout: сначала **остановить службу** (или переключить на disabled), потом разблокировать.
+- При WinRM-failed-login проверяй lockout первым делом (через `[ADSI]"WinNT://./<user>,user"` поле `IsAccountLocked`) — не подбирай пароль вслепую, иначе добиваешь счётчик.
+- `Set-LocalUser` не умеет снимать lockout — только ADSI или `net user`-с-новым-паролем.
+- Не доверяй `BadPasswordAttempts: 0` после разблока — этот счётчик не сразу обнуляется; смотри сам `IsAccountLocked`.
+
+## Открытые вопросы
+- Почему пароль `Администратор` в SCM разошёлся с фактом — не выяснено. `PasswordLastSet = 06.05.2024`, установка Effector Saver — 16.02.2025. Возможно, инсталлер прописал тестовый пароль, или пароль менялся без обновления службы.
+- Стоит ли увести `efsaveragent` на отдельную сервисную учётку без password-expiry (например, `.\Effector Saver`, которая уже имеет `SeServiceLogonRight`) — выяснить, что Effector Saver кладёт по сети: если UNC с админ-кредами, миграция нетривиальна.