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

date, type, tags, aliases

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

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

Отдельный роутер обхода РКН для стройрынка Бужарово (Северный лес). Не путать со шлюзом 1С-сервера buzharovo-router — это новый 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 (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 (потом удалил):

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-путь) её маскирует.

Фикс (сработал):

/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-панель и финский хаб