search

jbweston / nord

An unofficial NordVPN client [DEPRECATED]
GNU General Public License v3.0
28 stars 4 forks source link

route traffic for VPN servers around VPN tunnel #23

Closed jbweston closed 6 years ago

jbweston commented 7 years ago

We would like to be able to get an accurate RTT to VPN servers, even when the VPN is up. This information could be used to automatically reconnect to a better server if the connected one becomes sluggish.

If we naively ping, then the ICMP packets will get routed through the VPN, which will give us inaccurate RTT for the purposes that we require.

The solution is to set up explicit routes so that traffic destined for the VPN servers themselves is not routed through the VPN. This can be achieved by placing lines at the end of the openvpn client config:

route <ip address> 255.255.255.255 net_gateway

These lines can be manually added to the config file that we get from the NordVPN web service before pass it off to OpenVPN.

jbweston commented 6 years ago

Not sure this is a good idea. People do not expect their VPN software to leak information!.

hapylestat commented 6 years ago

it's not good idea as re-connection means that current opened connections would be broken, what might cause streams and game connection to be broken.

I think, if connections lags it may be not VPN issue but user internet connection.

jbweston commented 6 years ago

it's not good idea as re-connection means that current opened connections would be broken, what my cause streams and game connection to be broken.

I am unsure what you mean. AFAIK if I add the config route <ip address of a nordVPN server> ... net_gateway this will only affect traffic that is destined for the VPN server itself. Traffic for other places (the "streams and game connections" that you mention) will still go through the default route, via the VPN.

I think, if connections lags it may be not VPN issue but user internet connection.

This is a correct statement, but I'm not sure why it is relevant in the context of this issue.

hapylestat commented 6 years ago

well, to be clear here - route to vpn server external ip would be always around vpn tunnel, or you would be not able to connect to it and keep connection opened. So honestly, i don't understand this task at all

jbweston commented 6 years ago

route to vpn server external ip would be always around vpn tunnel, or you would be not able to connect to it and keep connection opened.

My understanding is that after the VPN tunnel is established, OpenVPN modifies the routing table so that the default route passes through the VPN interface. This would mean that sending a packet to another of Nord's servers whilst the VPN is up would result in the packet being routed via the VPN.

It may be that we would want to, while the VPN is up, monitor RTT (as well as other metrics) from other Nord servers, so that if the server we have the VPN connection comes under a high load we could close the VPN connection to it, and establish a new one with a "better" server.

As it stands, because packets to the other Nord servers would be routed via the VPN, the reported RTT would not be a good number to compare for the purposes of determining which server would be "best" to connect to next.

Does that make sense?

hapylestat commented 6 years ago

why not use https://nordvpn.com/api/server/stats to check server load?

RTT makes sense at start, to check every server RTT, which may depend on your connection location and arrange them by RTT and Server load params.

it still bad idea to add N additional routes, how much NordVPN have servers?

jbweston commented 6 years ago

RTT makes sense at start, to check every server RTT, which may depend on your connection location and arrange them by RTT and Server load params.

We already do this on initial connection. It seems reasonable to assume that the RTT will not change much (unless we take a drastically different route through the internet, but we shall ignore this) and that the only factor that will affect server performance is the stats.

Thanks for the discussion! I will close this issue now that it becomes obvious that it's not going to be useful.