Closed sadontsev closed 2 months ago
It looks like their desktop app might pick an api endpoint from the serverlist rather than using the fixed privateinternetaccess.com
one:
https://github.com/pia-foss/desktop/blob/master/daemon/src/metaserviceapibase.h
I wonder if thats something the container could do if needed. It looks like it still might need to access https://serverlist.piaservers.net/vpninfo/servers/v6
though to find an endpoint. I don't suppose thats also blocked?
It looks like their desktop app might pick an api endpoint from the serverlist rather than using the fixed
privateinternetaccess.com
one:https://github.com/pia-foss/desktop/blob/master/daemon/src/metaserviceapibase.h
I wonder if thats something the container could do if needed. It looks like it still might need to access
https://serverlist.piaservers.net/vpninfo/servers/v6
though to find an endpoint. I don't suppose thats also blocked?
Yes, good point. The server list (maybe being on a different host?) is reachable. I prepared a patch that seems to be "good enough" for now that overrides the auth script with a static token stored locally on the host (without refresh) and then the VPN can be connected. Surprisingly for me, I tried reconnecting the VPN today with the same token obtained on Sunday and it's still not expired.
I wonder if the tokens are permanent?
I wasn't able to find PIA API documentation myself to get an answer
I don't think I've ever noticed an auth token expiring before. My Docker install is only a few weeks old at the moment, but it looks like the initial tokens are still being re-used on container creation.
META_IP
and META_CN
env vars can be set to one of the 'meta' servers found in their server list (eg. META_IP=95.181.238.2
META_CN=bahamas404
), and doesn't need to be the same as the LOC
env var. META_PORT
doesn't need explicitly setting and defaults to 443, but it looks like 8080 might also be an option.If the server list is working as-is, then the env vars might only need setting on the initial run to generate the auth token, assuming /pia
is being stored as a persistent volume/mount.
I've built and tagged it as thrnz/docker-wireguard-pia:testing
on Docker hub if you're keen to test it out.
@thrnz amazing one :)
Works like Swiss watch:
Wed Jun 19 07:10:54 UTC 2024: Generating auth token
Fetching next-gen PIA server list via meta server: ip: 156.146.62.193, cn: zurich407, port: 443
Verified OK
Verified server list
Registering public key with PIA endpoint; id: swiss, cn: zurich407, ip: 156.146.62.207
Generating /etc/wireguard/wg0.conf
Using PIA DNS servers: 10.0.0.243,10.0.0.242
Port forwarding is available at this location
Successfully generated /etc/wireguard/wg0.conf
I specified both meta IP and CN
@thrnz is it something you would consider moving to master?
It's been merged and should be in the latest build on Docker Hub.
Hello everyone,
Could you suggest a solution to the PIA host being blocked by my ISP?
I see in the container logs:
I tried to call the token endpoint manually
https://www.privateinternetaccess.com/api/client/v2/token
And it's unreachable from my ISP but reachable first enabling PIA VPN on my Mac.