OpenVPN para certos IPs, eth0 para todo o resto

Question

Resumo: Gostaria de me conectar à minha VPN e ter acesso a determinados servidores, mas, para todos os outros, gostaria de usar minha rede regular.

Eu configurei um servidor OpenVPN no meu VPS, meu arquivo server.conf é assim:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log         /var/log/openvpn.log
verb 4
push "route 10.132.0.0 255.255.0.0"

Eu uso o seguinte arquivo .ovpn para configurar a conexão VPN:

client
dev tun
proto udp
remote <my.vpn.server.com> 1194
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
<ca>....</ca>
<cert>...</cert>
<key>...</key>

Por fim, no Network Manager para a conexão VPN, em Configurações IPv4, certifiquei-me de definir o "Método" para "Somente endereços automáticos (VPN)".

VPN conecta bem, eu posso acessar todos os servidores internos que eu preciso (10.132.x.x), no entanto eu não posso acessar qualquer outra coisa (como google.com). Eu gostaria que minhas configurações de eth0 fossem usadas para tudo, exceto para os IPs 10.132.x.x que eu gostaria de rotear através da VPN.

P.S. com base em outros artigos, tentei usar no-pull no arquivo .ovpn e adicionar minhas configurações de route , mas sem sucesso.

EDIT 1 :

Resultados da execução de ip a e traceroute enquanto conectado à VPN:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:dc:a6:ef brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 86320sec preferred_lft 86320sec
    inet6 fe80::f3d1:6eb3:e13e:d61b/64 scope link 
       valid_lft forever preferred_lft forever
15: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.6 peer 10.8.0.5/32 brd 10.8.0.6 scope global tun0
       valid_lft forever preferred_lft forever

$ traceroute google.com
google.com: Temporary failure in name resolution
Cannot handle "host" cmdline arg 'google.com' on position 1 (argc 1)

EDIT 2 : resultados de ip r

$ ip r
default via 10.8.0.5 dev tun0  proto static  metric 50 
default via 10.0.2.2 dev eth0  proto static  metric 100 
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15  metric 100 
10.8.0.1 via 10.8.0.5 dev tun0  proto static  metric 50 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6  metric 50 
10.132.0.0/16 via 10.8.0.5 dev tun0  proto static  metric 50 
104.236.239.153 via 10.0.2.2 dev eth0  proto static  metric 100 
169.254.0.0/16 dev eth0  scope link  metric 1000 

    

Answer 1

Consegui obter o efeito desejado brincando com a GUI do cliente (Ubuntu NetworkManager). Precisei verificar se a caixa de seleção em IPv4 Settings -> Routes para "Usar esta conexão apenas para recursos em sua rede" estava marcada:

Não tenho certeza do que eu precisaria fazer no arquivo .ovpn para replicar isso.

Minha tabela de roteamento agora parece assim:

$ sudo netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.132.0.0      10.8.0.5        255.255.0.0     UG        0 0          0 tun0
104.236.239.153 10.0.2.2        255.255.255.255 UGH       0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0

Lembre-se de que eu tinha o push "route 10.132.0.0 255.255.0.0" no meu server.conf , o que explica a entrada para 10.132.0.0 e, portanto, agora posso acessar meus servidores enquanto todo o restante é roteado fora da VPN (ou seja, 0.0.0.0 entry)

Sem essa configuração sendo marcada na GUI, minha tabela de roteamento ficou assim:

$ sudo netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.0.5        0.0.0.0         UG        0 0          0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.132.0.0      10.8.0.5        255.255.0.0     UG        0 0          0 tun0
104.236.239.153 10.0.2.2        255.255.255.255 UGH       0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0

Meu palpite é que a primeira 0.0.0.0 entry (rota padrão) estava bagunçando tudo.

    

Answer 2

A caixa de seleção "Usar esta conexão somente para recursos em sua rede " no nm-connection-editor controla se o NetworkManager deve adicionar uma rota padrão através da VPN. Se estiver marcado, como você fez, somente os pacotes direcionados para a sub-rede da VPN passarão pelo gateway da VPN e o sistema usará a rota padrão existente para outros destinos.

Você pode alterar a mesma configuração na linha de comando usando nmcli:

nmcli connection modify <VPN connection> ipv4.never-default yes

    

Answer 3

Para expor a resposta do jdmorei, você precisa do que é chamado de VPN de "túnel dividido" - na verdade, você quase teve a solução quando declarou: P.S. based on other articles I've tried using no-pull in the .ovpn file and adding in my route settings there but to no avail. .

Você desejará o seguinte no seu arquivo ovpn:

route-nopull # Make sure not to pull the default routes
route 10.8.0.0 255.255.255.0 # Route the /24 of 10.8.0.0 across the VPN
route 192.168.2.2 255.255.255.255 # Route the /32 (single IP) across the VPN

Agora, a chave é que, como você está executando o Windows, você deve executar o aplicativo openvpn como administrador. Se você não fizer isso, você verá entradas no log como:

Sat Nov 13 11:31:05 2010 ROUTE: route addition failed using CreateIpForwardEntry
: Access denied.   [status=5 if_index=11]
The requested operation requires elevation. 
Sat Nov 13 11:31:05 2010 ERROR: Windows route add command failed [adaptive]: ret
urned error code 1
Sat Nov 13 11:31:05 2010 Initialization Sequence Completed

    

Answer 4

se o seu servidor for / 24 ( 10.8.0.X )

servidor 10.8.0.0 255.255.255.0

e rota para seus clientes é / 16 ( 10.132.X.X )

push "route 10.132.0.0 255.255.0.0"

Talvez não seja um conflito?