Make proxy routing logic reusable#18370
Merged
rosstimothy merged 3 commits intomasterfrom Nov 18, 2022
Merged
Conversation
cb6423f to
51a0977
Compare
Contributor
Author
|
friendly ping @alistanis @fspmarshall |
fspmarshall
approved these changes
Nov 16, 2022
bf91ea2 to
140f822
Compare
zmb3
approved these changes
Nov 18, 2022
Collaborator
There was a problem hiding this comment.
I thought you didn't like doing this in init?
(I actually prefer it this way, FWIW)
Contributor
Author
There was a problem hiding this comment.
Lesser or two evils. Doing it on every proxy subsystem request seemed a bit excessive.
teleport/lib/srv/regular/proxy.go
Lines 192 to 196 in 9679315
Routing logic existed within an unexported handler of ssh subsystem requests, which prevented it from being reused by other components within the proxy, like the webapi server. This causes significant latency issues for web sessions because the web apiserver is required to dial the proxy ssh server to determine how to route to the host. Since the web apiserver and the proxy ssh server exist in the same process this is an entirely unnecesarry step that could be avoided if the routing and ability to established connections were shared throughout the proxy. A new `proxy.Router` object is introduced which contains all the logic that used to exist in `regular.proxySubsys` for determining how to connect to servers and clusters. All routing within the `regular.proxySubsys` now leverages the `proxy.Router` to dial the target. This is step 1 in addressing #15167. Now that the `proxy.Router` exists `web.APIServer` will be able to make use of it to avoid dialing the same process to establish connections.
140f822 to
a278ef2
Compare
Contributor
|
@rosstimothy See the table below for backport results.
|
rosstimothy
added a commit
that referenced
this pull request
Nov 18, 2022
Routing logic existed within an unexported handler of ssh subsystem requests, which prevented it from being reused by other components within the proxy, like the webapi server. This causes significant latency issues for web sessions because the web apiserver is required to dial the proxy ssh server to determine how to route to the host. Since the web apiserver and the proxy ssh server exist in the same process this is an entirely unnecesarry step that could be avoided if the routing and ability to established connections were shared throughout the proxy. A new `proxy.Router` object is introduced which contains all the logic that used to exist in `regular.proxySubsys` for determining how to connect to servers and clusters. All routing within the `regular.proxySubsys` now leverages the `proxy.Router` to dial the target. This is step 1 in addressing #15167. Now that the `proxy.Router` exists `web.APIServer` will be able to make use of it to avoid dialing the same process to establish connections.
rosstimothy
added a commit
that referenced
this pull request
Nov 21, 2022
Routing logic existed within an unexported handler of ssh subsystem requests, which prevented it from being reused by other components within the proxy, like the webapi server. This causes significant latency issues for web sessions because the web apiserver is required to dial the proxy ssh server to determine how to route to the host. Since the web apiserver and the proxy ssh server exist in the same process this is an entirely unnecesarry step that could be avoided if the routing and ability to established connections were shared throughout the proxy. A new `proxy.Router` object is introduced which contains all the logic that used to exist in `regular.proxySubsys` for determining how to connect to servers and clusters. All routing within the `regular.proxySubsys` now leverages the `proxy.Router` to dial the target. This is step 1 in addressing #15167. Now that the `proxy.Router` exists `web.APIServer` will be able to make use of it to avoid dialing the same process to establish connections.
rosstimothy
added a commit
that referenced
this pull request
Nov 30, 2022
* create package to contain proxy peering code * Refactor proxy routing logic into a reusable object Routing logic existed within an unexported handler of ssh subsystem requests, which prevented it from being reused by other components within the proxy, like the webapi server. This causes significant latency issues for web sessions because the web apiserver is required to dial the proxy ssh server to determine how to route to the host. Since the web apiserver and the proxy ssh server exist in the same process this is an entirely unnecesarry step that could be avoided if the routing and ability to established connections were shared throughout the proxy. A new `proxy.Router` object is introduced which contains all the logic that used to exist in `regular.proxySubsys` for determining how to connect to servers and clusters. All routing within the `regular.proxySubsys` now leverages the `proxy.Router` to dial the target. This is step 1 in addressing #15167. Now that the `proxy.Router` exists `web.APIServer` will be able to make use of it to avoid dialing the same process to establish connections.
This was referenced Nov 30, 2022
rosstimothy
added a commit
that referenced
this pull request
Dec 6, 2022
* create package to contain proxy peering code * Refactor proxy routing logic into a reusable object Routing logic existed within an unexported handler of ssh subsystem requests, which prevented it from being reused by other components within the proxy, like the webapi server. This causes significant latency issues for web sessions because the web apiserver is required to dial the proxy ssh server to determine how to route to the host. Since the web apiserver and the proxy ssh server exist in the same process this is an entirely unnecesarry step that could be avoided if the routing and ability to established connections were shared throughout the proxy. A new `proxy.Router` object is introduced which contains all the logic that used to exist in `regular.proxySubsys` for determining how to connect to servers and clusters. All routing within the `regular.proxySubsys` now leverages the `proxy.Router` to dial the target. This is step 1 in addressing #15167. Now that the `proxy.Router` exists `web.APIServer` will be able to make use of it to avoid dialing the same process to establish connections.
rosstimothy
added a commit
that referenced
this pull request
Dec 6, 2022
* Make proxy routing logic reusable (#18370) * create package to contain proxy peering code * Refactor proxy routing logic into a reusable object Routing logic existed within an unexported handler of ssh subsystem requests, which prevented it from being reused by other components within the proxy, like the webapi server. This causes significant latency issues for web sessions because the web apiserver is required to dial the proxy ssh server to determine how to route to the host. Since the web apiserver and the proxy ssh server exist in the same process this is an entirely unnecesarry step that could be avoided if the routing and ability to established connections were shared throughout the proxy. A new `proxy.Router` object is introduced which contains all the logic that used to exist in `regular.proxySubsys` for determining how to connect to servers and clusters. All routing within the `regular.proxySubsys` now leverages the `proxy.Router` to dial the target. This is step 1 in addressing #15167. Now that the `proxy.Router` exists `web.APIServer` will be able to make use of it to avoid dialing the same process to establish connections. * Make session control logic reusable (#18565) Session control logic existed within `HandleNewConn` of `srv/regular.Server`. This prevented any of it from being used by other components that also needed to enforce session control. All the logic from within `HandleNewConn` was refactored to a new `srv.SessionController` object which the `regular.Server` now uses to perform session control. There were a few additional changes needed to accomadate that session control now exists outside the server and to make tests easier to write. Namely, altering `srv.ComputLockTargets` to not take a `Server` as a parameter and leveraging a clock within `services.SemaphoreLock`. This is step 2 in addressing #15167. Before the web apiserver can leverage the newly introduced proxy.Router and bypass making ssh connections to the proxy ssh server it needs to be able to perfrom session control.
rosstimothy
added a commit
that referenced
this pull request
Jan 12, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 16, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-actions Bot
pushed a commit
that referenced
this pull request
Jan 16, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-actions Bot
pushed a commit
that referenced
this pull request
Jan 16, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-actions Bot
pushed a commit
that referenced
this pull request
Jan 16, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-actions Bot
pushed a commit
that referenced
this pull request
Jan 16, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 19, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 19, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 19, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 19, 2024
During refactoring performed in #18370 the counter was moved but never used outside of registration. This restores incrementing the counter for dial attempts and improves error reporting in traces in the router.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Routing logic existed within an unexported handler of ssh subsystem
requests, which prevented it from being reused by other components
within the proxy, like the webapi server. This causes significant
latency issues for web sessions because the web apiserver is required
to dial the proxy ssh server to determine how to route to the host.
Since the web apiserver and the proxy ssh server exist in the same
process this is an entirely unnecesarry step that could be avoided
if the routing and ability to established connections were shared
throughout the proxy.
A new
proxy.Routerobject is introduced which contains all thelogic that used to exist in
regular.proxySubsysfor determininghow to connect to servers and clusters. All routing within the
regular.proxySubsysnow leverages theproxy.Routerto dialthe target.
This is step 1 in addressing #15167. Now that the
proxy.Routerexists
web.APIServerwill be able to make use of it to avoiddialing the same process to establish connections.
Note to reviewers:
This PR will be easier to review commit by commit as the first commit refactors
lib/proxyso that all proxy peering code resides inlib/proxy/peer, which adds a bit of noise, but ultimately makeslib/proxya bit tidier. The second commit addsproxy.Router, replaces the existing logic withinregular.proxySubsysto use it, and updates all initializations ofregular.Serverwhich were supplying theSetProxyModeoption to pass in aproxy.Router.