sleep3r/mtproto.zig v0.24.1 on GitHub

🇷🇺 Что нового (RU)

Что решает этот релиз

v0.24.1 - patch-релиз для операторов, которые настраивают AmneziaWG / WireGuard tunnel mode через mtbuddy setup tunnel.

В v0.23.0 tunnel mode перешёл на явный contract SO_MARK=200 -> table 200: прокси помечает upstream sockets, а host policy routing отправляет только этот трафик через выбранный tunnel interface. Но в реальном install path нашёлся неприятный edge case: после успешной установки конфига туннеля mtproto-proxy.service мог не стартовать, потому что падал ExecStartPre=/usr/local/bin/setup_tunnel.sh.

Выглядело это так:

Restarting proxy......
Job for mtproto-proxy.service failed because the control process exited with error code.
Proxy failed to start. Check: journalctl -u mtproto-proxy -n 30

Причин было две:

Telegram HTTPS probe через curl --interface awg0 https://core.telegram.org/getProxyConfig считался обязательным условием старта. Если core.telegram.org, DNS или HTTPS probe недоступны, pre-start валил весь proxy service, даже когда policy route уже можно было поставить.
На первом запуске table 200 ещё могла не существовать. Команда чтения предыдущего route возвращала non-zero, а set -euo pipefail завершал скрипт до выбора tunnel.

v0.24.1 делает pre-start поведение более прагматичным: сервис стартует, если tunnel interface поднят, awg/wg show отвечает, policy rule установлен, а ip route get ... mark 200 реально указывает на выбранный interface. Telegram probe остаётся полезной диагностикой, но больше не блокирует запуск прокси.

[!NOTE]
Конфиг менять не нужно. После обновления достаточно повторить mtbuddy setup tunnel ..., чтобы пересоздать /usr/local/bin/setup_tunnel.sh и systemd unit с исправленным поведением.

[!TIP]
Если сервер уже застрял на старом ExecStartPre, обновите mtbuddy до v0.24.1 и заново выполните tunnel setup с тем же .conf или vpn:// link.

Что изменено

Tunnel pre-start больше не зависит от Telegram HTTPS probe (#269)

curl --interface <iface> https://core.telegram.org/getProxyConfig больше не является fatal check.
Tunnel считается пригодным, когда:
- interface можно поднять через awg-quick / wg-quick;
- awg show <iface> / wg show <iface> возвращает состояние;
- route table 200 указывает default route на выбранный interface;
- ip -4 route get <telegram-dc-ip> mark 200 подтверждает dev <iface>.
Если Telegram probe падает, controller пишет reason policy route ready; Telegram probe failed и логирует это как диагностику, не ломая mtproto-proxy.service.

Policy rule setup стал идемпотентным (#269)

fwmark 200 -> table 200 теперь ставится через explicit ensure-step.
Старые rules с тем же fwmark/table/priority удаляются перед добавлением нового rule.
После добавления rule скрипт отдельно проверяет, что ip -4 rule show действительно содержит нужный fwmark mapping.
Это делает повторные запуски setup_tunnel.sh, timer failover и systemctl restart mtproto-proxy устойчивее к уже существующим rules.

Первый запуск больше не падает на пустой table 200 (#269)

Чтение предыдущего default route из table 200 теперь допускает отсутствие самой FIB table.
Пустая table 200 больше не завершает script из-за set -euo pipefail.
Route всё равно создаётся через ip -4 route replace default dev <iface> table 200 после выбора tunnel.

Installer e2e теперь покрывает этот сценарий (#269)

В installer e2e добавлен tunnel regression test.
Тест подставляет fake awg / awg-quick, создаёт dummy/veth awg0 и специально ломает только curl --interface awg0.
Проверяется, что mtbuddy setup tunnel:
- успешно рестартит mtproto-proxy;
- оставляет mtproto-tunnel-pool.timer active/enabled;
- пишет active=awg0 и status=healthy в pool state;
- создаёт fwmark 200 -> table 200 -> dev awg0;
- не считает падение Telegram probe фатальным.
Debug dump installer e2e теперь сохраняет tunnel rules/routes/state для будущих разборов.

Проверено

bash -n test/installer-e2e/run.sh
zig build test
MTPROTO_INSTALLER_E2E_IMAGES='debian:12' test/installer-e2e/run.sh

🇬🇧 Release notes (EN)

What this release addresses

v0.24.1 is a patch release for operators configuring AmneziaWG / WireGuard tunnel mode through mtbuddy setup tunnel.

v0.23.0 moved tunnel mode to an explicit SO_MARK=200 -> table 200 contract: the proxy marks upstream sockets, and host policy routing sends only that traffic through the selected tunnel interface. A real install-path edge case showed up afterwards: tunnel config installation could succeed, but mtproto-proxy.service failed to start because ExecStartPre=/usr/local/bin/setup_tunnel.sh exited non-zero.

It looked like this:

Restarting proxy......
Job for mtproto-proxy.service failed because the control process exited with error code.
Proxy failed to start. Check: journalctl -u mtproto-proxy -n 30

There were two root causes:

The Telegram HTTPS probe through curl --interface awg0 https://core.telegram.org/getProxyConfig was treated as a startup requirement. If core.telegram.org, DNS, or that HTTPS probe was unavailable, pre-start failed the whole proxy service even when the policy route could be installed.
On first run, table 200 may not exist yet. Reading the previous route returned non-zero, and set -euo pipefail terminated the script before tunnel selection.

v0.24.1 makes pre-start behavior more pragmatic: the service starts when the tunnel interface is up, awg/wg show works, the policy rule is installed, and ip route get ... mark 200 actually resolves through the selected interface. The Telegram probe remains useful diagnostics, but it no longer blocks proxy startup.

[!NOTE]
No config changes are required. After updating, rerun mtbuddy setup tunnel ... to regenerate /usr/local/bin/setup_tunnel.sh and the systemd unit with the fixed behavior.

[!TIP]
If a server is already stuck on the old ExecStartPre failure, update mtbuddy to v0.24.1 and rerun tunnel setup with the same .conf or vpn:// link.

What changed

Tunnel pre-start no longer depends on the Telegram HTTPS probe (#269)

curl --interface <iface> https://core.telegram.org/getProxyConfig is no longer a fatal check.
A tunnel is considered usable when:
- the interface can be brought up with awg-quick / wg-quick;
- awg show <iface> / wg show <iface> returns state;
- route table 200 points its default route at the selected interface;
- ip -4 route get <telegram-dc-ip> mark 200 confirms dev <iface>.
If the Telegram probe fails, the controller writes reason policy route ready; Telegram probe failed and logs it as diagnostics without breaking mtproto-proxy.service.

Policy rule setup is idempotent (#269)

fwmark 200 -> table 200 is now installed through an explicit ensure step.
Stale rules with the same fwmark/table/priority are removed before adding the new rule.
After adding the rule, the script verifies that ip -4 rule show contains the expected fwmark mapping.
This makes repeated setup_tunnel.sh runs, timer failover, and systemctl restart mtproto-proxy more robust when rules already exist.

First run no longer fails on an empty table 200 (#269)

Reading the previous default route from table 200 now tolerates the FIB table not existing yet.
An empty table 200 no longer exits the script via set -euo pipefail.
The route is still created with ip -4 route replace default dev <iface> table 200 after tunnel selection.

Installer e2e now covers this scenario (#269)

Added a tunnel regression test to installer e2e.
The test injects fake awg / awg-quick, creates a dummy/veth awg0, and deliberately fails only curl --interface awg0.
It verifies that mtbuddy setup tunnel:
- restarts mtproto-proxy successfully;
- leaves mtproto-tunnel-pool.timer active/enabled;
- writes active=awg0 and status=healthy to pool state;
- creates fwmark 200 -> table 200 -> dev awg0;
- does not treat the Telegram probe failure as fatal.
Installer e2e debug dumps now include tunnel rules/routes/state for future investigations.

Verified

bash -n test/installer-e2e/run.sh
zig build test
MTPROTO_INSTALLER_E2E_IMAGES='debian:12' test/installer-e2e/run.sh

Changelog

fix: tunnel prestart policy routing (#269) (7c62b30)
chore(main): release 0.24.1 (#270) (48df22f)