Modifique o arquivo de configuração do servidor para incluir uma linha como a seguinte:
push "route 192.168.73.0 255.255.255.0"
onde 192.168.73.0/24 é a LAN por trás do servidor. Substitua com o que você usa. Aspas duplas must devem ser mantidas, não descartadas.
AVISO :
Os itens acima falharão se a LAN atrás do servidor e a LAN à qual o cliente pertence se sobrepuserem até certo ponto, e especialmente se eles usarem a mesma sub-rede : no exemplo acima, ele falharia se a LAN do cliente e a LAN do servidor fossem 192.168.73.0/255. Isso é um problema porque a maioria das LANs configuradas automaticamente é 192.168.1.0/24 ou 192.168.0.0/24, de modo que há muitas chances de encontrar uma colisão.
Esta é a razão pela qual eu configurei a LAN da minha casa como 192.168.73.0/24. Mudar a LAN para uma sub-rede incomum é o único remédio possível para tal colisão.
EDITAR:
Em resposta ao seu comentário:
-
a colisão não é entre a LAN atrás do servidor e os números IP distribuídos para os clientes openvpn, mas entre as duas LANs: seu cliente deve ter, em sua interface ethernet / wifi, um número IP que < strong> must não colidir com a LAN remota. Esqueça a sub-rede dos clientes openvpn.
-
Uma vez que o acima foi configurado, uma coisa que resta verificar é se o servidor pode transferir pacotes da interface virtual (estou pronto para apostar que é
tun0
no seu caso, nãotap0
, estou certo ) para a interface normal do servidor (aposto que é eth0, não br0). Isso pode acontecer por dois motivos:a. você não permitiu o encaminhamento IPv4. Como sudo,
echo 1 /proc/sys/net/ipv4/ip_forward
cuidará disso.
b. Você tem um firewall que bloqueia o encaminhamento de pacotes.
sudo iptables -F
limpará suas regras de firewall.
-
Por fim, lembre-se de usar o MASQUERADE, da seguinte forma:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.33.0/24 -j MASQUERADE