oleg/knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0e17414dae048cf28fd61fc1dc8859459a354197
knowledge-base/snippets/podkop-reference.md

27 KiB
Raw Blame History

date, type, tags, aliases
date type tags aliases
2026-05-29 reference
openwrt
podkop
sing-box
amneziawg
fakeip
netbird
reference
handbook
podkop
подкоп
podkop-handbook
podkop-справочник

Podkop — канонический справочник

Single source of truth по podkop. Почти все объекты Олега на этом стеке (NIIKN, Sergey, Переделки, Benelux, Krasnogorsk, Znamenskoye, HomeLab dttb). Здесь — модель, списки, правильный конфиг, грабли, инвентарь. Пошаговая диагностика «обход не работает» — в podkop-fakeip-diagnostics. Цель документа: перестать наступать на одни и те же грабли (история: ../decisions/2026-05-29-niikn-diadoc-ozon-fix — месяц лечил симптом вместо причины).

1. Модель — понимать, а не копировать

Podkop = обёртка над sing-box (+ туннель AmneziaWG/VLESS), которая селективно заворачивает ТОЛЬКО нужные домены в туннель через механизм FakeIP.

Клиент LAN
  └─DNS→ dnsmasq:53 ──(noresolv)──► sing-box FakeIP DNS 127.0.0.42:53
                                      ├─ домен В списке  → отдаёт FakeIP 198.18.x.x
                                      └─ домен НЕ в списке→ резолвит реально (upstream)
  └─пакет на 198.18.x.x → роутер: маршрут 198.18.0.0/15 → внутрь
                          → nftables fwmark + tproxy → sing-box
                          → sing-box знает реальный адрес (из FakeIP-кэша)
                          → main-out (bind_interface awg0) → туннель → EXIT
  └─пакет на реальный IP → обычный WAN напрямую

Главное, что нужно усвоить:

  • FakeIP (198.18.0.0/15) получают только домены из подключённых списков. Всё остальное идёт напрямую.
  • Туннель несёт только FakeIP-трафик. Значит «что заворачивается» = «какие списки подключены». Ошибся со списком → не тот трафик в туннеле.
  • EXIT-нода туннеля определяет, КУДА выходит завёрнутый трафик. У всех объектов Олега EXIT — зарубежный (Финляндия/Сингапур). Поэтому в туннель должно попадать только то, что нужно открывать с зарубежного IP (заблокированное РКН). Российский сайт в туннеле → выходит с зарубежного IP → гео-блок.

2. ⚠️ Списки inside/outside — ГЛАВНЫЕ грабли

itdoginfo называет списки по тому, где находится пользователь, а не где сайт. Легко перепутать. Запомнить намертво:

Список Что внутри Для кого Куда заворачивать
russia_inside Зарубежные сайты, заблокированные внутри России (РКН): соцсети, новости, и т.п. Для тех, кто внутри РФ и хочет обойти РКН ✅ в зарубежный туннель
russia_outside Российские сайты, доступные только из РФ-подсетей (gosuslugi, ozon, банки, gov.ru) Для тех, кто за границей и хочет попасть на РФ-сервисы ⛔ в РОССИЙСКИЙ выход (или вообще не заворачивать, если ты в РФ)

Мнемоника: inside = «я ВНУТРИ РФ, мне нужно наружу» (зарубежное заблокированное). outside = «я СНАРУЖИ РФ, мне нужно внутрь» (российское гео-фенсенное).

Decision guide

Сценарий объекта EXIT туннеля Какие списки НЕ ставить
Офис/дом в РФ, обойти РКН (типовой случай Олега) зарубежный (FI/SG) russia_inside ИЛИ точечно meta+youtube+telegram+(twitter/discord/tiktok по нужде) ⛔ russia_outside — сломает РФ-сайты (gosuslugi/ozon/ЕИС → гео-блок)
Доступ к РФ-сервисам из-за границы российский russia_outside inside-списки

НИИКН-урок (2026-05-29): стоял russia_outside при финском выходе → gosuslugi/ozon/ЕИС/nspd фейкапились и уходили в Финляндию → «Доступ ограничен». Лечилось dnsmasq-override'ами, которые слетали при каждом реконфиге → месяц повторяющихся жалоб. Корень — убрать russia_outside. Если объект в РФ — russia_outside НЕ ставить никогда.

Точечные списки vs бандл

Для рабочего объекта лучше точечные (meta, youtube, telegram) чем russia_inside целиком: russia_inside тащит и porn/anime/hdrezka/news — лишняя нагрузка на туннель и не всегда уместно. russia_inside оправдан, когда нужен «всё заблокированное разом».

3. Каталог community-листов

Источник: https://github.com/itdoginfo/allow-domains. Подключённые: uci -q get podkop.main.community_lists.

Список Содержимое
meta Instagram, Facebook, WhatsApp, Threads — все Meta
youtube YouTube/Google video CDN
telegram Telegram (домены + IP)
twitter X/Twitter
discord Discord (вкл. голосовые IP)
tiktok TikTok
cloudflare CF-инфра (осторожно — широкий)
oai OpenAI / ChatGPT
hdrezka,anime,news,porn контент-категории
russia_inside бандл зарубежного заблокированного (см. §2)
russia_outside ⛔ российские гео-фенсенные сайты (см. §2)

Добавить/убрать:

uci add_list podkop.main.community_lists='discord'
uci del_list podkop.main.community_lists='russia_outside'
uci commit podkop && /etc/init.d/podkop restart

4. Базовый правильный конфиг (типовой объект в РФ)

# /etc/config/podkop
uci set podkop.main.connection_type='vpn'      # vpn=AWG-интерфейс | proxy=VLESS/SS
uci set podkop.main.interface='awg0'
uci set podkop.settings.disable_quic='1'        # ⚠️ ОБЯЗАТЕЛЬНО (см. грабли)
# списки — точечные под РФ-объект:
for L in meta youtube telegram; do uci add_list podkop.main.community_lists="$L"; done
uci commit podkop && /etc/init.d/podkop restart

Обязательные внешние условия (иначе туннель «есть, но не работает»):

  1. awg0 в firewall WAN-зоне — иначе пакеты не уходят: uci add_list firewall.@zone[1].network='awg0'; uci commit firewall; /etc/init.d/firewall reload Проверка: nft list chain inet fw4 output | grep awg0 → oifname "awg0" jump output_wan.
  2. DNS клиентов = роутер (DHCP option 6), цепочка LAN→dnsmasq→127.0.0.42 с noresolv=1.
  3. Маршрут FakeIP-диапазона на upstream-роутере, если podkop не на дефолтном шлюзе (как НИИКН, где шлюз — MikroTik): /ip route add dst-address=198.18.0.0/15 gateway=<podkop-router> (MikroTik-синтаксис).
  4. EXIT зарубежный для inside-сценария.

5. Грабли (то, на что я наступал) — проверять в первую очередь

Грабли Симптом Что делать
russia_outside на РФ-объекте РФ-сайты (gov/ozon/банки) «Доступ ограничен», заграница работает Убрать список (§2). НЕ лепить per-domain override.
busybox ip -br не поддерживается ip -br link молча пуст → ложный вывод «интерфейса нет» Проверять ip addr show awg0 / ip link show awg0, живость — ping -I awg0 8.8.8.8. ../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_busybox_ip_br_flag
dnsmasq-overrides слетают «вчера работало, сегодня нет» после реконфига podkop владеет dhcp.@dnsmasq[0].server и переписывает его. Не бороться за override — убрать причину фейкапа (список). Если override нужен — выносить в /etc/dnsmasq.d/ (podkop не трогает).
disable_quic=0 YouTube/Meta/Google текут мимо обхода QUIC/HTTP3 на UDP:443 идёт мимо tproxy. disable_quic='1' обязателен.
awg0 не в WAN-зоне туннель UP, handshake есть, но трафик не уходит добавить awg0 в firewall WAN (§4).
NetBird + podkop конфликт fwmark tproxy-счётчик не растёт там, где есть NetBird (Переделки) оба вешают chain на prerouting priority mangle (-150), NetBird перетирает mark 0x00100000. Фикс: патч /usr/bin/podkop — priority -150 → -140. ../decisions/2026-04-17-peredelki-podkop-stability-fix
sing-box crash-loop / cache.db lock sing-box рестартует по кругу после ребута залочен cache.db (две копии): killall sing-box; sleep 2; /etc/init.d/podkop restart
sing-box без procd-автозапуска после ребута обход мёртв /etc/init.d/sing-box enabled должно быть включено
AmneziaWG H-значения диапазоном handshake не встаёт H1–H4 на сервере и клиенте — фиксированные числа, не диапазоны
MTU/фрагментация сайты открываются наполовину MTU awg0 1420→1380; ping -M do -s 1380 8.8.8.8 -I awg0
Клиент сам обходит DNS роутера curl с роутера ок, у клиента нет; на iPhone «видео играет и стопорится» (Instagram/YouTube) при здоровом туннеле iPhone: первым делом Wi-Fi → (i) → «Ограничение отслеживания IP‑адреса» ВЫКЛ — это default-on в iOS, включает шифрованный DNS мимо роутера и бьёт приложения (не только Safari). Далее iCloud Private Relay / Safari Hide IP / Chrome DoH. Выключать у клиента; сетевой вариант — блок mask.icloud.com/mask-h2.icloud.com + DoH в AGH. На роутере DNAT :53 + reject DoH. Дом 2026-06-23: iPhone Надежды, Instagram-видео — лечилось «Ограничением отслеживания IP». ../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_iphone_breaks_fakeip
🔴 Анти-утечка DNS не перенесена при миграции роутера новый роутер: обход на самом роутере ОК (curl 200, tproxy-счётчики растут), но у клиентов нет. В conntrack: src=LAN dst=8.8.8.8/1.1.1.1/77.88.8.8 dport=53 — клиенты резолвят мимо dnsmasq → нет FakeIP → мимо туннеля Перенести с эталонного роутера комплект анти-утечки: (1) Force-DNS-53 DNAT всех LAN :53 (tcp/udp)→<router-lan-ip>; (2) Block-DoT-853 REJECT; (3) Block-DoH-443 REJECT :443 к публичным DoH-IP (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); (4) Block-QUIC-443 REJECT udp/443 LAN→WAN (HTTP/3-DoH + транспорт iCloud Relay; TCP/443 цел); (5) dnsmasq address=/mask.icloud.com/+/mask-h2.icloud.com/+/mask-api.icloud.com/→NXDOMAIN. После — сбросить conntrack :53 (или ждать ~30с), иначе старые сессии висят мимо DNAT. Проверка: grep dport=53 /proc/net/nf_conntrack | grep -v dst=<router> пусто. Бужарово TR3000 2026-06-24.
🔴 Клиент с СОБСТВЕННЫМ VPN на телефоне (ложный «DNS не работает») Один клиент упорно не обходит, хотя DNS-фиксы применены. conntrack клиента: 0 запросов :53 к роутеру + крупный UDP-поток src=CLIENT dst=<внешний-IP> dport=<высокий> [ASSURED], мегабайты На телефоне установлено приложение AmneziaVPN/AmneziaWG/любой WireGuard — весь трафик идёт в свой туннель мимо Wi-Fi-маршрутизации роутера. Роутерный обход неприменим в принципе. Фикс — на телефоне: выключить/удалить VPN-приложение (Настройки → VPN → откл). Диагностика-правило: прежде чем чинить DNS на роутере, проверь conntrack клиента на свой VPN-туннель (большой UDP на внешний IP мимо :53) — иначе чинишь не то. Бужарово iPhone .115 2026-06-24 (туннель на 202.71.12.186).
podkop restart сбрасывает shutdown_correctly редкие странности после рестарта проверять флаг после рестарта
Роутер ходит, LAN-клиенты — нет (залип FakeIP/tproxy для форвардного) сам Cudy curl https://api.anthropic.com → 405, а с LXC/клиента ВСЕ туннельные сайты (telegram/anthropic) виснут на TCP-connect (Trying 198.18.x... timed out, до Connected не доходит); nft-метки/tproxy счётчики растут, но SYN-ACK не возвращается. Прямые сайты (не в списках) у клиента работают killall sing-box; sleep 2; rm -f /tmp/sing-box/cache.db; /etc/init.d/podkop restart на роутере. Бенелюкс 2026-06-21: из-за этого «висли» агенты swarmclaw на коробке (claude не достучивался до Anthropic). Диагностика-ловушка: curl --interface awg0 https://api.anthropic.com НЕ показатель — резолвит в FakeIP и шлёт фейк прямо в awg0 → ложный таймаут. Правильно = обычный FakeIP-путь роутера.
download_lists_via_proxy='1' с ПУСТОЙ секцией ломает sing-box sing-box FATAL: start service: initialize rule-set: download detour not found: -out → detour-тег вышел -out (пустая секция + суффикс) На 0.7.19 включать МОЖНО и НУЖНО, если GitHub блокирован РКН: uci set podkop.settings.download_lists_via_proxy=1; uci set podkop.settings.download_lists_via_proxy_section=main → detour main-out (туннель). Тогда remote rule-set'ы (*.srs с release-assets.githubusercontent.com) качаются ЧЕРЕЗ туннель. Без этого при пустом /tmp/sing-box/rulesets (после rm cache.db/обновления) sing-box падает initialize rule-set: Get ... т.к. route.final=direct-out=WAN. Грабля 0.7.14 = НЕ задана секция. HomeLab dttb 2026-06-23.
podkop list_update падает: raw.githubusercontent.com блокирован РКН в логах Attempt N/3 to download .../*.lst failed, напрямую с WAN curl raw.git = HTTP 000. Списки тихо устаревают (обход «потихоньку перестаёт ловить» новые домены/подсети) Добавить сам GitHub в обход: uci set podkop.main.user_domain_list_type='dynamic'; uci add_list podkop.main.user_domains='githubusercontent.com'; uci commit podkop; /etc/init.d/podkop restart. Тогда роутерный list_update резолвит raw.git в FakeIP → туннель → HTTP 200. via_proxy оставить 0.
🔴 rp_filter строгий на awg-интерфейсе → handshake есть, транзита НЕТ awg show = свежий handshake + растёт received; но ping -I awgN 1.1.1.1 = 100% потерь, end-to-end 000, sing-box не качает списки. Transport-ответ из туннеля приходит на awgN, при rp_filter=1 (strict) ядро не видит обратного маршрута к internet-src через awgN → дроп до доставки. Особенно на мульти-туннельных роутерах, где один awg работает (стоит =2), другой нет (унаследовал default=1) sysctl -w net.ipv4.conf.<iface>.rp_filter=2 (loose) → проверь ping -I <iface>. Персистентно: строка net.ipv4.conf.<iface>.rp_filter=2 в /etc/sysctl.conf + hotplug /etc/hotplug.d/iface/99-awg-rpfilter (loose на все awg* при ifup). Диагностика: сравни sysctl net.ipv4.conf.{рабочий,сломанный}.rp_filter — разница 2 vs 1 = это он. HomeLab dttb 2026-06-23 (awg2 vs awg0).
🔴 podkop-роутер ЗА чужим DNS-хайджеком → sing-box звонит на FakeIP Туннель жив (ping -I awg ОК), FakeIP присваивается, но end-to-end 000. В логах: open connection to <домен> using outbound/direct[main-out]: dial tcp 198.18.0.x: i/o timeout — sing-box знает домен, но дозванивается до самого FakeIP вместо реального IP. podkop self-check: ❌ «Прокси-трафик не маршрутизируется через FakeIP». Причина: при dns_type=udp восходящий резолв sing-box'а (реальный IP по udp:53) перехватывается вышестоящим роутером с DNS-хайджеком (udp dport 53 dnat → его DNS) → возвращается ЕГО FakeIP → петля. Бывает, когда podkop-роутер стоит WAN'ом за другим роутером, который сам хайджачит :53 (типично в препрод-лабе за домашним шлюзом). uci set podkop.settings.dns_type=doh + dns_server='1.1.1.1/dns-query' (DoH по IP, БЕЗ https://) → restart. Резолвер по https/443 минует :53-хайджек. ⚠️ Значение точно 1.1.1.1/dns-query: (а) НЕ bare 8.8.8.8 — podkop мапит bare IP в каноничный хостнейм (https://dns.google/dns-query), а хостнейм требует bootstrap по :53 (тоже хайджек); (б) НЕ полный https://1.1.1.1/dns-query — конфиг соберётся ОК, но проверка «Основной DNS» в диагностике podkop баговая (делит по /, делает dig @https:) → ложный красный. С 1.1.1.1/dns-query: url_get_host=IP → без bootstrap, И диагностика зелёная. На боевом объекте со своим провайдером работал бы и udp, но DoH = устойчивость к вышестоящему DNS-перехвату. НЕ путать с «missing fakeip record» (транзиент после rm cache.db). Бужарово/Severni Les 2026-06-23 за домашним catch-all хайджеком.

6. Частые операции

# Завернуть конкретный домен, которого нет в листах (через туннель):
uci set podkop.main.user_domain_list_type='dynamic'
uci add_list podkop.main.user_domains='example.com'    # покрывает и поддомены
uci commit podkop && /etc/init.d/podkop restart

# ИСКЛЮЧИТЬ домен из проксирования (форсировать реальный IP → напрямую).
# ⚠️ Сначала спроси: а почему он вообще фейкапится? Может, лишний список (§2).
# Если правда нужен — override в dnsmasq:
uci add_list dhcp.@dnsmasq[0].server='/example.ru/77.88.8.8'
uci commit dhcp && /etc/init.d/dnsmasq restart
rm -f /tmp/sing-box/cache.db && /etc/init.d/sing-box restart   # сбросить старый FakeIP

# Обновить листы вручную:
podkop list_update

7. Диагностика (кратко; полный runbook отдельно)

Самый полезный тест — спросить sing-box напрямую, фейкапит ли он домен:

nslookup ozon.ru 127.0.0.42
#  198.18.x.x → домен В списке (заворачивается). Реальный IP → идёт напрямую.

Этим я доказал НИИКН-фикс: до удаления russia_outside РФ-сайты = 198.18.x, после = реальные, а instagram/youtube остались 198.18.x.

Дальше — по шагам: podkop-fakeip-diagnostics (туннель → sing-box → nft/tproxy → маршрут → FakeIP → DNS-цепочка → клиент).

8. Анти-паттерн: симптом vs причина

  • Жалоба «РФ-сайт не открывается» + FakeIP на нём → не лепить override, а спросить «какой список его поймал» и убрать список.
  • «Overrides слетают» → не строить watchdog на доливку overrides, а убрать причину фейкапа.
  • Повторяется второй раз → проверить свой исходный конфиг, а не обход.
  • ../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_root_cause_recurring

9. Инвентарь podkop по объектам

Объект Роутер / доступ conn / iface EXIT Списки Статус
НИИКН OpenWrt VM101 192.168.1.50 (jump pve-niikn 100.70.120.229) vpn / awg0 Финляндия 78.17.4.225 meta,youtube,telegram + user_domains: Google AI, grok/x.ai, anthropic.com+claude.ai (2026-06-25) ✅ russia_outside убран 2026-05-29; gov через NetBird→LionART маршруты + dnsmasq-overrides (backup); watchdog на pve-niikn. AI-сервисы блокируют РФ-IP (anthropic→403 гео) → заводить в user_domains (dynamic). claude.ai отдаёт CF-challenge 403 в curl, но в браузере ОК
Sergey/Одинцово Cudy TR3000 100.70.110.164 root/1qaz!QAZ vpn / awg0 Сингапур 202.71.12.186 russia_inside,telegram,meta ✅ корректно (inside); VLESS-резерв vlees
Переделки см. ../projects/peredelki/README / ../projects/peredelki/credentials — — проверить fwmark-патч -150→-140 (NetBird coexistence)
Benelux Cudy TR3000 100.70.207.97, ssh mac-ed25519 (compromise 2026-05-20) vpn / awg0 Сингапур 202.71.12.186 russia_inside,telegram,meta (+githubusercontent.com user_domain) ✅ 2026-06-17: обход ОК (TG 302 / WA 200), russia_outside нет; list_update чинён (raw.git заведён в обход — RKN блокировал WAN-загрузку); download_lists_via_proxy=1 сломал sing-box, откатан
HomeLab dttb ../projects/dttb/openwrt-router (Cudy TR3000 10.0.0.1) vpn / awg2 Финляндия 151.241.234.241:41624 meta,russia_inside,telegram,google_ai ✅ 2026-06-23 на awg2; резерв awg0 202.71.12.186. Цепочка dnsmasq→AGH:5353→127.0.0.42; DNS-hijack стоит. Грабля: per-iface rp_filter=2 обязателен (см. §5)
Severny-Les / Бужарово ../projects/buzharovo/podkop-router (Cudy TR3000, NetBird 100.70.113.251; фолбэк jump 10.0.0.250→192.168.1.1) vpn / awg0 Финляндия 151.241.234.241:41624 meta,youtube,telegram ✅ 2026-06-23; dns_type=doh + dns_server=1.1.1.1/dns-query (DoH по IP, без https://; стоит за домашним :53-хайджеком — иначе sing-box звонит на FakeIP, см. §5); download_lists_via_proxy=1/main; sing-box 1.12.4
Krasnogorsk / Znamenskoye см. project README — — проверить проверить

Быстрый аудит любого роутера на «грабли inside/outside»: ssh root@<ip> 'uci -q get podkop.main.community_lists' — если объект в РФ и видишь russia_outside → это баг. TODO: пройтись по Переделки/Benelux/Krasnogorsk/Znamenskoye этим аудитом.

Ссылки

Reference in New Issue View Git Blame Copy Permalink