Rota todo o tráfego através do OpenVPN

Question

Sim, esta pergunta foi feita centenas de vezes, e eu procurei em todos os lugares, sem sucesso.

O título diz tudo realmente.

Eu tenho um servidor OpenVPN (no Ubuntu), e posso me conectar a ele através do meu cliente (Windows 8) ...

O problema começa quando tento rotear todo o tráfego pela VPN.

Eu adicionei os push flags no server.conf:

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Quando me conecto a partir do cliente, o cliente gera:

Wed May 07 21:38:40 2014 SENT CONTROL [StretchVPN-CA]: 'PUSH_REQUEST' (status=1)
Wed May 07 21:38:41 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,route-gateway <Remote Router IP>,ping 10,ping-restart 120,ifconfig 192.168.0.201 255.255.255.0'
Wed May 07 21:38:41 2014 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route-related options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed May 07 21:38:41 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 07 21:38:41 2014 open_tun, tt->ipv6=0
Wed May 07 21:38:41 2014 TAP-WIN32 device [Local Area Connection 4] opened: \.\Global\{1F145805-92FC-454E-8FD9-0A6017DD4AD1}.tap
Wed May 07 21:38:41 2014 TAP-Windows Driver Version 9.9
Wed May 07 21:38:41 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.201/255.255.255.0 on interface {1F145805-92FC-454E-8FD9-0A6017DD4AD1} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Wed May 07 21:38:41 2014 Successful ARP Flush on interface [35] {1F145805-92FC-454E-8FD9-0A6017DD4AD1}
Wed May 07 21:38:46 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD <Remote Router IP> MASK 255.255.255.255 172.20.10.1
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 Initialization Sequence Completed

Eu tentei usar os sinalizadores no lado do cliente ao abrir a conexão:

openvpn --config "C:\Program Files\OpenVPN\config\client.ovpn" --redirect-gateway def1 --route-method exe

Mas ainda assim, quando vou ao whatsmyip.org, ele ainda diz meus clientes ip.

Alguém já teve esse problema e conseguiu resolvê-lo?

Muito obrigado

    

Answer 1

Eu testei isso usando um servidor OpenVPN e configurar a opção def1 do gateway de redirecionamento na configuração do cliente e do servidor funciona bem. Quando eu acesso o whatismyip.org , vejo o IP do meu servidor OpenVPN. Abaixo está a configuração do cliente que uso:

client
dev tun
proto udp
# THE IP OF THE REMOTE OPENVPN SERVER:
remote ip_address port
resolv-retry infinite
nobind
persist-key
persist-tun
# THE CSR FILE:
pkcs12 certificate.p12
ns-cert-type server
cipher AES-256-CBC
comp-lzo
redirect-gateway def1
verb 3

Eu testei também com acrescentar a opção def1 do gateway de redirecionamento ao comando openvpn e obtive o mesmo resultado. A configuração do servidor é:

port 1194
proto udp
dev tun

dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
# ENSURE THE DOMAIN NAME/FILENAME IS CORRECT:
cert /etc/openvpn/easy-rsa/keys/cert.crt
key /etc/openvpn/easy-rsa/keys/cert.key

server 10.5.3.0  255.255.255.0
# YOUR LOCAL SERVER IP HERE:
client-config-dir ccd
route 10.5.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun

status log/openvpn-status.log 5
status-version 2
log-append log/openvpn.log
verb 3  # verbose mode
management localhost port /etc/openvpn/management-password

# ROUTE THE CLIENT'S INTERNET ACCESS THROUGH THIS SERVER:
push "redirect-gateway def1"
push "remote-gateway vpn_server_ip"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 60

    

Answer 2

Talvez você tenha se esquecido de modificar seu NAT? Execute esses 3 comandos como root

Comandos:

iptables -I FORWARD -i tun0 -o eth0 \
         -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
         -j ACCEPT

iptables -t nat -I POSTROUTING -o eth0 \
          -s 10.8.0.0/24 -j MASQUERADE

Legenda:

• tun0: sua placa de rede VPN virtual
• eth0: sua placa de rede normal
• 10.8.0.0: seu bloco de ip de rede VPN

Answer 3

Depois de um difícil olhar para a resposta parece que eu resolvi isso, talvez parcialmente, mas pelo menos de forma muito simples:

Eu uso o pacote Xubuntu 14.04 e OpenVPN da fonte principal. Em Configurações > Sistema > Rede , substituí o endereço DNS pré-instalado 127.0.1.1 pelo 8.8.8.8 do Google e agora consigo ver todo o tráfego que passa pelo servidor VPN.

Na tabela do Wireshark, tal cadeia de caracteres como o DNS está ausente: todos os dados são como o TCP através do canal criptografado. Eu posso ver o tráfego DHCP e DNS quando olho para tun0 (interno do notebook). Quando eu exploro o wlan0 de tráfego (externo entre o notebook e o roteador WiFi), eu só recebo pacotes TCP cinza.

Acho que está acontecendo porque a consulta ao DNS não é necessária na decodificação de caracteres para números e ela entra em fluxo comum como um pacote de dados normal.

Ficarei feliz em saber suas considerações, não será surpresa se eu estiver completamente errado

    

Answer 4

Adicione a seguinte diretiva ao arquivo de configuração do servidor:

push "redirect-gateway def1"

Se a sua configuração de VPN for através de uma rede sem fio, onde todos os clientes e o servidor estão na mesma sub-rede sem fio, adicione o sinalizador local:

push "redirect-gateway local def1"

Pressionar a opção do gateway de redirecionamento para os clientes fará com que todo o tráfego de rede IP originado nas máquinas cliente passe pelo servidor OpenVPN. O servidor precisará ser configurado para lidar com esse tráfego de alguma forma, como por NAT para a Internet ou roteando-o através do proxy HTTP do site do servidor.

No Linux, você poderia usar um comando como este para NAT o tráfego do cliente VPN para a Internet:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Este comando assume que a sub-rede da VPN é 10.8.0.0/24 (retirada da diretiva do servidor na configuração do servidor OpenVPN) e que a interface ethernet local é eth0.

Quando o gateway de redirecionamento é usado, os clientes OpenVPN encaminharão as consultas DNS através da VPN, e o servidor VPN precisará manipulá-las. Isso pode ser feito enviando um endereço de servidor DNS para os clientes de conexão, o que substituirá as configurações normais do servidor DNS durante o tempo em que a VPN estiver ativa. Por exemplo:

push "dhcp-option DNS 10.8.0.1"

configurará clientes Windows (ou clientes não-Windows com algum script extra do lado do cliente) para usar o 10.8.0.1 como seu servidor DNS. Qualquer endereço que possa ser acessado pelos clientes pode ser usado como o endereço do servidor DNS.

    

Answer 5

Se o seu cliente OpenVPN estiver no Windows 10 (ou similar), há outro problema a ser observado, a ordem de vinculação das NICs. As configurações de servidor DNS existentes no adaptador LAN ou Wifi podem ter prioridade sobre as configurações do servidor DNS para a interface de túnel, portanto, embora tudo esteja configurado corretamente de um ponto de vista do OpenVPN, o Windows continua a usar o servidor DNS original. p>

Você pode corrigir isso conforme descrito nesta postagem no fórum da Microsoft.

link