OpenVPN: Redirecionamento de tráfego não funciona

Question

OpenVPN: Redirecionamento de tráfego não funciona

#1 resposta do (2 votos)

1

tl; dr (depois de horas debugando com @krisFR): Pelo menos sob o Debian 8, nunca use interfaces virtuais (eth0: 1) para o OpenVPN, em vez disso aplique os novos métodos debian iproute2 (abordagem manual) descrita aqui: link . Ele irá rotear o tráfego bem.

Eu estava tentando configurar o OpenVPN em uma máquina onde todo o tráfego do cliente deveria ser enviado pelo túnel, então isso é parte da configuração do meu servidor:

local x.x.x.243
port 443
proto udp
dev tun
server 172.31.1.0 255.255.255.0 
push "redirect-gateway def1 bypass-dhcp"

E minha configuração do cliente:

pull
resolv-retry infinite
mute-replay-warnings 
redirect-gateway def1
script-security 1

O cliente pode se conectar à VPN e pode fazer ping no host da VPN em 172.31.1.1 ; no entanto, se eu tentar pingar google.com por domínio ou IP, receberei uma mensagem Request timeout for icmp_seq 0

O que pode estar causando isso? Nota lateral, eu desinstalei qualquer firewall e atualmente estou configurando o IPTables para:

iptables -A INPUT -i eth0:1 -m state --state NEW -p udp --dport 443 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0:1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0:1 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.31.1.0/24 -o eth0:1 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT

Obrigado.

Então eu tentei fazer ping no cliente 213.30.5.46 (um dos IPs do Google) e não funcionou, no entanto, obtive os seguintes resultados:

Ouvindo o IP da VPN de saída (eth0: 1): tcpdump -i eth0 -t host x.x.x.243

IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 113
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP vpn.exampledomain.com.https > [CLIENT_IP x..].51060: UDP, length 81
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145

Ao mesmo tempo, ouvindo no tun0, recebi isso: tcpdump -i tun0

23:40:39.864798 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 0, length 64
23:40:40.925951 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 256, length 64
23:40:41.886679 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 512, length 64
23:40:42.906125 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 768, length 64

Aqui está a saída de iptables -L -n -v :

Chain INPUT (policy ACCEPT 34772 packets, 2265K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0:1 *       0.0.0.0/0            0.0.0.0/0            state NEW udp dpt:443
   13  1092 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1437 96985 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun+   eth0:1  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth0:1 tun+    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 32574 packets, 7919K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13  1092 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

Observação: /proc/sys/net/ipv4/ip_forward está definido como 1 .

Segmentado tcpdump -i eth0:1 -t host 213.30.5.46 ao pingar o destino:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0:1, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 0, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 256, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 512, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 768, length 64

Nada é mostrado no cliente, o ping eventualmente expira.

O endereço IP usado pelo OpenVPN local x.x.x.243 está configurado em \etc\network\interfaces as eth0:1 logo após eth0 as:

 auto eth0:1
  iface eth0:1 inet static
   address x.x.x.243
   gateway x.x.x.129
   netmask 255.255.255.128
   dns-nameservers x.x.x.4 x.x.x.104

openvpn traffic tunneling route

por TCB13 19.05.2015 / 22:41

1 resposta

Tags openvpn traffic tunneling route

Como resolver o erro TLS no cliente FTP Filezilla? [fechadas] Qual é a ordem de implantação no Wildfly?

score 2 · Accepted Answer

Como você disse, passamos horas juntos para depurar isso ...

Com relação a todos os testes que fizemos e todos os rastreios que recuperamos, finalmente parece que estávamos experimentando alguns comportamentos estranhos em relação à interface virtual eth0:1 .

por exemplo: link

Most Linux distributions, and most UNIX's, currently use the venerable arp, ifconfig and route commands. While these tools work, they show some unexpected behaviour under Linux 2.2 and up. For example, GRE tunnels are an integral part of routing these days, but require completely different tools.

With iproute2, tunnels are an integral part of the tool set.

Decidimos mudar para iproute2 (pelo menos experimente), modificando o arquivo /etc/network/interfaces para alterar a maneira de atribuir vários IPs à interface eth0 .

Depois disso, tudo correu bem e funcionando!

iproute2 exemplo:

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 192.168.1.42
    netmask 255.255.255.0
    gateway 192.168.1.1

iface eth0 inet static
    address 192.168.1.43
    netmask 255.255.255.0

Mais informações sobre iproute2 aqui:

link
link