Pushing a `v*` tag now builds the agent for every supported target and attaches the archives to a GitHub release. Modelled on the furumi release workflow (a build matrix, then a publish job that runs `gh release create`), adapted to this project's two differences: it needs system integration (capabilities/polkit on Linux, elevation+wintun on Windows, a root daemon on macOS), and its users run varied distros, not just Ubuntu. Linux is built as a fully **static musl** binary with cargo-zigbuild, so one artifact runs on Arch, Alpine, NixOS and old-glibc systems alike, and can be repackaged into whatever a distro prefers later. musl has no prebuilt aws-lc-sys bindings, so the Linux jobs install cmake + libclang (bindgen) and zig (the cross C compiler zigbuild drives). macOS (aarch64) and Windows (x86_64) build natively; Linux covers x86_64 and aarch64. Targets: x86_64/aarch64 linux-musl, aarch64 macOS, x86_64 Windows. Each archive carries the binary, the top-level README, and the platform's install notes plus integration files: - dist/linux/: a static-friendly README, a systemd unit (runs as root, so no capability grant or polkit rule is needed; a commented non-root variant is included), and an install.sh that drops the binary and the unit or prints the setcap/polkit alternative. - dist/windows/: install notes covering wintun.dll and Run-as-administrator. - dist/macos/: the existing LaunchDaemon plist and notes, now also shipped in the archive. Not exercised yet: the workflow only runs on a real tag push, and the aws-lc-sys-under-musl build has not been run locally in this session (no zig toolchain here). YAML and install.sh syntax are validated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Running tsunagi on Windows
This archive holds tsunagi.exe. The overlay interface is a Wintun adapter, so
the agent needs two things to carry real traffic:
wintun.dllbeside the executable. Download it from https://www.wintun.net, take the DLL for your architecture (amd64), and put it in the same folder astsunagi.exe.- An elevated process. Creating the adapter requires Administrator rights.
Open PowerShell or Command Prompt with Run as administrator and start the agent there:
.\tsunagi.exe up
Run the commands that control it (join, status, dns, network) as the
same user with the same elevation. The agent serves its control interface on a
named pipe under %ProgramData%\tsunagi, so an elevated client finds it
regardless of which account started the agent.
Without touching the OS
.\tsunagi.exe up --no-tun
Tunnels form and handshake between agents, but no adapter, address or route is created, so traffic never reaches the operating system. Needs no Wintun and no elevation.
What the agent installs
Everything is tagged to its own adapter, computed from local state, and reversible — removed when a network leaves, broadcast is turned off, or the agent stops:
- a Wintun adapter configured with
netsh(addresses, MTU); - while broadcast is on, a
255.255.255.255route through the adapter and an inbound-UDP firewall allowance from the overlay range; - the Name Resolution Policy Table entry that sends the overlay zones' questions to the local resolver.
Nothing taken from a remote peer ever becomes a path, a command argument or an OS setting.