qdm12 / gluetun

VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.
https://hub.docker.com/r/qmcgaw/gluetun
MIT License
7.39k stars 349 forks source link

Feature request: Add support for ProtonVPN to identify and choose servers based upon subscription tier and/or feature set. #1103

Open DiamondPrecisionComputing opened 2 years ago

DiamondPrecisionComputing commented 2 years ago

What's the feature 🧐

I considered hijacking #1076 but decided that this might be a larger ask than a single feature.

The issue is that not all paid ProtonVPN servers support P2P. (By default, all paid servers that support P2P also support port forwarding.) Proton provides a server list that tells you what servers support P2P but, in their infinite wisdom, does not document what keys and values in their API determine what the server supports. (It should probably be noted that their free servers support neither P2P nor port forwarding.)

Updating the worker that pulls and parses the JSON data from Proton's API probably shouldn't be that difficult. But, the option to let end users add variables to specify which features they require and then picking a server based on that criteria is a significantly larger ask.

Ultimately, I can see these features being useful for some. Feel free to prioritize based upon which features are more widely used, or reject all together if the demand is not there. :)

  1. Free vs paid tier A. This is already implemented but I believe it is based upon whether "free" is located in the server name. There is a key that dictates what tier the server is. Unsure if there will be significant change in data accuracy based upon parsing out the server name vs using the key-value pair in the API.

  2. Adblocker (NetShield) A. Gluetun offers adblocking built-in but implementing this requires no code change, only documentation updates. Simply add the suffix +f1 to the username for blocking malware only. Add suffix +f2 for blocking malware, ads, and trackers.

  3. P2P and Port Forwarding A. By default, paid servers that support P2P also support Port Forwarding. The Features key-pair determines if this is supported on the server. B. I don't believe Gluetun currently looks to verify P2P is supported on the selected server. This could cause issues when using clients that use the P2P protocol for communication as Gluetun would continue to error until the connection was unhealthy and then try another server.

  4. TOR A. Select servers auto tunnel traffic through a TOR relay. The Features key-pair determines if this is supported on the server.

  5. Secure Core/Multihop A. Gluetun already provides this as it looks to see if the entry and exit countries are different. The Features key-pair determines if this is supported on the server. Unsure if there will be significant change if code is updated of this.

A few additional notes.

I can provide the data needed to correctly identify the key-pair values for each of the features so no one else has to go down the rabbit hole. :)

Extra information and references

No response

qdm12 commented 1 month ago

This is already implemented but I believe it is based upon whether "free" is located in the server name. There is a key that dictates what tier the server is. Unsure if there will be significant change in data accuracy based upon parsing out the server name vs using the key-value pair in the API.

Indeed! Changed to use the tier value in 4c47b6f142a1bf860caa447bd45f5e5d09d35066 and there is definitely a difference!

By default, paid servers that support P2P also support Port Forwarding. The Features key-pair determines if this is supported on the server.

Is there a difference between P2P and Port forwarding??? I'm working on implementing an automatic filter if VPN_PORT_FORWARDING is turned on.

Finally, this adds filters cb99f90bb5eadd49fac87570c45f6603afecc701 (although P2P_ONLY might get removed if it's the same as PORT_FORWARD_ONLY).

kvanzuijlen commented 1 month ago

@kvanzuijlen are you aware of a difference between 'p2p' and 'port forwarding' in terms of feature for Protonvpn? I'm looking at #1103 (comment) and thinking of removing P2P_ONLY in favor of PORT_FORWARD_ONLY. Also are all p2p servers able to port forward?

EDIT: Please answer on #1103 πŸ˜‰ Since I don't get notified for this PR anymore

Hi @qdm12,

No, I'm not sure about either 😞.

ismay commented 1 month ago

Tough to say with certainty. From here: https://protonvpn.com/support/port-forwarding

Note that port forwarding is only permitted on our special P2P servers.

and from here: https://protonvpn.com/blog/port-forwarding/

[...] toggle the Port Forwarding switch on. You can then connect to one of our many P2P-enabled servers.

So at least all port forwarding servers are p2p servers. But I'm not sure if all p2p servers are port forwarding servers. It does seem like it to me, from messing with it in the ui. But not sure.

17ex commented 1 month ago

I'm pretty sure that every P2P server supports port forwarding, as stated here: https://protonvpn.com/support/port-forwarding-manual-setup/

All our P2P servers support port forwarding. P2P servers can be easily identified in our apps and on our VPN configuration download pages by a double-arrow icon.

So it seems like the P2P and port forwarding features are equivalent.

qdm12 commented 1 month ago

It does seem like it to me, from messing with it in the ui

Seems good enough validation to me πŸ˜„ I removed P2P_ONLY in favor of the existing PORT_FORWARD_ONLY in 5191f3558f03140442f7545f3b1aef1950529218.

5d75bbc86904d58924a400ea98faf38625ccdc4f adds 'auto-filtering' of servers to only use port forwarding compatible servers (equivalent to setting manually PORT_FORWARD_ONLY=on if port forwarding (VPN_PORT_FORWARDING=on) is requested. This applies to both ProtonVPN and Private Intenet Access for now, resolving 3.B.

qdm12 commented 1 month ago

Summary regarding original issue @DiamondPrecisionComputing

  1. Free tier filtering. Done in 4c47b6f142a1bf860caa447bd45f5e5d09d35066
  2. After writing some of the documentation for this, I'm realizing this is generally bad advice for users, privacy wise. You're already handing over your traffic to the VPN provider, you really don't want to hand it your plaintext DNS traffic, which they can actually link to you. Better to give it to Google from your VPN IP address, so it cannot be linked to you. Sure, they can say they don't collect your data, but they could and they could also profit from it. Just me 2 cents, so I won't advertise this 'bad' behavior of using the VPN provider DNS serverπŸ™
  3. Port forwarding servers: filter PORT_FORWARD_ONLY added in 4c47b6f142a1bf860caa447bd45f5e5d09d35066 + 5191f3558f03140442f7545f3b1aef1950529218 and automatic filtering added in 5d75bbc86904d58924a400ea98faf38625ccdc4f
  4. Tor filtering: added in 4c47b6f142a1bf860caa447bd45f5e5d09d35066 with TOR_ONLY
  5. Secure Core filtering: added in 4c47b6f142a1bf860caa447bd45f5e5d09d35066 with SECURE_CORE_ONLY

Regarding:

Secure Core servers only support Adblocker Normal servers only support Adblocker

Not sure what you mean here? Normal DNS traffic (plaintext, over TLS and over HTTPS) should work fine as well right?

TOR servers only support

Something missing at the end?

10Gbps local server connection

I'm not sure how to identify servers with this feature.

So this issue is more or less completed, just waiting for some final feedback.

ismay commented 1 month ago

I thought PORT_FORWARD_ONLY would be usable as soon as it landed on master, but it does not seem to be working for my gluetun setup for testing. Should I wait for a release?

qdm12 commented 1 month ago

Yep indeed, just fixed it in ceb6ff4ca424b62110533b257c1c2551dcb605be - it was because it had the older field p2p instead of the newer field port_forward in the servers.json data. Also the free detection was bugged, it's also fixed in that commit. (11pm here, see you tomorrow! πŸ˜„ πŸ’€)

ismay commented 1 month ago

Yep indeed, just fixed it in ceb6ff4 - it was because it had the older field p2p instead of the newer field port_forward in the servers.json data. Also the free detection was bugged, it's also fixed in that commit. (11pm here, see you tomorrow! πŸ˜„ πŸ’€)

Ah yeah, just tested it and works perfectly. Thanks!

jgeorgeson commented 2 weeks ago

Just found this issue after looking through qdm12/gluetun-wiki/49, I know this is a feature request and not an issue report, but the errors mentioned on 49 are not what I'm seeing.

I just updated to latest image today and am seeing errors with server filtering.

image

I was having trouble with my router's OpenVPN connection yesterday, too. So I reset my Proton credentials and downloaded a fresh ovpn config file, updated those in my router and that is back to working. So I'm trying to get gluetun back up and running now. Along with updating the credentials I also added the missing +pmp to the username for port forwarding, and tried 4 different cities (Chicago, Denver, Phoenix, and Washington), and changing from udp to tcp and back. I also tried going from latest to v3 image, no change.

I'm running on a Synology, DSM 7, with Container Manager compose configuration.

  gluetun:
    image: qmcgaw/gluetun:v3
    container_name: vpn-gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8090:8090/tcp # port for qbittorrent
      - 5802:5800/tcp # port for jdownloader
    volumes:
      - /volume1/docker/gluetun:/gluetun
    environment:
      - PUID=1034 #CHANGE_TO_YOUR_UID
      - PGID=65538 #CHANGE_TO_YOUR_GID
      - TZ=America/Chicago #CHANGE_TO_YOUR_TZ
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=openvpn #change as per wiki 
      - OPENVPN_USER=[redacted]+pmp
      - OPENVPN_PASSWORD=[redacted]
      - VPN_PORT_FORWARDING=on
      - SERVER_COUNTRIES=United States #Change based on the Wiki
      - SERVER_CITIES=Washington
      - HTTPPROXY=off #change to on if you wish to enable
      - SHADOWSOCKS=off #change to on if you wish to enable
      - FIREWALL_OUTBOUND_SUBNETS=172.20.0.0/16,192.168.1.0/24 #change this in line with your subnet see note on guide.
#      - FIREWALL_VPN_INPUT_PORTS=12345 #uncomment this line and change the port as per the note on the guide
      - UPDATER_PERIOD=24h
    network_mode: gluetunbridge
    labels:
      - com.centurylinklabs.watchtower.enable=false
    security_opt:
      - no-new-privileges:true
    restart: always
jgeorgeson commented 2 weeks ago

Rolling the docker image back to 3.38.1 is working.