This would be great if it supported wildcards for ingress controllers. A service foo would give you foo.tailYYYY.ts.net as well as *.foo.tailYYYY.ts.net.
But, what found particularly interesting on that page was the following:
>" Some especially cruel networks block UDP entirely
, or are otherwise so strict that they simply cannot be traversed using STUN and ICE. For those situations, Tailscale provides a network of so-called DERP (Designated Encrypted Relay for Packets) servers. These fill the same role as TURN servers in the ICE standard, except they use HTTPS streams and WireGuard keys instead of the obsolete TURN recommendations."
DERP seems like one interesting solution (there may be others!) to UDP blockages...
Yup, really in very simple terms they just give you a public-key discovery/exchange server for your wireguard connected devices. Really wouldn't be that hard to create from scratch, wireguard does the heavy lifting.
Would encourage anyone to go look at the wireguard source code, it's amazingly concise and easy to read.
But they do seem to contribute and open source a lot to the community which I am grateful for.
Very cool, I love Tailscale. I use it to connect together a VPS, desktop computer, phone, and a few laptops. My main use case is self-hosted Immich and Forgejo so this is great.
I recently found Tailscale when searching to control my home lab when traveling and have been amazed by how simple it is we can create a private network.
I normally am one to not recommend proprietary services, especially for homelab use but their solution is just so far above all of the alternatives in terms of usability that I make an exception here.
Even better: while some public WiFi spots block VPN authentication, Tailscale (if already connected while on a different network) will continue to send traffic.
You can't VPN out of the guest WiFi at my work (using personal device), but Tailscale, if connected while I'm at my house or via phone hotspot, will happily let me use my home devices as exit nodes. So I just leave it on all the time and only disconnect if there are issues (rare). I can use sketchy WiFi without really worrying about snooping, and for services that require me to use a US IP address... well, my house is definitely in the US and it's not going anywhere.
i like tailscale but i notice that i get more weird network blippy latency issues when using it. i used to always have my phone connected to my tailnet so i could use my dns, etc. but always occasionally something won’t load right and i have to refresh again couple of times.
It tended to happen a lot more when switching between wifi / cellular when leaving and entering buildings, etc.
I've found that using Tailscale on my Android phone became worlds more reliable (as far as the issues you've described) once I stopped using a custom DNS resolver on my Tailnet.
This sounds great, I think it's exactly what I was looking for recently for hosting arbitrary services on my tailnet. I figured out a workaround where i created a wildcard certificate and dns cname record pointing to my raspberry pi on my tailnet but this could be potentially simpler
I want to give every node in my kubernetes cluster a tailscale key to join the cluster via the cloud-config / userdata. But this key is enforced by tailscale to be short lived, so if the server is reset and it boots again from cloud-config it has the expired key and can't join the tailscale network again.
I wonder if that architecture screenshot's "MagicDNS" value is a nod to Pangolin, since they are currently working on a new Clients feature that should eventually replicate some of the core Tailscale functionality.
I'm happy to see this feature added. It's a feature that I didn't quite realize I was missing, but now that I see it described, I can understand exactly how I'll put it to use. Great work as always by the Tailscale team.
If I'm getting this right it's only highly available from a network layer perspective. However if one of your nodes is still responsive but the service that you exposed on it isn't responsive there's no way for Tailscale to know and it'll route the packet just the same? It's not doing health checks like a reverse proxy would I imagine.
Can someone help me understand what this is vs exposing my services via MagicDNS using the tailscale Kubernetes operator? Functionally it looks like a fair amount of overlap but this solution is generic outside of Kubernetes and more baked into tailscale itself? The operator solution obviously uses kube primitives to achieve a fair amount of the features discussed here.
Fascinating to watch Tailscale evolve from what was (at least in my mind) a consumer / home-lab / small-business client networking product into an enterprise server-networking product.
I understand the usefulness of the feature, but find their examples weird. Are people really exposing their company's databases and web hosts on their tailnet?
25 comments
[ 5.7 ms ] story [ 51.5 ms ] threadhttps://tailscale.com/blog/how-tailscale-works
Ah! OK, now I get it! :-)
But, what found particularly interesting on that page was the following:
>" Some especially cruel networks block UDP entirely
, or are otherwise so strict that they simply cannot be traversed using STUN and ICE. For those situations, Tailscale provides a network of so-called DERP (Designated Encrypted Relay for Packets) servers. These fill the same role as TURN servers in the ICE standard, except they use HTTPS streams and WireGuard keys instead of the obsolete TURN recommendations."
DERP seems like one interesting solution (there may be others!) to UDP blockages...
Would encourage anyone to go look at the wireguard source code, it's amazingly concise and easy to read.
But they do seem to contribute and open source a lot to the community which I am grateful for.
You can't VPN out of the guest WiFi at my work (using personal device), but Tailscale, if connected while I'm at my house or via phone hotspot, will happily let me use my home devices as exit nodes. So I just leave it on all the time and only disconnect if there are issues (rare). I can use sketchy WiFi without really worrying about snooping, and for services that require me to use a US IP address... well, my house is definitely in the US and it's not going anywhere.
It tended to happen a lot more when switching between wifi / cellular when leaving and entering buildings, etc.
Now I just don’t use it
Short lived tokens is not always an option
We use it for to allow us to connect in from the outside (and user to user access etc), but not for service to service connections.