Eu configurei o OpenVPN entre meu trabalho e minha casa. Ele usa certificados (não chaves pré-compartilhadas), está no modo tun e funciona muito bem. As redes ficam assim:
Tenho rotas adequadas configuradas para enviar e receber tráfego, e o cliente não tem problemas para se comunicar com 192.168.80.1 (o IP do túnel do servidor) ou com qualquer coisa na rede 192.168.5.0/24 (trabalho), o que é ótimo.
O único problema que estou tendo é que o cliente não consegue conversar, nem pingar 192.168.5.10 (o IP do servidor na rede de trabalho).
iptables não está bloqueando nada. Há alguma configuração de segurança do OpenVPN ou configuração do Linux que estou perdendo?
Responder1
A resposta é provavelmente porque o ping usou oerradoIP de origem para o pacote ICMP. Por padrão ele escolherá o IP na interface de saída do pacote. No seu caso será 192.168.80.1 no Trabalho e 192.168.80.10 em Casa.
Em vez disso, tente o seguinte:
ping -I eth0 <address>
Responder2
Finalmente descobri meu problema. Não teve nada a ver com o OpenVPN em si e não foi possível resolver dadas as informações acima. Caso alguém se depare com isso, foi assim que acabou sendo:
Meu servidor OpenVPN está conectado a 2 redes diferentes e executa 2 instâncias diferentes do OpenVPN - uma escutando em uma interface e outra escutando na outra interface. Uma das interfaces está no meu diagrama (192.168.5.10), enquanto a outra não está - vamos chamá-la de 192.168.4.10.
Para fazer isso funcionar, tenho regras de roteamento baseado em políticas que dizem "se os pacotes tiverem um IP de origem 192.168.5.10, envie-os para o roteador 192.168.5.1" e "se os pacotes tenham um IP de origem 192.168.4.10, envie-os para o roteador 192.168.4.1". Isto significa que quando as conexões OpenVPN estão sendo estabelecidas, elas funcionam corretamente.
O problema é que quando eu ping 192.168.5.10 de dentro do túnel, os pacotes de retorno atingem a mesma regra PBR e são enviados para 192.168.5.1 em vez de voltarem para fora do túnel. Uma mudança nas minhas regras PBR corrigiu isso.