Салимóненко Дмитрий Александрович

ЗАДАНИЕ 1: Основы работы с сетью в LINUX при помощи утилит

Утилита nmap

Это – пожалуй, наиболее широко известная утилита в мире профессионалов, обслуживающих серверы Linux. В стандартные дистрибутивы Linux она, как правило, не входит, потому устанавливать ее необходимо самостоятельно. Естественно, для этого необходимы права администратора (суперпользователя).

Примечание. Для Windows также есть аналогичная утилита.

Архивы с утилитами можно скачать с официального сайта nmap.org. Там приведен довольно большой список версий. Я сам, к примеру, тестировал версию nmap-7.60.tgz от 2017-08-01, она имеет размер 12MБ.

В принципе, процесс установки этой утилиты очень хорошо описан здесь. На всякий случай, повторим здесь основные этапы.

Установка может производиться двумя путями:

1) Автоматическая установка:

(если Вы работаете в Ubuntu). ОС спросит пароль, после верного его ввода начнется установка.

Однако, может возникнуть проблема, если у Вас установлена старая версия Ubuntu. Дело в том, что релизы этой операционной системы меняются, вроде бы, каждые 9 месяцев. Соответственно, приведенная выше команда будет запрашивать версию nmap именно с тех адресов в интернете, которые соответствуют СТАРОЙ версии ОС. Однако, как правило, эти версии впоследствии переносятся в архив (что приводит к смене адреса). В итоге при попытке установки путем указанной команды Вы в консоли будете получать сообщения типа:

Подобные сообщения означают, что, скорее всего, по указанным адресам в архивах ничего полезного для нас нет (ошибка 404 означает. что соответствующая вебстраница недоступна). А это, в свою очередь, означает, что для того, чтобы воспользоваться данной командой, придется ВРУЧНУЮ (как и многое в Linux, увы) искать на официальном сервере Ubuntu необходимые нам архивы и, после чего, соответствующим образом конфигурировать команду.

Ну, или, как вариант – устанавливать самую последнюю версию ОС. Однако, если в процессе работы в Linux приходится периодически устанавливать то одни, то другие утилиты, модули, то из вышесказанного следует, что при этом придется, в среднем, 1-2 раза в год обновлять ОС. По поводу последнего я, теоретически, ничего не имею против. Однако, возникает резонный вопрос: а, собственно, работать-то в ОС – когда? Если постоянно/периодически приходится ее обновлять и, зачастую, заново устанавливать ранее инсталлированные утилиты? Это утомительно, да и время от времени придется вспоминать, как там что делалось.  Поэтому данный вариант, вероятно, будет не самым удобным.

2) Установка вручную:

а) wget -O Nmap.tgz http://nmap.org/dist/nmap-6.25.tgz

Это – команда, при помощи которой происходит скачивание утилиты версии 6.25. Обращаем внимание, что вместо этого можно самостоятельно посетить сайт nmap.org (ссылку см. выше) и скачать понравившуюся Вам версию утилиты оттуда вручную:
б) tar -xvzf Nmap.tgz

Это – команда разорхивации скачанного файла с утилитой. При этом автоматически создастся каталог с именем nmap-6.25. В него следует перейти при помощи следующей команды:
в) cd nmap-6.25

Переходим в нужный каталог:
г) ./configure

По всей видимости, это – команда что-то где-то конфигурирует. Делает она это долго, несколько минут. Следует дождаться удачного завершения.
д) make

Запускаем созданный make-файл. Это – тоже довольно длительный процесс, но и он когда-нибудь закончится.
е) sudo make install

И, наконец, в качестве завершающего этапа – запускаем саму команду инсталляции утилиты nmap. Еще немного ожидания – и утилита будет установлена в системе. По крайней мере, у меня в VMware Player, Linux Ubuntu 14.10 она установилась без особых проблем.

Для того, чтобы узнать информацию о работе этой команды, можно воспользоваться, как обычно, справочной системой:
man nmap

Предупреждаем, что содержание справки здесь составляет более 2000(!) строк. Возможности данной утилиты достаточно широки. Но, мы с Вами рассмотрим лишь некоторые из них – чтобы Вы получили представление о том, какие примерно виды задач она может решать.

Примечание. Не стоит вводить ПРОИЗВОЛЬНЫЙ IP-АДРЕС при использовании данной утилиты. В диапазон адресов могут попасть некие интересные учреждения, о которых в обычной жизни говорить вслух не принято. Даже сканирование (не говоря уже о пинговании) адресов, сетей таких учреждений может окончиться (в России) тюремным сроком. Раз уж даже за митинги или перепосты чужих сообщений людей сажают.

1) nmap scanme.nmap.org

Для примера, взят сервер - сайт разработчика утилиты: scanme.nmap.org. И вот результаты:

Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-14 12:52 PDT
Stats: 0:00:03 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 2.15% done; ETC: 12:54 (0:02:17 remaining)
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.25s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:­91ff:fe18:bb2f
Not shown: 990 filtered ports
PORT  STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
110/tcp   closed pop3
111/tcp   closed rpcbind
199/tcp   closed smux
256/tcp   closed fw1-secureremote
995/tcp   closed pop3s
1025/tcp  closed NFS-or-IIS
5900/tcp  closed vnc
31337/tcp open   Elite
Nmap done: 1 IP address (1 host up) scanned in 35.34 seconds

Что видим? Программа показывает IP-адреса в двух форматах: IPv4 и IPv6. Показываются также открытые (open) и закрытые (closed) порты. Также сообщается, что есть 990 портов, которые заблокированы сервером. Т.е. о них информации утилита nmap получить не может.

Примечание. Интересно, что при повторном вызове утилиты для этого сайта выдаваемая информация гораздо скуднее и состоит всего из двух видов протоколов – SSH и HTTP. Возможно, сервер, обнаружив, что с нашего IP-адреса произошел повторный аналогичный запрос, перестал «затруднять себя», выдав только наиболее необходимые, по его мнению, порты.

Nmap распознаёт следующие состояния портов: open, filtered, closed, или unfiltered:

1. Open означает, что приложение на целевой машине готово для принятия пакетов на этот порт.
2. Filtered означает, что брандмауэр, фильтр, или что-то другое в сети блокирует порт, так что Nmap не может определить, является ли порт открытым или закрытым.
3. Closed — не связаны в данный момент ни с каким приложением, но могут быть открыты в любой момент.
4. Unfiltered порты отвечают на запросы Nmap, но нельзя определить, являются ли они открытыми или закрытыми.

Мы видим, что, скажем, для того, чтобы обратиться к данному серверу по протоколу SSH (например, при помощи интерфейса сокетов), необходимо указывать порт 22 для ТСР протокола (см. задания с сокетами по предмету Вычислительные Системы, Сети и Телекоммуникации). Напомним, что порт задается командой вида
addr.sin_port = htons(3425);

В данном случае, вместо 3425 будет фигурировать порт под номером 22.

Если же мы захотим обратиться к этому серверу по протоколу http, тогда порт нужно указать номер 80.

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

Для проверки, Вы можете ввести любое другое (существующее!) доменное имя какого-нибудь сайта – и утилита выдаст информацию о портах для сервера, на котором физически находится этот сайт.

Таким образом, зная доменное имя, протокол и номер порта, соответствующий последнему, для конкретного сервера, можно послать ему запрос и получить ответ.

Вместо доменного имени можно ввести IP-адрес, например:
nmap 45.33.32.156

Результат будет тем же самым.

В локальной сети (состоящей из одного компьютера, подключенного через виртуальную машину и модем – к провайдеру) выдается сообщение следующего вида:
Nmap scan report for localhost (192.168.145.135)
Host is up (0.0000010s latency).
All 1000 scanned ports on localhost (192.168.145.135) are closed
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds

Данная утилита позволяет применять многочисленные опции:

Сканирования протокола TCP SYN:
nmap -sS 192.168.145.135

Сканирования протокола UDP:
nmap -sU 192.168.145.135

Сканирование протокола IP:
nmap -sO 192.168.145.135

Сканирование выбранных портов (80, 25, 443):
nmap -p 80,25,443 192.168.145.135

Сканирование диапазона портов 1024-2048:
nmap -p 1024-2048 192.168.145.135

Обнаружение вида ОС:
nmap -O --osscan-guess 192.168.145.135

В локальных сетях или просто имея на руках диапазон ip адресов, удобно проверить их на занятость с помощью ключей –sP (с указанием маски):
nmap -sP 192.168.145.0/24

Ответ будет выглядеть так:
Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-14 13:38 PDT
Nmap scan report for localhost (192.168.145.2)
Host is up (0.0070s latency).
Nmap scan report for localhost (192.168.145.135)
Host is up (0.00015s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 2.68 seconds.

Таким образом, видим, что в локальной сети имеется 2 хоста. Времена ответов для них составляют, соответственно, 0,007 сек и 0,00015 сек.

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

Более подробно работа утилиты nmap рассмотрена, например, в этой статье. Можете опробовать некоторые примеры из этой статьи.

Утилита ip a (ifconfig – аналог)

Эта утилита дает информацию о сетевых интерфейсах (аналогичные программы будут выполнены Вами в Задании 2). Вот примерный результат ее работы:

Видим, что присутствуют два интерфейса: локальный (lo) и приватный (eth0).

Утилита ping

Данная утилита позволяет проверить доступность хостинга (сервера) по его IP-адресу или по доменному имени, замеряя время отклика сервера. Например:

• Можно узнать IP-адрес по доменному имени.
• Можно узнать, работает ли сервер. Например, системный администратор может узнать, завис ли только веб-сервер или проблемы с хостом.
• Можно узнать, есть ли связь с сервером. Например, проблемы с настройкой DNS серверов на машине можно узнать, задав в ping сначала доменное имя, а потом IP-адрес.
• Также можно узнать качество канала, посмотрев, сколько ответов не пришло.

Примечание. В Windows есть аналогичная утилита.

Вот  как ею пользоваться:

или

Вот что получится:

Видим, что среднее время ответа сервера составляет примерно 240 мс. Чем выше это время, тем хуже доступен сервер.

Также видим, что 0% пакетов потеряно. Это говорит о том, что связь является надежной, передача сообщений происходит без потерь. В принципе, при таких условиях можно пользоваться не только протоколами ТСР, но и UDP.

У этой утилиты также есть опции, правда, список их не такой большой, как у nmap.

Утилита netstat

Если она запущена без параметров, то в консоли показывается список ВСЕХ открытых сокетов. Как PF_INET, так и PF_UNIX. Который является огромным.

Вот наиболее интересные опции:

-а   - показывает как слушающие, так и не слушающие сокеты. Т.е. – все.
-р  - показывает идентификатор и имя программы (точнее, процесса), создавшей сокет.
-n  - показывает IP-адреса в числовом виде.

Вводим
netstat -anp

Вот что выдается:

… и т.д.

Видим, что приватного адреса вида 192.168.145.135 не показывается, вместо него – адрес 127.0.0.1. Что же касается многочисленных сокетов в домене UNIX, то это сокеты, используемые ОС без обращения к сети.

netstat -p –inet

Команда покажет активные соединения (по протоколам TCP, UDP) – только интернетные серверы, без внутренних соединений. Результат будет примерно таким:

Утилита dig / nslookup

Зная имя хоста с помощью DNS запроса (DNS lookup) можно узнать его IP. Но иногда нужно решить обратную задачу: узнать имя хоста для которого известен IP адрес. Это называется reverse DNS lookup, можно перевести как обратное DNS преобразование или обратный DNS запрос. Вообще, в сети есть соответствующие сервисы, которые можно применить для этой цели. Например, там по своему IP-адресу можно узнать хост своего интернет-провайдера (Билайн, Мегафон, МТС, Теле и т.д.). Но, как это сделать при помощи своего компьютера?

В Linux обратное DNS преобразование можно сделать с помощью команды dig к которой добавлена опция -x:

dig -x 185.117.153.79

В Windows и Linux также можно использовать команду nslookup:

nslookup 185.117.153.79

Этот способ работает далеко не всегда. А лишь только, если в базе данных Reverse DNS (обратного DNS) присутствует PTR запись. PTR (pointer — указатель) запись сопоставляет IP адрес с доменным именем. Она часто называется "reverse DNS entry" (обратная DNS запись), поскольку она преобразовывает IP адрес в имя.

PTR записи преимущественно используются в мерах безопасности и предотвращения спама для верификации, что адрес почтового сервера разрешён для отправки email от имени конкретного хоста. По обратной DNS записи проверяется, действительно ли имя сервера ассоциировано с IP адресом, с которого было инициировано соединение.

Чтобы внести обратную DNS запись, которая бы связывала IP адрес (например, 185.117.153.79) с вашим доменом (например, site.com), вам нужно обратиться к вашему провайдеру IP адреса для создания PTR записи для конкретного IP адреса.

Утилита tcpdump

Эта утилита выдает информацию о сетевом обмене Вашего компьютера (точнее, сетевого интерфейса, функционирующего на нем) с сетью в режиме реального времени. По смыслу – она напоминает Задание 3, только, в отличие от него, имеет гораздо более широкие возможности. Эта утилита имеет множество опций. Посмотрите их, набрав
man tcpdump. Основные опции:

• -n - Отключает преобразование IP в доменные имена. Если указано -nn, то запрещается преобразование номеров портов в название протокола.
• -e - Включает вывод данных канального уровня (например, MAC-адреса).
• -v (-vv или -vvv) - Вывод дополнительной или еще более дополнительной информации (TTL, опции протокола IP).
• -w имя_файла - Задать имя файла, в который сохранять собранную информацию.
• -r имя_файла - Чтение дампа из заданного файла.
• -q - Переводит tcpdump в "бесшумный режим", в котором пакет анализируется на транспортном уровне (протоколы TCP, UDP, ICMP), а не на сетевом (протокол IP).
• -t - Отключает вывод меток времени.
• -A - дает возможность выводить в консоль не только заголовки протоколов IP/UDP/ТСР, но и данные, полученные с веб-сервера, в ASCII-виде. Это бывает очень полезно при отладке клиент-серверных приложений, когда необходимо посмотреть в консоли ответ сервера.
• -X - выводит эти данные в 16-ричном виде.

Кроме того, в составе ее параметров могут быть логические операторы and, or, not, т.е. можно комбинировать параметры, оформлять их в виде условий.

Для начала используйте команду sudo tcpdump -D, чтобы увидеть, какие интерфейсы доступны для захвата. Вот что получилось у меня, к примеру:

Видим, что под номером 2 имеется псевдоинтерфейс, обозначающий ВСЕ интерфейсы. Так вот, если использовать соответствующий параметр (any), то утилита tcpdump будет получать трафик со ВСЕХ интерфейсов.

Запуск утилиты для того, чтобы прослушивать ВЕСЬ сетевой трафик, осуществляется командой
sudo tcpdump -i any
Ключ -i показывает что мы захватываем пакеты с определенного (хоть и псевдо) интерфейса.

Теперь можно запустить эту утилиту как обычно, т.е. без учета локального интерфейса. Запустим ее:
sudo tcpdump –v

А теперь, не прерывая работы утилиты, можно попробовать открыть в браузере какую-нибудь вебстраницу (или обновить ее). Посмотрите, что получится. Рассмотрим, что будет, если в заранее открытом браузере Firefox открыть страницу 4846d.ru. Утилиту запустим со следующими параметрами:

sudo tcpdump -vnet

Так как объем информации, которой обмениваются браузер (точнее, сетевое соединение компьютера, которое использует браузер), открывающий страницу 4846d.ru, является довольно большим (почти 18 кБ), ниже рассмотрим лишь ее фрагменты, сообщаемой утилитой tcpdump, с их расшифровкой:

01:02:03:04:05:06 > 52:64:80:32:71:77, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.2 tell 10.0.2.15, length 28
52:64:80:32:71:77 > 01:02:03:04:05:06, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.0.2.2 is-at 52:64:80:32:71:77, length 46

Компьютер, имеющий МАС-адрес 01:02:03:04:05:06, имеющий IP-адрес 10.0.2.15, направляет запрос на компьютер, имеющий МАС-адрес 52:64:80:32:71:77 с помощью протокола ARP (сообщение имеет длину, равную 42 байта), используется сетевой протокол IPv4; запрос имеет следующий вид: какой МАС-адрес имеет узел с IP-адресом, равным 10.0.2.2 ?
Компьютер с МАС-адресом 52:64:80:32:71:77 отвечает источнику запроса (т.е. компьютеру с МАС-адресом 01:02:03:04:05:06) также при помощи протокола ARP, при помощи сетевого протокола IPv4, что IP-адрес, равный 10.0.2.2, имеет компьютер с МАС-адресом 52:64:80:32:71:77. Т.е. это - как раз тот самый компьютер, на который и был направлен запрос.

01:02:03:04:05:06 > 52:64:80:32:71:77, ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 34622, offset 0, flags [DF], proto UDP (17), length 54)
10.0.2.15.59127 > 10.0.0.1.53: 6707+ A? 4846d.ru. (26)

Компьютер, имеющий МАС-адрес 01:02:03:04:05:06 (с IP-адресом 10.0.2.15, порт 59127), направляет запрос на компьютер с МАС-адресом 52:64:80:32:71:77 (с IP-адресом 10.0.0.1, порт 53). Далее идет информация, касающаяся заголовков протокола IPv4, где, в частности, указано, что в качестве протокола транспортного уровня будет фигурировать UDP. А далее, после указания IP-адресов (с портами) источника и адресата указан id запроса, равный 6707; симвод + означает рекурсивный флаг. Длина запроса равна 26 байт, не включая заголовки UDP и IP протоколов. Символ А означает адресную запись. Далее указан домен, на который был направлен запрос.

Здесь мы видим уже ТСР-запрос на IP-адрес 37.140.192.59 и на стандартный порт 80. Это - IP-адрес сервера, на котором расположена страница 4846d.ru. Отметим, что так как эта страница была открыта в браузере ранее, IP-адрес сервера был известен браузеру, поэтому трафика с использованием ARP-протокола, связанного с обращением к серверам DNS и выяснением, какому именно IP-адресу соответствует такое доменное имя, может не быть. По той же причине может отсутствовать траффик, вызванный "тройным рукопожатием" браузера и сервера.
Далее, анализируя транспортный трафик, видим, что браузер с порта 46038 передает на сервер с IP-адресом 37.140.192.59 флаг РUSH, контрольную сумму, номер последовательности 150989406, содержащей 150989769-150989406 = 363 байт данных. Это - данные, записанные в формате протокола НТТР. Ну, а дальше - сразу же идут эти данные, представляющие собой HTTP-заголовки запроса браузера, плюс байты, обозначающие пропущенную строку (что, как мы уже знаем, обозначает конец заголовков).
Обратите внимание, что длина сообщения IP-протокола составляет 417 байт, ТСР-протокола - 403 байта, а НТТР-протокола - только 363 байта. Т.е. 417 > 403 > 363. Это - следствие инкапсуляции заголовков протокола друг в друга (более высокоуровневые инкапсулируются в менее высокоуровневые). Понаблюдайте за такой последовательностью длин сообщений протоколов разных уровней во всем трафике утилиты tcpdump.

Далее сервер отправляет подтверждение принятых заголовков:

Затем браузер начинает поочередно делать GET-запросы для скачивания файлов CSS, JS, фавиконки.

Tcpdump и процесс "тройного рукопожатия"

Все-таки, рассмотрим процесс "тройного рукопожатия" клиента (точнее, браузера) и сервера на конкретном примере. Чтобы избежать путаницы, сделаем такие фильтры для утилиты tcpdump, которые помогут избежать вывода излишней информации:

~$ sudo tcpdump -c 9 -i enp0s3 -nS host 4846d.ru

Здесь 9 –  максимальное число захватываемых (и выводимых на экран) пакетов, после чего работа утилиты останавливается; enp0s3 – имя сетевого интерфейса (для того, чтобы его узнать, используйте другие сетевые утилиты, например, ip a. Впрочем, имя сетевого интерфейса будет показано и при запуске tcpdump, в самом начале, так что его можно подсмотреть и там.

После чего в браузере обновим главную страницу сайта 4846d.ru. Итак, посмотрим, что получится:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes

1. 00:23:53.836734 IP 10.0.2.15.46102 > 37.140.192.59.80: Flags [S], seq 2435731096, win 29200, options [mss 1460,sackOK,TS val 86332015 ecr 0,nop,wscale 7], length 0
2. 00:23:53.876586 IP 10.0.2.15.46104 > 37.140.192.59.80: Flags [S], seq 4158226518, win 29200, options [mss 1460,sackOK,TS val 86332055 ecr 0,nop,wscale 7], length 0
3. 00:23:53.876842 IP 10.0.2.15.46106 > 37.140.192.59.80: Flags [S], seq 3298150341, win 29200, options [mss 1460,sackOK,TS val 86332056 ecr 0,nop,wscale 7], length 0
4. 00:23:53.898238 IP 37.140.192.59.80 > 10.0.2.15.46102: Flags [S.], seq 11328001, ack 2435731097, win 65535, options [mss 1460], length 0
5. 00:23:53.898268 IP 10.0.2.15.46102 > 37.140.192.59.80: Flags [.], ack 11328002, win 29200, length 0
6. 00:23:53.966816 IP 37.140.192.59.80 > 10.0.2.15.46106: Flags [S.], seq 11392001, ack 3298150342, win 65535, options [mss 1460], length 0
7. 00:23:53.966881 IP 10.0.2.15.46106 > 37.140.192.59.80: Flags [.], ack 11392002, win 29200, length 0
8. 00:23:53.966963 IP 37.140.192.59.80 > 10.0.2.15.46104: Flags [S.], seq 11456001, ack 4158226519, win 65535, options [mss 1460], length 0
9. 00:23:53.966999 IP 10.0.2.15.46104 > 37.140.192.59.80: Flags [.], ack 11456002, win 29200, length 0
   
10. 9 packets captured
11. 13 packets received by filter
12. 0 packets dropped by kernel

Рассмотрим детально информацию, выдаваемую этой утилитой. Слева видим временные метки (см. выше). Видим, что браузер послал первый запрос в момент времени 00:23:53.836734. Прождав сколько-то микросекунд, не получив ответа и, наверное, посчитав, что сервер этот запрос не получил, браузер посылает следующий запрос в момент времени 00:23:53.876586. И, вновь не дождавшись ответа, браузер посылает уже ТРЕТИЙ запрос, делая уже третью попытку соединиться с сервером. Тот, наконец-то, лишь после третьей попытки, ответил браузеру в момент времени 00:23:53.898238.

После временных меток, идут обозначения IP, т.е. работает протокол IP. В первых трех строчках направляется запрос с нашего адреса (10.0.2.15) на адрес хоста (37.140.192.59), как обычно, на открытый сервером по умолчанию порт 80. Это браузер делает запрос на сервер, пытаясь установить логическое соединение. В четвертой строчке, наоборот, сервер отвечает браузеру. И т.д.

После двоеточия в каждой строчке видим ключевое слово Flags - флаги. Сами они перечислены далее в квадратных скобках. В строчках 1…3 передается флаг SYN (обозначается как S). Затем идет номер последовательности (seq); браузер выбрал его равным 2435731096. Размер окна данных (win) установлен равным 29200 Байт.

Обратим внимание, что при очередной попытке браузера установить соединение он посылает каждый раз НОВЫЙ номер последовательности: вначале 2435731096, затем 4158226518 и, наконец, 3298150341.

В 4-й строчке мы можем наблюдать долгожданный ответ сервера только лишь на ПЕРВЫЙ(!) запрос браузера об установлении соединения. Это видно по тому, что сервер передал  acknowledgement (ack), равный 2435731097, что представляет номер последовательности 2435731096, переданный браузером в самом первом запросе, увеличенный на 1. При этом сервер, в рамках алгоритма «тройного рукопожатия», передал браузеру свой номер последовательности, равный 11328001. Сервер также посылает флаг SYN, что означает его готовность к установлению логического соединения и флаг АСК (обозначаемый точкой - .). Сообщение было отослано на порт 46102, который был открыт браузером при отсылке самого первого сообщения (см. 1-ю строчку).

В 5-й строчке браузер передает флаг АСК (обозначаемый точкой) и номер последовательности сервера, увеличенный на 1, т.е. число 11328002. Используется также порт 46102. Итак, после получения браузером этого сообщения логическое соединение, инициированное в 1-й строчке, считается установленным.

В 6-й строчке сервер дает ответ на 3-е сообщение браузера, аналогичный данному в 4-й строчке (на 1-е сообщение): он посылает браузеру ack 3298150342.

Самое интересное, что браузер подтвердил и этот ответ сервера – в 7-й строчке, послав серверу подтвердение АСК и флаг ack 11392002 (что на 1 больше, чем принятый от сервера seq 11392001, присутствующий в 6-й строчке). Сообщение от сервера в этот раз пришло на порт 46106, а ведь именно его открыл браузер при посылке серверу сообщения в 3-й строчке.

В 8-й строчке сервер, наконец-то, отвечает на… ВТОРОЕ сообщение браузера, т.е. на 2-ю строчку. Видим, что сервер прислал ему ack 4158226519, что на 1 выше, чем 4158226518. Также сервер прислал свой номер последовательности seq 11456001 и флаги SYN, ACK.

На что браузер, в 9-й строчке, подтвердил и это логическое соединение, прислав серверу флаг АСК, подтверждение ack 11456002, большее на 1.

Таким образом, можно констатировать, что:

• Браузер последовательно отправил три запроса об установлении соединения по номерам портов сокетов, соответственно, 46102, 46104, 46106.
• На момент отправления браузером сообщения из 9-й строчки установлено ТРИ логических соединения между ним и сервером по открытым портам сокетов с номерами 46102, 46106, 46104 (в хронологическом порядке установления соединений). Таким образом, второе соединение, будучи инициированным ранее третьего, установилось уже после него.
• Размер передаваемых данных равен 0, так как пока не идет речь об их передаче: происходит лишь установление трех логических соединений, передаются лишь заголовки протоколов ТСР с незаполненными полями данных.
• После установления соединений браузер будет использовать их для выполнения, например, GET-запросов, чтобы скачать с сервера html-код, а также иные ресурсы (CSS, JS и др.). В рамках этих запросов будут передаваться совокупности байтов, синтаксически форматированных по стандарту протокола HTTP. И вот тогда-то размер передаваемых данных будет отличен от нуля.

Поле данных протокола ТСР, содержащее в себе HTTP-запрос браузера, будет содержать:

1. Строку запроса (например, GET / HTTP/1.1),
2. Заголовки протокола НТТР,
3. Пустую строку (сигнализирующую сервера конец сообщения браузера).

Далее, разберем оставшиеся параметры (опции) сетевых запросов браузера и ответов сервера. В 1-й строчке мы видим:

win - количество байтов данных, ожидаемых отправителем данного, начиная с байта номер которого указан в поле подтверждения ack. Для оптимизации передачи отправитель не ждет подтверждения для каждого отправленного сегмента, а может отправить в сеть группу сегментов (но в байтах не больше размера окна). Если качество канала плохое (много запросов на повторную передачу, теряются подтверждения) окно уменьшается в размере, если хорошее — окно увеличивается.

options [mss 1460,sackOK,TS val 86332015 ecr 0,nop,wscale 7]

Опция mss (Maximum Segment Size) определяет максимальное количество байт, которое может быть получено источником сообщения в одном сегменте.

sackOK (Selective Acknowledgement) позволяет обоим участникам соединения принимать байтовые диапазоны. Обычно механизм подтверждения позволяет лишь подтвердить, что получатель имеет все данные, вплоть до специфического номера байта. В ответах сервера этот параметр отсутствует, вероятно, данный механизм не используется.

TS val / ecr используются TCP-протоколом для оценки примерного времени обработки запроса (round-trip time - RTT). TS val – это временная метка отправителя, а ecr – временная метка ответа, которая обычно представляет собой последнюю временную метку, полученную отправителем. Протокол TCP использует RTT для контроля правильности передачи.

В 1-й строчке браузер передал TS val 86332015, ecr 0. При последующих запросах браузер передавал увеличивающиеся метки времени. Вообще-то, в процессе обмена сообщениями браузера с сервером их временные метки (параметры val и ecr) должны бы меняться местами, что дополнительно будет подтверждать корректность получения сообщений. В данном случае, такой обмен почему-то не наблюдается.

Опция wscale представляет собой фактор шкалы окна. Например, если wscale = 7, win=29200 Байт, это означает, что браузер (см. 1-ю строчку) сообщает серверу, что максимальный размер его (браузера) буфера равен 7*29200 = 204400 Байт. Т.е. он может принять не более, чем 204400 Байт данных за один раз.

length – это длина сообщения (НТТР-запроса или ответа) в байтах. Включая и символы перевода строк. Сообщение в формате протокола HTTP содержится в поле данных протокола ТСР.

0. Самостоятельное задание:

1. Запустите утилиту, почти как было указано выше: sudo tcpdump -vne

2. Обновите страницу сайта. После этого прервите работу утилиты (Ctrl + C) и найдите в консоли сообщения, относящиеся в первому успешному "тройному рукопожатию". Поясните, что там происходило, какие параметры использовались и почему.

Утилита arp

Утилита arp используется для преобразования IP-адресов в адреса физической сети, к которой подключен компьютер, например, Ethernet или Wifi. Суперпользователь (администратор) может добавлять и удалять аrp записи. Вот пример информации, выдаваемой этой утилитой:

Видим, что на данный момент в ОС имеется 3 приватных хоста на одном интерфейсе.

Заключение

Вот, пожалуй, основные утилиты по работе с сетевыми интерфейсами и сетью в Linux. В Windows есть аналогичные утилиты – многие из них даже совпадают по названию и функциональности.

На самом деле, утилит по управлению сетью и ее конфигурированию – гораздо больше. Но, мы с Вами остановимся лишь на вышеизложенных, ибо они нам пригодятся для анализа результатов работы программ, которые Вы напишете самостоятельно, в рамках Заданий 2, 3.

Итак, освоив работу с сетевыми утилитами ОС Linux, можно перейти к самостоятельной разработке программ, представляющих собой упрощенные аналоги (естественно, с весьма и весьма урезанным функционалом) этих утилит. Переходим к Заданию 2.