3.8 KiB
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