-
Notifications
You must be signed in to change notification settings - Fork 11.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.