#Host publicly accessible web URLs from a home server using a remote proxy
Ideally, you would be able to open ports 80 and 443 of your public IP address and update DNS entries with solutions like ddclient or DNS-O-Matic.
However, if your ISP blocks direct traffic to those ports, its possible to use a remote server and SSH tunneling to bypass that limitation. With this setup, you can use Kubernetes ingresses normally. From the ingress’ perspective, http traffic will reach your home server directly. Therefore, tooling like Nginx and Cert Manager will work with no special tweaks.
Any Linux box with a public IP can be your remote proxy, but Oracle Cloud has a generous free tier and can be a good starting option. Just remember that the smallest available machine is probably enough for your needs since it will only forward traffic and not really act on it.
After setting up the remote server with your provider of choice, ensure that it has a SSH server running. We’re going to use it to forward network packets for us.
On your remote instance, edit the /etc/ssh/sshd_config file and add GatewayPorts yes to it. Apply the new configuration with service sshd restart.
If you opted for an Oracle Cloud server, go to the Ingress Rules section of the Virtual Cloud Network panel and open ports 80 and 443. Also, adjust iptables in the instance to allow public traffic to ports 80 and 443.
iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT
netfilter-persistent saveFrom your home server, you can run a quick test, as long as you already have a HTTP server running locally. Don’t forget to generate a new SSH key for your local server and authorize it on the remote machine. If everything until now went smoothly, you will be able to access a local web endpoint using the remote server IP as the DNS entry for your domain.
ssh -N -R 80:<local_ip>:80 root@<remote_ip>If the port forwarding worked, you can create deployment files for it so Kubernetes itself can maintain the connection up and running for you. Customize and apply the following to your local cluster.
apiVersion: v1
kind: Namespace
metadata:
name: proxy-router
--
apiVersion: apps/v1
kind: Deployment
metadata:
name: autossh-80
namespace: proxy-router
labels:
app: autossh-80
spec:
replicas: 1
strategy:
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
type: RollingUpdate
selector:
matchLabels:
app: autossh-80
template:
metadata:
labels:
app: autossh-80
spec:
containers:
- name: autossh-80
image: jnovack/autossh:2.0.1
env:
- name: SSH_REMOTE_USER
value: "root"
- name: SSH_REMOTE_HOST
value: "<remote_server_ip>"
- name: SSH_REMOTE_PORT
value: "22"
- name: SSH_TUNNEL_PORT
value: "80"
- name: SSH_BIND_IP
value: "0.0.0.0"
- name: SSH_TARGET_HOST
value: "<local_server_ip>"
- name: SSH_TARGET_PORT
value: "80"
- name: SSH_MODE
value: "-R"
volumeMounts:
- name: keys
mountPath: /id_rsa
nodeName: <node_with_ingress_enabled>
hostNetwork: true
volumes:
- name: keys
hostPath:
path: <node_path_for_ssh_keys>
type: FileTo redirect port 443 as well, create another deployment using the previous one as a reference.
Any public URLs should, of course, have their DNS entries pointing to the remote server’s IP.
