Disclaimer: Eu não sou um especialista nisso, então ... por favor, aponte qualquer bobagem que eu escrevi.
Mas, sim, isso é bem possível, porque os pacotes que essas ferramentas de diagnóstico enviam & espera que não sejam exatamente o mesmo que os seus pacotes de dados regulares. Eles não tentam fazer a mesma conexão TCP-port-80 que o navegador da Web faria.
O comando ping é simples - ele envia pacotes "Eco" do ICMP (dedicados para esse propósito) e espera respostas de "Resposta de eco" do ICMP do destino. Como o ICMP em si também é usado para relatar erros de conexão, a maioria dos sistemas operacionais já tem suporte embutido para responder às solicitações do Echo, no entanto ...
-
Existem alguns outros pacotes ICMP que não são tão úteis, por exemplo, "Redirect" ou mesmo o antigo "Source Quench" (fácil de abusar). Mesmo o mesmo Ping / Echo tem um histórico de ser usado como o Ping of Death contra várias pilhas de rede com bugs.
Como resultado, muitos administradores de sistemas até hoje configuram um bloco geral de todos pacotes ICMP de entrada, na crença de que isso tornaria sua rede mais segura.
Às vezes eles bloqueiam até mesmo os pacotes ICMP de saída, o que, entre outras coisas, interrompe o Traceroute, bem como outras coisas, como a descoberta de MTU. (Quero dizer, é óbvio que sua rede e seus negócios, mas… argh.)
-
Embora o Windows não seja usado para roteadores (muito), ele ainda é provavelmente o exemplo mais comum disso - desde o Windows XP SP3, o firewall interno descartaria, por padrão, todas as solicitações de eco recebidas. .
(Quase qualquer firewall permite que você filtre pacotes TCP e UDP seletivamente, com base em coisas como endereço de origem e / ou porta de destino. Portanto, não há surpresa que firewalls passem TCP, mas bloqueiem ICMP, por exemplo).
Quanto ao Traceroute, ele não possui mensagem ou protocolo dedicado, na verdade, depende de respostas de erros . A implementação exata varia - no Windows, o comando tracert envia pacotes de eco ICMP, enquanto a maioria das variações da ferramenta traceroute do Linux envia lixo pelo UDP (embora também possa fazer o ICMP). Mas a parte comum é que eles enviam os pacotes com pequenos, aumentando os limites de "time to live", esperando que cada roteador no caminho responda com um erro "Tempo de vida excedido" do ICMP. A maioria dos sistemas operacionais faz isso por padrão.
Mas, novamente, alguns sistemas têm firewalls configurados para descartar silenciosamente os pacotes de eco ICMP e, como resultado, não retornam nenhuma mensagem de erro. (Nesse caso, parece que a filtragem só se aplica a pacotes que o próprio roteador manipularia, mas não aos pacotes que ele simplesmente encaminhava.)
Alguns outros sistemas têm firewalls configurados para bloquear especificamente os erros ICMP de saída. Eu honestamente não faço ideia do porquê, mas eu vi isso acontecer.
E alguns roteadores fazem a própria geração de erros ICMP desativada, talvez para reduzir a carga ou evitar que os pacotes sejam manipulados pela CPU principal lenta quando, de outra forma, seriam encaminhados por hardware dedicado rápido. / p>
Então, no final, não é que "alguns roteadores não estão configurados para responder", mas mais que "estão configurados para não responder " as mensagens do traceroute.
(Eu não posso realmente responder por que às vezes o mtr funciona, mas nenhuma invocação do traceroute . À primeira vista, ele usa a mesma abordagem do traceroute, mas eu não o investiguei em profundidade.)