Skip to content
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

Consider banning VPNs #21

Closed
jimaek opened this issue Mar 16, 2022 · 3 comments · Fixed by #38
Closed

Consider banning VPNs #21

jimaek opened this issue Mar 16, 2022 · 3 comments · Fixed by #38
Assignees

Comments

@jimaek
Copy link
Member

jimaek commented Mar 16, 2022

How about we also block probes from connecting that have proxy_description=vpn and tor-* plus maybe proxy_type=anonymous,aol,blackberry,corporate,?
https://developer.fastly.com/reference/vcl/variables/geolocation/client-geo-proxy-description/
https://developer.fastly.com/reference/vcl/variables/geolocation/client-geo-proxy-type/

hosting example https://globalping-geoip.global.ssl.fastly.net/142.132.251.61

A probe hosted behind a VPN would only create problems. If the user is in China with the VPN server in Germany it would get registered in our system as a German probe. Then if someone tried to use the probe he would get 100ms latency to ping Germany from Germany.

@patrykcieszkowski
Copy link
Contributor

But that would mean we'll have to rely solely on fastly to obtain this data.

How about instead of attempting to verify whether probe's IP address is a commercial VPN or not, we run a quick ping query to a server closeby to their supposed geo? If they're using VPN - the ping would indicate that, and they could be exluced from the pool. It would also exclude any unstable connections.

@jimaek
Copy link
Member Author

jimaek commented Mar 16, 2022

I guess your way is more reliable but a lot more complicated. We would need a solid list of servers all around the world and an algorithm to calculate the correct latency we expect the probe to have.
We actually already have planned a benchmark to run during startup to test the probe for CPU resources and network stability.

I think starting with something simpler is better than nothing :) I actually don't worry about false positives, it's more likely to have false negatives which won't impact our users

@jimaek
Copy link
Member Author

jimaek commented Mar 21, 2022

I tested quite a few IPs and haven't any issues yet. If we implement this I don't think it will create any problems, it only might miss some VPNs but if that starts to become a problem we can just add a second solution on top of this one to catch stuff that this didn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants