В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.
Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):
R1#sh ip rou | i 40.
40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O 40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O 40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0
Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:
1 10.0.0.1 16.616 ms 16.270 ms 15.929 ms
2 20.0.0.0 15.678 ms 15.157 ms 15.071 ms
3 30.0.0.1 26.423 ms 26.081 ms 26.744 ms
4 40.0.0.0 48.979 ms 48.674 ms 48.384 ms
5 100.0.0.2 58.707 ms 58.773 ms 58.536 ms
Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.
Итак, утилита tracert.
В основе работы данной утилиты лежит протокол icmp. Рассмотрим вот такую схему:
Host отправляет по указанному в его таблице маршрутизации маршруту ICMP Echo-Request с ttl 1. Router1, получив такой пакет, проверит адрес назначения — может быть пакет ему. Так как данный пакет адресован другому хосту, то Router1 считает себя транзитным узлом, декрементирует ttl пакета и отбрасывает его, так как время жизни пакета становится равным 0. Так как пакет был дропнут, Router1 отправляет источнику пакета icmp сообщение с указанием причины дропа — Time Exceeded. Утилита tracert, получив данное icmp сообщение, указывает Router1 как первый хоп (информация об адресе указана в icmp сообщении). Далее процесс повторяется с инкрементированием ttl, пока ttl icmp запроса не будет равен количеству хопов между узлом-отправителем и узлом получателем. В данном примере Server1 является узлом назначения. Получив пакет, он проверит адрес назначения, увидит, что запрос адресован ему и отправит ICMP Echo-Reply, что и будет являться для утилиты tracert триггером к окончанию трассировки.
Вывод:
Icmp -протокол третьего уровня, и о портах он не знает ничего. Поэтому сделать tracert с указанием порта невозможно. Надеюсь тут мы разобрались.
Traceroute — данная утилита работает по иному принципу, хоть и вывод команды похож на вывод предыдущей.
Traceroute основана не на ICMP Echo-Request, а на отправке udp фрагментов и получения сообщения о доступности/недостижимости порта. Вернемся к прошлой схеме. Host генерирует udp фрагмент, инкапсулирует его в IP пакет и выставляет ttl=1. Router1, являясь транзитным узлом, ответит на данный пакет icmp сообщением об окончании времени жизни пакета. Утилита traceroute, получив данное сообщение, указывает адрес источника icmp пакета (Router1) как адрес первого хопа. Далее процесс повторяется с инкрементированием ttl пакета. Всё практически так же, как и в tracert. Но ведь мы не отправляем ICMP Echo-Request, как утилита traceroute поймет, что трассировка закончена? Все просто — в udp заголовке есть поля source и destination порт. Логично, что source порт будет любым портом выше 1023. А каким указать destination порт? Как было сказано выше, работа утилиты traceroute основана на получении сообщения о недостижимости или доступности порта назначения. То есть мы отправляем udp фрагмент с порта 45000 ( к примеру) на порт 33434 (именно этот порт используется по умолчанию). Как и в предыдущем случае, Server1 является узлом назначения. Получив пакет, он распаковывает его и должен передать его протоколам высшего уровня. Но так как порт 33434 по умолочанию будет закрыт на сервере, то Server1 формирует icmp сообщение о недостижимости порта назначения (ICMP Type 3 «Destination Unreachable» Code 3 «Port Unreachable»). Получив данное сообщение, утилита traceroute считает трассировку законченной. В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д). Может получится так, что порт назначения будет открыт. В данном случае сервер отправит на хост-инициатор например TCP ACK, что тоже будет являться триггером к окончанию трассировки.
Вывод:
Утилита traceroute позволяет сделать трассировку с указанием порта назначения.
Для этого разберем пример ниже:
Возьмем предыдущую схему и сделаем трассировку:
С использованием TCP SYN пакетов:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
1 10.0.0.1 16.616 ms 16.270 ms 15.929 ms
2 20.0.0.0 15.678 ms 15.157 ms 15.071 ms
3 30.0.0.1 26.423 ms 26.081 ms 26.744 ms
4 40.0.0.0 48.979 ms 48.674 ms 48.384 ms
5 100.0.0.2 58.707 ms 58.773 ms 58.536 ms
C использованием UDP пакетов:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
1 10.0.0.1 7.102 ms 6.917 ms 6.680 ms
2 20.0.0.0 17.021 ms 16.838 ms 17.051 ms
3 30.0.0.1 31.035 ms 30.859 ms 30.658 ms
4 40.0.0.0 41.124 ms 40.941 ms 40.728 ms
5 100.0.0.2 51.291 ms 51.045 ms 50.720 ms
Как видите трассировка прошла успешно. Мы видим путь до указанного хоста.
А теперь повесим на интерфейс Router4 фильтр на in (как указано на рисунке):
R4#sh run int fa0/0
Building configuration...
Current configuration : 121 bytes
!
interface FastEthernet0/0
ip address 40.0.0.0 255.255.255.254
ip access-group deny-to-server in
duplex half
!
end
R4#sh access-lists deny-to-server
Extended IP access list deny-to-server
10 deny tcp any host 100.0.0.2 log (32 matches)
20 deny udp any host 100.0.0.2 log (29 matches)
30 permit ip any any (128 matches)
Снова сделаем трассировку:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
1 10.0.0.1 4.575 ms 4.490 ms 4.367 ms
2 20.0.0.0 18.431 ms 18.359 ms 29.573 ms
3 30.0.0.1 30.579 ms 30.690 ms 30.722 ms
4 40.0.0.0 52.518 ms !X 62.977 ms !X 62.898 ms !X
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
1 10.0.0.1 5.614 ms 5.523 ms 5.689 ms
2 20.0.0.0 18.364 ms 18.629 ms 18.556 ms
3 30.0.0.1 42.289 ms 42.225 ms 42.143 ms
4 40.0.0.0 41.984 ms !X 41.898 ms !X 41.815 ms !X
Теперь трассировка закончилась на предпоследнем хопе и в выводе появились знаки! Х. Почему это произошло? Router4 получив пакет к Server1 дропает его, так как он попадает под запрещающее правило на входящем интерфейсе и отправляет хосту-инициатору сообщение о том, что пакет был зафильтрован (ICMP Type 3 «Destination Unreachable» Code 13 — «Communication Administratively Prohibited»). Это тоже сообщение о недостижимости порта назначения. Поэтому утилита traceroute получив такое сообщение, заканчивает свою работу так не добравшись до хоста назначения. В данном случае в выводе важно понять, что пакеты были именно зафильрованы, о чем нам подсказывает знак !X (в Unix) или знак !A (в Cisco):
R1#traceroute 100.0.0.2
Type escape sequence to abort.
Tracing the route to 100.0.0.2
1 20.0.0.0 24 msec 24 msec 16 msec
2 30.0.0.1 16 msec 36 msec 40 msec
3 40.0.0.0 !A !A !A
Примечание: Возможен случай, когда пакеты будут дропаться без отправки ICMP сообщений ( отправка в Null-интерфейс в Cisco/Huawei или discard в Juniper). В данном случае трассировка будет идти пока не кончится максимальное TTL, указанное в утилите traceroute (по умолчанию максимум 30 хопов, но можно задать вручную до 255, правда обычно достаточно 15-18 хопов) или ее не прервет администратор, а в выводе будут звездочки.
Примечание: Появление звездочек вместо адресов хостов может быть обусловлено различными причинами и хорошо описано тут
Собственно говоря, утилита traceroute может работать как и утилита tracert с использованием ICMP Echo-Request. Для этого ее следует запустить с ключом -I. В примеры выше фильтр не блокирует ICMP, поэтому трассировка с использованием данного протокола покажет нам весь путь пакета:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -I -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
1 10.0.0.1 4.073 ms 3.986 ms 3.890 ms
2 20.0.0.0 19.474 ms 19.389 ms 19.294 ms
3 30.0.0.1 30.147 ms 30.276 ms 30.826 ms
4 40.0.0.0 42.316 ms 42.240 ms 42.145 ms
5 100.0.0.2 52.705 ms 52.622 ms 52.521 ms
Надеюсь мы разобрались в работе данных утилит. Если надо сделать трассировку по какому то порту в Windows системах, можно использовать сторонние утилиты, к примеру tcptrace.
Спасибо за внимание!
Автор: Bormoglotx
