Fernando Cesario wrote:
> Os testes feitos sao pings para o proprio ip de maquinas externas.
> Sim existe um grande e unico motivo hoje a maioria dos meus servidores
> de internet estao publicados diretamente com IP VALIDO entao o que eu
> preciso fazer e fazer o cadastro dos meus ips validos no meu firewall
> e ai ao invez do servidor estar com esse ip valido ele fica no
> firewall e eu faco o encaminhamento pro ip da lan.

Ok, essa configuração é estranha. Acredito que algum daemon em execução
(NetworkManager?) esteja removendo o IP da interface, ou alguma rota da
tabela de rotas.

Em geral, você não precisa de aliases de interfaces para apenas ter um
IP adicional numa interface. O Linux permite que uma mesma interface
tenha vários endereços IP, sem precisar criar aliases:

        ip addr add 200.205.182.94/26 dev eth1
        ip addr add 200.205.182.68/26 dev eth1

Você só deve criar aliases se você precisa de uma unidade de roteamento
adicional (geralmente como origem de rota), e mesmo assim, ainda é
preferível usar o parâmetro 'src' para o 'ip route'. Na imensa maioria
dos casos, o uso de aliases é desencorajado.

> cat /etc/network/interfaces
> (...)
> iface eth1 inet static
>       address 200.205.182.94
>       netmask 255.255.255.192
> 
> iface eth1:1 inet static
>       address 200.205.182.68
>       netmask 255.255.255.192

Eu não estou familiarizado com a sintaxe da configuração de interfaces
de rede do Debian. Verifique se não é possível atribuir mais de um
endereço IP para a mesma interface.

Procure não usar 'route', e passe a usar 'ip route'. O comando 'route'
faz parte de uma interface obsoleta do Linux, mantida apenas para manter
compatibilidade com scripts antigos. O comando 'ip' e todos os seus
subcomandos são a maneira mais moderna de interagir com o subsistema de
redes do Linux.

Pelo que eu entendi: Os IPs públicos do seu roteador são 200.205.182.94,
200.205.182.68 e 200.212.230.3. Na sua rede interna ele é 192.168.10.30,
e há diversas outras subredes da sua LAN que você acessa passando por um
outro roteador 192.168.10.1.

Algumas conexões ao endereço 200.205.182.94 são redirecionados para um
outro servidor, 192.168.14.4, que está em outra sub-rede (para chegar
até esse servidor você tem que passar pelo 192.168.10.1).

Outras conexões, para o endereço 200.205.182.68 são redirecionadas para
192.168.30.1, que também está em outra sub-rede. Em momento nenhum você
utiliza este IP como origem de rota, já que o redirecionamento é criado
por uma regra DNAT do iptables.

> firewall:~# route -n

Sugestão:
        ip route list


Problema 1: Você tem duas rotas de saída, com a mesma métrica, em duas
interfaces diferentes (eth1 e eth2), tem certeza de que isso está certo?

> 0.0.0.0         200.212.230.1   0.0.0.0         UG    0      0        0 eth2
> 0.0.0.0         200.205.182.65  0.0.0.0         UG    0      0        0 eth1


Problema 2: Você tem duas rotas para atingir 192.168.10.0/24, uma
vizinha e uma via 192.168.10.1. Isso definitivamente não pode estar correto:

> 192.168.10.0    192.168.10.1    255.255.255.0   UG    0      0        0 eth0
> 192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0


Você está gerenciando um número muito grande de sub-redes,
desnecessariamente. Isso é ótimo para causar problemas, especialmente
por descuido humano. Você deve ter sua rede estruturada na forma de uma
árvore (talvez com raras exceções), e então fazer os IPs seguirem esta
mesma árvore. Todas essas sub-redes (192.168.9.0/24, de ..11.0/24 até
..21.0/24, ..30.0/24, ..50.0/24, ..95.0/24 e ..100.0/24) estão indo numa
única direção (via 192.168.10.1). Isso é um bom indício de que as
numerações de todas elas estão erradas.

Se você rearranjar todas estas redes com numeração a partir de
192.168.128.0/24, então você poderá ter uma única rota para
direcioná-las todas para o roteador em questão:

  ip route add 192.168.128.0/23 via 192.168.10.1 dev eth0

Se existirem mais ramificações, aplique o mesmo princípio recursivamente
nos roteadores seguintes.

> echo "1" > /proc/sys/net/ipv4/ip_forward
> echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Sugestão:
        sysctl net.ipv4.ip_forward=1
        sysctl net.ipv4.icmp_echo_ignore_broadcasts=1

> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp -d 200.205.182.94
> --dport 80 -j DNAT --to 192.168.14.4:80
> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp -d 200.205.182.94
> --dport 110 -j DNAT --to 192.168.14.4:110
> (...)

Não poderia ser atribuído um IP verdadeiro a este servidor, e direcionar
todo o tráfego (possivelmente filtrado) diretamente para o servidor?
Remove-se o NAT para esse servidor em questão, deixando apenas o
firewall. Não é muito legal dois hosts (firewall e o servidor em
questão) compartilharem o mesmo endereço IP.

> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp -d 200.205.182.68
> --dport 80 -j DNAT --to-destination 192.168.30.1:80

Idem.

> /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Isso está errado. Sequer faz sentido para a sua rede. O correto deveria ser:

iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j SNAT
--to-source 200.205.182.94

Isso, é claro, supondo que você tenha UMA rota de saída (aqui estou
considerando a eth1). Precisa determinar o que aquela segunda rota de
saída para eth2 está fazendo lá.

> Acredito que agora contenha todas informações necessario para entender
> o pq desse problema.

Pode ser uma entre muitas coisas... a primeira, listada exaustivamente
acima, é remover as ambiguidades da sua rede. Depois que não tiver mais
ambiguidades, aí fica mais fácil achar o problema.

Depois que os problemas acima estiverem resolvidos, se o problema
aparecer novamente, seria bom uma listagem de rotas (ip route list) e de
endereços (ip addr list) antes e depois de enfrentar o problema (para
saber se algum daemon está mexendo nas rotas), e também observar como
seu firewall responde via 'arping' de cada uma das interfaces.

Att,
Juliano.


-- 
Juliano F. Ravasi ·· http://juliano.info/
5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96

"A candle loses nothing by lighting another candle." -- Erin Majors

* NOTE: Don't try to reach me through this address, use "contact@" instead.
---------------------------------------------------------------------------
Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br

Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br
Regras de utilização da lista: http://linux-br.conectiva.com.br
FAQ: http://www.zago.eti.br/menu.html

Responder a