Домены Firebase/Google Cloud Functions (*.cloudfunctions.net) не входят
в Google-список, поэтому попадают под общую TLS-стратегию (#v7 и т.п.).
С ней Google Front End отдаёт только первый пакет ServerHello, дальше
соединение висит.
Пример: Goose Goose Duck ходит в API на
us-central1-gaggle-staging.cloudfunctions.net (HTTP/2, TLS 1.2, BestHTTP/2).
Под #v7 игра ждёт 20 с, уходит на медленный fallback и грузится ~135 с.
С cloudfunctions.net в Google-списке (#Yv08) — ~17 с.
splify2 считался установленным по любому следу: каталогу /usr/lib/splify2,
скрипту /etc/init.d/splify2 или объекту ubus. После удаления splify2 такие
следы остаются, и вкладка Steer закрывалась плашкой «Установлен splify2».
Теперь splify2 считается установленным, только если на месте его служба rpcd
и пакет luci-app-splify2 (или страница LuCI). И даже тогда вкладка не
закрывается, пока правила ядра steer написаны панелью.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WpV96wH7hUvwFR2a63mWT9
Устройство туннеля ядро 2.0 создаёт сразу, до выбора узла и рукопожатия: единственная попытка
curl попадала в «подключаемся», и после «Применить» рабочий туннель объявлялся мёртвым — ядро
пускало сервисы напрямую до прохода сторожа. Теперь ожидание up из steer status (до 90 с) и
три попытки трафика; причина отказа — словами.
v2.16
Committed-by: agy-cli (autonomous, run 96)
Строка cron автоперезапуска зовёт backend.sh, поэтому удаление панели
снимает её вместе с остальными строками панели: без панели ей нечего
звать. Раньше строка звала init-скрипт steer напрямую и переживала
удаление, а теперь после новой установки панели автоперезапуск молча
пропадал, хотя Steer и его настройки остались.
Выбранный режим теперь хранится в /etc/zm-steer/autorestart.
Установщик панели через steer_action sync возвращает строку, если Steer
стоит, а строки нет. «Выкл.» файл убирает, удаление Steer — вместе с
каталогом.
Committed-by: agy-cli (autonomous, run #96)
Установщик панели в конце зовёт steer_action sync, и оттуда же
запускался подъём ядра 1.x до 2.x. Это фоновая задача, а родитель у неё —
установщик, то есть ssh или терминал. Закрыли окно — задачу могло
убить между снятием прежнего ядра и установкой нового (opkg), и роутер
остался бы без ядра. Ещё она спорила с самим установщиком за менеджер
пакетов: следом он ставит curl и unzip.
Теперь sync только обновляет строку cron и перечитывает правила, а ядро
поднимает сторож cron в пределах двух минут или открытая страница Steer.
Committed-by: agy-cli (autonomous, run #96)
ctl check, apply --dry-run и steer apply шли без срока. Если демон
зависнет, вместе с ним зависла бы задача панели, а следом все
операции Steer. Теперь проверка ограничена 150 с (демон сам ждёт
проверку до 120 с), применение — 300 с. Если срок вышел, это
отказ: спека возвращается прежняя, как при любом отказе.
Committed-by: agy-cli (autonomous, run #96)
steer-extended 2.x — пустой пакет, который тянет steer-core и модули ровно
своей версии. Если он стоит, apk отказывался ставить новое ядро: прежний
метапакет требует прежний steer-core. Теперь при обновлении ядра 2.x
метапакет ставится той же версии вместе с ядром и модулями. Чьим
он был, тем и остаётся.
Committed-by: agy-cli (autonomous, run #96)
Чужие правила в /etc/steer/spec.json искались построчно, а у спеки, где
«"rules": [» и первое правило стоят на разных строках (так её пишут
splify2 и человек руками), совпадения не было. Такая спека считалась
пустой, и Zapret Manager переписал бы её своей. Теперь спека
читается целиком.
Committed-by: agy-cli (autonomous, run #96)
Сверка версии поднимала ядро 1.x до 2.x по одной отметке «engine», а её
Zapret Manager ставит и тогда, когда steer-extended уже стоял и ставил его
человек. Теперь сам поднимается только пакет, который ставил Zapret
Manager (pkg steer, pkg steer-extended). Своё ядро человек поднимает кнопкой
«Обновить» или при «Применить».
Пока идёт другая операция панели, подъём ждёт: она могла занять менеджер
пакетов, и установка 2.x сорвалась бы на чужой блокировке.
Committed-by: agy-cli (autonomous, run #96)
Где Zapret Manager сверяет ядро — страница Steer, главная панель, проверка
версий, сторож cron раз в две минуты и обновление панели, — ядро 1.x,
поставленное Zapret Manager, поднимается до 2.x отдельной задачей, без
«Применить» и кнопки. Состояние службы сохраняется, после подъёма настройка
переписывается спекой v2.
- 2.x не поставить (нет выпуска, нет сети) — работающее 1.x не трогается,
повтор при следующей сверке, не чаще раза в 10 минут; на странице —
«ядро нужно обновить».
- opkg: перед снятием прежнего пакета скачивается его файл для возврата;
нет файла — прежнее ядро не снимается, новое не встало — прежнее
ставится обратно.
- Чужое ядро (ставил не Zapret Manager, чужая спека, splify2, коннектор)
не трогается.
Committed-by: agy-cli (autonomous, run #96)
Весь разговор с ядром steer — в одном блоке функций stl_* (слой steer):
бекенд отдаёт ему свою модель (выход WARP или VPN, сервисы и их списки,
подписка с узлом и маркерами) и спрашивает состояние на своём языке, а слой
пишет спеку v2 в /etc/steer/spec.json и зовёт клиент steer, который отдаёт
команды демону steerd.
- Ядро: steer-core и только нужные модули (VLESS — когда есть подписка)
вместо steer-extended; версия — stable 2.x из splify2/releases
(version.json, с проверкой sha256), не ниже 2.0.0. Переход с 1.x:
apk — одной транзакцией, opkg — снятием прежнего пакета; спека остаётся.
Удаляются только пакеты, которые ставил Zapret Manager.
- Применение: проверка демоном (ctl check), затем steer apply через демона —
он сам трогает только изменившееся. Убраны костыли 1.5.9: srs-read и
перевод .srs в текст, сумма спеки и сверка outputs, выбор между reload и
restart, перезапуск при fail-open, kmod-tun руками, чтение набора nft.
- WARP — группа pick: latency из туннелей (один туннель — выход-устройство),
без IPv6, как и прежде. VPN — tunnel vless: маркеры узлов уходят в
exclude_name, скрытые и закреплённый узел — в nodes без предела 16.
- Состояние — из steer status (failed, device, probe), diag и explain — через
слой. Блокер: ядро ведёт steer-box-connector (podkop, forkop) или чужая
спека v1/v2/yaml.
- Прежняя спека ZM (v1) ядро 2.0 читает как есть; при первом применении
слой пишет её заново в v2. Автоперезапуск по cron и обновление панели
идут через backend.sh.
- Фронтенд: три подсказки про steer-extended переписаны под ядро 2.0.
- docs/autobypass: перестановка туннелей рвёт соединения сменой туннеля, а
не перезапуском ядра.
Committed-by: agy-cli (autonomous, run #96)
Zapret Manager 1.96 — исправления
- Исправлена ошибка «Object not found» после обновления (LuCI: «RPC call to zapret-manager/status failed with error -32000», Web UI: «Роутер не отвечает: Object not found»).
- Установщик теперь проверяет, что rpcd подхватил панель и новый список методов, и при необходимости сам перезапускает rpcd.
- Сторож (раз в 2 минуты) следит не только за входом в LuCI, но и за самой панелью: если rpcd её потерял, он перезапускает rpcd.
- LuCI и Web UI при «Object not found» больше не показывают ошибку сразу, а повторяют запрос несколько секунд, пока rpcd запускается.
- После обновления больше не нужно сбрасывать кэш браузера: панель сама замечает новую сборку, обновляет свои файлы в кэше и один раз перезагружает страницу.
- Файлы панели при обновлении заменяются целиком за один шаг — открытая страница больше не может запустить наполовину записанный скрипт.
- На странице входа Web UI вместо «Object not found» выводится понятное сообщение, что rpcd ещё запускается.
- Версия движка Steer — 1.5.8: таблица правил заменяется одним действием, при упавших
туннелях трафик каналов идёт через zapret. Запасная версия tgws — 0.3.1.
- Установленный движок раньше не обновлялся никогда: при «уже установлен» установка
выходила сразу. Теперь движок, который поставил Zapret Manager, обновляется до его
версии — при установке Steer и в начале автообхода. Чужой движок (splify2) не трогается.
Работающий Steer после обновления перезапускается, а не выключается.
Сторож DNS для ИИ-сервисов шёл задачей redbtn: затирал журнал последнего автообхода и выглядел
на странице идущим автообходом. Теперь у него своя задача redbtn_geo; автообход и кнопка
«Подобрать DNS заново» ждут его, «Выключить» просит повторить. После неудачного подбора резолвер
снимался, и сторож молчал навсегда при живой строке cron — теперь пробует снова раз в два часа,
а если пакет удалён или zm-geodns выключен в автозапуске, снимает свою строку сам. Подбор
резолвера — не больше RB_PARALLEL проб разом.
Удаление панели зовёт redbtn_panel_gone: служба zm-geodns, её файл dnsmasq и строка cron
снимаются. Steer, туннели и warp.lst моста остаются — они переживают удаление панели намеренно.
Замер стратегий: цели внешнего набора без схемы идут по https://, а не по HTTP на 80-й; 451 и
000 — отказ, как в _rb_check_one; файл исключений качается, только если его нет или он пуст.
Мёртвое: запись «pkg tgws» в owned, geoblock.lst в установщике, состояние off и ветка для
снятых в Steer сервисов, до которой подбор не доходил.
warp.up писался в порядке номеров туннелей, хотя комментарий обещал «лучший первым», а порядок
читают все, кому нужен один туннель: _st_warp_first, мост Telegram (warp.lst — первый живой) и
движок (devices в spec решают ничьи в пределах допуска prefer: latency). Разведка теперь отдаёт
ключ качества (разряд запаса, потери, круг), и _st_warp_order ставит туннели по нему. Если ни
один туннель не разведан заново, порядок прежний: перестановка по дрожанию пинга меняла бы spec
и перезапускала движок на каждом «Применить».
Второй найденный порт из warp.ports стал запасным: не дала точка рукопожатия при окончательной
привязке — тот же адрес пробуется на нём, прежде чем туннель сдаётся.
_st_warp_handshake, _st_warp_hs_epoch и _st_warp_colo нигде не вызывались — убраны.
StressOzz