Traffic from your machine (9.8.7.6) to VPS (4.3.2.1) will flow trough the previous, never changed, path.In this second case (replacing def-gw right after establishing VPN connection), your previous SSH connection will "hang", due to asymmetric routing: In this case you're tunneling ALL the outgoing IP traffic (with the exception of OpenVPN itself) within the VPN. IF remote OpenVPN server will push back some route, and expecially if VPS default-gateway will be replaced with 10.10.10.1 (remote OpenVPN endpoint), THEN you're having problems. In this case, the only traffic traversing the VPN is the one directed towards the remote OpenVPN Server (10.10.10.1) IF no route will be pushed from remote OpenVPN server to your local VPS, then nothing will change in term of routing, and your SSH connection will survive with no problems at all. as such, a new tun0 interface will be dinamically configured (let's suppose it will be assigned a 10.10.10.2 IP, with a 10.10.10.1 PTP).you launch an OpenVPN connection from your VPS 4.3.2.1.Now, with such an SSH connection established, let's suppose: Hence both hosts 4.3.2.1 and 9.8.7.6 can succesfully reach each other. In such a scenario, from your machine (let's suppose your machine is 9.8.7.6/24 with def-gw 9.8.7.254) you can successfully establish an SSH connection to 4.3.2.1. your VPS has not yet activated any OpenVPN connection hence there are no tun interface active.your VPS can access the Internet via a default-gateway 4.3.2.254.your VPS has a single ethernet interface, configured with IP address 4.3.2.1/24.
0 kommentar(er)
