8 Commits

Author	SHA1	Message	Date
Kuzz007	effcccceac	feat(amneziawg): add native AmneziaWG protocol support (#6105) ... * feat(amneziawg): add native AmneziaWG protocol backend AmneziaWG (WireGuard plus DPI-resistant obfuscation) needs no Docker here — it runs as a genuine kernel interface via awg-quick/awg, managed the same way internal/mtproto manages mtg: one Inbound row is one desired Instance, and a Manager reconciles running interfaces toward the database every 10s (internal/web/job/amneziawg_job.go) plus immediately after a client edit (applyLocalAmneziaWG). Clients reuse model.Client verbatim (the same PrivateKey/PublicKey/ PreSharedKey/AllowedIPs fields WireGuard already uses), so bulk operations, the QR/share-link modal and subscriptions come from the shared inbound infrastructure instead of a parallel implementation. internal/amneziawg owns the obfuscation param generator/validator (ported from coinman-dev/3ax-ui, upgraded to AmneziaWG 2.0's S3/S4 padding and I1 signature packet) and the exec wrapper around awg-quick/awg, with fingerprint-based reconcile (noop / reload-via- syncconf / full restart) mirroring mtproto.Manager so a same-protocol edit doesn't force an unnecessary interface bounce that would drop every peer's connection. Frontend and install.sh's DKMS/awg-tools setup are tracked separately; this is backend-only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): add frontend support and fix a Go->Zod generator gap Wires the amneziawg protocol through the panel UI the same way every other protocol is registered: a Zod settings schema (nested {server, clients}, matching the Go JSON exactly), the protocol enum, the inbound-form's per-protocol fields component and its tab-visibility allowlist, the default-settings factory, the client schema dispatcher, and the sniffing-capability exclusion (no Xray inbound exists for amneziawg, same as mtproto). Client key/allowedIPs fields are reused rather than duplicated: since AmneziaWG clients are wire-identical to WireGuard clients (same model.Client fields), ClientFormModal renders one shared field block for both, switching only the visible label by which protocol is active. The private-key input also gets a live public-key sync via a new useEffect, because unlike WireGuard's Xray-native inbound (which re-derives its public key at runtime and never stores one), AmneziaWG's server.publicKey is a real persisted field the Go backend reads directly — free-typing a new private key without this would silently save a mismatched keypair. Adds a downloadable per-client .conf (amneziawgConfig.ts, mirroring wireguardConfig.ts) with the obfuscation lines, and an InboundOption.AwgServer field on the Go side so the config builder gets the full server block in one round trip. Along the way, running tools/openapigen surfaced a real bug: it doesn't flatten anonymously-embedded Go structs the way encoding/json does, so ServerSettings embedding Obfuscation20 produced a Zod schema with a nested `obfuscation20` key that never matches the real wire JSON. Fixed by un-embedding (flat fields + an accessor method) and registering internal/amneziawg in the generator's own package list, which had been silently emitting a dangling schema reference. English and Russian translations are complete; the other 10 locale files still fall back to English for the new keys. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): complete frontend parity for the Inbounds list page The Clients page (form, CRUD, QR/config) already worked from the prior commit; this closes the remaining gap on the Inbounds side and in a couple of protocol allowlists that a plain search for existing wireguard/mtproto handling turned up. lib/xray/inbound-link.ts gets amneziawg-specific link/config builders (genAmneziaWGLink/genAmneziaWGConfig, plus the *s fan-out variants) mirroring the wireguard ones — AmneziaWG has no legacy peers-array to fall back to, so these read settings.clients directly and add the obfuscation lines every client must share with the server. Wired into genInboundLinks generically, and into three consumers that call the wireguard builders directly rather than through that dispatcher: QrCodeModal, InboundInfoModal, and InboundsPage's bulk export. ClientInfoModal, ClientBulkAddModal, and the bulk attach/detach modals each had their own protocol allowlist that needed amneziawg added alongside wireguard/mtproto. Two real gaps surfaced by grepping every remaining 'wireguard' / Protocols.WIREGUARD hit in frontend/src rather than trusting the checklist was exhaustive: - useInbounds.ts's TRACKED_PROTOCOLS gates the deactive/depleted/ expiring/online client counts shown per inbound on the list page; without amneziawg those counts would silently read zero. - inbound-tag.ts is an explicit client-side mirror of the Go backend's port_conflict.go (the file says so itself: "Keep in sync"). It still only special-cased wireguard for UDP, so an amneziawg inbound would have fallen through to the TCP default and disagreed with the backend's own port-conflict math. Also finishes translating the AmneziaWG UI strings into the 11 locale files that were still falling back to English (ar-EG, es-ES, fa-IR, id-ID, ja-JP, pt-BR, tr-TR, uk-UA, vi-VN, zh-CN, zh-TW), matching en-US/ru-RU key-for-key (26 new keys, verified by count in every file). Not run anywhere: npm run typecheck / build. This machine has neither Node nor npm, so nothing here has compiled — reviewed by hand plus brace/paren balance checks and cross-referencing the generated Zod/TS types. Treat this as needing a real typecheck before shipping. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(install): note that AmneziaWG kernel module install is still manual Tracked separately (not yet ported into this script) — see coinman-dev/3ax-ui's install_amneziawg for the reference approach (ppa:amnezia/ppa). Also serves as a real, path-filter-matching change to get the previous empty commit's CI trigger to actually fire — release.yml's push trigger is paths-scoped and an empty commit changes no files, so it never matched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): add a button to randomize obfuscation parameters Mirrors the existing key-regenerate button next to the private key field. Client-side randomization matches the ranges/constraints of GenerateObfuscation20's "default" preset (internal/amneziawg/params.go) closely enough for a form suggestion — the user can still hand-edit any field afterward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(install): auto-install the AmneziaWG DKMS module + amneziawg-tools Ports install_amneziawg from coinman-dev/3ax-ui's install.sh, adapted to this script's broader distro coverage and NONINTERACTIVE convention: - Ubuntu/Debian/Armbian: ppa:amnezia/ppa (primary, tested path), with a reachability pre-check for the Launchpad PPA host — often blocked by hosting providers, especially Russian VPS — so a flaky network skips the feature instead of hanging apt through several retries. - Fedora/RHEL-family, Arch/Manjaro/Parch: best-effort fallback to plain wireguard-tools (+ AUR amneziawg-dkms via yay/paru when available), with a manual-install pointer. - Everything else: manual-install pointer only. Also installs ndppd and persists IPv4/IPv6 forwarding (for the future IPv6/NDP phase, not yet wired into the panel) and adds a Secure Boot warning at the end of the run, since a DKMS-built module is unsigned and won't load while it's enabled — a common trap on cloud VPS images. Never fatal: the panel installs and runs fine either way, an AmneziaWG inbound just won't bring up its tunnel until the module is present. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): resolve all 3 real CI failures (typecheck/lint/codegen) Found by checking the fork's Actions tab after the last two pushes — the release build passed (it doesn't run these checks) but the separate CI workflow caught three real issues: - golangci-lint (noctx): every internal/amneziawg/manager.go exec.Command call is now exec.CommandContext with a 30s timeout, so a hung awg-quick/awg invocation can't block the reconcile job indefinitely (mirrors internal/mtproto/process.go's own CommandContext usage). - tsc --noEmit: frontend/src/schemas/client.ts's hand-maintained InboundOptionSchema (used by the useClients hook, separate from the auto-generated one in generated/) never got an awgServer field added when the AmneziaWG frontend work was done — every read of inbound.awgServer.* in amneziawgConfig.ts was typing as {}. Added AwgServerOptionSchema, nested (not flattened like wg*) to match what amneziawgConfig.ts already expects. Also guarded server.publicKey in inbound-link.ts's genAmneziaWGLink against the schema's optional type. - codegen staleness: frontend/public/openapi.json is produced by a Node script (gen:api) this machine can't run; hand-applied the exact diff the CI failure log already showed (amneziawg protocol enum entry, ServerSettings schema, InboundOption.awgServer, one example payload), verified as valid JSON. Also confirmed independently by this run: install_amneziawg (previous commit) installed and loaded the DKMS module successfully on both amd64 and arm64 CI runners. The two "Deploy Smoke Tests" failures are unrelated to this change — this fork has only ever published the dev-latest pre-release, and GitHub's /releases/latest API deliberately excludes pre-releases, so the smoke test's no-argument install path (which resolves "latest") has nothing to find. Not a regression; needs an actual tagged release whenever that's wanted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): Phase 2a — IPv6 support + NDP proxy Adds native dual-stack IPv6 to AmneziaWG inbounds, ported from coinman-dev/3ax-ui's approach: - ServerSettings gets ipv6Enabled/ipv6Subnet/ipv6ExternalInterface; Instance carries the server's own IPv6 address (first host of the subnet) alongside its IPv4 one. - defaultAmneziaWGClients allocates an IPv6 host address per client (second AllowedIPs entry) when the server has IPv6 enabled, reusing allocateWireguardAddress — which needed a real fix along the way: it always suffixed "/32" regardless of address family, which is wrong for an IPv6 host address (needs /128). Now family-aware. - generateServerConfig's PostUp/PostDown gains IPv6 forward-accept rules, proxy_ndp sysctl, and one `ip -6 neigh add/del proxy` entry per enabled peer with an IPv6 address — the lightweight per-client method, not the ndppd-daemon whole-subnet method (not worth the config-file-management complexity at this scale; ndppd itself is still installed by install.sh in case that changes later). - ValidateIPv6Subnet rejects a malformed subnet before save. - Frontend: ipv6Enabled/ipv6Subnet/ipv6ExternalInterface fields on the AmneziaWG inbound form, EN+RU translations, openapi.json/generated/* regenerated (the latter via `go run ./tools/openapigen`, pure Go). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): fill in IPv6 fields missed by the Phase 2a commit Two real gaps the CI caught (both new fields, both my miss): - inbound-defaults.ts's createDefaultAmneziawgInboundSettings() built a server object literal predating ipv6Enabled/ipv6Subnet/ ipv6ExternalInterface — AmneziawgServer's inferred type now requires them (zod .default() fields are non-optional post-parse), so this didn't typecheck at all. - openapi.json's ipv6Enabled property was missing the description the real generator attaches (the Go doc comment covering all three IPv6 fields is attached to the first one) — a one-line diff, but git diff --exit-code doesn't care how small. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): Phase 2b — per-client port-forwarding Admins can now set a per-client ForwardedPorts string (e.g. "80, 443, 8000-8100") that gets DNAT'd + FORWARD'd to that peer's tunnel address via iptables rules in PostUp/PostDown, ported and simplified from coinman-dev/3ax-ui's shared/portfwd. Two decisions worth flagging for future readers: - The iptables --comment tag on each rule is awg-fwd-<fnv32a(email)>, not the raw client email. Email is admin/API-supplied free text that ends up embedded in a shell-executed PostUp/PostDown line; a hash can never carry a shell metacharacter through where raw interpolation could. - The reconcile manager gained a third fingerprint (portFwdFP, next to the existing structural/peers ones). `awg syncconf` only touches the WireGuard peer table — it never re-applies PostUp/PostDown iptables rules — so a port-forward-only change has to force a full awg-quick down+up bounce, same as a structural change, rather than the lighter sync a plain peer add/remove can use. Also fixes a real pre-existing bug found while wiring up IPv6 client allocation in the previous commit's spirit: allocateWireguardAddress always suffixed "/32" regardless of address family, which produced invalid host bits for IPv6 (needs "/128"). ForwardedPorts flows through model.Client -> model.ClientRecord (gorm column wg_forwarded_ports, auto-migrated) -> ToRecord/ToClient/ MergeClientRecord, mirroring the awgServer field's earlier lesson that new fields need checking against a second, hand-maintained persistence-layer struct. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): route a client's traffic through Xray via the Routing page Every enabled AmneziaWG inbound gets its own Xray TPROXY bridge automatically, with no toggle to enable first: a loopback dokodemo-door inbound (sockopt.tproxy) tagged with the AmneziaWG inbound's own real tag, so it's already selectable in the existing Routing page's inbound-tag picker — the same trick the mtproto sidecar's own bridge already relies on (InboundService.GetInboundTags is a plain, protocol-blind SELECT over every inbound row's tag, no dedicated UI plumbing needed). internal/amneziawg's defaultPostUpDown TPROXYs every peer's traffic into that bridge unconditionally; the bridge's port is derived deterministically from the inbound's id (EgressPortForInbound) so the kernel-side reconcile loop and the Xray-config generator never need to negotiate a runtime value between them. injectAmneziawgEgress never generates a routing rule itself — whether a client's traffic goes anywhere beyond Xray's default routing is entirely up to whatever rules the admin adds through the existing Routing UI (pick the AmneziaWG inbound's tag as source, optionally a specific peer's IP via that page's own Source-IP field, and an outbound), exactly the same workflow as routing any other protocol. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): recover orphaned interfaces after an ungraceful exit Two gaps left an AmneziaWG interface stuck outside the manager's control after a crash (kill -9/OOM/panic skips StopAll): - ensureRestart's teardown was gated on the in-memory `exists` map, which is always empty on a fresh process, so a survived interface never got interfaceDown before interfaceUp tried `ip link add` against a name the kernel already had — failing forever and never populating m.ifaces, so traffic accounting silently stopped and the inbound could never be removed. Gate on isInterfaceUp instead, which checks real kernel state rather than this process's own bookkeeping. - An inbound deleted from the database entirely while the panel was down has no entry in `desired` ever again, so it never reaches the per-id cleanup loop in Reconcile (which only walks m.ifaces). Add a one-time sweepOrphansLocked scan of configDir, mirroring mtproto.Manager.sweepOrphansLocked, that tears down and removes any leftover interface/config not in the current desired set. Found by the automated review on MHSanaei/3x-ui#6105 (Finding 1). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * i18n(amneziawg): backfill IPv6/obfuscation/port-forwarding keys in 11 locales Only en-US/ru-RU ever got these 9 keys as each AmneziaWG feature landed (the regenerate-obfuscation button, then Phase 2a's IPv6 fields, then Phase 2b's per-client ForwardedPorts) — the other 11 locale files were never backfilled, so i18next has been silently falling back to English for all of them since Phase 1. Cosmetic-only (never broke anything), but now closed for every shipped locale. * fix(amneziawg): resolve 7 Medium findings from the automated PR review Each is independently reproducible; fixed together since one review pass found all of them. - manager.go: the shared "ip rule add fwmark" policy route had no existence check, so it duplicated in "ip rule show" on every interface bounce (which hostRulesFingerprint forces on any client add/remove/ re-IP). Now checked via "ip rule list | grep -q ..." first. (Finding 2) - params.go: ExternalInterface, IPv6ExternalInterface, and subnetIp/ subnetCidr are interpolated unescaped into a shell-executed PostUp/ PostDown line, but only obfuscation and the IPv6 subnet were validated before save. Added ValidateInterfaceName (a strict charset+length pattern) and ValidateSubnetIPv4 (netip.ParsePrefix), wired into normalizeAmneziaWGSettings. (Finding 3) - amneziawg_job.go: IsAwgInstalled() existed but nothing ever called it, so a host without awg/awg-quick (the Docker image, RHEL, Arch, a failed install.sh PPA step) logged a reconcile failure every 10s forever. Now checked once an inbound actually needs it, warning once instead of spamming. (Finding 4) - client_inbound_apply.go: the WireGuard/AmneziaWG credential carry-forward (added so a metadata-only client edit doesn't rotate keys) never covered ForwardedPorts, so a partial edit -- an API call or Telegram-bot toggle that omits the field -- silently wiped a client's port-forwarding spec. Carried forward and written back the same way the key fields already are. (Finding 5) - manager.go: hostRulesFingerprint keyed each peer on its IPv4 address only, and structuralFingerprint omitted IPv6Enabled/IPv6ExternalInterface entirely, so an IPv6-only change could pick the syncconf reload path (which never re-runs PostUp, leaving a stale NDP-proxy entry) or be a complete no-op. Both fingerprints now cover the IPv6 fields. (Finding 6) - port_conflict.go: the AmneziaWG egress bridge (injectAmneziawgEgress) binds 127.0.0.1:63100+id with no collision check anywhere, since it isn't a database row the ordinary port-conflict query can see -- same blind spot the reserved Xray API port already has its own check for. Added the equivalent check for the AmneziaWG bridge port. (Finding 7) - install.sh: install_amneziawg ran unconditionally for every install/ update, building a DKMS kernel module and enabling host-wide IPv4/IPv6 forwarding whether or not the feature is ever used. Gated behind a new should_install_amneziawg (XUI_INSTALL_AMNEZIAWG=true/false, or an interactive y/N prompt defaulting to no). Also replaced the deprecated apt-key adv with a dedicated keyring + signed-by= on the Debian branch, and guarded its sources.list appends against duplication on a retried install. (Finding 8) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): make the Xray TPROXY bridge a per-inbound opt-in Addresses Finding 10 from the automated PR review: an always-on TPROXY bridge makes every AmneziaWG tunnel hard-depend on Xray being up (all traffic, including DNS, drops whenever Xray restarts), and forces a full awg-quick down+up bounce on any client add/remove/re-IP, permanently losing the syncconf fast path. Adds ServerSettings.RouteThroughXray (off by default): - defaultPostUpDown only emits the TPROXY/policy-route rules when it's on; a plain AmneziaWG tunnel now has zero Xray dependency out of the box. - structuralFingerprint covers it (toggling it changes whether PostUp/ PostDown contain any TPROXY rules at all -- structural, not a per-peer host-rule). hostRulesFingerprint's IPv4 tracking is now itself conditional on RouteThroughXray (and IPv6 tracking on IPv6Enabled), so an instance that never uses either keeps the syncconf fast path for a plain peer re-IP. - injectAmneziawgEgress only creates a bridge for inbounds that opted in; checkAmneziawgEgressConflict (the Finding-7 fix) now parses each candidate through InstanceFromInbound so a non-routed inbound's port is correctly never treated as reserved. - New inbound-level Switch in the AmneziaWG form; the actual outbound decision is still made entirely through the panel's stock Routing page, same as before -- only whether the bridge exists at all is now a choice. Translation keys added to all 13 locales in the same commit this time, not backfilled later (see Finding 9's lesson). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): resolve 4 Low findings from the automated PR review - manager.go: serverAddress assumed subnetIp always ends in ".0"; a base like "10.8.1.5" was used verbatim as the server's own address, eventually colliding with peer allocation (which starts at .2 upward). Now derives the first host of the actual subnetIp/subnetCidr network via netip, matching serverAddressV6's own approach. A /32 base (no host bits at all) is still used as-is. (Finding 12, partial -- the /16 pool-widening half of this finding only exists on the upstream-pr/amneziawg branch's merged client_wireguard.go, not here; handled separately on that branch.) - manager.go: ensureLocked carried the previous per-peer traffic counters (`last`) forward even through a full restart, but awg-quick down+up resets the kernel's own counters to zero -- the next CollectTraffic computed a large negative delta (clamped to 0), silently discarding real traffic. Extracted the decision into nextTrafficBaseline: only a reload (syncconf) preserves the baseline. (Finding 13) - portfwd.go: exported ForwardedPortsInclude; inbound_amneziawg.go's new checkForwardedPortsConflict uses it to reject, at save time, a client's forwardedPorts that would DNAT the panel's own port or another enabled inbound's port to the tunnel client -- portForwardLines has no destination restriction, so this collision was previously silent. Wired into both the single-client update path and the add-client path (client_inbound_apply.go), plus normalizeAmneziaWGSettings for the whole-inbound save path. (Finding 14) - inbound.go: InboundOption.AwgServer sent the whole ServerSettings struct including PrivateKey to GetInboundOptions callers -- a shared, admin-wide dropdown-filling endpoint the frontend's own AwgServerOptionSchema never reads that field from. Redacted it before assigning. (Finding 11) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): don't widen the peer address pool past AmneziaWG's own subnet Completes Finding 12 from the automated PR review (the serverAddress half of this finding was already fixed on main and cherry-picked here). This half is specific to this branch: allocateWireguardAddress's /16 pool-widening fallback is an independent addition from upstream's own main that this branch inherited during the cherry-pick rebase -- it doesn't exist on the fork's own main at all, so this fix can't be cherry-picked the normal way and is committed directly here. Widening is safe for WireGuard's own Xray-native inbound (AllowedIPs isn't tied to a strict kernel interface subnet), but AmneziaWG's kernel interface Address is exactly the configured subnet -- an address allocated from the containing /16 once the /24 fills up would be silently unroutable. allocateWireguardAddress now takes an explicit allowWidening bool: WireGuard's own caller passes true (unchanged behavior), AmneziaWG's passes false (fails loudly on exhaustion instead). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(docker): note that AmneziaWG doesn't work in this image Investigated: the image is Alpine-based, and AmneziaWG's own packaging (DKMS module + amneziawg-tools) doesn't target Alpine/musl at all -- unlike the Debian/Ubuntu/Fedora/Arch paths install.sh already handles, there's no package to apk add even with full host network/capabilities. The panel already degrades gracefully (IsAwgInstalled() logs one warning instead of retrying forever), so no code change is needed -- just made the reason explicit at the point where a user would reach for cap_add/ network_mode to try to work around it. * fix(sub): include amneziawg inbounds in subscription links getInboundsBySubId's SQL protocol allowlist never had 'amneziawg' added, so every AmneziaWG client was silently excluded from all three subscription formats (plain/individual links, JSON, Clash) and from the Telegram bot's QR/individual-link buttons, which fetch through the same path. genAmneziaWGLink itself was already fully implemented and already wired into GetLink's dispatch switch -- it just never got a chance to run. Same bug shape as the earlier TRACKED_PROTOCOLS frontend gap: a hardcoded protocol list one entry short. Found while investigating whether the Telegram bot needed AmneziaWG- specific client-management code -- it doesn't (the bot itself is fully protocol-agnostic), but this is the actual root cause of "can't share an AmneziaWG client's config via the bot." Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(inbound): enforce node-eligibility server-side, not just in the UI Investigated multi-node interaction with AmneziaWG: the master's own reconcile (DesiredAmneziaWGInstances) and Xray config generation (injectAmneziawgEgress, the GenXrayInboundConfig protocol skip) all correctly filter on NodeID IS NULL, so a node-assigned AmneziaWG (or MTProto) inbound would never be managed by the master. But nothing stopped one from being created that way: NODE_ELIGIBLE_PROTOCOLS (frontend/src/pages/inbounds/form/InboundFormModal.tsx) only hides the node picker client-side -- a direct API call could set nodeId on an AmneziaWG inbound, which every node then reconciles as an ordinary local inbound (nodes run the identical binary, full cron suite included), leaving it running unmanaged and untracked by the master's own AmneziaWG bookkeeping. Added isNodeEligibleProtocol (inbound_protocol.go), mirroring the frontend's allowlist, and enforced it in both AddInbound (the actually exploitable path -- nodeId comes straight from the request) and UpdateInbound (defense in depth; NodeID is already restored from the stored row there before this check, so it mainly guards against a protocol change on an existing node-hosted inbound). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): allow TPROXY-marked traffic through a default-deny INPUT chain TPROXY never rewrites a packet's own destination address, only the routing decision. A default-deny firewall whose INPUT chain sanity-checks "is this destination actually local" (UFW's ufw-not-local, via addrtype --dst-type LOCAL, is a concrete example) silently drops the redirected packet before Xray's socket ever sees it -- RouteThroughXray looked fully configured (TPROXY rule present and counting, Xray listening with IP_TRANSPARENT set) yet every peer's traffic vanished with no trace on either side. Adds an idempotent, never-torn-down "iptables -I INPUT 1 -m mark --mark <fwmark> -j ACCEPT" alongside the existing shared policy route, so this works regardless of which firewall manager owns the rest of the INPUT chain. * fix(frontend): give AmneziaWG the same UDP tag and its own tag color The Inbounds list only special-cased isWireguard/isHysteria for the "UDP" network badge, so an AmneziaWG row showed just the bare protocol tag with no transport badge next to it. Added the missing isAmneziawg flag (mirrors isWireguard exactly) and wired it into the same branch. Client-row protocol-color maps in ClientsPage/HostList had no amneziawg entry, silently falling back to grey -- ClientInfoModal already had amneziawg: 'yellow' from earlier work, these two just never got it. * feat(logs): show which AmneziaWG client an access-log line belongs to The dokodemo-door TPROXY bridge every AmneziaWG peer's traffic is routed through has no per-user identity, so Xray's own access log never carries an "email:" token for these lines -- the Access Logs modal showed a blank Email column for every in-*-udp row, even though every other protocol's rows show the client normally. The peer's decapsulated tunnel IP does survive as the log's "from" address, and that IP deterministically maps to exactly one configured peer. Builds a "<inbound tag>|<ip>" -> email index from the same AmneziaWG inbounds already parsed elsewhere (amneziawg.InstanceFromInbound), and fills in Email from it whenever the raw log line didn't have one. * fix(amneziawg): enable sniffing on the TPROXY bridge Domain-based Routing rules could never match RouteThroughXray traffic: an AmneziaWG peer resolves DNS itself, through the tunnel, before ever sending a packet, so the decapsulated traffic TPROXY hands to the bridge is already a bare destination IP with no domain name attached at the network layer. Every other inbound recovers this via sniffing (confirmed working for the stock wireguard inbound, which does have it configured); the bridge never got a sniffing block at all, so only tag/IP/network-based rules could ever match it -- any domain rule above it in the list was silently unreachable. * docs: add an AmneziaWG config page and list it as a supported protocol Closes the PR checklist gap: the feature shipped with zero mention on the docs site. Mirrors reality.mdx's structure (key settings, setup steps, config excerpt) and notes the Docker/multi-node/Telegram-bot caveats the PR itself is honest about not having confirmed. * fix: address the fresh review round on PR #6105 (8 findings) 1. hostRulesFingerprint didn't account for ForwardedPorts when RouteThroughXray was off, so re-IPing a peer with port-forwarding configured left stale DNAT rules pointing at an address the next peer could be handed. 2. Server/client config values (keys, email, I1) were never validated for control characters before being written into the generated .conf; a newline could smuggle a PostUp hook into awg-quick's parser. Added ValidateConfigValue at save time and a sanitizeConfigValue backstop at render time. 3. checkForwardedPortsConflict didn't scope to node_id IS NULL, so a port used only on a different node produced a false collision; also hoisted the panel-port/inbounds lookup out of the per-client loop (portConflictContext) so N clients cost one query, not N. 4. PostDown commands were ";"-joined and abort on the first failure; appendOrTrue makes teardown best-effort so an external firewall flush can't leave DNAT rules to accumulate across bounces. 5. The "ip rule list | grep -q" existence check could SIGPIPE under pipefail and re-add a duplicate rule; switched to grep -c >/dev/null. 6. Ported the vpn:// share-link format (base64url of the plain .conf text, matching the real AmneziaVPN app) onto this branch -- it had only ever landed on our own fork's main, so this PR branch was still on the old amneziawg://+query-params scheme our own docs no longer described. Also corrected the docs' install.sh claim (opt-in/ interactive, not automatic) and stale pre-opt-in comments in route_egress.go. 7. install.sh: Arch's ndppd install used pacman -Syu (full system upgrade) instead of -Sy like every other call in the script; and should_install_amneziawg re-prompted on every `x-ui update` even when awg was already installed. 8. CollectTraffic could clobber a concurrent restart's freshly-reset (empty) traffic baseline with stale pre-restart counters, since getPeerStats runs lock-free; now checks pointer identity before writing back. sweepOrphansLocked permanently disabled itself on a transient os.ReadDir failure instead of allowing a retry. go build/vet/test and frontend typecheck/lint/build/vitest all pass. * fix(install.sh): check the live sysctl value, not sysctl.conf text Reviewer feedback (cherts, PR #6105): grepping /etc/sysctl.conf for the setting name is unreliable -- many distros split sysctl config across /etc/sysctl.d/*.conf, and /etc/sysctl.conf can be a symlink into that directory, so the check can miss an already-active setting (harmless duplicate append) or match a disabled/commented line (forwarding silently stays off). Query the live value via `sysctl -n` instead, which is accurate regardless of which file set it. Applied the same fix to both the IPv6 and IPv4 checks for consistency. * fix: update inbound_amneziawg.go to the split buildInboundForLocalRuntime Same fork-only-file blind spot as the one caught on our own main after the 3.6.0 sync: upstream split buildRuntimeInboundForAPI into buildInboundForNodePush / buildInboundForLocalRuntime (part of the node-sync client-deletion fix, 5bc81dfd), updating every call site it could see. This file doesn't exist upstream, so it kept calling the old name even after the branch merged in that commit. * fix(frontend): recognize AmneziaWG's vpn:// scheme in share-link labels The shared link-tag/label helper (used by the client info modal, QR modal, and subscription page) had no entry for the vpn:// scheme AmneziaWG links use, so it fell through to the generic fallback: a plain "Vpn" tag with no color, and an empty remark/port that made the row's title fall back to "Link N" instead of the inbound's actual name:port — unlike every other protocol, which shows its real tag and label. vpn:// links are base64url of a plain .conf text (matching the real AmneziaVPN app's own share-link format), not a structured URL, so there's no query string or #hash to read a remark/port from. Decode the payload and pull the remark/endpoint back out of the .conf text directly instead. * fix(xray): force a full restart for TPROXY inbounds, never hot-add them Real incident: an AmneziaWG inbound with RouteThroughXray enabled lost all internet on that connection after a migration. Root-caused on the live box -- iptables TPROXY counters were incrementing (packets correctly redirected to 127.0.0.1:63110), but nothing was actually listening there (ss showed nothing on that port) until a full `systemctl restart x-ui`, after which the bridge came up immediately. Xray-core's gRPC AddInbound reports success for a new sockopt.tproxy inbound (internal/amneziawg's own Xray egress bridge is the only kind this fork ever generates) but doesn't reliably bind a working listener for it outside of process startup -- the bridge silently never comes up, and RouteThroughXray traffic goes nowhere until the next full restart happens to occur for an unrelated reason. diffInbounds already has this exact defensive pattern for REALITY inbounds ("a gRPC remove+add does not reliably rebuild the REALITY authenticator"), just never extended to TPROXY, and only in the already-existing-then-changed branch -- the "brand new inbound" branch had no such guard at all, which is exactly the path a freshly-enabled RouteThroughXray bridge takes. Added inboundUsesTproxy and wired it into both branches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): flag Xray for resync when a peer edit changes qualifying state Real production bug, root-caused on iiadmin-vps: updateAmneziaWGInbound/ AddInbound/DelInbound only ever updated the kernel interface via amneziawg.GetManager() -- they never called SetNeedRestart the way every other protocol's mutation path does (client_crud.go, inbound.go, etc. all do). injectAmneziawgEgress's TPROXY bridge inbound depends on InstanceFromInbound finding at least one qualifying peer plus RouteThroughXray, so an edit that flips that (first peer added, last one removed, RouteThroughXray toggled on) previously required a full panel restart before the bridge actually got created, with no error anywhere: the kernel interface would handshake fine, but traffic redirected into the bridge's TPROXY port went nowhere because nothing was listening there. diffInbounds/inboundUsesTproxy already correctly force a full restart for a brand new TPROXY inbound (bdee0a20) -- that part was never the bug. The gap was entirely upstream: nothing ever told Xray a resync was even needed. * fix(clients): reject AllowedIPs already used on another WireGuard/AmneziaWG inbound defaultWireguardClients/defaultAmneziaWGClients only ever checked uniqueness against their own inbound's client list, so two inbounds sharing a subnet (same protocol or not) could silently hand out or accept the same address -- the exact scenario behind a real duplicate-IP incident where a WireGuard and an AmneziaWG client both ended up on the same address. otherTunnelAllowedIPs now collects every address already claimed on every other tunnel inbound and folds it into both the auto-allocation pool and the manual-entry collision check, naming the other inbound in the error when it fires. * fix(frontend): add the missing AmneziaWG config download on the sub page The subscription page already gave WireGuard links their own "Config" block (copy/download/QR of the actual .conf, via wireguardConfigFromLink reversing the wireguard:// query params) but had no equivalent for AmneziaWG's vpn:// links -- its isWireguardLink gate never matched them, and no reverse-parse helper existed for this page specifically. Every other surface (InboundInfoModal, ClientInfoModal, ClientQrModal) already had this parity; this was the one page that didn't. Fixed by adding amneziawgConfigFromLink (inbound-link.ts), simpler than its WireGuard counterpart since a vpn:// payload already *is* the plain .conf text -- just base64url-decode it, no query-param reconstruction needed -- and wiring it into SubPage.tsx alongside the existing WireGuard block, reusing the same pages.clients.amneziaWgConfig label the other three surfaces already use. * fix(xray): force a full restart for password-auth SOCKS5 hot-apply Real production incident: editing a client under an AmneziaWG inbound left its embedded SOCKS5 relay's settings byte-different (a new account list), and Xray's gRPC remove+add hot swap silently dropped the account for a peer whose email contained non-ASCII characters -- its tunnel kept handshaking fine but all its traffic got rejected at the SOCKS5 layer, while every other peer on the same relay was unaffected. A full restart (reading the same JSON straight from disk) always produced the correct account list. socks isn't in userDiffableProtocols (that only covers vless/vmess/trojan's clients+email shape, not accounts+user), so any settings drift on this inbound fell through to the generic remove+add path. Forces a restart instead, the same defensive choice already made for REALITY and TPROXY -- scoped to auth:"password" specifically so the other, noauth SOCKS5 bridges (panel/node/mtproto egress) keep the cheaper hot path. * Fix Attach reusing one identity's address across wg/awg inbounds ClientService.Attach deliberately copies one identity's stored AllowedIPs into every WireGuard/AmneziaWG inbound it's attached to in the same call, so the same person gets the same tunnel address on every protocol they use. Its loop calls addInboundClient once per inbound, and each of those independently computes otherTunnelAllowedIPs -- so by the second inbound in the batch, the first inbound's just-written copy of this identity's own address looked like a cross-inbound collision against itself. Real production symptom this caused: detaching then re-attaching a client to both wg and awg failed with "wireguard: allowedIPs entry X is already used by a client on inbound 'awg' (#N)" -- the exact address the identity is supposed to keep, rejected as if it belonged to someone else. Add a selfEmails exclusion to otherTunnelAllowedIPs and populate it from the client(s) being processed at the one real call site. Safe unconditionally: ClientRecord.Email is globally unique, so a match can only ever be this same identity's own entry on a sibling inbound, never a genuine different client's address. Reproduced the underlying mechanism live (manual entry correctly rejected as a cross-inbound collision; fresh auto-allocation correctly avoided a used address) before writing the fix, to confirm the guard itself works and the bug is specifically in how Attach's per-inbound calls interact with it. * Attach: allocate fresh when re-attaching with no active tunnel The previous fix (82cc69f5) made Attach's own address-reuse correctly not collide with itself across inbounds -- but it still always reused an identity's stored AllowedIPs verbatim, even when that identity currently has zero WireGuard/AmneziaWG attachments at all. A real report from testing this live: an identity fully detached from both its wg and awg inbounds, then re-attached, got its old address back even though several lower addresses were free -- because nothing about being fully detached ever cleared the stored value Attach copies from. Add hasTunnelAttachment, checked once against the identity's CURRENT inbound set before Attach's loop runs: if none of its current inbounds is WireGuard/AmneziaWG, clear the stored AllowedIPs so this attach allocates fresh (matching what a brand-new client would get) instead of resurrecting an address nothing reserves anymore. Left alone when the identity already has an active tunnel elsewhere, so extending it to a second protocol still keeps a consistent address. * Fix TestOtherTunnelAllowedIPsExcludesSelfEmail's own test setup CI caught this: the "genuinely different client" (other@wg) was seeded onto the SAME inbound passed as excludeID, which otherTunnelAllowedIPs already excludes entirely regardless of the selfEmails fix -- so the assertion that its address is still reported could never have passed, proving nothing either way. Move it onto the sibling inbound alongside shared@id, which is what the test actually needs to exercise (two clients on one sibling, one excluded by email, one not). * Attach: never inherit an address that doesn't fit the target inbound hasTunnelAttachment (from the earlier fix, commit 51067f16) only asked "does this identity have ANY tunnel attachment", treating that as license to reuse its stored address verbatim on every inbound being attached. Real production case this missed: an identity's stored address came from WireGuard's own fallback subnet (10.0.0.0/24, used when that inbound has no other clients to infer a base from), then got attached to a second, AmneziaWG inbound configured for a completely different subnet (10.8.1.0/24). defaultAmneziaWGClients's already-set-AllowedIPs branch only checks for collisions, never subnet membership, so the mismatched address was accepted silently -- producing a peer that can never actually connect, since an AmneziaWG address must fall inside the kernel interface's own configured subnet to be routable at all. Add addressesFitAmneziaWGInbound, checked per inbound inside Attach's loop: if the inherited address doesn't fit the SPECIFIC inbound being attached, clear it just for that one so it gets a fresh, valid allocation instead, while other already-attached inbounds keep their existing values. WireGuard has no equivalent strict subnet requirement (allocateWireguardAddress can widen to a fallback pool for it), so this only ever constrains AmneziaWG targets. * Give WireGuard an explicit, admin-configurable subnet field WireGuard previously had no configurable subnet at all -- only an implicit one, either inferred from existing clients' own addresses (wireguardAllocationBase) or a hardcoded 10.0.0.0/24 fallback when none exist yet. AmneziaWG, by contrast, has always had a real server.subnetIp/subnetCidr field in its settings, editable in the UI. User request: give WireGuard the same treatment. Backend: explicitWireguardSubnetBase reads an optional subnetIp/ subnetCidr pair from the inbound's own settings JSON (mirroring AmneziaWG's defaultAmneziaWGSubnetBases). defaultWireguardClients checks it first; only when unset does it fall back to today's inference-from-existing-clients behavior, so an inbound saved before this field existed keeps working exactly as it always has. Frontend: subnetIp/subnetCidr added to WireguardInboundSettingsSchema and the inbound form (mirroring AmneziaWG's own field layout/labels), with a real default (10.0.0.0/24, the same value the backend already fell back to) seeded for newly created inbounds so the field starts populated and editable rather than blank. Translated across all 13 locales. This also structurally closes the class of bug fixed in 82cc69f5/291c47b3: with wg and awg subnets explicit and independently controllable, an admin who wants matching addresses across both protocols can configure them to actually agree, instead of one silently inheriting the other's incompatible range. * Split the client edit form's AllowedIPs into per-protocol fields A client attached to both WireGuard and AmneziaWG shared one AllowedIPs form field with a dynamically-switching label, so its two genuinely different addresses could never both be shown or edited correctly. Worse, Update/Create broadcast that one shared value to every attached wg/awg inbound with no subnet-fit check, so an ordinary edit save could silently overwrite one protocol's address with the other's -- the same bug class already fixed for Attach, but reachable from any client edit. model.Client gains an optional AllowedIPsByInbound map so a caller can send distinct values per inbound; Update/Create honor it and, when it's absent, clear a shared value that doesn't fit an AmneziaWG inbound's own subnet instead of writing it through. A new TunnelAllowedIPsByInbound read path feeds the real per-inbound address to the client edit form via GET, which now renders two separate, correctly-labeled fields whenever both protocols are attached (unchanged single dynamic field otherwise). * Regenerate openapi.json for the new allowedIPsByInbound field Follow-up to 878ee839: gen:zod (frontend/src/generated) was already regenerated and committed, but gen:api (frontend/public/openapi.json) wasn't, so CI's codegen drift check failed. * Fix build breakage from merging upstream main: Update() gained a limitHwid param Two of our own AllowedIPs tests (not present upstream, so the merge never flagged them as conflicting) still called the old 3-arg Update(inboundSvc, id, client) -- upstream's hardware-ID-limit feature added a required limitHwid parameter that every other caller in this package already passes. Also drop createDefaultInboundSettings from InboundsPage.tsx: the merge conflict resolution kept the import, but upstream's clone-payload refactor (buildClonePayload, inbound-clone.ts) already calls it internally now -- this file doesn't need it directly anymore. * Fix real bug: AmneziaWG clients rejected as "empty client ID" in 3 places Three switch statements on inbound.Protocol handle "wireguard" explicitly (checking client.PublicKey) but fall through to the default case for "amneziawg" (checking client.ID, which AmneziaWG clients never set -- they use PublicKey/Email like WireGuard, not the VMess/VLESS UUID field). This is what the 4 AllowedIPs tests were actually catching: UpdateInboundClient's newClientId derivation hit this same default branch, so every Update() on an AmneziaWG client returned "empty client ID" before ever reaching the AllowedIPs logic being tested. Fixed by adding "amneziawg" alongside "wireguard" in each switch: addInboundClient's per-client validation, UpdateInboundClient's newClientId derivation, and AddInbound's per-client validation (the third one wasn't hit by these tests, but has the identical bug -- creating a brand-new AmneziaWG inbound with a client attached would fail the same way). * refactor(amneziawg): rename Obfuscation20 to Obfuscation31, drop the dead mobile preset Mechanical rename ahead of the AmneziaWG 3.1 parameter work: the type, generator and prose all said 2.0, and the "mobile" generator preset was reachable only from its own test. No behavior change. * feat(amneziawg): AmneziaWG 3.1 obfuscation parameters (backend + generated schemas) Adds the 3.1 parameter surface to the inbound settings and both Go config emitters: I2-I5 signature packets, HeaderProtectionKey (base64 32-byte, shared server<->client), ContentPaddingAddition, the five handshake-timing randomization ranges (RekeyAfterTime/RekeyTimeout/RejectAfterTime/ KeepaliveTimeout/MaxHandshakeAttempts), and the RandomTrailers/ DisableCookies switches. Freshly generated sets fill everything except I2-I5 (matching Amnezia's own generator) with jittered ranges bracketing WireGuard's stock timing constants; every reject window starts >= 30s above the rekey window by construction. Empty fields stay off the wire, so blanking a field disables just that feature. Validation generalizes the H1-H4 range checker for the new uint32-range fields, requires min 1 on timers, cross-checks rekey-vs-reject, and demands a real 32-byte base64 header-protection key. The manager warns once per process when the installed awg tools predate 3.1 but an inbound uses 3.1 parameters (awg-quick rejects unknown keys with a generic error otherwise); apply still proceeds. Requires amneziawg-tools v3.1.20260812+ / module or amneziawg-go v3.1.20260814+ on the host. * feat(amneziawg): emit and randomize 3.1 parameters in the frontend Both client-config emitters (the vpn:// link builder and the clients-page .conf builder) now carry the 3.1 [Interface] lines in the same order as the Go emitters. The obfuscation randomizer moves out of InboundFormModal into a shared lib/xray/amneziawg-obfuscation.ts that also fills the new fields, and createDefaultAmneziawgInboundSettings switches from static values to that generator — a fresh inbound now really gets the unique fingerprint the docs promise instead of the same jc=5/jmin=10 set on every install. Schema parse-time defaults for the new fields stay ''/false on purpose: real values come only from the generator, so resaving an inbound never mutates its stored parameters. A new parity test pins the hand-written AmneziawgServerSchema to the generated ServerSettings key set, so a field added on one side can no longer silently vanish from configs. * feat(amneziawg): 3.1 form fields and translations Inbound form gains inputs for I2-I5, HeaderProtectionKey (filled by the existing obfuscation Regenerate button), ContentPaddingAddition, the five timing ranges, and the RandomTrailers/DisableCookies switches; the MTU input picks up the min=1 its schema already enforced. All 13 locales get the 19 new keys and drop the "2.0" branding from the s3/s4/i1 labels. * docs(amneziawg): document 3.1 parameters; install.sh kernel/version notes The AmneziaWG page's obfuscation section moves from the 2.0 to the 3.1 parameter set: table rows for I2-I5, HeaderProtectionKey, ContentPaddingAddition, the timing-randomization ranges and the RandomTrailers/DisableCookies switches, a requirements callout (tools v3.1.20260812+, module/awg-go v3.1.20260814+, Linux 6.7+ for the DKMS path), and a sample client .conf that matches what the panel actually emits (including the DNS defaults and PersistentKeepalive it always had). install.sh warns before a DKMS build on a pre-6.7 kernel and after any install that left pre-3.1 amneziawg-tools on PATH. Also updates the hosts API operation paths ({id} -> {groupId}) in the stale ru/zh/fa reference pages: syncing docs/public/openapi.json for the new AmneziaWG schema fields surfaced that rename, which had never been copied over, and the docs build fails on paths missing from the spec. * fix(amneziawg): reject control characters and canonicalize 3.1 range values Adversarial review of the 3.1 work surfaced a validation gap: base64.DecodeString silently ignores CR/LF, so a header-protection key that picked up a line wrap in transit decoded to a valid 32 bytes, passed validation, and was emitted verbatim into every client config — where the orphan second line breaks the import while the server (whose emitter strips control chars) keeps running with the correct key. The key and range validators now reject control characters outright. Also from the same review: range values are canonicalized on save ("110 - 140" -> "110-140", whitespace-only collapses to feature-off, closing a case where the server conf rendered an invalid blank-value line the client emitters omitted); the rekey/reject invariant is now enforced against WireGuard's 120s/180s defaults when only one side is set; and the structural fingerprint joins on "\n" instead of "|", which is a legal I1-I5 character and made adjacent free-text fields join-ambiguous. * fix(install): resolve latest release tag via web redirect to dodge API rate limits The non-interactive install smoke test resolved the release version through the unauthenticated GitHub API (api.github.com/.../releases/latest), which allows only 60 requests/hour per IP. The test installs twice in one run, and on shared CI runner IPs the second call gets rate-limited, returns no tag_name, and install.sh treats an empty version as fatal (exit 1) — the same "Failed to fetch x-ui version" real users hit behind CGNAT/shared addresses. resolve_latest_tag() now reads the tag from the github.com releases/latest web redirect (not subject to the API rate limit), falling back to the API only if the redirect yields nothing. Verified with the real deploy/test/smoke-noninteractive.sh (two installs, both green). * fix(amneziawg): three review findings on #6105, plus a comment trim 1. A peer's allowedIPs reached the generated .conf unvalidated and unsanitized, unlike email/publicKey/preSharedKey which normalizeAmneziaWGSettings already guards. A newline in an entry let a following "[Interface]" re-open the interface section, whose "PostUp = ..." awg-quick then runs as root on the next apply. Reproduced end to end against generateServerConfig. The save path now rejects and canonicalizes through normalizeWireguardAllowedIPs, and the render path sanitizes as a backstop for rows predating the validation (an upgrade, a restored backup, a direct DB edit). H1-H4 get the same render-time sanitize, and the two NIC name fields a plausibility check, since stripping control characters alone would still let a shell metacharacter into a root-executed PostUp line. 2. EgressPortForInbound is 63100 + inbound id, so an id past 2435 derives a port above 65535 -- and Xray rejects the whole generated config over one invalid port, taking every other protocol down with it. It now reports ok=false past the range, and both the Xray bridge and its TPROXY rules are skipped instead of emitting an impossible port. 3. The downloadable AmneziaWG .conf read ClientRecord.allowedIPs, a single shared column that holds the WireGuard address for an identity attached to both protocols -- the exact ambiguity tunnelAllowedIPs was added to resolve for the edit form. The info and QR modals already hydrate that field, so they now pass this inbound's own address to the builder. Also trims the comment blocks in the files touched here to the 2-line guidance in CLAUDE.md: internal/amneziawg alone carried 423 comment lines in over-long blocks against 118 for the comparable internal/mtproto, and is now at 110. Every non-obvious constraint is kept (the kernel S1/S2 rule, why PostDown is best-effort, why grep -c and not -q, why the fingerprints split three ways); the narration is gone. Two hot_diff.go comments pointed at an internal/amneziawgnet package and an injectAmneziawgnetSocks function that exist nowhere in the tree; the checks themselves are unchanged. * feat(logs): add an AmneziaWG log view to the overview The overview has an access-log view for Xray but nothing for AmneziaWG, so when a tunnel misbehaves there is no way to see it from the panel at all. A kernel tunnel logs no per-request lines, so the equivalent view is built from the two things it does expose: - Live per-peer activity from `awg show <iface> dump`, joined to the client email through the desired peer set: last handshake, endpoint, allowed IPs, cumulative transfer and online state, newest handshake first. - The panel's own AmneziaWG event lines (interface up/down, awg-quick failures, the pre-3.1 tools warning), which are what actually explain a peer being absent from the table. POST /panel/api/server/amneziawglogs/:count serves both, with the same count + filter contract GetXrayLogs uses, and the modal mirrors XrayLogModal's toolbar, auto-update, mobile cards and download. The action-bar button is gated on a new status.amneziawg.configured, which stays true while an inbound exists but its interface is down -- exactly when the event lines matter. Verified against a running panel: the endpoint returns the peer table and real event lines ("awg/awg-quick not found on PATH", "create config dir: permission denied"), and count and filter both narrow as documented. One of those lines surfaced a Debugf that had been rendering as "for inbound1:amneziawg:"; fixed here since it is now user-visible. * fix(amneziawg): stop double-counting a routed inbound's traffic injectAmneziawgEgress tags its Xray bridge with the AmneziaWG inbound's own tag, so the stock Routing page can target it. Xray therefore reports that bridge's bytes under the inbound's tag, and XrayTrafficJob feeds them to AddTraffic -- which accumulates -- on top of the same bytes AmneziaWGJob already reported from `awg show dump`. An inbound with routeThroughXray on counted roughly twice its real traffic, which also inflates the quota checks that read the same counters. The awg counters are the complete measure: every peer, whether or not TPROXY routed it, and the same wire bytes the per-client totals are built from, so they stay and the Xray rows are dropped. Per-client stats were never affected -- a dokodemo-door bridge has no per-user identity, so Xray emits no user>>>email rows for it. Filtering happens before every consumer, so the DB totals, the external traffic inform and the dashboard's live speed all read one source per inbound. The set of bridge tags now comes from a predicate shared with injectAmneziawgEgress itself, with a test that pins the two together -- naming one tag too few doubles the traffic again, one too many makes real traffic vanish. * fix(amneziawg): align the three .conf emitters on one peer field order The panel builds an AmneziaWG client .conf in three independent places, and they disagreed: buildAmneziaWGClientConfig put PresharedKey right after PublicKey (wg-quick(8)'s own order, and what both WireGuard emitters on the clients side already use), while genAmneziaWGConfig and the Go amneziaWGConfigText put it after Endpoint. A user comparing a subscription link against a downloaded .conf sees the difference immediately, and the generators are exactly the kind of parallel implementation CLAUDE.md warns about drifting. Moves the two outliers onto the wg-quick order. Also drops the stray trailing newline that only appeared when PersistentKeepalive was set, so a config now always ends on its last set field whichever that is -- the same shape all three emitters produce for the same client. Parsing is unaffected either way (the format is order-insensitive, and the AmneziaVPN app reads it as a flat key-value bag), so this changes only the rendered text. Adds a test on each side that pins the peer block's field order, since nothing previously asserted it. * refactor(amneziawg): switch to the embedded amneziawg-go/gVisor architecture Replaces the kernel-module (DKMS) + awg-quick + TPROXY backend with the fork's own embedded design: amneziawg-go runs in-process over a userspace gVisor netstack, and each peer's decapsulated traffic relays into its own loopback Xray SOCKS5 inbound, so Xray's native stats/sniffing/routing work for free instead of through hand-rolled bridges. No kernel module, no DKMS, no Secure Boot conflicts, works the same in a container as on bare metal. - internal/amneziawgnet: new package (Device/UAPI, gVisor netstack, TCP/UDP forwarding, SOCKS5 relay, peer identity, IPv6 host-alias egress identity, per-client port-forwarding) - amneziawg-go v3.1.20260814 + gvisor. - internal/amneziawg: keep the reusable protocol-shape types/validation (Instance/Peer/Obfuscation, InstanceFromInbound); drop the OS-shellout half (awg-quick, TPROXY policy routing, NDP proxy, peer-stats parsing). - internal/web/service: rewire the 5 integration points (job, runtime, client-apply, web shutdown, xray config) from the old manager to the new one; the AmneziaWG log view is rebuilt on the embedded Device's own UAPI dump (extended to carry endpoint/AllowedIPs) instead of `awg show dump`. - install.sh: drop DKMS/ndppd/TPROXY/Secure-Boot installer code (~250 lines) - an entire recurring class of installer fragility goes away. - frontend: drop the now-meaningless routeThroughXray toggle (the relay is always on); keep the field in the Zod schema, unexposed, so it isn't silently stripped from stored settings on next save - two regression tests deliberately depend on the Go struct still carrying it. - docs/i18n: rewrite amneziawg.mdx for the new architecture; drop the dead routeThroughXray translation keys across all 13 locales. Real production throughput (embedded core datapath, isolated bench, same box the kernel-module path was measured on): ~296 Mbit/s up, ~640 Mbit/s down, vs. 414.69 MB/s (~3.3 Gbit/s) for the kernel module on the same hardware - a real gap, tempered by this being single-stream/no-SOCKS5-hop and most VPN traffic being latency-bound rather than throughput-saturating. * fix(amneziawg): restore the branch's own Obfuscation31 shape + 2 CodeQL findings The previous push's wholesale-copy of types.go/params.go from the fork's main branch pulled in that branch's own independent (and incompatible) naming for the same AWG 3.1 feature set: Obfuscation20/GenerateObfuscation20 instead of this branch's already-shipped Obfuscation31/GenerateObfuscation31, and a missing CanonicalizeUintRange -- broke every Go CI job (the whole matrix fails to compile when any one package doesn't, which is why govulncheck/ golangci/postgres-durable-first/race all failed identically, not just go-test). Restores params.go/params_test.go verbatim from this branch's own last commit (a strict superset of validation: it already cross-checks rekey vs. reject timing windows, which the copied version never did) and folds the 3.0/3.1 fields (HeaderProtectionKey, ContentPaddingAddition, the 5 timing fields, RandomTrailers/DisableCookies) into Obfuscation31 itself, matching the original struct exactly instead of as separate top-level Instance fields. instance.go, the two amneziawgnet call sites, and 7 amneziawgnet test files updated to match. Also drops the one test (sanitizeConfigValue) that only ever served the retired kernel-module .conf writer -- correctly not ported, so the test testing it shouldn't have been copied either. Also fixes 2 CodeQL findings the same push surfaced: a clamped uint64->int64 conversion for the new log view's live byte counters (server.go), and an unneeded len+len sum feeding a slice pre-size in the v6-egress outbound merge (xray.go) -- append already grows correctly without it. * chore(amneziawg): regenerate frontend schemas for updated doc comments npm run gen was missed after the previous commit's types.go doc-comment edits (Obfuscation20 -> Obfuscation31, ValidateHeaderProtection -> ValidateObfuscation in the prose) -- openapigen bakes those comments into the generated schema's description field, so the committed frontend/src/generated/schemas.ts and openapi.json still had the old wording. codegen's git-diff-exit-code check caught it correctly. * fix(amneziawg): narrow 2 test fixtures that collided with MaxForwardedPorts TestCheckForwardedPortsConflict_CollidesWithEnabledInboundPort and ..._NoCollisionWhenPortsDontOverlap used "8000-8100"/"9000-9100" as their ForwardedPorts fixture -- 101 ports each, one over MaxForwardedPorts (100). The cap check (checkForwardedPortsConflict, added this session alongside the SOCKS-phantom-port check) fires first, so both tests got "more than 100 forwarded ports" instead of ever reaching the collision logic they're actually testing. The cap itself has its own dedicated boundary test already; these two just needed a narrower range that still covers/misses port 8080 as intended -- 8075-8085 and 9075-9085, 11 ports each. * fix(amneziawg): checkAmneziawgnetSocksConflict had no receiver in its new home My merge-conflict resolution kept this as a method call (s.checkAmneziawgnetSocksConflict) inside checkPortConflictTx, a plain function with no *InboundService receiver -- upstream's #6225 fix moved the port-conflict check out of the (s *InboundService) method and into this new tx-scoped free function, and I didn't notice the call site needed to change shape too. CI caught it immediately (undefined: s); nothing in this specific package can be locally verified past internal/database's own unrelated, pre-existing CGO build issue on this dev machine. Since the signature had to change either way, folded in the fix already flagged as a separate follow-up: checkAmneziawgnetSocksConflict now takes the caller's db handle instead of fetching its own via database.GetDB(), so it actually runs inside the same serialized transaction #6225 introduced -- previously it sat right next to that race fix without benefiting from it. * fix: address the review findings on the embedded AmneziaWG PR 5 blocking findings: - Floor S3/S4 at 12 in both obfuscation generators (Go and frontend) and reject a hand-edited value below that when HeaderProtectionKey is set -- IpcSet requires it, and ~39% of previously-generated sets violated it silently. - Guard PrivateKey/PrimaryDNS/SecondaryDNS/remark against newline injection in the AmneziaWG .conf builder (both the Go subscription-link path and the frontend downloadable-config path) -- unguarded, any of them could inject an arbitrary config line into a subscriber's client. - Bound the derived AmneziaWG SOCKS relay port to <= 65535 once an inbound's id is known, and check the reverse direction (does the relay port collide with an existing inbound's port) on both create and update -- previously only port -> relay collisions were checked, not relay -> port. - Gate injectAmneziawgV6Egress on the same V6AliasesActive predicate desiredV6Aliases already uses, so the two can't disagree about whether a peer's IPv6 identity is actually active at the OS level. 2 minor findings: - Fix the forwarded-ports cap check's off-by-one (a spec covering exactly the cap was rejected as if it were over it). - Correct docker-compose.yml's stale comment describing the retired DKMS/kernel-module architecture. * chore: retrigger CI build (armv5) failed on a transient Go module proxy network error (INTERNAL_ERROR stream reset on sagernet/sing), unrelated to this PR's changes. * docs: fix doc comments still describing the retired DKMS/awg-quick design A few doc comments (and one illustrative test log line) survived the embedded-architecture cutover unchanged and now contradict the code they sit next to: - internal/amneziawg/types.go's package comment claimed this package still owns a Manager that reconciles OS-level interfaces via awg-quick/DKMS -- that Manager was removed; the reconcile loop lives in internal/amneziawgnet now, and this package is protocol-shape-only. - internal/amneziawg/params.go's ValidateObfuscation/ValidateConfigValue comments cited "awg-quick up" / "awg-quick executes as root" as the reason to validate -- the server itself never calls awg-quick in this architecture; the same value still reaches a real rendered .conf that a client app or an admin's own awg-quick CLI applies downstream, so the validation is still warranted, just for a different consumer. Mirrored the same fix in inbound_amneziawg.go's matching comment and its test's comment. - internal/amneziawgnet/manager.go's Manager doc comments (x3) pointed readers at "internal/amneziawg.Manager" for comparison -- that type no longer exists in this diff at all. Repointed at internal/mtproto.Manager, the pattern this was actually modeled on and the one that's still real. - Swapped one test's illustrative "awg-quick up awg2 failed" log line for a message shaped like this architecture's actual amneziawgnet logging, so a reader skimming the test doesn't wonder whether the server still shells out to awg-quick. No behavior change. * fix(docs): re-run codegen for xray-settings.mdx after conflict merge The automated conflict-resolution hand-merge for this generated file was content-correct but didn't byte-match a real regen (different YAML long-string folding style). Re-ran npm run gen + docs' gen:api and kept that canonical output instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): drop the dead access-log email backfill amneziawgEmailIndex keyed peers by "<tag>|<tunnel IP>", a scheme built for the retired TPROXY bridge where the peer's decapsulated tunnel address survived as the access log's from-address. The embedded architecture relays through a loopback SOCKS5 dial, so every AmneziaWG log line's from-address is 127.0.0.1:<ephemeral> and the lookup could never match: the index was rebuilt on every log view just to miss. Remove the index, its GetXrayLogs wiring and its test. If per-line emails are wanted back, the relay would have to publish a local-port->email registry for the viewer to resolve loopback sources. * fix(api): generate AmneziaWGLogs/PeerActivity schemas instead of hand-writing them The amneziawglogs endpoint's response structs were missing from openapigen's StructAllow, so they were silently absent from every generated schema/example, the endpoints.ts entry carried a hand-written response, and AmneziaWGLogModal.tsx duplicated the shapes as local interfaces - the exact drift the allowlist rule exists to prevent. Allowlist both structs with example tags, point the endpoint at the generated schema, import the generated types in the modal, and sync docs/public/openapi.json. * chore(amneziawg): drop the unreferenced quiccapture package Nothing imports internal/amneziawg/quiccapture and no route exposes it; its package doc justifies the code as a port of frontend/src/lib/xray/i1Generators.ts, which does not exist in this repository, and promises an API round-trip that also does not exist. 1,110 lines of unreachable code with misleading provenance claims. Revert this commit to bring the package back when the live-capture I1 feature and its frontend counterpart actually land. * fix(clients): re-run cross-inbound conflict checks on the serialized writer The new client-level checks - cross-inbound AllowedIPs collisions and AmneziaWG forwardedPorts conflicts - read a fresh DB snapshot, decide, and only then enter runSerializedTx, while lockInbound only serializes writers on the SAME inbound. Two concurrent client creates on two different tunnel inbounds both passed the read and both committed, yielding two peers with one address: the exact check-then-claim race 81cfd857 (#6225) closed for AddInbound, which this PR's own checkAmneziawgnetSocksReverseConflict already cites. Keep the pre-tx pass for fail-fast UX and re-validate inside the transaction, where the single writer makes the answer authoritative. The race test drives two goroutines at two inbounds and demands exactly one winner; it fails with committed=2 when the in-tx re-check is removed. * fix(amneziawg): hot-apply depletion disables like mtproto does applyTrafficMutationBatch special-cases MTProto so a quota/expiry depletion cuts the sidecar immediately, but AmneziaWG fell through to runtime AddUser/RemoveUser - explicit no-ops for this protocol - so a depleted peer kept tunneling until the next 10s reconcile tick. Route it through applyLocalAmneziaWG, whose own contract (re-read committed settings, filter depleted clients, push to the interface) is exactly this case; the comment claiming it mirrors applyLocalMtproto is now true for the depletion path too. * fix(amneziawg): persist cleared DNS fields instead of resurrecting defaults PrimaryDNS/SecondaryDNS marshaled with omitempty, so clearing them persisted settings with no key at all - and the frontend re-parses stored settings through a Zod schema whose .default('8.8.8.8') / .default('8.8.4.4') fire on missing keys, silently repopulating the form on every load and re-persisting the defaults on the next save. Blank is a documented, meaningful state (no DNS line in client configs); drop omitempty so a cleared value survives the round-trip. The regression test normalizes a server block with cleared DNS and fails when the keys are dropped. * fix(amneziawg): accept cleared numeric obfuscation/subnet fields in the form AntD InputNumber emits null when cleared, Zod .default() only replaces undefined, and unlike wireguard.ts - whose optionalClearedInt comment documents exactly this failure mode - the AmneziaWG schema declared subnetCidr and jc/jmin/jmax/s1-s4 as bare z.number() defaults. Clearing any of the eight fields made safeParse reject the null and block the save until the user retyped a value. Absorb null into undefined while keeping each field's schema default, so a cleared field refills its documented default and legacy blobs with absent keys behave as before. * fix(amneziawg): guard the third .conf emitter against newline injection The review-round fix added the newline guard to amneziaWGConfigText (Go) and buildAmneziaWGClientConfig, but genAmneziaWGConfig in inbound-link.ts - the third of the three emitters its own comment says must not drift - still rendered privateKey/primaryDns/secondaryDns/remark unescaped, so a newline there injected a config line (e.g. a rogue PostUp) into the inbound form's downloaded .conf. Add the same guard, plus the regression tests the original fix shipped without: all four fields on the Go and both frontend emitters go red if any guard is removed. * test(amneziawg): pin the S3/S4 floors the TS drift guard claims to mirror The test's docstring says it mirrors internal/amneziawg/params_test.go, but it asserted S3>=8/S4>=4 while the Go test and both generators pin 12/12 - the floor ValidateObfuscation enforces whenever a header protection key is set, which this generator always sets. A regression narrowing the TS floors into 8-11/4-11 would have passed the drift guard and produced configs the backend rejects on save. * docs: restore the pia repo-map entry and document the AmneziaWG subsystem Merging main dropped CLAUDE.md's internal/pia/ bullet (added by #6272) while resolving the repo-map conflict - the package itself is untouched. Restore it, add the missing map entries for the two packages this branch introduces (internal/amneziawg/, internal/amneziawgnet/), bump the cron count, and give amneziawg_job its row in architecture.md's 5.4 table. * chore(amneziawg): correct comments stranded by the architecture pivot ae77c7e9's cutover to the embedded gVisor path deleted the kernel-module code but left several comments describing it in the present tense: hot_diff.go cited the removed service.amneziawgEgressStreamSettings and wrongly claimed AmneziaWG is the only sockopt.tproxy source (tunnel's TProxy mode is the live one the guard protects), socks_config.go pointed at the deleted EgressBasePort/EgressPortForInbound, manager.go referred to the deleted Manager and its fingerprinting as live code, web.go's cron registration claimed the job scrapes traffic (its own doc says it does not), and types.go capped ContentPaddingAddition at uint16 when validation and upstream both use uint32. * style(lint): satisfy gofumpt/goimports so make verify is green json_service.go's two 'Tag: "proxy"}' literals came in with main's own cc245a90 formatting commit and fail the repo's gofumpt gate for everyone; the import grouping in inbound_amneziawg.go is from the serialized-writer fix on this branch. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-08-24 02:41:15 +02:00
Seyed Ali Shahrokhi	79e65f63df	fix(xray): validate generated egress targets (#5989) ... * fix(xray): validate panel egress target Avoid generating a loopback panel bridge and routing rule when a saved panel outbound disappears after an outbound subscription refresh. Preserve routing unchanged and log the missing target instead. * fix(xray): guard node and mtproto egress Apply the fail-closed target check to every generated egress bridge. Skip node and MTProto bridge injection when a selected outbound disappears or the relevant JSON cannot be parsed. * test(xray): complete node egress coverage Cover tag and port collisions plus absent and malformed routing. Clarify the fail-closed bridge behavior in the panel and MTProto egress documentation.	2026-07-21 15:57:34 +02:00
Sanaei	6214ff4edc	fix(mtproto): stop dropping connections on client/inbound edits; add live updates + ad-tag (#5838) ... * fix(mtproto): split the mtg fingerprint into structural and secrets parts A reordered clients array in the stored settings used to read as a config change because the fingerprint concatenated secrets in array order, and one opaque fingerprint could not tell a restart-worthy change (bind address, fronting, throttle) from a secret-set change a reload-capable mtg can absorb in place. Sort the secret pairs so order stops mattering, and split the value so the upcoming hot-reload path can decide between keeping, reloading, and restarting the process. * fix(mtproto): stop restarting mtg on every inbound edit Saving an mtproto inbound tore down and respawned its mtg sidecar even when nothing material changed, dropping every live Telegram connection: the update path pushed DelInbound+AddInbound, and Remove deletes the manager's map entry, so Ensure's fingerprint no-op gate could never fire. Route mtproto updates through a single Ensure call so an edit that leaves the generated TOML alone keeps the process, and only real config changes restart it. Capturing the pre-edit protocol also fixes a latent leak: changing an inbound's protocol away from mtproto never stopped the sidecar, because the snapshot handed to the runtime already carried the new protocol and the removal took the xray branch, leaving an orphaned mtg holding the port. An mtproto push failure no longer requests an xray restart - xray cannot fix the sidecar, and the 10s reconcile job self-heals it. The regression test fakes mtg by re-executing the test binary, counting spawns through a pid file: an unchanged save and a remark-only edit must keep the process, a re-keyed secret must restart it. * fix(mtproto): exclude depleted clients from the reconcile job to match the sync push The 10s reconcile job derived mtg secret sets from raw inbound settings while the interactive push filtered clients through buildRuntimeInboundForAPI, which drops client_traffics-disabled (depleted or expired) clients. The two paths therefore disagreed on the fingerprint - each disagreement one needless mtg restart dropping live connections - and worse, the job kept serving depleted clients' secrets indefinitely, so running out of traffic never actually cut an mtproto client's access. DesiredMtprotoInstances now builds the job's desired state with the same depletion overlay the push uses (one bulk client_traffics query), drops inbounds whose every secret is filtered away so their sidecar stops, and AddInbound pushes the filtered payload too so an imported inbound carrying disabled stats does not seed a fingerprint the next reconcile disagrees with. * feat(mtproto): hot-reload mtg secrets in place instead of restarting A client add, removal, re-key, or enable-toggle changes only the [secrets] section of the generated config, yet the panel could apply it only by killing and respawning the mtg sidecar, dropping every Telegram connection on that inbound. Split the ensure decision three ways: an identical config is a no-op, a secrets-only change rewrites the TOML on the same api port and asks mtg to hot-swap it via POST /reload, and a structural change (or a failed reload) falls back to the full stop-and-start. The reload endpoint is served by the mhsanaei/mtg-multi fork; against an older binary the POST 404s and the manager restarts exactly as before, so panel and binary upgrades stay order-independent. * feat(mtproto): apply single-client edits to the sidecar immediately Client CRUD on an mtproto inbound was a runtime no-op, so an add, delete, re-key, or enable-toggle only reached mtg on the next 10s reconcile. With the sidecar now able to hot-reload, push the change straight after the edit commits: applyLocalMtproto rebuilds the inbound's filtered client set and re-applies it, so a new client works within a moment (and, on a reload-capable binary, without disturbing the others) and deleting the last client stops the process. The three interactive single-client paths (add, update, delete) call it; bulk operations still ride the reconcile job, which converges to the same state. * chore(mtproto): pin mtg-multi to the mhsanaei fork v1.13.3 The reload endpoint the panel now uses lives in the mhsanaei/mtg-multi fork, so point the source-build pin (DockerInit.sh + both release.yml matrices) at it and bump to v1.13.3. The install still produces the same mtg-multi binary name, so the mtg-<os>-<arch> rename and everything downstream are unchanged. Docs and the package comment note the hot-reload path and its restart fallback. * feat(mtproto): apply live secret updates via the management API and add ad-tag Two capabilities the mhsanaei/mtg-multi v1.13.3 fork exposes are now surfaced by the sidecar manager. Live updates go through PUT /secrets on the fork's management API instead of POST /reload: the panel already holds the whole desired set per inbound, so it sends secrets and the advertising tag as one JSON call that mtg applies atomically, keeping every unchanged connection and closing only removed or re-keyed ones. The config file is still written first so a restart or crash recovery reproduces the state, and any non-200 (an older binary, a refused connection) still falls back to a full restart. Per-inbound ad-tag adds an optional 32-hex Telegram advertising tag plus public-ipv4/public-ipv6 overrides. The ad-tag rides the reloadable secrets fingerprint, so changing it hot-applies without dropping connections; the public IPs are proxy-construction parameters and sit in the structural fingerprint, so a change there restarts the process. Empty public IPs are omitted so mtg auto-detects the reachable address. * feat(inbounds): expose the mtproto ad-tag and public IP in the inbound form Adds an Ad-tag field (validated as 32 hex characters) plus optional Public IPv4 and Public IPv6 overrides to the MTProto inbound form, backed by the same-named settings the sidecar writes into the mtg config. The public IPs are optional — left blank, mtg auto-detects the reachable address the ad-tag middle proxy needs. English strings are added to every locale; the non-English ones carry the English text until translated and fall back to it meanwhile. * ci(mtproto): install mtg-multi from prebuilt release binaries The fork now publishes release archives for every platform we package, so download and unpack the matching mtg-multi-<ver>-<os>-<arch> binary instead of compiling it from source with go install. Faster builds and no toolchain step, and the archive's platform labels line up with our matrix; the produced mtg-<os>-<arch> filenames are unchanged. * i18n(mtproto): localize the ad-tag and public IP strings The six mtgAdTag*/mtgPublicIp* keys shipped with English text in every locale as a placeholder. Translate them into the twelve non-English locales (Arabic, Spanish, Persian, Indonesian, Japanese, Portuguese-BR, Russian, Turkish, Ukrainian, Vietnamese, and Simplified/Traditional Chinese); en-US is unchanged. * retired goreportcard.com	2026-07-07 01:13:24 +02:00
MHSanaei	5eec178483	feat(mtproto): route Telegram egress through Xray routing rules ... Add a per-inbound "Route through Xray" toggle (off by default) plus an optional outbound picker on MTProto inbounds. mtg only supports a SOCKS5 upstream, so when enabled the panel injects a loopback SOCKS bridge into the generated Xray config — tagged with the inbound's own tag — and mtg dials Telegram through it via a [network] proxies upstream. The router then governs Telegram egress: matchable in the Routing tab, or forced to a chosen outbound/balancer via the picker. - mtproto: Instance carries RouteThroughXray + XrayRoutePort (in the fingerprint); InstanceFromInbound parses them; renderConfig emits the socks5 [network] upstream; freeLocalPort exported as FreeLocalPort. - xray.go: injectMtprotoEgress appends the loopback SOCKS bridge and prepends an optional inboundTag->outbound/balancer rule, hot-appliable like injectPanelEgress. - inbound.go: backend-owned egress port persisted in settings, allocated once and carried across edits (stored value wins); stripped with the inert outboundTag when routing is off; allocation failure fails the save; routed add/update/del force a config regen. - mtproto_job: skip folding mtg metrics for routed inbounds (the bridge, carrying the inbound tag, is metered by xray_traffic_job) to avoid double-counting. - frontend: toggle + outbound/balancer Select (useOutboundTags) on the MTProto form; i18n keys for all locales.	2026-06-12 17:58:45 +02:00
MHSanaei	8578b229ce	feat(settings): allow a balancer as the panel traffic outbound ... The panel egress is injected as a routing rule, so a routing balancer is a valid target for it (unlike the geodata download, which dials a forced outbound tag and bypasses the router). Surface routing balancers in the panel outbound picker as a separate group, and emit balancerTag instead of outboundTag in the injected egress rule when the configured tag names a balancer, so the panel's own traffic load-balances across its members.	2026-06-11 23:32:58 +02:00
MHSanaei	7bcc5830c6	feat(online): use xray online-stats API for onlines and access-log-free IP limit ... Adopt xray-core's statsUserOnline policy and GetUsersStats RPC so online detection is connection-based and IP limiting no longer requires an access log. Falls back to the legacy traffic-delta onlines and access-log parsing when the running core lacks the RPCs (Unimplemented), probed lazily per process so a panel-driven version switch re-evaluates automatically. Backend: - xray/api.go: GetOnlineUsers (one GetUsersStats call returns all online users and their source IPs) and IsUnimplementedErr. - xray/process.go: per-process OnlineAPISupport tri-state capability cache. - service/xray.go: ensureStatsPolicy injects statsUserOnline into every policy level of the generated config; XrayService.GetOnlineUsers probes and falls back. - job/xray_traffic_job.go: union API onlines into the delta-derived active set; bump last_online for idle-but-connected clients. - job/check_client_ip_job.go: API-first IP source with shared enforcement; live observations bypass the 30-min stale cutoff; access-log path unchanged for older cores. - service/setting.go: GetIpLimitEnable always true; new accessLogEnable default for features that genuinely read the access log. Frontend: - Client form split into Basic and Config tabs; IP Limit and IP Log no longer gated on access log; compact Auto Renew next to Start After First Use; tabBasic/tabConfig added to all 13 locales. - Xray logs button on the dashboard now gated on accessLogEnable.	2026-06-11 19:42:03 +02:00
MHSanaei	ca4f32e3da	feat: replace panel proxy URL with outbound-based egress bridge ... Instead of requiring a manual SOCKS5/HTTP URL, the panel now lets the admin pick an Xray outbound from a dropdown (same UX as Geodata Auto-Update). At runtime, injectPanelEgress appends a loopback SOCKS inbound (tag: panel-egress) and prepends a routing rule so the panel's own HTTP traffic — version checks, Telegram, normal geo-file updates — is routed through the chosen outbound. Xray-native Geodata Auto-Update is unaffected (it uses its own geodata.outbound inside Xray). Blackhole outbounds are excluded from both picker dropdowns since routing any download through one just drops it. Translations updated for all 13 locales.	2026-06-10 23:52:20 +02:00
MHSanaei	6b16d8c37a	feat: apply inbound/outbound/routing changes live via Xray gRPC API ... Add a hot-apply layer that computes a diff between the old and new generated config and applies only the changed parts through the Xray gRPC HandlerService and RoutingService, avoiding a full process restart whenever possible. A restart is still performed when sections that have no reload API (log, dns, policy, observatory, ...) actually change. Key additions: - internal/xray/hot_diff.go: ComputeHotDiff with canonical-JSON comparison (sorted keys, null=absent, full number precision) so UI reformatting never triggers a spurious restart - internal/xray/api.go: AddOutbound/DelOutbound, ApplyRoutingConfig, GetBalancerInfo, SetBalancerTarget, TestRoute gRPC wrappers - internal/web/service/xray.go: tryHotApply, ensureAPIServices, GetBalancersStatus, OverrideBalancer, TestRoute service methods - internal/web/controller/xray_setting.go: balancerStatus, balancerOverride, routeTest API endpoints - frontend: BalancersTab live-status/override columns, RouteTester component, Restart button removed (Save now hot-applies) - balancer-helpers.ts: syncObservatories never creates observatory sections for random/roundRobin balancers (no reload API → restart) - i18n: balancerLive/Override/routeTester keys added to all 13 locales	2026-06-10 23:01:33 +02:00