Files
AuraVPN/crates/aura-cli
xah30 cff8de14af fix(cli): v3.4.1 — macOS default-route override + admin sock chmod 0666
Two production-blocking bugs from the GUI's first end-to-end live test against
the production server.

## 1) os_routes: macOS `0.0.0.0/0` does not override the existing default

Empirical observation: client connects, server-side rx counter grows as we
send packets (TCP/443 handshake + frames arrive), but server-side tx never
ticks. From the Mac side `ping 10.7.0.1` returns 0/3, `curl https://1.0.0.1`
returns empty. Tracing it: even with `[tunnel.split] default = "VPN"` the
host's pre-existing default route (`default → 192.168.1.254 → en0`) was
still winning routing decisions. Aura's `route add -net 0.0.0.0/0
-interface utunN` had exit-zero'd but the new entry never beat the original
default — macOS happily accepts the route command, the kernel just doesn't
use it for outgoing packets.

This is a known macOS quirk that every long-lived VPN works around the same
way: install two **half-Internet** routes (`0.0.0.0/1` and `128.0.0.0/1`)
which are strictly more specific than `0.0.0.0/0` and so win by
longest-prefix match. Tailscale, WireGuard, OpenVPN all do this. We now do
too.

Updated the macos_plan_default_vpn unit test to assert the new plan shape
(4 steps for VPN + direct-cidr + direct-host instead of the old 3).

The split has a known limitation: the server's own outer endpoint (e.g.
187.77.67.17:443) is now routed into the tunnel too. The dialer's
already-established TCP source-IP keeps the *current* connection alive, but
a redial after a route flap would loop. Documented in the source comment;
v3.5 will add an explicit `<server_ip>/32 via <orig_gateway>` bypass at
install time.

## 2) admin: chmod 0666 the freshly-bound Unix socket

When `aura client` is spawned by `sudo` (the GUI does this on the user's
behalf), the admin Unix socket ends up owned by root with the default 0755
mode. macOS's `connect()` requires write permission on the socket file, so
the desktop-user GUI sees `Permission denied (os error 13)` and the status
panel stays empty — even though the tunnel itself works.

`transport::listen` now does `chmod 0666` on the socket immediately after
`UnixListener::bind`. The socket lives under `/tmp` (laptop) or `/run`
(systemd-managed server) so the directory permissions still gate access;
making the socket world-RW just lets the per-machine apps that already have
filesystem access actually use it.

## Verification

- `cargo test -p aura-cli os_routes::tests::macos_plan_default_vpn` — ok
- `cargo build --release -p aura-cli` — green
- Bug repro: pre-fix, server admin shows `rx: 13 tx: 5` while client sends
  ICMP that never returns. Post-fix (manual test): the half-Internet routes
  appear in `netstat -rn`, ping 10.7.0.1 succeeds, curl through the tunnel
  works.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-29 20:02:35 +03:00
..