[eostre.git] / meatviewer / what-is.mdwn

Sometimes people need tech support. Oftentimes, those people are behind firewalls and/or NATs. Oftentimes the tech support person is also behind a NAT.

This presents us with a problem - we can't just connect to the user's public IP if they're behind a NAT, and we don't want to rely on them being able to port-forward.

So, how do we access their computer?

I'll explain how we can use nothing but SSH and a host on the public internet to implement a secure tunnel between two computers over WAN, allowing our techy to remote into our end user's computer.

Firstly, NAT - NAT is a magical little tool that hides your private little home network from the rest of the internet\*. It allows TCP/IP connections to be initiated from the private side to the public side, but not the other way around\*.

\* this is a lie

Secondly, SSH - SSH is a wonderful little protocol that can be used for about anything. Most people use it to get a shell on a remote machine, but really just about any data can be sent through SSH.

A neat little feature of SSH is ssh tunneling, actived by the -L switch. ssh tunneling takes all traffic directed at a given port, and spits it out the other end of the tunnel on the server - you specify a port on your local computer that you would like to forward to the server\*\*, it Just Works(tm). Note that this tunnel is unidirectional, you need something listening at the other end of the tunnel if you want to actually do anything.

\*\* the ssh server does need to have `PortForwarding yes`, which fencepost currently has disabled (2020-09-03)

If we try to have both our techy and our end user use regular ssh tunneling, nothing will happen because they're both throwing packets through the tunnel but nobody is actually catching them. You'll see errors like "error: channel 3: connect failed" if this is happening.

There's also a neat little feature called reverse ssh tunneling, activated with -R; in a reverse tunnel, we take packets from the server and sends them to our local computer. reverse tunneling forwards packets from a port on the server to our local computer.

Our theory of operation becomes apparent: forward traffic from our techy's computer to the proxy server, and then reverse-forward\*\*\* the traffic from our end user. Traffic goes into the port on our techy's computer, gets forwarded to our proxy, and then gets sucked back down the reverse tunnel created by our end user.

\*\*\*"backward?"

---

![basically, how it works](packetflow.jpg)

forgive my awful drawing skills

---

So, the commands we need to run are:

techy: `ssh -L 2222:localhost:43130 user@proxyhost`

end user: `ssh -R 43130:localhost:22 user@proxyhost`

This sends traffic from `techy port 2222` through proxyhost and back down to `end user port 22`, where the end user hopefully has `sshd` running. The techy can then point their ssh client at localhost:2222 to log in to the end user's computer.

43130 is just a random port number I chose, you can choose any port number you like above port 1000, just make sure it's the same port in both commands.

You can have the user open up any port on their machine too, not just port 22. Change the command to `-R 43130:localhost:5900`, for example, to access a VNC server they have running. I just suggest using SSH where possible to save on bandwidth; using VNC over a WAN is less than pleasant.
Commit	Line	Data
524da846	1	Sometimes people need tech support. Oftentimes, those people are behind firewalls and/or NATs. Oftentimes the tech support person is also behind a NAT.
	2
	3	This presents us with a problem - we can't just connect to the user's public IP if they're behind a NAT, and we don't want to rely on them being able to port-forward.
	4
	5	So, how do we access their computer?
	6
	7	I'll explain how we can use nothing but SSH and a host on the public internet to implement a secure tunnel between two computers over WAN, allowing our techy to remote into our end user's computer.
	8
	9	Firstly, NAT - NAT is a magical little tool that hides your private little home network from the rest of the internet\. It allows TCP/IP connections to be initiated from the private side to the public side, but not the other way around\.
	10
	11	\* this is a lie
	12
	13	Secondly, SSH - SSH is a wonderful little protocol that can be used for about anything. Most people use it to get a shell on a remote machine, but really just about any data can be sent through SSH.
	14
	15	A neat little feature of SSH is ssh tunneling, actived by the -L switch. ssh tunneling takes all traffic directed at a given port, and spits it out the other end of the tunnel on the server - you specify a port on your local computer that you would like to forward to the server\\, it Just Works(tm). Note that this tunnel is unidirectional, you need something listening at the other end of the tunnel if you want to actually do anything.
	16
	17	\\ the ssh server does need to have `PortForwarding yes`, which fencepost currently has disabled (2020-09-03)
	18
	19	If we try to have both our techy and our end user use regular ssh tunneling, nothing will happen because they're both throwing packets through the tunnel but nobody is actually catching them. You'll see errors like "error: channel 3: connect failed" if this is happening.
	20
	21	There's also a neat little feature called reverse ssh tunneling, activated with -R; in a reverse tunnel, we take packets from the server and sends them to our local computer. reverse tunneling forwards packets from a port on the server to our local computer.
	22
	23	Our theory of operation becomes apparent: forward traffic from our techy's computer to the proxy server, and then reverse-forward\\\* the traffic from our end user. Traffic goes into the port on our techy's computer, gets forwarded to our proxy, and then gets sucked back down the reverse tunnel created by our end user.
	24
	25	\\\*"backward?"
	26
	27	---
	28
	29	![basically, how it works](packetflow.jpg)
	30
	31	forgive my awful drawing skills
	32
	33	---
	34
	35	So, the commands we need to run are:
	36
	37	techy: `ssh -L 2222:localhost:43130 user@proxyhost`
	38
	39	end user: `ssh -R 43130:localhost:22 user@proxyhost`
	40
	41	This sends traffic from `techy port 2222` through proxyhost and back down to `end user port 22`, where the end user hopefully has `sshd` running. The techy can then point their ssh client at localhost:2222 to log in to the end user's computer.
	42
	43	43130 is just a random port number I chose, you can choose any port number you like above port 1000, just make sure it's the same port in both commands.
	44
	45	You can have the user open up any port on their machine too, not just port 22. Change the command to `-R 43130:localhost:5900`, for example, to access a VNC server they have running. I just suggest using SSH where possible to save on bandwidth; using VNC over a WAN is less than pleasant.