tl;dr (após horas de depuração com @krisFR): Pelo menos no Debian 8, nunca use interfaces virtuais (eth0:1) para OpenVPN, em vez disso, aplique os novos iproute2
métodos debian (abordagem manual) descritos aqui: https://wiki. debian.org/NetworkConfiguration#iproute2_method . Ele irá direcionar o tráfego muito 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 faz 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 a configuração do meu cliente:
pull
resolv-retry infinite
mute-replay-warnings
redirect-gateway def1
script-security 1
O cliente pode se conectar à VPN e pode executar ping no host da VPN em 172.31.1.1
, no entanto, se eu tentar fazer ping em google.com por domínio ou IP, recebo uma Request timeout for icmp_seq 0
mensagem...
O que pode estar causando isso? Observação lateral, 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
Obrigada.
Então tentei fazer ping no cliente 213.30.5.46
(um dos IPs do Google) e não funcionou, porém obtive este resultado:
Escutando no IP 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 isto: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
Nota: /proc/sys/net/ipv4/ip_forward
está definido como 1
.
Direcionado tcpdump -i eth0:1 -t host 213.30.5.46
durante o ping do 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 aparece no cliente, o ping eventualmente expira.
O endereço IP usado pelo OpenVPN local x.x.x.243
é configurado da \etc\network\interfaces
seguinte eth0:1
forma eth0
:
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
Como você disse, passamos horas juntos para depurar isso...
Em relação a todos os testes que fizemos e todos os rastreamentos que recuperamos, finalmente parece que estávamos experimentando alguns comportamentos estranhos em relação à Interface Virtual
eth0:1
.por exemplo: http://lartc.org/howto/lartc.iproute2.html
Decidimos mudar para
iproute2
(pelo menos tentar) modificar/etc/network/interfaces
o arquivo para alterar a maneira de atribuir vários IPs àeth0
interface.Depois disso tudo correu bem e funcionando!
iproute2
exemplo :Mais informações sobre
iproute2
aqui: