Tropeçando nesta questão enquanto conduz outra pesquisa, parece que o OP está tentando acessar uma subnet que está conectada a um servidor OpenVPN remoto.
Minha resposta assume o modo túnel , não o modo em ponte . (O OpenVPN está agindo como um roteador , não um switch .)
Se o meu entendimento estiver correto, então um --client-config-dir ("CCD") deve ser usado neste caso. Deve haver uma diretiva route cobrindo o intervalo de endereços da sub-rede na configuração principal, e um iroute (observe o "i") em um arquivo CCD que será corretamente identificado como pertencente a isso remoto. (Você verá se é ou não reconhecido observando os logs do OpenVPN e confirmando que agora existe uma rota em sua máquina.)
Se você está acessando a sub-rede de outra sub-rede (ou seja, não da máquina que está executando o cliente OpenVPN, deve também ser uma rota estática dentro de sua sub-rede local) envia tráfego para sua máquina OpenVPN "como um gateway". Isso pode ser definido em cada máquina cliente ou, mais convenientemente, no roteador local.
E aqui está como o tráfego vai fluir:
- Você faz ping na sub-rede remota.
- Sua máquina ou seu roteador encaminha o tráfego para sua caixa OpenVPN como um gateway. (porque, funcionalmente, um túnel OpenVPN atua como um roteador).
- A diretiva
routenessa máquina faz com que o tráfego seja enviado para o dispositivotunXpara que o OpenVPN realmente receba o mesmo. - A diretiva
iroute(e o CCD no qual ela ocorre) informa ao OpenVPN que existe uma sub-rede remota e para qual controle remoto ela deve ser enviada. (mesmo que haja apenas um controle remoto). - O tráfego é encaminhado para o destino no lado remoto.
- E agora, tudo tem que acontecer ao contrário! O controle remoto envia a resposta de ping usando seu endereço IP na sub-rede remota, e ele tem que fazer o seu caminho todo o caminho de volta casa.
Se você pingar de uma máquina que esteja diretamente conectada ao OpenVPN (ele está executando o cliente) , seu endereço provavelmente será 10.8.0.x e este endereço- O intervalo também deve ser roteado com sucesso, "lá e de volta", em todos os dispositivos envolvidos.
Estes são "problemas básicos de roteamento TCP / IP", o que seria o caso se "o roteador em questão" fosse OpenVPN ou não. Depois que você conseguir que os hosts conversem com sucesso (yay!) , "para a rede, eles são apenas roteadores".
tcpdump (ou WireShark) e traceroute são seus melhores amigos aqui. Primeiro, você deve garantir que o tráfego criptografado esteja sendo entregue como deveria estar entre os hosts do OpenVPN. (Embora, é claro, você não consiga ler o conteúdo deles, você pode vê-los sendo roteados ou não.) Em seguida, faça as mesmas coisas dentro do túnel. Veja que os pacotes são entregues para e através do túnel, e que eles fazem todo o caminho de volta e . (Se traceroute começar a imprimir linhas de asteriscos, isso provavelmente significa que não há um roteamento reverso naquele determinado "salto". O pacote chega lá, mas não pode chegar em casa de lá.)