Two coupled bugs from the macOS half-Internet-route fix (v3.4.1) put together. ## 1) Infinite tunnel loop: server IP routed through itself v3.4.1 made `default = "VPN"` actually win against the host's pre-existing default by installing `0.0.0.0/1` and `128.0.0.0/1` via the TUN. Both half-Internet routes are strictly more specific than `0.0.0.0/0`, so outbound traffic finally went through Aura. Side-effect: the server's outer IP (187.77.67.17) falls inside `128/1`. That means Aura's own encrypted ciphertext to 187.77.67.17:443 also matched the new route → re-entered the TUN → was about to be re-encrypted and shipped to … itself. The kernel held the existing TCP socket on en0 for a few seconds (sticky source), so the connection survived briefly. As soon as anything triggered a re-route resolution (TCP retransmit on a different socket, cover-traffic, new cipher frame), the socket flipped to utun4 and the data plane died — exactly the "Aura умирает через пару секунд" the user reported. Fix: before calling `OsRouteGuard::install`, scan the dial config for outer-endpoint IPs (the primary `server_addr` plus any `[client] bridges` entries) and inject them into `SplitRoutes::direct_hosts`. The existing macOS plan turns `direct_hosts` into `route add -host <ip> <gateway>` — a /32 bypass via the original LAN gateway, more specific than `128/1`, so the kernel routes the ciphertext via en0 even after the half-Internet routes are in. No recursion, no flap, no death. Only applied when `default = "VPN"` (the only mode where the bypass is needed). Linux doesn't need it — the `metric 50` default-via-TUN doesn't override more-specific kernel routes. ## 2) Dead GUI handle wedges the Connect button `connect()` in lib.rs refused with "already running" whenever the `Option<ClientHandle>` was `Some`, regardless of whether the child was still alive. So when the aura-client died from bug #1 (within ~2 s of Connect), the UI was permanently stuck — the only escape was quitting and relaunching the GUI. Now `connect()` checks `prev.is_alive()` first. If the previous handle is dead, we reap it (calling `kill()` to consume the handle's drop path) and spawn a fresh one transparently. Reconnect-after-crash now Just Works. This also matches what a sensible "Connect" button does on every other VPN GUI: clicking it when something looks stuck should make progress, not demand a quit-and-relaunch dance. ## Verification - `cargo test -p aura-cli --lib os_routes` — 21/21 ok - `cargo build --release` — green - Rebuilt /Applications/Aura.app against both fixes - Server-side aura.service restarted to clear the leftover pool reservation the dead session never released (see v3.5 task #52 for the auto-cleanup follow-up) 🤖 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.