Configurando IPTables

4

Estou tentando remover um roteador do nosso produto e substituindo todas as suas funcionalidades pelo uso do iptables.

O sistema é necessário para executar o controle de tráfego geral, bem como encaminhar dados para servidores específicos localizados atrás da LAN. A configuração atual é -

  • eth0 - externo
  • eth1 - interno
  • eth2 - interno
  • eth3 - interno

eth0 obtém um IP via DHCP.

eth1, eth2 e eth3 fazem parte de uma ponte (br0) que possui um endereço estático de 10.0.1.1.

Existe um servidor localizado no 10.0.1.2 que precisa de servidor HTTP e tráfego MySQL. Não há garantia de onde este servidor será conectado (eth1 / 2/3), mas o IP é estático.

Eu tentei configurar as regras do iptables, que parecem ser fáceis de seguir com apenas um único dispositivo eth, mas estou ficando preso quando o encaminhamento é necessário.

Isso é o que eu tentei até agora:

# clear and flush everything
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t raw -F
iptables -t raw -X
iptables -t security -F
iptables -t security -X

# DROP packets unless covered by rules
iptables -P FORWARD DROP
iptables -P INPUT   DROP
# No intention of filtering any outgoing traffic
iptables -P OUTPUT ACCEPT

# Handle our routing
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80   -j DNAT --to 10.0.1.2:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3306 -j DNAT --to 10.0.1.2:3306

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Input Chain
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0     -p tcp --dport 22   -j ACCEPT   # ssh
iptables -A INPUT -s 10.0.1.2 -p tcp --dport 3306 -j ACCEPT   # ssh

# Forward Chain
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 80   -d 10.0.1.2 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 3306 -d 10.0.1.2 -j ACCEPT

# enable ipv4 forwardning for the system
echo 1 > /proc/sys/net/ipv4/ip_forward

Isso me dá a configuração da cadeia / regra resultante -

Chain INPUT (policy DROP 1 packets, 49948 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    1    52 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       10.0.1.2             0.0.0.0/0            tcp dpt:3306

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            10.0.1.2             tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            10.0.1.2             tcp dpt:3306

Chain OUTPUT (policy ACCEPT 1 packets, 196 bytes)
 pkts bytes target     prot opt in     out     source               destination   

No entanto, não consigo entrar no meu servidor MySQL interno por meio de um cliente conectado por meio da interface externa (fora da caixa do firewall).

Eu li que os pacotes só passam por cada cadeia ONE (INPUT / FORWARD / OUTPUT), mas este ainda é o caso aqui? Meus pacotes FORWARD, então, serão tratados novamente como INPUT em uma interface separada?

Existe alguma coisa que se destaca como errada em alguma das configurações acima?

Detalhes da configuração -

Saída de netstat -rn

De um cliente que eu CAN conecto de ...

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.139      0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 br0

Telnet conecta como esperado.

De um cliente que eu CANNOT conecto de ...

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.139      0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U         0 0          0 wlan0

O Telnet exibe apenas Trying 10.0.0.17... e nunca é bem-sucedido ...

Descrição da (s) rede (s) -

10.0.0.0 é a rede geral do escritório e a interface eth0 na caixa do firewall está conectada aqui. Seu endereço IP é atualmente 10.0.0.17 ...

10.0.1.0 é a rede que deve estar por trás do firewall eth1 / 2/3.

Eu quero acessar os servidores que estão atrás do firewall usando o endereço IP dado a eth0 (10.0.0.17).

    
por juansta 06.08.2014 / 09:04

1 resposta

5

Como você lista um cliente que pode se conectar, não há nada de errado com sua iptables setup. Isso, no entanto, não é a história completa: os clientes devem ter uma rota para alcançar o endereço encaminhado do servidor, e o servidor deve ter uma rota de volta, para que os pacotes cheguem até o FORWARD.

O cliente que trabalha tem alguma presença física na rede 10.0.1.0/24 e, consequentemente, uma rota para a mesma:

10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 br0

O cliente que não só não tem rota para 10.0.1.0/24, mas também tem uma rota mais geral para 10.0.0.0/16 enviando tráfego para sua placa sem fio.

Agora você não nos contou a geometria da rede em que tudo isso está acontecendo; da confusão entre / 24 e / 16 netmasks para sobreposição de espaço, eu estou supondo que é tudo um pouco confuso (isso não é uma garantia; há razões legítimas para fazer isso, mas eles geralmente são superados pelos tolos). Além disso, os detalhes da sua rede são interessantes apenas para você.

Mas o resultado é que qualquer cliente que queira chegar até 10.0.1.2 deve, antes de tudo, ter alguma idéia de como chegar a 10.0.1.0/24 e, além disso, deve ser uma idéia correta.

Corrija as tabelas de roteamento nos seus clientes de maneira consistente com a geometria da sua rede, e tudo deve melhorar.

    
por 06.08.2014 / 09:36