Files
tsunagi/dist/windows/README.md
T
UltradesuandClaude Opus 4.8 d1ab993dd2
Release / tsunagi-linux-aarch64 (push) Failing after 3m12s
Release / tsunagi-linux-x86_64 (push) Failing after 2m21s
Release / tsunagi-macos-aarch64 (push) Canceled after 0s
Release / tsunagi-windows-x86_64 (push) Canceled after 0s
Release / Publish release (push) Canceled after 0s
Add a tagged-release CI workflow and Linux/Windows packaging
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>
2026-10-02 11:48:19 +01:00

1.6 KiB

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:

  1. wintun.dll beside the executable. Download it from https://www.wintun.net, take the DLL for your architecture (amd64), and put it in the same folder as tsunagi.exe.
  2. 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.255 route 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.