Cleanup?

[uhthomas]

The GitHub Action seems to work great, thank you!

The machines on my Tailscale account are quickly filling with GitHub actions runs. Is there any way to automatically delete them after the run, or separate them from the machines I actually care about?

[uhthomas]

@astrophena Was this feature released today? I am certain this was not here before.

Either way, thank you! This is perfect.

How does the tagging stuff work by the way?

[astrophena]

@astrophena Was this feature released today? I am certain this was not here before.

Either way, thank you! This is perfect.

How does the tagging stuff work by the way?

Sorry, I accidentially deleted my comment :cry:

But I tested this and it doesn't work. Probably because GitHub Actions doesn't support IPv6.

But before ephemeral keys I used this script:

#!/usr/bin/env bash

set -euo pipefail

apiurl="https://api.tailscale.com/api/v2"
domain="astrophena.name" # replace to your domain
hostname="github-$(cat /etc/hostname)"
apikey="${TAILSCALE_API_KEY:-}"

# fetch device ID
id="$(curl -s -S -u "$apikey:" "$apiurl/tailnet/$domain/devices" |
        jq --raw-output '.devices | .[] | select(.hostname=="'$hostname"\") | .id")"

# delete device
curl -s -S -X DELETE -u "$apikey:" "$apiurl/device/$id"

In workflow:

      - name: Disconnect from Tailscale
        if: ${{ always() }}
        env:
          TAILSCALE_API_KEY: ${{ secrets.TAILSCALE_API_KEY }}
        run: server/ci/tailscale-cleanup

[uhthomas]

😔

[tendstofortytwo]

I'm able to use the Action in my workflow by connecting over the IPv6 address of the other machine directly, rather than using MagicDNS resolution. In Tailscale 1.8+, this IP lookup can be automated with the tailscale ip command.

So curl $hostname becomes curl $(tailscale ip -6 $hostname).

[DentonGentry]

I think this issue was resolved by using ephemeral keys.

[uhthomas]

Sorry @DentonGentry this isn't quite resolved. Ephemeral keys are the solution but GitHub actions does not support IPv6 and so they cannot be used. As such, I still have hundreds of random GitHub runners in my TailScale device list. It's pretty annoying :/

Could we reopen this until it's fixed?

[uhthomas]

@astrophena Thanks for your script! I'll try using it and see if it helps in the meantime :)

[DentonGentry]

Ephemeral keys allocate an IPv6 address in the Tailscale overlay, so an IPv6 packet is constructed to hold whatever TCP/HTTP/etc data your code generates. Wireguard then encrypts that IPv6 packet into a binary blob, puts a wireguard header in front of it, and puts it into a packet to send to the destination wireguard node. In particular: the packet it constructs can be IPv4 or IPv6. The binary blob of data is just a binary blob. It doesn't require IPv6 support in the GitHub Runner, it just requires IP connectivity.

An IPv4 underlay network in GitHub's datacenter can carry IPv6 frames inside Wireguard tunnels.

I'm recommending ephemeral keys because they do work. We use them in GitHub runners every day. If they are not working for you, I can help debug why.

The most common issue is attempting to connect to a remote Tailscale node's IPv4 address, "curl http://100.x.y.z" for example. You'd need to connect to its Tailscale IPv6 address, which can be looked up using tailscale ip -6 hostname

[uhthomas]

I see, thank you for clarifying that point. I'm conecting to a Kubernetes cluster, the tailscale domain name for said cluster is in the kube config and so it's not possible to use tailscale ip -6 unfortunately. Are there any alternatives which force tailscale to always use IPv6 or something?

[uhthomas]

For anyone stumbling across this, it's possible to enforce IPv6 for the entire tailnet by amending the ACL such:

{
    "disableIPv4": true,
}

https://tailscale.com/kb/1018/acls/#network-policy-options

Disabling IPv4 will force MagicDNS lookups to return IPv6 addresses.

[DentonGentry]

While that is true, I don't think it is useful to use disableIPv4 at this point for the purpose of running this GitHub Action. When first released ephemeral nodes were only given an IPv6 address, but we changed that almost a year ago and now allocate both IPv4 and IPv6 for ephemeral nodes. GitHub Actions runners should be getting IPv4 addresses now.

Additionally, when first introduced the ephemeral node would be deleted about 48 hours after it dropped out of contact with the coordination server. Now the ephemeral node is deleted immediately if it shuts down cleanly, or after one hour if it just abruptly drops out of contact.

[uhthomas]

Thanks for the updated info @DentonGentry 😄 Really happy to see IPv4 support for ephemeral nodes.