Tailscale router fails on alpine 3.19.0, breaking MagicDNS #10540
Comments
|
Thank you for the detailed issue description. As a temporary workaround are you able to use nftables on your system? |
|
I built a tailscale container from I was able to reproduce the error that you saw in cases where the underlying host does not support nftables (GKE with Google COS nodes) On hosts that do support nftables (GKE with Ubuntu nodes), it seemed like tailscale was able to run in an My understanding of the
If that's correct, you might want to check whether your host supports nftables. There are some instructions here- I have personally always tested by running If my assumption about their change is correct, there is also nothing we can do from our side. I am not sure what we can do to upgrade our Some logs from within
/ # tailscale --version
1.55.157
track: unstable (dev); frequent updates and bugs are likely
tailscale commit: bac0df6-dirty
go version: go1.21.5
/ # iptables --version / # readlink -f /sbin/iptables / # iptables -t filter -L Chain FORWARD (policy ACCEPT) Chain OUTPUT (policy ACCEPT) Chain PREROUTING (0 references) Chain ts-forward (1 references) Chain ts-input (1 references) |
irbekrm
added
containers
needs-decision
waiting-for-info
L2 Few
|
I'm in a little bit over my head here 😅 but am working my way through this. In the meantime, for context, I'm running these containers on Fly.io. I'll send this issue their way to see if they've got input. |
Keen to hear what they say. I see this issue from earlier in the year where someone asks about nftables support https://community.fly.io/t/nftables-support/10259 Are you providing your own VM or using one of theirs (for context, I don't know much about Fly.io)? |
Both? :D (Again, slightly out of my depth here.) Fly uses Firecracker, so they're constructing VMs from our Docker images. The crew at Fly got back to me, and had this to say:
I haven't been successful yet, but I'll keep on keeping on. :) |
|
Yup, the approach Fly suggested is working! Our Dockerfiles now include this bit: # tailscale dependencies (nb: fly doesn't support nftables, so we gotta use iptables-legacy)
RUN apk add --no-cache ca-certificates iptables iptables-legacy
RUN rm /sbin/iptables && ln -s /sbin/iptables-legacy /sbin/iptables
RUN rm /sbin/ip6tables && ln -s /sbin/ip6tables-legacy /sbin/ip6tablesI don't have any idea what this means for this issue. :) @irbekrm, back to you? |
|
Hey @isaacbowen thank you very much for letting us know the feedback from Fly.io folks! I am glad that you were able to get it working. My understanding is that nftables is the future. I would imagine that Fly folks will eventually start supporting it too- perhaps there are some technical issues that are making it hard for them. Generally, I am guessing it is now expected that most cloud providers etc would support nftables- it seems like that was the assumption from Alpine when they linked the iptables to nftables. From our side I think we wil have to update our documentation for Fly.io https://tailscale.com/kb/1132/flydotio/#step-2-configure-your-dockerfile-to-install-tailscale- at the moment I am not sure what else we could do.
Do you foresee any issues with this flow (it looks fine to me, I'm just curious)? |
|
I'm on Fly specifically for the philosophy in their approach; from what I understand, I would be very surprised if they never gained nftables support. :) No, I don't see any issues with the current setup. (Thanks for asking!) I don't love having to choose a legacy implementation, obviously, but I don't mind it here. Feels transitional. |
|
@isaacbowen we've updated our docs for Fly.io - using bits of the Dockerfile config that you shared- thank you for that! (I also ran a test on Fly.io and could reproduce both the issue that you saw and also verify the fix). I am guessing we can now close this issue. |
|
Fantastic! Yep, that sounds like all there is to be done. I’ll close it out. Also, thanks for this exchange! I’m very grateful. :) |
|
Fly now supports nftables! Yay! :D https://community.fly.io/t/kernel-nftables-support/17669 @irbekrm I'm not sure what the right process is for updating Tailscale docs; can you have a look? |
|
Hi @isaacbowen thank you very much for the heads up and thanks for raising this issue with the Fly folks! I've tried it out and can confirm that it was working for me too (including MagicDNS functioning) after updating the machine as per their docs. I'm going to update our docs. It's awesome that they fixed this so quick :) |
|
Took me an hour of googling to find this. Works on a new LXC install of alpine 3.19 on proxmox. Not using docker. Thanks for the fix y'all. |
Can you share the download link for the proxmox lxc template for alpine version 3.19? |
Should have been more specific, Proxmox LXC is 3.18, upgraded to 3.19 via https://wiki.alpinelinux.org/wiki/Upgrading_Alpine |
What is the issue?
The main thing:
The machine can connect to other machines in the tailnet by ip address, but not via MagicDNS.
Complete logs from a recent bootup:
Steps to reproduce
Are there any recent changes that introduced the issue?
The error shows up using the ruby:alpine docker image, which just received an update to alpine 3.19.
docker-library/ruby#433
https://www.alpinelinux.org/posts/Alpine-3.19.0-released.html
The new version of alpine bumps the version of iptables:
For comparison, this was the previous version used:
OS
Linux
OS version
Alpine 3.19
Tailscale version
1.54.1
Other software
No response
Bug report
BUG-4de9ac0d2e29fe4712c0a1e555c47b8e0263df745e9675d34e9a03a39dbdbf22-20231209135110Z-ea37df7f8d02ead5
The text was updated successfully, but these errors were encountered: