We use Tailscale because we work for so many companies and each company has their own way of allowing their employees to connect to their infrastructure. We use Tailscale primarily for this purpose. For example, if there are Kubernetes clusters and engineers need to connect to the cluster to run their local applications against it, they connect using Tailscale. Additionally, we sometimes establish connections between on-premises and cloud environments. The first case involves ensuring that clients' employees have access to resources such as Kubernetes clusters, and the second case involves making connections between on-premises and cloud infrastructure, which makes it easier to connect.
Let me give you a quick simple example of how I've used Tailscale for one of my clients. One of our clients wanted their engineers to be able to connect to the cluster internally instead of going through the public internet. We introduced them to Tailscale and set up the tailnet in Tailscale. The tailnet in Tailscale enabled us to install a Tailscale operator on each cluster. For instance, if our client has ten clusters, we install the Tailscale operator to expose the subnet router of each environment to the tailnet. Users can connect to the tailnet, and since the subnet router is already exposed to the tailnet, they can have access to their clusters through the subnet routers that are already exposed to the tailnet. This is how they can connect to the Kubernetes cluster. The reason is because we don't want users to connect through the public internet, and in the setup of the Kubernetes cluster, we only allowed one or two specific VPN connections. The only way we can allow employees to connect is through the tailnet. We installed a Tailscale subnet router on each cluster, which exposed the cluster VPC and networks in the tailnet. When employees connect to the tailnet, since the subnet router is already exposed to the tailnet, they can connect through the tailnet.
There is another scenario where clients are trying to access their on-premises data to the cloud. Instead of using a cloud VPN, which would be a headache and could cost a lot, we decided to use Headscale. Headscale is similar to Tailscale because Tailscale is the enterprise version while Headscale is the open source alternative. We set up Tailscale for them on-premises and on the cloud. We set up a Tailscale tailnet on the cloud, and we set up a subnet router on-premises and another subnet router on the cloud. Both subnet routers will connect to the tailnet on the cloud and expose their VPCs. The one on the cloud will expose its VPC to the tailnet and the one on-premises will expose its VPCs to the tailnet. Machines on-premises can connect to machines on the cloud through the tailnet connection. The machine in the tailnet that is on-premises serves as a subnet router, and the one on the cloud also serves as a subnet router that routes traffic from the cloud to the tailnet, while the one on-premises serves as a subnet router that routes traffic from the on-premises to the tailnet.
When a connection needs to be established, for example from the cloud to the on-premises, we create a routing policy that says if you want to talk to a specific IP which is on on-premises, go through the subnet router. The same thing applies with the on-premises as well. If you want to talk to a specific IP on the cloud, go through the on-premises subnet router. This way, it connects to the tailnet which has exposure of the cloud IPs, and the connection is made.