Alright, let’s talk about this “tunnel 1” thing I messed around with today. It was a bit of a head-scratcher at first, but I think I’ve got a handle on it now. Basically, I was trying to get traffic from one network to another, securely, without exposing everything to the public internet. Think of it like building a secret passage between two houses.
First thing I did was fire up a couple of VMs. I needed two separate environments to simulate the networks I wanted to connect. I used Vagrant, because that’s just how I roll – quick and easy. Got ’em both running Ubuntu Server, nice and clean.
Next up: I picked a tunneling protocol. I went with SSH tunneling because it’s pretty common and I’m familiar with it. There are other options, like WireGuard or Open加速器, but SSH was good enough for this test. Plus, I didn’t want to spend all day configuring certificates and whatnot.
Okay, so the key is setting up the SSH tunnel. I hopped onto my ‘client’ VM (the one that needed to access the other network) and used the following command:
ssh -N -L 8080:server_ip:80 user@server_ip
Let me break that down a bit. -N means “don’t execute a remote command” – we just want the tunnel. -L is for “local port forwarding”. I’m telling SSH to listen on port 8080 on my client VM, and forward any traffic it receives there to port 80 on the ‘server’ VM (replace server_ip with the actual IP address of the server VM).
Important bit: You gotta make sure that SSH is allowed through the firewall on the server VM. I just did a quick sudo ufw allow ssh. Don’t do this in a real production environment, obviously – be more specific with your rules!
Then I needed something running on port 80 of the server VM to test the tunnel. I just threw up a quick Python web server:
python3 -m * 80
Super basic, but it does the job. Now, back on the client VM, I opened up a web browser and went to localhost:8080. And BAM! I saw the directory listing from the Python web server running on the other VM. Traffic was going through the tunnel!
Of course, it wasn’t all smooth sailing. I messed up the IP addresses a couple of times, and spent way too long staring at error messages before realizing I hadn’t actually started the Python web server on the server VM. Classic.
To make it a bit more useful, I started playing around with dynamic port forwarding. This lets you tunnel all sorts of traffic through the SSH connection, not just web traffic. For that, you use the -D option in the SSH command:
ssh -D 1080 user@server_ip
This creates a SOCKS proxy on port 1080 of the client VM. Then, you have to configure your applications (like your web browser) to use that SOCKS proxy. I used a browser extension called “FoxyProxy” to make it easy to switch the proxy on and off.
So, yeah, that’s “tunnel 1” in a nutshell. It’s not the most sophisticated solution, but it’s a handy way to get started with network tunneling and understand the basic concepts. Plus, it’s a good reminder that sometimes the simplest tools are the most effective.
- Spin up VMs
- Choose SSH tunneling
- Configure SSH tunnel with port forwarding
- Start a web server on the target VM
- Test the connection through the tunnel
- Experiment with dynamic port forwarding
