The command line package is now `tsunagi` and builds the `tsng` executable, which the packages, the unit, the installers and the workflows install and run. The core library package becomes `tsunagi-core`, keeping the library name `tsunagi`, so no code changes `use tsunagi::...`. Directories follow (crates/tsunagi-core, crates/tsunagi). Every command shown to a person is now `tsng ...`. Co-Authored-By: Claude <noreply@anthropic.com>
1.6 KiB
Running tsunagi on Windows
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.