DrSaeedHub/Tunnel-Panel

bash <(curl -Ls https://raw.githubusercontent.com/DrSaeedHub/Tunnel-Panel/main/scripts/install.sh)

It asks for an admin username, a password, a port and a web path — proposing a random port and a random web path, so accepting the defaults is the safe choice rather than the lazy one. Two minutes later the panel is a systemd service at https://<host>:<port>/<web-path>/. Everything lives under that prefix; anything outside it returns a bare 404 that gives no sign the panel is there.

Running the same line again once the panel is installed opens tnp, its management CLI, instead of installing over the top.

bash <(curl -Ls https://raw.githubusercontent.com/DrSaeedHub/Tunnel-Panel/main/scripts/install.sh) \
  --non-interactive --json \
  --username admin --password '…' --port 8443 --web-path $(openssl rand -hex 12)

CPU including steal time, memory derived from available rather than from free, swap, every filesystem, and per-interface throughput and volume — read straight from /proc and /sys, once a second, streamed over SSE. The fleet's health, the relay's throughput and the number of connections crossing it are on the same screen, because they are the same question.

Each tunnel appears in the breakdown under the name you gave it, and clicking it goes there.

Create, edit, enable, disable, restart, reapply and delete GRE, GRETAP, IP6GRE and IP6GRETAP tunnels. Nothing is reported working because a command exited zero: after every apply the panel reads the interface back out of the kernel and checks it against what was asked for.

Every change is previewed first — the exact commands, the exact unit file that will be written, the rollback that runs if a step fails, and the checks that will be made afterwards:

A tunnel's configuration travels to the second server as a pairing code — as text or as a QR code — with the side flipped automatically, so the two ends cannot disagree by a typo.

Native ICMP probing with no subprocess: one socket per tunnel bound to its own address, a rolling window in which a late reply revises a loss verdict, and hysteresis so a single dropped packet does not flip a tunnel to down and back. When ICMP is filtered but the path is fine, the panel knocks on the far end over TCP and says so, rather than reporting a dead tunnel.

A healthy tunnel	One that is losing packets

Latency and loss over the last hour, day, week or month; every state change kept as an event with the reason that caused it; per-tunnel thresholds that override the global ones.

Relay any TCP or UDP port — or a whole port range — over a tunnel or straight out of the host. Round-robin, source-hash or weighted balancing across several destinations; masquerade, SNAT or no NAT at all; MSS clamping; per-source connection limits and connection rate limits; and allowed source ranges kept in named lists you maintain once and point several rules at.

Failover is not a status badge. The panel knocks on each destination on a schedule, and a backend that stops answering is taken out of the generated ruleset and put back when it answers again. The suppression is a column on the destination, so rebuilding the ruleset from the records is the whole of what failover does:

The rules the kernel holds are never a mystery. Every rule the panel writes carries a comment naming the database row that generated it, so what is installed can be read back and matched — and the panel says plainly when the kernel and the database disagree:

Everything the panel installs lives in one nftables table, or in its own iptables chains. Rules belonging to Docker, firewalld or anything else live in their own tables and are never read, flushed or reordered.

Read over netlink from connection tracking: who connected, which destination took them, the transport state, how old the connection is and how much has moved through it — filterable by destination.

A limit on a tunnel, on a rule, or on a single destination. Received only, sent only, or both together. Total, daily, weekly or monthly, with the window rolling over by rebasing rather than by zeroing anything. Warn raises it in the interface; enforce takes the interface down or rebuilds the ruleset without that destination — through the same code path your own click would have used.

Not a wall of output: an analysis that names what is wrong, with the evidence it collected and what to try. Beside it, a high-precision manual probe that streams packet by packet and can be cancelled mid-run, a path-MTU binary search that reports what it found and offers to apply it, a traceroute, and a TCP knock on the far end.

A forwarding rule has its own: an analysis of the whole path, and a knock on every destination at once — which also runs before a rule exists, so "create it and see" becomes an answer.

A stock kernel is sized for a machine that serves a handful of connections at a time. A relay is not that machine, and several of its limits are low enough to stop one outright — a full conntrack table refuses every new connection on the host, SSH included. The panel reads what this host holds, works out what it should be from its memory and core count, and writes the difference to its own sysctl file: table size and timeouts, BBR and fq, backlogs, buffers, the local port range, file descriptors — each one a field with the current value, the recommendation, and a sentence explaining what it does.

Point-to-point addresses come out of pools you define, allocated per tunnel, with the capacity and the usage shown. Source lists are named sets of ranges — the panel ships a few — that any number of rules can allow, edited in one place instead of retyped into every rule that needs them.

Address pools	Source lists

Everything else is a typed setting with a default, a range and an explanation, rendered from the backend's own schema — so the interface cannot drift from what the panel accepts.

The panel is where an operator is, which at three in the morning is a phone.

Complete Farsi with genuine RTL and bidirectional isolation of every technical value — an IP address, a port range and a CIDR read correctly inside a right-to-left sentence, which is where most translated panels come apart. Adding a language needs no code change.

فارسی	Light

Self-contained bundles are published with each release for servers with no internet access, one per Ubuntu release and installation profile:

standard is for a normal, healthy Ubuntu Server. bootstrap additionally carries the full dependency closure of every required OS package, for minimal installations. Match the bundle to the server's Ubuntu release — the installer checks and refuses a mismatch. Both flavors include a local APT repository, so no installation step reaches the network; the bundle's SHA-256 manifest is verified before anything touches the system.

Download one from the releases page, transfer it to the server by any method you like, then:

tar -xzf tunnel-panel-<ver>-ubuntu24.04-amd64-standard.tar.gz
cd tunnel-panel-<ver>-ubuntu24.04-amd64-standard
sudo ./scripts/install_offline.sh

The prompts, flags and exit codes are the same as the online installer's. On a server that already has the panel, a bare run offers upgrade, repair and uninstall; non-interactively, --upgrade --yes upgrades in place preserving the database and tunnels, --repair --yes restores binaries, unit, packages and permissions without touching data, --uninstall removes the panel (asking separately about tunnels and the database), and --full-uninstall removes everything after one explicit confirmation. Each bundle ships its own README_OFFLINE.md with the exact instructions for the files inside it.

Installed alongside the panel, for the things you do from a shell:

tnp                 # the menu
tnp status          # service, port, web path, database, tunnels
tnp url             # where the panel is, including the web path
tnp update          # update to the latest release, keeping everything
tnp restart         # restart the service
tnp logs -n 200     # the last lines of the journal
tnp set-port 8443   # change the port, with a bind test first
tnp set-web-path …  # change the secret prefix
tnp set-username …  # rename the operator account
tnp reset-password  # when you are locked out
tnp backup          # write a backup file, or issue a one-time download link
tnp restore <file>  # restore one
tnp reinstall       # repair binaries, unit and permissions without touching data
tnp uninstall       # remove the panel; tunnels and database are asked about separately

The unit runs as root with CAP_NET_ADMIN and CAP_NET_RAW retained. NoNewPrivileges, ProtectHome, ProtectSystem=full and PrivateTmp are all kept. Four common hardening directives would break tunnel management and are deliberately absent: PrivateNetwork puts the panel in a namespace where the host's interfaces do not exist, ProtectSystem=strict makes /etc read-only so no tunnel unit file can be written, ProtectKernelModules stops ip_gre from autoloading on the first tunnel, and a capability bounding set without CAP_NET_ADMIN cannot create an interface at all.

Bootstrap settings come from the environment (or flags of the same name); everything else is configured in the panel itself and stored in the database.

Run gre-panel --help for the full list, and gre-panel --version for the build stamp.

Requires Go 1.23 and Node 18 (the frontend pins Vite 5 and Tailwind 3, which is what Node 18 supports).

# Everything: frontend, then a static binary per architecture, then SHA256SUMS
scripts/build-release.sh --version v0.1.0

# The frontend on its own — needed once in a fresh checkout, since web/dist is
# generated rather than committed and the Go build embeds it
cd web/_app && npm ci && npm run build      # writes web/dist

# Just the binary, once web/dist exists
CGO_ENABLED=0 go build -trimpath ./cmd/gre-panel

CGO_ENABLED=0 is what makes the binary static: the SQLite driver is pure Go, so nothing links against libc. Until the frontend has been built, every Go package fails to compile with pattern all:dist: no matching files found — that is web/embed.go reporting that the bundle it embeds is not there yet.

The npm project lives in web/_app rather than web/. The underscore is load-bearing — the Go tool ignores directories whose names begin with one, which keeps node_modules out of go build ./...; some npm packages ship Go files of their own, and without it the Go build would depend on whatever npm had installed.

go test -race ./...                  # backend, including the ICMP and state-machine tests
cd web/_app && npm run typecheck     # TypeScript
cd web/_app && npm run lint          # ESLint
cd web/_app && npm test              # Vitest, including bidi isolation

GRE_PANEL_DEV_MODE=true GRE_PANEL_DATA_DIR=/tmp/grepd GRE_PANEL_WEB_PATH=dev \
  GRE_PANEL_BIND_PORT=8080 go run ./cmd/gre-panel

Development mode substitutes a fake link manager, a fake netfilter backend and a loopback ICMP dialer, so the panel runs unprivileged with nothing to configure. Raw sockets and netlink both need root, so what runs there is a simulation of the network, not the network itself.

cmd/gre-panel/        entry point, flag and environment parsing, lifespan
cmd/tnp/              the management CLI
internal/config       bootstrap configuration and web-path normalisation
internal/model        entity structs and the fixed lookup identifiers
internal/db           SQLite schema, pragmas and idempotent seeds
internal/settings     typed settings store; the frontend renders from its schema
internal/auth         argon2id, JWT, CSRF, rate limiting and lockout
internal/api          chi router, error envelope, SSE, static assets
internal/audit        audit writer with secret redaction
internal/exec         process runner; no shell, ever
internal/link         netlink link manager, and a fake for tests and dev mode
internal/validate     input and conflict validation, MTU advice
internal/alloc        address pool allocation
internal/safety       the invariants no flag can override
internal/persist      systemd, networkd and sysctl rendering
internal/tunnel       the lifecycle pipeline: plan, apply, verify, roll back
internal/reconcile    drift detection and adoption
internal/monitor      native ICMP probing, the state machine, history
internal/rules        nftables and iptables backends, rendering and read-back
internal/route        forwarding rules, destination probing, accounting, conntrack
internal/sourcelist   shared address lists
internal/quota        traffic limits and enforcement
internal/tuning       kernel parameters: recommendation, apply, revert
internal/metrics      /proc and /sys sampling, traffic counters
internal/diag         analysis, manual probe, path-MTU search, traceroute
internal/backup       backup, restore and one-time download links
web/embed.go          embeds web/dist into the binary
web/_app/             the React application
scripts/              installer, offline bundles and release build