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?
13 Comments
markjamestwn1301@scribe.disroot.org · 5 pts · 17h
Genuine question from someone equally amateurish. What use is reverse proxy in this setup? What necessitated it instead of just a direct connection?
JacksStuff@lemmy.world · 7 pts · 17h
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
Quazatron@lemmy.world · 4 pts · 17h
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.
Joker_1902@lemmy.ml · 2 pts · 16h
I have the same setup, it’s perfect.
impersonator@lemmy.ml · 3 pts · 17h
How would having a separate reverse proxy per VM help you with this?
JacksStuff@lemmy.world · 2 pts · 17h
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
impersonator@lemmy.ml · 1 pts · 15h
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.
toebert@piefed.social · 1 pts · 16h
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.
stratself@lemdro.id · 1 pts · 12h
ssh and samba aren't meant to be reverse proxied. just use a dedicated port, ip, and dns entry for them, and the rest wildcarded back to traefik.
if you insist you need to route it through a "central machine", either look into layer-4 reverse proxying (e.g. traefik's tcp routers, nginx stream module, rinetd) or port forwarding from traefik.srv.lan to nas.srv.lan and so on. you can even use something like sslh to multiplex samba, ssh, and http on the same port 443. but generally these are not gonna be needed
non_burglar@lemmy.world · 2 pts · 11h
You're right about samba, it uses broadcast first to announce. But ssh should be fine.
ohshit604@lemmy.halstead.host · 1 pts · 7h
As another person mentioned, you typically wouldn’t reverse proxy SMB or SSH, you’re more likely to use SRV records for these services opposed to A records.
jet@hackertalks.com · -2 pts · 16h
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.
makeshift0546@lemmy.today · -3 pts · 15h
Just have a clanker fix it for you. I haven’t had to touch configurations for over a year now.