Чи показує traceroute / tracert кожен скачок, чи пропускає / приховує деякі деталі шляху?


35

Зараз я в коледжі здобув ступінь бакалавра з мережевої інженерії, і один з моїх професорів пояснив на уроці, що трасування, яке показує, наприклад, 15 хмелів, насправді абстрагує шлях, а насправді задіяно ще багато вузлів. Це правда?

Це суперечить усьому, що я можу знайти на traceroute. Наскільки мені відомо, traceroute працює, надсилаючи пакети ICMP (або UDP) до певного пункту призначення з TTL від 0 -> n до досягнення пункту призначення. Пакети зондів, які надсилаються в тайм-аут у кожній точці послідовно, створюючи відповідь ICMP "перевищений час" і, нарешті, повідомлення про недоступність порту при досягненні пункту призначення.

Я розумію недосконалість traceroute - наприклад, трафік traceroute може бути заблокований певними шлюзами, або TTL пакета відповідей може бути встановлений на решту TTL зонда, що змушує його ніколи не повертатися до відправника.

Однак, після багатьох досліджень, я не можу виявити, що щось, що посилається на traceroute, було неточним у випадку проходження traceroute, який завжди повертає той самий шлях. Крім того, нічого не посилається на те, що існують "зайві" хмелі, про які не повідомляється traceroute (крім хмільних * * *, які вичерпані без відповіді).

Я відкритий для обговорення, і мені щиро цікаво знати відповідь на це.


1
щоб було зрозуміло, перший пакет icmp / udp матиме TTL 1, а не 0
mellowd

1
Це може вас зацікавити: nanog.org/meetings/nanog47/presentations/Sunday/…
codey

Відповіді:


40

Структурна послідовність покаже вам, скільки стрибків шар3 ви отримуєте від A до B.

Однак ви можете переживати сотні комутаторів між ними. Ви також можете пройти через 10 маршрутизаторів провайдерів із запуском шару 2 vpn, який відображається як один перехід. Мережа MPLS може приховати свої внутрішні або показати свої внутрішні відомості вам. У вас також можуть бути прозорі міжмережеві екрани.

У будь-якому випадку ваш професор правильний, кажучи, що ви не можете гарантувати, що кожен окремий пристрій на шляху буде вважати вам стрибок. Через вищезазначені моменти, про які я згадував, ви могли пройти 50 пристроїв, але для вас це може виглядати як три.

Однак це не відбувається постійно. Якщо ви бачите 15 хмелів, це дуже добре може бути 15 хмелів.

Це основний приклад встановленого MPLS щодо TTL: http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/no-propagate-ttl-edit-protocols -mpls.html


Дякую! Ситуації, на які ви вказали, безумовно, дають більше уявлення про те, який слід може пропустити.
WilHall

1
Не хвилюйтесь. Навіть такі речі, як тунель GRE, можуть приховувати підкладені стрибки, оскільки сам заголовок GRE має свій власний TTL
mellowd

18

Будь-який пристрій, який не декрементує значення поля TTL IP, не збирається відображатися у шляху прослідковування. Наприклад, брандмауер Cisco ASA може бути налаштований на зменшення поля IP TTL для пакетів, що проходять між брандмауером ( встановити декремент-ttl з'єднання ). За замовчуванням TTL не зменшується, таким чином приховуючи (ну, дещо) брандмауер.


13

Traceroute не показуватиме пристрої, які не декрементують поля TTL IP-дейтаграми.

Він також не показуватиме пристрої, які зменшують поле TTL, і споживатиме пакет, якщо TTL досягає нуля, але нехтуватиме повідомленням відправника про цю подію за допомогою дейтаграми ICMP. Це не зовсім непомітно; Ви можете зробити висновок про існування цього відсутнього переходу в traceroute, оскільки коли використовується наступне вище значення TTL, наступний пристрій у ланцюзі реагує, і ми знаємо, що щось між цим та попереднім пристроєм декрементує TTL, але не оголошує про себе . Традиційна tracerouteутиліта друкує зірочки, коли вона не отримує відповіді; він надрукував би ряд зірочок для цього типу хоста.

Існує також віддалена можливість того, що якийсь маршрутизатор між селективно пригнічує ці ICMP-повідомлення в залежності від адреси їх джерела, завдяки чому деякі частини шляху виглядають невидимими, хоча вони генерують відповідь.


Це не така віддалена можливість, все, що знадобиться, це одна мережа, яка використовувала приватні IP-адреси для своїх маршрутизаторних посилань, а інша, яка скидала всі пакети з приватними джерелами IP.
Пітер Грін
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.