feat: route proxy core egress through the selected WAN provider#87
Closed
kittylabassistant wants to merge 2 commits into
Closed
feat: route proxy core egress through the selected WAN provider#87kittylabassistant wants to merge 2 commits into
kittylabassistant wants to merge 2 commits into
Conversation
On routers with two providers Keenetic does policy-based routing by fwmark. The proxy core (Xray/Mihomo) stamped its upstream sockets with a hardcoded mark 255, which matches no provider policy, so the router always fell back to the main provider — egress ignored the provider chosen in the XKeen connection-priority policy (the "backup" checkbox; see Known issues / FAQ jameszeroX#22). Accept the core egress mark as 255 OR the XKeen policy fwmark: - get_policy_mark: resolve the policy fwmark from the router API into a clean, lowercased, non-zero "0xNN" (or "" when absent). Lowercasing fixes the case-sensitive awk match in configure_route; rejecting 0 prevents "--mark 0 -j RETURN" from matching all unmarked traffic. - validate_routing_mark: accept sockopt.mark / routing-mark in {255, policy_mark} for Xray and Mihomo, reusing get_policy_mark; the warning now shows the exact decimal mark to configure. - add_output: the anti-loop RETURN now matches both 255 and the policy mark, so the core's own upstream still escapes re-proxying. - api_cache_init runs before validate so the policy mark is available. - xkeen -diag prints the policy fwmark (hex + decimal). Single-WAN behavior is unchanged (the mark 255 path is identical) and Entware proxying keeps working: unmarked Entware traffic is still captured and proxied; only the core's marked upstream returns. Docs: Configuration.md, FAQ jameszeroX#22 (policy-mark method + interface fallback), Known issues, test release notes.
kittylabassistant
force-pushed
the
feature/multiwan
branch
from
59ce93c to
9fdec94
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Что и зачем
При двух провайдерах Keenetic маршрутизирует по fwmark (метка политики «Приоритеты подключений»). Прокси-ядро (Xray/Mihomo) метило свои исходящие сокеты захардкоженной меткой
255— она не соответствует ни одной политике провайдера, поэтому роутер всегда уходил в основное подключение. Выход ядра игнорировал провайдера, выбранного галкой в политике XKeen (Known issues, FAQ #22 — «галка Резервное не работает»).Решение
Метка egress ядра теперь принимается как
255либо как fwmark политики XKeen (XKeen уже резолвит её из API роутера). Пользователь вписывает десятичное значение метки в конфиг ядра вместо 255 — выход идёт через выбранного в политике провайдера, с failover (провайдера выбирает сама политика, метка стабильна).Изменения
scripts/_xkeen/02_install/07_install_register/04_register_init.shget_policy_mark— резолвит метку политики в чистый0xNN(первая совпавшая, hex-валидация, lowercase, отсев нулевой метки) либо"".validate_routing_mark— принимаетsockopt.mark/routing-mark∈ {255, policy_mark} (Xray + Mihomo), переиспользуетget_policy_mark; предупреждение показывает точное десятичное значение метки.add_output— anti-loopRETURNтеперь и на255, и на метку политики (upstream ядра не зацикливается).api_cache_initперенесён передvalidate_routing_mark(метка должна быть доступна валидатору).scripts/_xkeen/04_tools/03_tools_diagnostic.shxkeen -diagпечатает метку политики XKeen (hex + десятичное).Документация —
wiki/Configuration.md(раздел multi-WAN),wiki/FAQ.md#22 (Способ 1 — метка политики, Способ 2 —sockopt.interface),wiki/Knownissues.md,test/README.md.Совместимость и безопасность
255идентичен прежнему.RETURNвыходит только меченый upstream ядра.Тестирование
shellcheck -s sh— без ошибок,sh -n— OK.xkeen -diagпоказывает метку; внешний IP через прокси = резервный провайдер;iptables -t mangle -nL xkeen_outсодержит обаRETURN; failover-переключение провайдера в политике.Вне scope (отдельными задачами)
proxy-providersпроверяется по принципу «хотя бы один»,listeners[].routing-markне проверяется (преэкзистинг, не связано с этой фичей).≥ 0x80000000на mips32 (signed overflow в POSIX-арифметике) — Keenetic назначает малые метки, на практике не наблюдается.