Warum kann ich diese IP-Adresse verfolgen, aber nicht pingen?

Ich habe eine IP-Adresse und kann die Route verfolgen, aber ich kann keinen Ping-Befehl senden.

Sie sehen, ich kann 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

Aber ich kann es nicht pingen:

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

Wenn es ein Verbot von ICMP gibt, traceroutesollte das auch nicht funktionieren. Was ist der Grund dafür?

Ich habe überprüft, ob die Firewall des Servers gestoppt ist.

Auf eine ähnliche Frage hier erklärte Luke Savage es perfekt:

Traceroute ist kein Protokoll selbst, sondern eine Anwendung, und die verwendeten Protokolle hängen von der von Ihnen verwendeten Implementierung ab. Dies ist in erster Linie ICMP.

Es gibt zwei Hauptimplementierungen:

tracert - tracert ist eine Windows-Anwendung, die ICMP-Pakete als inkrementierendes TTL-Feld verwendet, um die Hops der endgültigen Zieladresse zuzuordnen.

traceroute - traceroute ist eine * nix-Anwendung, die auf den meisten Linux-basierten Systemen, einschließlich Netzwerkgeräten, und auf Cisco-Geräten verfügbar ist. Hierbei werden UDP-Pakete mit einem inkrementierenden TTL-Feld verwendet, um die Hops dem endgültigen Ziel zuzuordnen.

Der Unterschied zwischen diesen ist nützlich, um zu wissen, dass einige Netzwerke ICMP jetzt standardmäßig blockieren, sodass sowohl PING als auch Tracert von einem Windows-Computer fehlschlagen, eine Traceroute von einem Linux-Gerät jedoch möglicherweise noch funktioniert.

Um die Antwort von @ naïveRSA zu ergänzen , kann es vorkommen, dass ein ICMP-Paket für "Echo Reply" (Ping) blockiert ist, ein ICMP-Paket für "Time Overed" (Tracert) jedoch zulässig ist, wenn der Pfad Filterung / Firewalling enthält . Dies würde zu denselben Ergebnissen führen, auch wenn nur ICMP (Windows) verwendet wird.

In beiden Fällen (Absender, der UDP oder ICMP verwendet) ist die Fehlerkommunikation ICMP (dh der Knoten, der auf ein Ping- oder Tracer * -Paket antwortet).

Schauen wir uns an, was passiert.

8.8.8.8 ist ein gutes Beispiel, denn zumindest von meinem Standort aus kann ich es sowohl mit tracerouteals auch erreichen ping.

Lassen Sie uns zuerst versuchen, zu ping 8.8.8.8beobachten, was passiert:

$ 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

So pingsendet eine ICMP - Echo - Request und erwartet eine ICMP - Echo - antworten.

Jetzt 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

So traceroutezumindest die Umsetzung habe ich installiert, nicht ICMP senden. Es werden vielmehr UDP-Pakete gesendet.

Was in diesem Trace nicht sichtbar ist (obwohl es wäre, wenn ich tcpdumpa gäbe, -vum die Ausführlichkeit zu erhöhen), ist, dass die ersten Sonden eine ttl von 1 haben und dann die ttl für spätere Sonden inkrementieren. Dies führt dazu, dass die Router zwischen mir und 8.8.8.8 mit einem ICMP-TTL-Überschreitungsfehler antworten. Auf diese Weise erkennt traceroute die Router zwischen hier und da.

Schließlich ist die ttl lang genug, um bis 8.8.8.8 zu gelangen, und 8.8.8.8 antwortet mit einem nicht erreichbaren ICMP-Port-Fehler, da kein Prozess den UDP-Port 44838 überwacht. Auf diese Weise weiß traceroute, dass er das endgültige Ziel erreicht hat .

Wenn zwischen hier und da etwas alles ICMP blockiert , funktionieren weder Ping noch Traceroute.

In der Regel ist jedoch nicht alles ICMP blockiert, obwohl dies auch nicht selten der Fall ist. Das Blockieren des gesamten ICMP ist problematisch: Beispielsweise wird die Pfad-MTU-Erkennung unterbrochen , die auf einem für die ICMP-Fragmentierung erforderlichen Fehler beruht. ICMP-Pakete haben einen Typ und einen Code, und verantwortliche Netzbetreiber blockieren nur einige Typen oder Codes, die möglicherweise missbräuchlich sind oder bestimmte Informationen preisgeben.

Einige Hosts reagieren beispielsweise überhaupt nicht auf eine ICMP-Echoanforderung, und daher funktioniert Ping nicht. Die Idee ist, dass es für einen Angreifer schwieriger ist, herauszufinden, welche Hosts im Netzwerk vorhanden sind, wenn er nicht auf Pings antwortet. In der Praxis ist dies fraglich, da es andere Möglichkeiten gibt, nach einem Host zu suchen. Beispielsweise kann ein TCP-SYN an Port 80 gesendet werden, um Webserver zu finden.

Viele Hosts senden auch keinen nicht erreichbaren ICMP-Port-Fehler, wenn sie ein UDP-Datagramm oder eine TCP-SYN an einen Port senden, an dem sie keinen Prozess überwachen, und dies führt zu einer Unterbrechung der Traceroute. Wieder ist die Idee, es einem Angreifer zu erschweren, das Netzwerk zuzuordnen, aber dies ist für einen Angreifer nur eine kleine Enttäuschung.

Da es sich bei traceroute um ein Programm und kein bestimmtes Protokoll handelt, gibt es andere Möglichkeiten zum Prüfen. Sie alle sind darauf angewiesen, die TTL zu erhöhen, um die Router zu ermitteln. Es können jedoch verschiedene Arten von Tests gesendet werden, die mehr oder weniger die Chance haben, eine Antwort vom Endpunkt auszulösen. Beispielsweise man tcpdumplistet my eine -IOption zur Verwendung von ICMP-Echosonden auf, die mit ping identisch ist. -TAnstelle von UDP müssen auch TCP-SYN-Prüfpunkte verwendet werden. Wenn Sie ein Host wissen reagieren wird pingdann -Imacht sehr viel Sinn. Wenn Sie wissen, dass der Host einen bestimmten TCP-Port -Tüberwacht, ist dies möglicherweise in Verbindung mit der -pOption zur Auswahl des Ports sinnvoll .

Leider erfordern diese Optionen möglicherweise Root- oder spezielle Funktionen, sodass UDP einen angemessenen Standardwert darstellt. Tatsächlich hat ein ähnliches Tool tracepathin seiner Manpage Folgendes zu sagen:

BESCHREIBUNG

Entlang dieses Pfades wird der Pfad zum Ziel verfolgt, an dem MTU entdeckt wurde. Es wird ein UDP-Port-Port oder ein zufälliger Port verwendet. Es ist ähnlich wie traceroute, erfordert nur keine Superuser-Rechte und hat keine ausgefallenen Optionen.

TLDR; Pings können auf einem Remote-Host blockiert werden (ICMP-Blockierung), Traceroute kann jedoch die Route zu diesem Host mithilfe des Standard-Netzwerkroutings (UDP oder TCP / IP) ermitteln (jedes Protokoll, siehe /networkengineering//a/36509/. 58968 ). Beachten Sie, dass Ihr Ping wahrscheinlich auch den Host erreichen kann (es sei denn, Sie haben irgendwo eine sehr intelligente Firewall, die den ICMP-Ping-Verkehr blockiert), der Host antwortet einfach nicht.

Linux verwendet UDP anstelle von ICMP für Traceroute. Die Firewall hat diesen UDP-Port nicht blockiert

Sie können nmap (insecure.org) installieren und nping entweder mit UDP oder TCP und jedem Port verwenden. Funktioniert hervorragend in Netzwerken, in denen Ping ausgehend blockiert ist.

Um einen Webserver zu pingen, nping --tcp -p 80,443

So pingen Sie einen Zeitserver an: nping --udp -p 123

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

Eine kurze Antwort auf Ihre Frage lautet, dass sich das pingDienstprogramm auf das ICMP-Protokoll stützt, das manchmal an der Netzwerk-Firewall oder an der Firewall des Geräts selbst blockiert ist. Der häufigste Grund, warum Netzwerkadministratoren ICMP blockieren, besteht darin, das "Scannen" des Netzwerks zu verhindern, das sie als Sicherheitsbedenken betrachten. Das tracerouteDienstprogramm unter Linux verwendet UDP, ein völlig anderes Protokoll, das in diesem Fall von den Netzwerkadministratoren nicht blockiert wird. UDP hat eine Vielzahl von Verwendungsmöglichkeiten und das Blockieren würde dazu führen, dass viele Dinge in einem Netzwerk unbrauchbar werden. Die Art der ICMP-Kontrollnachricht, die von benötigt wird, pingist eine Teilmenge eines Protokolls, was bedeutet, dass das Blockieren dieser Art von ICMP-Paketen in einem Netzwerk weniger Probleme verursacht und daher eher blockiert wird als UDP.