محافظت در برابر قطع دسترسی و بازیابی

دستگاهی که صفحه‌نمایش ندارد باید در دسترس بماند: اگر تنظیمی دسترسی به آن را قطع کند، ممکن است صفحه‌کلیدی برای درست کردنش نداشته باشید. Throne بدون رابط گرافیکی طوری ساخته شده است که Throne API را در دسترس نگه دارد، و برای مواردی که تنظیمات ذخیره‌شده با این حال دسترسی شما را قطع می‌کنند، یک روش شروع برای بازیابی دارد.

Throne چگونه در دسترس می‌ماند

API همیشه در دسترس است.

• API از نخستین اجرا روی 127.0.0.1:9095 و با یک کلید تولیدشده روشن است.
• گزینه‌ها و متغیرهای --api-* در هر بار شروع بر تنظیمات ذخیره‌شدهٔ API اولویت دارند، بنابراین یک شنوندهٔ نادرستِ ذخیره‌شده را می‌توان از خط فرمان درست کرد. گزینه‌ها و متغیرها را ببینید.
• بازیابی تنظیمات از یک پشتیبان، تنظیمات API، ورودی، TUN و کیل‌سوییچ این دستگاه را نگه می‌دارد.
• یک api.key خالی، مانند آنچه یک نخستین اجرای نیمه‌کاره به جا می‌گذارد، کلید جدیدی می‌گیرد. هر فایل کلید دیگری که قابل استفاده نباشد API را خاموش نگه می‌دارد؛ آن را حذف کنید تا Throne در شروع بعدی کلید جدیدی بسازد.

پورت API.

• وقتی برنامهٔ دیگری پورت پیش‌فرض یا ذخیره‌شدهٔ API را در اختیار دارد، Throne بدون API به کار ادامه می‌دهد (degraded برابر api_unavailable است) و هر 30 ثانیه دوباره امتحان می‌کند.
• وقتی API یک Throne دیگر پورت را در اختیار دارد، Throne این را در گزارش می‌نویسد و کاری به آن ندارد. با --api-listen PORT پورت دیگری به این یکی بدهید.
• شنونده‌ای که با --api-listen داده شده است و نمی‌تواند گوش دهد، به‌جای آن باعث می‌شود Throne با کد 78 خارج شود تا متوجه شوید. اگر نشانی آن هنوز روی رایانه وجود ندارد، Throne تا 30 ثانیه برای آن صبر می‌کند، سپس با کد 1 خارج می‌شود.

ورودهای ناموفق. پس از 5 احراز هویت ناموفق در یک دقیقه از یک نشانی، Throne آن نشانی را به مدت 60 ثانیه رد می‌کند و این را در گزارش می‌نویسد. Throne هرگز loopback را رد نمی‌کند، و همچنین نشانی‌ای را که یک کلاینت در 10 دقیقهٔ گذشته از آن احراز هویت کرده است.

کیل‌سوییچ و TUN.

• کیل‌سوییچ همیشه اجازهٔ عبور loopback را می‌دهد. برای شنوندهٔ API روی نشانی دیگر، اجازه می‌دهد پاسخ‌هایی که از پورت API فرستاده می‌شوند خارج شوند (Linux، macOS و Windows).
• وقتی هسته نمی‌تواند گروه کیل‌سوییچ (GID 1950896719) را به خود بگیرد، برای مثال در Docker بدون root (rootless) یا کانتینر دیگری با user namespace که CAP_SETGID یا آن GID را ندارد، هسته با کد 86 خارج می‌شود. Throne این را کرش به حساب نمی‌آورد: هسته را بدون آن گروه اجرا می‌کند، کیل‌سوییچ به‌صورت بسته (fail closed) با کد unsupported شکست می‌خورد و همچنان ترافیک را مسدود می‌کند، و نمایه‌ها رد می‌شوند (kill_switch_inactive) تا وقتی که تنظیم kill_switch را خاموش کنید.
• در Linux، وقتی TUN در حالی شروع می‌شود که API روی یک نشانی شبکه گوش می‌دهد، اگر ممکن باشد کلاینت‌های راه‌دور دسترسی به API را از دست بدهند، Throne یک بار هشدار می‌دهد: پاسخ‌ها به کلاینت‌هایی که بیرون از محدوده‌های نشانیِ دورزده‌شده هستند وارد تونل می‌شوند، مگر اینکه tun_auto_redirect روشن باشد، و مسیر سخت‌گیرانه (strict route) بدون tun_ipv6 ترافیک کلاینت‌های IPv6 را دور می‌ریزد.

نمایه‌ای که Throne را از کار می‌اندازد. وقتی Throne یا هسته‌اش در هر یک از سه شروع آخر، در کمتر از یک دقیقه پس از اجرای دوبارهٔ همان نمایه متوقف شده باشد، Throne آن نمایه را دوباره اجرا نمی‌کند (resume_suppressed). آن را یک بار با thronectl connect اجرا کنید. وقتی یک دقیقه اجرا شد، این وضعیت پاک می‌شود.

هسته‌ای که پشت سر هم شکست می‌خورد. پس از سه شروع پیاپی که در آن‌ها هسته هرگز یک دقیقه متصل نماند، Throne دیگر با کدهای 70 یا 71 خارج نمی‌شود. با API روشن می‌ماند (degraded برابر core_gave_up است) و هر 5 دقیقه هسته را دوباره امتحان می‌کند، تا وقتی که هسته یک دقیقه متصل بماند.

بازیابی دسترسی

اگر تنظیمات ذخیره‌شده با این حال دسترسی شما را قطع کنند، برای مثال کیل‌سوییچی که نشست SSH شما را قطع می‌کند، یا TUN که پاسخ‌های API را به تونل می‌برد، Throne را یک بار با --no-resume --no-kill-switch (یا متغیرهای THRONE_RESUME=0 و THRONE_KILL_SWITCH=0) شروع کنید:

• هیچ نمایه‌ای اجرا نمی‌شود،
• کیل‌سوییچ در آن اجرا خاموش می‌ماند (نمایه‌ها تا وقتی تنظیم 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        # or: thronectl tun off
# remove the two lines from /etc/throne/throne.env again, then:
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

1. سرویس را متوقف کنید: sc.exe stop Throne.

2. از یک خط فرمان با دسترسی مدیر، Throne را برای همان پوشهٔ داده‌ها به‌صورت دستی شروع کنید:

   start "" /wait "C:\Program Files\Throne\Throne.exe" --headless --data-dir C:\ProgramData\Throne --no-resume --no-kill-switch
   

3. تنظیمات را با thronectl از یک خط فرمان دیگر با دسترسی مدیر درست کنید (اجرای فرمان‌ها از خط فرمان را ببینید).

4. Throne را با Ctrl+C متوقف کنید، سپس سرویس را دوباره شروع کنید: sc.exe start Throne.

شروع از نو

اگر هیچ راه دیگری کمک نکرد، Throne را متوقف کنید و پوشهٔ داده‌های آن را به جای دیگری منتقل کنید (برای یونیت سیستمی، /var/lib/throne). شروع بعدی یک پوشهٔ جدید و خالی با یک کلید API جدید می‌سازد. نمایه‌هایتان را از یک پشتیبان بازیابی کنید.