Маршрутизатора нет в traceroute

Утилиты Traceroute и Tracert

Traceroute — это утилита, которая позволяет проследить маршрут следования данных до удалённого адресата в сетях TCP/IP. В Linux используется команда Traceroute, а в Windows — Tracert. При помощи этих команд можно увидеть путь пакета данных от вашего компьютера до целевого сервера или сайта.

Как работают Tracert и Traceroute

Когда вы пытаетесь открыть сайт, браузер отправляет сообщение (запрос) серверу, на котором этот сайт находится. Сообщение на своём пути проходит через маршрутизаторы. Они решают, куда дальше передать сообщение, чтобы гарантированно его доставить адресату. В трассировке маршрутизаторы ещё называют хопами (хоп — прыжок) или узлами. Количество узлов, через которые на своём пути пройдёт запрос, можно узнать при помощи утилит Tracert и Traceroute. Узлы, которые не являются целевыми для запроса, называют транзитными.

Утилита Traceroute формирует UDP-датаграмму (сообщение, которое нужно доставить целевому серверу), упаковывает её в IP-пакет и передаёт первому транзитному узлу. В заголовке такого IP-пакета есть поле TTL (Time To Live) — время жизни пакета. Оно определяет количество хопов, через которые пакет может пройти. На каждом узле TTL уменьшается на единицу. Если на пути к удалённому адресату время жизни пакета станет равно 0, маршрутизатор отбросит пакет и отправит источнику ICMP-сообщение об ошибке «Time Exceeded» (время истекло).

Этот принцип лежит в основе работы утилит Tracert и Traceroute, однако между ними есть отличия. Рассмотрим каждую утилиту отдельно.

Tracert отправляет на хост назначения ICPM-запрос «Echo Request» с TTL=1. Первый маршрутизатор, который получит запрос, проверяет, кому он предназначен. Если маршрутизатор не является целевым хостом, он уменьшает TTL на 1, отбрасывает пакет и отправляет ICMP-сообщение источнику, так как время жизни теперь равно 0. В этом сообщении маршрутизатор указывает информацию о себе и причину дропа пакета. Получив сообщение, Tracert запоминает этот маршрутизатор как первый хоп (прыжок) и отправляет следующий пакет, но уже с TTL=2. Первый хоп успешно обрабатывает новый пакет, уменьшает время его жизни на 1 и передаёт дальше. Следующий маршрутизатор тоже выполняет проверку хоста назначения и, если пакет предназначен не ему, уменьшает TTL, отбрасывает пакет и отправляет ICMP-сообщение источнику. Tracert запоминает второй хоп, снова увеличивает TTL на 1 и отправляет следующий пакет. Эти действия будут повторяться до тех пор, пока пакет не достигнет целевого хоста. Когда запрос попадёт к целевому хосту, этот хост в ответ направит ICMP «Echo Reply». Источник воспримет это как завершение трассировки.

Утилита Traceroute вместо ICMP-запроса отправляет 3 UDP-пакета на определенный порт целевого хоста и ожидает ответа о недоступности этого порта. Первый пакет отправляется с TTL=1, второй с TTL=2 и так далее, пока запрос не попадёт адресату. Отличие от Tracert в том, как Traceroute понимает, что трассировка завершена. Так как вместо ICMP-запроса он отправляет UDP-запрос, в каждом запросе есть порт отправителя (Sourсe) и порт получателя (Destination). По умолчанию запрос отправляется на закрытый порт 34434. Когда запрос попадёт на хост назначения, этот хост отправит ответ о недоступности порта «Destination port unreachable» (порт назначения недоступен). Это значит, что адресат получил запрос. Traceroute воспримет этот ответ как завершение трассировки.

Если Tracert работает по протоколу ICMP, то какой протокол используется командой Traceroute? По умолчанию используется протокол UDP, но traceroute может отправить и ICMP-запрос «Echo Request», как Tracert. Такой способ пригодится, если хоп не отвечает на UDP-пакет.

Как использовать Traceroute и Tracert

Кириллические домены необходимо вводить в формате Punycode. Для перевода домена в Punycode воспользуйтесь сервисом.

Источник

Маршрутизатора нет в traceroute

Есть Cisco 2811 в качестве пограничного маршрутизатора. Она как-то криво пропускает через себя ICMP-пакеты tracerout-a. Так, например, вот что видит человек, трассирующий хост за WAN из LAN: # traceroute ya.ru
traceroute: Warning: ya.ru has multiple addresses; using 87.250.251.8
traceroute to ya.ru (87.250.251.8), 30 hops max, 40 byte packets
1 192.168.0.1 (192.168.0.1) 0.969 ms 1.392 ms 1.639 ms
2 ###.###.###.### (###.###.###.###) 6.052 ms * *
3 cisco1.krasnodar.gldn.net (194.186.8.161) 139.643 ms * *
4 pe-l.krasnodar.gldn.net (194.186.10.93) 40.152 ms * *
5 * * *
6 * * p-l.Rostov-na-Donu.gldn.net (194.186.10.81) 37.214 ms
7 * p-l.Moscow.gldn.net (194.67.30.57) 46.119 ms *
8 pe-l.moscow.gldn.net (194.186.80.134) 56.654 ms * *
9 cat03.Moscow.gldn.net (194.186.158.193) 45.366 ms * *
10 cat02.moscow.gldn.net (195.239.10.190) 79.604 ms * *
11 * * *
12 ix2-m9.yandex.net (193.232.244.93) 137.516 ms * 198.609 ms
13 * * *
14 * ya.ru (87.250.251.8) 48.952 ms * При этом сами пинги никуда не пропадают:
# ping ya.ru -fc 50
PING ya.ru (213.180.204.8) 56(84) bytes of data.
— ya.ru ping statistics —
50 packets transmitted, 50 received, 0% packet loss, time 700ms
rtt min/avg/max/mdev = 42.303/94.081/147.654/28.271 ms, pipe 12, ipg/ewma 14.300/66.818 ms
Вот что видит человек, трассирующий хост за LAN из WAN:
#traceroute 2.2.2.2
1 80.72.225.1 (80.72.225.1) 0.430 ms 0.314 ms 0.505 ms
2 80.72.224.122 (80.72.224.122) 4.829 ms 4.094 ms 3.839 ms
3 83.69.67.50 (83.69.67.50) 6.375 ms 5.958 ms 6.943 ms
4 83.69.67.54 (83.69.67.54) 8.917 ms 10.460 ms 7.842 ms
5 1.1.1.1 (1.1.1.1) 62.696 ms 44.746 ms 37.936 ms
6 1.1.1.1 (1.1.1.1) 17.511 ms !X * 12.124 ms !X Здесь 2.2.2.2 — машина за cisco 2811, а 1.1.1.1 — IP самой 2811. то есть, в первый раз она отвечает нормально
ICMP: time exceeded (time to live) sent to 80.72.225.4 (dest was 2.2.2.2)
, а во второй — вместо того, чтобы отправить пакет дальше на 2.2.2.2, она отвечает
ICMP: dst (2.2.2.2) administratively prohibited unreachable sent to 80.72.225.4 (эти строчки я взял из debug ip icmp) Простые пинги (а я так понимаю, что от Traceroute они отличаются только большим TTL) и в этом случае нормально проходят. Ситуация не зависит от того, применяется NAT или нет, какие входные-выходные интерфейсы. Я так подозреваю, что где-то в циске при прохождении пакета через нее TTL меняется более одного раза. У кого-нибудь есть идеи? Конфиг циски очень здоровый, так что выкладывать лучше буду частями, если захотите на что-то конкретно взялянуть, пишите. Заранее благодарен за любую помощь.

>tracertoute это не только ICMP, но и UDP на высоких портах.

Спасибо, я об этом не знал. Теперь быстро нашел проблему в ACL, которая мешала прохождению UDP вовнутрь (т.е., трассированию извне).

Но трассирование изнутри — это у меня оказывется совсем другая проблема. сейчас к стыду обнаружил, что хосты без NAT трассируют нормально, т.е. проблема все-таки в NAT. Оно наверное и логично — уходит по UDP на один хост, а возвращается ICMP с другого хоста. Но ведь как-то у людей работает. Может, есть какие-то настройки режимов NAT? Вот мои:

interface FastEthernet0/0.13
encapsulation dot1Q 13
ip address x.x.x.x 255.255.255.252
no ip redirects
ip nat outside
ip virtual-reassembly
ip policy route-map MAP_NetUP
no ip mroute-cache
no snmp trap link-status
!
interface FastEthernet0/1.4
encapsulation dot1Q 4
ip address 192.168.0.33 255.255.255.224
ip access-group ACL_admin_in in
no ip redirects
ip nat inside
ip virtual-reassembly
ip policy route-map ISP
no ip mroute-cache
no snmp trap link-status
!
!
ip nat pool BGPNAT #.#.#.0 #.#.#.0 netmask 255.255.0.0
ip nat inside source list ACL_BGP_NAT pool BGPNAT overload
!
!
ip access-list extended ACL_BGP_NAT
deny ip host 192.168.1.24 any
deny ip host 192.168.1.125 any
permit ip 192.168.0.0 0.0.255.255 any
!

Два наблюдения:
1) от специфичности пула BGPNAT это не зависит, пробовал #.#.#.2, то же самое
2) Когда на Fa0/0.13 (nat outside) ставишь no ip unreachables, в трейсе вообще ничего дальше cisco 2811 нет, одни звезды. А без него — картина приведена в первом посте.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ Рекомендовать для помещения в FAQ]

Источник

traceroute не отображает шлюз по умолчанию и IP-адрес домашнего маршрутизатора

Я не понимаю, почему traceroute на Mac OS не отображает IP-адрес моего домашнего маршрутизатора.

Мой traceroute на www.google.com выглядит следующим образом

1 182.55.226.3 (182.55.226.3) 11.116 ms 13.576 ms 14.185 ms 2 183.90.44.217 (183.90.44.217) 8.347 ms 5.254 ms 7.229 ms 3 183.90.44.201 (183.90.44.201) 7.215 ms 5.495 ms 7.216 ms 4 203.117.35.193 (203.117.35.193) 7.693 ms 203.117.35.105 (203.117.35.105) 9.191 ms 203.117.35.221 (203.117.35.221) 7.427 ms 5 203.117.34.81 (203.117.34.81) 7.399 ms 7.444 ms 203.117.34.85 (203.117.34.85) 9.939 ms 6 203.117.37.22 (203.117.37.22) 14.190 ms 203.117.36.38 (203.117.36.38) 7.944 ms 203.117.37.22 (203.117.37.22) 12.577 ms 7 72.14.198.156 (72.14.198.156) 9.226 ms 72.14.196.189 (72.14.196.189) 12.200 ms 7.388 ms 8 108.170.240.242 (108.170.240.242) 5.872 ms * * 9 216.239.57.50 (216.239.57.50) 14.198 ms 72.14.234.96 (72.14.234.96) 8.626 ms 216.239.57.50 (216.239.57.50) 10.731 ms 10 72.14.239.65 (72.14.239.65) 10.027 ms 64.233.175.215 (64.233.175.215) 12.213 ms 72.14.233.43 (72.14.233.43) 28.103 ms 11 * * 216.239.35.168 (216.239.35.168) 16.768 ms 12 64.233.175.215 (64.233.175.215) 11.001 ms * 

Так как traceroute отображает маршрутизаторы, через которые проходит пакет, для посещения серверов google.com, почему мой первый маршрутизатор не является домашним маршрутизатором (192.168.0.1), который получает пакет. Вместо этого 182.55.226.3, кажется, прибывает из одного из маршрутизаторов в моей стране. Должен ли traceroute отображать частный или публичный IP-адрес моего домашнего маршрутизатора. IP-адрес первого прыжка также не соответствует внешнему IP-адресу моего маршрутизатора.

Трассировка на WAN IP-адрес моего маршрутизатора дает ровно один переход. Однако когда я пытаюсь выполнить трассировку до 182.55.226.3, результат выглядит примерно так.

traceroute to 182.55.226.3 (182.55.226.3), 64 hops max, 52 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 

Источник

Маршрутизатора нет в traceroute

Сообщения: 5
Благодарности: 0

• Операционная система: Windows 7×64.
• Стоит роутер D-Link Dir-300. Включён DHCP.
• Все брандмауэры и фаерволы на ПК отключены.
• Компьютер подключён к маршрутизатору посредством Wi-fi. Это единственное соединение с интернетом.

При трассировке маршрута (например, google.com) среди проходящих узлов отсутствует мой маршрутизатор.
С чем это может быть связано?

Сообщения: 1384
Благодарности: 177

Конфигурация компьютера
Процессор: Intel(R) Core(TM) i3-2120 3.3GHz
Материнская плата: Gigabyte H77M-D3H
Память: DDR3 4Gb
HDD: KINGSTON SV300S37A60G, 60GB, SSD, SATA3
Видеокарта: Intel HD Graphics 2000
Блок питания: 400W
CD/DVD: TSSTcorp SH-224DB
Монитор: AOC 2369M, 22.3»
ОС: Windows 7
Индекс производительности Windows: 4.4
Прочее: BlueTouth, C-Media Audio, Genius NetScroll, A4tech

Reputet, в настройках роутера (или в недрах прошивки) можно отключит icmp ответы, т.о. его не будет видно в маршрутизации. Так часто делают провайдеры, укорачивая видимый путь прохождения пакета до нужного сервера.

——-
Сообщение оказалось полезным? Кнопка Полезное сообщение располагается чуть ниже.

Источник