I’ve spent too many hours googling this stuff without a solution in sight that I’m able to understand.
I am moderately new to selfhosting, especially the networking aspect. To put it simply, all I want is to be able to access my services through Tailscale by using subdomain.mydomain.com.
I have gotten so far to point my domain to my Tailscale IP (using Cloudflare’s DNS), so that I don’t have to copy paste the Tailscale IP, but that means I still have to type in the ports to the services. Between the posts saying Tailscale can handle this, to the ones saying Synology can do it, and the remaining posts saying to use a reverse proxy (and the ones saying reverse proxy are a bad idea because of Synology stuff) I am now very lost. The terminology is exhausting and everyone is already so knowledgeable that they skip the basic steps and go straight to complex, short answers.
I’d like to keep using Tailscale, as I don’t want to deal with security issues and SSL certificates and all that, and if possible I’d like to avoid using a reverse proxy such as npm or Caddy if there’s a built in Tailscale/Synology solution that works.
To me more services just means more stuff that can break, and I really just want this stuff to work without fiddling with it.
Thanks for any help you can provide
Wow the responses here are really off at the moment. I’m going to try and help.
So, what you’re going to want to do is add all the subdomain A records you need to you DNS (sounds like you’re using cloudflare for that, not required, but that should be fine).
Those DNS records are all going to be the same IP record, that’s fine.
What you need to do after that, so that you don’t have to enter ports is a bit more complicated. For web servers, some kind of reverse proxy like nginx, haproxy, apache, etc is what you need. The term you’re looking for is “virtual host”.
A virtual host setup is basically one where a reverse proxy looks at the domain name that was used to access the server over HTTP and then uses that to decide what server running on the machine you actually talk to.
It’s HTTP that actually is passing along the domain name you used, so if the service isn’t HTTP you may or may not be able to do anything depending on the underlying protocol.
So to recap:
- Set up your DNS records
- Set up an HTTP reverse proxy
- Add virtual hosts for each service you added a DNS record for to the reverse proxy (so that the reverse proxy can turn foo.example.com into example.com:xyz – localhost:xyz in practice, morally example.com:xyz though – behind the scenes)
If they’re all resolving to the same IP and using a reverse proxy for name-based routing, there’s no need for multiple A records. A single wildcard should suffice.
I’ve never used wildcard DNS, I’m not even sure that Namecheap DNS supports wildcard. But I’ve also never been in a situation where there’s a dominate single machine I want my DNS to resolve to.
After searching … I’m not entirely sure I would use wildcard DNS https://serverfault.com/a/483625
My preferred strategy is actually alias records and then one primary address record the alias records point to so if I change IPs I can move the machine. I forgot about that last night.
I don’t think I’ve ever come across a DNS provider that blocks wildcards.
I’ve been using wildcard DNS and certificates to accompany them both at home and professional in large scale services (think hundreds to thousands of applications) for many years without an issue.
The problem described in that forum is real (and in fact is pretty much how the recent attack on Fritz!Box users works) but in practice I’ve never seen it being an issue in a service VM or container. A very easy way to avoid it completely is to just not declare your host domain the same as the one in DNS.
Interesting; well it’s good info/good to know it exist … though, I’m probably going to stick to explicit listing. I like to be able to look at my DNS records and know what connects to what.
If you are only accessing the services while connected to tailscale using the tailscale admin console you can add a nameserver, and then point that to a local DNS resolver. The local resolver can point the URL you want to the IP with the ports you want. I don’t know if Synology has DNS resolving apps but that might be an option, otherwise you could run pihole or something similar to achieve this.
So here’s my two cents:
I think that if you have a bunch of services, then you should use caddy or Apache or nginx. doing this in caddy and Apache is not that difficult, but I understand the hesitation (I don’t have much experience with nginx)
If you just want to get something working you could do bookmarks with the http://host.whatever.com:port and that would be Gucci.
You could also use another registrar or name server besides Cloudflare to make URL redirect records. This is like an A record but it also includes a port. This is not a standard type of record, but some places will do it like Namecheap.
Again, if you want to do it the right and best way, then I do think a reverse proxy is the way to go.
Tailscale has a feature which assigns you a random network subdomain off ts.net. You can use it to find any system by name. But also you don’t need it. You can usually just access the services via the host name if your client is attached to tailscale and also has open ACLs for the services you are accessing. as far as i know there is no way to do what you are trying to do and I’m not sure why you are trying to do it. if you are trying to make a service public you probably want to use something like cloudflared instead.
If your goal is to expose a web server to the internet I recommend you use cloudflare zero trust and create a tunnel. This would solve any ssl certificate issues and would also get rid of the need to use any kind of reverse proxy as cloudflare would be acting as a reverse proxy. There are other options of course but this is the simplest for web based services.
If your goal is to simply be able to reach the NAS remotely over the internet you don’t need to open ports or use reverse proxies. You can simply access it internally via the tailscale grid just as if it were local to you like on a LAN. As long as your client is on the same tailscale net as the NAS and has open ACLs this will work fine. It’s sort of unclear to me as to what your actual goal is.
Another option again assuming your goal is to access the synology NAS via the public internet. You could use synology built in quick connect service and that would get it done.
If at some point you find a way to articulate your actual goal let me know and I may have a better option for you.
Thanks for the answers. I guess that was not clear from my post, but I do not want to expose anything to the internet. All I want to do is tidy up the urls to the services for clarity. I have no issue with installing Tailscale on every device I want to access my services with. I can currently access any service just fine by doing “tailscaleIP:PortOfService”, but that is kind of unpractical. So by using my domain and Cloudflare DNS I changed it to “mydomain.com:PortOfService” which is already better, but means I have to look up what port the service I need uses. Like I said in my post I’d ideally like “nameOfService.mydomain.com”, no ports. And yes I realize this is purely for convenience/aesthetic reasons. Apologies if my words are not clear enough.
Ok so I guess what I’m confused about then is why you didn’t use Tailscale MagicDNS which is already integrated and used for this purpose.
In a similar vein you may also find this helpful:
You can’t reach a Tailscale device from the internet the way you’re trying because their IPs are from private ranges reserved for CGNAT use. They’re not routable on public internet.
What you want is called Tailscale Funnel but it uses their domain (.ts.net) not yours.
You can also try using a CloudFlare Tunnel but they force you to host your DNS server with them.
Both Tailscale and Cloudflare will be decrypting and re-encrypting your HTTPS traffic so please note that.
deleted by creator
deleted by creator
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CGNAT Carrier-Grade NAT DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol NAS Network-Attached Storage NAT Network Address Translation SSL Secure Sockets Layer, for transparent encryption nginx Popular HTTP server
7 acronyms in this thread; the most compressed thread commented on today has 12 acronyms.
[Thread #704 for this sub, first seen 22nd Apr 2024, 18:35] [FAQ] [Full list] [Contact] [Source code]
