Connectivity check can break routing in VPN setups

[josecv]

Describe the bug
When first connecting to a cluster, telepresence does a connectivity check to ensure that the cluster isn't already reachable. I assume this is in case of duplicate instances, or complex network stacks where one container spins up a telepresence connect for another. At any rate, some VPNs will route the traffic manager's IP address, to which the local telepresence is connecting for its connectivity check, and produce a result that makes it look like we're already connected to the cluster. The outcome of this is that telepresence makes no attempt to establish routing to the cluster, thinking it's already been configured. We need the connectivity check to be a bit more sophisticated to make sure it's not giving false positives simply because the routes already happen to be configured. That way, test-vpn will continue to work as a way for users to find conflicting routes and possibly reconfigure the VPN/cluster if needed; currently this bug prevents affected users from getting any meaningful output from test-vpn

To Reproduce
Unclear, but some VPNs clearly hit it.

Expected behavior
Telepresence should add the routes into the table

Versions (please complete the following information):

• Observed on v2.10.5

VPN-related bugs:
Bug breaks test-vpn unfortunately.