Ruslan PiatrovichandCursor
532ac723cb
Includes global state.vscdb, per-repo transcripts, workspace storage, composer exports, and restore scripts for a new machine. Co-authored-by: Cursor <cursoragent@cursor.com>
5 lines
6.9 KiB
JSON
5 lines
6.9 KiB
JSON
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nсходи на роутер ssh komehdaht@192.168.50.1\nпосмотри почему перестали работать jffs для обхода блокировок через польский впс\nкогда дома подключаюсь к вайфаю все ок\nкогда не дома подключаюсь через вг, иногда работает, иногда нет интернета\n</user_query>"}]}}
|
||
{"role":"assistant","message":{"content":[{"type":"text","text":"Пробуем подключиться к роутеру по SSH. 192.168.50.1 доступен только из вашей домашней сети; если среда выполнения не в той же сети, подключение не установится."}]}}
|
||
{"role":"assistant","message":{"content":[{"type":"text","text":"Подключение установлено (ASUSWRT-Merlin). Проверяем JFFS, VPN и маршрутизацию."}]}}
|
||
{"role":"assistant","message":{"content":[{"type":"text","text":"Проверяю таблицу маршрутизации `wgc1` и скрипты DNS — JFFS в порядке, проблема, скорее всего, в политике маршрутизации и DNS."}]}}
|
||
{"role":"assistant","message":{"content":[{"type":"text","text":"Вот что видно по факту с роутера.\n\n## JFFS\n\n**С JFFS всё в порядке:** раздел смонтирован (`ubi:jffs2` → `/jffs`, ~19% занято), скрипты на месте и выполняются (`firewall-start`, `services-start`, `wg_dnsmasq_watcher.sh`, `update_ai_dns.sh` и т.д.). Проблема не в «сломавшемся JFFS», а в том, **как устроен обход** (DNS + политики маршрутизации + WireGuard).\n\n## Как у вас сейчас устроен обход\n\n1. **Клиент WireGuard на роутере (`wgc1`)** — туннель в Польшу, пир **91.108.237.249**, handshake свежий, трафик по туннелю идёт.\n2. **В `nvram` у клиента WG:** `wgc_enable=0` — при этом интерфейс **поднят** (скорее, после ручной настройки/скрипта). После перезагрузки поведение может отличаться от ожидаемого; если что-то «отвалилось», проверьте в веб-интерфейсе, что клиент включён и сохранён.\n3. **Обход блокировок** делается через **dnsmasq + ipset `WG_AI_BYPASS`** и скрипт `wg_dnsmasq_watcher.sh`: он по логу DNS добавляет **сотни** правил `ip rule ... lookup wgc1` на конкретные IP. \n Без прохождения DNS через роутер эти правила **не появляются** для новых IP.\n4. В **глобальном DHCP** на WAN указано: `dhcp_dns = 8.8.8.8 1.1.1.1` — для клиентов LAN это может отличаться от сценария «всё через dnsmasq».\n\n## Почему дома стабильно, а «не дома через WG» — то да, то нет\n\nНаиболее правдоподобное объяснение **«иногда работает, иногда нет»**:\n\n1. **DNS на телефоне не всегда роутерный** \n Для схемы с ipset и watcher’ом **запросы к заблокированным доменам должны идти на DNS роутера (обычно `192.168.50.1`)**. В Merlin у сервера WG включено `wgs_dns=1` — роутер **может** отдавать DNS в профиль клиента, но на **Android** «Частный DNS» / **iOS** «ограничения контента» / DoH в браузере или приложениях DNS **может обходить** роутер. Тогда IP не попадает в ipset/лог, **правило `ip rule` в `wgc1` не создаётся**, и трафик к части CDN уходит в ISP и **режется** — отсюда «то открывается, то нет».\n\n2. **Ротация IP у CDN** \n Список из `ip rule` привязан к **уже увиденным** IP. Дома кэш DNS и список стабильнее; в сети снаружи чаще другие edge-адреса — пока не сработает `reseed`/watcher, часть трафика может идти не через `wgc1`.\n\n3. **Второй пир WireGuard на сервере** \n У пира **10.6.0.3** handshake **несколько дней** — если это ваш второй телефон/ноутбук, он может не подключаться; на «иногда нет интернета» это влияет только если вы путаете устройства.\n\n4. **MTU** \n Вложенный WG (телефон → домашний WG → польский WG) иногда даёт **обрывы/«нет сети»** из‑за MTU; это чаще лечится уменьшением MTU в клиенте (например 1280) или `PostUp`/`MTU` на сервере — имеет смысл, если проблема именно в «полном отсутствии» пакетов, а не только у отдельных сайтов.\n\n## Что проверить у себя\n\n1. В приложении WireGuard на телефоне в профиле для **домашнего** туннеля: **DNS = `192.168.50.1`** (или пусто, если клиент подставляет то, что раздаёт роутер), **не** 8.8.8.8 / 1.1.1.1 / «Частный DNS».\n2. Временно отключить **Private DNS** на Android и проверить, стабилизируется ли доступ.\n3. В веб-интерфейсе: **VPN → WireGuard → клиент** — включён ли клиент, совпадает ли с тем, что реально поднято (`wgc1` сейчас живой).\n4. Если после перезагрузки роутера всё «отваливается» — смотреть, не сбрасывается ли `wgc_enable` и поднимается ли `wgc1` автоматически.\n\nИтого: **JFFS не причина**; критично, чтобы **DNS для обхода шёл через роутер** и чтобы **клиент WireGuard в Польшу** был стабильно включён в конфиге. Если опишете точнее: «нет интернета вообще» или «не открываются только AI/заблокированные сайты» — можно сузить до DNS или до MTU/полного туннеля."}]}} |