Назад | Перейти на главную страницу

Пинги от сети VPN к клиенту VPN работают; Пинги от VPN-клиента к сети VPN не работают - почему?

Мы находимся в процессе настройки сервера OpenVPN для некоторых серверов, работающих в облаке. Мы столкнулись с проблемой подключения, когда узлы в локальной сети VPN-сервера могут пинговать VPN-клиент, но обратное неверно.

VPN-клиент может пинговать VPN-сервер по его VPN-адресу, но не по его LAN-адресу.

tcpdump показывает доказательства того, что пакеты ping от клиента достигают хоста, и отправляются ответы, но по какой-то причине ответы никогда не достигают интерфейса tun0 на сервере VPN или клиенте. И наоборот, согласно tcpdump, трафик для ping-запросов от LAN VPN-сервера к VPN-клиенту виден на всех ожидаемых интерфейсах.

Подробное описание нашей конфигурации и устранения неполадок на сегодняшний день приведено ниже.

Проблема, по-видимому, связана с пересылкой с адресов в сети сервера обратно в сеть клиента. Что действительно странно (для меня), так это то, что пинги, инициированные локальной сетью, могут выполнять полный цикл приема-передачи, но инициированные клиентом пинги, похоже, отбрасываются где-то между интерфейсами tun0 и eth1 сервера VPN.

Что нам не хватает?

Ситуация:

3 хоста:

Клиент VPN (tun0: 10.8.0.22)
VPN-сервер (tun0: 10.8.0.1, eth1: 10.11.11.2, eth0: x.x.x.x)
LAN-сервер (eth0: 10.11.11.7)

Оба сервера представляют собой виртуальные машины под управлением RHEL 5.7. Я думаю (но не совсем уверен), что среда виртуального хостинга - это VMWare.

Тесты

VPN-клиент установил туннель к VPN-серверу через интерфейс eth0 VPN-сервера.
VPN-клиент может пинговать VPN-сервер на своем интерфейсе tun0 10.8.0.1
VPN-сервер может пинговать 10.8.0.22
Сервер LAN может пинговать 10.8.0.22

но:

VPN-клиент не может проверить связь с VPN-сервером на своем интерфейсе eth1 10.11.11.2
VPN-клиент не может проверить связь с LAN-сервером на своем интерфейсе eth0 10.11.11.7

Для проверки связи между 10.11.11.7 и 10.8.0.22:

tcpdump показывает запросы ping и ответы, проходящие через tun0 на VPN-сервере
tcpdump показывает запросы ping и ответы, проходящие через eth1 на VPN-сервере
tcpdump показывает запросы ping и ответы, проходящие через eth0 на сервере LAN

Для проверки связи между 10.11.11.2 и 10.8.0.22:

tcpdump показывает запросы ping и ответы, проходящие через tun0 на VPN-сервере

Для теста ping между 10.8.0.22 и 10.11.11.2:

tcpdump показывает запросы ping, проходящие через tun0 на VPN-сервере
tcpdump показывает ответы ping, проходящие через eth1 на VPN-сервере
нет никаких следов ответа на интерфейсе tun0

Для теста ping между 10.8.0.22 и 10.11.11.7:

tcpdump показывает запросы ping, проходящие через tun0 на VPN-сервере
tcpdump показывает запросы ping, проходящие через eth1 на VPN-сервере
tcpdump показывает запросы ping, проходящие через eth0 на сервере LAN
tcpdump показывает ответы ping, проходящие через eth0 на сервере LAN
нет никаких следов ответа ни на интерфейсах tun0, ни на eth1 VPN-сервера

ip_fowarding был включен на VPN-сервере. rp_filter был отключен на VPN-сервере для всех интерфейсов, кроме интерфейса с выходом в Интернет, eth0.

iptables был отключен правилами (по умолчанию ACCEPT) на клиенте в целях отладки основной проблемы.

Я включил дампы маршрута -n и ifconfig для соответствующих интерфейсов на каждом хосте.

На сервере OpenVPN

$ /sbin/route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
x.x.x.x     0.0.0.0         255.255.248.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         x.x.x.x     0.0.0.0         UG    0      0        0 eth0

$ find /proc/sys/net -name 'rp_filter' | while read f
> do echo $f $(cat $f)
> done
/proc/sys/net/ipv4/conf/tun0/rp_filter 0
/proc/sys/net/ipv4/conf/eth1/rp_filter 0
/proc/sys/net/ipv4/conf/eth0/rp_filter 1
/proc/sys/net/ipv4/conf/lo/rp_filter 0
/proc/sys/net/ipv4/conf/default/rp_filter 0
/proc/sys/net/ipv4/conf/all/rp_filter 0

$ cat /proc/sys/net/ipv4/ip_forward 
1

$ sudo /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   


$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr DE:AD:BE:A6:28:21  
          inet addr:x.x.x.x  Bcast:x.x.x.x  Mask:255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:233929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24776 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:27881415 (26.5 MiB)  TX bytes:30534780 (29.1 MiB)

eth1      Link encap:Ethernet  HWaddr DE:AD:BE:3B:24:48  
          inet addr:10.11.11.2  Bcast:10.11.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:423658 (413.7 KiB)  TX bytes:863546 (843.3 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11992 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:34820967 (33.2 MiB)  TX bytes:34820967 (33.2 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:69 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:5796 (5.6 KiB)  TX bytes:4788 (4.6 KiB)

$ uname -a
Linux vhost0273 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

$ ping -c1 10.8.0.22 -w 1
PING 10.8.0.22 (10.8.0.22) 56(84) bytes of data.
64 bytes from 10.8.0.22: icmp_seq=1 ttl=64 time=145 ms

--- 10.8.0.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 145.676/145.676/145.676/0.000 ms

$ ping -c1 10.11.11.7 -w 1
PING 10.11.11.7 (10.11.11.7) 56(84) bytes of data.
64 bytes from 10.11.11.7: icmp_seq=1 ttl=64 time=0.794 ms

--- 10.11.11.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.794/0.794/0.794/0.000 ms

На хосте в локальной сети сервера:

$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr DE:AD:BE:7F:45:72  
          inet addr:10.11.11.7  Bcast:10.11.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33897 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2536157 (2.4 MiB)  TX bytes:8910725 (8.4 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:77779 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77779 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.11.11.2      255.255.255.0   UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.11.11.2      0.0.0.0         UG    0      0        0 eth0

$ ping -c1 10.8.0.1 -w 1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.516 ms

--- 10.8.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.516/0.516/0.516/0.000 ms

$ ping -c1 10.8.0.22 -w 1
PING 10.8.0.22 (10.8.0.22) 56(84) bytes of data.
64 bytes from 10.8.0.22: icmp_seq=1 ttl=63 time=146 ms

--- 10.8.0.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 146.913/146.913/146.913/0.000 ms

$ ping -c1 10.11.11.2 -w 1
PING 10.11.11.2 (10.11.11.2) 56(84) bytes of data.
64 bytes from 10.11.11.2: icmp_seq=1 ttl=64 time=0.775 ms

--- 10.11.11.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.775/0.775/0.775/0.000 ms

На VPN-клиенте

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.22  P-t-P:10.8.0.21  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

$ /sbin/route -n | grep ^10
10.8.0.21       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.0.1.0        0.0.0.0         255.255.255.0   U     2      0        0 wlan0
10.1.1.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.11.11.0      10.8.0.1        255.255.255.0   UG    0      0        0 tun0

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=145 ms

$ ping 10.8.0.2 -w 1
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.

--- 10.8.0.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.11.11.2 -w 1
PING 10.11.11.2 (10.11.11.2) 56(84) bytes of data.

--- 10.11.11.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.11.11.7 -w 1
PING 10.11.11.7 (10.11.11.7) 56(84) bytes of data.

--- 10.11.11.7 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

Основной причиной этой проблемы были некоторые неявные маршруты по умолчанию, которые не были видны в таблицах, отображаемых / sbin / route, но были видны в таблицах, отображаемых / sbin / ip route и / sbin / ip rule.

Затем эти таблицы были отображены, и стало очевидно, что правило такого рода:

default table route_eth0 via 10.11.11.1  dev eth0

отменял это правило:

10.8.0.0        10.11.11.2      255.255.255.0   UG    0      0        0 eth0

Отредактировав / etc / sysconfig / network-scripts / route-eth0 (предположительно с маршрутом / sbin / ip, хотя в данном случае сделал это вручную), я смог исправить проблему.

Итак, из этого я понял, что нельзя полагаться на / sbin / route, чтобы дать вам точное представление об эффективных правилах маршрутизации Linux, и что для этой цели лучше использовать / sbin / ip.

Спасибо ptman, чей ответ на этот вопрос помог мне увидеть свет. Спасибо, птман!

А как насчет ваших правил iptables? Они выглядят довольно пустыми.

Я использую следующие правила, но не уверен, что это решит вашу проблему:

# Allow TUN interface connections to OpenVPN server
iptables -A INPUT -i tun+ -j ACCEPT

# Allow TUN interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -o tun+ -j ACCEPT

# Allow TUN interface connections to get out
iptables -A OUTPUT -o tun+ -j ACCEPT

# We want to allow routing from OpenVPN tunnels
$IPTABLES -t nat -A POSTROUTING -o eth1 -s 10.8.1.0/255.255.255.0 -j MASQUERADE
$IPTABLES -A FORWARD -i tun+ -o eth1 -s 10.8.1.0/255.255.255.0 -j ACCEPT

На шлюзе вам нужна запись маршрутизации для направления трафика для 10.8.1.0/24 на сервер openvpn.

На сервере openvpn трафик для подсети 10.8.1.0/24 использует IP-адрес интерфейса tun сервера openvpn, например 10.8.1.2. Хотя это уже должно быть настроено самим openvpn.

Обновление: мне пришлось отредактировать несколько вещей, я использую здесь настройку с двумя серверами openvpn, которые также обмениваются данными друг с другом. Итак, я перепутал некоторые вещи, которые не имеют отношения к вашей ситуации.