oleg/knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
77924a8972dab0cb4668667f4d05195ba0b1b9ad
knowledge-base/snippets/podkop-fakeip-diagnostics.md

11 KiB
Raw Blame History

date, type, tags
date type tags
2026-05-12 snippet
openwrt
podkop
fakeip
amneziawg
sing-box
diagnostics
playbook

Диагностика подкоп-роутера (podkop + sing-box + AmneziaWG + FakeIP)

Универсальный playbook когда клиент жалуется «обход не работает» на типовом домашнем сетапе Олега. Идти строго по порядку — каждый шаг отсекает класс причин.

SSH-доступ ко всем роутерам Олега: ssh root@<netbird-ip> пароль 1qaz!QAZ. На Сергее проверено 2026-05-12 — см. ../decisions/2026-05-12-sergey-instagram-iphone-fakeip. 📖 Модель / списки / правильный конфиг / грабли / инвентарь → podkop-reference (это — только пошаговая диагностика).

0. Базовое — что вообще стоит

cat /etc/openwrt_release
opkg list-installed | grep -iE "podkop|sing-box|amneziawg|adguard|netbird|dnsmasq"
ps w | grep -iE "sing-box|podkop|adguard" | grep -v grep

1. AmneziaWG туннель живой?

ip -br a | grep -iE "awg|wg"
awg show awg0          # latest handshake должен быть <2 мин
ip route | grep awg0   # должен быть default или markroute
  • Handshake > 5 мин → endpoint недоступен или порт зарезан DPI. Проверить с другого хоста curl <endpoint>:<port> (если TCP-VLESS) или ребутнуть peer.
  • Нет интерфейса awg0 → kmod-amneziawg не загружен или конфиг побит: dmesg | grep -i amnezia, uci show network | grep awg.

2. Sing-box процесс живой?

ps w | grep -v grep | grep sing-box
ls -la /etc/sing-box/cache.db    # дата = когда последний раз был апдейт fakeip
podkop check_logs 2>&1 | tail -40

3. nft маркировка и tproxy

podkop check_nft | grep -E "tproxy|@podkop_subnets|198\.18" 
nft list table inet podkop 2>&1 | head -80

Смотреть счётчики (counter packets <N>):

  • Если 0 пакетов в proxy chain через tproxy ip to 127.0.0.1:1602 — клиенты не идут через FakeIP вообще (см. шаг 5).
  • Если есть пакеты — заворот работает, проблема ниже.

4. AmneziaWG реально маршрутизирует?

# Базовый WAN exit
curl -4 -s --max-time 5 https://ifconfig.me; echo
# Через туннель
curl -4 -s --max-time 5 --interface awg0 https://ifconfig.me; echo

Должны вернуться разные IP. Если оба = WAN — ip rule / fwmark сломан, либо main-out в sing-box без bind_interface: awg0.

ip rule | grep -E "podkop|fwmark"
jq '.outbounds[] | select(.tag=="main-out")' /etc/sing-box/config.json

5. FakeIP реально подменяет?

# Через локальный dnsmasq
for d in www.instagram.com chatgpt.com discord.com www.youtube.com; do
  printf "%-25s -> " "$d"
  nslookup $d 192.168.1.1 2>/dev/null | awk '/^Name:/{getline; print $2}'
done
  • Ответы 198.18.x.x → FakeIP работает ✅
  • Реальные IP типа 157.240.x.x → домен не в community-list, либо domain_resolver_enabled=1 (тогда sing-box резолвит сам, fakeip обходится).

Что подключено сейчас:

uci get podkop.main.community_lists      # сейчас: russia_inside, telegram, meta
podkop list_update                       # обновить вручную

Доступные community-листы podkop: russia_inside, russia_outside, telegram, meta, discord, cloudflare, oai (OpenAI/ChatGPT), twitter, hdrezka и др.

⚠️ inside ≠ outside! Объект в РФ (обход РКН, зарубежный выход) → russia_inside или точечные meta/youtube/telegram. НИКОГДА russia_outside — он гонит РФ-сайты (gosuslugi/ozon/ЕИС) в зарубежный выход → гео-блок. Полная семантика: podkop-reference#2-списки-insideoutside-главные-грабли.

Добавить — uci add_list podkop.main.community_lists='discord'; uci commit podkop; /etc/init.d/podkop restart.

6. DNS-цепочка целая?

# Кто слушает 53?
ss -ulnp 2>&1 | grep ":53"
# Через что dnsmasq форвардит
uci show dhcp.@dnsmasq[0] | grep -E "server|noresolv"
# Прямой 8.8.8.8 / 1.1.1.1 не режется провайдером?
nslookup chatgpt.com 8.8.8.8
nslookup chatgpt.com 1.1.1.1

Корректная цепочка для типового стэка: LAN → dnsmasq:53 → 127.0.0.42 (sing-box DNS) → upstream (с noresolv=1). Цепочка с AGH (как у Олега в HomeLab): LAN → dnsmasq:53 → AGH:5353 → 127.0.0.42 (sing-box) → upstream.

7. Клиент сам обходит роутерный DNS? (iPhone-проблема)

Это самая частая причина, когда роутер исправен. См. полный фикс ../decisions/2026-05-12-sergey-instagram-iphone-fakeip.

Признаки:

  • В /tmp/dhcp.leases MAC с рандомизированным первым октетом 02, 06, 0a, 0e (приватный Wi-Fi на iOS/Android)
  • Curl с роутера работает, у клиента — нет

Что сказать клиенту (iPhone):

  1. iCloud Private Relay → ВЫКЛ
  2. Wi-Fi → DNS → Автоматически
  3. Safari → Скрывать IP → ВЫКЛ
  4. Chrome → DNS over HTTPS → ВЫКЛ

Если клиент-сайд не подействовал — сделать на роутере:

# DNAT всего LAN-DNS:53 → роутер
nft 'add rule inet fw4 dstnat iifname "br-lan" meta l4proto { tcp, udp } th dport 53 dnat ip to 192.168.1.1:53'

# Reject DoH/DoT к публичным резолверам
nft 'add set inet fw4 doh_servers { type ipv4_addr; flags interval; elements = { 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 149.112.112.112 } }'
nft 'add rule inet fw4 forward iifname "br-lan" ip daddr @doh_servers tcp dport { 443, 853 } reject with tcp reset'

8. Что является НОРМОЙ (не баг)

  • Meta NetSeer probes в логе sing-box: ERROR ... {GUID}-netseer-ipaddr-assoc.xy.fbcdn.net: empty result — anti-CDN-detection Meta, штатное поведение, игнорировать.
  • 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 как настоящий):

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'.
  • Перейти с connection_type=vpn (AWG) на connection_type=proxy (VLESS) — секция vlees уже настроена как резерв.
  • Проверить MTU: ping -M do -s 1380 8.8.8.8 через awg0 — если фрагментация, MTU 1420 на awg0 уменьшить до 1380.

Ссылки

Reference in New Issue View Git Blame Copy Permalink