Files
knowledge-base/projects/buzharovo/podkop-router.md

209 lines
32 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
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-панель и финский хаб