Eu encontrei a solução para isso. Não há necessidade de ter conexões VPN múltiplas / redundantes da maneira descrita na Resposta 1. Nem penso que teria feito qualquer coisa para resolver o meu problema, tanto quanto apreciei o feedback.
O problema se deve ao fato de que um servidor OpenVPN aceitará somente o tráfego IP através do túnel do cliente conectado, se o endereço IP de origem corresponder ao que o servidor atribuiu ao cliente quando o túnel foi estabelecido. O tráfego originado de qualquer outro endereço IP de origem que passar pelo túnel será completamente ignorado pelo servidor.
Veja o seguinte:
10.2.1.15 10.2.0.1/123.123.123.1 124.124.124.1/10.1.0.1 10.1.1.20
(eth0) (eth0/eth1) (eth0/eth1) (eth0)
---------- ------------- ------------ ----------
| Host A |-------------| Gateway 1 |------------------------------------------| Gateway 2 |--------| Host B |
---------- -------------- {INTERNET} ---------------- -----------
VPN CLIENT VPN SERVER
172.16.1.12 172.16.2.1
(tun0) (tun0)
Portanto, neste exemplo, "Gateway 1" é o cliente VPN que estabelece um túnel para o "Gateway 2" como o servidor VPN. O que queremos realizar é a capacidade do Host A de se comunicar com o Host B através da VPN. Portanto, configuramos uma conexão padrão do OpenVPN, com o Gateway 1 como um cliente para o servidor do Gateway 2. Cada gateway tem uma interface "pública" e "privada". Um para a rede privada e outro para a Internet pública. Quando a conexão VPN é estabelecida, cada servidor está usando uma interface "tun0" adicional. O Gateway 2, atuando como o servidor VPN, solicita a conexão do gateway 1 e atribui a ele um IP de 172.16.1.12.
O problema é que o Gateway 2 só aceitará tráfego através do túnel VPN se o IP de origem for 172.16.1.12 .
Isso funciona bem quando Gateway 1 quer se conectar ao Host B, mas é um problema quando Host A tenta se conectar ao Host B. Quando o Host A tenta conecte-se, o Gateway 1 atua como um roteador e roteia o tráfego corretamente através do túnel VPN para o Gateway 2 (supondo que você tenha suas rotas configuradas corretamente). Se você executar o tcpdump no dispositivo tun0 do Gateway 1, você verá o tráfego do Host A passando pelo túnel, destinado à outra rede. Mas o Gateway 2 vê o endereço IP de origem como 10.2.1.15 , o qual não corresponde ao endereço IP que ele designou para a conexão, e o ignora completamente.
Portanto, a solução é configurar o Gateway 2 para aceitar o tráfego da rede 10.2.0.0/16 através do túnel VPN. O servidor VPN precisa ser configurado com uma configuração iroute . O procedimento para configurar isto e todos os parâmetros de configuração são explicados no site oficial da OpenVPN aqui então não vou re-explicar isso neste post.
Eu sugiro que quando você ler esta documentação, note que você precisa usar o diretório de configuração do cliente (CCD) em sua configuração OpenVPN para usar iroute . Certifique-se de ler essa parte da documentação com cuidado. Você também precisará, claro, configurar rotas em todos os seus gateways, para que eles saibam como rotear o tráfego através do túnel VPN. Referenciando o diagrama acima, você ainda precisaria adicionar uma rota no Gateway 2 desta forma:
route add -net 10.2.0.0 netmask 255.255.0.0 gw 172.16.1.12 tun0
e no Gateway 1 assim:
route add -net 10.1.0.0 netmask 255.255.0.0 gw 172.16.2.1 tun0
Para que o tráfego do Host B seja roteado adequadamente pela VPN ao tentar se conectar ao Host A.
No meu caso particular, o Gateway 1 está agindo como um cliente para o Gateway 2, mas também como um servidor para outros clientes que se conectam da Internet que precisam de acesso ao Host A. Então, eu precisava criar duas interfaces, tun0 e tun1, para que uma pudesse ser usada para a conexão do cliente com a outra rede, e a outra poderia ser usada como um servidor para os guerreiros da estrada se conectando. Eu também preciso adicionar rotas adicionais , para que eu possa estabelecer uma conexão VPN com o Gateway 1 (servidor) da Internet, e posso rotear o tráfego para o Host B na outra rede.
Espero que isso ajuda os outros que estão confusos sobre isso.