1145 Commits (7f3c1932b54fb6af2d8d1e367e0e456ff7fa40fd)

Author	SHA1	Message	Date
Brad Fitzpatrick	d912a49be6	net/tstun: add logging to aid developers missing Start calls ... Since 5297bd2cff, tstun.Wrapper has required its Start method to be called for it to function. Failure to do so just results in weird hangs and I've wasted too much time multiple times now debugging. Hopefully this prevents more lost time. Updates tailscale/corp#24454 Change-Id: I87f4539f7be7dc154627f8835a37a8db88c31be0 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Aaron Klotz	7d73a38b40	net/dns: only populate OSConfig.Hosts when MagicDNS is enabled ... Previously we were doing this unconditionally. Updates #14428 Signed-off-by: Aaron Klotz <aaron@tailscale.com>	1 year ago
James Tucker	6364b5f1e0	net/netmon: trim IPv6 endpoints in already routable subnets ... We have observed some clients with extremely large lists of IPv6 endpoints, in some cases from subnets where the machine also has the zero address for a whole /48 with then arbitrary addresses additionally assigned within that /48. It is in general unnecessary for reachability to report all of these addresses, typically only one will be necessary for reachability. We report two, to cover some other common cases such as some styles of IPv6 private address rotations. Updates tailscale/corp#25850 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
Aaron Klotz	d818a58a77	net/dns: ensure the Windows configurator does not touch the hosts file unless the configuration actually changed ... We build up maps of both the existing MagicDNS configuration in hosts and the desired MagicDNS configuration, compare the two, and only write out a new one if there are changes. The comparison doesn't need to be perfect, as the occasional false-positive is fine, but this should greatly reduce rewrites of the hosts file. I also changed the hosts updating code to remove the CRLF/LF conversion stuff, and use Fprintf instead of Frintln to let us write those inline. Updates #14428 Signed-off-by: Aaron Klotz <aaron@tailscale.com>	1 year ago
Brad Fitzpatrick	60d19fa00d	all: use Go 1.21's binary.NativeEndian ... We still use josharian/native (hi @josharian!) via netlink, but I also sent https://github.com/mdlayher/netlink/pull/220 Updates #8632 Change-Id: I2eedcb7facb36ec894aee7f152c8a1f56d7fc8ba Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Nahum Shalman	9373a1b902	all: illumos/solaris userspace only support ... Updates #14565 Change-Id: I743148144938794db0a224873ce76c10dbe6fa5f Signed-off-by: Nahum Shalman <nahamu@gmail.com>	1 year ago
Will Norris	60daa2adb8	all: fix golangci-lint errors ... These erroneously blocked a recent PR, which I fixed by simply re-running CI. But we might as well fix them anyway. These are mostly `printf` to `print` and a couple of `!=` to `!Equal()` Updates #cleanup Signed-off-by: Will Norris <will@tailscale.com>	1 year ago
James Tucker	de9d4b2f88	net/netmon: remove extra panic guard around ParseRIB ... This was an extra defense added for #14201 that is no longer required. Fixes #14201 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
Brad Fitzpatrick	1e2e319e7d	util/slicesx: add MapKeys and MapValues from golang.org/x/exp/maps ... Importing the ~deprecated golang.org/x/exp/maps as "xmaps" to not shadow the std "maps" was getting ugly. And using slices.Collect on an iterator is verbose & allocates more. So copy (x)maps.Keys+Values into our slicesx package instead. Updates #cleanup Updates #12912 Updates #14514 (pulled out of that change) Change-Id: I5e68d12729934de93cf4a9cd87c367645f86123a Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Joe Tsai	b62a013ecb	Switch logging service from log.tailscale.io to log.tailscale.com (#14398) ... Updates tailscale/corp#23617 Signed-off-by: Joe Tsai <joetsai@digital-static.net>	1 year ago
James Tucker	aa04f61d5e	net/netcheck: adjust HTTPS latency check to connection time and avoid data race ... The go-httpstat package has a data race when used with connections that are performing happy-eyeballs connection setups as we are in the DERP client. There is a long-stale PR upstream to address this, however revisiting the purpose of this code suggests we don't really need httpstat here. The code populates a latency table that may be used to compare to STUN latency, which is a lightweight RTT check. Switching out the reported timing here to simply the request HTTP request RTT avoids the problematic package. Fixes tailscale/corp#25095 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
Irbe Krumina	614c612643	net/netcheck: preserve STUN port defaulting to 3478 (#14289) ... Updates tailscale/tailscale#14287 Signed-off-by: Irbe Krumina <irbe@tailscale.com>	1 year ago
James Tucker	7f9ebc0a83	cmd/tailscale,net/netcheck: add debug feature to force preferred DERP ... This provides an interface for a user to force a preferred DERP outcome for all future netchecks that will take precedence unless the forced region is unreachable. The option does not persist and will be lost when the daemon restarts. Updates tailscale/corp#18997 Updates tailscale/corp#24755 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
Brad Fitzpatrick	74069774be	net/tstun: remove tailscaled_outbound_dropped_packets_total reason=acl metric for now ... Updates #14280 Change-Id: Idff102b3d7650fc9dfbe0c340168806bdf542d76 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Brad Fitzpatrick	8d0c690f89	net/netcheck: clean up ICMP probe AddrPort lookup ... Fixes #14200 Change-Id: Ib086814cf63dda5de021403fe1db4fb2a798eaae Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
James Tucker	4d33f30f91	net/netmon: improve panic reporting from #14202 ... I was hoping we'd catch an example input quickly, but the reporter had rebooted their machine and it is no longer exhibiting the behavior. As such this code may be sticking around quite a bit longer and we might encounter other errors, so include the panic in the log entry. Updates #14201 Updates #14202 Updates golang/go#70528 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
James Tucker	f6431185b0	net/netmon: catch ParseRIB panic to gather buffer data ... Updates #14201 Updates golang/go#70528 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
Brad Fitzpatrick	0c8c7c0f90	net/tsaddr: include test input in test failure output ... https://go.dev/wiki/CodeReviewComments#useful-test-failures (Previously it was using subtests with names including the input, but once those went away, there was no context left) Updates #14169 Change-Id: Ib217028183a3d001fe4aee58f2edb746b7b3aa88 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
James Scott	ebaf33a80c	net/tsaddr: extract IsTailscaleIPv4 from IsTailscaleIP (#14169) ... Extracts tsaddr.IsTailscaleIPv4 out of tsaddr.IsTailscaleIP. This will allow for checking valid Tailscale assigned IPv4 addresses without checking IPv6 addresses. Updates #14168 Updates tailscale/corp#24620 Signed-off-by: James Scott <jim@tailscale.com>	1 year ago
Brad Fitzpatrick	3b93fd9c44	net/captivedetection: replace 10k log lines with ... less ... We see tons of logs of the form: 2024/11/15 19:57:29 netcheck: [v2] 76 available captive portal detection endpoints: [Endpoint{URL="http://192.73.240.161/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.240.121/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.240.132/generate_204", StatusCode=204, ExpectedContent="", 11:58SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://209.177.158.246/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://209.177.158.15/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://199.38.182.118/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.243.135/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.243.229/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.243.141/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://45.159.97.144/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://45.159.97.61/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://45.159.97.233/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://45.159.98.196/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://45.159.98.253/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://45.159.98.145/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://68.183.90.120/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://209.177.156.94/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.248.83/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://209.177.156.197/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://199.38.181.104/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://209.177.145.120/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://199.38.181.93/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://199.38.181.103/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://102.67.165.90/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://102.67.165.185/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://102.67.165.36/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.90.147/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.90.207/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.90.104/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://162.248.221.199/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://162.248.221.215/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://162.248.221.248/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://185.34.3.232/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://185.34.3.207/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://185.34.3.75/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://208.83.234.151/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://208.83.233.233/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://208.72.155.133/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://185.40.234.219/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://185.40.234.113/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://185.40.234.77/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://43.245.48.220/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://43.245.48.50/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://43.245.48.250/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.252.65/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.252.134/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://208.111.34.178/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://43.245.49.105/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://43.245.49.83/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://43.245.49.144/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.92.144/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.88.183/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.92.254/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://148.163.220.129/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://148.163.220.134/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://148.163.220.210/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.242.187/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.242.28/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.242.204/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.93.248/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.93.147/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://176.58.93.154/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://192.73.244.245/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://208.111.40.12/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://208.111.40.216/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://103.6.84.152/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://205.147.105.30/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://205.147.105.78/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://102.67.167.245/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://102.67.167.37/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://102.67.167.188/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://103.84.155.178/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://103.84.155.188/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://103.84.155.46/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=true, Provider=DERPMapOther} Endpoint{URL="http://controlplane.tailscale.com/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=false, Provider=Tailscale} Endpoint{URL="http://login.tailscale.com/generate_204", StatusCode=204, ExpectedContent="", SupportsTailscaleChallenge=false, Provider=Tailscale}] That can be much shorter. Also add a fast exit path to the concurrency on match. Doing 5 all at once is still pretty gratuitous, though. Updates #1634 Fixes #13019 Change-Id: Icdbb16572fca4477b0ee9882683a3ac6eb08e2f2 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Brad Fitzpatrick	4e0fc037e6	all: use iterators over slice views more ... This gets close to all of the remaining ones. Updates #12912 Change-Id: I9c672bbed2654a6c5cab31e0cbece6c107d8c6fa Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Brad Fitzpatrick	01185e436f	types/result, util/lineiter: add package for a result type, use it ... This adds a new generic result type (motivated by golang/go#70084) to try it out, and uses it in the new lineutil package (replacing the old lineread package), changing that package to return iterators: sometimes over []byte (when the input is all in memory), but sometimes iterators over results of []byte, if errors might happen at runtime. Updates #12912 Updates golang/go#70084 Change-Id: Iacdc1070e661b5fb163907b1e8b07ac7d51d3f83 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
VimT	43138c7a5c	net/socks5: optimize UDP relay ... Key changes: - No mutex for every udp package: replace syncs.Map with regular map for udpTargetConns - Use socksAddr as map key for better type safety - Add test for multi udp target Updates #7581 Change-Id: Ic3d384a9eab62dcbf267d7d6d268bf242cc8ed3c Signed-off-by: VimT <me@vimt.me>	1 year ago
VimT	b0626ff84c	net/socks5: fix UDP relay in userspace-networking mode ... This commit addresses an issue with the SOCKS5 UDP relay functionality when using the --tun=userspace-networking option. Previously, UDP packets were not being correctly routed into the Tailscale network in this mode. Key changes: - Replace single UDP connection with a map of connections per target - Use c.srv.dial for creating connections to ensure proper routing Updates #7581 Change-Id: Iaaa66f9de6a3713218014cf3f498003a7cac9832 Signed-off-by: VimT <me@vimt.me>	1 year ago
Jordan Whited	49de23cf1b	net/netcheck: add addReportHistoryAndSetPreferredDERP() test case (#13989) ... Add an explicit case for exercising preferred DERP hysteresis around the branch that compares latencies on a percentage basis. Updates #cleanup Signed-off-by: Jordan Whited <jordan@tailscale.com>	1 year ago
Andrea Gottardo	6985369479	net/sockstats: prevent crash in setNetMon (#13985)	1 year ago
Anton Tolchanov	b4f46c31bb	wgengine/magicsock: export packet drop metric for outbound errors ... This required sharing the dropped packet metric between two packages (tstun and magicsock), so I've moved its definition to util/usermetric. Updates tailscale/corp#22075 Signed-off-by: Anton Tolchanov <anton@tailscale.com>	1 year ago
James Tucker	e1e22785b4	net/netcheck: ensure prior preferred DERP is always in netchecks ... In an environment with unstable latency, such as upstream bufferbloat, there are cases where a full netcheck could drop the prior preferred DERP (likely home DERP) from future netcheck probe plans. This will then likely result in a home DERP having a missing sample on the next incremental netcheck, ultimately resulting in a home DERP move. This change does not fix our overall response to highly unstable latency, but it is an incremental improvement to prevent single spurious samples during a full netcheck from alone triggering a flapping condition, as now the prior changes to include historical latency will still provide the desired resistance, and the home DERP should not move unless latency is consistently worse over a 5 minute period. Note that there is a nomenclature and semantics issue remaining in the difference between a report preferred DERP and a home DERP. A report preferred DERP is aspirational, it is what will be picked as a home DERP if a home DERP connection needs to be established. A nodes home DERP may be different than a recent preferred DERP, in which case a lot of netcheck logic is fallible. In future enhancements much of the DERP move logic should move to consider the home DERP, rather than recent report preferred DERP. Updates #8603 Updates #13969 Signed-off-by: James Tucker <james@tailscale.com>	1 year ago
Renato Aguiar	5d07c17b93	net/dns: fix blank lines being added to resolv.conf on OpenBSD (#13928) ... During resolv.conf update, old 'search' lines are cleared but '\n' is not deleted, leaving behind a new blank line on every update. This adds 's' flag to regexp, so '\n' is included in the match and deleted when old lines are cleared. Also, insert missing `\n` when updated 'search' line is appended to resolv.conf. Signed-off-by: Renato Aguiar <renato@renatoaguiar.net>	1 year ago
Andrew Dunham	7fe6e50858	net/dns/resolver: fix test flake ... Updates #13902 Signed-off-by: Andrew Dunham <andrew@du.nham.ca> Change-Id: Ib2def19caad17367e9a31786ac969278e65f51c6	1 year ago
Andrew Dunham	b2665d9b89	net/netcheck: add a Now field to the netcheck Report ... This allows us to print the time that a netcheck was run, which is useful in debugging. Updates #10972 Signed-off-by: Andrew Dunham <andrew@du.nham.ca> Change-Id: Id48d30d4eb6d5208efb2b1526a71d83fe7f9320b	1 year ago
Maisem Ali	85241f8408	net/tstun: use /10 as subnet for TAP mode; read IP from netmap ... Few changes to resolve TODOs in the code: - Instead of using a hardcoded IP, get it from the netmap. - Use 100.100.100.100 as the gateway IP - Use the /10 CGNAT range instead of a random /24 Updates #2589 Signed-off-by: Maisem Ali <maisem@tailscale.com>	1 year ago
Maisem Ali	d4d21a0bbf	net/tstun: restore tap mode functionality ... It had bit-rotted likely during the transition to vector io in 76389d8baf. Tested on Ubuntu 24.04 by creating a netns and doing the DHCP dance to get an IP. Updates #2589 Signed-off-by: Maisem Ali <maisem@tailscale.com>	1 year ago
Andrea Gottardo	f8f53bb6d4	health: remove SysDNSOS, add two Warnables for read+set system DNS config (#13874)	1 year ago
Andrea Gottardo	fd77965f23	net/tlsdial: call out firewalls blocking Tailscale in health warnings (#13840) ... Updates tailscale/tailscale#13839 Adds a new blockblame package which can detect common MITM SSL certificates used by network appliances. We use this in `tlsdial` to display a dedicated health warning when we cannot connect to control, and a network appliance MITM attack is detected. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	1 year ago
Jordan Whited	877fa504b4	net/netcheck: remove arbitrary deadlines from GetReport() tests (#13832) ... GetReport() may have side effects when the caller enforces a deadline that is shorter than ReportTimeout. Updates #13783 Updates #13394 Signed-off-by: Jordan Whited <jordan@tailscale.com>	1 year ago
Kristoffer Dalby	e0d711c478	{net/connstats,wgengine/magicsock}: fix packet counting in connstats ... connstats currently increments the packet counter whenever it is called to store a length of data, however when udp batch sending was introduced we pass the length for a series of packages, and it is only incremented ones, making it count wrongly if we are on a platform supporting udp batches. Updates tailscale/corp#22075 Signed-off-by: Kristoffer Dalby <kristoffer@tailscale.com>	1 year ago
Nick Khyl	f07ff47922	net/dns/resolver: add tests for using a forwarder with multiple upstream resolvers ... If multiple upstream DNS servers are available, quad-100 sends requests to all of them and forwards the first successful response, if any. If no successful responses are received, it propagates the first failure from any of them. This PR adds some test coverage for these scenarios. Updates #13571 Signed-off-by: Nick Khyl <nickk@tailscale.com>	1 year ago
Nick Hill	c2144c44a3	net/dns/resolver: update (*forwarder).forwardWithDestChan to always return an error unless it sends a response to responseChan ... We currently have two executions paths where (*forwarder).forwardWithDestChan returns nil, rather than an error, without sending a DNS response to responseChan. These paths are accompanied by a comment that reads: // Returning an error will cause an internal retry, there is // nothing we can do if parsing failed. Just drop the packet. But it is not (or no longer longer) accurate: returning an error from forwardWithDestChan does not currently cause a retry. Moreover, although these paths are currently unreachable due to implementation details, if (*forwarder).forwardWithDestChan were to return nil without sending a response to responseChan, it would cause a deadlock at one call site and a panic at another. Therefore, we update (*forwarder).forwardWithDestChan to return errors in those two paths and remove comments that were no longer accurate and misleading. Updates #cleanup Updates #13571 Signed-off-by: Nick Hill <mykola.khyl@gmail.com>	1 year ago
Nick Hill	e7545f2eac	net/dns/resolver: translate 5xx DoH server errors into SERVFAIL DNS responses ... If a DoH server returns an HTTP server error, rather than a SERVFAIL within a successful HTTP response, we should handle it in the same way as SERVFAIL. Updates #13571 Signed-off-by: Nick Hill <mykola.khyl@gmail.com>	1 year ago
Nick Hill	17335d2104	net/dns/resolver: forward SERVFAIL responses over PeerDNS ... As per the docstring, (*forwarder).forwardWithDestChan should either send to responseChan and returns nil, or returns a non-nil error (without sending to the channel). However, this does not hold when all upstream DNS servers replied with an error. We've been handling this special error path in (*Resolver).Query but not in (*Resolver).HandlePeerDNSQuery. As a result, SERVFAIL responses from upstream servers were being converted into HTTP 503 responses, instead of being properly forwarded as SERVFAIL within a successful HTTP response, as per RFC 8484, section 4.2.1: A successful HTTP response with a 2xx status code (see Section 6.3 of [RFC7231]) is used for any valid DNS response, regardless of the DNS response code. For example, a successful 2xx HTTP status code is used even with a DNS message whose DNS response code indicates failure, such as SERVFAIL or NXDOMAIN. In this PR we fix (*forwarder).forwardWithDestChan to no longer return an error when it sends a response to responseChan, and remove the special handling in (*Resolver).Query, as it is no longer necessary. Updates #13571 Signed-off-by: Nick Hill <mykola.khyl@gmail.com>	1 year ago
Jordan Whited	33029d4486	net/netcheck: fix netcheck cli-triggered nil pointer deref (#13782) ... Updates #13780 Signed-off-by: Jordan Whited <jordan@tailscale.com>	1 year ago
Brad Fitzpatrick	841eaacb07	net/sockstats: quiet some log spam in release builds ... Updates #13731 Change-Id: Ibee85426827ebb9e43a1c42a9c07c847daa50117 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Andrew Dunham	8ee7f82bf4	net/netcheck: don't panic if a region has no Nodes ... Updates #13728 Signed-off-by: Andrew Dunham <andrew@du.nham.ca> Change-Id: I1e8319d6b2da013ae48f15113b30c9333e69cc0b	1 year ago
Andrea Gottardo	6de6ab015f	net/dns: tweak DoH timeout, limit MaxConnsPerHost, require TLS 1.3 (#13564) ... Updates tailscale/tailscale#6148 This is the result of some observations we made today with @raggi. The DNS over HTTPS client currently doesn't cap the number of connections it uses, either in-use or idle. A burst of DNS queries will open multiple connections. Idle connections remain open for 30 seconds (this interval is defined in the dohTransportTimeout constant). For DoH providers like NextDNS which send keep-alives, this means the cellular modem will remain up more than expected to send ACKs if any keep-alives are received while a connection remains idle during those 30 seconds. We can set the IdleConnTimeout to 10 seconds to ensure an idle connection is terminated if no other DNS queries come in after 10 seconds. Additionally, we can cap the number of connections to 1. This ensures that at all times there is only one open DoH connection, either active or idle. If idle, it will be terminated within 10 seconds from the last query. We also observed all the DoH providers we support are capable of TLS 1.3. We can force this TLS version to reduce the number of packets sent/received each time a TLS connection is established. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	1 year ago
Brad Fitzpatrick	f49d218cfe	net/dnscache: don't fall back to an IPv6 dial if we don't have IPv6 ... I noticed while debugging a test failure elsewhere that our failure logs (when verbosity is cranked up) were uselessly attributing dial failures to failure to dial an invalid IP address (this IPv6 address we didn't have), rather than showing me the actual IPv4 connection failure. Updates #13597 (tangentially) Change-Id: I45ffbefbc7e25ebfb15768006413a705b941dae5 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Andrea Gottardo	ed1ac799c8	net/captivedetection: set Timeout on net.Dialer (#13613) ... Updates tailscale/tailscale#1634 Updates tailscale/tailscale#13265 Captive portal detection uses a custom `net.Dialer` in its `http.Client`. This custom Dialer ensures that the socket is bound specifically to the Wi-Fi interface. This is crucial because without it, if any default routes are set, the outgoing requests for detecting a captive portal would bypass Wi-Fi and go through the default route instead. The Dialer did not have a Timeout property configured, so the default system timeout was applied. This caused issues in #13265, where we attempted to make captive portal detection requests over an IPsec interface used for Wi-Fi Calling. The call to `connect()` would fail and remain blocked until the system timeout (approximately 1 minute) was reached. In #13598, I simply excluded the IPsec interface from captive portal detection. This was a quick and safe mitigation for the issue. This PR is a follow-up to make the process more robust, by setting a 3 seconds timeout on any connection establishment on any interface (this is the same timeout interval we were already setting on the HTTP client). Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	1 year ago
Brad Fitzpatrick	262c526c4e	net/portmapper: don't treat 0.0.0.0 as a valid IP ... Updates tailscale/corp#23538 Change-Id: I58b8c30abe43f1d1829f01eb9fb2c1e6e8db9476 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	1 year ago
Andrew Dunham	16ef88754d	net/portmapper: don't return unspecified/local external IPs ... We were previously not checking that the external IP that we got back from a UPnP portmap was a valid endpoint; add minimal validation that this endpoint is something that is routeable by another host. Updates tailscale/corp#23538 Signed-off-by: Andrew Dunham <andrew@du.nham.ca> Change-Id: Id9649e7683394aced326d5348f4caa24d0efd532	1 year ago
Andrea Gottardo	69be54c7b6	net/captivedetection: exclude ipsec interfaces from captive portal detection (#13598) ... Updates tailscale/tailscale#1634 Logs from some iOS users indicate that we're pointlessly performing captive portal detection on certain interfaces named ipsec*. These are tunnels with the cellular carrier that do not offer Internet access, and are only used to provide internet calling functionality (VoLTE / VoWiFi). ``` attempting to do captive portal detection on interface ipsec1 attempting to do captive portal detection on interface ipsec6 ``` This PR excludes interfaces with the `ipsec` prefix from captive portal detection. Signed-off-by: Andrea Gottardo <andrea@gottardo.me>	1 year ago