Custom/change IP address

[cg31]

Headscale is assigning IPs to machines in registering order as x.x.x.1 ... x.x.x.2 ... x.x.x.N.

Is it possible to add a command to assign/change the IP associated with a machine?

The reason is when using script to do automatic job, we can simply use fixed IPs directly.

[cg31]

Someone already mentioned it in #983 (comment)

[san3Xian]

+1 ,now I can only specify the ip of the machine by modifying the ip_addresses column in the machines table via sqlite3 db.sqlite, which is a poor experience.

[rjmalagon]

+1 ,now I can only specify the ip of the machine by modifying the ip_addresses column in the machines table via sqlite3 db.sqlite, which is a poor experience.
Thanks for the tip.
It works enough, although not user-friendly.

[gbraad]

On the headscale coordination server

$ sqlite3 /var/lib/headscale/db.sqlite
SELECT id, hostname, ip_addresses FROM machines;
UPDATE machines SET ip_addresses = "100.64.0.3" WHERE id=3;

On the tailscale client

$ tailscale down
$ tailscale up

[rjmalagon]

Im my case, I used a more blunt approach to replace my custom tailnet IPV6 range to the standard one.
SELECT ip_addresses FROM machines;
UPDATE machines SET ip_addresses = replace( ip_addresses, 'fdad:1cd0:8088', 'fd7a:115c:a1e0') ;

[kradalby]

While this was closed with a standardised message, I do not believe we will accept this feature for the time being, it does require more thought than it might seem on the surface and we are currently not willing to open this can of worms.

People can as mentioned use DB modification if needed, but you should rather base your network of not depending on the assigned IPs.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[aapeliv]

For anyone trying to backfill IPv6 addresses still on v0.22.3, this works:

update machines set ip_addresses = '100.64.0.1,fd7a:115c:a1e0::1' where ip_addresses = '100.64.0.1';

[surepy]

newer versions changed the table schema so it's now

update nodes set ipv4 = 'desired-ipv4' where ipv4 = 'current-ipv4';

for ipv4

update nodes set ipv6 = 'desired-ipv6' where (...);

[ArcticLampyrid]

you should rather base your network of not depending on the assigned IPs.

DNS is not always reliable. In my opinion, manually providing a custom IP for infrastructure will be beneficial for maintenance work.

[Geofferey]

I know the issue is closed, however if you still Google, you'll probably land here.

Here's a quick script to assist those with changing IPs of nodes in headscale v0.23.0.

If you're like me and not SNATing or OCD I hope you'll appreciate this.

https://gist.github.com/Geofferey/e3c49d195a01229e61b878f4530bd052

wget https://gist.githubusercontent.com/Geofferey/e3c49d195a01229e61b878f4530bd052/raw/d0711e21ba645798aa438228725f3a884686ff3a/hschip.sh

sudo cp hschip.sh /usr/bin/hschip

sudo chmod +x /usr/bin/hschip

sudo hschip nodname 100.64.0.2

You'll need sudo apt-get install sqlite3 ofc

The script has several sanity checks to determine if you're on headscale version v0.23.0, the node exist, IP is valid + tailscale CIDR: 100.64.0.0/10 and that the IP is not actively being used by another node... Sorry, no v6 support 😭😭😭

I couldn't have engineers screwing with the DB by hand and there may be a requirement to ensure the IP is controlled since we are full routing across non tailscale nets. We are not using v6 support in our env so I wasn't gonna go the extra mile.

[TheWebMachine]

Here's a quick script to assist those with changing IPs of nodes in headscale v0.23.0.

Perfect timing! I just setup headscale for the first time tonight and wanted to move my exit node to .1!

This worked perfectly. Thank you!

[ngaro]

Seeing that all PR's with code to implement this feature contain comments really similar to the "I do not believe we will accept this feature for the time being, it does require more thought than it might seem on the surface and we are currently not willing to open this can of worms." I assume that changing IP's will cause unexpected/buggy behavior that we are missing...

For now the only things I can think off are these things:
(Note that this is just what I expect can happen, I didn't examine the inner working of Headscale and Tailscale enough to be sure)

• Headscale will need to restart and during that time new connections will not be possible between systems that didn't change IP's and didn't communicate for a while (I assume the Tailscale client caches info it receives).
  This shouldn't be a large issue and should just feel like laggy behavior for a few seconds
• The system with the changed IP will not be accessible until it's tailscale client is restarted (or maybe until it's cache expires if it also caches info about itself)
• Other systems cannot connect to the system with the new IP until they restart their tailscale client (or until their cache expires)

Is this behavior that you noticed and are there also other problems ?

[Oni]

(Sorry for joining the discussion late)

People can as mentioned use DB modification if needed, but you should rather base your network of not depending on the assigned IPs.

You need fixed IPS if the DNS server is hosted inside the tailnet, headscale requires a fixed ip in (of course):

dns:
  # List of DNS servers to expose to clients.
  nameservers:
    global:
      - <tailscale machine here>

What about an approach similar to DHCP servers? You basically reserve ips to certain nodes.

dhcp:
  foo.node.myhs.net:
    ipv4:
      - <ip here in headscale range>

After headscale reboots, when a node tries to connect, the server checks if it has a reserved ip. If not, it assigns a non-reserved ip.

This approach would cut down the complexity of dealing with ip changes, but would still provide the advantage of controlling ips of nodes.