Files
AuraVPN/aura-gui
xah30 fa452f00b1 fix(cli,aura-gui): v3.4.2 — break the infinite-tunnel loop + drop dead GUI handle
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>
2026-05-29 20:12:21 +03:00
..

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 .tgz and you're set)
  • Connect / Disconnect (spawns / kills aura client per 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.tgzprofiles/client-1/).

Aura binary path

The GUI shells out to aura client for each connection. It defaults to:

  1. /Users/xah30/AuraVPN/target/release/aura if present (dev convenience),
  2. /usr/local/bin/aura on Unix,
  3. C:\Program Files\AuraVPN\aura.exe on 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.