diff options
| author | Denton Gentry <dgentry@tailscale.com> | 2022-07-04 09:05:01 -0700 |
|---|---|---|
| committer | Denton Gentry <dgentry@tailscale.com> | 2022-08-27 14:56:54 -0700 |
| commit | a78b8c14a4a80b602af5b619bbedb66e09ebaf21 (patch) | |
| tree | 55dd9c9e49c662cd7b8e86bc3221cfe21738af2e /scripts | |
| parent | e8f09d24c77ab4239783ea5d886402b38aeb6a3c (diff) | |
| download | tailscale-ip6tables.tar.xz tailscale-ip6tables.zip | |
WIP: tolerate ip6tables failures.ip6tables
It comes up reasonably often that a host has IPv6 configured
but broken or non-functional in some way. One recent example is
https://github.com/gitpod-io/gitpod/issues/8049 where the sypmtoms
were:
1. an error message and health check failure about ip6tables
2. MagicDNS didn't work, even for IPv4
MagicDNS is broken because the failure to initialize IPv6 returns
an error which stops the rest of the initialization. I think we
have another case where IPv6 failing results in not acceping IPv4
subnet routes. Clearly we'd prefer not to have subsets of
functionality be mysteriously broken.
This PR is not the right way to do it, but serves as a proof of concept
that tolerating IPv6 failures results in fixing https://github.com/gitpod-io/gitpod/issues/8049
without needing the workaround which gitpod put together.
Fixes https://github.com/tailscale/tailscale/issues/3002
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions