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>

aura-gui/src-tauri/src/lib.rs

@@ -125,8 +125,19 @@ fn connect(
     }
     let bin = state.aura_binary.lock().clone();
     let mut guard = state.running.lock();
-    if guard.is_some() {
-        return Err("a client is already running — disconnect first".into());
+    // v3.4.1: previously we refused with "already running" whenever the handle Option was Some,
+    // even when the child had since died (e.g. it survived the 1.5 s spawn check, then crashed
+    // a few seconds later). The dead handle wedged the UI — Connect was permanently blocked
+    // until the user restarted the GUI. Now we check `is_alive` first and clear stale handles
+    // so a reconnect just works.
+    if let Some(prev) = guard.as_ref() {
+        if prev.is_alive() {
+            return Err("a client is already running — disconnect first".into());
+        }
+        // Dead handle: reap it (drop its kill code path) before installing the new one.
+        if let Some(dead) = guard.take() {
+            let _ = dead.kill();
+        }
     }
     let handle =
         cli_proc::spawn_client(&bin, &profile_dir, &profile_id).map_err(|e| e.to_string())?;

crates/aura-cli/src/client.rs

@@ -356,7 +356,34 @@ pub async fn run(config_path: &Path, admin_socket: &str) -> anyhow::Result<()> {
         .clone()
         .unwrap_or_else(crate::config::OsRoutesSection::default);
     let _os_routes_guard: Option<OsRouteGuard> = if os_routes_cfg.enabled {
-        let split = SplitRoutes::from_config(&cfg.tunnel.split, &resolved_domains);
+        let mut split = SplitRoutes::from_config(&cfg.tunnel.split, &resolved_domains);
+        // v3.4.1: when `default = "VPN"` on macOS, os_routes installs two half-Internet routes
+        // (`0.0.0.0/1` + `128.0.0.0/1` via the TUN) that beat the kernel's pre-existing default.
+        // Those wildcards also capture the SERVER's outer endpoint (e.g. 187.77.67.17:443),
+        // which would route Aura's own ciphertext packets back into Aura — an infinite tunnel
+        // loop that kills the data plane in a couple of seconds. Inject the server IP (and any
+        // configured bridge IPs) into `direct_hosts` so they egress through the host's original
+        // default route, exempting them from the VPN. Linux is fine without this — `metric 50`
+        // on the default-via-TUN doesn't override more-specific routes — but on macOS the
+        // half-Internet routes inherently match the server IP, so the bypass is required.
+        if matches!(split.default, crate::os_routes::DefaultAction::Vpn) {
+            let mut bypass_ips: Vec<std::net::IpAddr> = Vec::new();
+            if let Ok(addr) = cfg.server_socket_addr() {
+                bypass_ips.push(addr.ip());
+            }
+            for raw in &cfg.client.bridges {
+                if let Ok(sa) = raw.parse::<std::net::SocketAddr>() {
+                    bypass_ips.push(sa.ip());
+                } else if let Ok(ip) = raw.parse::<std::net::IpAddr>() {
+                    bypass_ips.push(ip);
+                }
+            }
+            for ip in bypass_ips {
+                if !split.direct_hosts.contains(&ip) {
+                    split.direct_hosts.push(ip);
+                }
+            }
+        }
         let guard = OsRouteGuard::install(
             &actual_tun_name,
             &split,