Notes/VPN Works

VPN Works Adds a Tamper-Evident Run Record and an 18-Fault Test Kit

VPN Works gives each program, an AI agent for example, a network of its own. vpnw seals the program in, decides every connection it tries to make and writes down what happened. In September that took five separate engines. Since 0.3.0 it’s one small core with WebAssembly plugins, run on the same Go runtime BareProxy uses, and the old engines are coming back one release at a time. Two of them returned on 13 October.

Ledger, in 0.5.0

Ledger records each event of a run in a file as soon as it occurs. Each line carries a SHA-256 hash chained to the previous line, with a checkpoint every 100 events, and vpnw verify walks the chain to say whether the file is intact or where it was changed. The tests tried 22 kinds of tampering. 21 were flagged as changes, 18 of them at the exact line. The last, a removed end line with nothing kept elsewhere, reads as a run that was cut short.

The run’s trace also gets a copy of every checkpoint. Stored apart from the ledger, those copies expose a ledger rewritten from its first line, something the hashes by themselves can’t show. Before release, an independent review found four edits that got past verify. All four are fixed and are now test cases.

Ledger gets no special access. Any plugin can ask for file.write, which gets it one new file it can append to and nothing more, and that’s all Ledger uses.

Lab, in 0.6.0

Lab is a fault kit inside the project’s test suite, run on every push. A relay between vpnw and a real WireGuard peer drops packets or handshakes on command, adds 300 ms of delay or hands the tunnel to a peer with the wrong key, and the peer’s DNS server can be set to give false answers. To pass, a case has to show that the fault reached the program in time, that no traffic got around the tunnel, that every recorded connection ended with an outcome and that vpnw exited with the program.

Lab has 18 cases, and the ones that failed at first led to four fixes, shipped in the same release. One of them matters for anyone using a provider’s config that sends everything through the tunnel. A false DNS answer could point a program at loopback or cloud metadata addresses on the VPN server’s side, and vpnw now refuses those addresses on any tunnel. All 18 cases pass.

Where It Stands

Before these two, 0.4.0 sent a single program through a WireGuard tunnel without root, with the tunnel running inside vpnw. 0.4.1 ran the sandbox test on GitHub’s Linux runners and blocked all 17 escape routes it tried, IPv6 included. Exit, the server end of a path, is next as 0.7.0. Binaries for Linux and macOS are on the releases page.