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

Openvpn: клиент может пинговать сервер, сервер не может пинговать клиента

У меня странная проблема с настройкой openvpn между центрами обработки данных AWS и GoGrid. Моя сеть выглядит так

/----------------\               /----------------\               /------------------\               /----------------\
|  VPS-DEVEL.gg  |               |    VPS-VPN.gg  |               |   VPS-VPN.aws    |               | VPS-PROVIS.aws |
| 10.160.64.7/24 | eth1 --- eth1 | 10.160.64.9/24 | tun0 --- tun0 | 10.160.48.219/24 | eth0 --- eth0 | 10.160.52.8/24 |
\----------------/               \----------------/               \------------------/               \----------------/

Я могу без проблем пинговать с AWS на gogrid (как VPS-DEVEL.gg, так и VPS-VPN.gg с обеих виртуальных машин aws), но я не могу пинговать с gogrid на AWS.

Моя таблица маршрутизации на VPS-VPN.gg выглядит так:

[root@VPSVPN ~]# route -n
Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
169.254.4.1     164.40.132.83   255.255.255.255 UGH   0      0        0 eth0
169.254.4.2     10.160.64.9     255.255.255.255 UGH   0      0        0 eth1
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
164.40.132.80   0.0.0.0         255.255.255.240 U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.240 UG    0      0        0 tun0
10.159.254.0    10.160.64.1     255.255.255.0   UG    0      0        0 eth1
10.160.64.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.160.0.0      10.8.0.2        255.255.192.0   UG    0      0        0 tun0
0.0.0.0         164.40.132.81   0.0.0.0         UG    0      0        0 eth0

Моя таблица маршрутизации на VPS-VPN.aws:

admin@ip-10-160-48-219:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.160.48.1     0.0.0.0         UG    0      0        0 eth0
10.8.0.0        10.8.0.9        255.255.255.240 UG    0      0        0 tun0
10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.160.48.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.160.64.0     10.8.0.9        255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

Конфигурация моего сервера openvpn (сторона gogrid):

[root@VPSVPN ~]# cat /etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert vpsvpn.crt
key vpsvpn.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.240
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd # ghor
client-to-client # ghor
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
max-clients 100
status /var/log/openvpn-status.log
log-append  /var/log/openvpn.log
verb 11
route 10.160.0.0 255.255.192.0
push "route 10.160.64.0 255.255.255.0"

Моя конфигурация клиента openvpn (сторона aws):

admin@ip-10-160-48-219:~$ cat /etc/openvpn/gogrid/gogrid.ovpn 
client
dev tun
proto udp
remote 164.40.132.83 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
ca /etc/openvpn/gogrid/ca.crt
cert /etc/openvpn/gogrid/test-eu-west-1-aws.crt
key /etc/openvpn/gogrid/test-eu-west-1-aws.key
askpass /etc/openvpn/gogrid/test-eu-west-1-aws.pass

TCPDump показывает это:

  1. Пинг от aws (обе виртуальные машины) идет по интерфейсу VPS-VPN.aws tun0 в туннель vpn, доходит до tun0 на VPS-VPN.gg, и ответ возвращается вправо
  2. Пинг от gogrid идет по интерфейсу VPS-VPN.gg tun0 в туннель vpn, но не доходит до интерфейса tun0 на VPS-VPN.aws
  3. Пинг с VPS-VPN.gg на VPS-VPN.aws IP-адрес tun0 (10.8.0.10) работает хорошо

Оба VPS-VPN включили ip_forward.

IPTables на VPS-VPN.aws выглядит так, группы безопасности AWS настроены на разрешение всего трафика отовсюду (мне не нравится использовать SecGroups, когда я могу использовать iptables на виртуальных машинах):

admin@ip-10-160-48-219:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 867 packets, 68073 bytes)
 pkts bytes target        prot opt in     out     source            destination         
 1426  117K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0         0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1360  105K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 743 packets, 72322 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 1400  115K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0          

admin@ip-10-160-48-219:~$ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 1743 packets, 105K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 1359 packets, 69760 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 390 packets, 40130 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target      prot opt in     out     source              destination         
  748 67734 MASQUERADE  all  --  *      eth0    0.0.0.0/0           0.0.0.0/0           
   17  1428 MASQUERADE  all  --  *      tun0    0.0.0.0/0           0.0.0.0/0           

Я использую 10.160.0.0/18 для маршрутизации только потому, что у меня будет больше VPC с подсетями в этом диапазоне. У каждого AWS VPC есть подсеть / 21. Все находится в подсети 10.160.64.0/24 на стороне GoGrid, а таблица маршрутизации aws настроена для маршрутизации всего для этой подсети в экземпляр VPS-VPN.aws. Это работает, я могу пинговать GoGrid из AWS.

Вы можете указать мне, где я делаю ошибку? Эта настройка AFAIK должна работать в обоих направлениях. Большое спасибо.

Итак, я нашел решение. У меня была плохо настроенная маршрутизация клиент-клиент. Чтобы это работало, должен быть client-to-client директива в файле конфигурации сервера, должна быть правильно установлена client-config-dir директива, и в этом каталоге должен быть файл CCD для подключения клиента.

Имя файла CCD должно быть таким же, как Общее имя в сертификате, которое клиент использует для аутентификации, и в этот файл должно быть добавлено правило маршрутизации для клиентской сети, в моем случае

iroute 10.160.0.0 255.255.192.0

После внесения этих изменений коммуникация работает отлично в обоих направлениях.