Turns out the iOS client has been only sending the OS version it first
started at. This whole hostinfo-via-prefs mechanism was never a good idea.
Start removing it.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
I forgot to include this file in the earlier
7cf8ec8108 commit.
This exists purely to keep "go mod tidy" happy.
Updates #1609
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
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>
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>
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>
The old name invited confusion:
* is this the HTTP proxy to use ourselves? (no, that's
via an environment variable, per proxy conventions)
* is this for LetsEncrypt https-to-localhost-http
proxying? (no, that'll come later)
So rename to super verbose --outbound-http-proxy-listen
before the 1.16.0 release to make it clear what it is.
It listens (serves) and it's for outbound, not inbound.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This adds support for tailscaled to be an HTTP proxy server.
It shares the same backend dialing code as the SOCK5 server, but the
client protocol is HTTP (including CONNECT), rather than SOCKS.
Fixes#2289
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
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>
Because the macOS CLI runs in the sandbox, including the filesystem,
so users would be confused that -cpu-profile=prof.cpu succeeds but doesn't
write to their current directory, but rather in some random Library/Containers
directory somewhere on the machine (which varies depending on the Mac build
type: App Store vs System Extension)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This was already possible on Linux if you ran tailscaled with --debug
(which runs net/http/pprof), but it requires the user have the Go
toolchain around.
Also, it wasn't possible on macOS, as there's no way to run the IPNExtension
with a debug server (it doesn't run tailscaled).
And on Windows it's super tedious: beyond what users want to do or
what we want to explain.
Instead, put it in "tailscale debug" so it works and works the same on
all platforms. Then we can ask users to run it when we're debugging something
and they can email us the output files.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
There are two reasons this can't ever go to actual logs,
but rewrite it to make it happy.
Fixestailscale/corp#2695
Signed-off-by: Brad Fitzpatrick <bradfitz@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 2db877caa3, but the
files exist from fresh 1.14 installs)
Updates #2856
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
So if the control plane knows that something's broken about the node, it can
include problem(s) in MapResponse and "tailscale status" will show it.
(and GUIs in the future, as it's in ipnstate.Status/JSON)
This also bumps the MapRequest.Version, though it's not strictly
required. Doesn't hurt.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Real goal is to eliminate some allocs in the STUN path, but that requires
work in the standard library.
See comments in #2783.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Avoid splitting fields in the common case. Field splitting was 84% of
the overall CPU.
name old time/op new time/op delta
ParsePorts-6 33.3ms ± 2% 6.3ms ± 4% -80.97% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
ParsePorts-6 520B ±79% 408B ± 0% -21.49% (p=0.046 n=10+8)
name old allocs/op new allocs/op delta
ParsePorts-6 7.00 ± 0% 7.00 ± 0% ~ (all equal)
Updates tailscale/corp#2566
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Notably, it no longer allocates proportional to the number of open
sockets on the machine. Any alloc reduction numbers are a little
contrived with such a reduction but e.g. on a machine with 50,000
connections open:
name old time/op new time/op delta
ParsePorts-6 57.7ms ± 6% 32.8ms ± 3% -43.04% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
ParsePorts-6 24.0MB ± 0% 0.0MB ± 0% -100.00% (p=0.000 n=10+9)
name old allocs/op new allocs/op delta
ParsePorts-6 100k ± 0% 0k ± 0% -99.99% (p=0.000 n=10+10)
Updates tailscale/corp#2566
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
The earlier 382b349c54 was too late,
as engine creation itself needed to listen on things.
Fixes#2827
Updates #2822
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Updates #2781 (might even fix it, but its real issue is that
SetPrivateKey starts a ReSTUN goroutines which then logs, and
that bug and data race existed prior to MemLogger existing)
In prep for other bug fixes & tests. It's hard to test when it was
intermingled into LocalBackend.authReconfig.
Now it's a pure function.
And rename variable 'uc' (user config?) to the since idiomatic
'prefs'.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
And in the process, fix the related confusing error messages from
pinging your own IP or hostname.
Fixes#2803
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
And add health check errors to ipnstate.Status (tailscale status --json).
Updates #2746
Updates #2775
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
At "Starting", the DERP connection isn't yet up. After the first netmap
and DERP connect, then it transitions into "Running".
Fixes#2708
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
So people can use the package for whois checks etc without version
skew errors.
The earlier change faa891c1f2 for #1905
was a bit too aggressive.
Fixes#2757
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
A public key should only have max one connection to a given
DERP node (or really: one connection to a node in a region).
But if people clone their machine keys (e.g. clone their VM, Raspbery
Pi SD card, etc), then we can get into a situation where a public key
is connected multiple times.
Originally, the DERP server handled this by just kicking out a prior
connections whenever a new one came. But this led to reconnect fights
where 2+ nodes were in hard loops trying to reconnect and kicking out
their peer.
Then a909d37a59 tried to add rate
limiting to how often that dup-kicking can happen, but empirically it
just doesn't work and ~leaks a bunch of goroutines and TCP
connections, tying them up for hour+ while more and more accumulate
and waste memory. Mostly because we were doing a time.Sleep forever
while not reading from their TCP connections.
Instead, just accept multiple connections per public key but track
which is the most recent. And if two both are writing back & forth,
then optionally disable them both. That last part is only enabled in
tests for now. The current default policy is just last-sender-wins
while we gather the next round of stats.
Updates #2751
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
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>
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>