I managed to get my home lab self-hosted using DuckDNS and Traefik, and I’m having issues trying to do the same with deSEC…I got the main page up, mafmanhomelab.dedyn.io, but I also have a Glances instance that I want to run on glances.mafmanhomelab.dedyn.io, which currently returns a 404 because I don’t know how to set it up. How do I set up nested subdomains like that?
Specifically, I want one Glances instance running on the laptop I’m posting from, which is configured as a backup server, as glances-laptop.mafmanhomelab.dedyn.io, and another Glances instance on the Raspberry Pi that actually runs the Traefik reverse proxy, as glances-pi.mafmanhomelab.dedyn.io.
If you’re getting a 404 error, you’re connecting to something, so either you’re not connecting to the server that you intend to connect to or the server isn’t configured correctly. Subdomains can have their own A/AAAA records or point to the same addresses as the Domain through CNAME records. It all very much depends on what you want to do.
2 Likes
I’m basically trying to configure things so that the Raspberry Pi is the only thing exposed to the internet, and it runs the reverse proxy that directs traffic to the laptop whenever I try to visit something hosted on the laptop. Maybe what’s happening is I’m trying to access something on the laptop and the Raspberry Pi thinks that it’s the only thing on the network so it searches for a subdomain that doesn’t exist.
In that case, point the subdomains at the same address by setting CNAME records for them that point at your main domain. This way you only need to update the main domain if your address changes. All connections go to the same address, and with the reverse proxy you don’t need any port numbers to tell the services apart, just the different domain names. If your domain is configured that way, the reverse proxy is where you need to fan out to the server instances, so that’s where you also need to look if connections arrive as expected and how they’re handled. The reverse proxy needs a mapping of external domain names to actual services, i.e. IP addresses or internal domain names and possibly port numbers.
One possible complication is when the target server is itself doing name based virtual hosting and the domain name configured for the service isn’t the external domain. In the typical configuration, reverse proxies do not change the host name in the forwarded requests, which leads to the target service not knowing what to do with the request, but this can be worked around on the reverse proxy or on the target server.
3 Likes
Since I’m new to using this kind of interface and managing DNS records in general, how would I go about adding those CNAME records? Clicking the + icon on the interface and setting the record set type to CNAME, what would go into the subname and target domain name fields?
With the names you mentioned in your first comment, make glances the subname (if you leave this empty, the record is for the zone apex, which is your mafmanhomelab dedyn domain). The target is your full mafmanhomelab dedyn domain, with a dot at the end, so mafmanhomelab.dedyn.io.This tells the resolver that anyone looking for glances.mafmanhomelab.dedyn.io should really look at mafmanhomelab.dedyn.io. There the client will find the A or AAAA record you put there with your dynamic DNS client.
Add more records for other subnames as you need, or alternatively use the subname * to set the CNAME for all possible subdomains. This is the so-called wildcard name. Then you just need to add another domain name to the list of services accessible through your reverse proxy if you need it. The DNS is already there.
2 Likes
I get it! I almost have it working. I think the challenge now is the fact that my router points 80 and 443 only to the Raspberry Pi and not to the laptop. I would need a way for the request for the laptop instance of Glances to hit the Pi which would then forward it to the laptop.
I have glances-pi working, and I want to add glances-laptop.
So currently I have one instance of glances running on the laptop, and one instance running on the raspberry pi, and even though the two are both in a Docker network called proxy, they’re on separate devices so the two identically named networks are still logically two different networks.
With the reverse proxy, all connections go to that. The proxy then looks at the domain in the host header and forwards the requests to the respective web servers on the same or other hosts according to the proxy configuration. It forwards the responses it gets from the servers back to the client. The client only ever talks to the proxy, not the servers directly. If you need port forwards because the proxy only has an internal IP address, then the port forward must go to the proxy, not any of the servers, because the client does not talk directly to the servers.
This is called name based virtual hosting. Multiple domains are hosted on the same IP address and port. The client indicates what domain/host it wants to talk to in the request. The proxy makes an internal connection to the host it has configured for that domain name and shuttles requests and responses back and forth.
2 Likes
I just realized what I’ve been probably forgetting this entire time is I don’t think I’ve even set up a proper configuration file for the reverse proxy, just relying on internal Docker labels. That’ll do it!