-
Notifications
You must be signed in to change notification settings - Fork 85
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
Support for forwarding traffic over an upstream proxy server #42
Comments
@DRSDavidSoft I have a good news, I've built a preview version with support of this feature. |
@krlvm Wow, thanks for the implementation, that was fast! The upstream proxying works awesome, I'm going to test out the DPI bypassing features with the upstream proxying. What does the "Cache upstream proxy address" do, though? Can you please explain? |
As you know, PowerTunnel uses LittleProxy internally, and it's designed in such a way that it tries to resolve address of the upstream proxy server on every connection, which, of course, takes time, memory and increases the load on the CPU, albeit a little, especially if the address that user provided in settings is already is IP address (it support URL too). I agree that I had to write a better documentation, but sometimes I don't have enough time, sometimes I'm afraid to spend time writing something unreadable or hard to read, because English is not my primary language, to be honest. In addition to that, I've already done proxy authorization, so it will be available in the stable release. A small advertisement, for those who need proxy authorization support for TunProxy for commercial purposes and it got here:PowerTunnel forwards requests to upstream proxy not directly, i.e. firstly requests come to the local proxy server, and then to the upstream, which slightly reduces performance and consumes a little more battery power, so it's not the best way to utilize TunProxy if you need proxy authorization support. I'm ready for offers regarding the TunProxy edition with direct support for authorization on the proxy server (it's already done). |
@krlvm Oh, I understand now, it is useful to turn off resolve cache in situations where the IP address of the domain name changes, e.g. in a DDNS scenario. I think it's best to leave it on for the domain addresses that always resolve to a permanent IP address, or when a direct IP address (e.g. For one of my domains, I use DDNS with an expiry date of TTL set to 60 seconds; so if I was to use that for the upstream proxy settings, I would leave the option turned off. Nevertheless, I made a suggestion here that I think would be more verbose and clear. "Improves performance" is unclear here and doesn't make sense, as the traffic and bandwidth are untouched, only a little bit of CPU (and network) is consumed when caching is off.
That's a good idea, I believe in most cases it's better to resolve the address only once.
Don't worry, I'm sure the documentation can be improved bit by bit, you don't have to rush it. English isn't my first language but I believe you're doing fine with the stings that already have been defined in the project. As a sidenote, I can submit PRs to make them a bit more clear if it's fine with you. |
While this is true for the most part, I believe using LittleProxy + TunProxy has its own benefits, since you can now implement the following features that would not be possible if TunProxy was directly used:
|
Yes, you understood it correctly. This is the latest v1.9 preview version, it includes authorization support and slightly optimized upstream proxy support in general, I'm going to push it to production tomorrow if I will not find serious issues: |
@krlvm Everything works wonderfully, thank you for adding this feature 😃 P.S. The automatic restarting (instead of stopping and starting) on changing the settings is also a welcome update! |
You are right about something, but if you want to start a commercial anonymizer business without a real VPN server and only when a proxy server (they're usually cheaper IIRC), this combination will be unforgivably slow, which can be solved by removing LittleProxy from the chain. By the way, I've written the algorithm which applies DPI tricks conditionally, but I still not pushed it to production because I cannot think of the most convenient option for editing the list of blocked sites, expect loading it from a URL each time. |
The method of updating via a URL is convenient, but I propose using a With that being said, ...I also propose making another repository for the domains lists, as different countries block different domains, and I believe it'd be beneficial to be able to send a pull request to that repository. Maybe use a `Spinner` (Drop-down) to be able to select different pre-defined domains list for different countries (like how you can select different DNS providers, or select "Custom DNS provider" and type in your own).Currently, I'm collecting the following lists for my projects:
Not all of these lists are applicable to all countries (e.g. Russia, China, Iran, etc) -- but many domains might be shared between the lists. |
I don't think I will be able to maintain a repository with these lists, but I know there's several websites that provides this information. |
As on the purpose of using PowerTunnel with an upstream proxy, the problem with using only
TunProxy
is that it doesn't have the DNS-over-HTTPS feature and a nice GUI with all the options that you've implemented in PowerTunnel (e.g. quick connect button, while a solution like VPN Client Pro has that button). Plus, I don't have to use Intra alongside the actualTunProxy
to both use a proxy and encrypt the DNS (you cannot use multiple VPN connections in Android).The authorization support is also a nice feature, but what I really think is useful if you could implement it, would be HTTPS proxy support (proxy over SSL); e.q. using
https_proxy
directive in Squid proxy server. That way, the government cannot inspect the ongoing traffic, as it's always being encrypted. This is what the closed-source UPX Browser is using internally. I have also asked for this on a similar project called DPITunnel, which would be an awesome functionality to have.Additionally, if you could implement conditional forwarding using a list (kind of like how the government domains list exists), then we can apply DPI obfuscation methods (like
Host
header modifications or SNI modifications) on domains that can be bypassed that way; then forward everything else to the proxy server. I can confirm that some domains work with PowerTunnel's method, but several others need to be forwarded to the proxy server.P.S. Alternatively, instead of HTTPS proxy, an HTTP proxy over Chisel can be used, which is awesome since it can work over Cloudflare and similar services. There's already socks support for chisel -- but I believe the HTTP proxy is superior in this case.
Sorry for the long comment!
Originally posted by @DRSDavidSoft in #23 (comment)
The text was updated successfully, but these errors were encountered: