Reverse Proxy and SSH Tunneling
Explanation
Proxying a wiki that runs on a machine with no public address takes a second hop: a reverse SSH tunnel to a server that has one. The tunnel is opened by the local machine, outwards, which is what makes the arrangement work behind a firewall that allows no incoming connection and without a fixed public IP address:
ssh -R 8080:127.0.0.1:8080 serverThe port the tunnel opens on the remote server is bound to that server's loopback interface, not to its public one, so nothing reaches the wiki through it from outside. Publishing it is the reverse proxy's job, and the proxy is configured as it is on any other host, following Configure NginX Server as a Proxy on a Linux OS with proxy_pass naming the tunnelled port: to XWiki the request arrives from the proxy, exactly as it would if the wiki ran on the same machine.
This is a development and temporary-deployment arrangement. Every request crosses an SSH connection that nothing restarts on its own, so a permanent wiki is better served from a host that carries it directly.
FAQ
How do I check that the remote port is free?
Run ssh server curl -sS http://127.0.0.1:8080/ before opening the tunnel: Connection refused means the port is free, and any other answer means a service is already listening on it.
What if another service is already using that port?
Stop that service, or open the tunnel on a free port instead, for example ssh -R 9090:127.0.0.1:8080 server, and point proxy_pass at http://127.0.0.1:9090.
What keeps the tunnel up?
Nothing on its own: the tunnel dies with the SSH session. Run it under a supervisor such as autossh or a systemd service, and set ServerAliveInterval so that a connection lost silently is noticed and reopened.
