Running on Windows needed wintun.dll by hand, an elevated console and a
manually started agent; without the DLL the agent silently ran with no
interface (and so no exit node or routing at all).
`tsng service` (hidden) runs the same `up` under the Windows service manager:
src/winservice.rs registers with the SCM through the windows-service crate,
reports Running/StopPending/Stopped, and maps a stop request onto the existing
shutdown path (stop_signal). The only unsafe is the extern "system" entry point
that define_windows_service! expands to, allowed in that module alone. A
service has no console, so it logs to %ProgramData%\Tsunagi\logs\tsng.log
(one older file kept past 8 MiB). Its state defaults to
%ProgramData%\Tsunagi\{data,cache} and its control socket to the system-wide
default every client already uses, so an unelevated `tsng status` and the tray
find it.
dist/windows/tsunagi.iss (Inno Setup) installs tsng.exe, the tray and Wintun
0.14.1 (pinned by SHA-256 in CI, licence text shipped), registers the
"Tsunagi" service as LocalSystem with auto start and restart-on-failure, locks
the data/cache/log directories to SYSTEM and Administrators by SID, and by
tasks adds tsng to the PATH, an inbound firewall rule for the agent and a tray
autostart. It stops the service, the tray and any hand-started agent before
replacing files; uninstall removes the service, rule and PATH entry and asks
before deleting the data (never on a silent uninstall). The release workflows
(GitHub and Gitea) build it on the Windows job and publish
tsunagi-setup-<version>-x86_64.exe.
.cargo/config.toml links the MSVC C runtime statically so nothing needs a
Visual C++ redistributable on a clean machine.
Compatibility: an agent run by hand keeps its data in the user profile; the
service has its own, so networks must be joined again once.
Checks: cargo fmt --check, clippy -D warnings, cargo test --workspace passed on
macOS (one unrelated wireguard restart test failed once under load and passed
on three reruns). winservice.rs was cargo-checked for x86_64-pc-windows-msvc in
a scratch crate; the whole tsunagi crate cannot be built for Windows from
macOS (aws-lc needs the Windows SDK). The .iss script and the CI step were NOT
compiled or run: no Inno Setup or Windows here.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2.9 KiB
Running tsunagi on Windows
The installer (recommended)
tsunagi-setup-<version>-x86_64.exe does everything in one go. Run it as an
administrator (it asks):
- installs
tsng.exe, the tray app and Wintun toC:\Program Files\Tsunagi; - registers and starts the Tsunagi Windows service (it starts at boot and restarts after a crash), running as the system account;
- adds
tsngto the PATH and an inbound Windows Firewall rule for the agent (both are tasks you can untick); - starts the tray icon at sign-in.
Where things live: the device's identity and networks in
%ProgramData%\Tsunagi\data (readable only by administrators and the system),
the log in %ProgramData%\Tsunagi\logs\tsng.log. The service keeps its own
state: networks joined by an agent you started by hand (tsng up, which keeps
its data in your user profile) are not carried over; join them again with
tsng join. The installer stops such an agent, because it cannot run beside the
service.
tsng status, tsng join and the tray work from an ordinary, non-elevated
terminal. Manage the service with the Services app or sc stop Tsunagi /
sc start Tsunagi. Silent install: /VERYSILENT /SUPPRESSMSGBOXES; choose
tasks with /TASKS="!autostart,addtopath,firewall". Uninstalling removes the
service, the firewall rule and the PATH entry, and asks before deleting the
data.
By hand (the zip)
This archive holds tsng.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 astsng.exe.- An elevated process. Creating the adapter requires Administrator rights.
Open PowerShell or Command Prompt with Run as administrator and start the agent there:
.\tsng.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
.\tsng.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.