О. С. Попова Хіхловська І. В. Системне та прикладне програмне забезпечення у телекомунікаціях Конспект

Вид материала

Формат пакета ping.
Программа tracert в Windows.
Программа ttcp.
Порядок вызова
Опции, употребляемые вместе c –
Перехват пакетов с помощью bpf
Использование tcpdump
Выходная информация, формируемая tcpdump

Подобный материал:

1 2 3 4 5 6 7 8 9 ... 14

20 байт 8+n байт

Формат пакета ping.

В качестве n – числа дополнительных байтов в пакете ping равно 56 в UNIX и 32 WIN, но эту величину можно менять с помощью флагов – S (UNIX) и – L (Win).

В некоторых версиях ping пользователь может задавать дополнительные данные или указывать, что они должны генерироваться псевдослучайным образом. По умолчанию в большинстве версий дополнительные данные – это циклически пераставляемые по кругу байты.

Первое действие пользователя при пропадании связи с удаленным хостом – это запуск ping с указанием адреса этого хоста. Причин пропадания связи может быть несколько: нет связи, по сети между двумя хостами, не работает сам хост А, причина в удаленном стеке ТСР/IP или не запущен сервер telnet.

Сначала следует проверить, достижим, ли сам хост А. Если работа ping проходит нормально, то с сетью все в порядке, а проблема связана с хостом А. Если же невозможно достучаться до хоста А, то требуется пропинговать ближайший маршрутизатор, чтобы понять, удается ли достичь хотя бы границы собственной сети. Если это получается, то дальше можно воспользоваться программой traceroute, чтобы выяснить, насколько далеко можно продвинуться по маршруту к хосту А. Часто это помогает идентифицировать сбойный маршрутизатор или сделать предположение о месте возникновения ошибки.

Т.к. ping работает на уровне протокола IP, он не зависит от правильности конфигурации ТСР или UDP. Можно таким образом пропинговать свой хост, чтобы проверить правильность установки сетевого программного обеспечения. Сначала можно указать ping возвратный адрес localhost (127.0.0.1), чтобы убедиться в работе хотя бы части сетевой поддержки. Если при этом проблем не возникнет, то следует пропинговать один или несколько сетевых интерфейсов и удостовериться, что они правильно сконфигурированы.

Пример: ping –t 195.5.27.1; 192.168.64.1; 195.5.27.3; 195.5.27.1; 195.5.27.10;

Bsd:$ping netcom4.Netcom.com.

PING netcom4. .Netcom.com.(199.183.9.104):556 data bytes.

64 bytes from 199.183.9.104:incmp_seg = 0 tll = 245 time = 598.554 ms

---------------------------------------------------------------------------------------

64 bytes from 199.183.9.104:incmp_seg = 5 tll = 245 time = 598.554 ms

---------------------------------------------------------------------------------------

64 bytes from 199.183.9.104:incmp_seg = 10 tll = 245 time = 598.554 ms

завершим ping вручную:

--- netcom4. Netcom.comping statistics ---

12 packets transmitted, 10 packets receied, 16% packets loss round-trip min/avg/max/staddev = 400.137/540.939/598.554 k10 87/ms bsd$.

RTT (round-trip time)- период кругового обращения, т.е. время необходимое пакету для прохождения с одного хоста на другой и обратно. Для установления соединения нужно полтора таких периода RTT для разных таких пакетов мало и остаётся в пределах 500мс. RTT модифицируется от 480,137мс до 598,554мс со стандартным отклонением 40,871мс. При более длительном прогоне (около 2 мин.) результат существенно не изменится, это свидетельствует о том, что нагрузка на сеть постоянная. Значительный разброс RRT –это признак изменяющейся нагрузки сети. При повышенной загрузке возрастает длина очереди в маршрутизаторе и RTT. При изменении загрузки очередь сокращается, что приводит к изменению RTT.

В таблице отсутствует ответ на этот запрос ICMP с порядковым номером 4. Это означает, что запрос либо ответ потеряны одним из промежуточных маршрутизаторов. По данным сводной статистики было послано 12 запросов (0-11) и получено 10 ответов. Один из пропавших ответов имеет порядковый номер 4, а второй 11(т.к. прервана работа ping). Для работы ping требуется функционирование самых нижних служб (сетевых уровней), поэтому ping полезна для проверки связи в условиях, когда сервисы высокого уровня (TCP, telnet) не работают. С помощью ping часто удаётся сделать выводы об условиях в сети, наблюдая за значениями и дисперсией RRT и за числом постоянных ответов.

Утилита traceroute

Утилита traceroute служит для нахождения ошибок маршрутизации, изучения трафика в Internet и исследования топологии сети.

Утилита пытается определить маршрут между двумя хостами в сети, заставляя каждый промежуточный маршрутизатор посылать ICMP – сообщение хосту – отправителю. В каждой IP – датограмме есть поле TTL (time – to – live – время жизни). Это поле уменьшается на единицу каждым маршрутом, через который походит дейтаграмма. При TTL равным 0, датаграмма уничтожается. Отрицательно TTL измеряется в секундах, в действительности это поле интерпретируется маршрутизаторами как счетчик промежуточных узлов. Прождав время 2MSL, хост 1, который закрывает свою сторону приложения, завершат процесс, traceroute ziggy. uf.edu

Traceroute to ziggy.uzf.edu(131.247.1.40), 30 hops max, 40 byte packets

tam – fl – pm8.Netcom.net(163.179.44.15)

128.960 ms 139.230.ms 129.483 ms

tam – fl – gqlt. netcom.net(163.179.44.15)

139.436 ms 129.226 ms 129.570 ms

-----------------------------------------------------------------------------------------------------

131.247.254.36(131.247.254.36) 209 310 ms 199.281 ms 219.588 ms
ziggy.uzf.edu(131.247.1.40)209.591 ms* 210.159 ms

Число слева в строке – это номер промежуточного узла за ним идет имя хоста или маршрутизатора в этом узле и далее IP – адрес (строка 13). Программа пыталась определить имя хоста или маршрутизатор трижды, а три числа, следующие за IP – адресом – это периоды кругового обращения (RTT) для каждой из трех попыток. Если при очередной попытке теряется, то вместо времени печатается «*», netcom.net – сервис – провайдер, через который bsd выходит в Internet.

Когда TTL равен 1 (или 0), он отбрасывает ее и посылает отправителю ICMP – сообщение «истекло время внутри». Программа traceroute использует это свойство. Сначала она получателю посылает ИДР – датаграмму, в которой TTL устанавливается равной 1. Когда датаграмма доходит до первого маршрутизатора,. Тот определяет, что поле TTL равно 1, отбрасывает и посылает ее и посылает отправителю ICMP – сообщение. Таким образом, становится известным адрес первого промежуточного узла, и traceroute пытается выяснить его имя с помощью функции gethostbyaddr. Чтобы получить информацию о втором узле traceroute повторяет процедуру, но с TTL=2. Маршрутизатор в первом узле уменьшит ТТЛ на 1 и отправит дейтограмму дальше. Второй маршрутизатор определит 1 в поле TTL, отбросит дейтаграмму и пошлет ICMP – сообщение отправителю. Увеличивая TTL и повторяя запуск traceroute автоматически можно построить весь маршрут от отправителя к получателю. Когда датаграмма с достачно большим начальным значением TTL доходит до получателя, ТСР/IP пітается доставить ее ожидающему приложению. Однако traceroute устанавливает такое значение порта (процесса) назначения, которое вряд ли кем-ни-будь используется, поєтому хост – получатель вернет ICMP – сообщение «порт недоступен», которое traceroute воспринимает как обнаружение конкретного получателя, и трассировку можно завершить.

Т.к. протокол UDP ненадежен, не исключена возможность потери датаграмм. Поэтому traceroute пытается достучаться до каждого промежуточного хоста или маршрутизатора несколько раз, по умолчанию 3 попытки, но это можно изменить с помощью опции –g. Время, отведенное по умолчанию на ожидание ICMP – сообщения после каждой попытки составляет 5с, то его также можно менять с помощью опции w. Если в течении этого времени ответ не придет, то вместо RTT выводится («*»).

Утилиты traceroute предполагает, что маршрутизаторы будут, как положено, отбрасывать IP – датаграммы; в которых TTL = 1 и посылать ICMP – сообщение « истекло время внутри». Некоторые маршрутизаторы ошибочно переправляют далее датаграммы, в которых TTL = 0. Если такое происходит, то следующий маршрутизатор, например, N + 1 отбросит дейтаграмму и вернет ICMP – сообщение, «истекло время в пути». На дальнейшие итерации маршрутизатор получит датаграмму со значением TTL, равным 1, и вернет обычное ICMP – сообщение. Таким образом, маршрутизатор N + 1 появится дважды.

Утилиты traceroute позволяет проследить в динамике маршруты сообщений, например, изменение маршрута для сбалансирования нагрузки.

Еще одна проблема состоит в том. Что некоторые организации, ошибочно пологая, что ICMP – сообщения несут опасность, отключают их и маршрутизаторы полностью блокируют все ICMP – сообщения. Первый же маршрутизатор в этом случае сбросит сообщение «истекло время в пути» и сообщение «порт не доступен».

Следующая проблема – это асимметрия маршрутов. При запуске traceroute получается маршрут до пункт а назначения от пункта отправления. Но нет гарантии, что дейтаграмма будет следовать тем же маршрутом, 49% маршрутов имеют асимметрию.

Программа tracert в Windows.

Программа tracert работает аналогично traceroute, но для определения маршрута используются не UDР – датаграммы, а эхо – запросы протокола ICMP. В результате хост – получатель возвращает эхо – получатель возвращает эхо – ответ ICMP, а не сообщение о недоступности порта. Промежуточные маршрутизаторы по – прежнему возвращают сообщение, «истекло время в пути». Эхо – запросы и эхо – ответы менее подвержены отфильтровыванию маршрутизаторами.

Программа ttcp.

Программ ttcp, бесплатно распространяемая лабораторией баллистических исследований, служит для возможности передачи произвольного объема данных другой или той же самой машине по протоколу ТСР или UDР и сбора статической информации о полученных результатах.

У программы ttcp есть несколько опций, позволяющих управлять: объемом посылаемых данных, длиной отдельных операций записи и считывания буферов приема и передачи сокета и др.

Порядок вызова

Ttcp –t [опции] хост [
Ttcp –r [опции] > [out]

Часто используемые опции:

l ### Длина в байтах буферов, в которых происходит считывание из сети и запись в сеть (по умолчанию 8192).
u ## использовать ИДР, а не ТСР
p ## Номер порта, в который надо посылать данные или прослушивать (по умолчанию 5001).
s – t: Отправить данные в сеть.
s r: Считать (или отбросить) все данные из сети.
A – Выравнивать начало каждого буфера на эту границу (по умолчанию 1634)
O – Считать, что буфер начинается с этого смещения относительно границы (по умолчанию 0)
V – Печать более подробную статистику
d – Установить опцию сокета SO_DEBUG.
b ## Установить размер буфера сокета (если поддерживается ОС)
f x – формат для вычисления скорости обмена: к, К – кило (бит, байт), m, M = мега, g, G = гига.

Опции, употребляемые вместе c – t;

n ## число буфера, записываемых в сеть (по умолчанию 2048),

D – не буферизировать запись по протоколу ТСР (установить опцию сокета ТСР_NODELAY).

Опции, употребляемые вместе c – r:

B для – S, выводить только полные блоки в соответствии с опцией –1 (TAR).
T “touch”: обращаться к прочитанному байту.

При проверке программы сначала прогоняется тест с размером буфера, выбранным по умолчанию, чтобы получить точку отсчета.

В одном окне записывается ttcp -– потребителя.

Bsd: $ ttcp - rcv

В другом – ttcp – источника.

Bsd:$ ttcp – tsv bsd

ttcp – t: buflen = 8192, nbuf = 2048, align = 16384/0, port = 5013, tcp = bsd.
ttcp –t: socket
ttcp –t: connect
ttcp –t: 16777216 bytes in 1.341030 real seconds = 12217.474628 cb/sec (95. 449021 Mb/sec)
ttcp –t: 16777216 bytes in 000 CPU seconds = 16384000.000000 кB/cpu sec
ttcp –t:2048 J/0 calls, msec/ call = 0.67.calls/cec = 1527.18
ttcp –t: buffer address 0x8050000

bsd:$

ttcp дает информацию о производительности. Для передачи 16 Мб потребовалось около 1,3 с.

Аналогичная статистика печатается принимающем процессом, но цифры те же.

При установке размера буфера передачи равным 1448 байт и сохранении параметров приемника:

Bsd: $ ttcp –tcvb 1448 bsd

Bsd:$

Передача занимает 41 мин реального времени, а процессорное время осталось малым.

Программу ttcp можно использовать для тестирования собственніх приложений и организации сетевого конвеера между двумя или более машинами.

Программа tcpdump (снифер) сетевой анализатор для поиска неисправностией в сети и отладки сетевых приложений.

Snoop в solaris, iiptrace/ipreport AIX – поставляются вместе с ОС, иногда используются программы третьих фирм – tcpdump.

Сниферы используются для изучения динамики и взаимодействия в сетях, для изучения работы сетевых протоколов. Утилита tcpdump работает во всех Uhix и Windows. Тексты tcpdump опубликованы и ее можно адаптировать для специальных целей или перенести на новую платформу.

Tcpdump состоит из двух компонент: первая работает в ядре и занимается перехватом и, возможно. Фильтрацией пакетов, а вторая действует в адресном пространстве пользователя и определяет интерфейс пользователя, а также выполняет форматирование пакетов, если последнее не делается ядром.

Пользовательская компонента tcpdump взаимодействует с компонентой в ядре с помощью библиотеки libcap (блока для перехвата пакетов), которая абстрагирует системно – зависимые детали общения с канальным уровнем стека протоколов, например, с пакетным фильтром BSD (BDF _ BSD packet bilter) BPF исследует каждый пакет, проходящий через канальный уровень и сопоставляет его с фильтром, заданным пользователем. Если пакет удовлетворяет критерию фильтрации помещается в выделенный ядром буфера, который accoциируется с данными фильтром. Когда буфер заполняется или истекает заданный пользователем тайм – аут, содержимое буфера передается приложению с помощью libcap .

ПЕРЕХВАТ ПАКЕТОВ С ПОМОЩЬЮ BPF

Программа tcpdump и любая другая программа использует BPF для считывания необработанных пакетов, а пользовательская программа читает данные из стека TCP/IP как обычно. BPF перехватывает сетевые пакеты на уровне драйвера устройства, т.е. как только они считаны с носителя. Это не то же самое, что чтение из простого сокета, когда получаются IP – дейтаграммы, уже обработанные уровнем IP и преданные непосредственно приложению, линия транспортный уровень (ТСР или UDР) архитектура WinDump похожа на BSD эта программа пользуется специальным NDIS – драйвером (спецификация стандартного интерфейса сетевых адаптеров), предоставляющем совместный с BPF фильтр и интерфейс NDIS драйвер представляет собой часть стека протоколов, но функционирует он также tcpdump, но надо заменить BPF на драйвер NDIS.

Использование tcpdump

Поскольку применение сетевых анализаторов небезопасно, по умолчанию tcpdump конфигурируется с полномочиями суперпользователя root(BSD). Для Win этих ограничений нет. Если NDIS.-драйвер установлен, то программой WinDump можно пользоваться. В BSD следует сделать tcpdump setuid – программой. Если вызвать tcpdump вообще без параметров, тогда будут перехватываться все пакеты и выводить о них информацию. Но лучше указать кааой-нибудь фильтр, чтобы видеть только нужные пакеты и не отвлекаться на остальные. Например, если требуются лишь пакеты, полученные от хоста bsd или отправленные ему, то можно вызвать tcpdump:

tcpdump host bsd

Если нужны пакеты, которыми обмениваются хосты bsd и sparc то так же используется фильтр:

Фильтровать можно следующие атрибуты:

Протокол
хост отправления и /или назначения
сет отправления и /или назначения
Ethernet-адрес отправления и /или назначения
Порт отправления и /или назначения
Размер пакета
Пакеты, вещаемые на всю локальную сеть или группу (u в Ethernet, u в IP)
Пакет, используемый в качестве шлюза указанным хостом

Можно проверять конкретные биты или байты в заголовках протоколов. Например, чтобы отбирать только TCP-терминалы, в которые выставлен бит срочности, следует использовать фильтр:

tcp[13]&16

Четвертый бит четырнадцатого байта заголовка TCP – это бит срочности.

Т.к. разрешается использовать булевские операторы (and) или (&&), or (или ||)not(или !) для комбинирования предикатов, можно задавать фильтры произвольной сложности

Icmp and not sprc net localnet – фильтр, отбирающий ICMP-пакеты, приходящие из внешней сети.

Выходная информация, формируемая tcpdump

Информация, выдаваемая tcpdump зависит от протокола.

Пример. С помощью клиента udphelloc следует послать один байт в порт сервера времени дня в домене netcom.com:

bsd:$ udphelloc netcom4. netcom.com daytime

Thu Sep 16 15:11:49 1999

bsd:$

Хост netcom4 возвращает дату и время в UDР-дейтаграмме

18:12:23 bsd 1127>netcom4.netcom.com.daytime: nop1

18:12:23.389284 netcom4.netcom.com.daytime>bsd.1127:26

bsd послал netcom4 UDР-дейтаграмму длиной 1 байт, а netcom4 ответил дейтаграммой длиной 26 байт.

Протокол обмена ICMP пакетами аналогичен.

Трассировка одного запроса, генерируемого программой ping с хоста bsd на хост netcom4:

1. 06:21:28.690320 bsd>netcom4.netcom.com:icmp:echo request

2. 06:21:29.400433 netcom4.netcom.com.daytime>bsd.1127:26

Строка icmp: означает, что это ICMP-дейтаграмма, а следующий за ней текст описывает тип этой дейтаграммы. Недостатком tcpdump является неполная поддержка вывода собственно данных. По умолчанию tcpdump выводит только первые 68 байт, что достаточно для заголовков большинства протоколов. Авторы tcpdump не всегда дают ASCII-представление данных из-за возможности кражи паролей. Программы перевода выдачи tcpdump в код ASCII распространены.

# !/usr/bin/per l5
$ tcpdump= “/usr/sbin/tcpdump”;
open( ICPD, “$tcpdump@ARGV|” )||
“не могу запустить tcpdump; \$!\\n”;
$|=1;
While ()
{
if (/\t/)
{
chop;
$str=S_;
$str=-tr/\t//d;
$str=pack “H*”, $str;
$str=~tr/|x0-\x1f\x7f-\xff/./;
printf “\t%-40s\t%S\n”, substr ($_,4), $str;
}
else
{
print;
}
}

Программа netstat

Ядро ОС ведет разнообразную статистику об объектах, имеющих отношение к сети. Эту информацию можно получить. Существует четыре вида запросов.

1.Активные сокеты

netstat дает информацию о разных типах сокетов, но интерес представляют только сокеты из адресных доменов inet(AF_INET) и UNIX (AF_LOKAL или AF_UNIX). netstat a дает вывод всех типов сокетов или выбрать один тип, указав адресное семейство с помощью опции –f.

При необходимости получить сведения о TCP/ИДР сокеты, то следует вызывать netstat так

Bsd: $ netstat –f inet

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp 0 0 localhost.domain *.* listen

tcp 0 0 bsd domain *.* listen

udp 0 0 localhost.domain *.*

udp 0 0 bsd domain *.*

bsd:$ netstat –af inet

При обращении к серверу эхо-контроля с помощью telnet:

Bsd: $ telnet bsd echo, то появится соединение в состоянии ESTABLISHED:

Proto Recv-Q Send-Q localAddress Foreign Address (state)

tcp 0 0 bsd.echo bsd.1035 ESTABLISHED

tcp 0 0 bsd.1035 bsd.echo ESTABLISHED

tcp 0 0 *,echo *,* LISTEN

Т.к. соединение указано с локальной машиной

telnet – клиент подсоединился к порту 7 (порт эхо) и фактически использует его в качестве порта назначения, хост продолжает прослушивать этот порт. Это нормально, так как с точки зрения протокола TCP соединение – это 4 адреса : 2 локальных IP – адреса и порта и 2 удалённых IP – адреса и порта. inetd прослушивает порт на универсальном «псевдоадресе» INADDP_ANY (*.echo), тогда как IP – адрес для установленного соединения равен bsd. Если завершить работу клиента (telnet) и снова запустить netstat, получим :

Proto	Recv – Q	Send – Q	Local Address	Foreign Address	(state)
tcp	0	0	bsd.1035	Bsd.echo	TIME_WAIT

Клиентная строка соединения находится в состоянии TIME-WAIT.

Blog

О. С. Попова Хіхловська І. В. Системне та прикладне програмне забезпечення у телекомунікаціях Конспект

Формат пакета ping.

Порядок вызова