fixestailscale/tailscale#15269
Fixes the various CLIs for all of the various flavors of tailscaled on
darwin. The logic in version is updated so that we have methods that
return true only for the actual GUI app (which can beCLI) and the
order of the checks in localTCPPortAndTokenDarwin are corrected so
that the logic works with all 5 combinations of CLI and tailscaled.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
fixestailscale/corp#26806
IsMacSysApp is not returning the correct answer... It looks like the
rest of the code base uses isMacSysExt (when what they really want
to know is isMacSysApp). To fix the immediate issue (localAPI is broken
entirely in corp), we'll add this check to safesocket which lines up with
the other usages, despite the confusing naming.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
fixestailscale/corp#26806
This was still slightly incorrect. We care only if the caller is the macSys
or macOs app. isSandBoxedMacOS doesn't give us the correct answer
for macSys because technically, macsys isn't sandboxed.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
fixestailscale/corp#26806
Fixes a regression where LocalTCPPortAndToken needs to error out early
if we're not running as sandboxed macos so that we attempt to connect
using the normal unix machinery.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
updates tailscale/corp#25687
The darwin appstore and standalone clients now support XPC and the keychain for passing user credentials securely between the gui process and an NEVPNExtension hosted tailscaled. Clients that can communicate directly with the network extension, via XPC or the keychain, are now expected to call SetCredentials and supply credentials explicitly, fixing issues with the cli breaking if the current user cannot read the contents of /Library/Tailscale due to group membership restrictions. This matches how those clients source and supply credentials to the localAPI http client.
Non-platform-specific code that has traditionally been in the client is moved to safesocket.
/Libraray/Tailscaled/sameuserproof has its permissions changed to that it's readably only by users in the admin group. This restricts standalone CLI access for and direct use of localAPI to admins.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
updates tailscale/corp#24197
tailmac run now supports the --share option which will allow you
to specify a directory on the host which can be mounted in the guest
using mount_virtiofs vmshare <path>.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
updates tailscale/corp#24197
Generation of the Host.app path was erroneous and tailmac run
would not work unless the pwd was tailmac/bin. Now you can
be able to invoke tailmac from anywhere.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
updates tailcale/corp#22371
Adds custom macOS vm tooling. See the README for
the general gist, but this will spin up VMs with unixgram
capable network interfaces listening to a named socket,
and with a virtio socket device for host-guest communication.
We can add other devices like consoles, serial, etc as needed.
The whole things is buildable with a single make command, and
everything is controllable via the command line using the TailMac
utility.
This should all be generally functional but takes a few shortcuts
with error handling and the like. The virtio socket device support
has not been tested and may require some refinement.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
fixes tailscale#12968
The dns manager cleanup func was getting passed a nil
health tracker, which will panic. Fixed to pass it
the system health tracker.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
updates tailscale/corp#21823
Misconfigured, broken, or blocked DNS will often present as
"internet is broken'" to the end user. This plumbs the health tracker
into the dns manager and forwarder and adds a health warning
with a 5 second delay that is raised on failures in the forwarder and
lowered on successes.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Updates tailscale/corp#20677
The recover function wasn't getting set in the benchmark
tests. Default changed to an empty func.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Fixestailscale/corp#20677
Replaces the original attempt to rectify this (by injecting a netMon
event) which was both heavy handed, and missed cases where the
netMon event was "minor".
On apple platforms, the fetching the interface's nameservers can
and does return an empty list in certain situations. Apple's API
in particular is very limiting here. The header hints at notifications
for dns changes which would let us react ahead of time, but it's all
private APIs.
To avoid remaining in the state where we end up with no
nameservers but we absolutely need them, we'll react
to a lack of upstream nameservers by attempting to re-query
the OS.
We'll rate limit this to space out the attempts. It seems relatively
harmless to attempt a reconfig every 5 seconds (triggered
by an incoming query) if the network is in this broken state.
Missing nameservers might possibly be a persistent condition
(vs a transient error), but that would also imply that something
out of our control is badly misconfigured.
Tested by randomly returning [] for the nameservers. When switching
between Wifi networks, or cell->wifi, this will randomly trigger
the bug, and we appear to reliably heal the DNS state.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Fixestailscale/corp#20677
On macOS sleep/wake, we're encountering a condition where reconfigure the network
a little bit too quickly - before apple has set the nameservers for our interface.
This results in a persistent condition where we have no upstream resolver and
fail all forwarded DNS queries.
No upstream nameservers is a legitimate configuration, and we have no (good) way
of determining when Apple is ready - but if we need to forward a query, and we
have no nameservers, then something has gone badly wrong and the network is
very broken.
A simple fix here is to simply inject a netMon event, which will go through the
configuration dance again when we hit the SERVFAIL condition.
Tested by artificially/randomly returning [] for the list of nameservers in the bespoke
ipn-bridge code responsible for getting the nameservers.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Updates tailscale/corp#18960
Tests in corp called us using the wrong logging calls. Removed.
This is logged downstream anyway.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Updates tailscale/corp#18960
iOS uses Apple's NetworkMonitor to track the default interface and
there's no reason we shouldn't also use this on macOS, for the same
reasons noted in the comments for why this change was made on iOS.
This eliminates the need to load and parse the routing table when
querying the defaultRouter() in almost all cases.
A slight modification here (on both platforms) to fallback to the default
BSD logic in the unhappy-path rather than making assumptions that
may not hold. If netmon is eventually parsing AF_ROUTE and able
to give a consistently correct answer for the default interface index,
we can fall back to that and eliminate the Swift dependency.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Fixestailscale/corp#19558
A request for the suggested exit nodes that occurs too early in the
VPN lifecycle would result in a null deref of the netmap and/or
the netcheck report. This checks both and errors out.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Updates tailscale/corp#18724
When localAPI clients directly set ExitNodeID to "", the expected behaviour is that the prior exit node also gets zero'd - effectively setting the UI state back to 'no exit node was ever selected'
The IntenalExitNodePrior has been changed to be a non-opaque type, as it is read by the UI to render the users last selected exit node, and must be concrete. Future-us can either break this, or deprecate it and replace it with something more interesting.
Signed-off-by: Jonathan Nobels <jonathan@tailscale.com>
Jonathan NobelsandGitHub