Eu construí uma rede virtual e uma série de VMs, mostradas nesta imagem, para facilitar a visualização desse problema.
Cadasistemaesperadoparaencaminharpacotesdeveteroencaminhamentodeipv4ativado:
#sysctlnet.ipv4.ip_forward=1
Aconfiguraçãodoopenvpnnaminharededetesteésimplificada.Estouusandooopenvpnsemautenticação/criptografia,executando-oapartirdalinhadecomando,parafornecerumtúnelsimplesentreasmáquinas"openvpn-a" e "openvpn-b".
openvpn-a:
root@openvpn-a# openvpn --remote openvpn-b --dev tun1
openvpn-b:
root@openvpn-b# openvpn --remote openvpn-a --dev tun1
Eu experimentei o problema exato que você descreve, tentando pingar openvpn-b (192.168.20.1) do client-a (192.168.10.10).
Isso resultou do pacote sendo encaminhado pelo openvpn-a e chegando ao openvpn-b com um endereço de origem para o qual o openvpn-b não tinha uma rota.
Uma solução para este problema pode ser abordada de várias maneiras ... uma é adicionar uma rota ao lado 'a' da rede no openvpn-b, via dispositivo de túnel do openvpn-a:
openvpn-b:
root@openvpn-b# ip route add 192.168.10.0/24 via 10.8.0.1
Outra é configurar a rota padrão do openvpn-b para ser via dispositivo de túnel do openvpn-a:
openvpnb-b:
root@openvpn-b# ip route add default via 10.8.0.1
E ainda outro é configurar o NAT no dispositivo de túnel em openvpn-a:
openvpn-a:
root@openvpn-a# iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
O Wireshark e / ou o tcpdump podem ser usados com grande eficácia ao diagnosticar este problema. Como pode ser visto no dispositivo de túnel do openvpn-b quando um pacote chega e não há rota para a rede de endereço de origem:
root@openvpn-b# tcpdump -n -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
15:45:10.973251 IP 192.168.10.10 > 192.168.20.1: ICMP echo request, id 2550, seq 1, length 64
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel