☰

tcptraceroute: Hop não responde

tag-icon • tag-icon networking firewall traceroute
tcptraceroute: Hop não responde

AFAIK tcptracerouteé a melhor ferramenta para verificar se um firewall está bloqueando a conexão TCP com um serviço. (Se você conhece uma ferramenta melhor, deixe um comentário)

Alguns saltos não respondem. Ver* * *

remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
 1  * * *
 2  172.18.56.12  0.407 ms  0.222 ms  0.230 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  10.102.1.1  32.017 ms  31.728 ms  31.486 ms
 8  * * *
 9  10.101.7.124 [open]  31.728 ms  32.391 ms  33.549 ms

Tem algumaprazopara o comportamento desses lúpulos?

Como chamar isso, se o hop não responde e vejo * * *na saída?

(Infelizmente não tenho 300 reputações e não consigo criar a nova tag "tcptraceroute")

Antecedentes: Eu gostaria de dizer às pessoas como são responsáveis ​​pela rede, que elas deveriam usar roteadores que façam AGORA-ESTOU-PERDINDO-O-TERMO-MÁGICO.

Responder1

Não existe uma palavra exata para isso, mas para ajudá-lo em seu diálogo com aqueles que gerenciam essa rede, você pode procurar CoPP (Control Plane Policing).

É importante notar que o dispositivo pode não estar realmente configurado para negar esses pacotes, pode apenas estar limitando a taxa deles, então se você quiser respostas, você pode pedir que eles excluam certos IPs do limite de taxa ou aumentem o limite para tudo, se for o caso. desejado.

Vou avisá-lo de que pode ser difícil fazer com que a equipe de rede faça essas alterações, pois elas existem para proteger o dispositivo contra ataques DoS ou sobrecarga de uso normal no plano de controle.

DeDocumentos da Cisco, abaixo estão alguns dos efeitos que podem ser observados se o plano de controle estiver sobrecarregado:

  • Qualidade de serviço reduzida (como tráfego ruim de voz, vídeo ou aplicativos críticos)
  • Alta utilização da CPU do processador de rota ou do processador switch
  • Flaps de rota devido à perda de atualizações ou keepalives do protocolo de roteamento
  • Topologia instável da camada 2
  • Sessões interativas lentas ou sem resposta com a CLI
  • Esgotamento dos recursos do processador, como memória e buffers
  • Quedas indiscriminadas de pacotes recebidos

Responder2

Como já foi dito nos comentários, não há uma resposta real para isso (então me sinto um pouco bobo por digitar isso, mas seria muito longo para um comentário). O que você está vendo é apenas tcptraceroutedizer que não obteve resposta do salto. Não existe um termo para isso, é apenas a forma como o traceroute foi projetado. Quando o salto não responde à solicitação ICMP, você recebe uma *resposta, o que significa que nada foi retornado, portanto, uma resposta na forma de um tempo de resposta de ping não pôde ser determinada.

Então, para chegar ao seu histórico:

Eu gostaria de dizer às pessoas como são responsáveis ​​pela rede, que elas deveriam usar roteadores que façam AGORA-ESTOU-PERDINDO-O-TERMO-MÁGICO.

Basta dizer a eles que seus roteadores devem bloquear solicitações ICMP e pronto, eles entenderão o que você quer dizer com apenas algumas palavras. Até porque não é tanto uma funcionalidade, mas sim uma configuração. Para que você não "use roteadores que bloqueiem solicitações ICMP", você os instrui a fazer isso (pode ser a configuração padrão, mas mesmo assim é uma configuração). Os responsáveis ​​pela rede deveriam saber disso.

informação relacionada