Files
Easytier/easytier
KKRainbow 8794e12a26 feat(vpn): hot add/remove WireGuard portal clients without restart (#2514)
* feat(vpn): hot add/remove WireGuard portal clients without restart

WireGuard portal clients were frozen at instance construction: the
engine slot maps, host key table, and PortalModule state were all
immutable after startup, so any client change required recreating the
whole instance and dropping every established session.

Wire dynamic client management through the existing config-patch
channel (ConfigRpc.patch_config -> apply_config_patch), following the
same pattern as connectors, port forwards, and proxy networks:

- proto: InstanceConfigPatch gains repeated VpnPortalClientPatch
  (Add/Remove/Clear by client name)
- engine: slot maps move under an RwLock with a free-index allocator;
  add_client/remove_client recycle indices, mark removed slots retired,
  and expire active sessions so Core tears down the attached peer via
  the regular channel-close path (credential revocation and disconnect
  events included); untouched clients keep their sessions intact. The
  retired flag is re-checked under the session lock so a datagram that
  races with removal cannot resurrect a session
- host: WireGuardPortalHost derives keys deterministically per name
  (HKDF), keeps a mutable client table for render_client_config, and
  forwards updates to the live engine; changed clients are re-added so
  they re-handshake into a fresh generation with the new virtual IP or
  groups
- PortalModule: client set, statuses, and session locks become shared
  mutable state; run_session resolves clients from the shared map at
  accept time; update_clients() validates against a caller-supplied
  runtime snapshot. An empty client set is legal in every lifecycle
  stage, so clearing all clients never produces a configuration that
  fails instance recreation
- config_patch: apply_vpn_portal_client_patches mutates the candidate
  TOML; the sub-patch runs last and is deep-validated and hot-applied
  before the candidate commits, so a rejected client set leaves neither
  the shared model nor the live portal changed, and validation sees the
  fully patched state including routes and node IPv4 from the same
  request. Rejects patches when no portal is configured or a removed
  client does not exist
- cli: vpn-portal add-client/remove-client/clear-clients subcommands

Tests: engine index recycling, module update validation/state/host
notification, TOML patch application, and a three-node integration test
that adds a second WireGuard client live, removes the first while the
second stays online, and asserts rejected patches leave the shared
model unchanged.

* feat(web): reconcile WireGuard portal client edits as hot patches

The web console reconciles desired network config against the running
instance and patches it in place when possible. VPN portal changes were
not part of that: any client edit made the base configs differ, so every
save recreated the instance and dropped all established sessions.

Exclude vpn_portal_config from the base comparison and diff its clients
by name instead. Client add/remove/change now produces
VpnPortalClientPatch entries (removals first, changed clients as
remove+add) applied through the existing PatchConfig channel. Listener
identity changes (address or private key) and enabling or disabling the
portal still fall back to a full instance recreate, since those change
the listener lifecycle.

* feat(web/gui): map portal client patches to frontend RPC backends

Extend the RemoteClient seam with add/remove/clear VPN portal client
operations so frontend hosts can drive the same PatchConfig channel as
the CLI. There is deliberately no dedicated editing UI: the config form
stays the single editing surface (aligned with port forwards), and
these methods exist for programmatic and future use.

- web console: JSON proxy-rpc to ConfigRpcService.patch_config with
  VpnPortalClientPatch entries (pbjson string enum actions)
- desktop GUI: patch_vpn_portal_clients tauri command forwarding the
  same patch through the typed ConfigRpc client
2026-08-22 01:18:42 +08:00
..

EasyTier

Github release GitHub GitHub last commit GitHub issues GitHub Core Actions GitHub GUI Actions GitHub Test Actions Ask DeepWiki

简体中文 | English

A simple, secure, decentralized virtual private network solution powered by Rust and Tokio

config page running page

📚 Full Documentation | 🖥️ Web Console | 📝 Download Releases | 🧩 Third Party Tools | ❤️ Sponsor

Features

Core Features

  • 🔒 Decentralized: Nodes are equal and independent, no centralized services required
  • 🚀 Easy to Use: Multiple operation methods via web, client, and command line
  • 🌍 Cross-Platform: Supports Win/MacOS/Linux/FreeBSD/Android and X86/ARM/MIPS architectures
  • 🔐 Secure: AES-GCM or WireGuard encryption, prevents man-in-the-middle attacks

Advanced Capabilities

  • 🔌 Efficient NAT Traversal: Supports UDP and IPv6 traversal, works with NAT4-NAT4 networks
  • 🌐 Subnet Proxy: Nodes can share subnets for other nodes to access
  • 🔄 Intelligent Routing: Latency priority and automatic route selection for best network experience
  • High Performance: Zero-copy throughout the entire link, supports TCP/UDP/WSS/WG protocols

Network Optimization

  • 📊 UDP Loss Resistance: KCP/QUIC proxy optimizes latency and bandwidth in high packet loss environments
  • 🔧 Web Management: Easy configuration and monitoring through web interface
  • 🛠️ Zero Config: Simple deployment with statically linked executables

Quick Start

📥 Installation

Choose the installation method that best suits your needs:

Linux (Recommended):

curl -fsSL "https://github.com/EasyTier/EasyTier/blob/main/script/install.sh?raw=true" | sudo bash -s install

Homebrew (MacOS/Linux):

brew tap brewforge/chinese
brew install --cask easytier-gui

Windows (Recommended, run with administrator privileges):

irm "https://github.com/EasyTier/EasyTier/blob/main/script/install.ps1?raw=true" | iex

Install via cargo (Latest development version):

cargo install --git https://github.com/EasyTier/EasyTier.git easytier

Install pre-built binary (Recommended, All platforms supported)

Install via Docker

Install OpenWrt ipk package

Additional steps:

One-Click Register Service (Automatically start when the system boots and run in the background)

🚀 Basic Usage

Quick Networking with Shared Nodes

EasyTier supports quick networking using shared public nodes. When you don't have a public IP, you can use the free shared nodes provided by the EasyTier community. Nodes will automatically attempt NAT traversal and establish P2P connections. When P2P fails, data will be relayed through shared nodes.

When using shared nodes, each node entering the network needs to provide the same --network-name and --network-secret parameters as the unique identifier of the network.

Taking two nodes as an example (Please use more complex network name to avoid conflicts):

  1. Run on Node A:
# Run with administrator privileges
sudo easytier-core -d --network-name abc --network-secret abc -p tcp://<SharedNodeIP>:11010
  1. Run on Node B:
# Run with administrator privileges
sudo easytier-core -d --network-name abc --network-secret abc -p tcp://<SharedNodeIP>:11010

After successful execution, you can check the network status using easytier-cli:

| ipv4         | hostname       | cost  | lat_ms | loss_rate | rx_bytes | tx_bytes | tunnel_proto | nat_type | id         | version         |
| ------------ | -------------- | ----- | ------ | --------- | -------- | -------- | ------------ | -------- | ---------- | --------------- |
| 10.126.126.1 | abc-1          | Local | *      | *         | *        | *        | udp          | FullCone | 439804259  | 2.6.2-70e69a38~ |
| 10.126.126.2 | abc-2          | p2p   | 3.452  | 0         | 17.33 kB | 20.42 kB | udp          | FullCone | 390879727  | 2.6.2-70e69a38~ |
|              | PublicServer_a | p2p   | 27.796 | 0.000     | 50.01 kB | 67.46 kB | tcp          | Unknown  | 3771642457 | 2.6.2-70e69a38~ |

You can test connectivity between nodes:

# Test connectivity
ping 10.126.126.1
ping 10.126.126.2

Note: If you cannot ping through, it may be that the firewall is blocking incoming traffic. Please turn off the firewall or add allow rules.

To improve availability, you can connect to multiple shared nodes simultaneously:

# Connect to multiple shared nodes
sudo easytier-core -d --network-name abc --network-secret abc -p tcp://<SharedNodeIP1>:11010 -p udp://<SharedNodeIP2>:11010

Once your network is set up successfully, you can easily configure it to start automatically on system boot. Refer to the One-Click Register Service guide for step-by-step instructions on registering EasyTier as a system service.

Decentralized Networking

EasyTier is fundamentally decentralized, with no distinction between server and client. As long as one device can communicate with any node in the virtual network, it can join the virtual network. Here's how to set up a decentralized network:

  1. Start First Node (Node A):
# Start the first node
sudo easytier-core -i 10.144.144.1

After startup, this node will listen on the following ports by default:

  • TCP: 11010
  • UDP: 11010
  • WebSocket: 11011
  • WebSocket SSL: 11012
  • WireGuard: 11013
  1. Connect Second Node (Node B):
# Connect to the first node using its public IP
sudo easytier-core -i 10.144.144.2 -p udp://FIRST_NODE_PUBLIC_IP:11010
  1. Verify Connection:
# Test connectivity
ping 10.144.144.2

# View connected peers
easytier-cli peer

# View routing information
easytier-cli route

# View local node information
easytier-cli node

For more nodes to join the network, they can connect to any existing node in the network using the -p parameter:

# Connect to any existing node using its public IP
sudo easytier-core -i 10.144.144.3 -p udp://ANY_EXISTING_NODE_PUBLIC_IP:11010

🔍 Advanced Features

Subnet Proxy

Assuming the network topology is as follows, Node B wants to share its accessible subnet 10.1.1.0/24 with other nodes:

flowchart LR

subgraph Node A Public IP 22.1.1.1
nodea[EasyTier<br/>10.144.144.1]
end

subgraph Node B
nodeb[EasyTier<br/>10.144.144.2]
end

id1[[10.1.1.0/24]]

nodea <--> nodeb <-.-> id1

To share a subnet, add the -n parameter when starting EasyTier:

# Share subnet 10.1.1.0/24 with other nodes
sudo easytier-core -i 10.144.144.2 -n 10.1.1.0/24

Subnet proxy information will automatically sync to each node in the virtual network, and each node will automatically configure the corresponding route. You can verify the subnet proxy setup:

  1. Check if the routing information has been synchronized (the proxy_cidrs column shows the proxied subnets):
# View routing information
easytier-cli route

Routing Information

  1. Test if you can access nodes in the proxied subnet:
# Test connectivity to proxied subnet
ping 10.1.1.2

WireGuard Integration

EasyTier can act as a WireGuard server, allowing any device with a WireGuard client (including iOS and Android) to access the EasyTier network. Here's an example setup:

flowchart LR

ios[[iPhone<br/>WireGuard Installed]]

subgraph Node A Public IP 22.1.1.1
nodea[EasyTier<br/>10.144.144.1]
end

subgraph Node B
nodeb[EasyTier<br/>10.144.144.2]
end

id1[[10.1.1.0/24]]

ios <-.-> nodea <--> nodeb <-.-> id1
  1. Start EasyTier with WireGuard portal enabled:
# Register one WireGuard client as virtual peer 10.144.144.3
sudo easytier-core -i 10.144.144.1 \
  --network-secret portal-secret \
  --vpn-portal wg://0.0.0.0:11013 \
  --vpn-portal-private-key "$(wg genkey)" \
  --vpn-portal-client phone=10.144.144.3
  1. Get WireGuard client configuration:
# Get WireGuard client configuration
easytier-cli vpn-portal
  1. In the output configuration, replace a wildcard Peer.Endpoint with the public IP/domain of your EasyTier node, then import it. Interface.Address is local to that WireGuard client and may be changed to any IPv4 address; EasyTier translates it to the registered virtual-peer address.

Self-Hosted Public Shared Node

You can run your own public shared node to help other nodes discover each other. A public shared node is just a regular EasyTier network (with same network name and secret) that other networks can connect to.

To run a public shared node:

# No need to specify IPv4 address for public shared nodes
sudo easytier-core --network-name mysharednode --network-secret mysharednode
  • ZeroTier: A global virtual network for connecting devices.
  • TailScale: A VPN solution aimed at simplifying network configuration.

Contact Us

License

EasyTier is released under the LGPL-3.0.

Sponsor

CDN acceleration and security protection for this project are sponsored by Tencent EdgeOne.

EdgeOne Logo

Special thanks to Langlang Cloud and RainCloud for sponsoring our public servers.

If you find EasyTier helpful, please consider sponsoring us. Software development and maintenance require a lot of time and effort, and your sponsorship will help us better maintain and improve EasyTier.