tl; dr (после нескольких часов отладки с помощью @krisFR): по крайней мере, в Debian 8 никогда не используйте виртуальные интерфейсы (eth0: 1) для OpenVPN, вместо этого примените новый debian iproute2 методы (ручной подход), описанные здесь: https://wiki.debian.org/NetworkConfiguration#iproute2_method . Он будет хорошо направлять трафик.
Я пытался настроить OpenVPN на машине, где весь клиентский трафик должен отправляться через туннель, поэтому это часть конфигурации моего сервера:
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"
И моя клиентская конфигурация:
pull
resolv-retry infinite
mute-replay-warnings
redirect-gateway def1
script-security 1
Клиент может подключиться к VPN и пинговать VPN-хост на 172.31.1.1однако, если я попытаюсь проверить связь с google.com по домену или IP, я получаю Request timeout for icmp_seq 0 сообщение...
Что может быть причиной этого? Боковое примечание: я удалил все брандмауэры и в настоящее время устанавливаю IPTables на:
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
Спасибо.
Итак, я попытался пинговать клиента 213.30.5.46 (один из IP-адресов Google), и это не сработало, однако я получил следующие результаты:
Прослушивание исходящего IP-адреса VPN (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
При этом, слушая на tun0, получилось вот что: 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
Вот результат 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
Примечание: /proc/sys/net/ipv4/ip_forward установлен на 1.
Целевые tcpdump -i eth0:1 -t host 213.30.5.46 во время пингования пункта назначения:
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
На клиенте ничего не отображается, время ожидания пинга истекает.
IP-адрес, используемый OpenVPN. local x.x.x.243 настроен на \etc\network\interfaces так как eth0:1 сразу после 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
Как вы сказали, мы часами вместе отлаживаем это ...
Что касается всех проведенных нами тестов и всех полученных трассировок, то, наконец, кажется, что мы испытали странное поведение в отношении виртуального интерфейса. eth0:1.
например: http://lartc.org/howto/lartc.iproute2.html
Большинство дистрибутивов Linux и большинство UNIX в настоящее время используют почтенные команды arp, ifconfig и route. Хотя эти инструменты работают, они демонстрируют неожиданное поведение в Linux 2.2 и выше. Например, туннели GRE в наши дни являются неотъемлемой частью маршрутизации, но для них требуются совершенно другие инструменты.
В iproute2 туннели являются неотъемлемой частью набора инструментов.
Мы решили перейти на iproute2 (по крайней мере, попробуйте) изменение /etc/network/interfaces файл, чтобы изменить способ назначения нескольких IP-адресов для eth0 интерфейс.
После этого все прошло нормально и заработало!
iproute2 пример :
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
Дополнительная информация о iproute2 Вот :