Adds concurrent default-port detection to tsh
#6374
Conversation
|
@fspmarshall @xacrimon Can you two review? |
Addresses issue #4924 If a default Web Proxy port is not specified by the user, either via config or on the command line, `tsh` defaults to `3080`. Unfortunately `3080` is often blocked by firewalls, leading to an unacceptably long timeout for the user. This change adds an RFC8305-like default-port selection algorithm, that will try multiple ports on the supplied host concurrently and select the most reponsive address to use for Web Proxy traffic. I have included the standard HTTPS port (443) in the defaulut set, and this can be easily expanded if other good candidates come along. If the port selection fails for any reason, `tsh` reverts to the legacy behaviour of picking `3080` automatically.
| func raceRequest(ctx context.Context, cli *http.Client, addr string, waitgroup *sync.WaitGroup, results chan<- raceResult) { | ||
| defer waitgroup.Done() | ||
|
|
||
| target := fmt.Sprintf("https://%s/webapi/ping", addr) |
There was a problem hiding this comment.
Noticing this just now - proxy can run in insecure mode so https:// won't work.
There was a problem hiding this comment.
What is the solution to that? I could spawn separate http & https racers I suppose.
There was a problem hiding this comment.
... although the webclient is just going to plug whtever we find straight into an https URL anyway. See:
There was a problem hiding this comment.
Hmm this is a good point. I'm only superficially familiar with --insecure-no-tls flag but I wonder if it exists solely for scenarios where proxy runs behind a TLS-terminating load balancer so the actual public proxy endpoint clients connect to is still TLS (i.e. proxy in "insecure no TLS" mode is not supposed to be connected to directly). If that's the case, then it's ok to just use https. @webvictim or @russjones maybe, do you folks know?
There was a problem hiding this comment.
Your reasoning is correct - --insecure-no-tls disables the TLS part of Teleport's web listener and just makes it speak plain HTTP, but is only intended to be used for backend -> Teleport connections. tsh and Teleport agents joining the cluster will still be expecting to communicate over HTTPS - it's just that the HTTPS will be terminated in front of Teleport rather than inside it.
While we're on the topic, though, it's worth checking how the --insecure flag to tsh and Teleport agents works as that skips all TLS verification, but I'm unsure whether it also allows the use of an HTTP connection rather than HTTPS when combined with --insecure-no-tls on the web listener.
There was a problem hiding this comment.
As far as tsh is concerned, it blithely assumes https everywhere that I can see. There are at least half a dozen places in the webclient that have constants that start "https://".
|
@tcsc Is this ready to merge or are the test failures real? |
Co-authored-by: Nic Klaassen <nic@goteleport.com>
Addresses issue #4924
If a default Web Proxy port is not specified by the user, either via
config or on the command line,
tshdefaults to3080. Unfortunately3080is often blocked by firewalls, leading to an unacceptably longtimeout for the user.
This change adds an RFC8305-like default-port selection algorithm,
that will try multiple ports on the supplied host concurrently and
select the most reponsive address to use for Web Proxy traffic. I
have included the standard HTTPS port (443) in the defaulut set,
and this can be easily expanded if other good candidates come along.
If the port selection fails for any reason,
tshreverts to thelegacy behaviour of picking
3080automatically.