Управляющий сокет steer (протокол версии 1)#

steerd daemon — демон ядра: долгоживущий сервер, который держит спеку в памяти, сторожит выходы, держит помощников и резолвер и отвечает на запросы по unix-сокету. steerd ctl-serve — синоним steerd daemon. Сокет сделан для Android: приложению splify2 (домен SELinux splify2_app) политика не даёт ни исполнить ядро, ни прочитать его файлы, и единственная дверь к ядру — этот сокет. И на роутере, и на телефоне демон — сама служба: один steerd daemon --watch --supervise --apply (на роутере его держит /etc/init.d/steer, на телефоне — служба steerd в init/steerd.rc у vendor/der), а rpcd splify2 и все, кто зовёт steer <команда>, говорят с ним через клиент steer (ниже, «Клиент steer»).

Код — src/daemon/ctl.c (в шапке те же правила с доводами), цикл событий — src/daemon/loop.c, состояние в памяти — src/daemon/state.c, сторож выходов (--watch) — src/daemon/watchd.c, помощники и резолвер (--supervise) — src/daemon/supd.c и src/daemon/helpers.c; стенды — tests/ctlmatch.sh, tests/supdmatch.sh.

Где сокет и кто его создаёт#

Почему не опция socket у init (/dev/socket/…): каталог /dev/socket может листать любой домен (domain.te: allow domain socket_device:dir r_dir_perms), и имя сокета увидело бы любое приложение. /data/misc/steer приложениям не листается.

Кого пускают#

1. SELinux: connectto к домену steerd разрешён splify2_app (и su на userdebug).
2. Сервер по SO_PEERCRED/SO_PEERSEC:
   • uid 0 (root) и 1000 (system) — всегда;
   • процесс в домене splify2_app (флаг --allow-domain, по умолчанию в сборке под Android), если он у владельца устройства — uid меньше 100000, то есть пользователь 0;
   • uid, названные --allow-uid N (до восьми; стенд и отладка).

UID приложения нигде не записан: сервер спрашивает у ядра контекст SELinux собеседника, а домен splify2_app назначается только пакету com.der.splify2 с платформенной подписью (seapp_contexts). Остальным — ответ denied и строка steer[warn] ctl: отказ: … в журнале.

Запрос#

Одно соединение — один запрос и один ответ; после ответа сервер закрывает соединение. Исключение одно — subscribe (ниже): после ответа соединение остаётся открытым и несёт события.

• Строка ASCII до 512 байт с \n в конце: имя команды и слова через один пробел.
• У команд с телом (apply, check, put-file, sub-check) последнее слово — длина тела в байтах, десятичным числом, и сразу за \n идут ровно эти байты. Тело спеки (apply, check) — не больше 1 МиБ, тело файла (put-file, sub-check) — не больше 16 МиБ.
• На весь запрос (строка и тело) — 5 секунд.
• Слова проверяются по виду до запуска: имя выхода — [A-Za-z0-9_.-], до 31 знака; адрес или имя у explain — ещё : и /, до 253 знаков; ни одно не может начинаться с - или .. Имя файла списка (put-file, rm-file) — [A-Za-z0-9_.-], до 64 знаков, не с - и не с ., без .. где угодно.

status\n
explain youtube.com\n
vless-probe loc 2 5\n
apply 1834\n{"schema":2, ...}
put-file yt.lst 52311\n<байты списка>

Ответ#

Один объект JSON в одну строку с \n в конце. Читать до \n, а не до закрытия.

{"v":1,"cmd":"status","code":0,"stdout":"{\"schema\":1,...}\n","stderr":""}

Значения error:

Команды#

«Где» — как демон исполняет команду: в процессе — сам, из спеки в памяти, тем же кодом, что печатает одноимённая подкоманда (ответ байт в байт тот же, что дала бы подкоманда по той же спеке); ребёнок — запуском подкоманды ядра, не останавливая остальных запросов. Срок есть только у детей: по нему ребёнок и всё, что он запустил, убиваются, а ответ — timeout.

Детям демон сам добавляет --spec и --state-dir — те, с которыми запущен.

Спека в памяти. Демон читает спеку при старте и перечитывает после apply, reload и по SIGHUP. status и explain отвечают по ней, а всё, что меняется без спеки (/sys, счётчики nft, реестр меток), читают на каждый вызов. Устройство, выбранное сторожем, status берёт из памяти демона, если сторож — сам демон (--watch, ниже), и из файла active, если сторожит steer failover --loop. Спеку, заменённую в файле руками, демон увидит после reload. Не прочиталась при старте — status и explain отвечают тем же отказом, что подкоманда (код 2, причина в stderr); не прочиталась при перечитывании — демон продолжает отвечать по последней годной и шлёт подписчикам spec-error.

apply#

1. Спека во временный файл рядом с spec.json и план по нему (служебная подкоманда apply-plan): те же проверки и предупреждения, что у apply --dry-run, и отпечатки частей. Отказ — spec.json не тронут: "saved":false,"applied":false, в stderr — причина.
2. Кандидат становится spec.json переименованием (снаружи виден либо прежний файл, либо новый).
3. Ядро выключено (свойство persist.der.steer.enabled не 1) — на этом всё: "saved":true,"applied":false,"enabled":false. Правила поставит init, когда ядро включат.
4. Сверка с применённым (ниже) и применение только изменившихся частей (служебная подкоманда apply-commit); не изменилось ничего — в ядро демон не идёт вовсе. Отказ ядра (план ядро не спрашивает) — прежняя спека возвращается: "saved":false,"applied":false,"rolled_back":true.
5. Успех — как reload: "saved":true,"applied":true,"enabled":true,"reload":{…},"changed":{…}.

{"v":1,"cmd":"apply","code":0,"stdout":"steer: applied 2 channel(s), 2 output(s)\n","stderr":"",
 "saved":true,"applied":true,"enabled":true,"reload":{"dnsd":"table","outputs":"daemon"},
 "changed":{"ruleset":false,"routing":[],"helpers":["b"],"dnsd":false}}

Сверка по частям. Демон помнит, что применил сам, и сравнивает с этим новую спеку, а то, что применил, — с тем, что сейчас стоит в ядре:

Не изменилось ничего и в ядре всё на месте — nft и ip не запускаются, наборы (и адреса, которые в них положил резолвер), счётчики, помощники и резолвер остаются как были. Новые поддельные адреса, которые резолвер выдал после прошлого применения, изменением не считаются: в карту fake-IP и наборы каналов их кладёт сам резолвер, а при замене набора правил и карта, и наборы каналов fake-IP приходят заполненными всей раздачей на момент замены.

Порядок применения — у apply-commit тот же, что у подкоманды steer apply (и у применения при старте, и у reapply из init без демона):

1. устройства выходов kind=awg, затем правила fwmark и таблицы выходов (у выхода без устройства — то, что ставит его on_fail: запрет при drop, пустая таблица при direct и zapret). До набора правил — чтобы метка выхода ни мгновения не существовала без своего правила: помеченный пакет без правила уходит по таблице main, то есть в WAN. Правило без меток ничего не ловит и безвредно;
2. набор правил одной транзакцией nft -f. Карта подмены fake-IP и наборы каналов fake-IP засеяны в том же тексте из файла состояния резолвера (fakeip.state): подмена поддельного адреса появляется в ядре только вместе с его меткой, а поддельный адрес без подмены отбрасывается правилом steer-fakeip-nomap за dnat и никуда не уходит. Прямо перед засевом загрузчик просит резолвер этого каталога состояния записать файл (просьба flush по dnsd-ctl.sock, ответ — после записи, ждётся до 1 с): сам резолвер переписывает его не чаще раза в минуту, и без просьбы засев отставал бы от его памяти — новые имена без подмены, сменившиеся адреса прежними. Таблицу от демона резолвер сверяет с картой ядра по своей памяти и ставит свой адрес там, где засев оказался другим;
3. сразу после загрузки — просьба резолверу вернуть элементы real-ip из его памяти (в тексте они не засеваются: память о них только у резолвера), отметки «пущен напрямую» по таблицам выходов, карта раздачи balance — к живым членам;
4. снятие правил и таблиц меток, которых больше не несёт ни один выход, — только после удачной загрузки: до неё ими метит прежний набор правил;
5. (демон, после удачной загрузки нового набора правил) снятие соединений правил, у которых сменился выход, — ниже.

Смена выхода правила. Метка выхода пишется и в метку соединения, и по ней группа balance держит установленное соединение на том члене, где оно началось. Правило перевели на другой выход — и без снятия его установленные соединения жили бы на прежнем выходе (а у группы balance, в которой прежний выход — член, — до самого конца), а новые шли бы новым путём: один сеанс сайта с разных внешних адресов. Поэтому после загрузки демон сравнивает правила прежней и новой спеки (по имени, без имени — по номеру) и для каждого изменившегося — выход другой, правило снято или выключено — снимает записи conntrack с метками его прежнего выхода (у группы balance — и с метками её членов):

• метку не держит ни одно правило, у которого выход не менялся, — сняты все записи с ней;
• держит — сняты только записи, чьё назначение (у fake-IP — поддельный адрес) не лежит ни в одном наборе групп, ведущих в выход с этой меткой, после загрузки; есть такая группа без набора («весь трафик») или набор не прочитать — сняты все записи с меткой.

Следующий пакет снятого соединения заводит запись заново по новым правилам и идёт новым путём, сервер отвечает сбросом, и приложение соединяется заново уже через новый выход (у QUIC — когда браузер бросит прежнее соединение). В журнале демона — steer[info] ctl: смена выхода правил (p → all): снято соединений метки 0x00400000 — 29 (целиком). Привязка выхода сторожем к другому устройству (тот же выход, другое устройство) снимает соединения своим путём — «Сторож выходов».

Если ядро отвергнет набор правил, прежний остаётся стоять, а привязка выходов (шаг 1) уже новая: правила новых меток безвредны, сменённое устройство выхода несёт трафик прежнего набора правил того же выхода.

Сверка с ядром. apply и reload с той же спекой — это и починка: то, что в ядре изменили снаружи, они возвращают, а не отвечают «менять нечего». Спрашивается ядро по netlink, в процессе демона (элементы наборов — в ребёнке-плане), без запуска nft и ip:

• набор правил — снятое или изменённое правило, снятая или добавленная цепочка, чужой набор в нашей таблице: набор ставится заново одной транзакцией (changed.ruleset), в журнале демона — steer[warn] ctl: набор правил в ядре изменён снаружи … — ставлю набор правил заново. Адреса, которые клал в наборы резолвер, после замены на месте: постоянные элементы fake-IP приходят в самом наборе правил (засев из файла состояния), элементы real-ip с оставшимся сроком резолвер возвращает по просьбе загрузчика сразу после nft -f и ещё раз по таблице (резолверу уходит таблица и неизменной);
• элементы статических наборов — адреса и подсети списков и .srs, которые целиком ставит набор правил: снятый руками или добавленный чужой адрес — набор ставится заново так же, в журнале — steer[warn] ctl: элементы статических наборов в ядре не те, что ставило ядро steer (в ядре N, после загрузки было M) — ставлю набор правил заново. Сверяется сводка элементов (хэш, не зависящий от порядка), снятая сразу после nft -f, против сводки ядра, которую снимает план (ребёнок демона, не сам демон). Не сверяются: карты (fake-IP, раздача balance), набор «пущен напрямую» и в доменных наборах — адреса, которые кладёт резолвер (со сроком — real-ip, без срока из пула fake-IP — поддельные); подсети списка, которые лежат в доменном наборе выхода (у выхода есть и адресный, и доменный канал), сверяются — по началу диапазона. Стоит это дампа всех элементов — на больших списках роутера это секунды на каждый apply и reload, — поэтому на проходе сторожа элементы не сверяются;
• цепочка разметки на ingress (ingress_mark, docs/contract-v1.md, §7): её устройства входят в отпечаток, и устройство раздачи, которое пересоздали (ядро вынимает его из цепочки, последнее — вместе с цепочкой), — это расхождение, после которого набор ставится заново уже на новое устройство: ближайшим проходом сторожа или apply/reload. Устройство раздачи, которого не было при прошлом применении, меняет сам текст правил и попадает в цепочку тем же apply или reload. До них пакеты с такого устройства размечает prerouting_mark;
• правило fwmark и таблица выхода — у выхода, который сторож считает работающим, правило должно стоять, а таблица — вести в одно из его устройств (или, если устройств нет, стоять так, как ставит on_fail): иначе выход привязывается заново (changed.routing), в журнале — steer[warn] ctl: выход … — привязываю заново. У выхода в отказе маршрутизацию возвращает проход сторожа (… — сторожу внеочередной проход).

После любого найденного расхождения сторожу — внеочередной проход (с --watch).

На каждом проходе сторожа (с --watch) набор правил сверяется с ядром и без apply: перед проходом демон сравнивает номер своей таблицы и отпечаток её цепочек, правил и заголовков наборов с тем, что стояло сразу после его последнего nft -f, — четыре запроса по netlink, без процессов и без элементов наборов (элементы — только на apply и reload). Разошлось — в журнале steer[warn] ctl: проход сторожа: набор правил в ядре разошёлся с поставленным (…) — сверка в очереди, и демон ставит в очередь изменяющих команд reload — тот же, что пришёл бы по сокету: набор правил встаёт заново одной транзакцией, адреса резолвера возвращаются, итог — строкой steer[info] ctl: набор правил сверен с ядром проходом сторожа — поставлен заново, подписчикам — applied с by: "watch". Проход ждёт конца починки, как любой изменяющей команды.

• Расхождение — снятое, изменённое или добавленное правило, цепочка или набор в любой из наших таблиц (в раскладке старого ядра — и в ip/ip6), и таблица, которую заменили мимо демона (steerd apply без сокета, скрипт): у неё другой номер.
• Своя замена набора правил, которая идёт сейчас (apply, reload, починка), расхождением не бывает: проход не начинается, пока идёт изменяющая команда, а новое ожидаемое демон запоминает до её конца.
• Таблицы нет вовсе (steer down) — не чинится: ядро сняли нарочно.
• Не больше трёх починок за пять минут: то, что правит нашу таблицу без остановки, не превращает каждый проход в компиляцию. Отказ по лимиту — строка в журнал, одна на окно: steer[warn] ctl: проход сторожа: набор правил в ядре разошёлся с поставленным (…), но починок по сверке уже 3 за 5 мин — следующая через N с. Расхождение после того, как устройство раздачи пропало или появилось, а плана с тех пор не было (цепочку ingress_mark ядро снимает вместе с устройством), в счёт трёх не идёт: у него свой предел — двадцать сверок по устройствам раздачи за пять минут (см. «Страж правил выходов», «Устройства раздачи»), в журнале — … разошёлся с поставленным (…) после пересоздания устройства раздачи — сверка в очереди.
• Починка применяет спеку, которая на диске, — как reload.
• Демон перезапущен и ещё ничего не применял сам (без --apply) — сверять не с чем, до первого apply или reload.

После перезапуска демона применённое ему неизвестно, и первый apply или reload применяет всё, как подкоманда steer apply. Так же — после выключения ядра, после отказа применения и когда нашу таблицу в ядре сменил или снял кто-то другой (steer down, steer apply из init).

changed — что тронуто:

При отказе ("saved":false) поля changed нет: в ядре остаётся прежнее.

Команды apply, check, reload и rm-file идут по одной: следующая ждёт в очереди демона, пока не кончится предыдущая (check спеку не трогает, но dry-run раздаёт выходам метки в реестре состояния). Остальные команды, в том числе status, отвечают и пока идёт apply: проверка и компиляция идут в детях демона, а не в нём самом.

После шагов 3 и 5 демон перечитывает спеку в память и шлёт подписчикам applied.

reload#

{"v":1,"cmd":"reload","code":0,"enabled":true,"reload":{"dnsd":"hup","outputs":"hup"},
 "changed":{"ruleset":false,"routing":[],"helpers":[],"dnsd":false}}

При включённом ядре steer reload сверяет спеку на диске с применённой, а применённое — с ядром, и применяет изменившееся и разошедшееся — так же, как apply (выше, «Сверка с ядром»), только без новой спеки и без отката: спека на диске остаётся той же. code не 0 — спека не прошла проверку или ядро не приняло набор правил; причина — в stderr, в ядре остаётся прежнее, а остальное (reload, перечитывание) делается как обычно. При выключенном ядре steer в ядро Linux reload не идёт.

• dnsd: hup — подпись доменных каналов (steer dnsd-sig) совпала с той, что резолвер записал при запуске, и ему послан SIGHUP (списки перечитаны без потери запросов); restart — не совпала, послан SIGTERM, init поднимет сервис заново; none — резолвер не запущен.
• outputs: hup — супервизору помощников (steer supervise) послан SIGHUP: новые выходы поднимаются, убранные гасятся, у выходов с изменёнными параметрами (узел подписки, сервер обфускации, файл xsteer, домен tgws, файл стратегии zapret или его содержимое) помощник перезапускается сразу; none — не запущен.

С --supervise (ниже) резолвер и помощники — дети демона, и поле другое: "reload":{"dnsd":"table","outputs":"daemon"} — демон перечитал спеку, написал резолверу новую таблицу и сам сверил помощников; сигналов процессам по /proc он в этом режиме не шлёт.

Сам демон перечитывает спеку в память и шлёт подписчикам applied (или spec-error, если она не прочиталась). Сторожу сигнал не нужен: failover --loop читает спеку заново на каждом проходе, а сторож демона (--watch) после перечитывания спеки делает внеочередной проход, если изменились выходы или помощники.

conns#

Ответ — как у любой подкоманды: code и stdout, в stdout — объект JSON (разбирать второй раз).

{"schema":1,
 "conns":[
   {"family":"ipv4","proto":"tcp","src":"10.0.0.5","sport":40312,"dst":"142.250.74.14","dport":443,
    "mark":"0x00400000","out":"vpn","state":"established",
    "packets":12,"bytes":2310,"reply_packets":10,"reply_bytes":8812},
   {"family":"ipv6","proto":"udp","src":"2a00:…","sport":51000,"dst":"2a00:…","dport":443,
    "mark":"0x00800000","out":null}
 ],
 "shown":2,"total":2,"truncated":false}

Что попадает: записи conntrack обоих семейств, у которых поле метки ядра steer не ноль. Собственный трафик ядра (запросы резолвера наверх, значение поля «все биты» на телефоне) не показывается. UID приложения в ответе нет: conntrack его не хранит. code 1 — conntrack недоступен (нет модуля nf_conntrack_netlink или прав), причина в stderr, stdout пуст.

dns-log#

stdout — объект JSON:

{"schema":1,"running":true,"size":256,
 "names":[
   {"name":"youtube.com","channel":"YouTube","out":"vpn","count":14,"last":1790272505,"ago":3},
   {"name":"example.org","channel":null,"out":null,"count":1,"last":1790272410,"ago":98}
 ]}

Журнал живёт только в памяти резолвера: на диск не пишется ни периодически, ни по запросу, и перезапуск резолвера (смена состава доменных каналов, выключение ядра) его обнуляет. Кто спрашивал и что ответили, в журнале нет. Резолвер отдаёт журнал через свой сокет <каталог состояния>/dnsd.sock (права 0600, только домен ядра); приложению он виден только через dns-log управляющего сокета.

put-file, list-files, rm-file#

Файлы, на которые ссылается спека (domains_files, prefixes_files, файл подписки), приложение заливает в каталог ядра через сокет: писать туда само оно не может (SELinux). В спеку пишется путь из ответа put-file. Спека с путями вне этого каталога по-прежнему законна — каталог лишь место, куда может писать приложение.

put-file yt.lst 52311\n<52311 байт>

{"v":1,"cmd":"put-file","code":0,"name":"yt.lst","size":52311,"path":"/data/misc/steer/lists/yt.lst"}

• Файл кладётся атомарно: во временный файл того же каталога, fsync, переименование. Резолвер и apply видят либо прежний файл целиком, либо новый целиком. Существующее имя заменяется.
• Каталог создаётся при первом put-file с правами 0700. Пределы: файл — 16 МиБ, каталог — 4096 файлов и 128 МиБ всего (too-large с числом; замена существующего имени при 4096 файлах разрешена).
• Слишком большое тело сервер отвергает, не читая: мост должен проверить размер до отправки, иначе запись тела может оборваться ошибкой (ответ too-large при этом всё равно в сокете).
• Замена файла, на который уже ссылается применённая спека, сама ничего не меняет в работе ядра: подсети из списков стоят в наборах nft, собранных при apply, а доменные правила резолвер перечитывает по сигналу. Поэтому после заливки обновлённых списков — apply той же спеки: он пересоберёт наборы и сам перечитает списки резолвером (как reload). Одного reload хватает только для доменных строк.

list-files\n

{"v":1,"cmd":"list-files","code":0,"dir":"/data/misc/steer/lists",
 "files":[{"name":"yt.lst","size":52311,"mtime":1790272515}]}

По имени; mtime — секунды Unix (время последнего put-file этого имени). Каталога ещё нет — "files":[].

rm-file yt.lst\n

{"v":1,"cmd":"rm-file","code":0,"name":"yt.lst","removed":true}

removed:false — такого файла не было (повторное удаление не ошибка). Файл, путь которого ("<каталог>/<имя>" строкой JSON) есть в сохранённой спеке, не удаляется: ответ {"error":"in-use",…}. Порядок у приложения поэтому такой: собрать спеку без списка, apply (при выключенном ядре он спеку только сохраняет — этого достаточно), затем rm-file.

sub-check#

sub-check 20480\n<20480 байт подписки>

Ответ — как у подкоманды vless-nodes с путём файла: code и stdout с объектом JSON. Приложению нужны из него usable (пригодных узлов), skipped (непригодных ссылок vless://), foreign (ссылок чужих протоколов), nodes (пригодные узлы: index, name, host, port, type, security, …) и skipped_reasons ([{"reason","count","example"}], плюс skipped_other, если причин больше, чем влезло). Поля output, sub_file, node, chosen здесь ничего не значат: sub_file — имя временного файла, удалённого сразу после разбора.

{"v":1,"cmd":"sub-check","code":0,"stdout":"{\"output\":\"\",\"sub_file\":\"/data/misc/steer/tmp/sub-check.ctl-aARWzB\",\"node\":-1,\"chosen\":[],\"usable\":1,\"skipped\":1,\"foreign\":1,\"nodes\":[…],\"skipped_reasons\":[{\"reason\":\"tls по адресу без sni: нечем сверить\",\"count\":1,\"example\":\"wsnode\"}]}\n","stderr":""}

Разбор — тот же vless_parse_sub, которым узлы потом поднимаются. В базовой сборке (без VLESS) code 2 и отказ в stderr, как у vless-nodes.

subscribe#

subscribe\n

{"v":1,"cmd":"subscribe","code":0,"spec":"9c1f4e0a7b2d3e61"}
{"v":1,"ev":"applied","by":"apply","spec":"5a0e2f9d4c7b1e38","enabled":true,"changed":{"ruleset":true,"routing":["vpn"],"helpers":[],"dnsd":false}}
{"v":1,"ev":"spec-error","by":"reload","message":"spec: нет закрывающей скобки — файл оборван?"}

Первая строка — ответ на сам запрос: spec — отпечаток спеки, с которой демон работает сейчас (нет поля — спека не прочитана). Дальше соединение не закрывается, и демон пишет в него события: одна строка JSON на событие, \n в конце, у каждой "v":1 и имя в ev. Читать построчно; события неизвестного имени и неизвестные поля — пропускать: список будет расти в той же версии протокола.

why у switched:

select#

select eu nl\n

{"v":1,"cmd":"select","code":0,"stdout":"steer: группа eu — выбран nl (vl-nl)\n","stderr":""}

Группа pick: manual (docs/spec-v2.md) отдаёт трафик члену, выбранному этой командой; до первой команды — default группы. Apply не нужен: демон сразу переписывает маршрут таблицы группы на лист члена (устройство, которое сейчас несёт трафик члена, у вложенной группы — её текущее), как сторож при переключении, и шлёт подписчикам switched с by: "select". Идущий проход сторожа при этом прерывается (его решения легли бы поверх выбора) и повторяется через несколько секунд.

Выбор хранится в файле select рядом со спекой (/etc/steer/select на роутере — файл объявлен в keep.d и переживает и обновление прошивки; /data/misc/steer/select на телефоне), а не в каталоге состояния: тот на роутере — tmpfs. Пишется только при изменении выбора, заменой через временный файл с fsync, и переживает перезапуск демона и перезагрузку. Выбор, оставшийся от прежнего ядра в каталоге состояния, читается оттуда, пока файла рядом со спекой нет.

Если выбранный член не работает (по последнему приговору сторожа), группа НЕ переходит на другой член — manual значит выбор человека: применяется on_fail группы (drop — трафик группы стоит, direct — идёт напрямую), подписчикам — failed с by: "select", в stdout — об этом прямо. Когда член поднимется, сторож вернёт группу на него сам (switched, why: "select").

Так же и при запуске: после перезапуска и перезагрузки стартовый apply сразу ставит таблицу группы на лист выбранного члена (выбор — из файла select, даже если его сменили, пока демон стоял), а если у члена нет устройства или последний приговор сторожа — «не работает», сразу ставит on_fail группы, не дожидаясь первого прохода.

Отказы — code 2 и причина в stderr: группы нет, у группы не pick: manual, член не из группы. При выключенном ядре выбор только запоминается. Клиент steer select <группа> <член> шлёт команду демону, а без демона тот же выбор делает само ядро (память сторожа — файлы каталога состояния).

helper#

helper xa\n

{"v":1,"cmd":"helper","code":0,"stdout":"{\"schema\":1,\"out\":\"xa\",\"helper\":\"xsteer\",\"running\":true,\"up\":true,\"since\":1790000000,\"started\":1789999990,\"restarts\":0}\n","stderr":""}

Что демон с --supervise знает о помощниках выхода по их событиям — строка JSON на помощника: running (процесс есть), up (последнее событие — up), since (когда up сменилось, секунды Unix; 0 — ни разу), started, restarts (перезапусков с подъёма демона), last_down — причина последнего отказа (поля нет — отказа не было); у vless ещё node и total (перебор узлов или номер вне подписки) и active — номера активных живых узлов пула ([3,7], номера среди пригодных, как у steer vless-nodes; [] — живых нет; поля нет — клиент ещё не сказал), у tgws — paths_down (отставленные пути, как в status). Если помощник — бинарник модуля (steer-vless, steer-xsteer, steer-obfs, steer-tgws), ещё module (имя бинарника), module_ver (версия из его hello, если он представился) и rejected: true, если демон его отверг: чужая версия, первое сообщение не hello, hello без версии; причина — в last_down («модуль steer-vless версии 1.9.0, а ядро 1.10.0 — обновите пакеты steer вместе»). Бинарника модуля нет — last_down «нужен пакет steer-<имя>», running ложно. Счётчиков и рукопожатия клиента xsteer здесь нет: он сообщает только смену состояния. Этим отвечает steer xsteer-peers <выход> у выхода под демоном — его клиент с трубой событий файла xsteer-<выход>.json не пишет. Помощника у выхода нет (демон без --supervise, вид без помощника) — code 1 и причина в stderr.

switched и failed приходят один раз — на перемене, а не на каждом проходе: пока выход в отказе или на том же устройстве, событий нет. События сторожа шлёт только демон с --watch; steer failover --loop — отдельный процесс, и о его переключениях подписчик не узнаёт. Так же и helper-up, helper-down, node, health: их шлёт только демон с --supervise, а помощник пишет событие только при смене состояния.

spec — FNV-1a 64 по байтам файла спеки, 16 шестнадцатеричных знаков: чтобы отличить «та же спека» от «другая», а не для проверки подлинности.

Что подписчик пишет после subscribe, демон читает и выбрасывает; полузакрытие записи с его стороны (как у steer ctl subscribe) — не уход. Уход — закрытие соединения. Подписчиков — не больше восьми (девятому — busy), и в четыре одновременных запроса они не входят. Очередь событий у каждого — 32 КиБ поверх буфера сокета: подписчик, который не забирает события, по переполнению отключается (в журнале демона — steer[warn] ctl: подписчик не забирает события), и остальным это не мешает. Отключённому — переподключиться и спросить status: пропущенные события не повторяются.

Из adb root shell: steer ctl subscribe печатает события по мере прихода.

Сторож выходов (--watch)#

steer daemon --watch — демон сам сторожит выходы: выбирает живое устройство пула, возвращается на предпочтительное, применяет on_fail, оживляет молчащие туннели и сверяет маршрутизацию выходов с ядром. Это тот же проход, что у steer failover (код один), только расписание и память между проходами — в демоне.

Не больше одного сторожа. Демон с --watch рядом с steer failover --loop — два сторожа, которые дерутся за одни и те же таблицы выходов и оживляют одни и те же устройства дважды. На роутере сторож один — демон (init.d/steer другого круга не держит, а hotplug шлёт демону SIGHUP вместо прохода steer failover); на телефоне тоже — служба steerd в init/steerd.rc. Сам демон второго сторожа не обнаруживает.

Проход идёт в самом демоне, на его цикле событий, без отдельного процесса: пока проход ждёт ответа пробы или подъёма туннеля, демон отвечает на запросы. Проход по здоровым выходам не запускает процессов; процесс появляется только на действие — перезапуск интерфейса (ifdown/ifup), сигнал помощнику, перепривязку таблицы. События switched, failed, revived уходят после конца прохода, когда status уже отвечает новым выбором. В тишине, когда выходы здоровы и событий нет, демон просыпается только по периоду. Строки прохода в журнале — те же, что у steer failover (steer[warn] failover: …).

Вместе с --supervise. Помощники — дети демона, и их состояние сторож берёт из памяти демона, а не из файлов:

• выход, чьё устройство создаёт наш процесс (туннели vless, hysteria2 и протоколов прокси, xsteer, и устройство такого выхода в пуле interface): помощник не запущен, сообщил down или ещё ничего не сообщил — устройство не живо, без пробы; сообщил up — дальше та же проверка, что и без супервизора (наличие устройства, мера вида);
• клиент vless (и протоколов прокси) сам следит за своими активными узлами (active выхода, docs/spec-v2.md, «Пул узлов туннеля»): проверяет каждый раз в interval (60 с) и сразу после трёх несостоявшихся подряд соединений с ним или обрыва живого соединения по порогу молчания (silence, 20 с); две неудачные проверки подряд — узел мёртв: его соединения клиент сбрасывает (RST) и ставит на его место следующий свободный кандидат по порядку предпочтения — сам, без выхода процесса. down с причиной (подписчику — helper-down) — только когда живых узлов не осталось; тогда круг проверок (сперва прежние узлы, потом свободные кандидаты, через 15 с, после каждого пустого круга вдвое дольше, до 5 мин), и первый ответивший — снова up (helper-up). Состав активных узлов клиент сообщает событием active, демон отдаёт его в helper (поле active). Его up устройство считается живым без пробы TCP (она узла и не мерила: SYN-ACK клиент отдаёт сам, до соединения с узлом); по down выход уходит в отказ или группа — на другого члена, внеочередным проходом, а оживления (ожидания в проходе) нет — выход вернёт проход по up клиента. Без супервизора событий слушать некому: клиент следит за узлами и заменяет их так же, а сторожу у vless остаётся проба TCP;
• перебор узлов подписки (node) при оживлении — ожидание, а не отказ; номер узла вне подписки (nonode) — отказ с причиной в журнале, без ожидания;
• смена состояния помощника такого выхода (up, down, процесс вышел после up) — внеочередной проход через 5 с, как событие сети;
• обфускатор выхода interface, чьё устройство не отвечает, демон перезапускает сам: подписчику — helper-down с причиной «перезапуск: выход не отвечает» и helper-up после подъёма; ubus не зовётся. Дальше, как и без супервизора, ifdown/ifup интерфейса.

Туннель xsteer, поднятый netifd (устройство в пуле interface, а не выход kind: xsteer), — не ребёнок демона: его здоровье сторож и здесь читает из файла, который пишет его клиент.

Страж правил выходов (--watch)#

netd на телефоне при каждом (пере)запуске стирает все правила маршрутизации, кроме приоритета 0, и перестраивает iptables — вместе с ними пропадают правила выходов и masquerade. На роутере то же делает netifd на каждом своём старте (/etc/init.d/network restart) и чужой ip rule flush. Демон со --watch замечает это сам:

Устройства раздачи. Сторож читает и события устройств: у устройства из lan_devices появился новый номер (мост пересоздан — так делает netifd на network restart) — через 300 мс ставится сверка набора правил с ядром (reload без соединения, как у прохода), и цепочка ingress_mark возвращается на новое устройство, не дожидаясь прохода сторожа. В журнале — steer[info] ctl: устройство раздачи появилось заново — набор правил сверяется с ядром и … сверен с ядром по новому устройству раздачи — поставлен заново; подписчикам — applied с by: "watch". Такие сверки не идут в счёт «трёх за пять минут» у сверки прохода; у них свой предел — двадцать за пять минут, и строка в журнал, когда он исчерпан. Только на роутере и только там, где раскладка ставит ingress.

Помощники и резолвер (--supervise)#

steer daemon --supervise — демон сам держит процессы, которые нужны выходам и доменным каналам: помощников (steer vless, xsteer, obfs, tgws — по выходу; обработчик zapret steer-nfqws <очередь> <файл ключей>) и резолвер steer dnsd. Состав, порядок и перезапуск — тот же код, что у steer supervise (src/daemon/helpers.c).

Не больше одного супервизора. Демон с --supervise рядом с другим супервизором поднял бы второй экземпляр каждого помощника (второй обфускатор на том же порту, второй резолвер на 5300). На роутере супервизор один — демон; на телефоне тоже (служба steerd — steerd daemon --watch --supervise --apply в init/steerd.rc у vendor/der). Сам демон второго супервизора не обнаруживает.

status при --supervise меняется только добавлением: поле probe у выхода vless (перебор узлов, отказ, номер вне подписки) то же, что и без супервизора, только берётся из памяти демона; у выхода vless, чей клиент потерял узел, — node_down (причина и время, docs/contract-v1.md, §2), а diag говорит о нём «узел перестал отвечать» с той же причиной; у выхода моста tgws — paths_down, отставленные мостом пути (docs/contract-v1.md, §2). Остальное состояние помощников видно по событиям и команде helper.

status и diag, запущенные подкомандой мимо клиента (steerd status — так их зовёт rpcd), при живом демоне тех же спеки и каталога состояния спрашивают его (version, затем status или diag, как клиент) и печатают его ответ байт в байт: ход перебора узлов, замеры групп и состояние помощников есть только в его памяти. Демона нет, он чужой или не ответил за 10 с — подкоманда считает сама. status --fast демона не спрашивает (снимок на диске у них общий), а подкоманда, которую клиент steer отдал ядру, уже спросив демон (STEER_DAEMON_ASKED в окружении), не спрашивает его второй раз.

Применение при старте (--apply)#

steerd daemon --apply применяет спеку сам, сразу после старта, — тем же reload, что по сокету (сверка с применённым; после старта применённое неизвестно, поэтому применяется всё). Так одна служба и применяет спеку, и держит её: отдельного steer apply перед демоном не нужно. Идёт в очереди изменяющих команд: apply, пришедший по сокету сразу после старта, ждёт его, а сторож заводится придержанным: его первый проход — сразу после конца применения, удачного или нет (проход раньше видел бы ядро без правил и писал бы «маршрутизация разъехалась»). Итог — строкой в журнал демона (steer[info] ctl: спека применена при старте или steer[warn] ctl: применение при старте не прошло … с причиной). Спеки нет — применять нечего, демон всё равно слушает сокет. Выключенное ядро steer (телефон) — в ядро Linux не идёт, как reload.

С --watch демон ещё и раз в пять минут пересчитывает status — ради снимка status.json, который отдаёт status --fast. При выключенном ядре этого таймера нет, как и таймеров сторожа и стража правил.

Клиент steer#

steer — отдельный маленький бинарник (src/client/main.c), ядро — steerd рядом с ним. Команды, которые обслуживает демон, клиент посылает в сокет и печатает ответ так, чтобы вывод и код возврата были те же, что у одноимённой подкоманды ядра: stderr из ответа — в stderr, stdout — в stdout, выход с code. Остальное — и любую команду, когда демона нет, — клиент отдаёт ядру: execv файла steerd с теми же аргументами (включая argv[0]).

• Какой сокет. STEER_SOCKET, иначе путь платформы (/etc/steer/steer.sock на роутере, /data/misc/steer/steer.sock на телефоне). Платформа выбирается так же, как у ядра (--platform, STEER_PLATFORM, умолчание сборки, признаки среды).
• Тот ли демон. Перед командой клиент спрашивает version и сверяет spec_path и state_dir демона со своими (--spec, --state-dir или пути платформы; после realpath). Не совпали — команда идёт ядру: ответ про чужую спеку был бы неверным ответом.
• Какое ядро. STEER_ENGINE, иначе steerd в каталоге самого клиента.
• Слово, флаги. Вызов, который не укладывается в форму команды демона (незнакомый флаг, --help, лишнее слово, слово с пробелом), идёт ядру: оно и откажет своими словами.
• Отказы сервера. busy — клиент повторяет запрос до десяти секунд; denied, internal, bad-request и прочие отказы без code — команда идёт ядру (у reload и subscribe — отказ с кодом 3). timeout — печатается приложенный вывод, фраза сервера в stderr, код — из ответа. Обрезанный ответ (truncated) читающей команды повторяется ядром целиком.
• Выключенное ядро (телефон): steer apply через демон только сохраняет спеку — клиент добавляет строку об этом в stderr, код 0.

steer-tools — ссылка на steerd: под этим именем ядро отвечает только на инструменты (fit, srs-read, obfs-server, sub-fetch, sub-quota, sub-hwid, dev-id, tls-probe, tgws-probe, vless-nodes, xsteer-key, xsteer-link, xsteer-check, xsteer-hub, dnsd-table), а на остальное — отказом с кодом 2.

Включение и выключение#

Выключатель — свойство persist.der.steer.enabled, и ставит его само приложение (SystemProperties.set, право set_prop(splify2_app, steerd_prop) в политике): init по нему сообщает демону о выключателе (steer reload) и при выключении снимает правила (steerd down); сам демон работает при любом положении (init/steerd.rc). Демону положение выключателя сообщают apply, reload или SIGHUP: при выключенном ядре у демона со --watch нет ни одного таймера и ни одного сокета событий, кроме управляющего, — он не просыпается сам ни разу (стенд tests/daemonmatch.sh: не больше одного переключения контекста за 20 с). Таймеры цикла идут по CLOCK_MONOTONIC: во сне телефона они стоят, не будят его и не догоняют пачкой после пробуждения; wakelock демон не берёт. Через сокет выключатель не идёт: домену ядра писать это свойство нельзя нарочно, чтобы ядро не могло включить сам себя. Сервер сокета работает при любом положении выключателя — status и сохранение спеки доступны и при выключенном ядре.

Пример (Kotlin, набросок для моста)#

fun steer(cmd: String, body: ByteArray? = null): JSONObject {
    LocalSocket().use { s ->
        s.connect(LocalSocketAddress("/data/misc/steer/steer.sock",
                                     LocalSocketAddress.Namespace.FILESYSTEM))
        val line = if (body != null) "$cmd ${body.size}\n" else "$cmd\n"
        s.outputStream.write(line.toByteArray(Charsets.US_ASCII))
        body?.let { s.outputStream.write(it) }
        val reply = s.inputStream.bufferedReader(Charsets.UTF_8).readLine()
        return JSONObject(reply)
    }
}