Sim, é totalmente possível que seu firewall esteja impedindo que o traceroute seja bem-sucedido. Para entender por que isso está falhando, é melhor consultar a página traceroute
man.
trecho
This program attempts to trace the route an IP packet would follow to some internet host by launching probe packets with a small ttl (time to live) then listening for an ICMP "time exceeded" reply from a gateway.
We start our probes with a ttl of one and increase by one until we get an ICMP "port unreachable" (or TCP reset), which means we got to the "host", or hit a max (which defaults to 30 hops).
Three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe. The address can be followed by additional information when requested. If the probe answers come from different gateways, the address of each responding system will be printed. If there is no response within a 5.0 seconds (default), an "*" (asterisk) is printed for that probe.
Portanto, os asteriscos que você vê são servidores nos quais seus pacotes estão sendo roteados, por meio de quem está expirando (5.0 segundos) e, portanto, traceroute
padroniza a impressão de *
.
A outra coisa que irá tankar traceroute
de funcionar, é quando um servidor / roteador ao longo do caminho é configurado para não responder aos pacotes ICMP (também conhecidos como ping). Sem responder aos pings, o truque do traceroute de induzir cada servidor incrementando o TTL (Time To Live) para cada pacote que ele envia para o destino real, falhará.
OBSERVAÇÃO: há até mesmo um aviso sobre isso na página traceroute
man.
trecho
In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp), see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).
Então, dependendo de como você configura traceroute
, ele pode estar usando pacotes ICMP, UDP ou até mesmo TCP para obter uma resposta dos vários sistemas que estão entregando o roteamento de seus pacotes do ponto A para o ponto B.
Novamente, consultando a página traceroute
man, anote essas três opções:
-I, --icmp
Use ICMP ECHO for probes
-T, --tcp
Use TCP SYN for probes
-U, --udp
Use UDP to particular destination port for tracerouting (instead
of increasing the port per each probe). Default port is 53 (dns).
Existem mais, veja a LISTA DE MÉTODOS DISPONÍVEIS para a lista completa.
Então, o que dizer de curl?
Como é frequentemente o caso dos firewalls de borda, como em uma empresa ou universidade, somente portas de tráfego 80 (HTTP) e 443 (HTTPS) podem sair. É inteiramente provável que os pacotes ICMP ECHO_REQUEST sejam descartados pelo firewall das universidades, o que explicaria por que você está recebendo os asteriscos. Assim que você começar a acessar servidores fora da rede das universidades.
Com a saída de pacotes pela porta 80, você pode tirar vantagem disso e dizer a traceroute
para usar o TCP em uma porta específica, 80 nesse caso, para obter o que deseja.
Exemplo
$ sudo traceroute -T -p 80 www.google.com
traceroute to www.google.com (173.194.46.81), 30 hops max, 60 byte packets
1 byers.bubba.net (192.168.1.6) 3.265 ms 3.236 ms 3.213 ms
2 * * *
3 24.93.10.17 (24.93.10.17) 21.359 ms 35.414 ms 48.045 ms
4 rdc-72-230-153-79.wny.east.twcable.com (72.230.153.79) 48.064 ms 48.044 ms 54.523 ms
5 rdc-72-230-153-243.wny.east.twcable.com (72.230.153.243) 70.067 ms 70.013 ms 73.312 ms
6 be35.cr0.chi10.tbone.rr.com (107.14.19.104) 73.201 ms be45.cr0.chi10.tbone.rr.com (107.14.19.106) 62.289 ms be35.cr0.chi10.tbone.rr.com (107.14.19.104) 65.485 ms
7 ae0.pr1.chi10.tbone.rr.com (107.14.17.192) 62.056 ms 48.685 ms ae1.pr1.chi10.tbone.rr.com (107.14.17.194) 32.193 ms
8 * * *
9 209.85.254.130 (209.85.254.130) 42.624 ms 45.159 ms 42.777 ms
10 * * *
11 ord08s11-in-f17.1e100.net (173.194.46.81) 48.036 ms 42.543 ms 44.751 ms