AIVPN built successfully in our sandbox, but two network-cleanup tests failed. One reported that unshare was not permitted. That leaves an important question open for anyone considering a full tunnel: what happens to routing and connectivity after a crash on the machine where you will actually run it?
AIVPN calls itself an experimental tunnel with traffic masking
AIVPN combines an encrypted UDP tunnel with traffic masks that define outer protocols, packet sizes and sending intervals. Its README calls the project experimental and explicitly disclaims guaranteed anonymity or resistance to detection and blocking. That qualification should carry more weight in an adoption decision than the names attached to individual masks.
The documented architecture separates a Linux gateway from clients on several desktop and mobile platforms. It also describes local machine-learning components for monitoring traffic statistics and changing masks. Those are upstream descriptions of how the system works. Our repository run did not measure tunnel throughput, traffic classification, blocking resistance or whether a particular network would permit a connection.
For a protocol researcher, the interesting proposition is having tunnel behavior and traffic shaping in the same project. For someone who needs a dependable everyday connection with established failure behavior, the experimental label is a reason to choose cautiously. A successful compiler result cannot settle that difference in requirements.
What happened when we ran it
Our AIVPN sandbox installed dependencies in 24 seconds and built the project in 201 seconds at commit c526258 on October 30, 2026. The record lists 358 dependencies. The test step exited 101 after 176 seconds, with 234 passed and two failed in the supplied summary of 236.
The failed cases were named explicit_clear_recovers_ipv6_after_sigkill_and_preserves_foreign_routes and ipv6_cleanup_continues_after_a_real_permission_failure. The latter panicked at crates/aivpn-client/src/tunnel.rs:3131 with “unshare: unshare failed: Operation not permitted”. That is direct evidence of a denied operation in that check. The tail does not show the underlying exception for the other failed case.
The raw cargo summary also reports two ignored tests and an internal elapsed time of 4.71 seconds. That differs from the 176-second outer test step, so the shorter figure should not replace the recorded step duration. These are observations from the supplied log, not a new run on an unrestricted networking host.
The sandbox configuration specified 3 CPUs, 12 GB RAM and image label lab-rust:1. Actual runtime and operating-system versions require the raw toolchain logs. The checkout contained 665 files, approximately 230,614 source lines and 18.5 MB. The scan found two CI workflow files, a Dockerfile and a Compose file, but no separate tests directory. The cargo results demonstrate why the last observation cannot mean “no tests”.
A full tunnel needs a recovery check on your target host
The README describes owned IPv6 blackhole routes when a Linux full tunnel has no assigned IPv6 address. It says an explicit disconnect removes the owned routes, while a crash can leave guards for an explicit kill-switch clear command to remove. Normal startup does not automatically clean those routes. That is operating behavior you need to understand before directing all traffic through the client.
Our failed case names concern that same recovery area, but the denied unshare operation prevents a clean conclusion about behavior on a suitable host. We cannot certify crash recovery from this run. Nor does the permission error prove the cleanup implementation is broken. Reproduce a controlled disconnect and crash on a disposable target with the necessary networking privileges before relying on the tunnel.
The README also distinguishes macOS kill-switch behavior: it blocks new outside connections while preserving connections already open when enabled. If your policy requires all existing connections to stop, that documented boundary matters. Platform checkmarks do not establish identical semantics across clients.
Server deployment changes networking; SOCKS5 is a narrower trial
The documented server runs on Linux. Its Compose route uses host networking and persistent configuration, and the quick start calls for opening a UDP port. The bare-metal route manages forwarding and NAT. You need an operator-controlled server, protected server keys and a securely distributed client connection key. Our build did not verify those deployment steps.
AIVPN also documents a SOCKS5 mode without a TUN device or administrator privileges. That can provide a narrower evaluation for selected applications that you configure to use the proxy. It does not establish the behavior of a full-device tunnel or resolve the failed network-cleanup checks. Pick the mode according to what you need to learn.
The v1.2.0 release requires coordinated client and server updates because its initial exchange is incompatible with older peers. Its notes include embedded mobile cores in that requirement. If you cannot update the machines you depend on together, this is a concrete reason to postpone adoption or the upgrade.
Nebula and Headscale fit private-network jobs
Nebula uses certificates to assert a node's address, name and group membership. Evaluate it when connecting your own hosts under certificate-based identity is the goal. This review supplies no evidence that Nebula reproduces AIVPN's traffic masks or defeats a particular network restriction.
Headscale implements a self-hosted Tailscale control server with a stated scope of one tailnet for personal use or a small organization. Choose it for that coordination job when you intend to use Tailscale clients. Neither alternative is a measured performance winner here, and neither comparison substitutes for defining your network requirements.
If AIVPN's experimental traffic shaping is the feature you actually need to investigate, use a disposable gateway and a recoverable client first. Record routing before connection and after both orderly shutdown and a forced stop. The unresolved result to close is reliable recovery on your intended host, not whether the source can compile.