Depois de outra rodada exaustiva de loucura on-line, descobri a solução.
Primeiro, no entanto, há uma suposição inválida em relação ao iptables. Minha abordagem inicial às regras era que, quando um pacote fosse recebido, ele passaria pelas cadeias INPUT e OUTPUT. Não tão; No minuto em que uma regra corresponde a um pacote, ele sai da tabela. Como a tabela de filtros é assumida, a menos que seja especificada (por exemplo, "-t nat"), a maioria das regras listadas é executada na tabela de filtros.
Em relação às cadeias
- INPUT : executado em pacotes destinados ao servidor
- OUTPUT : executado em pacotes originados no servidor
- FORWARD : todo o resto - se uma regra corresponde aqui, e o "salto" (eu gosto de pensar se -j como "trabalho";) é ACCEPT, o pacote irá ser roteado de forma adequada
A discriminação das regras
Esta é uma descrição das regras em Configurações atuais acima
iptables -t filter -F
iptables -t nat -F
Essas regras simplesmente liberam as tabelas filtro e nat . Note que existem mais tabelas e uma maneira mais completa de limpar as regras do iptables.
iptables -A INPUT -i tun+ -j ACCEPT
Esta regra não faz nada porque:
- é executado no tráfego destinado a VPN1, não a outra rede
- não há política definida para o tráfego de entrada, por isso é permitido por padrão
seguindo em frente ...
iptables -A FORWARD -i tun+ -j ACCEPT
Esta regra permite que o tráfego proveniente de 10.8.8.0/24 seja roteado. As regras na tabela nat são executadas em pacotes que correspondem a essa regra.
iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
Esta regra também não tem efeito sobre o roteamento desejado, uma vez que o tráfego 10.8.8.0/24 não é destinado ao servidor VPN1.
iptables -A FORWARD -i eth0 -j ACCEPT
Esta regra permite que o tráfego de 10.10.10.0/16 seja roteado.
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE
Esta regra faz com que o tráfego destinado à VPN a partir de 10.10.10.0/16 pareça ter vindo da VPN1, efetivamente fazendo com que a VPN1 pareça um gateway.
O que há de errado?
As regras devem ser "OK", assim como para obter tráfego de uma rede para outra. Não há nenhuma proteção real no lugar - por exemplo, uma política padrão "DROP", etc, mas esse não é o ponto da questão.
Se o iptables estiver configurado para que possa rotear o tráfego pela VPN, o que faria com que ele fosse enviado de volta por eth0 para o gateway? Se VPN1 não sabia sobre 10.8.8.0/24. Se o servidor VPN não estivesse ciente dessa rede, seria tratado como tráfego da Internet e enviado de volta ao gateway.
A correção
A solução foi informar ao servidor VPN sobre a rede (este é um servidor openvpn). Existem duas maneiras de fazer isso; se o servidor está servindo apenas uma rede, é uma configuração simples:
server 10.8.8.0 255.255.255.0
No meu caso, eu tinha a rota do servidor configurada e precisava saber sobre uma rede adicional. A configuração parecia mais com isso:
server 10.5.5.0 255.255.255.0
route 10.8.8.0 255.255.255.0
É isso! Depois que a VPN1 tiver uma rota para a rede, a cadeia FORWARD poderá rotear o tráfego.
Uma configuração melhor do iptables
Depois de fluir o iptables, uma configuração melhor seria algo como isto:
# Forward established traffic so that (in the above case) VPN1 doesn't
# drop responses from the client, A.K.A. "the magic"
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -s 10.10.10.0/16 -d 10.8.8.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -j MASQUERADE
# Drop everything else that wants to be forwarded
iptables -P FORWARD DROP
Observe que não há regras explícitas para o tráfego proveniente de 10.8.8.0/24, o que significa que, por padrão, o tráfego não alcançará a rede 10.10.10.0/16 - exceto o tráfego em resposta ao tráfego enviado de 10.10. 10,0 / 16. Agora que o iptables está configurado, os clientes podem ser atribuídos a um IP na configuração da VPN e adicionados ao DNS para uma solução completa.