… campus party

Começa nesta segunda 11 de fevereiro, o Campus Party, evento que integra a comunidade da Internet e comunicação e tecnologia. Em sua décima primeira edição, a feira ocorre até sábado dia 16 no prédio da Bienal do Ibirapuera, em São Paulo.

Esta é a primeira vez, que o evento ocorre fora da Espanha. Para mais informações: http://www.campus-party.com.br

… traceroute com icmp e tcp

Quando “debugamos” problemas em um rede, sempre utilizamos alguns comandos ou temos sempre uma mesmo direcionamento:

- ping para o host

- traceroute para o host

- conectar ao host

- …

Mas quando nos confrontamos com firewall em algumas partes da rede, eis que surgem os problemas. Pois muitos firewalls bloqueiam o protocolo ICMP, e outros pings e até mesmo o uso traceroute se torna obsoleto. Para estes casos surge uma ferramenta bem interessante , o TCPtraceroute (ou similares).

Situação:

Imaginem a situação:Alguém esta tentando enviar um e-mail, porém esta tentando saber o porque o mesmo não está sendo enviado. O servidor está com o nome de BRUMAIL, e esta disposto em uma DMZ. Infelizmente não temos acesso as configurações do firewall, para verificar se há ou não uma regra barrando o tal acesso.

Passos para se debugar o fato relatado:

Segundo o que havíamos comentando inicialmente, as primeiras tentativas se baseiam exclusivamente nas 3 principais ferramentas: ping, traceroute, netcat

O teste de verificar se o host está sendo alcançado, ou mesmo ha resposta se baseia no ping, e veja o resultado:

$ ping -c 2 193.190.255.40
PING 193.190.255.40 (193.190.255.40) 56(84) bytes of data.

--- 193.190.255.40 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms

O ping realmente não foi produtivo, já que nem mesmo nos retornou qualquer resposta. Então no tentamos utilizar o segundo comando traceroute:

$ tracepath -n 193.190.255.40
 1:  213.251.167.209   0.200ms pmtu 1500
 1:  213.251.167.252   0.819ms
 2:  213.186.32.1      0.634ms
 3:  213.186.32.4    asymm  2   2.467ms
 4:  194.68.129.183   16.559ms
 5:  193.191.1.1      16.443ms
 6:  193.191.1.174    17.083ms
 7:  no reply
 8:  no reply
 9:  no reply

Neste caso, tivemos um resultado para os 7 primeiros hops. Mas o hop 7 não nos mostra nada, e o firewall provavelmente nos anula qualquer resultado conclusivo. Neste caso, vamos utilizar o comando seguinte, o netcat, já que um acesso a porta do servidor de e-mail poderá ser algo bem mais conclusivo do que as tentativas anteriores.

$ nc -n -vv 193.190.255.40 25
(UNKNOWN) [193.190.255.40] 25 (smtp) : Connection timed out
 sent 0, rcvd 0

$ nc -n -vv 193.190.255.40 80
(UNKNOWN) [193.190.255.40] 80 (www) open
 sent 0, rcvd 0

Assim, verificamos que o nosso webserver esta rodando. E que o serviço de SMTP, ao qual havíamso inicialmente validar, está fora do ar. Infelizmente dizer para todos que a resposabilidade é do firewall, pode ser algo ainda prematuro, pois como na maioria dos lugares dirão que o firewall está configurado corretamente.

A solução:

TCPtraceroute (ou outras variantes) é a solução. Em comparação com o traceroute normal, tcptraceroute não usa pacotes ICMP. Mas ainda assim usa o principio o TTL para os hops, porém com pacotes TCP.

A grande questão é que os pacotes TCP, sempre são liberados nos firewall e não bloqueados com o ICMP. A resposta para as tentativas anteriores, para acesso ao webserver e ao SMTP seguem abaixo com a nova ferramenta.

$ tcptraceroute -i eth0 -n 193.190.255.40 80
Selected device eth0, address 213.251.167.209, port 53545 for outgoing packets
Tracing the path to 193.190.255.40 on TCP port 80 (www), 30 hops max
 1  213.251.167.252  0.522 ms  0.378 ms  0.544 ms
 2  213.186.32.1  0.475 ms * 5.214 ms
 3  213.186.32.4  0.657 ms * 1.252 ms
 4  194.68.129.183  15.986 ms  16.138 ms  15.946 ms
 5  193.191.1.1  15.824 ms  16.130 ms  16.017 ms
 6  193.191.1.174  16.204 ms  16.683 ms  16.917 ms
 7  193.191.9.29  17.168 ms  17.091 ms  17.676 ms
 8  193.190.255.40 [open]  16.953 ms  17.342 ms  17.429 ms

Aguarde, e verá que diferentemente do traceroute neste caso, são mostrados todos os hops além dos apenas 7, que tinhamos anteriormente. E ainda podemos assumir que o 193.191.9.29 é um fiewall. E imediatamente testaremos o serviço SMTP (Porta 25).

$ tcptraceroute -i eth0 -n 193.190.255.40 25
Selected device eth0, address 213.251.167.209, port 57399 for outgoing packets
Tracing the path to 193.190.255.40 on TCP port 25, 30 hops max
 1  213.251.167.252  0.504 ms  0.388 ms  0.396 ms
 2  213.186.32.1  0.292 ms * 6.403 ms
 3  213.186.32.4  0.977 ms * 0.691 ms
 4  194.68.129.183  16.052 ms  15.803 ms  15.862 ms
 5  193.191.1.1  16.088 ms  16.021 ms  15.870 ms
 6  193.191.1.174  16.806 ms  16.505 ms  16.571 ms
 7  * * *
 8  * * *
 9  * * *

A conclusão:

A conclusão é simples. É provavel que o firewall esteja bloqueando conexões para a porta 25. Com estas informações, podemos convencer todos sobre a configurações errônea do firewall.Já que a justificativa se mostra é a seguinte, porque o pacote vai até o hop7 e não até temos resposta do 8 em diante? E se buscarmos pela porta 80 isso não acontece, e só acontece caso tentamos o STMP na porta 25? Bem ai, está a justificativa.

Espero ter ajudado e boa sorte.

… fedora 6 – proxy transparente

Um amigo estava tentando colocar o Fedora 6, como proxy transparente. Embora eu tenha também tentado e como á máquina estava em produção, preferi baixar uma versão 2.5 e instalá-la e seguir a mesma receita de sempre . Porém no Fedora 6 quando ele é atualizado, somos apresentado a uma nova versão do squid (2.6.x), e ai esta o problema, pois não é tão simples criar um proxy transparente…ao menos era o que eu achava !!!!

Mas esta aí a dica do Moisés Coffani, que após várias tentativas também achou o pulo do gato !!

Veremos que é mais simples do que a gente imaginava:

1. Abra o arquivo /etc/squid/squid.conf e procure pela opção http_port.

Ela deve ficar assim http_port <ip squid>:<porta> <transparent> . Exemplo:

http_port 192.168.0.254:3128 transparent

2. Procure a opcao always_direct allow all , onde esta opção deve ser habilitada, já que por default ela vem desabilitada. Então basta retirar o # da frente e pronto.

O resto é seguir os passos simples, de redirecionamento via iptables e habilitar o forward de pacotes.

Pronto, agora é só reiniciar a máquina e navegar.

Valeu Moisés, pela dica !!!

… demorei

É demorei um pouco para atualizar novamente o blog, mas saiba que também mereço férias..mas enfim, estamos de volta e pretendo dar continuidade ao projeto do blog, assim como as notícias relacionadas ao Fedora.

Mas durante estes dias, surgiram novas notícias sobre a distro, inclusive o codinome escolhido para a versão 9.0 do fedora, Surphur.

Opiniões á parte, eu gostei !!! Lembrando que caso alguém se interesse, pode mandar artigos para adamantina.rodrigo@gmail.com, que o quanto antes estarei postando no blog.

Obrigado e continuando….