xah30
f68a61f760
Two bugs found in the GUI's first end-to-end test: ## #41 was incomplete — `Some("")` is not the same as `None` for tun-rs The agent's earlier #41 fix passed `""` to `Configuration::tun_name()` expecting the tun crate to treat empty as "let the kernel auto-assign". It doesn't. Looking at tun-0.8.9/src/platform/macos/device.rs: if !tun_name.starts_with("utun") { return Err(Error::InvalidName); } An empty string fails `starts_with("utun")` so the create errors out before the kernel is ever consulted. The auto-assign branch ONLY triggers when `config.tun_name` is `None` — which requires us to skip the `.tun_name()` call entirely, not pass a sentinel value. Fix: split the builder chain so `.tun_name()` is only called when the sanitized name is non-empty. The kernel now correctly auto-picks the next free `utunN` for the standard provisioned `tun_name = "aura0"` config. User-visible symptom this resolves: the GUI's Connect button consistently died with `failed to create TUN device 'aura0'` followed by an InvalidName chain, even though aura was running as root. ## check_admin_access tested the wrong command shape `check_admin_access` ran `sudo -n <aura> --help` and inferred the sudoers entry was installed iff that succeeded. But our sudoers entry is scoped to `<aura> client *` — `<aura> --help` does NOT match, so even when the entry was correctly installed and Connect was already working, the yellow "One-time setup needed" banner stayed up forever. Switched to `sudo -n -l <aura>` which lists matching sudoers entries for the binary path itself. Returns 0 iff ANY entry covers it without a password — works regardless of the per-command scope. ## Verification - `cargo test -p aura-tunnel --lib tun` — all 3 sanitize / create tests pass - Rebuilt `target/release/aura` and `/Applications/Aura.app` against the fixes - Confirmed via `sudo -n -l /Users/xah30/AuraVPN/target/release/aura` that the installed sudoers entry is detectable by the new check 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
aura-gui — desktop client for AuraVPN
A Tauri 2 + React TypeScript app that runs in the system tray. It's the GUI front-end for the
existing aura CLI: import a provisioned bundle (.tgz), pick a profile, hit Connect, watch
the live tunnel status. No clash-verge replacement and no protocol patching — just a thin
manager around the existing CLI.
Status
v0.1 (MVP) — scaffolding + core flows. Working:
- ✅ Profile list / import / delete (drop in a
provision-client.tgzand you're set) - ✅ Connect / Disconnect (spawns / kills
aura clientper profile) - ✅ Live status panel (peer, tx/rx packets, default action, rules) via admin socket
- ✅ System tray with Open / Disconnect / Quit menu
- ✅ Close button hides to tray (app stays alive in background)
Deferred for v0.2:
- Auto-start at login (launchd plist / systemd user unit / Windows Run key)
- Code signing + notarization (macOS) / Authenticode (Windows)
- Per-profile route overrides editor
- Live log streaming (currently polled, frontend tails the in-memory ring)
- Admin status query on Windows (uses Unix sockets today; need named pipe support)
Layout
aura-gui/
├── src-tauri/ (Rust 2 backend, separate Cargo manifest)
│ ├── src/
│ │ ├── lib.rs (Tauri commands + tray + window plumbing)
│ │ ├── profiles.rs ([app_data]/profiles/ I/O + .tgz import)
│ │ ├── cli_proc.rs (spawns aura client + stderr ring buffer)
│ │ └── admin.rs (JSON-line admin socket client)
│ ├── Cargo.toml
│ └── tauri.conf.json
├── src/ (React TS frontend)
│ ├── App.tsx
│ └── App.css
├── package.json
└── README.md (this file)
The src-tauri/ crate is intentionally excluded from the workspace at the repo root
(workspace.exclude = ["aura-gui"]) so cargo check --workspace from the project root keeps
checking just the protocol crates and doesn't pull tauri/wry/webview into every CI run.
Build
# Backend deps come down with cargo at build time
cd aura-gui
npm install # ~10 s, downloads vite + React 19
npm run build # frontend tsc + vite build → dist/
npm run tauri build # full bundle: .dmg / .deb / .msi / .AppImage
For dev:
npm run tauri dev
The first build downloads ~200 MB of native deps (tauri, wry, webview) — subsequent builds are fast (incremental).
Profile storage
Per-platform app-data dir:
| OS | Path |
|---|---|
| macOS | ~/Library/Application Support/ru.undergr0und.aura/profiles/ |
| Linux | ~/.config/AuraVPN/profiles/ |
| Windows | %APPDATA%\AuraVPN\profiles\ |
Each profile is a directory with the same shape as aura provision-client emits:
profiles/<id>/
├── client.toml
├── ca.crt
├── client.crt
├── client.key
└── bridges.signed (optional, v3.3+)
The id is the basename of the imported .tgz (e.g. client-1.tgz → profiles/client-1/).
Aura binary path
The GUI shells out to aura client for each connection. It defaults to:
/Users/xah30/AuraVPN/target/release/auraif present (dev convenience),/usr/local/bin/auraon Unix,C:\Program Files\AuraVPN\aura.exeon Windows.
Change it at runtime via the "Change…" button at the bottom of the window. The setting is session-only for now (persisting it to a config file is a v0.2 todo).
Sudo / admin privileges
aura client creates a TUN device, which needs root on Unix and Administrator on Windows.
Currently the GUI does not run with elevated privileges — the operator must launch it from
a privileged shell, or via sudo open -a aura-gui on macOS, etc.
v0.2 will add a polkit / authorization-services prompt for the privileged step.
Why not just patch clash-verge?
We thought about it. AuraVPN is an L3 IP-tunnel (like WireGuard); clash-verge / mihomo / sing-box outbounds are L4 per-flow proxies (like Trojan / VLESS / Hysteria). Bridging the two requires either a user-space TCP/IP stack inside the outbound (gVisor) or extensive mihomo patching. Neither was a small lift, and a self-contained tray app turned out to be the shortest path to "vpn that always-on in a clash-verge-ish UX".
A v0.3 stretch goal is to ship a local SOCKS5 listener alongside the TUN, so clash-verge users who already use SOCKS5 outbounds can point at AuraVPN as a SOCKS5 proxy. That requires the gVisor netstack — separate piece of work.