NTIPNetwork control plane
GitHubLive demo

Working pre-release · v0.2

Private networking you can see and control.

NTIP connects Linux servers behind NAT through an encrypted, Master-mediated Layer-3 network. Assign stable private IPv4 addresses, manage routes, and compare configured state with live observations from one self-hosted dashboard.

Built for small infrastructure and security teams operating roughly 10–250 Linux Nodes.

View on GitHub Open live demo
Commit-pinned demov0.2.0-dev preview
curl -fsSL https://ntip.alkhatib.online/demo/install.sh | sudo sh

This is a commit-pinned v0.2.0-dev demonstration build. It is not the public v0.2.0 release and is intended only for evaluation on a fresh host.

Management overview
Actual pre-release interface · full frame
Control plane register

Overview

Inventory, runtime observations, service posture, and recent activity share one measured surface without smoothing over unknown state.

Configured inventory and observed runtime remain separate, so uncertainty stays visible.
Fleet
10–250 Nodes
Runtime
Linux 6.1+
Address plane
Private IPv4
Transport
Master-mediated

01 / What NTIP is

A visible control plane for private Linux networks.

NTIP joins distributed machines through one authoritative Master. Operators define Virtual Network Ranges (VNRs), select stable addresses, attach explicit routes, and inspect whether live state agrees with configured intent.

01
Authorityntsrv + SQLite

One durable owner for configured state.

02
Management edgentip-api

DB-free, loopback-only, authenticated Unix IPC.

03
Network modelLayer 3

VNR membership and explicit owned routes.

04
Address choiceOperator-set

Allocation-aware suggestions; no automatic assignment.

05
Runtime truthObserved

Kept distinct from desired configuration.

Linux stays in charge

NTIP provides the encrypted Layer-3 interconnect. Ordinary forwarding, firewalling, NAT, policy routing, and load balancing remain explicit Linux responsibilities.

02 / How it works

One authority. Deliberate addressing. No hidden peer-to-peer path.

  1. 01

    Master

    ntsrv owns SQLite, enrollment, network configuration, and runtime coordination. It is the durable authority.

  2. 02

    Virtual Network Range

    The operator creates a non-overlapping IPv4 VNR. The Master receives the first usable address, such as 10.10.1.1 for 10.10.1.0/24.

  3. 03

    Nodes and routes

    NAT-friendly Nodes receive operator-chosen stable addresses and optional owned routes. Node-to-Node traffic is relayed through the Master.

BrowserHTTPS proxyDashboard gatewayntip-apiAuthenticated Unix IPCntsrv

The separate ntip-api service is DB-free and loopback-only. It reaches the authoritative server through peer-authenticated, typed Unix IPC.

03 / Dashboard

Read the network as it is.

Four real views from the working v0.2 management surface. The visible runtime uncertainty is preserved exactly as observed; no healthier data has been fabricated for this site.

01

Control plane register

Overview

Inventory, runtime observations, service posture, and recent activity share one measured surface without smoothing over unknown state.

Control plane register

Overview

Inventory, runtime observations, service posture, and recent activity share one measured surface without smoothing over unknown state.

02

Address domains

Virtual Network Ranges

Operators define non-overlapping IPv4 ranges deliberately. The Master takes the first usable address and every Node assignment stays explicit.

Address domains

Virtual Network Ranges

Operators define non-overlapping IPv4 ranges deliberately. The Master takes the first usable address and every Node assignment stays explicit.

03

Configured identities

Nodes

Enrollment and durable address assignments appear alongside live observations, so configured does not quietly become connected.

Configured identities

Nodes

Enrollment and durable address assignments appear alongside live observations, so configured does not quietly become connected.

04

Deterministic read model

Topology

The map keeps the transport boundary honest: the Master mediates the VNR and every Node relationship. A complete table remains available in the console.

Deterministic read model

Topology

The map keeps the transport boundary honest: the Master mediates the VNR and every Node relationship. A complete table remains available in the console.

04 / Install

A guarded path to an evaluation Master.

This external convenience installer composes the core, API, Node bootstrap assets, and dashboard gateway packages. It does not change NTIP’s protocol or its pre-release guarantees.

Preview commandFull source commit pinned
curl -fsSL https://ntip.alkhatib.online/demo/install.sh | sudo sh

Demonstration preview — not the v0.2.0 public release. The mutable channel script selects one artifact directory named by the full source commit; every downloaded archive is then locked to that directory, byte size, and SHA-256 digest.

The stable /install.sh remains fail-closed while the public v0.2.0 release is pending. This temporary preview channel does not waive or satisfy that release gate.

Hostglibc Linux

systemd, kernel 6.1+, and /dev/net/tun

CPUx86_64 or AArch64

Exact architecture-matched artifacts

Host stateFresh installs only

Existing NTIP state or occupied gateway/API ports are refused

FirewallOperator-managed

443/tcp from the proxy; public UDP for Nodes

05 / Guide

From fresh Master to an enrolled Node.

The dashboard handles deliberate configuration and reveals one tailored setup command plus one short-lived secret. The long internal enrollment credential never becomes operator workflow.

  1. 01

    Prepare the HTTPS reverse proxy

    Create the public HTTPS origin first, then forward its entire origin to plain HTTP port 443 on the future Master. Keep that backend reachable only by the trusted proxy.

  2. 02

    Install the Master management stack

    Run the evaluation installer on a fresh Linux host. Confirm the exact HTTPS origin and public UDP endpoint; the installer validates TLS, pins its public key, and installs every matching service and Node asset.

  3. 03

    Create a Virtual Network Range

    Create a VNR such as 10.10.1.0/24. NTIP assigns the first usable address—10.10.1.1 in this example—to the Master.

  4. 04

    Add a Node at a stable address

    Choose a free address explicitly. The dashboard is allocation-aware, but it does not silently allocate or submit an address for you.

  5. 05

    Save the Node setup pair

    After Node creation, save the tailored one-line installation command and its short XXX-XXX-XXX secret. The dashboard displays the secret only for this setup handoff.

  6. 06

    Run the tailored command on the Node

    Paste the command on a fresh Linux 6.1+ Node. It selects the matching x86_64 or AArch64 package, verifies the pinned HTTPS endpoint and archive digest, and installs ntcl as a systemd service.

  7. 07

    Enter the short secret and verify

    Enter the secret only at the Node's controlling terminal. The installer redeems it without exposing the internal credential, starts ntcl, and waits for enrollment; then test the assigned private IPv4 address.

    XXX-XXX-XXX

External HTTPS boundary

Bring the proxy; NTIP owns the whole-origin backend.

NTIP deliberately does not install or configure NGINX. Its unprivileged dashboard service binds a plain-HTTP gateway to 0.0.0.0:443 for your existing TLS edge.

Do not expose the cleartext backend directly. Forward the whole origin and preserve Host and Origin.

Public origin

Provision one exact lowercase HTTPS origin with a certificate valid for that hostname. The installer CA-validates the live leaf certificate and derives the SPKI pin used by Node setup commands.

Whole-origin route

Forward every path without rewriting to plain HTTP port 443 on the Master. The dashboard gateway owns pages, /api/v1, enrollment redemption, and immutable Node assets.

Network boundary

Allow the dashboard's cleartext port only from the trusted reverse proxy. Publish the confirmed UDP endpoint separately; it is never inferred from the proxy hostname.

06 / Origin

Built from a recurring infrastructure problem.

NTIP began with the difficulty of connecting VPSs, virtual machines, local systems, and edge Nodes that sit behind NAT or move between network environments. Connectivity usually arrived as a pile of VPN configuration, credentials, static routes, monitoring tools, and ad hoc troubleshooting commands.

The project turns that fragmented work into one coherent operating model: define the network, enroll identities, establish connectivity, and compare intended state with what the Master actually observes.

OpenAI Build Week is part of NTIP’s project history: it was the period when the existing protocol and command-line implementation grew into a persistent control plane and web dashboard. NTIP remains an independently developed project; this history does not imply an ongoing OpenAI endorsement.