Resumo:
-
A LAN remota é 192.168.0.0/24.
-
A rede OpenVPN é 10.8.0.0/24.
-
Seu cliente OpenVPN obtém um IP em 10.8.0.0/24. Vamos supor que seja 10.8.0.42.
Tentando conversar com a LAN remota:
-
Quando seu cliente OpenVPN envia um pacote para um IP na LAN remota (digamos 192.168.0.56), ele é enviado com o endereço de origem 10.8.0.42 e alcança o servidor OpenVPN.
-
O servidor OpenVPN o descarta a menos que você tenha habilitado o encaminhamento de IP
sysctl -w net.ipv4.ip_forward=1
). -
Se o encaminhamento de IP estiver ativado, 192.168.0.56 recebe o pacote e tenta responder enviando pacotes para 10.8.0.42, mas ele não tem uma rota para ele. Em vez disso, usa o gateway padrão. A menos que o servidor OpenVPN seja o gateway padrão, o pacote será perdido. Você pode verificar a rota na máquina remota com
ip route get 10.8.0.42
.
Soluções possíveis:
-
adicione uma rota para 10.8.0.0/24 em cada nó na LAN (
ip route add 10.8.0.0/24 via $ip_of_vpn_server
); -
adicione uma rota para 10.8.0.0/24 no gateway padrão
-
os pacotes farão um salto inútil para o roteador em vez de alcançar diretamente o servidor OpenVPN;
-
mas
send_redirects
está habilitado no roteador eaccept_redirects
está habilitado nos nós da LAN, o roteador enviará um redirecionamento ICMP para indicar uma rota melhor e os nós da LAN deverão usar essa rota posteriormente ;
-
-
configure o NAT no servidor OpenVPN para ocultar os endereços 10.8.0.0/24.
O mesmo problema acontece ao tentar acessar o IP público do seu cliente OpenVPN:
-
se você usou a primeira ou segunda solução, certifique-se de que 10.8.0.0/24 esteja corretamente NATed pelo roteador da LAN remota;
-
se você usou NAT no servidor OpenVPN, não precisa fazer mais nada.
Eu sugeriria usar a segunda solução. Quanto menos NAT você tiver, melhor.