---
date: 2026-06-23
type: project
tags: [buzharovo, openwrt, podkop, amneziawg, fakeip, doh]
aliases: [Severni Les router, Бужарово podkop роутер]
---

# Бужарово — podkop-роутер «Severny-Les» (Cudy TR3000)

Отдельный роутер обхода РКН для стройрынка Бужарово (Северный лес). **Не путать** со шлюзом 1С-сервера [[buzharovo-router|Cudy WR6500H 185.13.47.2]] — это новый Cudy TR3000 под podkop.

- **hostname:** `Severny-Les` (было `Severni_Les` — поправлено на корректную латиницу 2026-06-23).
- **NetBird:** `100.70.113.251` / `severny-les-113-251.netbird.cloud` (группа Claude-Diag, ключ `64DF527E-…`, `--disable-dns`). Прямой доступ: **`ssh root@100.70.113.251`** (root/`1qaz!QAZ`).

## Железо / ОС
- **Cudy TR3000 v1**, OpenWrt 24.10.3 r28872, aarch64; extroot на USB (Verbatim 31 ГБ, ext4 label `extroot` → `/overlay`, ~27 ГБ свободно).
- podkop **v0.7.19**, sing-box **1.12.4** (бинарь скопирован с домашнего 10.0.0.1; opkg-метадата числит 1.12.22 — бэкап `/usr/bin/sing-box.bak-1.12.22`; версия на обход НЕ влияла, см. ниже).
- **AmneziaWG-пакеты** (`kmod-amneziawg 6.6.104.1.0.20250924`, `amneziawg-tools 1.0.20250903`, `luci-proto-amneziawg 2.0.4`) перенесены **с домашнего 10.0.0.1** (байт-в-байт та же платформа) — `opkg files`→tar→распаковка+`depmod`; kmod-зависимости (`kmod-udptunnel4/6`, crypto) из штатного фида. AWG 1.5 поддержан (S3/S4 + H-диапазоны). См. [[reference_infra]] / память «Переиспользуй инфру Олега».
  - ⚠️ **Грабля LuCI «Unsupported protocol type» у awg0** (туннель при этом работает — это только вебка): при ручном копировании `luci-proto-amneziawg` его **ресурсная зависимость `/www/luci-static/resources/uqr.js`** (QR-lib) НЕ попадает в `opkg files` пакета → `amneziawg.js` делает `require uqr` → класс протокола не регистрируется. Фикс: скопировать `uqr.js` с домашнего + `rm -f /tmp/luci-*; /etc/init.d/rpcd restart` + hard-refresh браузера. (Бэкенд тоже нужен: `ubus list | grep amnezia` → `luci.amneziawg`.) `dom.js` отдельным файлом отсутствует — это норма (в базовом бандле).

## Сеть и доступ (стадия препрод, 2026-06-23)
Сейчас стоит в домашней лабе: воткнут во **второй LAN-порт Proxmox**.
- LAN роутера: **192.168.1.1/24** (br-lan).
- WAN роутера: `eth0` DHCP из домашней сети — IP **10.0.0.215**, шлюз **10.0.0.1** (домашний роутер). Весь интернет идёт через дом.
- **Доступ (основной):** по NetBird — `ssh root@100.70.113.251`.
- **Доступ (фолбэк, по LAN):** jump через Proxmox — `ssh root@10.0.0.250` → `ssh -o UserKnownHostsFile=/dev/null root@192.168.1.1` (root / `1qaz!QAZ`). Host-key 192.168.1.1 на Proxmox конфликтует → нужен `UserKnownHostsFile=/dev/null`.
- **Firewall для NetBird:** добавлена зона `nbird` (device `wt0`, `input=ACCEPT` для управления, `forward=REJECT` — NetBird-пиры НЕ ходят в LAN стройрынка, masq off). Без неё SSH на NetBird-IP = «Connection refused» (wt0 был вне зон). ⚠️ Доступ к роутеру по NetBird гейтит ACL группы Claude-Diag — на проде сузить, если в группе лишние пиры.
- На стройрынке будет свой провайдер — сохранить LAN `192.168.1.0/24`.

## Туннель
- AmneziaWG **awg0** → Finland HOSTKEY `151.241.234.241:41624` (тот же хаб, что у дома и НИИКН; AWG 1.5: S3/S4 + H-диапазоны), клиент `10.8.1.3/32`.
- На Amnezia-панели (LXC 143) пир называется **«Severni Les»**. Список клиентов хаба: `Admin [macOS]`=10.8.1.1, `podkop homelab`=10.8.1.2 (домашний), `Severni Les`=10.8.1.3.
- `rp_filter` глобально `0` → транзит через туннель работает без правок (в отличие от домашнего, где нужен per-iface `=2` — см. [[../dttb/openwrt-router]]).

## podkop-конфиг (рабочий)
| Параметр | Значение |
|---|---|
| `interface` | `awg0` (Финляндия) |
| `community_lists` | `meta youtube telegram` |
| `disable_quic` | `1` |
| `dns_type` | **`doh`** ← ключевой фикс |
| `dns_server` | **`1.1.1.1/dns-query`** (DoH по IP, БЕЗ префикса `https://`) |
| `download_lists_via_proxy` | **`1`** / section `main` |

> ⚠️ **DoH по IP, и значение — `1.1.1.1/dns-query` (без `https://`).** Два подвоха:
> 1. **Не bare IP.** Если задать `dns_server=8.8.8.8`, podkop подставляет каноничный DoH-URL `https://dns.google/dns-query` (**хостнейм**) — его надо резолвить через bootstrap по `:53` (за домашним хайджеком) → хрупко.
> 2. **Не полный URL `https://1.1.1.1/dns-query`.** Конфиг sing-box он соберёт верно (IP-DoH), НО **проверка «Основной DNS» в диагностике podkop баговая**: делит `dns_server` по `/` и для `https://…` выполняет `dig @https:` → ложный красный крест.
> Правильное значение **`1.1.1.1/dns-query`**: `url_get_host`=`1.1.1.1` (IPv4) → bootstrap не нужен (sing-box стучит прямо на `1.1.1.1:443`), И диагностика парсит верно (`dig @1.1.1.1 +https=/dns-query`) → зелёная.
> Косметика: «Счётчики правил mangle» краснеют в препроде (нет LAN-клиентов → forward-метки на нуле); в проде с клиентами зеленеют.

## Грабли, которые лечили (2026-06-23)
1. **`download_lists_via_proxy=0` → sing-box не качал rule-set'ы** (GitHub блокирован РКН по WAN, `/tmp/sing-box/rulesets` пуст). Фикс: `download_lists_via_proxy=1` + `download_lists_via_proxy_section=main` (detour→`main-out`=туннель). Бэкап `/etc/config/podkop.bak-srs-fix-20260623`. Подробно: [[../../snippets/podkop-reference]] §5.
2. **Главное: обход не работал (telegram/youtube 000), хотя туннель жив.** sing-box дозванивался до самого FakeIP (`dial tcp 198.18.0.x: i/o timeout`) вместо реального IP. **Корень — препрод-среда:** роутер стоит за домашним роутером, а у того **catch-all DNS-хайджек** (`udp dport 53 dnat → 10.0.0.1:53`). Восходящий резолв sing-box'а (за реальным IP по `udp:53`) перехватывался домашним хайджеком → возвращался домашний FakeIP → петля. **Фикс: `dns_type=doh`** — резолвер по `https/443` минует `:53`-хайджек. На боевом объекте (свой провайдер) работал бы и на `udp`, но DoH делает роутер устойчивым к любому вышестоящему DNS-перехвату. Грабля в справочнике: [[../../snippets/podkop-reference]] §5.
   - Тупиковые версии (отброшены проверкой): sing-box 1.12.22→1.12.4 и `dns_server` 77.88.8.8→8.8.8.8 — **на обход не влияли**, причина была в DNS-хайджеке.

## sing-box 1.13.x — НЕ ставить (пока podkop 0.7.19)
podkop 0.7.19 генерит sing-box-конфиг под ветку **1.12** (старый формат DNS-секции). В 1.13 формат DNS менялся → риск, что sing-box не распарсит конфиг и не стартует. Держим 1.12.x (как дома). Латест — только после проверки совместимости с podkop, откатно.

## Веб-терминал в LuCI (ttyd)
`luci-app-ttyd` + `ttyd` 1.7.3 уже стоят, служба enabled, слушает `0.0.0.0:7681`, **writable** (этот билд RW по умолчанию; `-R` сделал бы RO — его нет). LuCI-вьюшка (System → Terminal) вставляет `<iframe src="http://<хост-как-открыта-LuCI>:7681">`.
- **Грабля «окно терминала не активно/пустое»:** LuCI открывали на `192.168.1.1`, а этот адрес **коллизит с НИИКН/Переделки** в NetBird (тот же `192.168.1.0/24`) → iframe на `192.168.1.1:7681` уходил не туда. Фикс: `uci set ttyd.@ttyd[0].url_override='http://100.70.113.251:7681'` (стабильный NetBird-IP). Теперь терминал грузится с него независимо от того, как открыта LuCI (браузер должен быть в NetBird).
- **Рекомендация:** открывать сам роутер по NetBird — **`http://100.70.113.251`** (а не `192.168.1.1`), тогда и LuCI, и терминал однозначны. После правки — hard-refresh страницы LuCI (term.js кешируется).
- Терминал спрашивает логин (`/bin/login` → root/`1qaz!QAZ`); :7681 гейтит firewall-зона `nbird` + ACL группы Claude-Diag.

## Шлюз 1С — миграция настроек со старого WR6500H (2026-06-23)
TR3000 = шлюз Бужарово (Вариант B, см. [[../../decisions/2026-06-22-buzharovo-podkop]]). Перенесено:

**Статик-лизы DHCP** (`/etc/config/dhcp`, у всех `dns=1`):
| Хост | IP | MAC |
|---|---|---|
| Server1C | `192.168.1.249` | `00:E0:4C:68:9E:34` |
| KASSA3 (касса 1) | `192.168.1.18` | `1C:1B:0D:32:10:A2` |
| KASSIRULICA2 (касса 2) | `192.168.1.99` | `74:D4:35:83:B8:B6` |

MAC'и сняты из ARP-кэша Server1C (WinRM через openclaw LXC137 по NetBird, физ. iface `192.168.1.249` — чтобы обойти коллизию подсети с НИИКН). Полный ARP объекта — в логе сессии.

**Проброс портов** (`firewall.@redirect`, пока «как на старом WR6500H»):
- `RDP-Server1C`: WAN tcp/udp `3389` → `192.168.1.249:3389` (DNAT).
- На WR6500H публично были также 443 (LuCI) и 53 (DNS) — это сервисы самого роутера, не host-проброс, не переносим.
- ⚠️ RDP в интернет — security-риск (флагалось в разведке). Рекомендация: позже увести в NetBird (Server1C уже `100.70.75.103`). Пока по решению Олега — как на старом.

**LAN (проверено 2026-06-23):** `br-lan` = `192.168.1.1/24` (= WR6500H), gw/DNS клиентам `.1` = TR3000. DHCP-пул обрезан до **`.100–.238`** (был `.100–.249`) — статик-IP касс (`.18`/`.99`) и Server1C (`.249`) вне пула. dnsmasq→`127.0.0.42` (FakeIP), `noresolv=1`, `dont_touch_dhcp=0`. Проверка клиента: `nslookup web.telegram.org @192.168.1.1`→`198.18.x` (туннель), `gosuslugi.ru`→реальный IP (напрямую). **IPv6 на LAN отключён** (`dhcp.lan.ra=disabled`, `dhcpv6=disabled`) — против утечки заблокированного мимо v4-FakeIP (как дома/Оливье).

**Не пробрасывалось наружу:** 1С-кластер (`1540/1541/1560-1591`) и MSSQL (`1433`) — только LAN. Wi-Fi держит WR6500H в режиме AP/bridge.

**WR6500H** (`185.13.47.2`): SSH off + браузерный sha256-хэш-логин → headless-дамп конфига невозможен; 1С-настройки восстановлены из [[../../decisions/2026-05-07-buzharovo-recon]].

## Установлен на объекте + проверка (2026-06-24)
Своп со WR6500H выполнен, роутер в проде. Проверено по NetBird `100.70.113.251`:
- **WAN** поднялся на родном `185.13.47.2/25` (gw `185.13.47.1`) — WAN-MAC/тип подключения перенесены верно.
- **Туннель** awg0→Финляндия: handshake свежий, трафик идёт. telegram/youtube `200` через FakeIP (`198.18.x`); gosuslugi `200` напрямую (реальный IP). На роутере обход 100% рабочий (tproxy-счётчики PodkopTable растут).
- **1С**: Server1C `192.168.1.249` в сети; проброс RDP `3389→.249` активен (DNAT-счётчик >0, порт OPEN по WAN и по NetBird `100.70.75.103`).
- **NetBird**: Management/Signal Connected, служба enabled (autostart).
- Точки доступа TP-Link (`c4:2f:90`: .200/.105) и Keenetic (`44:47:cc`: .210) — чистые AP/bridge (свой DHCP/DNS не раздают, на :53 молчат). Двойного NAT нет.

### Грабля «обход не работает у клиентов» — ДВЕ разные причины (2026-06-24)
При миграции роутера **не перенесли DNS-hijack/анти-утечку** (дома он есть, см. [[../../snippets/podkop-reference]] §190). Клиенты резолвили мимо роутера → нет FakeIP → мимо туннеля. В conntrack видны были утечки `src=LAN dst=77.88.8.8/1.1.1.1/8.8.8.8 :53`.

**Добавлено на TR3000** (бэкапы: `/etc/config/firewall.bak-forcedns-20260624`, `firewall.bak-blockdoh-20260624`, `dhcp.bak-privaterelay-20260624`):
1. `Force-DNS-53` — DNAT всех LAN :53 (tcp/udp) → `192.168.1.1`. Заворачивает любой чужой DNS на dnsmasq роутера. ✅ счётчик растёт, утечки переписываются на `.1`.
2. `Block-DoT-853` — REJECT :853 (Android/iOS Private DNS).
3. `Block-DoH-443` — REJECT :443 к публичным DoH-резолверам (8.8.8.8/8.8.4.4/1.1.1.1/1.0.0.1/9.9.9.9/149.112.112.112/94.140.14.14-15/77.88.8.8/77.88.8.1).
4. `Block-QUIC-443` — REJECT udp/443 LAN→WAN (убивает HTTP/3-DoH и транспорт iCloud Private Relay; TCP/443 цел).
5. dnsmasq `address=/mask.icloud.com/`, `/mask-h2.icloud.com/`, `/mask-api.icloud.com/` → NXDOMAIN (отключает iCloud Private Relay при переподключении к Wi-Fi).
> ⚠️ Эти 5 правил полезны для ВСЕХ клиентов и должны остаться. После добавления сбрасывать conntrack :53 (или ждать ~30с UDP-таймаут), иначе старые сессии висят мимо DNAT.

**НО iPhone `192.168.1.115` «не сработал» по ДРУГОЙ причине (не DNS/не Relay):** на самом телефоне установлено **приложение AmneziaVPN/AmneziaWG**, заворачивающее весь трафик в свой туннель `202.71.12.186:37209` (старый резервный домашний AWG-эндпоинт). conntrack: `src=192.168.1.115 dst=202.71.12.186 dport=37209` [ASSURED], мегабайты трафика, 0 запросов :53 к роутеру изначально. Роутерный обход к такому телефону неприменим — он ходит мимо Wi-Fi-маршрутизации целиком.
> **Фикс (на стороне айфона, НЕ роутера):** выключить/удалить приложение Amnezia на телефоне (`Настройки → VPN → откл` или в самом приложении). После — переподключить Wi-Fi → пойдёт через FakeIP роутера. **Урок:** прежде чем чинить DNS на роутере — проверь conntrack клиента на свой VPN-туннель (большой UDP-поток на внешний IP мимо :53).

**Не доделано (вернуться):** подтвердить, что после выключения Amnezia на iPhone .115 трафик идёт через FakeIP (`dst=198.18.x`). Опц.: решить, оставлять ли Block-QUIC-443 (к этому айфону отношения не имел, но полезен против HTTP/3-DoH).

### 2026-06-29: РЕЦИДИВ «не работает у клиентов» — анти-утечка слетела после ребута
Клиенты снова пожаловались. Диагностика по NetBird: **роутер исправен на 100%** (awg0 handshake свежий, выход `151.241.234.241`, FakeIP подменяет `web.telegram.org→198.18.0.16`/`youtube→198.18.0.18`, gosuslugi→реальный IP). **НО все 5 правил анти-утечки (Force-DNS-53 / Block-DoT-853 / Block-DoH-443 / Block-QUIC-443 + iCloud-mask) исчезли из конфига.** В conntrack — 30+ живых утечек клиентского `:53` на публичные резолверы (`.249→1.1.1.1`, `.234→8.8.8.8`, `.238→1.0.0.1` и пр.) → клиенты резолвили telegram/youtube напрямую → мимо FakeIP → мимо туннеля → РКН блок.

**Корень:** роутер ребутнулся в 04:36 (`uptime`). Правила 06-24 были применены в рантайме, но **не закоммичены** (`uci commit`) → ребут их смыл. RDP-проброс (закоммичен) выжил, анти-утечка — нет. Это band-aid-vs-root урок: фикс не был сделан персистентным. extroot при этом смонтирован (`/dev/sda1→/overlay`), бэкапы 06-24 на месте — overlay цел, дело именно в коммите.

**Фикс (2026-06-29):** все 5 правил восстановлены через `uci` + **`uci commit firewall && uci commit dhcp`** → теперь в `/etc/config` (на overlay, переживут ребут). Бэкап «до» = `/etc/config/{firewall,dhcp}.bak-restore-20260629`. После `fw4 reload` + рестарт dnsmasq: Force-DNS DNAT-счётчик растёт (клиентский `:53` прозрачно заворачивается на `.1`, reply от `192.168.1.1`), PodkopTable tproxy несёт LAN-трафик на FakeIP→туннель, утечек на WAN — ноль. ⚠️ `conntrack`-бинаря на роутере нет — старые UDP:53-сессии не флашатся вручную, истекают сами за ~40с.

> **Проверить после следующего ребута:** что `grep -cE "Force-DNS-53|Block-DoT|Block-DoH|Block-QUIC" /etc/config/firewall` = 4. Если снова 0 — значит что-то затирает `/etc/config` (не просто некоммит), копать сторону vendor/sync.

### 2026-06-29: ⚠️ Server1C — НЕвалидная точка проверки обхода (NetBird-коллизия)
Проверял обход с самого [[server1c|Server1C]] (`192.168.1.249`, WinRM `100.70.75.103`). **Вывод: с Server1C обход НЕ работает, но это НЕ вина роутера** — артефакт коллизии подсетей.

Что измерено с Server1C:
- DNS отдаёт правильный FakeIP: `web.telegram.org→198.18.0.16`, `youtube→198.18.0.18`, `gosuslugi→реальный` ✅ (резолвер/конфиг TR3000 корректны; Force-DNS DNAT ловит даже хардкод `1.1.1.1`/`8.8.8.8`).
- НО TCP к `198.18.0.16:443` падает (ok=0/fail=10), telegram/youtube таймаутят, google.com=200, прямой выход = WAN `185.13.47.2`.
- На TR3000 в этот момент: tproxy-счётчик **delta=0**, conntrack `src=192.168.1.249 dst=198.18.*` **пуст** — пакеты Server1C к FakeIP **не доходят до br-lan роутера**.

**Корень — коллизия `192.168.1.0/24` Бужарово↔НИИКН через NetBird** (давно зафлагана в [[../../decisions/2026-06-22-buzharovo-podkop]]). На Server1C маршрут NetBird `192.168.1.0/24 → wt0` имеет **metric 1**, локальная LAN (Ethernet) — **metric 256**. Поэтому сам шлюз `192.168.1.1` резолвится через wt0: `Test-NetConnection 192.168.1.1` → SourceAddress `100.70.75.103` (wt0), `GetBestInterface(192.168.1.1)` = ifIndex wt0. Любой трафик с next-hop `192.168.1.1` утекает в NetBird → на МикроТик НИИКН (там тоже `192.168.1.1`), а не на локальный TR3000. Пин `198.18.0.0/15 → 192.168.1.1 dev Ethernet metric 1` **не помог** — отравлен сам next-hop-шлюз, не диапазон.

**Важно:** это касается ТОЛЬКО Server1C (единственный клиент с NetBird). Телефоны/кассы NetBird не имеют. ⚠️ **Тогда я поспешил с выводом «обход на объекте исправен»** — он опирался на косвенные признаки (рост tproxy-счётчика, трафик awg0, роутерный `curl`=200). Прямая проверка чистым LAN-клиентом (ниже) показала, что обход НЕ работал и для нормальных клиентов — рост счётчика был ретрансмитами падающих коннектов, а роутерный curl шёл по output-пути и маскировал залипший forward/tproxy. Настоящий корень — следующая секция.

Server1C обход и не нужен (1С-сервер, telegram/youtube ему ни к чему). Если когда-нибудь понадобится — чинить НЕ роутер, а коллизию: сузить NetBird-маршруты (не пушить `192.168.1.0/24` НИИКН на Server1C через distribution-group) либо перенумеровать один сайт. ⚠️ Латентный риск той же коллизии: 1С-инициированные коннекты к кассам `.18`/`.99` тоже ушли бы в wt0 (касса→1С работает, т.к. соединение инициирует касса).

### 2026-06-29: НАСТОЯЩИЙ корень жалоб — залип forward/tproxy sing-box после ребута
Чтобы проверить обход без NetBird-помех Server1C, поднял на самом TR3000 **netns-«LAN-клиента»** (трафик заходит на br-lan ровно как у телефона — в отличие от роутерного `curl`, который идёт по output-пути). Для этого временно ставил `ip-full`+`kmod-veth` (потом удалил):
```sh
opkg install ip-full kmod-veth        # busybox ip не умеет netns/veth; нужен kmod-veth (иначе "Unknown device type")
ip netns add lanprobe
ip link add veth-h type veth peer name veth-p
ip link set veth-p netns lanprobe; ip link set veth-h master br-lan; ip link set veth-h up
ip netns exec lanprobe sh -c 'ip link set lo up; ip link set veth-p up; ip addr add 192.168.1.241/24 dev veth-p; ip route add default via 192.168.1.1'
TG=$(ip netns exec lanprobe nslookup web.telegram.org 192.168.1.1 | awk "/^Address/{a=\$NF} END{print a}")
ip netns exec lanprobe curl -s -o/dev/null -w "%{http_code}\n" --resolve web.telegram.org:443:$TG https://web.telegram.org
# уборка: ip netns del lanprobe; ip link del veth-h; opkg remove kmod-veth ip-full libbpf1
```

**Результат ДО фикса:** DNS отдаёт FakeIP корректно (`198.18.0.16`), пакеты доходят до sing-box (счётчик `tproxy ip to 127.0.0.1:1602` растёт), **НО HTTPS = `000` (таймаут)**. sing-box принимает tproxy-коннект, но не дозванивается до реального telegram через туннель. Это та самая грабля «**роутер ходит, LAN-клиенты нет — залип FakeIP/tproxy форвард**» (см. историю commit `742e44b`, Бенелюкс 21.06). Роутерный `curl`=200 (output-путь) её маскирует.

**Фикс (сработал):**
```sh
/etc/init.d/podkop stop; killall sing-box; rm -f /tmp/sing-box/cache.db; /etc/init.d/podkop start
/etc/init.d/dnsmasq restart   # сбросить стейл-FakeIP у клиентов
```
**Результат ПОСЛЕ:** FakeIP переаллоцировался (`198.18.0.16→198.18.0.3`), netns-клиент: **telegram HTTP 200 за 0.25с, youtube 200 за 0.39с** ✅. gosuslugi→реальный IP (прямой). Анти-утечка цела (4/4). Обход для реальных клиентов теперь работает — доказано прямым тестом, не косвенно.

⚠️ **Риск рецидива на КАЖДОМ ребуте:** `/tmp` — tmpfs, cache.db создаётся заново, значит залипание — это **гонка при старте** (sing-box поднимается раньше готовности awg0/сети → forward/tproxy в кривом состоянии). Роутер ребутается (04:36 — вероятно питание, как у Server1C без ИБП). **Рекомендация:** boot-safeguard — после подъёма (когда awg0 даёт handshake) сделать `/etc/init.d/podkop restart`. Варианты: hotplug на awg0 up, или cron `@reboot sleep 60; /etc/init.d/podkop restart`, или watchdog на Антошке (как у НИИКН). Пока не внедрено — обсудить с Олегом.

**Урок (для себя):** «роутер `curl`=200 + растут tproxy-счётчики» ≠ «обход у клиентов работает». Output-путь и forward/tproxy-путь — РАЗНЫЕ. Проверять обход только с позиции клиента (netns или реальный телефон), не с роутера. [[../../snippets/podkop-fakeip-diagnostics]] §3-5.

### 2026-06-29: Мониторинг + автолечение podkop (внедрено)
Чтобы залипание форварда не повторялось молча — автолечение на ребут + watchdog с алертами.

**На роутере TR3000** (постоянно стоят `ip-full`+`kmod-veth`):
- `/usr/local/bin/podkop-probe.sh` — netns-«LAN-клиент» (192.168.1.242 на br-lan), резолвит telegram через `.1` → FakeIP, `curl --resolve` → ждёт HTTP 200. Тестирует именно forward/tproxy-путь. exit 0=OK / 1=сломан / 2=инфра. Лок не нужен.
- `/usr/local/bin/podkop-heal.sh` — `podkop stop; killall sing-box; rm cache.db; podkop start; dnsmasq restart; re-probe`. Лок `/tmp/.pkheal.lock` (от гонок).
- **Boot-self-heal:** `/etc/rc.local` → `( sleep 75; podkop-heal.sh ) &` (busybox cron НЕ умеет `@reboot`). Лечит гонку старта после каждого ребута.
- **Страховочный self-heal:** cron `*/15` `podkop-probe || podkop-heal` (на случай если LXC139 недоступна). crond enabled.

**На LXC139 (severny-les)** — мозг алертинга (секреты не на удалённом роутере):
- `/usr/local/bin/podkop-watchdog.sh` + systemd-таймер `podkop-watchdog.timer` (`*/5`). По SSH (NetBird) дёргает `podkop-probe.sh` на роутере; при поломке — `podkop-heal.sh`, повторный пробник.
- Состояния `OK`/`DOWN`/`UNREACH` в `/var/lib/podkop-wd/state`, **антиспам** (алерт только при смене). Heal-нотис деду́плится 50 мин.
- **Алерты (оба канала):** Telegram через бота **Антошки** (`8020760639…`, username `maxim_dttb_bot`) → Олег `1292155421`; **email** через mailcow `mail.dttb.ru:587` (`admin@dttb.ru`) → **`support@dttb.ru`** (mailbox на mailcow). Конфиг/секреты: `/etc/podkop-wd.env` (chmod 600).
- Сообщения: 🔴 «обход не работает / роутер недоступен», ✅ «восстановлено / роутер на связи», ⚠️ «залипал — авто-вылечен».

**Проверено боевым тестом 2026-06-29:** `podkop stop` на роутере → watchdog за ~17с поймал (пробник FAIL) → вылечил → пробник `200` → алерт TG+email ушёл, `state=OK`. Оба канала по отдельности тоже протестированы (доставка подтверждена).

Минор: при рестарте podkop/dnsmasq в логах мелькает `udhcpc: no lease, failing` — DHCP-попытка на неосновном интерфейсе, WAN (`185.13.47.2`) не страдает; разобраться отдельно (косметика).

## Установка на объекте — чеклист (выезд 2026-06-24, утро)
TR3000 полностью преднастроен на столе. На объекте — физический своп со WR6500H + WAN провайдера.

**Доступ во время работ:**
- По NetBird (основной): `ssh root@100.70.113.251` (root/`1qaz!QAZ`), LuCI `http://100.70.113.251`, веб-терминал в LuCI работает.
- Локально (фолбэк): ноут в LAN-порт TR3000 → `http://192.168.1.1` (но этот IP коллизит с НИИКН в NetBird — по NetBird-IP надёжнее).

**Шаги:**
1. **WAN/провайдер (Олег сам).** Снять с WR6500H тип подключения (Network → WAN: `DHCP` / `PPPoE` / `Static`) и **WAN-MAC** (Status). Поставить то же на TR3000 (`Network → Interfaces → WAN`):
   - *DHCP с привязкой IP к MAC* → WAN=DHCP + клонировать WAN-MAC WR6500H (WAN → Advanced → Override MAC). Иначе провайдер не выдаст `185.13.47.2`.
   - *PPPoE* → логин/пароль провайдера.
   - *Static* → IP `185.13.47.2` + маска/шлюз/DNS.
   - 2.5G-аплинк перецепить в 2.5G-порт TR3000.
2. **WR6500H → режим AP/bridge:** DHCP off; патч-корд LAN-порт WR6500H → LAN-порт TR3000. Wi-Fi 7 раздаёт WR6500H. Так нет двойного NAT (единственный NAT — на TR3000).
3. **Проверки после подъёма WAN** (`ssh root@100.70.113.251`):
   - `awg show awg0` — handshake свежий; `curl -s -m8 -o/dev/null -w '%{http_code}' https://web.telegram.org` → `200`.
   - Телефон в Wi-Fi: Telegram/YouTube открываются; gosuslugi/банк/ОФД — напрямую (НЕ через туннель).
   - Server1C получил `192.168.1.249` (статик-лиз); RDP `185.13.47.2:3389` отвечает (проброс уже на TR3000).
   - Кассы `.18`/`.99` видят 1С на `192.168.1.249`.
4. **Флешку НЕ вынимать** (на ней overlay → роутер откатится на 19 МБ внутренней памяти).

**Откат:** вернуть WAN в WR6500H + WR6500H обратно в router-режим. Конфиг TR3000 не трогается.

**Уже готово на TR3000:** extroot · podkop→awg0 (FI) `meta/youtube/telegram` · DoH · NetBird `100.70.113.251` · ttyd · статик-лизы (Server1C/KASSA3/KASSIRULICA2) · проброс RDP `3389→.249`. Server1C — доступ/рецепты: [[server1c]] (rmngr-loop: `Restart-Service '1C:Enterprise 8.3 Server Agent (x86-64)' -Force`).

## Связанное
- [[README]] — проект Бужарово
- [[../dttb/openwrt-router]] — домашний роутер (тот же финский хаб awg2; там грабля rp_filter)
- [[../../decisions/2026-06-23-amnezia-web-panel-lxc143]] — Amnezia-панель и финский хаб
