Support for forwarding traffic over an upstream proxy server

[krlvm]

Support for forwarding traffic over an upstream proxy server

[krlvm]

@DRSDavidSoft I have a good news, I've built a preview version with support of this feature.
Please, tell how it works for you.
PowerTunnel-v1.9-preview.zip

[DRSDavidSoft]

@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!

[DRSDavidSoft]

@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?

[krlvm]

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 decided to resolve it only once and then give the already cached result, but this can cause problems if the entered address is URL and periodically changes its IP address (which is rare, but still).
So I'm thinking of enabling caching by default.

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).

[DRSDavidSoft]

@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. 127.0.0.1 or 192.168.1.100 ) is set.

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.

So I'm thinking of enabling caching by default.

That's a good idea, I believe in most cases it's better to resolve the address only once.

 

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.

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.

[DRSDavidSoft]

As you know, PowerTunnel uses LittleProxy internally

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

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:

• conditional domain forwarding:
  based on domain type, either apply DPI circumvention utilities, forward the request, do both, or do neither and let the request go through directly
• support HTTPS proxying:
  allow the upstream proxy to be an SSL connection
• use encrypted DNS (DoH) alongside proxying

[krlvm]

Yes, you understood it correctly.
I've enabled it by default and made its description more clear as you've proposed.
Pull requests are highly appreciated.

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:
PowerTunnel-v1.9-preview2.zip

[krlvm]

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:

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.
This was just a small advertisement and it is not related to PowerTunnel, so I'm not going to get rid of proxy server :)

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.

[DRSDavidSoft]

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 ListView with checkboxes, the same as you did for "Excluded applications" and "Allowed applications".

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:

• blocked domains (by the government)
• disallowed access (e.g. by sanctions)
• whitelist (known good domains that are outside the country)
• intranet domains (domains that are inside the country)
• blocked by the user (e.g. ads, tracking, malware, etc)

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.

[krlvm]

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.
I also don't think that using a ListView for government blocked sites will be convenient, because, for example, we have more than 600 thousand websites blocked in Russia IIRC.