Re: tcptraceroute: Einige Hops haben nur Sternchen
Hi, Am Tue, 19 Mar 2019 12:34:38 +0100 schrieb Christian Perle : > 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
Re: tcptraceroute: Einige Hops haben nur Sternchen
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 -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Re: tcptraceroute: Einige Hops haben nur Sternchen
Christian Perle (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 -
signature.asc
Description: PGP signature
Re: tcptraceroute: Einige Hops haben nur Sternchen
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 Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Re: tcptraceroute: Einige Hops haben nur Sternchen
Hallo, > Falls jemand ein besseres Tool kennt, dann bitte melden. schon mal mtr probiert? Grüße -- Henri Wahl IT Department Leibniz-Institut für Festkörper- und Werkstoffforschung Dresden e.V. Helmholtzstr. 20, 01069 Dresden, Germany tel: +49 (3 51) 46 59 - 797 email: h.w...@ifw-dresden.de https://www.ifw-dresden.de Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc 0xFAC1C12483E6CEC2.asc Description: application/pgp-keys smime.p7s Description: S/MIME Cryptographic Signature
tcptraceroute: Einige Hops haben nur Sternchen
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 -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
