On Mon, 5 May 2014 14:35:18 -0300 Daniel Bareiro <daniel-lis...@gmx.net> wrote:
> On Saturday, 19 April 2014 11:47:37 -0300, > Daniel Bareiro wrote: > > > I'm doing tests to simultaneously maintain two VPN links against PureVPN > > servers. As this is an external provider, I have no way to make changes > > in the configuration of VPN servers. > > > > The settings I'm using to set up each link are: > > > > ------------------------------------------------------------------------------------------------------------ > > # cat client.conf > > client > > dev tun > > proto tcp > > remote br1-ovpn.purevpn.net 80 > > persist-key > > persist-tun > > ca ca.crt > > tls-auth Wdc.key 1 > > cipher AES-256-CBC > > comp-lzo > > verb 3 > > mute 20 > > route-method exe > > route-delay 2 > > # route 0.0.0.0 0.0.0.0 > > float > > > > auth-user-pass auth.asc > > auth-retry interact > > ifconfig-nowarn > > > > status /var/log/openvpn-status.log > > log-append /var/log/openvpn.log > > ------------------------------------------------------------------------------------------------------------ > > # cat client2.conf > > client > > dev tun > > proto udp > > remote cl1-ovpn.purevpn.net 53 > > persist-key > > persist-tun > > ca ca.crt > > tls-auth Wdc.key 1 > > cipher AES-256-CBC > > comp-lzo > > verb 3 > > mute 20 > > route-method exe > > route-delay 2 > > # route 0.0.0.0 0.0.0.0 > > float > > > > auth-user-pass auth.asc > > auth-retry interact > > ifconfig-nowarn > > > > status /var/log/openvpn2-status.log > > log-append /var/log/openvpn2.log > > ------------------------------------------------------------------------------------------------------------ > > > > The two links are established, but when I do ping tests (with "-I tun1" > > and "-I tun2"), I have an answer by a single link. I think there should > > be a routing problem. > > > > When the connection is established using client.conf, these are the > > routing rules added by the server: > > > > Fri Apr 18 10:46:30 2014 /sbin/ip link set dev tun0 up mtu 1500 > > Fri Apr 18 10:46:30 2014 /sbin/ip addr add dev tun0 181.41.205.194/26 > > broadcast 181.41.205.255 > > Fri Apr 18 10:46:32 2014 /sbin/ip route add 181.41.198.225/32 via > > 162.252.86.177 > > Fri Apr 18 10:46:32 2014 /sbin/ip route add 0.0.0.0/1 via 181.41.205.193 > > Fri Apr 18 10:46:32 2014 /sbin/ip route add 128.0.0.0/1 via 181.41.205.193 > > Fri Apr 18 10:46:32 2014 /sbin/ip route add 0.0.0.0/0 via 181.41.205.193 > > > > When the connection is established using client2.conf, these are the > > routing rules added by the server: > > > > Fri Apr 18 10:49:39 2014 /sbin/ip link set dev tun1 up mtu 1500 > > Fri Apr 18 10:49:39 2014 /sbin/ip addr add dev tun1 179.61.208.135/26 > > broadcast 179.61.208.191 > > Fri Apr 18 10:49:41 2014 /sbin/ip route add 181.41.198.181/32 via > > 162.252.86.177 > > Fri Apr 18 10:49:41 2014 /sbin/ip route add 0.0.0.0/1 via 179.61.208.129 > > Fri Apr 18 10:49:41 2014 /sbin/ip route add 128.0.0.0/1 via 179.61.208.129 > > Fri Apr 18 10:49:41 2014 /sbin/ip route add 0.0.0.0/0 via 179.61.208.129 > > > > After reading this [1] document, I thought maybe after the two links are > > established, I could manually delete the rules added by the servers and > > add something like the following: > > > > ip route add 181.41.205.192/26 dev tun0 src 181.41.205.194/26 table T1 > > ip route add default via 181.41.205.193 table T1 > > ip route add 179.61.208.128/26 dev tun1 src 179.61.208.135/26 table T2 > > ip route add default via 179.61.208.129 table T2 > > > > ip route add 181.41.205.192/26 dev tun0 src 181.41.205.194/26 > > ip route add 179.61.208.128/26 dev tun1 src 179.61.208.135/26 > > > > ip route add default via 181.41.205.193 > > > > ip rule add from 181.41.205.194/26 table T1 > > ip rule add from 179.61.208.135/26 table T2 > > > > > > Not sure if this can works as I'm manually entering these rules outside > > the OpenVPN configuration and would like something neater (if possible, > > within the same configuration files) for easy maintenance. > > > > I would appreciate any comments. > > Thank you in advance for responding. > > > > [...] > > > > [1] http://lartc.org/howto/lartc.rpdb.multiple-links.html > > Hi all! > > I made a bash script to automatically apply the routing logic that I > commented on the other post. But I'm noticing that sometimes, all > connections fail simultaneously: > > client1: > > Mon May 5 12:47:26 2014 SIGUSR1[soft,ping-restart] received, process > restarting > Mon May 5 12:47:26 2014 Restart pause, 5 second(s) > Mon May 5 12:47:31 2014 WARNING: No server certificate verification method > has been enabled. See http://openvpn.net/howto.html#mitm for more info. > Mon May 5 12:47:31 2014 Socket Buffers: R=[87380->131072] S=[16384->131072] > Mon May 5 12:47:51 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:48:11 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:48:36 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:01 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:26 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:51 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:50:16 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:50:41 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:51:06 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:51:31 2014 RESOLVE: Cannot resolve host address: > ua1-ovpn.purevpn.net: Temporary failure in name resolution > > client2: > > Mon May 5 12:47:26 2014 [PureVPN] Inactivity timeout (--ping-restart), > restarting > Mon May 5 12:47:26 2014 SIGUSR1[soft,ping-restart] received, process > restarting > Mon May 5 12:47:26 2014 Restart pause, 5 second(s) > Mon May 5 12:47:31 2014 WARNING: No server certificate verification method > has been enabled. See http://openvpn.net/howto.html#mitm for more info. > Mon May 5 12:47:31 2014 Socket Buffers: R=[87380->131072] S=[16384->131072] > Mon May 5 12:47:51 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:48:11 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:48:36 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:01 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:26 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:51 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:50:16 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:50:41 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:51:06 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:51:31 2014 RESOLVE: Cannot resolve host address: > ru1-ovpn.purevpn.net: Temporary failure in name resolution > > client3: > > Mon May 5 12:47:25 2014 [PureVPN] Inactivity timeout (--ping-restart), > restarting > Mon May 5 12:47:25 2014 SIGUSR1[soft,ping-restart] received, process > restarting > Mon May 5 12:47:25 2014 Restart pause, 5 second(s) > Mon May 5 12:47:30 2014 WARNING: No server certificate verification method > has been enabled. See http://openvpn.net/howto.html#mitm for more info. > Mon May 5 12:47:30 2014 Socket Buffers: R=[87380->131072] S=[16384->131072] > Mon May 5 12:47:50 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:48:10 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:48:35 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:00 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:25 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:49:50 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:50:15 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:50:40 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:51:05 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > Mon May 5 12:51:30 2014 RESOLVE: Cannot resolve host address: > ch1-ovpn.purevpn.net: Temporary failure in name resolution > > Can this be related to a routing problem? > > Is there any way to do load balancing with the connections for each client? > > > Thanks in advance. > > Best regards, > Daniel Make sure your direct name server is in /etc/resolv.conf (openvpn may replace it) and add route to it via physical interface/gateway. Or use resolved addresses in your config files. -- http://markorandjelovic.hopto.org One should not be afraid of humans. Well, I am not afraid of humans, but of what is inhuman in them. Ivo Andric, "Signs near the travel-road" -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140506030318.22155...@eunet.rs
