When two devices are behind NAT or strict firewalls and cannot \u201csee\u201d each other directly, a VPN seems to be the standard solution. But a full-fledged L3 tunnel (like WireGuard or OpenVPN) is often redundant: it requires root rights, setting up virtual interfaces, and can conflict with existing routes.<\/p>\n
In such cases, it is convenient to use Chisel<\/b> – a TCP\/UDP tunnel that runs on top of HTTP and uses WebSockets for data transfer. In this note I will show how to \u201cforward\u201d a port from one client to another through an intermediate server.<\/p>\nHow does it work?<\/h2>\n
Imagine the situation: you have Client A<\/b> (for example, your home server), Client B<\/b> (your work laptop) and a VPS<\/b> with a public IP address. Clients A and B can access the VPS, but not each other.<\/p>\n
The forwarding scheme will look like this:
\n1. Client A<\/b> connects to the VPS and opens a \u201creverse\u201d port on the server. Now everything that comes to port X of the server goes to port Y of Client A.
\n2. Client B<\/b> connects to the VPS and forwards port Z from its local machine to port X of the server.
\n3. As a result, Client B accesses localhost:Z<\/b> and ends up on Client A:Y<\/b>.<\/p>\n
This approach is one of the solutions in cases where communication with a VPS does not implement an L3 layer or there is no ability to configure routing between clients. We work exclusively at the application and port level.<\/p>\n
On your VPS, just run Chisel in server mode. The Let’s say Client A wants to open access to his local web server on port 3000. He connects to the VPS and says: \u201creserve port 2000 on the server and forward it to me to 3000.\u201d<\/p>\n Now port 2000 on the VPS (on the loopback interface) leads to Client A.<\/p>\n Now Client B wants to access this resource. It connects to the same VPS and forwards its local port 8080 to port 2000 of the server.<\/p>\n Ready! Now, when you open Chisel supports authentication via the The main advantage of this approach is that there is no need for TUN\/TAP devices and complex routing tables. This is a stripped-down tunnel that does exactly one thing: binds ports via a WebSocket connection. This even works through corporate proxies if you configure Chisel to work through port 443.<\/p>\n Chisel is a utility for specific network tasks. When you need to forward ports between isolated nodes without setting up a full-fledged VPN, a combination of forward and reverse tunnels through a relay server turns out to be a completely viable solution.<\/p>\n--reverse<\/code> flag is required to allow clients to open ports on the server side.<\/p>\nchisel server --port 8080 --reverse\n<\/code><\/pre>\n<\/div>\nStep 2: Connecting Client A (Source)<\/h2>\n
chisel client vps-ip:8080 R:2000:127.0.0.1:3000\n<\/code><\/pre>\n<\/div>\nStep 3: Connecting Client B (Consumer)<\/h2>\n
chisel client vps-ip:8080 8080:127.0.0.1:2000\n<\/code><\/pre>\n<\/div>\nhttp:\/\/localhost:8080<\/code> on Client B, you will see the service running on Client A.<\/p>\nSafety and nuances<\/h2>\n
--auth<\/code> flag, which is highly recommended when working through public servers. You can also use TLS certificates to encrypt traffic.<\/p>\nOutput<\/h2>\n
Links<\/h2>\n