Files

dttb bf565f1392 mmfb/lionart-1c: SSH + фикс efsaveragent + накопленный backlog vault-а

Сегодня (mmfb / LionART 1C):
- projects/mmfb/lionart-1c.md — новый файл: VM 100 на pve LionART
  (WIN-70M2VEJIKEF, 10.253.1.240, Win Server 2022, 1С+SQL+Effector Saver),
  SSH-доступ claude/Kl@udeD1ag!2026 заведён, RDP под Администратор + 2FA.
- projects/mmfb/proxmox-inventory.md — hostname WIN-70M2VEJIKEF в VM 100.
- decisions/2026-05-28-mmfb-effector-saver-locked-admin.md — диагноз
  цикла 7038 (SCM-пароль разъехался с .\Администратор) + lockout учётки,
  и пошаговое решение (disable службы → ADSI unlock → LogonUser-проверка
  → sc.exe config password= → start auto).

Накопившийся backlog (без отдельной правки в эту сессию):
- decisions/: buzharovo (recon, migration-plan, 1c-licensing), sergey
  (instagram iPhone fakeip), amneziavpn macOS v1/v2 incompat, benelux
  compromise 2026-05-20, glavtorg autologon off, omni domain+update.
- projects/: benilux README, buzharovo README+server1c, dttb
  (nextcloud-talk-bot, npm-proxy-hosts, proxmox-inventory, vpn-clients),
  glavtorg, sergey README, projects/_index.
- claude-memory/: benelux, omniroute.
- snippets/mac-dictation/groq-dictate.sh.
- notes/claude/: ~80 авто-сохранённых транскриптов сессий за май.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-29 12:33:03 +03:00

6.2 KiB

Raw Permalink Blame History

date, type, status, tags, aliases

date

type

status

2026-05-12 — Sergey: «Инста не работает» — диагноз и фикс

Кейс

Сергей (объект ../projects/sergey/README, Одинцово, Cudy TR3000 v1, 100.70.110.164) пожаловался Олегу — на телефоне не открывается Instagram через его роутер. Стек обхода: podkop v0.7.14 + sing-box 1.12.12 + AmneziaWG (kmod) до VLESS-Singapore endpoint 202.71.12.186, community_lists = russia_inside, telegram, meta.

Что проверил (на роутере)

Проверка	Результат
AmneziaWG `awg0` handshake	свежий (1:37 назад), 11.5 GiB rx
Sing-box процесс	running PID 11491
nft mangle + tproxy 127.0.0.1:1602	108k TCP / 2598 UDP пакетов прошли
FakeIP для `www.instagram.com` через `192.168.1.1` (dnsmasq роутера)	`198.18.0.17` ✅
FakeIP для `i.instagram.com`	`198.18.0.6` ✅
FakeIP для `scontent.cdninstagram.com`	`198.18.0.27` ✅
`curl --interface awg0 https://www.instagram.com/` с роутера	HTTP/2 200 ✅
WAN exit IP без VPN	`217.73.118.172` (NetByNet, РФ)
WAN exit IP через `awg0`	`202.71.12.186` (Singapore) ✅
`podkop list_update`	прошёл 09:13 сегодня без ошибок
DNS 8.8.8.8 / 1.1.1.1 не режется провайдером	подтверждено nslookup'ом

На стороне роутера всё исправно. Никаких правок инфраструктуры не нужно.

Реальная причина

В DHCP-leases роутера активен ровно один клиент — 192.168.1.102, MAC 2e:7f:8c:ce:07:8a (рандомизированный — бит 02 в первом октете), т.е. iPhone/Android с приватным Wi-Fi-MAC. Все маркеры указывают на iPhone, который обходит роутерный DNS:

iCloud Private Relay — целиком тоннелирует трафик Safari + системные DNS через Apple-серверы (mask.icloud.com), минуя локальный dnsmasq. FakeIP не успевает подменить IP.
Encrypted DNS в Safari / приложении Instagram / Chrome (DoH к 1.1.1.1:443 или dns.google:443 по TCP) — те же симптомы.
Кастомный DNS-профиль в настройках Wi-Fi сети — устройство просто игнорирует роутерный DNS.

В любом из трёх случаев клиент получает реальный IP 157.240.x.x от внешнего DoH-резолвера, и DPI провайдера (NetByNet) блочит TLS handshake по SNI instagram.com.

Фикс — клиент-сайд (приоритет)

Скажи Сергею выключить на iPhone в таком порядке:

Настройки → имя сверху → iCloud → Частный узел → ВЫКЛ
Настройки → Wi-Fi → ⓘ его сети → Настройка DNS → Автоматически
Safari → Конфиденциальность и безопасность → Скрывать IP-адрес → ВЫКЛ
Если ходит через Chrome: chrome://settings/security → DNS через HTTPS → ВЫКЛ
Wi-Fi выкл/вкл на телефоне (сбросить кэш DNS клиента)

Этих действий достаточно в 80%+ случаев для подобных сетапов.

Фикс — роутер-сайд (если клиентский путь не помог)

В podkop v0.7.14 нет встроенной опции "force DNS / block DoH" — делать вручную через nft. Опционально — у домашнего OpenWrt Олега это уже сделано (projects/dttb/openwrt-router.md: «DNS Hijack: перехватывает порт 53 → 10.0.0.1»).

Шаги для Сергея (если потребуется):

# 1) Принудительный редирект исходящего 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'

# 2) Drop DoH/DoT к публичным резолверам (TCP/443 + TCP/853)
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'

# 3) Закрепить в /etc/firewall.user или uci

Также можно поднять AdGuard Home (как у Олега в HomeLab) — он по умолчанию форсит свой :53 и фильтрует DoH-домены. Сейчас у Сергея AGH не установлен — стек чисто dnsmasq → 127.0.0.42 (sing-box) → upstream.

Что НЕ является проблемой

Шум в логе sing-box — ERROR ... {GUID}-netseer-ipaddr-assoc.xy.fbcdn.net: empty result. Это Meta NetSeer probes (anti-CDN-detection), штатное поведение Meta. Игнорировать.
check_fakeip показывает 217.73.118.172 — это российский WAN IP роутера. Тестовый домен (ip.podkop.fyi) не в community-listах, идёт direct через WAN — это норма для проверки.

Связанное

../projects/sergey/README — полный recon роутера
../snippets/podkop-fakeip-diagnostics — типовой playbook для диагностики любого подкоп-роутера
../projects/dttb/openwrt-router — домашний OpenWrt Олега, где DNS-hijack уже включён
2026-04-30-openwrt-homelab-agh-podkop-chain — стек AGH+podkop у Олега дома (как референс)

6.2 KiB Raw Permalink Blame History Unescape Escape