Directing non-allowed CONNECT ports directly to destination closes #3684 #3686
Conversation
| FrontedServers []*FrontedServerInfo | ||
| ChainedServers map[string]*ChainedServerInfo | ||
| MasqueradeSets map[string][]*fronted.Masquerade | ||
| ProxiedCONNECTPorts []int |
There was a problem hiding this comment.
I made these ports part of the configuration so that we can quickly change them if we decide to add some.
|
cc: @myleshorton |
| // Android | ||
| 5228, 5229, | ||
| // Google Hangouts (see https://support.google.com/a/answer/1279090?hl=en) | ||
| 19302, 19303, 19304, 19305, 19306, 19307, 19308, 19309, |
There was a problem hiding this comment.
This all looks good @oxtoacart. I'm wondering here about UDP, and this is also a question for @xiam and @atavism. Basically, udpgw will handle all UDP traffic not just DNS, correct? So in this case, for example, a users' phone sends UDP traffic destined for Google on port 19302. Will the local client successfully tunnel all that traffic over TCP and then HTTP CONNECT to hit the local udpgw server on 127.0.0.1 on the proxies? And then udpgw will successfully ferry traffic in both directions for the duration of the call? Does that sound right? Does anyone know if that's actually what happens in practice in addition to in theory? Any idea if udpgw can scale to handle significant numbers of calls if a lot of users started doing this?
Just wanted to walk through that together, as it's one of the more complex and less obvious parts of our architecture!
There was a problem hiding this comment.
Interesting question. I think your description of what should happen is correct. I don't know the performance characteristics of udpgw.
There was a problem hiding this comment.
I partly asked because I think ports 19302, 19303, and 19304 are UDP-only. I think we want to include them here for the above reason, but I just want to synchronize our mental maps of how all this works!
There was a problem hiding this comment.
Oh, good point. For the UDP-only ports, we don't actually care about the port number because what we're proxying is actually the udpgw connection, which is on a different port. In theory, it shouldn't be hard to add udp support directly to Lantern, we mostly just need to stop hardcoding the "tcp" protocol everywhere and add a custom header to our CONNECT request that indicates the protocol :)
There was a problem hiding this comment.
Actually, take that back. I bet it's not that easy, with UDP being connectionless.
|
OK LGTM @oxtoacart! |
Directing non-allowed CONNECT ports directly to destination closes #3684
No description provided.