# Super N2N

Super N2N is a Tauri 2 desktop control plane. Its pinned n2n dependency is
stored as the `third_party/n2n` Git submodule.

## Reproducible Windows build

Clone the project together with its fixed n2n source revision:

    git clone --recurse-submodules https://git.code.cq.cn/chun_qiu/supern2n.git
    cd supern2n

The only supported portable-package build entry point is:

    npm run build:portable

Or call the same script directly when a clean output is required:

    powershell -NoProfile -ExecutionPolicy Bypass -File scripts/build.ps1 -Clean

The script initializes submodules, compiles n2n, installs frontend dependencies
with `npm ci`, runs Rust tests, creates the Tauri portable package, and writes a
SHA-256 checksum beside it. Outputs are placed in `release/`.

The Windows build host needs Node.js, Rust with the MSVC toolchain, Git for
Windows (Bash), and MinGW-w64 tools providing `gcc`, `windres`, and
`mingw32-make`.

## Frontend development

Install dependencies:

    npm install

Start the Vite preview:

    npm run dev

The current preview URL is http://127.0.0.1:1420/.

## Native desktop development

Install dependencies, then start the Tauri development window:

    npm install
    npm run tauri dev

The portable build creates a versioned archive such as
`release/super-n2n-portable-1.2.zip`. It contains
`n2n/edge.exe`, `n2n/supernode.exe`, and the official TAP-Windows installer in
`drivers/tap-windows-9.24.7-I601-Win10.exe`; on Windows Super N2N starts the n2n
programs with the relative paths `./n2n/edge.exe` and `./n2n/supernode.exe`.

### Windows TAP requirement

N2N uses an installed TAP-Windows virtual adapter; it does not create a new
adapter itself. Super N2N checks for an adapter on first launch, offers the
bundled installer when one is missing, and automatically selects an available
adapter before starting Edge. The optional TAP device field is only needed to
select a specific existing adapter. Connection settings, including advanced
settings, are stored beside `super-n2n.exe` in `super-n2n.config.json` and are
restored on the next application launch.

### Supernode and special server

The `创建服务器` home starts Supernode on the configured UDP port and can
optionally restrict communities and the Supernode address-assignment pool.
The optional special server listens on its own TCP port. A special client only
needs that server address and port; it receives the community, static TAP IP,
gateway, DNS, and Supernode port automatically. The client username is sent as
the n2n edge description (`-I`) and defaults to the Windows computer name.

The special address pool must be a subnet inside the normal Supernode pool, and
its community must be present in the allowed-community list when that list is
restricted. Supernode's compact client window polls the management API and
marks addresses issued by the special server.

## Gitea Actions

`.gitea/workflows/build-windows.yml` runs when a Release is published and uploads
the portable zip plus its checksum as workflow artifacts. Configure a dedicated
Gitea runner with the `windows-host` label and the Windows build prerequisites
above. It can also be run manually from the Actions page.

The native command layer can start and stop edge/supernode processes, query the n2n UDP management API, run ping and TCPing checks, and inspect the local firewall state. Browser preview does not fabricate native process, management, or network-check results.

## Included UI

- Overview of managed services, management API client records, P2P/relay counts, and management request latency
- Visual Edge and Supernode option editors mapped to n2n command flags
- Auto-IP/DHCP client table populated from the n2n management API
- Topology view populated from the currently configured services and returned client records
- Ping, TCPing, and local firewall checks
- Process, management API, and tool event log