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?
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
Okay, I see what you mean. I would keep a single reverse proxy, and use different dns records then if you really want to access samba for example by name and not IP. You could keep the wildcard DNS entry and create separate ones for non-http services, that go straight to their respective hosts.