Reverse Proxy Http Configuration
Add an nginx config file at /etc/nginx/sites-available/<SERVERNAME>.conf
To do this use the command
cd /etc/nginx/
nano sites-available/<NETNAME>.conf
Ours looks like:
cd /etc/nginx/
nano sites-available/servpub.conf
Choosing your NGINX reverse proxy setup is very much up to you but we will show two setups, a simple one with just http, and a more secure and standard one with https redirect and certificate.
Simple http conf for listening for traffic on port 80:
server {
# listen to http on port 80
listen 80;
listen [::]:80;
# listen to url: REPLACE domainname.com with YOUR DOMAIN NAME
server_name domainname.com;
# linking the client to the vpn subnet ip address of the pi
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# replace this with the user vpn subnet ip adress you set earlier
proxy_pass http://10.10.12.51;
proxy_read_timeout 90;
}
location / {
rewrite ^ https://$host$request_uri? permanent;
}
}
Reverse Proxy Https Configuration
Depending on where or how you are hosting your server, in order for it to work with https you will need to add in rules for handling secure ssl requests on port 443. You will need to contact your hosting provider to understand how your ssl certificates are handled or you can skip to 04.2 Managing certificates for https if you need to manage certificates yourself. You can then proceed with configuring the routing for https traffic as seen below.
Example of a config with https, http redirect, and certificate:
# A server to derirect http traffic to https
server {
# listen on port 80 (http) of servpub.net
listen 80;
listen [::]:80;
# listen to servpub, change to your url
server_name servpub.net;
# send trafic to https of the url
return 301 https://servpub.net$request_uri;
}
server{
# SSL configuration, listen to https of port 443
listen 443 ssl;
listen [::]:443 ssl;
# link to ssl certificate on vpn server
ssl_certificate /etc/letsencrypt/live/servpub.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/servpub.net/privkey.pem;
# link to root folder
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
# listen to url: REPLACE domainname.com with YOUR DOMAIN NAME
server_name domainname.com;
# linking the client to the vpn subnet ip address of the pi
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# replace this with the user vpn subnet ip adress you set earlier
proxy_pass http://10.10.12.53;
proxy_read_timeout 90;
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}
Debugging Routing issues
Depending on your use case for the reverse proxy we include some separate information about changes we made to the reverse proxy configuration to better handle traffic to the raspberry pi servers in the VPN.
We had an issue passing on requests to the servers in the VPN if the url / route was not pointing at the root, i.e. most of the requests!
The try_files directive was causing the issue for us because it could not find any resources (or file) on the Jean server at those routes, and instead served up a 404 for most of the client requests. We changed the location / route to use a named location @proxy to handle the requests, read more about trying several options here.
The change we made:
location @proxy {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://10.10.12.4;
proxy_read_timeout 90;
}
location / {
# Instead of serving up a 404 error pass all of the route on
try_files $uri @proxy;
}
Note on Debugging
We include here a story of debugging to share a tactic around investigating issues and knowledge sharing between and within collectives. Within both Systerserver and In-grid we aim to share technical knowledge during different processes of making, setting up and/or maintaining. Within Systerserver sharing technical findings on sysadmin mailing lists is one way that this is practiced. Within In-grid the act of making docs or explaining discoveries is one way that this is practiced. We share here the process of debugging and an excerpt of an email sent to the Systerserver sysadmin mailing list by someone from In-grid.
By looking at the nginx access and error logs we were able to analyse what the issue was. You should be able to find information about errors and traffic here: /var/log/nginx/access.log /var/log/nginx/error.log
Email excerpt:
If you go to wiki4print.servpub.net, the request access log on Jean will show:
[15/Dec/2023:14:49:40 +0100] “GET / HTTP/1.1” 301 5
Request gets immediately passed to wiki4print pi: 10.10.12.2 - - [15/Dec/2023:13:49:40 +0000] “GET / HTTP/1.0” 301 0
The 301 is showing that the php is doing what is expected by redirecting to the “/index.php?title=Main_Page” location, we then see this immediately in Jean access log:
[15/Dec/2023:14:49:40 +0100] “GET /index.php?title=Main_Page HTTP/1.1” 404 188
That request gives the 404 so it does not get passed to wiki4print (no record in nginx error or access log on wiki4print).
Through this analysis, and then the use of forum posts and Nginx documentation we were able to discover a solution to the problem with the try_files directive and then share that information amongst members of the collectives.