Traceroute включає IP без маршрутизації (?)

9

Я провів наступну трасеру один раз, намагаючись відключити мережеву проблему.

c:\>tracert linode.com -d

Tracing route to linode.com [67.18.186.61]
over a maximum of 30 hops:

  1    <1 ms     *       <1 ms  10.43.51.252
  2     1 ms    <1 ms    <1 ms  10.45.253.33
  3    <1 ms    <1 ms    <1 ms  10.62.254.251
  4    20 ms    23 ms    45 ms  192.118.32.52
  5    47 ms    20 ms    85 ms  207.232.60.250
  6    54 ms    24 ms    79 ms  212.143.8.69
  7     7 ms    79 ms    11 ms  212.143.8.209
  8    89 ms   110 ms   108 ms  212.143.12.75
  9   143 ms   240 ms    94 ms  212.143.14.154
 10   244 ms   179 ms    95 ms  10.50.1.1
 11   176 ms    80 ms   190 ms  195.66.225.105
 12   174 ms   164 ms   157 ms  70.87.255.217
 13   187 ms   185 ms   186 ms  70.87.253.189
 14   189 ms   194 ms   195 ms  70.87.253.18
 15   187 ms   188 ms   190 ms  70.87.253.126
 16   187 ms   185 ms   185 ms  70.87.254.78
 17   186 ms   184 ms   187 ms  67.18.186.61

Trace complete.

Перші три сайти - це локальні маршрутизатори / шлюзи; ігноруйте ці.

Однак я не впевнений, як крок 10 міг би дати мені 10.50.1.1 як ціль? Це не беззаперечний IP, який не повинен бути ніде знайти в загальнодоступному маршрутизаторі?

routing networking

— Пробіг
джерело

11

Адреси RFC1918 (10/8, 172.16 / 12 та 192.168 / 16) не повинні відображатися в глобальних таблицях маршрутизації, оскільки вони розроблені для використання в "одному підприємстві". Однак до певної міри є сенс використовувати адреси RFC1918 для своїх точкових посилань у вашому ядрі, навіть якщо трафік, що перетинає ці посилання, має "глобально маршрутизовані" діапазони IP-адрес, оскільки це зберігає дещо обмежений ресурс .

Причина, що виявляється в traceroute, полягає в тому, що TTL кадру IP закінчився на інтерфейсі, який є його інтерфейсом IP. Недоліком цього є те, що стає важче пінгувати інтерфейс і виконувати деякі проблеми з цього питання, але немає гарантії, що ви все одно зможете це зробити.

Отже, я б сказав, що це може бути трохи незвично, але це, звичайно, нечувано.

— Ватин
джерело

Я використовував префікс з приватного адресного простору "тимчасово" (на кілька місяців) для асиметричного маршруту. Клієнти були спантеличені тим, що, прослідковуючи від комп'ютерів до Інтернету, вони бачили приватний IP, але від Інтернету до їх ІР, приватний IP не показувався.

— Mircea Vutcovici

5

Мені це здається дивним. Цілком нормально також бачити приватні IP-адреси посередині маршруту, оскільки одна організація може використовувати приватний IP-адресу в межах своєї мережі. Але згідно Whois, 212.143.14.154 та 195.66.225.105 належать дві різні організації. Але, можливо, ці дві організації мають точку зору між собою, і в такому випадку вони можуть використовувати приватний IP для цього.

Термін "не маршрутизований" не зовсім точний, тому що вони можуть бути маршрутизовані. Однак слід використовувати лише одне "підприємство", термін RFC1918 . Тому я вважаю це трохи дивним.

— Кайл Брандт
джерело

2

Звичайно, хто насправді не такий надійний

— Кайл Брандт

вони можуть мати PTP-посилання, але оскільки один є ізраїльським провайдером [корпоративне з'єднання, в даному випадку], а другий є провідним хостинг-провайдером у США [theplanet.com], це здається дивним.

— Майкаж

3

Я бачив, як це відбувається на деяких ялівцевих маршрутизаторах. У них були призначені належні публічні IP-адреси, але маршрутизатор надсилав відповіді icmp за допомогою приватного ip, який був прив’язаний до інтерфейсу управління (недоступний через публічний Інтернет).

— pQd
джерело

+1 Здається, як для мене більш ймовірне пояснення

— Кайл Брандт,

2

Можливо, він проходить через чиюсь внутрішню мережу, через MPLS або щось подібне, де вони використовують внутрішні IP-адреси.

— Сіань
джерело

2

Я згоден з Ціаном. Іноді ці WAN Hops мають приватну IP-адресу зі зворотним зв'язком. З якоїсь причини це повертається в трасе. Програма під назвою Wireshark (дійсно хороша безкоштовна програма) може дати вам більше розуміння вашої проблеми з мережею.

Манні

— Манні
джерело