Perché posso indirizzare a questo indirizzo IP, ma non eseguire il ping?

21

Ho un indirizzo IP e posso rintracciarlo, ma non riesco a eseguire il ping.

Vedi, posso traceroute 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

Ma non posso eseguire il ping:

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

Se c'è un divieto di ICMP, traceroutenon dovrebbe funzionare neanche. Qual è la ragione?

Ho verificato che il firewall del server è stato arrestato.

— 244boy
fonte

può essere che il timeout per il ping sia troppo restrittivo e avrebbe avuto successo, dati i termini più indulgenti? Traceroute ha fornito oltre 500 ms per alcuni nodi.

— vsz

Qualche risposta ti è stata d'aiuto? In tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, puoi fornire e accettare la tua risposta.

— Ron Maupin

39

Su una domanda simile qui Luke Savage lo ha spiegato perfettamente:

Traceroute non è un protocollo in sé, è un'applicazione e i protocolli utilizzati dipendono dall'implementazione che si sta utilizzando. Principalmente questo è ICMP.

Esistono due implementazioni principali:

tracert - tracert è un'applicazione Windows che utilizza i pacchetti ICMP con campo TTL incrementale per mappare i salti all'indirizzo di destinazione finale.

traceroute - traceroute è un'applicazione * nix disponibile sulla maggior parte dei sistemi basati su Linux, inclusi i dispositivi di rete e sui dispositivi Cisco. Questo utilizza pacchetti UDP con un campo TTL incrementale per mappare gli hop alla destinazione finale.

La differenza tra questi è utile da sapere poiché alcune reti ora bloccano ICMP per impostazione predefinita, quindi sia PING che tracert da un computer Windows falliranno ma un traceroute da un dispositivo Linux potrebbe ancora funzionare.

— naïveRSA
fonte

2

quindi, perché il mio IP server può traceroute ma non ping?

— 244boy,

10

Dal tuo output condiviso vedo che stai usando il traceroutecomando e non tracertche mi ha fatto pensare che stai usando un sistema operativo basato su Unix o gnu. Nella risposta che ho menzionato puoi vedere che i sistemi basati su unix non stanno usando ICMPper traceroute. In altre parole, poiché PINGsta usando ICMP(che credo è bloccato dal sistema si sta tentando di portata) e traceroute sta utilizzando UDPpacchetti con un metodo incrementazione di TTLcampo (che penso non bloccata al sistema si sta tentando di portata) PINGfallisce ma ci Tracerouteriesce.

— naïveRSA

4

Piuttosto che aggiungere un nuovo commento al tuo post quando qualcuno come 244boy suggerisce un miglioramento, sarebbe meglio modificare il tuo post in modo che le persone future che leggono la risposta non debbano leggere tutti i commenti per ottenere la risposta completa.

— Keeta: ripristina Monica il

@ naïveRSA A rigor di termini, traceroutesta usando ICMP, anche se sta inviando UDP, vale a dire si aspetta e valuta i TTL exceededmessaggi dal luppolo lungo la strada. Un host che blocca tutto l' ICMP è una cattiva idea, ma pingfallirà in modo considerevole quando le ICMP echorichieste o le risposte vengono bloccate nell'host di destinazione

— Hagen von Eitzen

17

Per aggiungere alla risposta di @ naïveRSA , se ci sono filtri / firewall nel percorso si potrebbe anche verificare la situazione in cui un pacchetto ICMP "echo reply" (ping) è bloccato, ma è consentito un pacchetto ICMP "time overed" (tracert) . Ciò darebbe gli stessi risultati anche quando si utilizza solo ICMP (Windows).

In entrambi i casi (mittente che utilizza UDP o ICMP) la comunicazione dell'errore sarà ICMP (ovvero il nodo che risponde a un pacchetto ping o tracer *).

— Arjan
fonte

6

Diamo un'occhiata a cosa succede, vero?

8.8.8.8 fa un buon esempio, perché almeno dalla mia posizione, posso raggiungerlo con traceroutee ping.

Prima proviamo a ping 8.8.8.8guardare cosa succede:

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

Quindi pinginvia una richiesta di eco ICMP e si aspetta una risposta di eco ICMP.

Adesso traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

Quindi traceroute, almeno l'implementazione che ho installato, non invia ICMP. Piuttosto, invia pacchetti UDP.

Ciò che non è visibile in questa traccia (anche se sarebbe, se avessi dato tcpdumpun -vper aumentare la verbosità) è che le prime sonde hanno un ttl di 1, e quindi incrementa il ttl per le sonde successive. Questo fa sì che i router tra me e 8.8.8.8 rispondano con un errore ICMP ttl superato, che è il modo in cui traceroute scopre i router tra qui e lì.

Alla fine il ttl è abbastanza lungo da arrivare fino a 8.8.8.8 e 8.8.8.8 risponde con un errore irraggiungibile della porta ICMP, perché non ha alcun processo di ascolto sulla porta UDP 44838. Ecco come traceroute sa che è arrivata alla destinazione finale .

Se qualcosa tra qui e là sta bloccando tutto l' ICMP, allora né il ping né il traceroute funzioneranno.

Ma di solito non è bloccato tutto l' ICMP, anche se non è raro. Il blocco di tutti gli ICMP è problematico: ad esempio interrompe il rilevamento MTU del percorso , che si basa su un errore di frammentazione ICMP richiesto. I pacchetti ICMP hanno un tipo e un codice, e gli operatori di rete responsabili bloccheranno solo selettivamente alcuni tipi o codici, quelli che comportano potenziali abusi o divulgano particolari informazioni.

Ad esempio, alcuni host non risponderanno affatto a una richiesta di eco ICMP e quindi il ping non funzionerà. L'idea è che non rispondendo ai ping, è più difficile per un utente malintenzionato scoprire quali host esistono sulla rete. In pratica, ciò è discutibile, poiché esistono altri modi per sondare un host. Ad esempio, è possibile inviare un SYN TCP alla porta 80 per trovare i server web.

Molti host inoltre non invieranno un errore irraggiungibile della porta ICMP quando ottengono un datagramma UDP o un SYN TCP a una porta su cui non hanno alcun processo in ascolto e questo interrompe il traceroute. Ancora una volta l'idea è di rendere più difficile per un utente malintenzionato mappare la rete, ma di nuovo questa è solo una piccola frustrazione per un utente malintenzionato.

Poiché traceroute è un programma e non un protocollo particolare, ha altri modi di sondare. Si basano tutti sull'incremento del TTL per scoprire i router, ma possono essere inviati diversi tipi di sonde che possono avere più o meno la possibilità di ottenere una risposta dall'endpoint. Ad esempio, i miei man tcpdumpelenchi -Iun'opzione per utilizzare le sonde echo ICMP, lo stesso del ping. Deve inoltre -Tutilizzare le sonde TCP SYN anziché UDP. Se sai che un host risponderà, pingallora -Iha molto senso. Se sai che l'host è in ascolto su una determinata porta TCP, allora -Tha senso, forse in combinazione con l' -popzione per selezionare la porta.

Sfortunatamente queste opzioni potrebbero richiedere funzionalità di root o speciali, quindi UDP rende un default predefinito. In effetti uno strumento simile tracepath, ha questo da dire nella sua pagina man:

DESCRIZIONE

Traccia il percorso verso la destinazione scoprendo MTU lungo questo percorso. Utilizza la porta UDP o una porta casuale. È simile al traceroute, solo non richiede i privilegi di superutente e non ha opzioni fantasiose.

— Phil Frost
fonte

2

TLDR; i ping possono essere bloccati (blocco ICMP) su un host remoto ma traceroute può ancora trovare il percorso verso di esso utilizzando il routing di rete standard UDP o TCP / IP (qualsiasi protocollo in realtà; ref /networkengineering//a/36509/ 58968 ). Nota che probabilmente il tuo ping può anche raggiungere l'host (a meno che tu non abbia un firewall molto intelligente che blocca il traffico del ping ICMP da qualche parte), l'host semplicemente non risponde.

— Roel Van de Paar
fonte

0

Linux usando UDP invece di ICMP per traceroute, il firewall non ha bloccato quella porta UDP

— Farshad Khazaee
fonte

0

È possibile installare nmap (insecure.org) e utilizzare nping con UDP o TCP e qualsiasi porta. Funziona alla grande su reti con ping bloccato in uscita.

Per eseguire il ping di un server Web nping --tcp -p 80.443

Per eseguire il ping di un time server nping --udp -p 123

https://nmap.org/book/nping-man.html

— Michael Hubbard
fonte

0

Una breve risposta alla tua domanda è che l' pingutilità si basa sul protocollo ICMP che a volte è bloccato sul firewall di rete o sul firewall sul dispositivo stesso. Il motivo più comune per cui gli amministratori di rete bloccano ICMP è impedire la "scansione" della rete che considerano un problema di sicurezza. L' tracerouteutilità su Linux utilizza UDP, un protocollo completamente diverso, che in questo caso non è bloccato dagli amministratori di rete. UDP ha una varietà di usi e il blocco di ciò renderebbe inutilizzabili molte cose su una rete. Il tipo di "messaggio di controllo" ICMP necessario pingè un sottoinsieme di un protocollo che significa che bloccare quel tipo di pacchetto ICMP causa meno problemi su una rete ed è quindi più probabile che sia bloccato rispetto a UDP.

— Cybernaut
fonte