Бужарово podkop: НАСТОЯЩИЙ корень жалоб — залип forward/tproxy sing-box после ребута (фикс=restart podkop+cache); netns-тест доказал обход у клиентов; урок 'роутер curl != клиент работает' в playbook

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

projects/buzharovo/podkop-router.md

@@ -128,10 +128,36 @@ MAC'и сняты из ARP-кэша Server1C (WinRM через openclaw LXC137
 
 **Корень — коллизия `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-счётчик рос от не-`.249` клиентов (11939→12066, +127), awg0 активно гонял трафик (1 МБ+, handshake свежий), роутерный `curl web.telegram.org`=200, утечек DNS — ноль. **Обход на объекте исправен.**
+**Важно:** это касается ТОЛЬКО 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-24, утро)
 TR3000 полностью преднастроен на столе. На объекте — физический своп со WR6500H + WAN провайдера.