Better VPN detection

[jimaek]

The current system of just asking external APIs about the probe's IP is too broken. Too many false positives.

• Old data
• Shared IPs
• NAT

We need something better. Maybe traceroute can work after all? But instead of analyzing hop hostnames we analyze latency and query hop IPs.

e.g. This is a container running in Poland with VPN to Germany.

# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
 1  10.2.0.1 (10.2.0.1)  26.908 ms  26.772 ms  27.710 ms
 2  159.26.104.125 (159.26.104.125)  28.252 ms  27.504 ms  159.26.104.124 (159.26.104.124)  26.452 ms
 3  vl251.fra-itx7-core-2.cdn77.com (79.127.195.82)  26.230 ms  vl251.fra-itx7-core-1.cdn77.com (79.127.195.81)  29.711 ms  vl251.fra-itx7-core-2.cdn77.com (79.127.195.82)  27.211 ms
 4  vl1101.fra-eq5-edge-1.cdn77.com (185.229.188.13)  27.674 ms  28.394 ms  27.819 ms
 5  cloudflare-fra.cdn77.com (45.134.215.7)  28.950 ms  28.388 ms  27.600 ms
 6  162.158.84.1 (162.158.84.1)  28.593 ms  162.158.84.187 (162.158.84.187)  28.082 ms  162.158.84.161 (162.158.84.161)  29.661 ms
 7  162.158.84.209 (162.158.84.209)  52.938 ms  one.one.one.one (1.1.1.1)  27.293 ms  28.745 ms

1. First hop has way too high latency. We could use that. But there are networks that would not report data for the first hop. So if its present and high it could be a +1 to being a VPN. If its missing then we test the second hop and do the same logic.
2. If we query the first available public IP, hop 2, it's accurately marked as a VPN

{"as":{"number":208172,"organization":"Proton AG"},"ip":"159.26.104.124","location":{"country":"EU"},"organization":"PV-SL-HOSTED-Frankfurt-Network","risks":["TUNNEL"],"tunnels":[{"anonymous":true,"operator":"PROTON_VPN","type":"VPN"}]}

This could be another +1 to being a VPN.
3. We could also query the probe IP and if its a VPN then +1.

At the end if a probe gets 2 points its blocked. This way just the probe IP being marked as a VPN wont block it.

[MartinKolarik]

Wouldn't the second hop usually be the same IP we see as the probe IP?

[jimaek]

Not really. Depends on the network. And I dont think it would ever be the probe IP, thats the public IP of the device, the first hop is the router, next is the next router... So it would never hit itself

# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.301 ms  0.266 ms  0.254 ms
 2  192.168.0.1 (192.168.0.1)  0.524 ms  0.701 ms  0.832 ms
 3  89-67-4-1.dynamic.play.pl (89.67.4.1)  3.501 ms  3.488 ms  3.477 ms
...

# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  100.91.238.65 (100.91.238.65)  2.574 ms  2.545 ms  2.525 ms
 2  core21.fsn1.hetzner.com (213.239.227.229)  1.840 ms  1.870 ms core22.fsn1.hetzner.com (213.239.227.177)  3.048 ms
 3  core1.fra.hetzner.com (213.239.224.70)  4.920 ms core4.fra.hetzner.com (213.239.224.106)  4.886 ms core0.fra.hetzner.com (213.239.224.10)  6.052 ms

[jimaek]

I'm not 100% certain. But wouldn't the first hop through a VPN always be a private IP? The router of the VPN server.
A local router with latency higher than 3ms would most likely be a VPN

[MartinKolarik]

I'm not 100% certain. But wouldn't the first hop through a VPN always be a private IP? The router of the VPN server.
A local router with latency higher than 3ms would most likely be a VPN

Maybe, but 3 ms is likely too low. Some ISPs also have multiple of their routers with private IPs on the way before they reach the public internet.

[jimaek]

Yeah maybe not 3. But definetely if over 10ms. Probably lower since I doubt there are wifi based probes that we need to take into account.

[jimaek]

Note that satellite internet has a high 2nd hop, but still low first https://globalping.io/?measurement=2fgJF1QLOBcntvPQt0001zNnU

Although it's not guaranteed to have the value. So we need to use a points system, where e.g. high first hop would be +2.