95 lines
3.8 KiB
Markdown
95 lines
3.8 KiB
Markdown
# 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
|