Você perguntou: " Alguém pode explicar por que esse problema ocorre em primeiro lugar? "
Com base no que é relatado nas perguntas frequentes oficiais do OpenVPN , aposto que é causado por um problema de roteamento no mecanismo OpenVPN.
Para esclarecer melhor o cenário, deixe-me consultar o seguinte diagrama:
Aqui você pode ver:
- um "servidor" OpenVPN conectado à rede interna do HEADQUARTER (10.0.1.0/24)
- um "cliente" do OpenVPN em execução em um site remoto e conectado à rede remota 192.168.1.0/24
Além disso
- estamos assumindo que o túnel OpenVPN esteja estabelecido e:
- O "servidor" do OpenVPN é acessível através de sua própria interface tun , com o endereço 10.10.0.1. Também o endereço P2P, usado pela interface tun é 10.10.0.2 ( isso é importante para discussões posteriores, então vamos enfatizá-lo )
- O "cliente" do OpenVPN possui uma interface tun com IP 10.10.0.2
Agora, vamos supor que:
- o "Cliente" do OpenVPN redefiniu seu gateway padrão, para redirecionar dentro do túnel todo o tráfego IP de saída;
- o "Cliente" do OpenVPN tem IP_FORWARDING ativado e, como tal, pode rotear pacotes provenientes de sua LAN interna (192.168.1.0/24) ( estou enfatizando esse ponto, pois é fundamental para a nossa discussão ).
Com esse cenário, vamos verificar em detalhes o que acontece quando R_PC1 (192.168.1.2) envia um pacote, como uma solicitação de eco, para L_PC1 (10.0.1.2):
- depois de sair da placa de rede R_PC1, o pacote chega ao cliente OpenVPN;
- O cliente OpenVPN (que está configurado para atuar como um roteador comum), direciona-o de acordo com sua tabela de roteamento. Como o gateway padrão é o túnel, ele envia o pacote para o túnel;
- Os pacotes atingem a interface tun do servidor OpenVPN. O OpenVPN "o verá" e, como (servidor OpenVPN) sabe que 10.0.1.2 é um endereço pertencente à sua sub-rede LAN, "encaminha" o pacote, de TUN para LAN;
- Alcance do pacote L_PC1.
Então está tudo bem ...
Agora vamos verificar o que acontece com a resposta de eco que L_PC1 responde a R_PC1.
- a resposta de eco sai da placa de rede L_PC1 e alcança a interface LAN do servidor OpenVPN (10.0.1.1);
Agora, se queremos que o OpenVPN Server possa acessar o site remoto, precisamos definir o roteamento com uma "rota estática". Algo como:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2
Observe o endereço P2P usado como gateway .
Essas rotas estáticas funcionarão no nível do SO. Em outras palavras, é necessário que o sistema operacional roteie adequadamente o pacote. Significa algo como: "Por favor, todo o tráfego endereçado à sub-rede 192.168.1.0/24 precisa ser encaminhado para o mecanismo OpenVPN, com quem o sistema operacional pode falar através do endereço P2P". Graças a essa rota estática, agora ...
- o pacote sai do contexto de roteamento do SO e alcança o OpenVPN. A instância do OpenVPN em execução no servidor OpenVPN. Portanto, neste ponto, o sistema operacional não tem mais nada a fazer e todo o roteamento (dentro da VPN) é deixado para o software do servidor OpenVPN.
Então, agora, o problema é: como, o software do servidor openvpn, poderá decidir a rota de um pacote, com SRC_IP 10.0.1.2 e DST_IP 192.168.1.2 ?
Observe que, com base na configuração do servidor OpenVPN, ele não sabe nada sobre a rede 192.168.1.0/24, nem sobre o host 192.168.1.2. É não um cliente conectado. É não um cliente local. E entao? OpenVPN, também, sabe que é não o "OS-Router", então ele realmente não quer (e pode ....) enviar a parte de trás do pacote para o gateway local. Portanto, a única opção, aqui, é gerar um erro. Exatamente o erro que você está enfrentando
Para dizê-lo com o idioma da FAQ: " ... ele não sabe como rotear o pacote para esta máquina, então ele solta o pacote ... ".
Como podemos resolver o problema?
Como você pode ver na documentação oficial , a opção iroute serve exatamente para o nosso escopo:
--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server
to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to the
system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.
Então você precisa de:
--iroute 192.168.1.0 255.255.255.0
a ser aplicado (ao servidor) quando o seu cliente OpenVPN se conectar, por exemplo, através de um arquivo de configuração ad-hoc definido no servidor (client-config-dir, etc.).
Se você se perguntar por que esse problema não ocorre na etapa 2) acima, meu entendimento é que o OpenVPN Client sabe como rotear isso, porque sabe que o túnel da VPN é um gateway padrão.
O mesmo não pode ser feito no servidor OpenVPN, porque o gateway padrão normalmente não é substituído. Além disso, considere que você poderia ter um único servidor OpenVPN com bastante cliente OpenVPN: cada cliente sabe como acessar o servidor, mas ... como o servidor pode decidir qual é o cliente que atua como gateway para uma sub-rede desconhecida?
Quanto à sua primeira pergunta ( as regras necessárias podem ser escritas de maneira genérica / única? ), Desculpe-me, mas não estou tendo muito problema. Você pode reformular o fornecimento de mais detalhes?