Eu tenho um script bash em uma caixa do Ubuntu que procura o servidor openvpn mais rápido, conecta e vincula um programa à interface tun0. Infelizmente, todo o tráfego está sendo passado pela VPN. Alguém sabe o que está acontecendo?
A linha relevante segue:
openvpn --daemon --config $cfile --auth-user-pass ipvanish.pass --status openvpn-status.log
Parece que não existem entradas no iptables quando eu digito sudo iptables --list .
Os arquivos de configuração são assim:
client
dev tun
proto tcp
remote nyc-a04.ipvanish.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
ca ca.ipvanish.com.crt
tls-remote nyc-a04.ipvanish.com
auth-user-pass
comp-lzo
verb 3
auth SHA256
cipher AES-256-CBC
keysize 256
tls-cipher DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA
Não há nada lá que dirija tudo através do tun0, então talvez seja um novo capricho do Ubuntu? Não me lembro de isso acontecer no passado.
edit: aqui está o ip r ls :
0.0.0.0/1 via 172.20.24.1 dev tun0
default via 192.168.0.1 dev eth1 proto static
128.0.0.0/1 via 172.20.24.1 dev tun0
172.20.24.0/22 dev tun0 proto kernel scope link src 172.20.27.20
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.10 metric 1
216.151.180.2 via 192.168.0.1 dev eth1
E ifconfig com algumas ofuscações:
[$] <> ifconfig
eth0 Link encap:Ethernet HWaddr *:*:*:*:*:*
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:16 Memory:fdbc0000-fdbe0000
eth1 Link encap:Ethernet HWaddr *:*:*:*:*:*
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2604:*:*:*:*:*:*:*/64 Scope:Global
inet6 addr: fe80::223:54ff:fe07:6555/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19923223 errors:0 dropped:1 overruns:0 frame:0
TX packets:35568399 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4692090933 (4.6 GB) TX bytes:56325183667 (56.3 GB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:77741 errors:0 dropped:0 overruns:0 frame:0
TX packets:77741 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19058271 (19.0 MB) TX bytes:19058271 (19.0 MB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.20.27.20 P-t-P:172.20.27.20 Mask:255.255.252.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:15810638 errors:0 dropped:0 overruns:0 frame:0
TX packets:36553479 errors:0 dropped:146946 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:872811046 (872.8 MB) TX bytes:49841453877 (49.8 GB)
Você pode configurar o tunelamento dividido no cliente usando algo semelhante ao seguinte em seu arquivo de configuração .ovpn:
route-nopull
route 172.20.24.0 255.255.252.0 vpn_gateway
Primeira linha desativa o roteamento. Segunda linha adiciona a rota estática.
É melhor você resolver isso no servidor, mas suponho que esteja procurando uma solução do lado do cliente.
Parece que o servidor está configurado para enviar rotas para os clientes algo como
push "redirect-gateway"
Você faz um cliente ignorar todas as rotas com o
route-nopull
diretiva no arquivo de configuração do cliente.