Reverse proxies are helpful in that they
I've got the Pangolin proxy+tunnel service running "on the internet" on a VPS with a public IP. I could stop there and things would "work" just fine. It provides IAM, per-user service policies, and a reverse proxy via Newt (a userspace WireGaurd tunnel client running on my LAN).
There's a slight disadvantage to this, though, in cases where I am currently connected to the homelab LAN.
Assume I'm on my laptop, at home, and I type in myservice.rileys.house in my browser. My DNS client will resolve *.rileys.house to the public IP of my Pangolin VPS. My client will be routed out of the LAN to that VPS. Pangolin would then (after authenticating my user) route this myservice. traffic to whatever internal service I've mapped to it via the Newt tunnel.
This means that, despite my client and service both being located on the same LAN, the traffic must go out and back again to a VPS in Sydney.
This "Trombone-shaped" traffic is acceptable for low-bandwidth applications such as this Wiki, but can be annoying or problematic for high-bandwidth ones like media streams (e.g. Jellyfin, Frigate) or latency-critical ones like game servers (Crafty Controller)
One solution to the above is to leverage local DNS records to "short-circuit" requests to a local Proxy which mirrors the remote Pangolin one.
I've set up custom dnsmasq rules in my local DNS server (PiHole) via its misc.dnsmasq_lines option. At the moment, I've set up only one such "capture" setting for Frigate which looks like the following:
address=/frigate.rileys.house/192.168.0.12
This will route any requests to frigate.rileys.house to 192.168.0.12, which is currently my local Nginx Proxy Manager reverse proxy service instance address.
While this could easily be achieved with a more-traditional "Local DNS" A-record, I've done this to set myself up for future plans.
This has been implemented! See burrowd
The below is retained for posterity and context.
Prior to moving to a publicly-hosted reverse proxy, I was using Nginx Proxy Manager as my only reverse proxy. It worked well for local-only access. I was previously using homelab.rileywaite.com as a base domain for these services, and had a dnsmasq rule like above which would capture all requests to it or any of its subdomains to the NPM instance.
This is the reason for using a dnsmasq entry instead of a Local DNS record --- the custom entry allows wildcard captures. URLs like frigate.homelab.rileywaite.com would resolve to the NPM instance just as well as anything.homelab.rileywaite.com or even just the base homelab.rileywaite.com.
Which leads to the future optimization:
I want to set up a proxy on the LAN which mirrors the Traefik proxy running on the remote Pangolin service and use a
rileys.housednsmasqentry to redirect to this local mirror to avoid Trombone routing for all services
The one-off frigate entry example above works well, but required me to manually copy the LetsEncrypt TLS certificates from my Pangolin instance over to my local NPM one.
The steps I'd like to take to streamline this are:
*.rileys.house on the Pangolin instance using certbot with a Route53 plugindnsmasq entry to capture everythingFor the moment, it's sufficient to just add an A-record in PiHole for each service as-needed. As noted above, this is especially (maybe only) important for high-bandwidth (media streaming) or low-latency (game servers) applications.