SSH local port forwarding ... Anycast Style
SSH by its self is a wonderful tool, but when you combine it with a little bit of ingenuity, it can be EXTREMELY powerful. You can use the following technique to locally access remote services through an ssh port forward without having to change anything else about the way that you access a remote resource. This means that you won't have to mess with the /etc/hosts file, or DNS entries, or deal with SSL cert Common Name mismatches anymore.
Recall that the ssh command has the ability to forward local ports to remote systems. using the following syntax:
ssh -L LocalIP:LocalPort:RemoteIP:RemotePort RemoteSystem
Most of the time people will use a local IP to bind the ssh port forwarding to. However, there is no requirement that a local IP address be used. (I'm referring to local IP addresses as those reserved in RFC 3330 - Special-Use IPv4 Addresses as local.) You can just as easily use any IP address that is bound locally. So, if you bind your remote IP address to a local interface, you can bind your ssh port forwarding to your remote IP address.
Use the following command to add the remote IP address to a local interface.
ip addr add RemoteIP/32 dev lo
Here we are binding an additional IP address to the loop back interface. The ingenuity of this technique is that we are binding the remote IP that we want to access as if it were local. (Note: We could easily do the same thing with "ifconfig" but we would have to worry about alias numbers. "ip" does not have the same limitation as "ifconfig".) So, if we are wanting to access 192.0.2.123, we would use the following commands.
Bind the IP...
ip addr add 192.0.2.123/32 dev lo
SSH to the remote system with port forwarding...
ssh -L 192.0.2.123:443:192.0.2.123:443 RemoteSystem
Presuming that everything is working properly, you can now open your web browser and connect to the ""remote IP like normal.
https://192.0.2.123/
What's better is that you can use the name that resolves to the remote IP, thus matching the Common Name of the SSL certificate. There by avoiding any common SSL errors.
https://www.example.net/
This technique is very simple and does not really do anything complex. We are simply utilizing classic routing that has existed since the inception of TCP/IP to cause our clients to connect to the the first instance of the ""remote IP that it comes to, which happens to be on our systems. (Incidentally, this is how anycast works.) All that we need to do is to make sure that our local instance of the IP is offering the service(s) that we care about. We accomplish this by using ssh port forwarding to cause traffic to our local instance of the IP to be forwarded to the (real) remote instance of the IP and service.
Note: You will need to take some additional steps to forward ports between 1 and 1023 as non-root users can't bind to those ports. - Personally, I just run the ssh client doing the forwarding as root. There are multiple other techniques that can accomplish the same thing.
Note: This technique will not work as desired if the remote IP is on the local subnet.