Lot of people have been hitting this.
Now it says:
$ tailscale cert tsdev.corp.ts.net
Access denied: cert access denied
Use 'sudo tailscale cert' or 'tailscale up --operator=$USER' to not require root.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit f62e6d83a9cdc2dc62d15411aeb45927e916ead4)
We still try the host's x509 roots first, but if that fails (like if
the host is old), we fall back to using LetsEncrypt's root and
retrying with that.
tlsdial was used in the three main places: logs, control, DERP. But it
was missing in dnsfallback. So added it there too, so we can run fine
now on a machine with no DNS config and no root CAs configured.
Also, move SSLKEYLOGFILE support out of DERP. tlsdial is the logical place
for that support.
Fixes#1609
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 7cf8ec8108f4e26092bf07f698c8c5ce70d27d13)
DNSSEC is an availability issue, as recently demonstrated by the
Slack issue, with limited security advantage. DoH on the other hand
is a critical security upgrade. This change adds DoH support for the
non-DNSSEC endpoints of Quad9.
https://www.quad9.net/service/service-addresses-and-features#unsec
Signed-off-by: Filippo Valsorda <hi@filippo.io>
(cherry picked from commit d7ce2be5f4588e5451aebc457adf778081e0a114)
Like mentioning which cert domain(s) are valid.
(cherry picked from commit 891e7986cce17a3c5ff24047a2e5c6158dd66d67)
(cherry picked from commit b10a55e4ed82a42cc0b46c8c8d87af4d08569e16)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
It was in the wrong filter direction before, per CPU profiles
we now have.
Updates #1526 (maybe fixes? time will tell)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 080381c79fa4fa273c486e45edbd7f6cc5ee73ac)
So SOCKS5 dialer can dial HTTPS cert names, for instance.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 29a8fb45d32b562c7b0624a56170978076506a67)
This fixes "tailscale cert" on Synology where the var directory is
typically like /volume2/@appdata/Tailscale, or any other tailscaled
user who specifies a non-standard state file location.
This is a interim fix on the way to #2932.
Fixes#2927
Updates #2932
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
We unconditionally set appropriate perms on the statefile dir.
We look at the basename of the statefile dir, and if it is "tailscale", then
we set perms as appropriate.
Fixes#2925
Updates #2856
Signed-off-by: Aaron Klotz <aaron@tailscale.com>
ProgramData has a permissive ACL. For us to safely store machine-wide
state information, we must set a more restrictive ACL on our state directory.
We set the ACL so that only talescaled's user (ie, LocalSystem) and the
Administrators group may access our directory.
We must include Administrators to ensure that logs continue to be easily
accessible; omitting that group would force users to use special tools to
log in interactively as LocalSystem, which is not ideal.
(Note that the ACL we apply matches the ACL that was used for LocalSystem's
AppData\Local).
There are two cases where we need to reset perms: One is during migration
from the old location to the new. The second case is for clean installations
where we are creating the file store for the first time.
Updates #2856
Signed-off-by: Aaron Klotz <aaron@tailscale.com>
tailscale-ipn.exe (the GUI) shouldn't use C:\ProgramData.
Also, migrate the earlier misnamed wg32/wg64 conf files if they're present.
(That was stopped in 2db877caa332c8968ee1b1eb08ef40a219ff3eec, but the
files exist from fresh 1.14 installs)
Updates #2856
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
C:\WINDOWS\system32\config\systemprofile\AppData\Local\
is frequently cleared for almost any reason: Windows updates,
System Restore, even various System Cleaner utilities.
The server-state.conf file in AppData\Local could be deleted
at any time, which would break login until the node is removed
from the Admin Panel allowing it to create a new key.
Carefully copy any AppData state to ProgramData at startup.
If copying the state fails, continue to use AppData so at
least there will be connectivity. If there is no state,
use ProgramData.
We also migrate the log.conf file. Very old versions of
Tailscale named the EXE tailscale-ipn, so the log conf was
tailscale-ipn.log.conf and more recent versions preserved
this filename and cmdName in logs. In this migration we
always update the filename to
c:\ProgramData\Tailscale\tailscaled.log.conf
Updates https://github.com/tailscale/tailscale/issues/2856
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
This reverts the following commits:
8704fb308d6109baf9797231c09bcc6af9681771
afb95d7246b3f7776185abf0959544549d425f06
277bf8f48c0e52dd26b36a39ddf88b924927ee72
c995ac72a39dbc3a99ce7752f4a3c996f6fb7d99
e699226e802fed16e5af64d7eaa6c3c4537058bb
We're going to try again to build 1.14.1
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
I had updated VERSION.txt to 1.14.1, tagged and pushed the tag, then
noticed that continuous integration failed because the list of DERP
servers for emergency DNS fallback needed to be updated.
I tried to revert VERSION.txt, delete the tag, update DERP, and tag
again but it won't import in the next step because the checksum is
wrong. I had deleted the tag and moved it, and something out there
wants none of that funny business.
Honestly I'm kindof glad, gives confidence in the integrity of
the tree.
ANYWAY, 1.14.1 is unusable and we're going to 1.14.2.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
Nevermind, that was not 1.14.1 after all
This reverts commit e699226e802fed16e5af64d7eaa6c3c4537058bb.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
This test is highly dependent on the accuracy of OS timers.
Reduce the number of failures by decreasing the required
accuracy from 0.999 to 0.995.
Also, switch from repeated time.Sleep to using a time.Ticker
for improved accuracy.
Updates #2727
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
(cherry picked from commit 30458c71c81a3d680aacecafa67fabc1c728c52d)
Unfortunately this test fails on certain architectures.
The problem comes down to inconsistencies in the Go escape analysis
where specific variables are marked as escaping on certain architectures.
The variables escaping to the heap are unfortunately in crypto/sha256,
which makes it impossible to fixthis locally in deephash.
For now, fix the test by compensating for the allocations that
occur from calling sha256.digest.Sum.
See golang/go#48055
Fixes#2727
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
(cherry picked from commit 3f1317e3e52e63c8aaaf251ae77efc0e4dfe0f6e)
It wasn't using the right metric. Apparently you're supposed to sum the route
metric and interface metric. Whoops.
While here, optimize a few little things too, not that this code
should be too hot.
Fixes#2707 (at least; probably dups but I'm failing to find)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 3606e68721d6e11e01b31acfc66e959635bf9926)
To be scraped in the Go expvar JSON format, as a string is involved.
For a future tool to record when processes restarted exactly, and at
what version.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
If a peer is connected to multiple nodes in a region (so
multiForwarder is in use) and then a node restarts and re-sends all
its additions, this bug about whether an element is in the
multiForwarder could cause a one-time flip in the which peer node we
forward to. Note a huge deal, but not written as intended.
Thanks to @lewgun for the bug report in #2141.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This log is quite verbose, it was only to be left in for one
unstable build to help debug a user issue.
This reverts commit 1dd25520326f0adc1d37c12710c9f33c830a7ef5.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
This is useful for manual performance testing
of networks with many nodes.
I imagine it'll grow more knobs over time.
Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>
