releases

VPN Works 0.4.1: All 17 Ways Out of the Sealed Sandbox Blocked, IPv6 Included

VPN Works 0.4.1 adds no features. It closes the one gap the 0.4.0 tests left open, and it fixes a bug those same tests turned up along the way.

The gap was IPv6. A sealed program tries every known way around vpnw, and two of those ways go over IPv6. The machine that records the project’s figures has no IPv6 in its kernel at all, so those two tests never ran. 0.4.0 said so: 14 of 14 blocked, 2 not run.

Now they run on GitHub’s Linux machines, which do have IPv6, every time code is pushed. If IPv6 is missing there, or the sandbox can’t be set up, the run fails instead of quietly skipping. The table they produce comes back into the project’s recorded results. All 17 ways out were blocked, the two over IPv6 included.

17 ways out of the sealed sandbox, all blocked, IPv6 included, on a GitHub Actions Linux runner

What the IPv6 Tests Prove

The loopback test is the strong one. A listener waits on the runner’s own ::1. Outside the sandbox the test program reaches it. Inside, it finds nothing there, because the sandbox has a loopback of its own. The listener counts every connection it gets, and it got none from inside.

The public address test is weaker, and it’s worth saying so. GitHub’s runners can’t reach the IPv6 internet either, so “no route” inside the sandbox doesn’t tell you much on its own. The table shows that: its control outside the sandbox fails too.

Seventeen, not sixteen, because the runner has ping installed, and that gets a row of its own.

The Bug

Recording the figures runs every test a second time under Go’s race detector. This time it caught a race in the plugin host. When a run ended while an Observer plugin was still behind on its events, vpnw could close the plugin while a call into it was still running. It showed up once, in the test that makes a plugin fall behind on purpose.

Now vpnw cuts the call short, waits for it to end, and only then closes the plugin. No call can start after that. The fix came with a test, an independent review of it, and a clean run under the race detector.

Measured

What 0.4.1
Ways out of the sealed sandbox 17 of 17 blocked, IPv6 included
Test functions 123 of 123 passed
Under the race detector no failures
Statements covered 82.4%
Fuzz targets 9, all clean
A connection opened through a WireGuard tunnel 0.28 ms
Data through a WireGuard tunnel, both ends on one machine 81 MB/s
A Guard plugin’s decision 0.18 ms

The sandbox figures come from a GitHub Actions Linux runner, and the rest from the same 2-CPU Linux machine as before. Timings on a shared VM move a little from run to run. test/results

Next is 0.5.0, Ledger: records that show it if anyone edits them. Roadmap · Download