Стандартный механизм маршрутизации пакетов в интернете — 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 в GNU/Linux и 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 если для трассировки используются TCP SYN пакеты, что тоже будет являться триггером к окончанию трассировки.
Вывод:
Утилита 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.
Спасибо за внимание!
Комментарии (60)
Bormoglotx
09.04.2016 15:22+1Для трассировки может использоваться и udp пакеты и tcp-что в статье отражено. Если порт tcp открыт, то на tcp SYN мы.получим tcp ACK. Если udp порт открыт (к примеру 67), то мы получаем ответ сервера с ошибкой, так как 67 порт ждет dhcp discover. Помоему это само собой разумеется, не так?? Внес в статью корректировку что бы никто больше так, как вы не подумал.
powerman
10.04.2016 07:01+3И давно у нас все UDP-сервисы обязательно отвечают отправителю?
Bormoglotx
10.04.2016 07:13+1При использовании udp ответственность за предоставление ответа лежит на сервисе, который использует udp как транспорт. Если запрос попадет на открытый порт, утилита traceroute ответа скорее всего не получит.
Bormoglotx
10.04.2016 13:38Ваш вопрос меня заинтересовал, поэтому провел тест в лабе. Открыл 53 udp порт на сервере (DNS сервер) и попробовал сделать трассировку по UDP на 53 порт. В дампе ICMP-сообщение о том что порт не доступен, а от DNS-сервера — ошибка Malformed Packet.
Gendalph
10.04.2016 14:08ЕМНИП, если порт открыт но ничем не занят или правильно закрыт, то срабатывает REJECT (ICMP Port Unreachable). И это, вроде, даже в стандарте описано.
Bormoglotx
10.04.2016 14:12Это понятно, но в данном случае порт открыт и ждал запрос к службе dns. Dns ответил, что запрос не верный.
MichaelBorisov
09.04.2016 15:26Спасибо за статью. Всегда думал, что трассировка производится только с помощью ICMP Echo, а оказалось, что нынче такие хитрые технологии задействуются.
А бывает такое, что путь пакета различается для разных протоколов (TCP, UDP, ICMP) или даже для разных портов?Bormoglotx
09.04.2016 16:09Это уже PBR. Классифицируем пакеты по адресу/протоколу/порту и отправляем эти пакеты на отличный от остального трафика next-hop.
simpleadmin
09.04.2016 15:36+8Надеюсь мы разобрались в работе данных утилит.
Да ладно Вам.
Простейшая трассировка:
# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 31.41.40.1 0.569 ms 0.476 ms 0.452 ms
2 10.52.12.1 0.463 ms 0.561 ms 0.514 ms
3 95.213.189.1 0.608 ms 0.549 ms 0.536 ms
4 195.208.208.232 1.539 ms 0.957 ms 1.587 ms
5 66.249.94.100 2.137 ms
66.249.94.94 2.101 ms 1.619 ms
6 66.249.95.241 25.756 ms
64.233.174.85 25.829 ms
209.85.243.149 22.934 ms
7 216.239.56.208 17.262 ms
216.239.40.240 16.171 ms
209.85.247.77 16.547 ms
8 * * *
9 8.8.8.8 14.459 ms 14.591 ms 13.890 ms
Откуда взялся серый адрес на втором хопе?
Почему на 5-6-7 ответы от нескольких ip?
Почему время ответов на 9-м шаге меньше чем на 6-м?
и т.д. и т.п.
О traceroute можно роман написать.
P.S.: ответы не требутся.sohmstyle
09.04.2016 17:01А позвольте узнать, как это понимать, что на одном хопе несколько ip?
Я сколько работаю с сетевым оборудованием — не сталкивался с таким выводом traceroute.
Везде был один ip на хопе.Bormoglotx
09.04.2016 17:18Это может быть по разным причинам. Например роутер имеет несколько одинаковых по косту маршрутов и использует балансировку per-packet. Если у роутера будет например 4 пути, то может быть не два а три адреса на одном и то и же хопе.
sohmstyle
09.04.2016 17:28Допустим такую ситуацию.
Отправляется пакетом с TTL=5.
По вашей трассировке пакет дойдёт до хоста, имеющий ip адреса 66.249.94.100 и 66.249.94.94. Этот роутер должен будет ответить одним пакетом с каким-то одним source ip (loopback или физический интерфейс, не суть). Используется балансировка трафика или нет, пакет пойдёт по какому-то одному пути.
Как в выводе на пятом хопе 2 ip светится?
Meklon
09.04.2016 17:46+1Для особых нубов в сетях — почему 8 хоп пуст? Это значит, что он маршрутизирует, но не откликается сам на запросы?
Bormoglotx
09.04.2016 18:05+1Это значит что icmp сообщение от данного хоста не получено.Скорее всего они запрещены на данном хосте администратором. Это бывает, ничего страшного в этом нет.
f1inx
10.04.2016 21:40+1На самом деле из наиболее заметного, если запрещен ICMP ответ Destination Unreachable с кодом 4 (Fragmentation Needed and Don't Fragment was Set) то может перестать работать TCP path MTU discovery что приводит к дропам TCP пакетов с MTU превышающим MTU на данном маршрутизаторе. Это было распространенной причиной странного поведения TCP в 1990-1998 годах, когда много серверов были за модемами.
lightman
09.04.2016 20:42Тут был вопрос, но уже понял, что всё есть по ссылке
https://habrahabr.ru/post/129627/
RicoX
10.04.2016 09:54+2Откуда взялся серый адрес на втором хопе?
Пирринг между хоп 1 и хоп 2, а также хоп 2 и хоп 3 может быть на серых адресах, никто не заставляет обязательно для пирринга использовать белые, ситуация часто встречается когда внутри одной сети несколько маршрутизаторов на разных уровнях, среди ISP — это вообще частая ситуация.
Почему на 5-6-7 ответы от нескольких ip?
Потому, что для 8.8.8.8 используется anycast и нормальная ситуация когда ответило несколько серверов с разных маршрутов, тут кто раньше ответил, того ответ и приняли.mayorovp
10.04.2016 12:52+1anycast работает не так. Каждый запрос «доходит» только до одного сервера.
sunnybear
10.04.2016 21:30имеется в виду, что маршруты могут быть разные (потому что «светятся» anycast адреса из многих сетей), а в промежутке оказалось, что какой-то маршрут лучше — и ушло по финальному
lexore
10.04.2016 22:08Так на каждом шаге отправляется по три пакета.
В одном случае все три пришли на один роутер, а в другом случае три пакета разлетелись на три разных роутера.mayorovp
10.04.2016 22:10Да, но при этом все зависит лишь от маршрутов. Нет никакого «кто раньше ответил, того ответ и приняли».
Bormoglotx
09.04.2016 15:39Ссылку внутри статьи посмотрите, там есть.ответы на ваши вопросы. Дублировать другие посты нет смысла да и цель статьи была не рассказать о всех нюансах данных утилит, которых очень много.
ValdikSS
09.04.2016 18:53-8Вы про какой traceroute говорите? Мой, линуксовый, умеет работать и по UDP, и по TCP, и по ICMP.
-I, --icmp
Use ICMP ECHO for probes
-T, --tcp
Use TCP SYN for probesBormoglotx
09.04.2016 18:59+7Не понял вопроса если честно. Traceroute в линуксе не только у вас умеет и icmp, и tcp и udp. Это в статье отражено.
zirf
10.04.2016 12:55-1Дело в том, что линуксоид man traceroute умеет, и про то, что там масса переключателей знает (на практике иногда мешаются к месту и ни к месту сетевые фильтры, поэтому знание — сила, иначе маршрут туманен. MS Windows изначально не имеет мощной встроенной поддержки сетей (до 1994 TCP/IP не поддерживался вовсе). Поэтому встроенный tracert такой простенький. Некоторые сетевые службы в весьма продвинутом в свое время MS Windows 2003 Server оказывались в работе хуже, а в настройке не проще, чем в любых тогдашних Linux/FreeBSD.
Во времена MS Windows 2000 MS DNS был крайне сырой, что очень весело сказывалось на большом количестве запросов к корневым серверам.
ComodoHacker
10.04.2016 13:37В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д)
А это для чего?
zw_irk
10.04.2016 13:57-4В статье совершена большая ошибка: стандартный traceroute unix использует протокол UDP по ограниченному диапазону портов. Более того, следующему пакету, вместе уменьшением TTL, traceroute будет выставлять другой порт UDP. Диапазон выбирался с точки зрения малоиспользуемости. Например, traceroute Cisco IOS вы никакие порты указать не сможете.
Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute. И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.
И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert.Bormoglotx
10.04.2016 13:57+2Добрый день!
По порядку разберем ваш комментарий.
1.Ваша цитата:
«В статье совершена большая ошибка: стандартный traceroute unix использует протокол UDP по ограниченному диапазону портов. Более того, следующему пакету, вместе уменьшением TTL, traceroute будет выставлять другой порт UDP. Диапазон выбирался с точки зрения малоиспользуемости.»
В статье:
«В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д).»
Это стандартное поведение утилиты без каки либо флагов и оно описано в статье. Что касается этого: «Диапазон выбирался с точки зрения малоиспользуемости.» — диапазон специально определен и начинается с порта 33434, количество используемых портов зависит от количества хопов при трассировке.
2. Ваша цитата:
«Например, traceroute Cisco IOS вы никакие порты указать не сможете.»
Правда? Пора бы перейти на IOS 15 или XR:
R1#traceroute 100.0.0.2 ? numeric display numeric address port specify port number probe specify number of probes per hop source specify source address or name timeout specify time out ttl specify minimum and maximum ttl <cr>
3. Ваща цитата:
«Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute.»
tcptraceroute это более расширенный инструмент, который умеет делать трассировку не только TCP SYN. Ну и на сколько мне известно, задать UDP как протокол в нем нельзя. Плюс к тому же tcptraceroute необходимо ставить отдельным пакетом, в то время как traceroute стандартная утлилита для любого unix-сервера.
4. Ваша цитата:
«И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.»
То есть раньше traceroute не умел делать того, что умеет сейчас. Мы находимся в настоящем и говорим о том, что утилита может сейчас.
5. Ваша цитата:
«И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert»
Это строка меня поразила. Вы точно прочитали статью?
«Собственно говоря, утилита traceroute может работать как и утилита tracert с использованием ICMP Echo-Request. Для этого ее следует запустить с ключом -I.»simpleadmin
10.04.2016 14:21Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute
Возможность выбора диапазона портов была в первой же версии traceroute, по крайней мере во FreeBSD 1.0 уже присутствовала. Вот выбор протоколов появился только с FreeBSD 4.0.
в то время как traceroute стандартная утлилита для любого unix-сервера
Если правильно ошибаюсь, то в CentOS-7 её нет.
zw_irk
10.04.2016 18:58-1Ещё раз: есть понятие стандартный traceroute unix-систем, который работает только по UDP, использует ограниченный диапазон портов UDP, и ждёт что порты там будут закрыты. Диапазон выбирался, в своё время, как малоиспользуемый. Поэтому у всех ОС, которые растут от всевозможных BSD и System 5 поведение этой команды именно такое.
Трассировка TCP появилась не так уж давно (примерно с 2000), по сравнению с возрастом UNIX, и долгое время на windows подобного не было (кстати, вы точно уверены, что название tcptrace, а не tracetcp?). И вот все эти TCP плюшки — это traceroute, входящий в состав такой-то ОС. И по умолчанию утилита с функционалом tcp trace стала появляться в дистрибутивах LInux и UNIX не так уж давно(года с 2005, а у некоторых тру из тру помоему до сих пор нет).
И вот именно поэтому traceroute Cisco IOS, который создавался как UNIX-like — ведёт себя именно так, а порт, который там задаётся — это порт UDP. TCP trace оно не умеет. Да наверно сетевому оборудованию и не к чему это.
Всё что я хотел этим сказать, так только то, что не надо все варианты trace смешивать в один абзац, а всё же делать выделение UDP trace, потому что когда говорят «стандартный unix traceroute» имеют ввиду именно UDP trace c порта 33434. Когда говорят про «стандартный windows trace» имеют ввиду icmp trace.
PS. А вообще, появление tcp traceroute, ИМХО вызвал массовый фаерволинг всего подряд, эпидемия которого и пошла с конца 90-х. Для того, чтобы понять, на каком хопе закрыли порт, нужен был инструмент. До этого момента, похоже об этом мало кто задумывался.
Ovsiannikov
11.04.2016 01:06Я вот даже не пойму как мне относится к этой статье. С одной стороны вроде всё правильно написано, хоть тема и довольно известная, у меня даже в своё время сложилось мнение, что это один из самых распространённых вопросов на собеседованиях (был?).
С другой, тема не раскрыта до конца и количество писем провайдерам с темой «я нашёл где у вас проблема» вырастет в разы…
итак уже сылка https://habrahabr.ru/post/129627/ + «особое внимание обратите на 4й снизу абзац» забит шаблоном в почтовые клиенты техподдержки, достали их уже «полуумные» которые где-то что-то прочитали, но до конца не разобрались…Bormoglotx
11.04.2016 07:12Техподдержка так отвечает только тем, кто действительно что то где то прочитал и думается теперь он самый умный.
Дело в том, что что бы понять как работает эти утилиты на уровне сетевого специалиста нужно хотя бы изучить курс ccna, а лучше ccnp или jnsip-sp. Только тогда придет понимание.
Цель статьи дать минимальные базовые знания и толчке к изучению,. Как уже кто то написал выше — про traceroute можно написать роман.zirf
11.04.2016 10:25CCNA для более глубокого понимания. Возьмем ходовой Routing and Switching прослушать ICND1, ICND2, может еще сдать 200-120, чтобы уж наверняка? эдак 130 т р если найти недорого. Притом, что Cisco уже давно не является лидером в области сетей(хотя все еще так думает).
А может таки RTFM вот отсюда. Первое описание traceroute от 1993 года, этот RFC естественно, не последний.
Кстати, при всем уважении к учебным материалам Cisco (они реально хороши), там медицинский факт того, что не пропиеритарные вещи описаны в документах Request-For-Comments, которые опубликованы упомянут?
simpleadmin
11.04.2016 23:06+1Небольшой оффтоп.
сложилось мнение, что это один из самых распространённых вопросов на собеседованиях
Напомнили вопросы на одном из собеседований (лет 10 назад, компания сейчас с Громким именем):
1) кто автор утилиты traceroute?
2) почему Ван выбрал порт 33434 (и как его легко запомнить)?
Ответил на оба, но работать к ним не пошёл. Нахрена мне это знать как простому админу?
Alexsandr_SE
11.04.2016 05:22Хорошая статья. Заодно появились подозрения почему эти две команды у местами выдают разный результат.
msfs11
11.04.2016 11:00А можно вопрос касательно темы маршрутизации? У нас была такая ситуация: мы в Москве, а сервера были в Праге, и иногда происходили сбои связи — потери пакетов, пинг увеличивался. В результате проверки маршрута провайдером, выяснили, что это происходит на участке сети в Германии. Я попросил изменить маршрут нашего провайдера — Глобустелеком, но они отказали — не имеют возможности. При этом другой провайдер в ДЦ, имея такие же проблемы, спокойно изменил маршрут. Почему один провайдер может менять маршрут, а другой — нет? Реально это так? От чего зависит?
TaHKucT
11.04.2016 11:45От кучи вариантов начиная от того, сколько и каких каналов, как ходит трафик и в каких отношениях сетевой инженер состоит с сетевым инженером аплинка.
Иногда можно совершенно безболезненно пустить часть трафика в обход проблемного участка своими силами, иногда можно попросить сделать это аплинка просто написав знакомому в скайп «у нас вон там фигня, перекинь пожалуйста трафик», а иногда упираешься в корп. систему заявок и ответы типа «не имеем технической возможности» которые следует читать как «нам не выгодно гонять этот трафик по другому маршруту».
mayorovp
11.04.2016 11:54Провайдер может лишь выбрать следующую сеть в маршруте — или попросить следующую сеть поменять маршрут. Вполне может быть ситуация, когда у провайдера всего один аплинк — и выбирать не из чего. Или аплинков несколько — но потом все возможные маршруты все равно проходят через проблемного провайдера.
Возможны также технические проблемы с переключением маршрута (желанный вами вариант перегружен). Или экономические (желанный вами вариант слишком дорогой).
Наконец, не исключен вариант простой лени — ведь ваш договор с провайдером не предусматривает решения провайдером тех проблем, в возникновении которых он не виноват.
ONEGiN
13.04.2016 09:48-2Здравствуйте, нагуглить решения вопроса не удалось, спрошу здесь:
Я закрыл на своем сервере все порты кроме 80 и 22, через arno-iptables-firewall. После этого начал получать письма от Я.Метрики что с сайтами размещенными на этом сервере проблемы и они не доступны.
Описание проблемы: Закончилось время подключения к серверу
Возможные причины проблемы: Сервер, на котором находится сайт, перегружено или на нем неправильно сконфигурирован файрвол
При этом сайты работают отлично, и нагрузки на сервере практически нет.
В чем может быть проблема? Может быть такое что Я.Метрика проверяет доступность не только по 80 порту, как тогда еще?
Кстати, сервер не пингуется, какой порт отвечает за прием и ответ icmp-запросов?
Буду благодарен за наводку.mayorovp
13.04.2016 10:32+1icmp — это отдельный протокол. Он не имеет никакого отношения к портам протокола TCP.
ONEGiN
13.04.2016 13:59-1Спасибо за развернутый ответ.
Перефразирую вопрос:
Если файрвол настроен на отбрасывание всех пакетов, кроме тех что приходят на 80 и 22 порт, при этом icmp-пакеты тоже отбрасываются, какое правило для IP-tables разрешит прием icmp-пакетов?RicoX
13.04.2016 14:46+2Например такие, ну если нужны еще типы кроме 8 и 11 — добавьте по аналогии.
iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT iptables -A INPUT -p ICMP --icmp-type 11 -j ACCEPT
scarab
TCP ACK в ответ на UDP-пакет? Это какое-то новое слово в сетевых технологиях?