Use the Tailscale Subnet Router feature to expose a private VPC based Hashilab
to the Tailscale network. This example will create a VPC in IBM Cloud with two subnets, one for the Tailscale subnet router and one for our services (Vault, Consul, Nomad). The subnet router will advertise the services subnet to the Tailscale network and allow us to connect to the services using the FQDNs we define in the private DNS zone.
Here is a hgh level overview of the solution: Not complete
- IBM Cloud API Key
- Tailscale API Key
- Tailscale Organization. This is the name of your Tailnet Organization not your Tailnet DNS name.
- Terraform installed locally
The first step is to clone the repository and configure the terraform variables.
git clone https://github.com/cloud-design-dev/ibmcloud-ts-router-hashilab.git
cd ibmcloud-ts-router-hashilab
Copy the example terraform variables file and update the values with your own.
cp tfvars-template terraform.tfvars
Name | Description | Type | Default | Required |
---|---|---|---|---|
allowed_ssh_ip | The IP address or CIDR block to allow SSH access from in to our Tailscale router instance. | string |
"0.0.0.0/0" |
no |
cluster_size | The number of worker nodes to create in the cluster. | number |
3 |
no |
existing_resource_group | The IBM Cloud resource group to assign to the provisioned resources. | string |
n/a | yes |
existing_ssh_key | The name of an existing SSH key to use for provisioning resources. If one is not provided, a new key will be generated. | string |
"" |
no |
ibmcloud_api_key | The IBM Cloud API key to use for provisioning resources | string |
n/a | yes |
ibmcloud_region | The IBM Cloud region to use for provisioning VPCs and other resources. | string |
n/a | yes |
private_dns_zone | Name of the private DNS zone to create for the VPCs | string |
"internal.lab" |
no |
project_prefix | The prefix to use for naming resources. If none is provided, a random string will be generated. | string |
"" |
no |
tailscale_api_key | The Tailscale API key | string |
n/a | yes |
tailscale_organization | The Tailscale tailnet Organization name. Can be found in the Tailscale admin console > Settings > General. | string |
n/a | yes |
Once you have the required variables set, you can initialize the terraform configuration and create a plan for the deployment.
terraform init
terraform plan -out=plan.out
If no errors are returned, you can apply the plan to create the VPCs, subnets, and compute instances.
terraform apply plan.out
When the provosion is complete, you should see the output of the plan, including the private IP addresses of the compute hosts, the advertised subnets, and our custom resolvers.
<under-construction.gif>
By default the subnet router will not advertise any of the subnets until they are approved in the Tailscale admin console. From the admin console, navigate to the Machines tab and click the subnet router instance name. On the machine details page you should see the subnets that are available to be advertised.
Under Approved click Edit
and select the subnets you want to advertise and click Save
.
Once the subnets are approved, you can start the Tailscale app on your local machine and set the local DNS resolvers to the custom resolvers that were created in the VPC. You can find the IP addresses of the custom resolvers in the terraform output. If you happen to be using a Mac, you can set the custom resolvers in the Network settings or via the command line with the networksetup
command:
networksetup -setdnsservers Ethernet 10.250.0.5 10.250.64.4
With the resolvers set, we can now start testing connectivity to our deployed services. Take one of the FQDNs from the terraform output and try to connect to it.
<under-construction.gif>
To remove the resources created by the terraform configuration, you can run the destroy
command.
terraform destroy
In this example we have deployed a Tailscale subnet router in an IBM Cloud VPC to expose private DNS services to our Tailscale network. We also created custom resolvers in the private DNS zone that allow us to connect to our private services using the FQDNs we have defined in the private DNS zone from our local machine.