This change refactors & moves the bulk of the app connector logic from
./cmd/sniproxy.
A future change will delete the delta in sniproxy and wire it to this type.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates: https://github.com/tailscale/corp/issues/15038
For the app connector use-case, it doesnt make sense to use listeners, because then you would
need to register thousands of listeners (for each proto/service/port combo) to handle ranges.
Instead, we plumb through the TCPHandlerForFlow abstraction, to avoid using the listeners
abstraction that would end up being a bit messy.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates: https://github.com/tailscale/corp/issues/15038
This PR plumbs through awareness of an IPv6 SNAT/masquerade address from the wire protocol
through to the low-level (tstun / wgengine). This PR is the first in two PRs for implementing
IPv6 NAT support to/from peers.
A subsequent PR will implement the data-plane changes to implement IPv6 NAT - this is just plumbing.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates ENG-991
The revoke-keys command allows nodes with tailnet lock keys
to collaborate to erase the use of a compromised key, and remove trust
in it.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates ENG-1848
These RPCs will be used to power the future 'tailscale lock remove' default behavior
of resigning signatures for which trust is about to be removed.
Signed-off-by: Tom DNetto <tom@tailscale.com>
With https://github.com/tailscale/corp/commit/a42a594bb311686197b64d6389524920a2b07b2a, iOS uses netstack and
hence there are no longer any platforms which use the legacy MagicDNS path. As such, we remove it.
We also normalize the limit for max in-flight DNS queries on iOS (it was 64, now its 256 as per other platforms).
It was 64 for the sake of being cautious about memory, but now we have 50Mb (iOS-15 and greater) instead of 15Mb
so we have the spare headroom.
Signed-off-by: Tom DNetto <tom@tailscale.com>
* Do not print the status at the end of a successful operation
* Ensure the key of the current node is actually trusted to make these changes
Signed-off-by: Tom DNetto <tom@tailscale.com>
Previously, `TAILSCALE_USE_WIP_CODE` was needed to hit a bunch of the TKA paths. With
this change:
- Enablement codepaths (NetworkLockInit) and initialization codepaths (tkaBootstrapFromGenesisLocked via tkaSyncIfNeeded)
require either the WIP envknob or CapabilityTailnetLockAlpha.
- Normal operation codepaths (tkaSyncIfNeeded, tkaFilterNetmapLocked) require TKA to be initialized, or either-or the
envknob / capability.
- Auxillary commands (ie: changing tka keys) require TKA to be initialized.
The end result is that it shouldn't be possible to initialize TKA (or subsequently use any of its features) without being
sent the capability or setting the envknob on tailscaled yourself.
I've also pulled out a bunch of unnecessary checks for CanSupportNetworkLock().
Signed-off-by: Tom DNetto <tom@tailscale.com>
This commit implements `tailscale lock log [--limit N]`, which displays an ordered list
of changes to network-lock state in a manner familiar to `git log`.
Signed-off-by: Tom DNetto <tom@tailscale.com>
By always firing off a sync after enablement, the control plane should know the node's TKA head
at all times.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Found by tests in another repo. TKA code wasn't always checking enough to be sure a node-key was set for the current state.
Signed-off-by: Tom DNetto <tom@tailscale.com>
* Plumb disablement values through some of the internals of TKA enablement.
* Transmit the node's TKA hash at the end of sync so the control plane understands each node's head.
* Implement /machine/tka/disable RPC to actuate disablement on the control plane.
There is a partner PR for the control server I'll send shortly.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Duplicating this at each layer doesnt make any sense, and is another
invariant where things could go wrong.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Running corp/ipn#TestNetworkLockE2E has a 1/300 chance of failing, and
deskchecking suggests thats whats happening are two netmaps are racing each
other to be processed through tkaSyncIfNeededLocked. This happens in the
first place because we release b.mu during network RPCs.
To fix this, we make the tka sync logic an exclusive section, so two
netmaps will need to wait for tka sync to complete serially (which is what
we would want anyway, as the second run through probably wont need to
sync).
Signed-off-by: Tom DNetto <tom@tailscale.com>
* tka.State.staticValidateCheckpoint could call methods on a contained key prior to calling StaticValidate on that key
* Remove broken backoff / RPC retry logic from tka methods in ipn/ipnlocal, to be fixed at a later time
* Fix NetworkLockModify() which would attempt to take b.mu twice and deadlock, remove now-unused dependence on netmap
* Add methods on ipnlocal.LocalBackend to be used in integration tests
* Use TAILSCALE_USE_WIP_CODE as the feature flag so it can be manipulated in tests
Signed-off-by: Tom DNetto <tom@tailscale.com>
This change masks the bitspace used when setting and querying the fwmark on packets. This allows
tailscaled to play nicer with other networking software on the host, assuming the other networking
software is also using fwmarks & a different mask.
IPTables / mark module has always supported masks, so this is safe on the netfilter front.
However, busybox only gained support for parsing + setting masks in 1.33.0, so we make sure we
arent such a version before we add the "/<mask>" syntax to an ip rule command.
Signed-off-by: Tom DNetto <tom@tailscale.com>
This will be needed to support preauth-keys with network lock in the future,
so getting the core mechanics out of the way now.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates #5435
Based on the discussion in #5435, we can better support transactional data models
by making the underlying storage layer a parameter (which can be specialized for
the request) rather than a long-lived member of Authority.
Now that Authority is just an instantaneous snapshot of state, we can do things
like provide idempotent methods and make it cloneable, too.
Signed-off-by: Tom DNetto <tom@tailscale.com>
It doesn't make a ton of sense for disablement to be communicated as an AUM, because
any failure in the AUM or chain mechanism will mean disablement wont function.
Instead, tracking of the disablement secrets remains inside the state machine, but
actual disablement and communication of the disablement secret is done by the caller.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Needed to identify the node. A serverside-check the machine key (used
to authenticate the noise session) is that of the specified NodeID
ensures the authenticity of the request.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Following the pattern elsewhere, we create a new tka-specific types package for the types
that need to couple between the serialized structure types, and tka.
Signed-off-by: Tom DNetto <tom@tailscale.com>
- A network-lock key is generated if it doesn't already exist, and stored in the StateStore. The public component is communicated to control during registration.
- If TKA state exists on the filesystem, a tailnet key authority is initialized (but nothing is done with it for now).
Signed-off-by: Tom DNetto <tom@tailscale.com>
This PR implements the synchronization mechanics for TKA: generating a SyncOffer, processing a SyncOffer to find an intersection,
and computing the set of AUMs that should be transmitted to effect convergence.
This is the final PR implementing core mechanics for TKA.
Signed-off-by: Tom DNetto <tom@tailscale.com>
FS implements Chonk, and given the expected load characteristics (frequent use
of AUM() + ChildAUMs(), and infrequent use of Heads() + CommitVerifiedAUMs()), the
implementation avoids scanning the filesystem to service AUM() and ChildAUMs().
Signed-off-by: Tom DNetto <tom@tailscale.com>
Chonks are responsible for efficient storage of AUMs and other TKA state.
For testing/prototyping I've implemented an in-memory version, but once we
start to use this from tailscaled we'll need a file-based version.
Signed-off-by: Tom DNetto <tom@tailscale.com>
This is the first in a series of PRs implementing the internals for the
Tailnet Key Authority. This PR implements the AUM and Key types, which
are used by pretty much everything else. Future PRs:
- The State type & related machinery
- The Tailchonk (storage) type & implementation
- The Authority type and sync implementation
Signed-off-by: Tom DNetto <tom@tailscale.com>
Tom DNettoandTom
