-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
support federation queries through http connect proxy #9306
Conversation
@clokep I'd like your feedback here, some notes:
|
I didn't look in detail yet, but a quick look makes it look reasonable. Is this only HTTPS proxy support? (No HTTP proxy support?) I've set the review flag so that someone can provide feedback! |
This is https only (target server is on https, not the proxy server like #9090) because I was under the impression that federation traffic requires a tls connection anyway. (I should be easy enough to pass through the http_proxy as well, if that is necessary for some reason.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- This has been running in production on an instance of synapse that only supports outgoing connections via a proxy. So I'm somewhat certain that in general it does the correct thing.
Awesome news! I know that there's interest by others in running with this too!
- It obviously still needs tests. I didn't actually look into that yet.
Yeah...it is rather unfortunate that the federation client is separate from the other HTTP client, but I don't think fixing that is trivial.
- this doesn't attempt to tackle the fact that the blacklisting should probably be only happening at the proxy instead of in synapse. I think this can be solved independently though.
I think non-federation requests somewhat have the same issue right now, so I don't see this as a problem to solve here.
- From the will not be used for list from Support for routing outbound HTTP requests via a proxy #6239 this only adds fed traffic as there was no immediate need for the other things on that list (in fact adding some of those would need Support for proxy exceptions (e.g. NO_PROXY env var) #9088 to be solved)
Ideally we would eventually add proxy support for all of these locations, I think. But not 100% sure. This fixes #8660, might be worth filing an issue with the remaining places we don't use a proxy?
- This might be solving Support proxy server for outbound federation #8859, though the reasoning in that issue is currently not clear to me (ssl offloading vs. us needed that just for connectivity to other servers)
This solves #8660, which I've added to the description (#8859 was marked as duplicate of #8660).
- The thing I'm unsure about is how to best introduce this: It changes existing functionality if you use a proxy server for anything... but on the other hand introducing more (nonstandard) env vars or config options for this doesn't seem satisfactory either. Maybe add this together with Support for proxy exceptions (e.g. NO_PROXY env var) #9088 and pointing it out in the upgrading notes would be enough?
For #6239 it seems we just turned it on, I don't think we would do something different here. I suspect documenting it in the upgrade notes should be enough.
Thanks for starting this @Bubu! This would also be really useful for me and I'm running a similar patch to support a setup where outbound traffic flows through an egress proxy host. A follow up that I would also want would be to support the |
@Bubu based on the conversation above...do you think this is ready for more feedback or what's the next step? |
### Changes proposed in this PR - Add support for the `no_proxy` and `NO_PROXY` environment variables - Internally rely on urllib's [`proxy_bypass_environment`](https://github.com/python/cpython/blob/bdb941be423bde8b02a5695ccf51c303d6204bed/Lib/urllib/request.py#L2519) - Extract env variables using urllib's `getproxies`/[`getproxies_environment`](https://github.com/python/cpython/blob/bdb941be423bde8b02a5695ccf51c303d6204bed/Lib/urllib/request.py#L2488) which supports lowercase + uppercase, preferring lowercase, except for `HTTP_PROXY` in a CGI environment This does contain behaviour changes for consumers so making sure these are called out: - `no_proxy`/`NO_PROXY` is now respected - lowercase `https_proxy` is now allowed and taken over `HTTPS_PROXY` Related to #9306 which also uses `ProxyAgent` Signed-off-by: Timothy Leung tim95@hotmail.co.uk
1fb936c
to
960e8a9
Compare
@Bubu is this ready for review, or are you still working on it? It looks like a couple of conflicts have cropped up. |
I also have a problem with the federation traffic not going through the proxy. Can anyone point me to a patch that I can apply to 1.31.0 ? |
Can be specified by HTTPS_PROXY env var. pass unfiltered reactor to federation agent for proxy support Signed-off-by: Marcus Hoffmann <bubu@bubu1.eu>
This is used for proxy authentication, we just continue our "solution" of copying code from proxyagent -> matrix_federation_agent.
17d183c
to
ef8792a
Compare
@richvdh I resolved the conflicts. In general review is appreciated though it still lacks functioning tests. (I currently don't have time to look into writing those, though potentially @chrisguida wanted to look at that.) |
If anyone else wants to take on writing the test so that this can be merged, please go ahead. I've run this code and it works, but figuring out how to write the test properly will most likely take me a while since I'm not too familiar with the testing framework. Otherwise I'll get to it when time permits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I don't really understand what's going on in this code. Please update the docstrings to help me follow it.
@@ -72,6 +76,7 @@ def __init__( | |||
tls_client_options_factory: Optional[FederationPolicyForHTTPS], | |||
user_agent: bytes, | |||
ip_blacklist: IPSet, | |||
proxy_reactor: Optional[ISynapseReactor] = None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add new params to the docstring (on the class, in this case). As well as making the code maintainable in future, it's important to help with review.
@@ -279,6 +279,7 @@ def __init__(self, hs, tls_client_options_factory): | |||
tls_client_options_factory, | |||
user_agent, | |||
hs.config.federation_ip_range_blacklist, | |||
proxy_reactor=hs.get_reactor(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given that we already pass the ip blacklist into MatrixFederationAgent
, why not move the construction of BlacklistingReactorWrapper
down to it, rather than having to pass in two reactors?
@@ -1,3 +1,4 @@ | |||
# -*- coding: utf-8 -*- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# -*- coding: utf-8 -*- |
This is no longer needed. See #9786
I will work on it after #10360 and #9119 is merged. |
I'm seeing uses of My main gripe with it is that |
I am not sure if it is useful to use the library only here. There is also a discussion about it there: #9119 (comment) |
Sure, sorry for not having the bandwidth to continue here :-(. And thanks for picking this up @dklimpel. |
Can be specified by HTTPS_PROXY env var.
pass unfiltered reactor to federation agent for proxy support
Signed-off-by: Marcus Hoffmann bubu@bubu1.eu
Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.Fixes #8660