Czy traceroute / tracert pokazuje każdy przeskok, czy też pomija / ukrywa niektóre szczegóły ścieżki?

Obecnie studiuję na licencjat z inżynierii sieci, a jeden z moich profesorów wyjaśnił w klasie, że traceroute pokazujący na przykład 15 przeskoków w rzeczywistości abstrahuje ścieżkę, aw rzeczywistości zaangażowanych jest wiele innych węzłów. Czy to prawda?

Jest to sprzeczne ze wszystkim, co mogę znaleźć na traceroute. Według mojej wiedzy traceroute działa, wysyłając pakiety ICMP (lub UDP) do określonego miejsca docelowego z TTL od 0 -> n aż do osiągnięcia miejsca docelowego. Pakiety sondujące, które są wysyłane w każdym miejscu po drodze, wysyłają limit czasu, generując odpowiedź ICMP „przekroczenie czasu”, a na koniec komunikat „port nieosiągalny” po osiągnięciu miejsca docelowego.

Rozumiem niedoskonałości traceroute - na przykład ruch traceroute może być blokowany przez niektóre bramy lub TTL pakietu odpowiedzi może być ustawiony na pozostały TTL sondy, powodując, że nigdy nie powróci do nadawcy.

Jednak po wielu badaniach nie mogę znaleźć niczego, co wskazywałoby na traceroute, w przypadku traceroute, który zawsze zwraca tę samą ścieżkę. Podobnie nic nie wskazuje na istnienie „dodatkowych” przeskoków niezgłoszonych przez traceroute (innych niż przeskoki * * *, które przekroczyły limit czasu bez odpowiedzi).

Jestem otwarty na dyskusję i naprawdę jestem zainteresowany odpowiedzią na to pytanie.

Traceroute pokaże ci ile przeskoków warstwy 3 docierasz od A do B.

Jednak możesz przechodzić przez setki przełączników między nimi. Możesz także przechodzić przez 10 routerów ISP z uruchomioną siecią VPN warstwy 2, która pojawia się jako pojedynczy przeskok. Sieć MPLS może ukryć swoje elementy wewnętrzne lub pokazać Ci te elementy wewnętrzne. Na ścieżce możesz również mieć przezroczyste zapory ogniowe.

Tak czy inaczej, profesor ma rację mówiąc, że nie możesz zagwarantować, że każde urządzenie na ścieżce będzie dla ciebie liczone jako przeskok. Z powodu powyższych punktów, o których wspomniałem, możesz przechodzić przez 50 urządzeń, ale może to wyglądać na trzy.

Ale to się nie zdarza cały czas. Jeśli widzisz 15 chmielu, bardzo dobrze może to być 15 chmielu.

Jest to podstawowy przykład konfiguracji MPLS w odniesieniu do TTL: http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/no-propagate-ttl-edit-protocols -mpls.html

Każde urządzenie, które nie zmniejsza wartości pola IP TTL, nie pojawi się na ścieżce traceroute. Na przykład zaporę Cisco ASA Firewall można skonfigurować tak, aby zmniejszała pole IP TTL dla pakietów przechodzących przez zaporę ( ustaw dekrementację połączenia-ttl ). Domyślnie TTL nie jest zmniejszany, co ukrywa zaporę ogniową.

Traceroute nie pokaże urządzeń, które nie zmniejszają pól TTL datagramu IP.

Nie pokaże także urządzeń, które zmniejszają pole TTL, i zużyją pakiet, jeśli TTL osiągnie zero, ale zaniedbują poinformowanie nadawcy o tym zdarzeniu za pomocą datagramu ICMP. Nie jest to jednak całkowicie niewidoczne; możesz wnioskować o istnieniu tego brakującego skoku w traceroute, ponieważ gdy zostanie użyta następna wyższa wartość TTL, następne urządzenie w łańcuchu zareaguje i wiemy, że coś między tym a poprzednim urządzeniem zmniejsza TTL, ale nie ogłasza się . Tradycyjne narzędzie traceroutedrukuje gwiazdki, gdy nie otrzyma odpowiedzi; wypisałby rząd gwiazdek dla tego typu hosta.

Istnieje również zdalna możliwość, że jakiś router pomiędzy selektywnie tłumi te komunikaty ICMP w zależności od ich adresu źródłowego, przez co niektóre części ścieżki wyglądają niewidocznie, nawet jeśli wygenerowały odpowiedź.