tl; dr(después de horas de depuración con @krisFR): al menos en Debian 8, nunca use interfaces virtuales (eth0:1) para OpenVPN; en su lugar, aplique los nuevos iproute2métodos de Debian (enfoque manual) que se describen aquí:https://wiki.debian.org/NetworkConfiguration#iproute2_method. Dirigirá bien el tráfico.
Estaba intentando configurar OpenVPN en una máquina donde todo el tráfico del cliente debería enviarse a través del túnel, por lo que esto es parte de la configuración de mi 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"
Y mi configuración de cliente:
pull
resolv-retry infinite
mute-replay-warnings
redirect-gateway def1
script-security 1
El cliente puede conectarse a la VPN y puede hacer ping al host VPN en 172.31.1.1, sin embargo, si intento hacer ping a google.com por dominio o IP, aparece un Request timeout for icmp_seq 0mensaje...
¿Qué puede estar causando esto? Nota al margen: desinstalé cualquier firewall y actualmente estoy configurando 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
Gracias.
Intenté hacer ping al cliente 213.30.5.46(una de las IP de Google) y no funcionó, sin embargo obtuve estos resultados:
Escuchando en la IP VPN saliente (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
Al mismo tiempo, escuchando en tun0, me salió esto: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
Aquí está el resultado 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_forwardse establece en 1.
Dirigido tcpdump -i eth0:1 -t host 213.30.5.46mientras se hace ping al 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
No se muestra nada en el cliente y el ping finalmente se agota.
La dirección IP utilizada por OpenVPN local x.x.x.243se configura \etc\network\interfacesinmediatamente eth0:1después eth0como:
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
Respuesta1
Como dijiste, pasamos horas juntos para depurar esto...
Con respecto a todas las pruebas que realizamos y todos los rastros que recuperamos, finalmente parece que estábamos experimentando algunos comportamientos extraños con respecto a la interfaz virtual eth0:1.
p.ej :http://lartc.org/howto/lartc.iproute2.html
La mayoría de las distribuciones de Linux, y la mayoría de UNIX, utilizan actualmente los venerables comandos arp, ifconfig y route. Si bien estas herramientas funcionan, muestran algún comportamiento inesperado en Linux 2.2 y versiones posteriores. Por ejemplo, los túneles GRE son una parte integral del enrutamiento hoy en día, pero requieren herramientas completamente diferentes.
Con iproute2, los túneles son una parte integral del conjunto de herramientas.
Decidimos cambiar iproute2(al menos intentarlo) a modificar /etc/network/interfacesel archivo para cambiar la forma de asignar múltiples IP a la eth0interfaz.
¡Después de eso todo salió bien y funcionando!
iproute2ejemplo :
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
Más información sobre iproute2aquí: