DEV Community: Ebrahim Shafiei

One Binary to Manage an SSH Tunnel Server: Abdal 4iProto Panel

Ebrahim Shafiei — Tue, 09 Jun 2026 22:49:40 +0000

Why a single binary matters for tunnel administration

If you have ever stood up an SSH tunnel server on a fresh VPS, you know the real cost is not the server—it is everything around it. You need a way to add and revoke users, cap their bandwidth, watch sessions in real time, block abusive IPs, and survive a reboot without a 12-step runbook. The usual answer is a stack: a runtime, a web framework, a database, a reverse proxy, a process manager. Each layer is one more thing that breaks at 2 a.m.

Abdal 4iProto Panel takes the opposite bet. It is a web-based management interface for the Abdal 4iProto Server—a dedicated SSH tunnel server—written in Go and compiled to a single executable with embedded resources. CSS, JS, HTML templates, and translation files all live inside the binary. There is no runtime to install, no external dependency to pin, no asset directory to ship. You drop one file on Windows or Linux, optionally register it as a service, and you have a full admin console. This article walks through how it is built and how an expert operator would actually use it.

🔗 Panel repo: https://github.com/ebrasha/abdal-4iproto-panel
🔗 Server repo: https://github.com/ebrasha/abdal-4iproto-server

The architecture in one sentence

The panel is a Go process that embeds its own web assets, persists configuration as flat JSON files, talks to the 4iProto SSH tunnel server it manages, and can run as a Windows Service or a Linux systemd unit. That is the whole shape of it—and the simplicity is the point.

Configuration lives in plain JSON, not a database engine. On first run the panel writes abdal-4iproto-panel.json:

{
  "port": 52202,
  "username": "ebrasha",
  "password": "ebrasha1309",
  "logging": true,
  "blocked_ips": [],
  "max_login_attempts": 5,
  "login_attempt_window": 300,
  "block_duration": 3600
}

For a tunnel management surface, JSON state is a defensible choice: the data set (users, blocked IPs, server config) is small, human-auditable, trivially backed up with cp, and never introduces a separate failure domain. You can inspect or diff the live state with tools you already have. Note the SSH-native footprint of the install set, too—id_ed25519 and id_ed25519.pub ship alongside the binaries, since the server is doing real SSH tunneling.

⚠️ Change ebrasha1309 immediately after first login. Defaults are for first boot, not production.

The administrative workflow

Point a browser at http://localhost:52202 (or your configured port), authenticate, and you land on a dashboard summarizing users, sessions, and traffic. From there the work is organized around the lifecycle of a tunnel deployment rather than a flat settings dump.

User provisioning is full CRUD, but the interesting part is per-user policy. Each account carries far more than a username and password: a role (admin/user), blocked domains and IPs scoped to that user, concurrent session limits and TTL, a speed cap in KB/s, a traffic quota in MB, and individual logging preferences. This is enough to run differentiated tiers—a throttled trial account and an uncapped admin account—without touching the server binary.

Server configuration is edited from the same UI: listening ports (multiple are supported), the default shell for Windows/Linux targets, the maximum authentication attempts, and even the server's advertised version signature. The panel writes these to the server's config and the change takes effect on the managed service.

Security is handled at two layers. There is straightforward IP blocking, and there is an automatic brute-force defense with a configurable attempt ceiling, a sliding time window, and a block duration. Cross the threshold inside the window and the offending IP is blocked automatically for the configured period—no manual intervention.

Monitoring is where an operator spends real time. User access logs update over Ajax without a full page reload. Traffic monitoring tracks consumption per user—session-based and cumulative—and surfaces warnings as accounts approach their quota. The sessions view reflects live state from the server: session ID, username, source IP, client version, creation time, and last-seen timestamp, with the ability to revoke a session.

The whole console is bilingual (English and Persian), responsive down to a mobile hamburger menu, and—because configuration changes can require a clean reload—the panel auto-restarts its own service after you save, so applied settings are never half-live.

The Telegram bot: a study in isolation

The feature most worth dissecting is the optional Telegram bot, which mirrors every administrative action from the web UI. Enabling it is a config flow: create a bot via @BotFather, grab your numeric ID from @userinfobot, then in Panel Configuration → 🤖 Telegram Bot tick enable, paste the token, and list admin IDs. Settings persist under a telegram_bot key:

"telegram_bot": {
  "enabled": true,
  "token": "123456789:AA...your-bot-token",
  "admins": [111111111, 222222222]
}

The security model is deliberately blunt: the bot drops every update that does not originate from an admin Telegram ID and replies with a short "not authorized" message, so an attacker cannot silently probe behavior.

What makes the bot worth studying is its concurrency design. It is not a side thread bolted onto the request handler—it is a fully isolated subsystem inside the panel process, with its own HTTP connection pool, dispatcher worker pool, asynchronous log channel, and a debounced restart queue. The explicit goal: a busy panel UI or slow disk I/O can never slow the bot down. The update pipeline:

┌─────────────────────────┐      ┌──────────────────────┐
│ Telegram getUpdates     │ ───► │ updates channel      │
│ (1 goroutine)           │      │ (cap 1024)           │
└─────────────────────────┘      └──────────┬───────────┘
                                            │
                          ┌─────────────────┼─────────────────┐
                          ▼                 ▼                 ▼
                   ┌──────────┐      ┌──────────┐      ┌──────────┐
                   │ worker 1 │ ...  │ worker N │      │ worker N │ (NumCPU*2, ≥8)
                   └────┬─────┘      └────┬─────┘      └────┬─────┘
                        │                 │                 │
                        ▼ (go r(ctx,b,u)) ▼                 ▼
                   ┌────────────────────────────────────────────┐
                   │ Per-handler goroutine                       │
                   │  → trackerMiddleware (WaitGroup +1)         │
                   │  → adminOnly                                │
                   │  → recover                                  │
                   │  → handler (sendText via HTTP/2 conn pool)  │
                   └────────────────────────────────────────────┘
                        │
                        ▼ (svc.Info/Warning/Error)
                   ┌────────────────┐
                   │ async log chan │ ──► dedicated writer ──► panelLogger
                   │ (cap 1024)     │
                   └────────────────┘

A single goroutine long-polls getUpdates and pushes into a buffered channel (capacity 1024). A worker pool sized at NumCPU*2 (floor of 8) drains it. Each update spawns a per-handler goroutine wrapped in a middleware chain: a trackerMiddleware that increments a WaitGroup for clean shutdown, an adminOnly gate, a recover so one panicking handler never takes down the pool, and finally the handler itself sending replies through the shared HTTP/2 connection pool. Logging is fire-and-forget into another 1024-cap channel drained by a dedicated writer—so logging never blocks a handler. This is textbook Go: bounded channels for backpressure, a fixed worker pool to cap concurrency, recover per goroutine for fault isolation, and a WaitGroup for graceful drain.

The command surface is registered automatically via SetMyCommands, so everything shows up in Telegram's / menu. Highlights:

Command	Description
`/start`	Start the bot; first-time users pick a language (🇬🇧 / 🇮🇷).
`/menu`, `/help`, `/cancel`	Navigation and flow control.
`/users`, `/adduser`, `/adduser_interactive`	Paginated user list; quick or step-by-step user creation.
`/server`	View/edit server config field by field.
`/blockedips`, `/blockedaccess`	Manage blocked IPs and browse blocked-access logs.
`/logs`	Browse access logs (last 20 per user).
`/traffic`, `/sessions`	Per-user traffic; list and revoke sessions.
`/restart_server`, `/restart_panel`	Restart either service, with confirmation.

Build and deploy

From source you need Go 1.21+:

git clone https://github.com/ebrasha/abdal-4iproto-panel.git
cd abdal-4iproto-panel
go build -o abdal-4iproto-panel main.go      # Linux
go build -o abdal-4iproto-panel.exe main.go  # Windows

As a service, the binary self-registers. On Windows:

abdal-4iproto-panel.exe install
abdal-4iproto-panel.exe start

On Linux with systemd:

sudo ./install-abdal-4iproto-panel.sh
sudo systemctl enable abdal-4iproto-panel
sudo systemctl status abdal-4iproto-panel

For a hands-off setup, the Abdal 4iProto Cli detects your OS/architecture, verifies SHA-256 checksums, configures ports, generates SSH keys, and registers persistent services.

FAQ

Does the panel need a database? No. State is stored in flat JSON files, which keeps deployment to a single binary and makes backups a file copy.

Can I cap individual users? Yes—per-user speed limits (KB/s), traffic quotas (MB), session limits, and TTL are all configurable.

Is the Telegram bot safe to expose? It only accepts updates from explicitly listed admin IDs and rejects everything else. Treat the token like a secret and restrict admins tightly.

Windows and Linux both? Yes—single binary per platform, installable as a Windows Service or a Linux systemd unit.

Closing thought

The design philosophy behind Abdal 4iProto Panel is that operational tooling should reduce moving parts, not add them. One binary, embedded assets, JSON state, and a concurrency model that isolates the bot from the UI—each decision trades novelty for fewer 2 a.m. surprises.

Handcrafted with passion by Ebrahim Shafiei (EbraSha) — 📧 Prof.Shafiei@Gmail.com · ✈️ @ProfShafiei

Build a Self-Hosted SSH Tunneling Server with Per-User Accounting (Abdal 4iProto)

Ebrahim Shafiei — Tue, 09 Jun 2026 22:02:29 +0000

Build a Self-Hosted SSH Tunneling Server with Per-User Accounting

If you want a self-hosted SSH tunneling server that handles bandwidth limits, session control, and brute-force protection without you scripting any of it, this walkthrough is for you. We'll set up Abdal 4iProto Server — a Go-based tunnel by Ebrahim Shafiei (EbraSha) — from build to first connection, and I'll explain the config decisions along the way so you're not just copy-pasting blindly.

Heads up: this server is part of the broader Abdal 4iProto ecosystem (https://github.com/4iProto), so there are matching clients and tools once your server is up.

What you'll have at the end

A running tunnel server with per-user speed caps, total-traffic quotas, concurrent-session limits, automatic IP blocking on failed logins, and a SOCKS5 endpoint your apps can use. Let's go.

Step 1: Prerequisites

You need:

Go 1.25.10 or higher
An SSH private key (id_rsa)
A Linux or Windows host

Step 2: Generate your host key

ssh-keygen -t rsa -b 4096 -f id_rsa

Drop the resulting id_rsa in the project directory.

Step 3: Write the server config

Create server_config.json. On Linux:

{
  "ports": [64235, 64236, 64237],
  "shell": "/bin/bash",
  "max_auth_attempts": 3,
  "server_version": "SSH-2.0-Abdal-4iProto-Server"
}

On Windows, swap the shell:

{
  "ports": [64235, 64236, 64237],
  "shell": "cmd.exe",
  "max_auth_attempts": 3,
  "server_version": "SSH-2.0-Abdal-4iProto-Server"
}

The ports array makes the server listen on several ports at once. max_auth_attempts: 3 means three strikes and the IP is auto-blocked. server_version customizes the banner.

Step 4: Define your users

Create users.json. Here's an admin and a rate-limited user:

[
  {
    "username": "ebrasha",
    "password": "change-me",
    "role": "admin",
    "blocked_domains": [],
    "blocked_ips": [],
    "log": "no",
    "max_sessions": 1,
    "session_ttl_seconds": 300
  },
  {
    "username": "user1",
    "password": "change-me-too",
    "role": "user",
    "blocked_domains": ["facebook.com", "*.facebook.com"],
    "blocked_ips": ["10.0.0.*", "172.16.*.*"],
    "log": "yes",
    "max_sessions": 2,
    "session_ttl_seconds": 300
  }
]

Key fields to understand:

role: admin gets host shell access; user is tunnel-only. Keep day-to-day accounts as user.
blocked_domains / blocked_ips: support wildcards (*.facebook.com) and ranges (10.0.0.*).
log: per-user visited-site tracking — "yes" or "no".
max_sessions: concurrent session ceiling.
session_ttl_seconds: hard session lifetime before auto-reap.

To add bandwidth control, set max_speed_kbps (e.g. 1024 = 1 MB/s, enforced via token bucket on both directions) and max_total_mb (e.g. 10240 = 10 GB total quota). Quotas are checked every 1–2 seconds, and over-quota sessions are disconnected immediately — not just refused at next login.

Step 5: Build and run

go mod tidy
go build -o abdal-4iproto-server
./abdal-4iproto-server

That's it — the server is listening.

Step 6: Connect

The quickest test is a standard dynamic-forwarding SSH client:

ssh -D 1080 username@server_ip -p 22

Now point any app at the local SOCKS5 proxy and your traffic tunnels through. On Linux you can route everything with sshuttle:

sshuttle --dns -r ebrasha@SERVER_IP:2222 0.0.0.0/0 -vv

For a GUI experience, grab the official clients: Windows and Android.

Optional: relay traffic through another host with iptables NAT

If you need a relay in front of your server, enable forwarding and NAT:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination IRAN_IP
iptables -t nat -A PREROUTING -j DNAT --to-destination 4iProto_IP
iptables -t nat -A POSTROUTING -j MASQUERADE

⚠️ Gotcha: the SSH-port DNAT rule must come before the general PREROUTING rule, and confirm you have alternate SSH access before applying these — it's an easy way to lock yourself out.

What's happening under the hood

A few implementation notes worth knowing as you operate this:

Rate limiting uses a token-bucket algorithm, which smooths throughput while allowing short bursts — friendlier to interactive sessions than a hard window.
Traffic accounting flushes to traffic_<username>.json every 10 seconds, so a crash costs at most a few seconds of stats.
Failed logins go to invalid_logins.log with the attempted credentials and IP; blocked IPs persist in blocked_ips.json.
TCP and UDP forwarding are both supported, plus DNSTT for DNS tunneling on hostile networks.

The full ecosystem

Component	Repository
🔐 Server	abdal-4iproto-server
⚙️ Web Panel	abdal-4iproto-panel
💻 Windows Client	abdal-4iproto-client
📱 Android Client	abdal-4iproto-client-android
🖱️ CLI Installer	abdal-4iproto-cli
🗝️ SSH KeyGen	abdal-4iproto-server-ssh-keygen

Tip: the CLI installer automates OS/arch detection, SHA-256 verification, port config, key generation, and service registration if you'd rather skip the manual build.

🔗 Source: https://github.com/ebrasha/abdal-4iproto-server

FAQ

Do I need the GUI clients? No — any SSH client with -D dynamic forwarding works. The clients just make it nicer.

How do I cap a user's speed? Add max_speed_kbps to their users.json entry (1024 = 1 MB/s).

What happens when a user hits their data quota? They're disconnected mid-session within 1–2 seconds and refused at next login until the quota resets.

Build a Device-Wide SSH Tunnel on Android with Abdal 4iProto Android

Ebrahim Shafiei — Tue, 09 Jun 2026 20:52:46 +0000

Build a Device-Wide SSH Tunnel on Android with Abdal 4iProto
If you've ever run ssh -D 1080 and pointed your browser at a local SOCKS5 proxy, you already understand half of what this app does. The other half is the interesting part: doing it for every app on your phone, with no root, and with leak protection that actually holds up. Let's walk through it hands-on.
Abdal 4iProto Android is the Android client of the open-source Abdal 4iProto ecosystem by Ebrahim Shafiei (EbraSha). It builds a device-wide SSH tunnel on Android, routing all traffic through an encrypted connection to your own server. No third-party VPN provider, no per-app juggling.
TL;DR of the data flow
Here's the path a packet takes, start to finish:

 App → VpnService (TUN, raw IP packets)
    → hev-socks5-tunnel (native tun2socks via JNI)
    → local SOCKS5 bridge
    → SSH direct-tcpip channel (JSch)
    → your Abdal 4iProto Server → Internet

The trick is that SSH forwards TCP streams, but the OS gives you raw IP packets. The native tun2socks engine bridges that gap by turning packets into SOCKS5 connections, which then get forwarded over SSH.
Step 1: Stand up a server
This is a client, so you need the other end. Grab the server component from the ecosystem repo and get it running first. You'll need its IP/hostname, port, and an SSH username/password.
Step 2: Install and add a server
Open the app, then:

Hamburger menu → Server Management → Add Server
Enter a friendly name, your server's IP/hostname, port, username, and password
Select the server on the main screen

You can store multiple named servers and switch between them — handy if you run more than one.
Step 3: Configure before connecting
A gotcha worth flagging up front: connection options are applied at connect time, so toggle them before you tap Connect.
The ones worth knowing:

Fake-IP / FakeDNS — resolves domains on the server (remote DNS) so no real DNS query leaves your device. Turn this on to close the DNS-leak gap. With it off, you still get tunneled DNS-over-TCP.
Kill Switch — blocks all traffic if the tunnel drops unexpectedly, with no leak gap, until it reconnects or you disconnect.
Advanced Settings → Whitelist IPs / CIDR — comma-separated IPs or CIDR blocks that should bypass the tunnel.

Step 4: Per-app split tunneling (optional)
Open the Per-App Split Tun screen and pick a mode:

Route via Tunnel → only the apps you select are tunneled.
Bypass Tunnel → everything is tunneled except the apps you select.

The list is searchable and each app gets its own toggle. Apps kept off the tunnel are also exempt from the kill switch, so they keep normal connectivity.
Step 5: Connect
Tap Connect and grant the VPN permission when Android prompts. That permission is what lets the app stand up its VpnService TUN interface. Once it's up, your whole device is tunneled. Watch the real-time logs from the menu to confirm what's happening.
Tap Disconnect to tear it down.
Why it doesn't leak
Two implementation details do the heavy lifting here, and they're worth understanding if you build networking apps yourself:

The control socket is protected. The SSH connection itself is wrapped in VpnService.protect() so it doesn't get routed back into the TUN interface. Skip this and you get a routing loop that kills reconnects.
Local ranges bypass automatically. Private/LAN ranges (192.168.x.x, 10.x.x.x) skip the tunnel, so your router, printer, and any phone-hosted services keep working. On API 33+ this uses excludeRoute().

The stack, quickly

minSdk 24 (Android 7.0)  ·  compileSdk/targetSdk 36 (Android 16)
applicationId net.abdal.abdal4iproto.client  ·  versionName 5.2

Kotlin 2.2.10 · AGP 9.1.1 · Gradle 9.3.1 · KSP 2.3.5 · Java 11
UI: Jetpack Compose (Material 3), Navigation Compose 2.8.9
SSH: JSch (mwiede fork) 0.2.21
Crypto: Bouncy Castle bcprov-jdk18on 1.84  → ssh-ed25519 host keys
Coroutines: kotlinx-coroutines 1.10.2
Persistence: Room 2.7.0 (KSP)
Native: hev-socks5-tunnel (.so) tun2socks via JNI (TProxyService)

The native tun2socks engine is the deliberate performance call — packet translation stays in compiled native code instead of crossing the JNI boundary per packet in managed Kotlin.
Wrapping up
The whole design comes down to one principle: capture everything, leak nothing, and keep the trust boundary at your server. No telemetry, open source, auditable via live logs. If you've been meaning to graduate from per-app proxies to a real device-wide tunnel you actually control, this is a clean way to do it.
FAQ
Do I need root? No — it uses VpnService.
Why does my home network still work while connected? Private/LAN ranges bypass the tunnel by design.
What's the minimum Android version? API 24. Some routing features need API 33+.
Can I tunnel only specific apps? Yes — use the Per-App Split Tun screen's "Route via Tunnel" mode.

https://github.com/ebrasha/abdal-4iproto-client-android

🤵 Programmer

Handcrafted with Passion by Ebrahim Shafiei (EbraSha)