Трассировка маршрута к rbc.ru [178.248.236.77]
с максимальным числом прыжков 30:
1 1 ms 1 ms 1 ms 192.168.1.1
2 * * * Превышен интервал ожидания для запроса.
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 36 ms 36 ms 36 ms 178.248.236.77
Трассировка завершена.
причем на какой сервер не иди — везде одно и то же, только число прыжков разное.
На все промежуточные хосты — превышен интервал, на конечный — все нормально.
Написал в поддержку Дом Ру. Проверили у себя — то же самое. Так что мои компьютер и роутер тут ни при чем.
В поддержке мне долго объясняли, как работает tracert и убеждали, что такое — норма. Но в конце концов приняли обращение для передачи специалистам. Посмотрим, что напишут.
А пока что я сам пытаюсь понять, как такое может быть.
Чтобы все промежуточные хосты не отправляли ответ об уничтожении ICMP пакета — не верю.
Пока что у меня одно объяснение — сервер Дом Ру либо не принимает ответные ICMP пакеты, либо не транслирует их инициатору tracert. Но почему тогда от конечного — все нормально ?
P.S. Пробовал через сотовый Интернет. Там все как обычно.
Здравствуйте, Maniacal, Вы писали:
M>У меня при пинге с google.com часть узлов ближе к концу звёздочками отображаются. Не хотят узлы тебе ICMP пакет присылать с ответом "Time to live exceeded".
Все по маршруту ? Все по разным маршрутам к разным серверам ? И только конечный всегда присылает ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Сегодня обнаружил, что лог tracert выглядит так
PD> 1 1 ms 1 ms 1 ms 192.168.1.1 PD> 2 * * * Превышен интервал ожидания для запроса.
PD>В поддержке мне долго объясняли, как работает tracert и убеждали, что такое — норма. Но в конце концов приняли обращение для передачи специалистам. Посмотрим, что напишут.
"Это норма". В том смысле что это допустимое поведение.
PD>А пока что я сам пытаюсь понять, как такое может быть. PD>Чтобы все промежуточные хосты не отправляли ответ об уничтожении ICMP пакета — не верю.
ping tracert ходят по ICMP. В обычных ситуациях, с настройками по умолчанию, icmp трафик имеет самый низкий приоритет.
В случаях, когда нагрузка на сеть или на транзитный узел превышает некоторый порог, для снижения нагрузки на CPU (а ответ на icmp довольно ресурсоемкое занятие) автоматически прекращают обрабатываться некоторые типы пакетов. ICMP дропаются первыми — "и без них работает".
Вторая, по частоте, причина не отображения транзитных узлов в трейсе — кипучая деятельность службы безопасности, которой внезапно пришла в голову "светлая" мысль скрыть от хакеров инфраструктуру подвластной им сети, как часть комплекса мер для защиты от DDoS
PD>Пока что у меня одно объяснение — сервер Дом Ру либо не принимает ответные ICMP пакеты, либо не транслирует их инициатору tracert. Но почему тогда от конечного — все нормально ?
Потому что это не от них зависит.
PD>P.S. Пробовал через сотовый Интернет. Там все как обычно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Все по маршруту ? Все по разным маршрутам к разным серверам ? И только конечный всегда присылает ?
PD>Не верю.
Тут только одно объяснение, что один из узлов не хочет через себя пропускать такой пакет в обратную сторону или у него нет прописанного до предыдущего узла маршрута в обратную сторону. НужноМожно через линух попробовать, средствами консольной утилиты traceroute, она без ключа -I или --icmp использует UDP
Здравствуйте, Stanislaw K, Вы писали:
SK>В случаях, когда нагрузка на сеть или на транзитный узел превышает некоторый порог, для снижения нагрузки на CPU (а ответ на icmp довольно ресурсоемкое занятие) автоматически прекращают обрабатываться некоторые типы пакетов. ICMP дропаются первыми — "и без них работает".
На всех транзитных узлах на разных маршрутах? Вряд ли. Или же на сервере Дом.ру ?
SK>Вторая, по частоте, причина не отображения транзитных узлов в трейсе — кипучая деятельность службы безопасности, которой внезапно пришла в голову "светлая" мысль скрыть от хакеров инфраструктуру подвластной им сети, как часть комплекса мер для защиты от DDoS
Не годится объяснение. То же самое при трассировке на apple.com, ibm.com и др. Все хосты по всем маршрутам решили скрыть инфраструктуру ?
И потом, при работе по мобильной сети все показывается.
PD>>Пока что у меня одно объяснение — сервер Дом Ру либо не принимает ответные ICMP пакеты, либо не транслирует их инициатору tracert. Но почему тогда от конечного — все нормально ?
SK>попробуй SK>
SK>pathping.exe www.rbc.ru
SK>
Трассировка маршрута к www.rbc.ru [178.248.234.119]
с максимальным числом переходов 30:
0 имя-моего-компьютера [192.168.1.105]
1 192.168.1.1
2 * * *
Подсчет статистики за: 25 сек. ...
Исходный узел Маршрутный узел
Прыжок RTT Утер./Отпр. % Утер./Отпр. % Адрес
0 имя-моего-компьютера [192.168.1.105]
0/ 100 = 0% |
1 3мс 0/ 100 = 0% 0/ 100 = 0% 192.168.1.1
Здравствуйте, Maniacal, Вы писали:
M>Тут только одно объяснение, что один из узлов не хочет через себя пропускать такой пакет в обратную сторону или у него нет прописанного до предыдущего узла маршрута в обратную сторону. НужноМожно через линух попробовать, средствами консольной утилиты traceroute, она без ключа -I или --icmp использует UDP
Линукса у меня нет, но пробовал с Андроид. Правда, бог его знает, с какими ключами — делал из PingTools. То же самое, плюс еще и для конечного хоста timeout. Ничего, в общем, кроме моего роутера.
SK>>Вторая, по частоте, причина не отображения транзитных узлов в трейсе — кипучая деятельность службы безопасности, которой внезапно пришла в голову "светлая" мысль скрыть от хакеров инфраструктуру подвластной им сети, как часть комплекса мер для защиты от DDoS
PD>Не годится объяснение. То же самое при трассировке на apple.com, ibm.com и др. Все хосты по всем маршрутам решили скрыть инфраструктуру ? PD>И потом, при работе по мобильной сети все показывается.
Админы мобильного оператора "на две головы выше" админов "дом.ру" и защищаются от DDoS нормальными методами.
PD>>>Пока что у меня одно объяснение — сервер Дом Ру либо не принимает ответные ICMP пакеты, либо не транслирует их инициатору tracert. Но почему тогда от конечного — все нормально ?
Потому что нельзя заблокировать весь icmp, он таки немножечко важен.
Здравствуйте, Stanislaw K, Вы писали:
SK>Потому что нельзя заблокировать весь icmp, он таки немножечко важен.
Похоже, да.
Первая серия пакетов отправляется с TTL, равным 1, и поэтому первый же маршрутизатор возвращает обратно ICMP-сообщение «time exceeded in transit», указывающее на невозможность доставки данных. Traceroute фиксирует адрес маршрутизатора, а также время между отправкой пакета и получением ответа (эти сведения выводятся на монитор компьютера). Затем traceroute повторяет отправку серии пакетов, но уже с TTL, равным 2, что заставляет первый маршрутизатор уменьшить TTL пакетов на единицу и направить их ко второму маршрутизатору. Второй маршрутизатор, получив пакеты с TTL=1, так же возвращает «time exceeded in transit».
Процесс повторяется до тех пор, пока пакет не достигнет целевого узла. При получении ответа от этого узла процесс трассировки считается завершённым.
На оконечном хосте IP-датаграмма с TTL = 1 не отбрасывается и не вызывает ICMP-сообщения типа срок истёк, а должна быть отдана приложению. Достижение пункта назначения определяется следующим образом: отсылаемые traceroute датаграммы содержат UDP-пакет с заведомо неиспользуемым номером порта на адресуемом хосте. Номер порта будет равен 33434 + (максимальное количество транзитных участков до узла) — 1. В пункте назначения UDP-модуль, получая подобные датаграммы, возвращает ICMP-сообщения об ошибке «порт недоступен». Таким образом, чтобы узнать о завершении работы, программе traceroute достаточно обнаружить, что поступило ICMP-сообщение об ошибке этого типа.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Линукса у меня нет, но пробовал с Андроид. Правда, бог его знает, с какими ключами — делал из PingTools. То же самое, плюс еще и для конечного хоста timeout. Ничего, в общем, кроме моего роутера.
Ради эксперимента хотя бы на время разрешить на роутере проброс ICMP-протокола, может?
Здравствуйте, Maniacal, Вы писали:
M>Ради эксперимента хотя бы на время разрешить на роутере проброс ICMP-протокола, может?
Во-первых, я ничего не менял на роутере с момента покупки, а раньше tracert нормально работала
В-вторых, для конечного хоста и сейчас ответ нормальный, а это значит, что роутер вообще-то ICMP пропускает.
Здравствуйте, Janus, Вы писали:
J>Это промежуточные хосты "темной сети" (из частного диапазона IP ) вы их не увидите J>Все нормально настроено
Нет. То же самое и до , например, microsoft.com, apple.com и др. Едва ли от моего моего провайдера все хосты по пути до них принадлежат частному диапазону .
Ну и при работе через мобильного оператора мне показывают в трассировке эти самые хосты частного диапазона, всякие 10.x.x.x. Без DNS-имени, но это-то понятно.
PD> 1 1 ms 1 ms 1 ms 192.168.1.1 PD> 2 * * * Превышен интервал ожидания для запроса.
/// PD> 7 * * * Превышен интервал ожидания для запроса. PD> 8 36 ms 36 ms 36 ms 178.248.236.77
PD>А пока что я сам пытаюсь понять, как такое может быть.
Iptables –A INPUT -m ttl --ttl-lt 8 –j DROP
.. это ответ на вопрос 'как'. А вопрос 'зачем' это надо только им задавать. Ну может не хотелось им чтобы трейсроутом можно было прощупать их сетку.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>.. это ответ на вопрос 'как'. А вопрос 'зачем' это надо только им задавать. Ну может не хотелось им чтобы трейсроутом можно было прощупать их сетку.
Проверил сейчас — все стало как положено.
Насчет "прощупать их сетку" — сомневаюсь. Едва ли тут что-то интересное есть, что стоило бы скрыть.
Трассировка маршрута к rbc.ru [178.248.236.77]
с максимальным числом прыжков 30:
1 1 ms 2 ms 1 ms 192.168.1.1
2 3 ms 2 ms 2 ms 172.21.191.253
3 3 ms 2 ms 2 ms lag-3-438.bgw01.omsk.ertelecom.ru [109.194.120.30]
4 45 ms 44 ms 49 ms ertelekom-ic-389478.ip.twelve99-cust.net [62.115.145.221]
5 40 ms 39 ms 39 ms mow-b2-link.ip.twelve99.net [62.115.145.220]
6 46 ms 40 ms 41 ms 62.105.157.143
7 41 ms 41 ms 41 ms 178.248.236.77
PD>Проверил сейчас — все стало как положено.
Видимо тот параноик что поставил тот рул там больше не работает.
PD>Насчет "прощупать их сетку" — сомневаюсь. Едва ли тут что-то интересное есть, что стоило бы скрыть.
Ну видна сетка провайдера, малоли там какие уязвимые сервера, всегда лучше скрыть чем не скрыть.
Как много веселых ребят, и все делают велосипед...
и убеждали, что такое — норма. Но в конце концов приняли обращение для передачи специалистам. Посмотрим, что напишут.
