Hallo,
so weit ich weiß ist tcptraceroute das beste Tool um zu sehen ob ein tcp Port über ein Netz erreichbar ist. Falls jemand ein besseres Tool kennt, dann bitte melden.
Schade ist, dass einige Hops nur ein Sternchen anzeigen: * * *
Beispiel:
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
Frage1: Gibt es einen Namen für das Verhalten hier, wenn hier nur Sternchen stehen?
Frage2: Warum wir das gemacht? Ist das wirklich eine höhere Sicherheit? Als Anwender finde ich das eher nervig, weil man dann schlechter sieht wo es eigentlich klemmt.
Gruß, Thomas
PS: Ich hatte die gleiche Frage mal hier gestellt. Aber einen passenden Begriff habe ich bis jetzt noch nicht gefunden: https://serverfault.com/questions/929670/tcptraceroute-hop-does-not-reply
Hallo,
Falls jemand ein besseres Tool kennt, dann bitte melden.
schon mal mtr probiert?
Grüße
Hallo Thomas,
On Tue, Mar 19, 2019 at 09:55:25 +0100, Thomas Güttler wrote:
so weit ich weiß ist tcptraceroute das beste Tool um zu sehen ob ein tcp Port über ein Netz erreichbar ist.
Fuer die reine Erreichbarkeit reicht auch netcat.
Traceroute/tracepath/tcptraceroute liefern Dir noch zusaetzliche Informationen, welche Hops auf dem Weg zum Zielhost durchlaufen werden und (im Fall von tracepath) welche Path-MTU von welchem Hop gefordert wird.
Schade ist, dass einige Hops nur ein Sternchen anzeigen: * * *
Es liegt nicht am Tool, wenn Du zwischendurch nur Sternchen angezeigt bekommst, sondern daran, dass der jeweilige Hop kein ICMP ttl exceeded oder ICMP frag needed zurueckschickt. In diesem Fall hat das Tool keine Moeglichkeit, die Adresse des Hops zu erfahren. Sowas liegt meistens an paranoiden Router/Firewall-Admins, die ICMP-Pakete fuer etwas grundsaetzlich boeses halten und deshalb verwerfen. Dass sie damit etwa Path-MTU-Discovery kaputtmachen, ist vielen nicht bewusst.
Frage1: Gibt es einen Namen für das Verhalten hier, wenn hier nur Sternchen stehen?
Ich kenne keinen. Es zeigt nur, dass im diesem Fall jemand zuviel wegwirft.
Frage2: Warum wir das gemacht? Ist das wirklich eine höhere Sicherheit?
Aus Sicht mancher Admins schon. Die Absenderadresse der ICMP ttl exceeded / ICMP frag needed kommt jeweils aus dem Bereich eines Transfernetzes. Falls man die Kenntnis dieser Adressen fuer ein Sicherheitsproblem haelt, versendet man eben keine ICMPs. Ich sehe das aber auch eher als Fehlkonfiguration an, weil es wie gesagt eine Grundfunktion von IP (Path-MTU-Discovery) kaputtmacht.
Gruesse, Christian
Christian Perle chris@linuxinfotag.de (Di 19 Mär 2019 12:34:38 CET):
Frage2: Warum wir das gemacht? Ist das wirklich eine höhere Sicherheit?
Aus Sicht mancher Admins schon. Die Absenderadresse der ICMP ttl exceeded / ICMP frag needed kommt jeweils aus dem Bereich eines Transfernetzes. Falls man die Kenntnis dieser Adressen fuer ein Sicherheitsproblem haelt, versendet man eben keine ICMPs. Ich sehe das aber auch eher als Fehlkonfiguration an, weil es wie gesagt eine Grundfunktion von IP (Path-MTU-Discovery) kaputtmacht.
Ich meine, es muss nicht grundsätzlich am bösen Willen oder der Dummheit der Transfer-Admins liegen. Es kann z.B. auch am Eingreifen des Reverse-Path-Verify liegen.
HOME ----------- ROUTER ------------ R1 ---------------- R2 ---- 192.168.0.0/24 öff. Netz Transfernetz öff. Netz 192.168.0.0/24
Wenn R2 jetzt ein Problem (Frag. needed, TTL excceeded) feststellt, wird er dieses an die für ihn sichtbare Absender-IP (ext. Interface des Homerouters) senden. Der Absender dieser ICMP-Nachricht ist vermutlich das transfernetzseitige Bein von R2, oder?
Dann … selbst wenn es dieses Paket bis zum Homerouter schafft, besteht die Möglichkeit, daß der es wegen rp_filter (reverse path filter/verify) verwirft, weil der meint, daß solche Absender nur auf seinem inneren Interface auftauchen dürfen.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Hallo Heiko,
On Tue, Mar 19, 2019 at 21:46:21 +0100, Heiko Schlittermann wrote:
Ich sehe das aber auch eher als Fehlkonfiguration an, weil es wie gesagt eine Grundfunktion von IP (Path-MTU-Discovery) kaputtmacht.
Ich meine, es muss nicht grundsätzlich am bösen Willen oder der Dummheit der Transfer-Admins liegen. Es kann z.B. auch am Eingreifen des Reverse-Path-Verify liegen.
HOME ----------- ROUTER ------------ R1 ---------------- R2 ----192.168.0.0/24 öff. Netz Transfernetz öff. Netz 192.168.0.0/24
Wenn R2 jetzt ein Problem (Frag. needed, TTL excceeded) feststellt, wird er dieses an die für ihn sichtbare Absender-IP (ext. Interface des Homerouters) senden. Der Absender dieser ICMP-Nachricht ist vermutlich das transfernetzseitige Bein von R2, oder?
Ja. Lokal erzeugter Traffic, fuer den die Route keine explizite Absender-Adresse vorgibt, erhaelt als Absender-Adresse die des Interfaces, ueber das er versendet wird. Kann auch schoen mit ip route get DEST_IP pruefen.
Dann … selbst wenn es dieses Paket bis zum Homerouter schafft, besteht die Möglichkeit, daß der es wegen rp_filter (reverse path filter/verify) verwirft, weil der meint, daß solche Absender nur auf seinem inneren Interface auftauchen dürfen.
Okay, sowas ist denkbar, aber eher unwahrscheinlich. Und es zeigt, dass rp_filter mir Vorsicht zu geniessen ist. Spaetestens wenn man mit Tunneling-Szenarien zu tun hat, will man rp_filter eher nicht anschalten.
Gruesse, Christian
Hi,
Am Tue, 19 Mar 2019 12:34:38 +0100 schrieb Christian Perle chris@linuxinfotag.de:
Es liegt nicht am Tool, wenn Du zwischendurch nur Sternchen angezeigt bekommst, sondern daran, dass der jeweilige Hop kein ICMP ttl exceeded oder ICMP frag needed zurueckschickt.
das kann gerade im Geschäftsumfeld auch an VPNs z.B. zu Kunden/Dienstleistern liegen, wenn deren encryption domain nicht 0.0.0.0/0 ist, sondern eine limitierte Menge an Netzen, oder eine Firewall nach Netzen filtert und keine Ausnahme für ICMP enthält. Dann ist es einigermaßen wahrscheinlich, dass die entfernten Router zwar antworten, deren Absender-IP aber nicht Teil der encryption domain ist, die Pakete also das VPN nicht betreten können (bzw. fälschlich doch geschickt werden und auf empfangender Seite verworfen werden) bzw. nicht durch die Firewallregeln kommen und das auch durch ICMP inspection nicht geheilt werden kann.
Carsten
lug-dd@mailman.schlittermann.de
-
Carsten Weber -
Christian Perle -
Heiko Schlittermann -
Henri Wahl -
Thomas Güttler