O traceroute acho que todo mundo já conhece né? Pra descobrir a rota de um lugar a outra… Mas acho que uma coisa que pouca gente sabe, é que usar ICMP (ping) pra fazer traceroute é só uma possibilidade, e que usar pacotes TCP ou UDP pode ser um meio bem mais eficiente de detectar uma conexão.
A idéia do traceroute é manipular o campo TTL dos pacotes IP para que ele receba uma mensagem “ICMP Time Exceeded” dos roteadores que estiverem entre você o a máquina alvo, e normalmente usa-se (ou eu imaginava que usava-se…) pacotes ICMP ECHO para isso. No entanto MUITOS roteadores/firewalls são configurados para barrar pacotes ping (para se “ocultarem” na rede), e por isso essa sondagem não é muito eficiente.
Existe um pacote chamado “tcptraceroute” que ao invés de utilizar pacotes UDP e ICMP utiliza pacotes TCP. Ao enviar pacotes TCP SYN ao invés de UDP ou ICMP ECHO, o tcptraceroute é capaz de passar os filtros mais comuns de roteadotes.
Para usuários Debian o pacote já está no repositório. Binários(RPM) e o código fonte podem ser baixados no site oficial:
http://michael.toren.net/code/tcptraceroute/
Veja a diferença entre o traceroute e o tcptraceroute:
Quando utilizado o traceroute, note que a máquina alvo não respondeu a minha consulta. Provavelmente por que ela (ou o roteador/firewall) antes dela, barra pacotes ICMP ECHO
Tracing route to www.itau.com.br [200.246.143.40]
over a maximum of 15 hops:
1 * * * Request timed out.
2 755 ms 204 ms 22 ms 200.217.72.224
3 752 ms 303 ms 619 ms 200.164.178.161
4 757 ms 342 ms 1051 ms 200.223.127.229
5 118 ms 23 ms * 200.223.131.81
6 979 ms * 213 ms 200.223.131.94
7 752 ms 423 ms 968 ms 200.216.4.89
8 172 ms 246 ms 196 ms 200.223.254.117
9 429 ms 173 ms 242 ms 200.211.219.145
10 360 ms 151 ms 189 ms 200.244.163.11
11 615 ms 224 ms 492 ms 200.230.0.114
12 455 ms 134 ms 475 ms 200.230.243.32
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
Trace complete.
Enquanto que com o tcptraceroute, é permitido que você use pacotes TCP, com o campo TTL manipulado, para fazer esse trace, podendo inclusive escolher para qual porta você quer mandar o pacote:
Selected device eth0, address 192.168.1.14, port 1447 for outgoing packets
Tracing the path to www.itau.com.br (200.246.143.40) on TCP port 80 (www), 30 hops max
1 * * *
2 200.217.72.224 52.385 ms 53.778 ms 217.908 ms
3 200.164.178.161 448.959 ms 951.025 ms 225.461 ms
4 200.223.127.229 114.464 ms 467.334 ms 1092.071 ms
5 200.223.131.81 477.904 ms 86.221 ms 17.921 ms
6 200.223.131.94 123.253 ms 446.530 ms 771.054 ms
7 200.216.4.89 308.760 ms 280.420 ms 654.370 ms
8 200.223.254.117 905.862 ms 438.826 ms 635.176 ms
9 200.211.219.145 738.222 ms 160.895 ms 126.095 ms
10 200.244.163.11 299.300 ms 456.284 ms 543.155 ms
11 200.230.0.114 464.796 ms 257.757 ms 1116.234 ms
12 200.230.243.32 275.573 ms 160.785 ms 261.812 ms
13 201.90.84.242 788.507 ms 368.006 ms 834.374 ms
14 200.246.143.40 [open] 256.319 ms 2409.728 ms 263.736 ms
BEM mais completo não?! Duas máquinas que não aparaceram no traceroute estão aparentes com o tcptraceroute!
Gostou da dica? Mais informações sobre os parâmetros de utilização do comando estão disponíveis em seu Manual.
Bom, para vocês, #FikDik Até mais!
Legal o post pabéns!! só que na hora de editar o apache ou seja o httpd.conf o correto não seria utilizar outra porta que não seja a 80? afinal o varnish está respondendo qualquer requisição que chegue até a porta 80 utilizando o cache armazenado, se o apache continuar a responder requisições na porta 80 o varnish não teria nenhuma utilidade pois o apache ainda estaria fritando nas requisições.
No arquivo default.vcl é configurado o proxy reverso, então a porta definida em:
backend default {
.host = “127.0.0.1″;
.port = “80″;
}
será a porta que o apache vai estar respondendo, como foi definida a porta 80 o proxy reverso vai acabar requisitando o próprio varnish que está respondendo a porta 80.
abraço galera!