Блокируют товарищи провайдеры ответы ICMP.
А ОС какая? Windows использует ICMP, а вот Linux и IOS (не Apple iOS, а Cisco IOS) используют UDP, с ним вероятность успеха чуть повыше.
А вы случаем не путаете уровни в модели OSI для этих протоколов ??
Для справки UDP протокол 4 уровня и его дейтаграммы инкапсулируются в нижестоящий протокол. Будь то IP, ICMP, IGMP, RIP, OSPF ...
Если на 3-м уровне в ACL блокируется ICMP, то тут уж ничего не сделаешь.
Модель OSI, в основном, интересна при академическом изучении сетей. Если начать строить сетевое оборудование и ПО строго по ней, получится антипаттерн "артель 'Реванш'" (переливание из пустого в порожнее) из "Золотого теленка" Ильфа и Петрова.
На практике чаще всего можно видеть "Модель TCP/IP".
jidckii: Вы можете указать страницу того же Таненбаума, на которой прямым текстом написано "UDP инкапcулируется в ICMP?" Я вот могу указать на вырезку из спецификации IP, опубликованную в википедии, в которой для UDP и ICMP предусмотрены разные идентификаторы протоколов, и оба они инкапсулируются в IP.
jidckii: Вы показали страницу, где нарисовано, что UDP или TCP оборачиваются в IP. Выше у вас в комментарии написано, что "UDP - поле data в ICMP-пакете". Так вот, пакет UDP/IP содержится не только там, где вы намалевали красным, но и в поле "Протокол верхнего уровня (октет 66)" - там записывается 17. Для ICMP в это поле записывается 1, а для TCP - 6.
jidckii@keikogi~14:35:48:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 5.189.7.1-FTTB.planeta.tc (5.189.7.1) 0.637 ms 0.419 ms 0.363 ms
2 vl4001.sr06-02.ekb.ru.mirasystem.net (92.242.29.237) 213.940 ms 214.026 ms 213.893 ms
3 google.w-ix.net (193.106.112.21) 29.537 ms 31.409 ms 31.294 ms
4 216.239.47.149 (216.239.47.149) 32.271 ms 33.011 ms 30.574 ms
5 google-public-dns-a.google.com (8.8.8.8) 33.102 ms 30.201 ms 34.139 ms
Во второй консоли:
jidckii@keikogi~14:36:02:~$ sudo tcpdump -n net 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:36:09.135312 IP 5.189.13.127.44925 > 8.8.8.8.33434: UDP, length 32
14:36:09.135603 IP 5.189.13.127.52440 > 8.8.8.8.33435: UDP, length 32
14:36:09.135750 IP 5.189.13.127.54928 > 8.8.8.8.33436: UDP, length 32
14:36:09.135885 IP 5.189.13.127.33829 > 8.8.8.8.33437: UDP, length 32
14:36:09.136075 IP 5.189.13.127.54742 > 8.8.8.8.33438: UDP, length 32
14:36:09.136232 IP 5.189.13.127.41642 > 8.8.8.8.33439: UDP, length 32
14:36:09.136340 IP 5.189.13.127.34364 > 8.8.8.8.33440: UDP, length 32
14:36:09.136438 IP 5.189.13.127.39560 > 8.8.8.8.33441: UDP, length 32
14:36:09.136577 IP 5.189.13.127.52723 > 8.8.8.8.33442: UDP, length 32
14:36:09.136701 IP 5.189.13.127.44940 > 8.8.8.8.33443: UDP, length 32
14:36:09.136820 IP 5.189.13.127.32936 > 8.8.8.8.33444: UDP, length 32
14:36:09.137020 IP 5.189.13.127.47465 > 8.8.8.8.33445: UDP, length 32
14:36:09.137160 IP 5.189.13.127.48462 > 8.8.8.8.33446: UDP, length 32
14:36:09.137280 IP 5.189.13.127.56283 > 8.8.8.8.33447: UDP, length 32
14:36:09.137405 IP 5.189.13.127.44759 > 8.8.8.8.33448: UDP, length 32
14:36:09.137515 IP 5.189.13.127.59819 > 8.8.8.8.33449: UDP, length 32
14:36:09.140022 IP 5.189.13.127.46011 > 8.8.8.8.33450: UDP, length 32
14:36:09.140237 IP 5.189.13.127.47503 > 8.8.8.8.33451: UDP, length 32
14:36:09.140316 IP 5.189.13.127.56273 > 8.8.8.8.33452: UDP, length 32
14:36:09.165989 IP 5.189.13.127.52915 > 8.8.8.8.33453: UDP, length 32
14:36:09.167463 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33447 unreachable, length 68
14:36:09.170244 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33446 unreachable, length 68
14:36:09.170278 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33450 unreachable, length 68
14:36:09.170327 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33451 unreachable, length 68
14:36:09.171525 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33448 unreachable, length 68
14:36:09.172044 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33449 unreachable, length 68
14:36:09.172071 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33452 unreachable, length 68
14:36:09.195974 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33453 unreachable, length 68
jidckii: где вы увидели, что UDP обернулся в ICMP? Просто ответы пришли в виде ICMP. Все соответствует тому, что я написал - машина отправляет UDP, в ответ идет ICMP. Теперь проделайте аналогичное под windows - она и запросы будет слать по ICMP.
Если у провайдера закрыт ICMP - запрос, tracert из windows работать не будет, а вот закрывать ICMP-ответ - довольно опасно (при недоступном сайте клиентам придется оооочень долго ждать отвала connect() по тайм-ауту), провайдерские узлы конечно же ответят на запросы молчанием, но вот после выхода из опорной сети провайдера, ответы, скорее всего, появятся.
jidckii@keikogi~15:13:52:~$ sudo tcpdump -n net 172.16.76.67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:15:10.487711 IP 172.16.76.67 > 5.189.13.127: ICMP echo request, id 4, seq 47908, length 72
15:15:10.487773 IP 5.189.13.127 > 172.16.76.67: ICMP echo reply, id 4, seq 47908, length 72
15:15:10.489075 IP 172.16.76.67 > 5.189.13.127: ICMP echo request, id 4, seq 47909, length 72
15:15:10.489106 IP 5.189.13.127 > 172.16.76.67: ICMP echo reply, id 4, seq 47909, length 72
15:15:10.490609 IP 172.16.76.67 > 5.189.13.127: ICMP echo request, id 4, seq 47910, length 72
15:15:10.490634 IP 5.189.13.127 > 172.16.76.67: ICMP echo reply, id 4, seq 47910, length 72
Итого, что мы этим выяснили:
в Windows если мы запускаем tracert то посылаются ICMP пакеты с TCP сегментами, в ответ летит то же самое, то есть в полной мере используется утилита ping.
Если мы запускаем traceroute c *nix то посылаются IP пакеты с UDP дейтаграммами, в ответ мы получаем ICMP пакеты с тем же дейтаграммным UDP внутри.
А ОС какая? Windows использует ICMP, а вот Linux и IOS (не Apple iOS, а Cisco IOS) используют UDP, с ним вероятность успеха чуть повыше.
абсурдна, ибо вы говорите о разных уровнях.
Не важно какая модель имеется ввиду OSI или TCP/IP в любом случае уровни разные.
Суть в том, что если провайдер на всем пути блокирует ICMP не важно какой там используется вышестоящий протокол.
jidckii: вы изобрели новое слово в сетях "ICMP пакет с TCP (UDP)-дейтаграммой внутри". Это не спор, а констатация того, что вам нужно подтянуть ваши знания.
Парни я так и не понял из чего разразился ваш спор, если учесть что в Заокеанской википедии черным по яркому написано: "Traceroute, by default, sends a sequence of User Datagram Protocol (UDP) packets addressed to a destination host; ICMP Echo Request or TCP SYN packets can also be used", собственно там же ссылка на святаясвятых - linux.die.net/man/8/traceroute - где ключ -M как раз и отвечает за тип используемого реквеста.
Похоже вы спорите вокруг терминологии, а не вокруг сути.
Евгений Быченко: Почитайте внимательно, проблема в том, что jidckii продвигает явно ошибочное утверждение о том, что TCP или UDP пакеты могут быть инкапсулированы в ICMP. Я тщетно указываю ему на спецификацию IP, из которой прямо следует, что UDP/TCP/ICMP - все инкапсулируются в IP (тип пакета записывается в октет 66, а не в первые 4 бита как на его красной пометке на картинке), но jidckii мои замечания игнорирует. Это не терминологический спор, а фактологический.
Армянское Радио: в таком случае, вынужден констатировать, что уважаемый jidckii не прав. Протокол ICMP неплохо описан в ненадёжном источнике https://ru.wikipedia.org/wiki/ICMP и естественно в него нельзя вложит протоколы 4-го уровня, для них в его пакете просто нет места - он размером всего 32 байта и не имеет в теле поля для data.
Ну а фраза "Для справки UDP протокол 4 уровня и его дейтаграммы инкапсулируются в нижестоящий протокол. Будь то IP, ICMP, IGMP, RIP, OSPF" и вправду странная. Коллега, jidckii, подтяните матчасть.
Армянское Радио: Евгений Быченко: Признаю, свою неправоту в этом вопросе. Перечитал главу, ICMP действительно инкапсулируется в IP
Видимо у меня в голове не укладывалось, что сетевой протокол может работать внутри сетевого протокола.
Спасибо, что поправили.
jidckii
Проблема в том что вывод tcpdump может немного "запутать" выводом "udp port 33447"
14:36:09.167463 IP 8.8.8.8 > 5.189.13.127: ICMP 8.8.8.8 udp port 33447 unreachable, length 68
Протокол всетаки ICMP:
5.189.13.127: ICMP
, а далее в Payload у ICMP лежит заголовок исходного IP и первые 64 бита уже его Payload(RFC 792), там как раз и лежит заголовок UDP с его номерами портов и прочее.
Для простоты понимания вывода tcpdump показывает вам, что за ICMP пришла.
В итоге получаем: Запрос: IP1|UDP1|Data1 -> Ответ: IP2|ICMP["IP1"|"UDP1"|"Data1"]
и естественно в него нельзя вложит протоколы 4-го уровня, для них в его пакете просто нет места - он размером всего 32 байта и не имеет в теле поля для data.
Поле есть, его длинна ограничена максимальным размером Payload-а IP.
А инкапсулировать можно по разному, TDMoIP, MPLSoGRE и прочие извращения.
Ivan: tcpdump честно показывает, что traceroute отправляет UDP, а в ответ получает ICMP с ошибками. Чтобы хост мог разобраться, за какие пакеты на него ругаются, в эти ICMP включается кусок исходного пакета IP.
