Posso tracert a un indirizzo IP, ma non un rumore metallico

19

Su Windows, se tracert per Google ottengo il seguente;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

Ora, se eseguo il ping del terzo ultimo indirizzo IP di 66.249.95.234, ottengo questo ...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

In che modo il "ping" interno a tracert funziona in qualche modo in modo diverso da quello del ping reale? Come sono differenti? Cosa devo fare per far funzionare il ping come tracert?

ping traceroute

— DJA
fonte

3

Potrebbe essere semplicemente che ICMP ECHO è bloccato.

— Burhan Khalid

27

Tutto ha a che fare con il modo in cui tracert funziona. Ping è dritto ICMP dal punto A al punto B, che attraversa le reti tramite regole di routing. Tracert funziona molto diverso, anche se utilizza ICMP.

Tracert funziona mirando al hop finale, ma limitando il TTL e aspettando un messaggio ha superato il tempo, quindi aumentandolo di uno per la successiva iterazione. Pertanto, la risposta si ottiene non è un ICMP echo rispondere alla richiesta ICMP echo dall'host lungo la strada, ma un tempo messaggio superato da quello ospite - quindi, anche se sta usando ICMP, si sta usando in un modo molto diverso .

Potete leggere maggiori dettagli su di esso qui .

— MaQleod
fonte

12

Per aggiungere il punto finale del timeout del ping: Apparentemente il 3o ultimo 3 host è configurato per funzionare come router per il traffico attraverso di esso (che include l'invio di messaggi di controllo ICMP TTL EXCEEDED per errori) ma per bloccare il traffico verso di esso, in particolare per non rispondere a ICMP ECHO REQ. A proposito, il client traceroute potrebbe inviare qualsiasi cosa con l'hop finale come destinazione - potrebbe essere ICMP ECHO REQ ma potrebbe anche essere un po 'di TCP SYN (che potrebbe innescare altri messaggi ICMP, specialmente quando viene raggiunto il jhost di destinazione. In effetti, l'implementazione differisce tra i sistemi operativi e poi c'è tracepath...

— Hagen von Eitzen,

@HagenvonEitzen Sarebbe fare una risposta decente da solo (il migliore, IMO!)

— La leggerezza gare con Monica

3

Vale anche la pena notare che molte implementazioni "tracert" non inviano nemmeno pacchetti ICMP. Almeno questo è il caso della traceroutemaggior parte di Linux, che invia datagrammi UDP, anche se non sono sicuro di cosa faccia la versione di Windows. Il luppolo intermedio dovrebbe inviare un ICL TTL EXCEEDED per qualsiasi tipo di pacchetto, non solo ICMP.

— Digital Trauma

1

@DigitalTrauma Wireshark dice che tracertsu Windows 7 invia richieste Echo ICMP.

— Bob

4

Prima di tutti i vostri due comandi sta inviando pacchetti con diversi indirizzi IP di destinazione. Ciò significa che possono prendere strade diverse.

Quando vedi 66.249.95.234sul percorso verso 216.58.220.100, potresti supporre che i pacchetti con l'indirizzo di destinazione 66.249.95.234utilizzino lo stesso percorso fino a raggiungere quel punto. Questo non è comunque un presupposto valido.

E 'del tutto valido per il percorso per 66.249.95.234essere più lungo di quello a 216.58.220.100. A volte capita persino che non ci sia alcun percorso che possa portare i pacchetti verso quel router intermedio, ma non sarebbe una rete ben progettata, se così fosse.

Non so se i comandi tracerte pingche stai utilizzando utilizzano entrambi lo stesso protocollo. La maggior parte delle implementazioni di ping ICMP echo utilizzano pacchetti di richiesta. Tuttavia esistono implementazioni traceroute che supportano una vasta gamma di protocolli tra cui la richiesta di eco ICMP, TCP SYN e pacchetti UDP. Se i due utilizzano protocolli diversi, ciò potrebbe contribuire a vedere risultati diversi.

Infine, anche se tutti i pacchetti dovessero raggiungere 66.249.95.234, è possibile che 66.249.95.234si comporterebbe in modo completamente diverso a seconda che debba:

Inoltrare il pacchetto
Produrre un errore ICMP su un pacchetto indirizzato a se stesso
Produce un errore ICMP su un pacchetto indirizzato a qualcun altro

La scelta di eliminare silenziosamente i pacchetti in uno solo dei tre casi interromperà ovviamente molti strumenti di diagnostica di rete, ma ciò non impedisce comunque ad alcuni amministratori di sistema di farlo.

— kasperd
fonte

0

Poiché la sicurezza sulla rete è in costante aumento, una cosa semplice che molte persone fanno ora è sostanzialmente disabilitare gli aspetti del protocollo ICMP. Ciò impedisce di rispondere ai traceroute e di restituire l'FQDN dall'hop. A volte gli amministratori bloccano le cose in modo stretto che persino un ping non funziona. Questa è una decisione dell'amministratore del sistema in questione.

V'è anche la possibilità che il sistema gestisce un carico rete estesa, ICMP è generalmente molto bassa in priorità in lavorazione rispetto ai dati reali.

— MDPC
fonte

5

Questo in realtà non rispondere alla domanda. La domanda è perché, se entrambi traceroute e ping ICMP uso, non fallisce e ping traceroute successo.

— MaQleod