Openvpn: o cliente pode fazer ping no servidor, o servidor não pode fazer ping no cliente

Question

Eu tenho um problema estranho com a configuração openvpn entre os datacenters da AWS e da GoGrid. Minha rede parece com isso

/----------------\               /----------------\               /------------------\               /----------------\
|  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 |
\----------------/               \----------------/               \------------------/               \----------------/

Eu posso pingar de aws para gogrid sem problemas (tanto VPS-DEVEL.gg quanto VPS-VPN.gg de ambas as aws VMs), mas não consigo pingar de gogrid para AWS.

Minha tabela de roteamento no VPS-VPN.gg parece assim:

[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

Minha tabela de roteamento em 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

Minha configuração do servidor openvpn (lado do gegrid):

[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"

Minha configuração do cliente openvpn (lado 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 mostra isso:

1. Ping do aws (ambas as VMs) entra na interface do VPS-VPN.aws tun0 no túnel do vpn, chega ao tun0 no VPS-VPN.gg e a resposta volta à direita
2. O ping da gogrid entra na interface tun0 VPS-VPN.gg no túnel vpn, mas não chegou à interface tun0 no VPS-VPN.aws
3. Ping de VPS-VPN.gg para VPS-VPN.aws IP de tun0 (10.8.0.10) funciona bem

O VPS-VPN ativou o ip_forward.

IPTables no VPS-VPN.aws parece isso, os grupos de segurança da AWS estão configurados para permitir todo o tráfego de qualquer lugar (eu não gosto de usar SecGroups quando eu posso usar o iptables em VMs):

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           

Estou usando o 10.160.0.0/18 no roteamento apenas porque terei mais VPCs com sub-redes nesse intervalo. Cada AWS VPC tem sub-rede / 21. Tudo está na sub-rede 10.160.64.0/24 no lado do GoGrid e a tabela de roteamento aws está definida para rotear tudo para essa sub-rede para a instância VPS-VPN.aws. Isso está funcionando, posso fazer ping no GoGrid da AWS.

Você pode me apontar onde estou cometendo algum erro? Esta configuração AFAIK deve estar funcionando para ambas as direções. Muito obrigado.

    

Answer 1

Então eu encontrei uma solução. Eu tinha configurado mal o roteamento de cliente para cliente. Para obter este trabalho, deve haver client-to-client diretiva no arquivo de configuração do servidor, deve ser definido corretamente client-config-dir diretiva e deve haver um arquivo CCD neste dir para conectar o cliente.

O nome do arquivo CCD deve ser o mesmo que o nome comum no cliente de conexão de certificado está usando para autenticar e neste arquivo deve ser adicionado a regra de roteamento para a rede do cliente, no meu caso

iroute 10.160.0.0 255.255.192.0

Após essas alterações terem sido feitas, a comunicação funciona perfeitamente em ambas as direções.