I’ve started a homelab a few months ago, and since then it looked more or less like this:
- DNS server - with one wildcard record “*.srv.lan” pointing to my reverse proxy (I don’t have a proper domain yet)
- Proxy (traefik) - forwards the requests to specific services (nas.srv.lan -> NAS, photos.srv.lan -> Immich etc.)
An issue showed up when I got around to setting up samba, where because I have a single wildcard DNS record, and the proxy runs on http(s), I cant forward SMB requests to the server, other than using its ip. The same issue arose when I wanted to get dns-based ssh working (even though I have nas.srv.lan set up, ssh-ing that gets me onto the proxy instead of the nas, which makes sense with the dns setup)
One solution that came to my mind would be making each service (I’m using vms, so each service is a different host) have a separate reverse proxy, as well as making the DNS server have all the records separately (nas.srv.lan -> NAS ip, photos.srv.lan -> Immich ip etc.) and then perform the proxying on the hosts. That would lead to me having a dozen different reverse proxies, wasting resources and making managment more difficult.
Are there any other things I could try?
You must log in or register to comment.
You can have *.srv.lan point to your reverse proxy, and then just add something.srv.lan to point to somewhere else as well as another record. The exact record will overwrite the wildcard, but things would default to the wildcard.
Alternatively, your router’s DHCP server should make things accessible under a local domain, sometimes it’s just .lan, or .local, or .home. If it’s nice it’d set the DNS search to that by default so you may be able to just ping the hostname of a device without any domains. Using those, you could keep your wildcard for services behind your reverse proxy vs devices on your network using the hostnames.
You could also consider structuring your domains. E.g. $device.lan = the network interface. *.$device.lan = the reverse proxy on it.
I’m using Pi-hole for the DNS stuff and Nginx Proxy Manager for the proxying. Super easy to setup as docker containers, with lovely web GUIs for configuration. Works great.
I have the same setup, it’s perfect.
Genuine question from someone equally amateurish. What use is reverse proxy in this setup? What necessitated it instead of just a direct connection?
For me, it’s all boils down to not having to type the port number in the url + centralized ssl certs. Instead of having the users type, say, https://nas.srv.lan:1234/ into their browser I can just make the proxy forward https://nas.srv.lan/ to http://some-nas-ip:1234/. It saves me from having to configure ssl/https and port configs for each service on each host, and as long as I pretend my homelab network is secure (it’s not), using http internaly (between the proxy and service hosts), while keeping stuff encrypted externally (between the users and the proxy), is relatively ok and much easier to configure. I know that there’s more to it, load balancing etc but for me that’s it.
Hope I was of some help
How would having a separate reverse proxy per VM help you with this?
I could make it so that each host has a separate dns record. This would immediately fix the ssh issue, and the smb issue (probably), because the connections would go directly to the service host, instead of the external proxy (currently running ‘ssh user@nas.srv.lan’ connects me to the proxy instead of nas). I could keep the behaviour the same for the end user - they can still type https://nas.srv.lan/ and get the nas dashboard, if that makes sense. But, like i said, the issue is the resource consumption and having to manage multiple proxies at once
A central proxy adds a central point of failure.
However, if you give each service its own DNS entry, your proxy can look at the incoming DNS of the request, and use that to proxy to the service. At least for http services
I think it’d be much cleaner, to give each VM its own DNS entry, run the service on Port 80, or 443 so you don’t have to remember port numbers.
I’m not sure the reverse proxy is buying you much ease of use for a totally internal system. If you like, you can have a central web page, that links to all your different services from one location.
