☰

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

tag-icon • tag-icon iptables routing openvpn tun
iptables: acesse o cliente openvpn conectado da LAN com o servidor VPN

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

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 fazer um ou mais dos seguintes:

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

Topologia

Nossa topologia de rede é mais ou menos 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á oscilando entre VPN1 e o gateway.

Responder1

Depois de outra rodada exaustiva de loucura de aprendizado on-line do iptables, descobri a solução.

Primeiro, porém, 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, ela sai da tabela. Como a tabela de filtros é assumida, a menos que seja especificada (por exemplo, "-t nat"), a maioria das regras listadas são executadas na tabela de filtros.

Em relação às correntes

  • ENTRADA: executado em pacotes destinados ao servidor
  • SAÍDA: executado em pacotes originados do servidor
  • AVANÇAR: todo o resto - se uma regra corresponder aqui, e o "salto" (gosto de pensar se-jcomo "job" ;) for ACCEPT, o pacote será roteado apropriadamente

Uma análise das regras

Esta é uma descrição das regras sobConfigurações atuaisacima

iptables -t filter -F
iptables -t nat -F

Estas regras simplesmente liberam ofiltroenaturaltabelas. Observe 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:

  • ele é executado em tráfego destinado à VPN1, não a outra rede
  • não há nenhuma política definida para o tráfego de entrada, por isso é permitido por padrão

se movendo...

iptables -A FORWARD -i tun+ -j ACCEPT

Esta regra permite que o tráfego proveniente de 10.8.8.0/24 seja roteado. Regras nonaturaltabela executada em pacotes que correspondem a esta regra.

iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24

Esta regra também não tem efeito no roteamento desejado, pois 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 de 10.10.10.0/16 pareça ter vindo da VPN1, fazendo com que a VPN1 pareça efetivamente um gateway.

O que está errado?

As regras devem estar "OK", pois permitem o tráfego de uma rede para outra. Não existe nenhuma proteção real - por exemplo, uma política padrão "DROP", etc., mas esse não é o objetivo da questão.

Se o iptables estiver configurado para poder rotear o tráfego pela VPN, o que faria com que ele fosse enviado de voltaeth0para o portal? Se VPN1 não soubesse sobre 10.8.8.0/24. Se o servidor VPN não conhecesse essa rede, ela seria tratada como tráfego da Internet e enviada de volta ao gateway.

O conserto

A solução foi informar ao servidor VPN sobre a rede (este é um servidor openvpn). Existem duas maneiras de fazer isso; se o servidor estiver 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 ficou mais parecida com esta:

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 será capaz de rotear o tráfego.

Uma configuração melhor do iptables

Depois de liberar o iptables, uma configuração melhor seria parecida com esta:

# 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 receber um IP na configuração da VPN e adicioná-los ao DNS para obter uma solução completa.

informação relacionada