Защита от потери доступа и восстановление

Как headless Throne сохраняет доступ к своему API и как вернуть доступ, если сохранённые настройки, например kill switch или TUN, лишили вас его.

Устройство без экрана должно оставаться доступным: если настройка отрежет его от сети, у вас может не оказаться клавиатуры, чтобы это исправить. Headless Throne устроен так, чтобы Throne API оставался доступным, а на случай, когда сохранённые настройки всё же лишают вас доступа, у него есть запуск в режиме восстановления.

Как Throne остаётся доступным

API всегда на месте.

API включён с первого запуска, на 127.0.0.1:9095, со сгенерированным ключом.
Параметры и переменные --api-* при каждом запуске переопределяют сохранённые настройки API, поэтому неудачно сохранённый слушатель можно исправить из командной строки. См. Параметры и переменные.
При восстановлении настроек из резервной копии сохраняются настройки API, входящих подключений, TUN и kill switch этого устройства.
Вместо пустого api.key, который остаётся после прерванного первого запуска, создаётся новый ключ. Любой другой файл ключа, который нельзя использовать, оставляет API выключенным; удалите этот файл, и Throne создаст новый ключ при следующем запуске.

Порт API.

Если порт API по умолчанию или сохранённый порт занят другой программой, Throne продолжает работать без API (degraded равно api_unavailable) и пробует снова каждые 30 секунд.
Если порт занят API другого Throne, Throne записывает это в лог и не трогает этот порт. Укажите этому Throne другой порт через --api-listen PORT.
Если слушатель, заданный через --api-listen, не может начать слушать, Throne вместо этого завершается с кодом 78, чтобы вы это заметили. Если его адреса ещё нет на компьютере, Throne ждёт его появления до 30 секунд, а затем завершается с кодом 1.

Неудачные попытки входа. После 5 неудачных попыток аутентификации за минуту с одного адреса Throne отклоняет этот адрес на 60 секунд и записывает это в лог. Он никогда не отклоняет loopback, а также адрес, с которого клиент успешно прошёл аутентификацию за последние 10 минут.

Kill switch и TUN.

Kill switch всегда пропускает loopback. Для слушателя API на другом адресе он выпускает ответы с порта API (Linux, macOS и Windows).
Если ядро не может переключиться на группу kill switch (GID 1950896719), например в Docker без root (rootless) или в другом контейнере с пространством имён пользователей, где нет CAP_SETGID или этого GID, ядро завершается с кодом 86. Throne не считает это сбоем: он запускает ядро без этой группы, kill switch переходит в закрытое состояние (fail closed) с кодом unsupported и продолжает блокировать трафик, а профили отклоняются (kill_switch_inactive), пока вы не выключите настройку kill_switch.
В Linux, если TUN запускается, пока API слушает сетевой адрес, Throne один раз предупреждает, если удалённые клиенты могут потерять доступ к API: ответы клиентам вне диапазонов адресов, идущих в обход туннеля, уходят в туннель, если не включён tun_auto_redirect, а строгий маршрут без tun_ipv6 отбрасывает клиентов IPv6.

Профиль, который роняет Throne. Если при каждом из последних трёх запусков Throne или его ядро останавливались в течение минуты после возобновления одного и того же профиля, Throne больше не возобновляет этот профиль (resume_suppressed). Запустите его один раз командой thronectl connect. Когда он проработает минуту, это состояние сбросится.

Ядро, которое постоянно падает. После трёх запусков подряд, в которых ядро ни разу не оставалось подключённым в течение минуты, Throne больше не завершается с кодами 70 или 71. Он остаётся запущенным вместе с API (degraded равно core_gave_up) и снова пробует запустить ядро каждые 5 минут, пока ядро не останется подключённым в течение минуты.

Восстановление доступа

Если сохранённые настройки всё же лишают вас доступа — например, kill switch обрывает ваш сеанс SSH или TUN перехватывает ответы API, — запустите Throne один раз с --no-resume --no-kill-switch (или с переменными THRONE_RESUME=0 и THRONE_KILL_SWITCH=0):

ни один профиль не запускается,
kill switch остаётся выключенным в этом запуске (профили по-прежнему отклоняются, пока настройка kill_switch не будет выключена) и
thronectl на том же устройстве может исправить настройки.

Затем исправьте настройку, из-за которой вы потеряли доступ, например командой thronectl settings set kill_switch=false или thronectl tun off, и снова запустите Throne обычным образом.

systemd

printf 'THRONE_RESUME=0\nTHRONE_KILL_SWITCH=0\n' | sudo tee -a /etc/throne/throne.env >/dev/null
sudo systemctl restart throne
thronectl settings set kill_switch=false        # или: thronectl tun off
# снова удалите эти две строки из /etc/throne/throne.env, затем:
sudo systemctl restart throne

Docker

Добавьте обе переменные в environment: в compose.yaml и выполните docker compose up -d:

    environment:
      THRONE_RESUME: "0"
      THRONE_KILL_SWITCH: "0"

Исправьте настройки командой docker compose exec throne thronectl …, снова удалите переменные и выполните docker compose up -d.

macOS

Добавьте обе переменные в EnvironmentVariables в plist, затем снова загрузите его:

sudo launchctl bootout system/moe.Throne.headless
sudo launchctl bootstrap system /Library/LaunchDaemons/moe.Throne.headless.plist

Исправьте настройки с помощью thronectl, удалите переменные и снова загрузите plist тем же способом.

Служба Windows

Остановите службу: sc.exe stop Throne.
Из командной строки с правами администратора вручную запустите Throne для того же каталога данных:
```
start "" /wait "C:\Program Files\Throne\Throne.exe" --headless --data-dir C:\ProgramData\Throne --no-resume --no-kill-switch
```
Исправьте настройки с помощью thronectl из другой командной строки с правами администратора (см. Команды из командной строки).
Остановите Throne клавишами Ctrl+C, затем снова запустите службу: sc.exe start Throne.

Начать заново

Если больше ничего не помогает, остановите Throne и переместите его каталог данных в другое место (для системного юнита — /var/lib/throne). При следующем запуске будет создан новый пустой каталог с новым ключом API. Восстановите профили из резервной копии.