Roteamento: Maquina da rede interna sendo acessada pela internet.

[danistation]

Caras,

Estou trocando um servidor IPTABLES+DHCP. A máquina velha (em funcionamento hoje) está com FC2 e os serviços/configs da sua época.

A máquina nova que estou trocando está com FC8 toda atualizadinha e com os 2 serviços instalados.

A topologia segue:
http://img182.imageshack.us/img182/5...uvidxx4.th.png

DETALHE: O SERVIÇO DE DHCP NA MÁQUINA NOVA ESTÁ PARADO PARA NÃO DAR CAGADA COM A MÁQUINA VELHA!!!

Cara, ainda to quebrando um pouco a cabeça com esse papo de iptables, roteamento e tals. Eu sou novato no quesito servidores e preciso muito da ajuda dos amigos para aproveitar a oportunidade que estão me dando aqui no trampo.

Bem, vamos aos detalhes:

MAQUINA IPTABLES VELHA:
No script /etc/rc.d/init.d/iptables foram adicionadas algumas linhas que fazem:
- o compartilhamento da internet na eth1 para a eth0;
- o roteamento de saída da eth0 (porta 80 apenas) para o servidor com squid;
- o roteamento de algumas máquinas na rede interna, para serem acessadas pela internet.

Já no arquivo de configuração em /etc/sysconfig/iptables:
- tabela *filter com a liberação de algumas portas, etc.

Está tudo funfando de boa.

Lendo em muitos lugares, descobri que eu poderia colocar a tabela *nat no mesmo aquivo em /etc/sysconfig/iptables, ao invés de mantê-lo no script original do iptables em /etc/rc.d/init.d/iptables. Fiz isso na máquina de IPTABLES NOVA para ficar mais elegante, script de um lado e arquivo de configuração no outro. Reparei também, que nessa versão do fedora (FC8), os flags de /proc/sys/net/ipv4/ip_tables e /etc/sysctl.conf (net.ipv4.conf.default.rp_filter) já estavam, por padrão, inicializados com 1.

O que acontece, toda vez que reinicio esse servidor novo, o script de iniciazliação do iptables lê o arquivo de configuração /etc/sysconfig/iptables e beleza, tudo no lugar.

Quando passei a fazer o MASQUERADE na máquina nova, também funfou de boa apenas alterando o arquivo de configuração. Depois, acrescentei a regra para que, toda a conexão de saída pela porta 80 da rede interna, fosse desviada para o servidor que tem squid instalado. Beleza, funfou de boa!! Por último fui testar o acesso à uma máquina da rede interna, pela internet. Fiz o seguinte: Nessa máquina nova criei 2 alias (210.200.200.223 e 210.200.200.224) na eth1 com IPs válidos e que não estão sendo utilizados pela empresa, claro. Beleza, assim, essa máquina nova passou a responder os pings por esses IPs, da mesma maneira que está a máquina velha. Até aím, sem novidades, tudo OK.

Testei então adicionar a regra PREROUTING para quando chegasse requisições na porta 80 para o IP externo 210.200.200.223 (configurado como alias da eth1 da maquina nova) fosse roteado para a minha máquina, na rede interna, com o IP 192.168.1.25. Maravilha, funcionou de prima. Testei tanto de outras máquinas da rede interna, como de outros servidores que estão antes do router, além de pedir que colegas da maztriz que fica em outro prédio looonge daqui também acessassem a minha máquina com esse IP novo e beleza. Funcionou perfeitamente.

Agora, a cagada: Quando altero o arquivo de configuração e faço com que o roteamento não vá mais para a minha máquina (192.168.1.15) e sim para a máquina correta (192.168.1.16) que já está sendo roteada pelo servidor antigo, apenas esse roteamento não funciona nem a pau. Vou fazer um teste hoje à noite desligando o servidor de ITPABLES velho, deixando apenas esse novo que estou terminando para ver no que dá.

segue o arquivo de configuração do IPTABLES:

# Generated by iptables-save v1.4.1.1 on Mon Sep 8 17:44:01 2008

*filter

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

#Olha o que descobri!! O tal do RH-Firewall-1-INPUT é apenas uma TAG!!
# Vou utilizar a seguinte TAG que pelo menos não quebra a linha
# na hora de consultar o arquivo no shell. Apenas trocando o nome
# RH-Firewall-1-INPUT.... para TESTE-FW
:TESTE-FW - [0:0]

# Redirecionando todos os INPUTs e FORWARDs para a regra personalizada.
-A INPUT -j TESTE-FW
-A FORWARD -j TESTE-FW


# Filtrando os INPUTs E FORWARDs, igualmente.
#liberadno INPUT e FORWARD para a interface 'lo'
-A TESTE-FW -i lo -j ACCEPT

#liberando INPUT e FORWARD para a interface 'eth0' (rede interna)
-A TESTE-FW -i eth0 -j ACCEPT

#liberando INPUT e FORWARD para a rede '192.168.1.0'
-A TESTE-FW -s 192.168.1.0/24 -j ACCEPT
-A TESTE-FW -d 192.168.1.0/24 -j ACCEPT

#liberando INPUT e FORWARD para o protocolo ICMP para qualquer interface
-A TESTE-FW -p icmp --icmp-type any -j ACCEPT

#liberando INPUT e FORWARD para conexoes com o estado abaixo
-A TESTE-FW -m state --state RELATED,ESTABLISHED -j ACCEPT

#negando INPUT e FORWARD para o protocolo ICMP no estado abaixo
-A TESTE-FW -j REJECT --reject-with icmp-host-prohibited

#liberando portas
-A TESTE-FW -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A TESTE-FW -p tcp --dport 80 -j ACCEPT
COMMIT



*nat

# Regra padrão para NAT
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Compartilhando a rede da 'eth1'
-A POSTROUTING -o eth1 -j SNAT --to 210.200.200.218

# Desviando o fluxo da eth0-porta 80 para o servidor squid
-A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 210.200.200.212:3128


#### O PROBLEMA ESTÁ AGORA! QUANDO A ROTA É PARA MINHA MÁQUINA (192.168.1.25)
#### FUNFA DE BOA, DE QUALQUER LUGAR. MAS QUANDO ALTERO PARA O IP 192.168.1.16
#### QUE EJÁ ESTÁ SENDO ROTEADO PELO SERVIDOR VELHO, ESSE ROTEAMENTO NÃO
#### FUNCIONA MAIS. APENAS O QUE JÁ ESTÁ NA MÁQUINA VELHA FICA FUNCIONANDO...
# DNAT para o servidor da rede interna na porta 80 apenas
-A PREROUTING -p tcp -m tcp --dport 80 -d 210.200.200.223 -j DNAT --to 192.168.1.16:80
COMMIT


Antemão, além de deixar uma mostra interessante de topologia, distribuição de serviços, roteamento e regras, gostaria de saber o seguinte:

1- por que tá dando essa cagada? Será por causa de ter duas máquinas fazendo o mesmo serviço, apesar de trabalharem com IPs de origem diferentes e apenas os IPs de destino iguais???

2- por que é raríssimo encontrar na internet tutoriais para configuração de IPTABLES que trabalham sempre em cima de scripts e não do próprio arquivo de configuração localizado em /etc/sysconfig/iptables?

Colegas, se o texto que escrevi ficou confuso, por favor, indaguem!! Mas to quebrando a cabeça para esclarecer esses assuntos.

Abaixo segue o arquivo de configuração do iptables da máquina nova!

No aguardo!!

[]s

Daniel

[Magnun]

Cara, pra mim você ta entendendo até bem de iptables... Para quem ta começando na área de redes e servidores , parabens, você fez uma estrutura de migração muito boa! Muitas pessoas simplesmente montariam tudo e tentariam trocar as máquinas...

Mas vamos aos problemas... quando você estava mandando o tráfego pra máquina 192.168.1.15 estava funcionando mas pra 192.168.1.16 não. Você já olhou o default gateway da máquina 192.168.1.16? Ela está usando o mesmo gateway da 192.168.1.15??

Qualquer dúvida posta ai...

[danistation]

quando você estava mandando o tráfego pra máquina 192.168.1.15 estava funcionando mas pra 192.168.1.16 não. Você já olhou o default gateway da máquina 192.168.1.16? Ela está usando o mesmo gateway da 192.168.1.15??

Bem, acho que era isso NO MOMENTO.. Claro que o gateway da máquina 16 estava apontando para o servidor de iptables velho.. não ia dar certo mesmo....

Fiz o seguinte: Desliguei o servidor de IPTABLES velho e deixei apenas o novo. Dessa forma, TODAS as máquinas que estão pra dentro do router (CISCO 2620), pingam e acessam a máquina 16 sem problemas...

Agora, com o servidor antigo de IPTABLES fora da rede, fiz o seguinte:
- configurei o servidor novo com os ips e ips alias, etc, conforme estava o servidor antigo;
- A DNAT para a máquina 16 funciona apenas quando o acesso é feito por qualquer computador que estiver após o router (cisco 2620)
- Não consigo nem a pau acessar essa máquina 16 (win 2k) através de qualquer máquina que estiver antes do router (cisco), no caso, o nosso outro escritório que está looonge daqui, porém, a DNAT para minha máquina ( 192.168.1.15 - XP), acessam sem problemas. Aliás, bateu, pegou!!!...

Colega Magnun e demais colegas, será que o roteador pode ter alguma configuração que restringe o acesso à máquina 192.168.1.16 (win-2k) somente pelo MAC do servidor iptables antigo, ou coisa parecida???

Ah sim, muito obrigado pelo elogio. É o esforço.. das 8 às 20 só lendo, testando, lendo, testando... rssss...

[]s,

[Magnun]

Cara, esse router suporta ACLs, o que pode restringir certos trafegos, mas isso não faz sentido. Não tem porque ter algo do tipo.

Agora me diz uma coisa. Você disse: antes do cisco e a partir de outro escritório. Não entendi como outro escritório pode estar antes do cisco, umas vez que ele é sua saída pra internet. Como esse outro escritório se conecta? e com que faixa de ip?

[danistation]

Cara, esse router suporta ACLs, o que pode restringir certos trafegos, mas isso não faz sentido. Não tem porque ter algo do tipo.

Agora me diz uma coisa. Você disse: antes do cisco e a partir de outro escritório. Não entendi como outro escritório pode estar antes do cisco, umas vez que ele é sua saída pra internet. Como esse outro escritório se conecta? e com que faixa de ip?

Essa máquina win 2000 tem MS-SQL e IIS instalados. Essa topologia que coloquei fica toda em barueri. O escritório (matriz) fica na vila olimpia. O pessoal de lá acessa alguns sites neste servidor pelo IP 210.200.200.223. Os sites acessam localmente o banco de dados. A máquina win-2k, além do ip 192.168.1.16 (acessado internamente por barueri) é acessada externamente com o ip 210.200.200.213. Esse ip externo é um dos alias da ETH1 do servidor IPTABLES (para responder a ping, etc), além de estar presente na NAT:
-A PREROUTING -p tcp -m tcp --dport 80 -d 210.200.200.213 -j DNAT --to 192.168.1.16:80

Ao colocar o servidor novo em paralelo, fiz o DNAT do novo ip 210.x.x.223 para a mesma máquina 192.168.1.16. Então vc comentou sobre o gateway nessa máquina .16. Faz sentido, pois o gateway dela é o servidor antigo de IPTABLES.

Aí é que ficou minha dúvida, porque no servidor antigo de IPTABLES, o acesso feito pela matriz que está antes do roteador da CISCO, não há problemas, assim como qualquer outra máquina no mundo. Quando tiro o servidor antigo de iptables e coloco apenas o novo no seu lugar, com as mesmas configurações de IP e tals, a matriz e ninguém que esteja antes do router da CISCO, não consegue mais acessar essa máquina. Porém, se eu fizer NAT para outras máquinas na mesma rede que esse servidor win-2k, funciona sem problemas....

Nisso que surgiu a dúvida de haver no roteador da CISCO alguma regra para que os acessos(redirecionados ou respondidos) ao/pelo ip 210.200.200.213 (NAT para a máquina win-2k) sejam aceitos pelo router CISCO apenas se forem/vierem do MAC ADDRESS da máquina de IPTABLES velha. No roteador CISCO, isso seria possível configurar?

Senão fudeu!! Aí eu fico sem reciocínio no momento...

aguardando...

[Magnun]

Concordo com você...
Esse tipo de funcionalidade existe em switches da cisco, geralmente implementados com o comando port-security. Mas até hoje não vi algo similar em routers.

Acho que uma boa opção no momento seria fazer algumas capturas e verificar o que está ocorrendo com esse tráfego. Começa devagar.

Verifica se ao tentar acesar o ip 210.x.x.213 as requisições chegam no servidor de iptables novo. Se não estiver nem chegando tem algum problema antes dele.
Depois verifica se o NAT de 210.x.x.213 para 192.168.1.16 está sendo feito. Olha na interface de saída do iptalbes novo se os pacotes estão saíndo corretamente e no 192.168.1.16 se os pacotes estão chegando até ele.
Depois verifica se o 192.168.1.16 está respondendo as requisições e para quem está respondendo (tem que ser pro servidor de iptables novo).
Continua sendo o tráfego, só que agora no sentido de saída da sua rede. Vai parte a parte.

Pra visualizar essas coisas eu costumo usar os contadores do iptables (verifica se a regra está sendo utilizada) e o tcpdump (visualizar os pacotes). O iptraf também é bom pra visualizar as conexões existentes... No windows temos a opção do wireshark ou ethereal que são sniffers de pacote (similares ao tcpdump) com interface gráfica.

Qualquer coisa posta ai...

[danistation]

... Acho que uma boa opção no momento seria fazer algumas capturas e verificar o que está ocorrendo com esse tráfego. Começa devagar...

Consegui o user e pass do router, dei alguns 'show' nele e de fato, nada nada nada que tenha a ver com o problema. então o router foi descartado.

Suas dicas de verificação são muito bem vindas! Embora eu não saiba ainda fazer alguma delas. Meu próximo passo:

- Procurar no gooooogle sobre as suas dicas de como proceder;
- Fazer a troca do outro servidor (apache + squid) que praticamente já está pronto;
- Se não obtiver sucesso na busca com o gooooogle volto a te questionar sobre os comandos e interpretação dos resultados, OK?
- Agendar uma madrugada para fazer novos testes com esse novo servidor de iptables, porém, todos os testes com certeza serão feitos com o sevidor antigo desligado e, o servidor novo, com as mesmas configurações do antigo;

Muito obrigado por enquanto!

Logo mais coloco mais dúvidas a respeito. Acredito realizar estes testes entre terça, quarta e quinta-feira da semana que vem.

[]s

[Magnun]

Consegui o user e pass do router, dei alguns 'show' nele e de fato, nada nada nada que tenha a ver com o problema. então o router foi descartado.

Suas dicas de verificação são muito bem vindas! Embora eu não saiba ainda fazer alguma delas. Meu próximo passo:

- Procurar no gooooogle sobre as suas dicas de como proceder;
- Fazer a troca do outro servidor (apache + squid) que praticamente já está pronto;
- Se não obtiver sucesso na busca com o gooooogle volto a te questionar sobre os comandos e interpretação dos resultados, OK?
- Agendar uma madrugada para fazer novos testes com esse novo servidor de iptables, porém, todos os testes com certeza serão feitos com o sevidor antigo desligado e, o servidor novo, com as mesmas configurações do antigo;

Muito obrigado por enquanto!

Logo mais coloco mais dúvidas a respeito. Acredito realizar estes testes entre terça, quarta e quinta-feira da semana que vem.

[]s

Blz!! Precisando pode postar ai!
Até mais...

[river2]

Bom topico heim.

[danistation]

Caras, loucura loucura. Não sei se é a implementação do iptables, mas o treco resvolveu funcionar apenas da seguinte forma:

Se vocês leram todas as mensagens notarem que fiz um comentário a respeito da tag RH-Firewall-1-INPUT, renomeando a mesma para TESTE-FW. Essa tag apontava para execuções FORWARD e INPUT simultanamente, ou seja, para economizar dedo, ao invés de utilizar INPUT e FORWARD para uma mesma situação, estava sendo utilizado essa TAG escrota:
-A INPUT -j RH-Firewall-1-INPUT
-a FORWARD -j RH-Firewall-1-INPUT

Assim, ao invés de utilizar duas linhas para cada treco que fosse necessário fazer (uma linha de INPUT e outra linha de FORWARD), bastava utilizar a linha RH-Firewall-1-INPUT e a regra, que valia para as duas condições...

Bem, pelo menos no fedora 2 funcionava sem problemas. No fedora 8 não funcionou nem a pau. Fiquei horas comparando detalhes nos arquivos /etc/sysconfig/iptables das máquinas e, como estavam idênticas, alguma coisa estava errada ainda.

Moral: Desfiz a utilização das tags e passei a trabalhar com o método correto:
*filter
:INPUT
todos os inputs ficaram aqui.
:FORWARD
todos os forwards aqui.
:OUTPUT
todos os outputs aqui.

*nat
:PREROUTING
todos os preroutings aqui.
:POSTROUTING
todos os posroutings aqui.
:OUTPUT
todos os outputs aqui.

Ainda não sei pra que me serveria a tabela mangle.

Bem, feito isso, bateu pegou. Tudo funfou de PRIMA, EXCETO, ADIVINHEM QUEM????

FTP.....

Embora estivesse com a porta liberada... nada de FTP funfar... Mas, felizmente, já está NORMAL. Embora, também, muitos sites, artigos, tutoriais, etc dessem soluções mirabólicas, procurei saber como o servidor antigo estava funfando, fiz igual, e minha configuração para acesso FTP também ficou muito mais elegante que qualquer outro pos que encontrei... MAS, essa informação vou colocar em outro tópico!!!

MAGNUN LENO, muito obrigado pelas dicas de como proceder para encontrar o erro. Mesmo utilizando metade da dica, foi o suficiente para raciocinar no funcionamento da coisa! Esta ficará guardada para apreciação das ferramentas e métodos mencionados, obrigado mesmo!!!

Abraços a todos,

[Magnun]

Haha, cara, acredita que eu nem tinha visto aquele -j pra uma outra chain!! Realmente aquilo era um problema... foi mal..

Mas é isso ai! se saiu muito bem! Quanto a tabela mangle, ela é utilizada para marcação de pacotes, ToS e QoS.

Quanto ao FTP, quais portas você abriu? O FTP usa as portas 20 e 21. É bom, abrir também pra pacotes do tipo STABLISHED e RELATED.
Acho que é isso...
Valeu!

Caras, loucura loucura. Não sei se é a implementação do iptables, mas o treco resvolveu funcionar apenas da seguinte forma:

Se vocês leram todas as mensagens notarem que fiz um comentário a respeito da tag RH-Firewall-1-INPUT, renomeando a mesma para TESTE-FW. Essa tag apontava para execuções FORWARD e INPUT simultanamente, ou seja, para economizar dedo, ao invés de utilizar INPUT e FORWARD para uma mesma situação, estava sendo utilizado essa TAG escrota:
-A INPUT -j RH-Firewall-1-INPUT
-a FORWARD -j RH-Firewall-1-INPUT

Assim, ao invés de utilizar duas linhas para cada treco que fosse necessário fazer (uma linha de INPUT e outra linha de FORWARD), bastava utilizar a linha RH-Firewall-1-INPUT e a regra, que valia para as duas condições...

Bem, pelo menos no fedora 2 funcionava sem problemas. No fedora 8 não funcionou nem a pau. Fiquei horas comparando detalhes nos arquivos /etc/sysconfig/iptables das máquinas e, como estavam idênticas, alguma coisa estava errada ainda.

Moral: Desfiz a utilização das tags e passei a trabalhar com o método correto:
*filter
:INPUT
todos os inputs ficaram aqui.
:FORWARD
todos os forwards aqui.
:OUTPUT
todos os outputs aqui.

*nat
:PREROUTING
todos os preroutings aqui.
:POSTROUTING
todos os posroutings aqui.
:OUTPUT
todos os outputs aqui.

Ainda não sei pra que me serveria a tabela mangle.

Bem, feito isso, bateu pegou. Tudo funfou de PRIMA, EXCETO, ADIVINHEM QUEM????

FTP.....

Embora estivesse com a porta liberada... nada de FTP funfar... Mas, felizmente, já está NORMAL. Embora, também, muitos sites, artigos, tutoriais, etc dessem soluções mirabólicas, procurei saber como o servidor antigo estava funfando, fiz igual, e minha configuração para acesso FTP também ficou muito mais elegante que qualquer outro pos que encontrei... MAS, essa informação vou colocar em outro tópico!!!

MAGNUN LENO, muito obrigado pelas dicas de como proceder para encontrar o erro. Mesmo utilizando metade da dica, foi o suficiente para raciocinar no funcionamento da coisa! Esta ficará guardada para apreciação das ferramentas e métodos mencionados, obrigado mesmo!!!

Abraços a todos,