iptables: acessa o cliente openvpn conectado da LAN com o servidor VPN

3

Eu tenho o que é essencialmente um problema de roteamento, e não estou familiarizado o suficiente com roteamento e iptables para solucionar problemas e configurar efetivamente minhas necessidades de rede.

O que está funcionando

Eu tenho uma rede openVPN configurada e funcionando; os clientes podem se conectar a uma LAN através da Internet.

O que eu gostaria que acontecesse

... quando um cliente se conecta à VPN em uma determinada sub-rede.

  • O cliente deve estar acessível a partir da rede VPN

Pontos de bônus se as regras puderem executar uma ou mais das seguintes ações:

  • o cliente não deve poder iniciar conexões com a VPN
  • o cliente deve aparecer em nosso DNS

Topologia

Nossa topologia de rede se parece com algo assim:

   ______        ____________________
 /        \     /                    \
| internet |---| client (10.8.8.0/24) |
 \________/     \____________________/
     |
   ______
 /        \
| gateway  |
 \________/
     |
-----LAN------ (10.10.10.0/24)
|    |   |   |
             L_____VPN Server 'VPN1' 10.10.10.2 (fictional name/subnet)

Configurações atuais

Nosso gateway tem a seguinte rota definida:

10.8.8.0    255.255.255.0   10.10.10.2  LAN & WLAN

Em VPN1 , o iptables tem as seguintes regras

# Flush the filter and nat tables
iptables -t filter -F
iptables -t nat -F

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE

O que está acontecendo atualmente

A execução do comando mtr 10.8.8.1 (o IP do cliente conectado na VPN) mostra que a rota atual está indo e voltando entre a VPN1 e o gateway.

    
por jobu1324 19.12.2013 / 17:37

1 resposta

1

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.

    
por 20.12.2013 / 19:16