diff --git a/projects/buzharovo/podkop-router.md b/projects/buzharovo/podkop-router.md index 4da563d..461b66c 100644 --- a/projects/buzharovo/podkop-router.md +++ b/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 провайдера. diff --git a/snippets/podkop-fakeip-diagnostics.md b/snippets/podkop-fakeip-diagnostics.md index b6a9506..fece9f8 100644 --- a/snippets/podkop-fakeip-diagnostics.md +++ b/snippets/podkop-fakeip-diagnostics.md @@ -141,6 +141,22 @@ nft 'add rule inet fw4 forward iifname "br-lan" ip daddr @doh_servers tcp dport - **`podkop check_fakeip` показывает российский IP** — тестовый домен `ip.podkop.fyi` не в community-list, идёт direct через WAN. Это проверка что *fakeip-сервис* работает, а не *обход* работает. - **`ash: ^[0-9]+...: unknown operand`** в выводе `podkop check_proxy` — баг regex'а в `/usr/bin/podkop`, не влияет. +## 8b. ⚠️ Роутер ходит, а клиенты нет — проверяй с позиции КЛИЕНТА + +Грабля, на которой легко обмануться (Бужарово 2026-06-29): с роутера `curl https://web.telegram.org`=200 И tproxy-счётчики растут — НО у LAN-клиентов обход не работает. Причина: **output-путь (трафик самого роутера) и forward/tproxy-путь (трафик клиентов) — РАЗНЫЕ.** После ребута forward/tproxy sing-box может залипнуть (гонка: sing-box стартует раньше готовности туннеля), при этом output-путь жив и маскирует проблему. Рост `iifname … 198.18/15` / `tproxy` счётчиков = пакеты лишь ПОМЕЧЕНЫ (часто ретрансмиты падающих коннектов), не «успех». + +**Проверять обход ТОЛЬКО с позиции клиента.** Если реального телефона под рукой нет — подними на роутере netns-«клиента» (трафик зайдёт на br-lan как настоящий): +```sh +opkg install ip-full kmod-veth # busybox ip без netns/veth; без kmod-veth → "Unknown device type" +ip netns add p; ip link add vh type veth peer name vp +ip link set vp netns p; ip link set vh master br-lan; ip link set vh up +ip netns exec p sh -c 'ip link set lo up; ip link set vp up; ip addr add 192.168.1.241/24 dev vp; ip route add default via 192.168.1.1' +TG=$(ip netns exec p nslookup web.telegram.org 192.168.1.1 | awk "/^Address/{a=\$NF} END{print a}") +ip netns exec p curl -s -o/dev/null -w "%{http_code}\n" --resolve web.telegram.org:443:$TG https://web.telegram.org # 200 = обход реально работает +ip netns del p; ip link del vh; opkg remove kmod-veth ip-full libbpf1 # уборка +``` +**Фикс залипшего форварда:** `/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`. Если повторяется на каждом ребуте — boot-safeguard (cron `@reboot sleep 60; /etc/init.d/podkop restart` или hotplug на awg0 up). + ## 9. Когда уже всё проверено и не помогло - Поменять `dns_type` с `udp` на `doh` (если провайдер режет UDP/53 — редко, но бывает): `option dns_type 'doh'; option dns_server 'https://dns.google/dns-query'`.