[Mashiro]

@deanhills

Another (new) note about the IP address(es) geolocation. Based on my previous post and what @fChk also mentioned I think that the IP address is geolocated correctly (actually) because the tunnel endpoint of this protected IP address space (your VPS IP) is at the Las Vegas, Nevada location / data center. You see this being even confirmed by the fact that the first hop from the traceroute is another IP address out of Las Vegas, Nevada. You also see that for some reason the traffic goes back to Phoenix, Arizona and from there on it goes its normal route.

Code: (Select All)

1  107.xxx.235.xxx (107.xxx.235.xxx)  0.983 ms  0.941 ms  1.082 ms
2  ae10.cr1-pnap-phx1-cl.phx1.serverhub.com (104.xxx.0.xxx)  34.438 ms  34.469 ms  34.468 ms
3  ae0.bb1-pnap-phx1.phx1.serverhub.com (104.xxx.0.xx)  0.886 ms  0.876 ms  0.855 ms
4  phx-b1-link.telia.net (62.xxx.54.xxx)  1.910 ms  1.932 ms  2.079 ms

(It wasn't necessary to censor any other IP address than the first hop and the last hop. Everything in between are core routers and exchanges at data centers.)

1st hop is most likely the core router or similar in Las Vegas going to 2nd hop in Phoenix at Serverhub (data center) where it is passing another Serverhub Phoenix router (hop 3) and then going to a local Phoenix bandwidth exchange hosted by Telia.net (hop 4). From there on it continues further through the US and etc over Germany (hop 9 through 13) before it seems to reach South Africa and continues there (hop 15).

So in light of their tunnel to protect the VPSs from attacks it rather seems to be correct that the IP space is geolocated to Las Vegas, Nevada as all their tunnels seem to end there and from there they get their Internet connection. Hence why Virmach keeps and will keep insisting and saying not to worry about the location. So why sites detect different locations still stays mostly like I said before: due to geolocation databases being inaccurate and / or multiple databases being used at different times and checks.


Another note about the traceroute as you mentioned it. The initator IP of the traceroute (your VPS) will never appear in the traceroute path. A traceroute always starts with the first hop that your machine reaches when it communicates with a network. That is usually the first router or a firewall. That is the 107.* IP address in Las Vegas, Nevada. So you will never see the IP address of the machine from where you started a traceroute or ping from unless you capture the network packets and analyze them (with Wireshark for example).


About the speed tests. You could use speedtest.net still if you really wanted but don't let it auto pick the location but rather pick a location in Arizona or around it manually. Additional speed tests you can do easily with for example the benchmark scripts. The speed tests there do basically the same as speedtest.net by downloading a big file and measuring the speed (no upload speed here though). As I explained before maybe a much more proper test would be a iperf test to a iperf server near to the VPS location.

There are a few public iperf3 servers available:
- https://iperf.cc/ (Multiple locations)
- https://speedtest.serverius.net/ (Netherlands)
- https://iperf.fr/iperf-servers.php (France)
- http://iperf.volia.net/ (Ukraine)

For example at https://speedtest.serverius.net/ you have instructions to perform a download and upload speed test using iperf3 to the Serverius iperf server. This server is hosted in the Netherlands though.

You could use the Fremont, CA server from https://iperf.cc/ for a test because that seems to be the closest server to your VPS location.

Download:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4 -R

Upload:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4

^ You have to install iperf3 on your VPS first before you can run these commands.

Alternatively you can of course even host your own iperf server and test your VPS against it for example.