Criando uma resposta anterior no tópico, foi assim que consegui resolver o problema no meu computador Ubuntu 17.10 (habilidoso) executando o OpenVPN 2.4.3.
1) Desativar filtragem de caminho reverso
Precisamos de alterar o encaminhamento do caminho inverso unicast para o modo solto ( rp_filter=2 ) em vez do modo estrito ( rp_filter=1 ). No modo estrito, um pacote de entrada deve ser recebido na mesma interface de rede que seria usada para encaminhar o pacote de retorno.
sysctl -w net.ipv4.conf.<if>.rp_filter=2
Onde <if> é a interface física de ethernet que o computador usa para se conectar ao roteador. No meu caso, o comando ficou assim: sysctl -w net.ipv4.conf.enp2s0.rp_filter=2 . Para ler o parâmetro do kernel, use sysctl net.ipv4.conf.<if>.rp_filter .
Para tornar a alteração persistente após uma reinicialização, adicione ou altere essa linha em /etc/sysctl.conf :
net.ipv4.conf.<if>.rp_filter=2
2) Defina o servidor OpenVPN para marcar pacotes criptografados
No arquivo .conf do servidor, adicione:
mark <value>
Em que <value> é um valor arbitrariamente exclusivo para marcar os pacotes. Isso permitirá o reencaminhamento dos pacotes criptografados pelo servidor OpenVPN. Eu usei mark 9 .
Reinicie o servidor OpenVPN.
3) Redirecione os pacotes marcados para o roteador com uma nova regra ip e rota ip
ip rule add fwmark <value> table <N>
ip route add default via <router> table <N>
Onde <N> é um número arbitrariamente exclusivo para a tabela de roteamento e <router> é o endereço IP do roteador na minha LAN. Em outras palavras, executei estes comandos: ip rule add fwmark 9 table 42 e ip route add default via 192.168.8.1 table 42 .
Tornar essas alterações persistentes após a reinicialização é mais complicado, especialmente com o Ubuntu 17.10, que usa o novo pacote netplan para gerenciar conexões de rede, em vez do tradicional arquivo /etc/network/interfaces . Por falta de uma solução melhor, adicionei uma série de comandos no arquivo de serviço systemd do OpenVPN. Isso criará a regra de ip e a rota antes que o OpenVPN seja iniciado: ExecStartPre=-/sbin/ip rule add fwmark 9 table 42 e ExecStartPre=-/sbin/ip route add default via 192.168.8.1 table 42 . Eu uso o sinal de menos - antes do caminho de comando para garantir que o servidor será iniciado mesmo se o comando falhar (no caso da regra ou rota já existir), consulte o página man systemd.service para obter mais informações.
Dica : Eu executo o servidor OpenVPN como um serviço systemd no meu computador, a melhor maneira de solucionar esse problema no meu caso foi aumentar o detalhamento do servidor OpenVPN no arquivo .conf para 6 e, em seguida, para usar journalctl -fu openvpn-server@<conf_file_name>.service para ver se a conexão pode ser estabelecida. Se a filtragem de caminho inverso não estiver desativada, você nem verá qualquer atividade quando os clientes tentarem se conectar. Depois de definir o rp_filter para 2 (etapa 1), pude ver alguma atividade, mas o handshake de TLS falharia. Depois que consegui redirecionar os pacotes do OpenVPN para o roteador (etapa 2-3), meus clientes puderam se conectar.
