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
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>
47 lines
1.6 KiB
Markdown
47 lines
1.6 KiB
Markdown
# 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:
|
|
|
|
```powershell
|
|
.\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
|
|
|
|
```powershell
|
|
.\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.
|