Fix profiles and leave only P2P ones

[Forage]

Breaking change

The selection of country profiles is limited to 24 now (TCP+UDP)

Proposed change

This fixes #157.
All country profiles not designated as P2P supported have been removed in addition to that.

Fixes:
- remove user name
- replace `auth-user-pass` with `auth-user-pass /config/openvpn-credentials.txt`
- comment out up/down lines

Type of change

• [X] Bugfix (non-breaking change which fixes an issue)
• [ ] New provider (thank you!)
• [X] Updated provider (thank you!)
• [ ] New feature (which adds functionality to a provider script/repo usage)
• [ ] Breaking change (fix/feature causing existing functionality to break)

Additional information

• This PR fixes or closes issue: fixes #157

Checklist

• [X] The code change is tested and works locally.
• [X] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

• [ ] Documentation added/updated

[Forage]

Now with the country profiles limited to P2P profiles only, the use-case for server specific profiles, that @cacula did not see before, should become clear: there are server specific P2P profiles for countries that do not have country-wide P2P profiles (CA, DE, FR, UK, US). Users from those counties will not have something more close to them to choose from.

Different options:

1. Stick to only country-wide P2P profiles (current PR)
2. Have country-wide P2P profiles, plus server specific P2P ones for those countries that don't have them country-wide
3. Only have server specific P2P profiles (those of P2P country-wide as well)
4. Ignore provider P2P designations and include all profiles like before (server specific and country-wide)

Option 1 and 4 are the easiest to maintain. Sticking to P2P profiles only is, I think, important to play nice with the VPN provider. Server specific P2P profiles are a pain to maintain, since there's no "Download all P@P profiles" button. So option 2 could be considered a compromise and less of a hassle, despite it being less consistent.

[cacula]

i would suggest going with option 1 because

• easy to maintain
• easy to use: no need to choose a specific server that maybe overloaded when connecting
• only 5 countries missing
• no real disadvantages in choosing a country nearby @Forage thanks for the hint with exposed connection user - has been reset :)

[jsloan117]

What's the trouble with pulling all the configs like before? Since they provide a button to do that? Maybe other than maybe the number of them. To a degree, I like having options to use P2P or not depending on the use case, although I do see the merit of option 1 mainly due to the number of configs.

I just recently moved from VyprVPN to ProtonVPN, so don't have long-term XP w/ this.

Also this may be a bigger question than just ProtonVPN, but why are we removing the up/down script line? Since they help to prevent DNS leaks?

[Forage]

The problem is that many profiles are not supposed to be used for P2P, as indicated by Proton VPN, even though they might work. The profiles pulled in by this container are for the sole purpose of being used for P2P. By providing the non-P2P profiles anyway it could be seen as encouragement to abuse them.

Up/down needs to be removed because the container does not use resolv-conf if I recall correctly.

[jsloan117]

fair point :-). I believe I found the code round the up/down, its tunnelUp/down. more or less the same.

[haugene]

I'm not a ProtonVPN user but it seems that for most users here it's really nice to have country specific configs that are already filtered for being P2P compliant, given the nature of this container image.

About the auth-user-pass stuff it should work either way. By default we run this modification script to all configs before we run them and the default behavior will do the auth-user-pass substitution needed.

As for the up/down scripts that might actually be necessary to remove now :thinking: We used those signals previously to start the container, but now we use the route-up so they won't get overridden like before.

Either way, this change looks good to me. Merging :+1:

[Forage]

Thanks for the info and merge @haugene. All I know is that the container did not run for me after the previous PR. Must be the removal of the up/down lines that fixed it now if the auth line was automatically replaced already. In which case, it might be a good to add removal of the up/down to the clean-up script as well.

[haugene]

Yeah, I think so as well. It will probably affect others going forward as it's a very common option to have and we don't clean it as of today.

[mark-monteiro]

For those who now have a broken setup, I wrote a short guide on how to migrate to using a custom config file here: https://github.com/haugene/vpn-configs-contrib/issues/159#issuecomment-1320758800

[Radicitus]

Hey all! I understand that you removed a lot of the config files for countries that don't have only P2P servers for maintainability, however I believe this was a mistake.

I think those countries are actually the ones with the largest ProtonVPN customer bases which is why they have more of a variety of server options. The US alone has 511 servers and 7 more cities than any other country with no other country nearby to choose from. I think this change affects a lot of transmission users and we can't just revert back to an old version as we could in the past, as these are separate repos now.

[Forage]

I think those countries are actually the ones with the largest ProtonVPN customer bases which is why they have more of a variety of server options.

That's assuming that country had the largest user base of this container as well for the same reason, but there's no link nor actual statistic on that whatsoever.

Before this container existed you'd download from P2P servers from all over the world directly. Using a profile from a different country really won't reduce your speed that much now. And speed is not that critical anyway, otherwise you wouldn't be relying on torrents to begin with.

You've got your alternative, an external profile. Which puts the maintenance hassle in the user's hands. With some luck, for a single server profile of a single country, you'll last a long time.

[haugene]

This is an old discussion that keeps coming back for various provider config updates. Should we optimize for simplicity, stability, flexibility or even speed? And the answer is probably somewhere in between so there are many answers. That's part of the reason for splitting configs out as a separate repo making it much easier for anyone to make their own version and share it with those who view the config-world similarly. Configs are inherently unstable as any VPN provider can discontinue any server at any time, so at some point it will probably break and you need to choose a new server.

I'm still hoping to set up a CODEOWNER file per provider and distribute the ownership of these configs and then the maintainers for each provider can choose their strategy. I don't want to have a general rule across providers as I think it varies.

As for what you can do to have more control over your setup you can:

1. Mount a local config file like @mark-monteiro outlines in the comment he links to :point_up:
2. Fork this repository and upload the configs you want there, then set GITHUB_CONFIG_SOURCE_REPO=yourUserName/vpn-configs-contrib
3. You can actually revert back to a specific version @Radicitus. In this case you want the commit before this PR was merged which is a7e9a01 so you can set GITHUB_CONFIG_SOURCE_REVISION=a7e9a01 when running the main image and you will get that version of the configs.

EDIT:

4. Technically we actually support both at the same time as well (only p2p servers and a full listing). You can have sub-folders within the vpn provider folder. This way you can do OPENVPN_CONFIG=p2p/germany.ovpn or OPENVPN_CONFIG=all_configs/germany_server_2.ovpn. But there is still the burden of maintaining these, so it's up to the people who take on that to decide IMO.

[Forage]

...or step up as a maintainer of the ProtonVPN profiles. By that it means updating all of them regularly and not just a one-time PR. Without that dedication the profiles will disappear again when the next round of country-wide profile updates does come along again.

[jsloan117]

@Forage -- it sounds like you've used ProtonVPN for a long while now? If this is true, how often do they get updated that you or someone else here noticed, which forced the community to update them?

For context, I've just recently switched from VyprVPN to ProtonVPN, and the 2+yrs I used them I think it broke once because they changed something. I can't recall exactly what but it deff broke hard. That was before I created the script to automatically download the configs though.

[Radicitus]

@Forage @haugene Thanks for the valuable input guys, I appreciate it! Honestly, I wasn't even aware of some of the options you listed were available Haugene, as I didn't see them listed in the Docs last time I read through. Awesome stuff here man.

[hudsonpeden]

Does this mean all US based configs (even those that allow p2p) are no longer supported?

[jsloan117]

@hudsonpeden -- they are still supported by Proton. Their just not included by default in the repo. You can download configs you want and use them with the container.