Простые службы tcp ip. Коммуникации между приложениями

1.1 Основные службы TCP/IP

После прочтения этой главы и выполнения упражнений вы сможете:

понять, как работают протоколы и службы Прикладного уровня TCP/IP;

разобраться в возможностях, типах сообщений и структурах запроса/ответа множества основных служб TCP/IP, включая FTP, Telnet, SMTP и HTTP;

усвоить операции других основных служб TCP/IP, среди которых Echo,Quoteof the Day, Chargen, Whois,TFTP, Finger, RPC (Remote Procedure Call, удаленный вызов процедуры), службы NetBIOS over TCP/IP (также известные под именем NBT), а также SNMP;

объяснить, как нужно расшифровывать пакеты, содержащие протоколы Прикладного уровня, соотносить типы сообщений или другую подобную информацию с типами запросов и ответов, передающихся между клиентом и сервером (или между хостами в более общем смысле).

1.2 Виды атак на сетевом уровне TCP/IP

Атаки на TCP/IP можно разделить на два вида: пассивные и активные.

Пассивные атаки на уровне TCP

При данном типе атак крэкеры никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводиться к наблюдению за доступными данными или сессиями связи.

Подслушивание

Атака заключаются в перехвате сетевого потока и его анализе (от англ. "sniffing").

Для осуществления подслушивания крэкеру необходимо иметь доступ к машине, расположенной на пути сетевого потока, который необходимо анализировать; например, к маршрутизатору или PPP-серверу на базе UNIX. Если крэкеру удастся получить достаточные права на этой машине, то с помощью специального программного обеспечения сможет просматривать весь трафик, проходящий через заданные интерфейс.

Второй вариант -- крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях).

Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли.

Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell) или использование одноразовых паролей (например, S/KEY).

Другой вариант решения - использование интеллектуальных свитчей и UTP, в результате чего каждая машина получает только тот трафик, что адресован ей.

У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Один из ярких примеров -- общеизвестный tcpdump.

Активные атаки на уровне TCP

При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соответствующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN -затопление).

Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии.

Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется.

Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.

Предсказание TCP sequence number

Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.

Описание

Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN ), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK ) и собственный sequence number сервера (S-SYN ). Теперь уже клиент должен выслать подтверждение (S-ACK ). Схематично это можно представить так:

После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.

Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыток и с поправкой на скорость соединения) предсказать sequence number для следующего соединения.

Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.

Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.

Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант -- использование описанными в следующих разделах методов.

После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).

с Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.

с Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.

с Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B.

с Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK (заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным.

Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла.rhosts или отправки /etc/passwd крэкеру по электронной почте.

Представим это в виде схемы:

Детектирование и защита

Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети.

В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые в находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты?

Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм).

Если сеть использует firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.).

Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing"а (при условии, что используются криптографически стойкие алгоритмы).

Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.

Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing"а.

Описание

Необходимые условия -- крэкер должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов.

Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.

Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы.

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

Есть два способа рассинхронизировать соединение:

Ранняя десинхронизация

Соединение десинхронизируется на стадии его установки.

с Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии.

с Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN -пакет от имени клиента.

с Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN -пакет.

с Клиент игнорирует S-SYN -пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK -пакет от имени клиента.

с Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована.

Представим это в виде схемы:

Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные крэкером. Для корректной обработки этих ситуаций программа должна быть усложнена.

Десинхронизация нулевыми данными

В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.

Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии, вызывает так называемый ACK -бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK -пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.

К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK -пакеты не несут данных, повторных передачи не происходит и "буря стихает".

Как показали опыты, чем сильнее ACK -буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше.

Детектирование и защита

Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения.

Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK -бурь. Это можно реализовать при помощи конкретных средств контроля за сетью.

Если крэкер не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откроют новую сессию, не обращаясь к администратору.

Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровне протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP.

Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на , который требует молчаливого закрытия сессии в ответ на RST -пакет, некоторые системы генерируют встречный RST -пакет. Это делает невозможным раннюю десинхронизацию.

Пассивное сканирование

Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру.

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

Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN -пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN /ACK -пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST -пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN /ACK -пакеты он может также ответить RST -пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST -пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер).

Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать:

с резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST );

с прием от клиента RST -пакета в ответ на SYN /ACK .

К сожалению, при достаточно умном поведении крэкера (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение.

В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне.

Затопление ICMP-пакетами

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

Данная атака требует от крэкера доступа к быстрым каналам в Интернет.

Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его ping выдает скорость прохождения пакета.

При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию.

Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт.

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

Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на broadcast-адреса крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество broadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей, можно вызвать резкой заполнение канала "жертвы".

Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP).

В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood"а, ограничьте доступ к ping.

Локальная буря

Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю высылается строка знакогенератора) и других (date etc).

В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности.

Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов.

Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов).

Затопление SYN-пакетами

Пожалуй, затопление SYN -пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие заняться этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом.

Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN /C-ACK -пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течение заданного времени от клиента не придет S-ACK , соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED.

Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN -пакет, приглашающий к установке соединения. По RFC он будет молча проигнорирован.

Затопление SYN -пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель.

В различных системах работа с очередью реализована по-разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет, и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN -пакетов, а для Solaris 2.5 их количество будет гораздо больше.

После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD).

Как обычно, крэкер может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика.

Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN -затопления, обратитесь к поставщику системы.

Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN -затопление и не пропустить его внутрь сети.

3.1.1. Модель “Клиент/Сервер”

“Клиент/Сервер” - модель взаимодействия, согласно которой компьютеры сети являются либо клиентами, либо серверами. Клиентами являются запрашивающие компьютеры, а сервером - компьютер, который обрабатывает запросы клиентов и отвечает на них.

Следует иметь в виду, что модель “Клиент/Сервер” применима и к

программам, когда серверная часть распределенного ПО обслуживает запросы нескольких его клиентских частей.

3.1.2. Сетевые службы, сокеты, порты и протоколы

Сетевыми службами или сервисами называют построенное на основе модели “Клиент/Сервер” программное обеспечение, которое используется для удаленного обмена данными

между приложениями в TCP/IP сетях.

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

Сокет в TCP/IP сети включает в себя

IP-адрес хоста и номер порта (числовой идентификатор приложения).

В тоже время сетевые приложения связанны

не только с уникальными номерами портов, но и с конкретными сетевыми протоколами.

Таким образом, использование сокетов позволяет автоматически определять,

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

Первоначально серверная часть сетевой службы создает так называемый

“слушающий” серверный сокет, обеспечивая тем самым возможность

Клиентским частям службы обращаться к этому сервису.

После чего клиентские части могут посылать запросы на открытие клиент-

Ских сокетов с указанием IP-адреса сервера и порта сервиса, т.е. на

Создание соединения для сетевого взаимодействия.

Когда это происходит, для осуществления взаимодействия с обнаруженным

Клиентом сервер автоматически создает новый (клиентский) сокет, а по

Старому - продолжает “слушать” запросы на установление новых

Соединений.

Используя эту схему, сервер может одновременно “общаться” с несколькими клиентами.

3.1.3. Назначение IP-адресов хостам и протокол DHCP

Назначение IP-адресов для множества компьютеров вручную представляет

Собой довольно утомительную процедуру.

Протокол DHCP (Dynamic Host Configuration Protocol) позволяет компьютерам

Сети автоматически получать IP-адреса.

При включении компьютер-клиент сам обращается к DHCP-серверу, и получает от него все необходимые параметры.

Данный протокол предоставляет три способа назначения IP-адресов:

“ ручное”;

“ автоматическое”;

“ динамическое”.

В “ ручном ” способе администратор размещает на DHCP-сервере

информацию о соответствии IP-адресов физическим MAC-адресам клиентов. Эти IP-адреса пересылаются компьютерам-клиентам в ответ на их запросы к DHCP-серверу.

При “ автоматическом ” способе DHCP-сервер назначает IP-адреса

клиентам из заданного пула без вмешательства человека. Границы пула назначаемых IP-адресов задает администратор в настройках DHCP-сервера.

Между идентификатором клиента и его IP-адресом по-прежнему, как и при ручном назначении, существует постоянное соответствие.

Оно устанавливается в момент первичного назначения сервером IP-адреса клиенту. При всех последующих запросах сервер возвращает тот же самый IP-адрес.

При “ динамическом ” способе сервер выдает IP-адрес клиенту на ограниченное время, называемое "сроком аренды", по истечении которого старый адрес освобождается, и клиент обязан запросить новый. Освободившийся адрес может быть предоставлен любому клиенту, в т.ч. и тому, который его ранее использовал.

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

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

При этом назначенный ему IP-адрес автоматически освобождается.

Когда компьютер подключается к другой подсети, то

ему автоматически назначается новый адрес.

Ни пользователь, ни сетевой администратор не вмешиваются в этот процесс. Это свойство очень важно для мобильных пользователей в беспроводных сетях, использующих технологии Wi-Fi или Bluetooth.

3.1.4. Отображение символьных имен на числовые IP-адреса: служба DNS

Доменная система имен DNS является распределенной базой данных,

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

Основной задачей сетевой службы DNS является

поиск адресуемых компьютеров с преобразованием символьных имен в числовые IP-адреса и наоборот.

База данных DNS поддерживается с помощью

иерархии территориально распределенных DNS-серверов,

взаимодействующих по одноименному протоколу.

DNS-сервер, отвечающий за доменное имя, может

делегировать ответственность за часть домена другому серверу, что позволяет возложить ответственность за актуальность информации на серверы различных организаций, отвечающих только за “свою" часть доменного имени.

При этом за хранение и обслуживание отельных узлов или зон DNS обычно

Отвечают несколько серверов, разделенных как физически, так и

Логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из серверов.

3.1.5. Протокол передачи гипертекста HTTP

Протокол HTTP (Hypertext Transfer Protocol) используется в Интернете для

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

Специальные программы - браузеры (Internet Explorer, Safari, Opera, FireFox,

Google Chrome и др.), являясь HTTP-клиентами, направляют запросы к

HTTP-серверам (веб-серверам) и отображают содержание полученных

От них веб-страниц.

Веб-сервера (из набора IIS корпорации Microsoft или Apache) ожидают

Поступления HTTP запросов, а затем выполняют поиск и отправку клиентам связанных с этими запросами веб-страниц.

3.1.6. Протокол передачи файлов FTP

FTP (File Transfer Protocol) - это протокол, обеспечивающий в стеке TCP/IP простой способ обмена файлами между компьютерами.

С помощью протокола FTP имеющий соответствующие полномочия пользователь может размещать, удалять, переименовывать, перемещать и копировать файлы, хранящиеся на FTP-серверах.

3.1.7. Протоколы удаленного терминального доступа Telnet и SSH

Протокол Telnet разрабатывался для обеспечения доступа пользователей к

удаленным компьютерам сети в режиме текстового терминала.

Однако этот протокол не использует шифрования и проверки подлинности данных. Поэтому сессия Telnet, если она осуществляется без применения особых средств защиты, уязвима для любого вида атак.

Для доступа к удаленным компьютерам в настоящее время используется

Сетевой протокол SSH , который позволяет безопасно передавать в

Незащищенной среде не только текст, но любой другой трафик,

Например, звуковой поток или видео.

Кроме того, SSH может сжимать передаваемые данные перед их шифрованием.

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

Примером программной реализации клиента как для протокола Telnet, так и для протокола SSH может служить программа PuTTy.

3.1.8. Простой протокол электронной почты SMTP

Протокол SMTP (Simple Mail Transfer Protocol) и его расширения -

это часть стека протоколов TCP/IP, предназначенная для организации электронной почты.

SMTP чаще всего применяется вместе с протоколами доступа к сообщениям: POP3 (Post Office Protocol v3) или IMAP (Internet Message Access Protocol). Причем для отправки почты используется протокол SMTP ,

а дл я ее получени я - POP3 или IMAP.

Данные протоколы позволяют организовать хранение электронной почты

Пользователей в их почтовых ящиках на серверах сети и ее загрузку на клиентские компьютеры лишь по мере надобности.

Почтовые программы (Outlook Express, The Bat и др.) позволяют определить как SMTP-сервер, так и POP3-сервер.

Обзор служб набора протоколов TCP/IP

2.1 Введение

Почему семейство протоколов TCP/IP получило столь широкое распространение? Прежде всего, благодаря способности к взаимному объединению гетерогенных локальных и глобальных сетей. Не менее важной является способность создавать основы для коммуникаций "равный с равным" (peer-to-peer), а также базовых служб поверх такого взаимодействия. Кроме того, с самого начала протоколы TCP/IP ориентировались на поддержку взаимодействия типа клиент/сервер.

2.2 Коммуникации между приложениями

Существует два основных типа взаимодействия между приложениями. Первый тип - связи, ориентированные на создание соединения (connection-oriented), - применяется при работе приложения с потоком данных. Второй вариант - связи без создания соединения (connectionless) - предполагает обмен независимыми сообщениями и подходит для случайных взаимодействий между приложениями при небольшом объеме пересылаемых данных.

2.2.1 Коммуникации с созданием соединений (TCP)

Протокол TCP (Transmission Control Protocol) отвечает в TCP/IP за надежные коммуникации с созданием соединения по принципу "равный с равным". Сеанс регистрации с терминала и пересылка файлов выполняются с помощью TCP.

2.2.2 Коммуникации без создания соединений (UDP)

Некоторые операции обмена данными не требуют постоянного взаимодействия систем. Например, база данных на сетевом сервере может содержать таблицы имен сотрудников компании и их телефонные номера. Узнать номер телефона конкретного сотрудника можно при передаче на сервер запроса с указанием имени этого сотрудника. Сервер должен будет ответить сообщением, содержащим соответствующий телефонный номер. Такой тип взаимодействия поддерживается протоколом пользовательских датаграмм (User Datagram Protocol - UDP).

2.2.3 Интерфейс программирования socket

Реализации TCP/IP обычно предоставляют для разработчиков коммуникационный программный интерфейс. Многие из таких интерфейсов основаны на программном интерфейсе socket (дословно - "штепсельная розетка", "гнездо"), который первоначально был разработан для операционной системы Unix университета Беркли.

К программному интерфейсу socket относятся:

■ Простые подпрограммы для создания, пересылки и приема независимых сообщений, используемых при коммуникациях без создания соединения по протоколу UDP

■ Программы для создания соединения TCP, передачи и приема данных, а также для закрытия созданного соединения

2.2.4 Программный интерфейс RPC

Хотя и не так широко распространенный, как socket, программный интерфейс вызова удаленных процедур (Remote Procedure Call - RPC) для соединений типа клиент/сервер достаточно часто используется в различных системах. Первоначально он был реализован в компьютерах компании Sun Microsystems, а затем перемещен на многие другие платформы.

Клиент, использующий интерфейс RPC, способен вызывать подпрограммы, которые автоматически пересылают запрос на сервер. Сервер исполняет затребованную подпрограмму и возвращает ее выходные результаты клиенту. Именно с этим связано название данного интерфейса, поскольку локально запущенная программа может инициировать обработку на удаленной системе.

Например, описанное в п. 2.2.2 приложение для просмотра телефонных номеров может быть реализовано через программы RPC.

2.3 Основные службы

Реализация TCP/IP предполагает доступность, по крайней мере, трех прикладных служб: пересылки файлов, удаленной регистрации и электронной почты. Многие продукты имеют клиентские и серверные службы для WWW, а также функции для печати на удаленных принтерах.

2.3.1 Пересылка файлов

Пересылка файлов (file transfer) является старейшей службой TCP/IP. Протокол пересылки файлов (File Transfer Protocol - FTP) разрешает пользователю пофайловое копирование с одной системы на другую. FTP имеет дело с простыми типами файлов, такими как текстовые файлы в коде для обмена информацией Американского национального института стандартов (American National Standard Code for Information Interchange - ASCII) или неструктурированные двоичные файлы. FTP обеспечивает пользователю доступ к удаленной файловой системе для выполнения служебных операций: переименования и удаления файлов либо создания новых каталогов.

2.3.2 Доступ с терминала

В начале 70-х гг. многие производители компьютеров создавали модели терминалов, которые были совместимы только с их собственными компьютерными системами. Министерство обороны США закупало оборудование у различных производителей и, естественно, настаивало на обеспечении для каждого терминала единообразного доступа к любому компьютеру сети. Протокол терминального доступа telnet сделал возможными такие операции для любого типа терминала. С течением времени telnet расширил свои возможности по работе с самыми разнообразными моделями терминалов и операционными системами.

2.3.3 Электронная почта

Электронная почта (далее будем называть ее просто почтой, а когда речь пойдет об обычной почтовой службе, это будет оговорено дополнительно.- Прим. пер.) привела к распространению TCP/IP среди многих конечных пользователей. Стандартизованы два аспекта почтовой службы:

■ Формат почтового сообщения, пересылаемого между пользователями. Определены форматы для неструктурированного текста, текста, состоящего из нескольких частей, и мультимедийных сообщений.

■ Механизмы для направления и пересылки методом сохранить-переслать дальше при обмене почтовыми сообщениями между хостами. С первых дней Интернета для этого применяется простой протокол пересылки почты (Simple Mail Transfer Protocol - SMTP). Более поздние расширения добавили этой службе новые функции.

Многие лицензионные почтовые системы были подключены к Интернету, что существенно расширило круг потенциальных пользователей почтовой службы.

На рис. 2.1 показано взаимодействие между хостами сети. Отметим, что TCP/IP полностью соответствует сетевой архитектуре "равный с равным" и любой из хостов может выступать как клиент или сервер, а также одновременно как клиент и сервер.

Рис. 2.1. Прикладные службы сети TCP/IP

2.3.4 Служба WWW

Word Wide Web (WWW) - наиболее привлекательная система из всех прикладных служб клиент/сервер, реализованных в TCP/IP. Пользователь может получить доступ к прекрасно оформленным документам, содержащим графические изображения и звуковые файлы, легко перемещаться между сайтами сети одним щелчком мыши и проводить поиск в огромных информационных архивах.

2.4 Дополнительные службы

К набору протоколов TCP/IP были добавлены и другие службы. Ниже рассмотрены наиболее популярные и широко распространенные.

2.4.1 Доступ к файлам

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

Многие продукты TCP/IP включают сетевую файловую систему (Network File System - NFS). Такие продукты поддерживают одну или обе роли NFS:

Доступ клиента к файлам. Позволяет компьютеру получить доступ к удаленным файлам как к локальным. Конечный пользователь и локальные программы могут не учитывать реальное размещение файла в сети.

Файловый сервер. Обслуживает каталоги, доступ к которым разрешен для других сетевых компьютеров.

2.4.2 Новости

Приложения для работы с электронными новостями появились для обслуживания локальных электронных досок объявлений (bulletin board) и распространения находящихся на них данных на другие сайты сети.

Многие организации используют бесплатное программное обеспечение для публикации внешней информации электронным способом. Другие организуют доступ к группам новостей Интернета, на которых обсуждаются самые разнообразные темы, начиная от спорта и кончая физикой плазмы. Такое программное обеспечение применяется и для доступа к коммерческим информационным службам новостей, например к Рейтер, АР или UPI.

2.4.3 Служба имен DMS

Для использования сетевых служб требуется способ идентификации удаленных компьютеров. Пользователи и программы могут указывать нужный компьютер по его имени, которое легко запомнить или ввести.

Для создания соединения с хостом имя хоста должно быть преобразовано в его цифровой адрес. Первоначально каждый хост TCP/IP хранил полный список всех имен и адресов для хостов сети. Однако при стремительном расширении Интернета это стало невозможным, поскольку число хостов стало измеряться тысячами и миллионами.

Система именования доменов (Domain Name System - DNS) предназначена для решения этой проблемы. DNS представляет собой базу данных для имен и адресов хостов, которая распределена по тысячам отдельных серверов. Протокол DNS разрешает пользователю послать запрос к базе данных локального сервера и получить ответ, который, возможно, придет от удаленного сервера.

Кроме трансляции имен и адресов хостов, серверы DNS предоставляют информацию для маршрутизации сообщений электронной почты в точку назначения.

2.4.4 Коммерческое программное обеспечение

Многие сторонние разработчики создают приложения, работающие поверх TCP/IP. Например, производители баз данных соединяют настольные компьютеры-клиенты с серверами средствами TCP/IP.

2.4.5 Управление сетью

По прошествии некоторого времени многие инструменты сетевого управления стали создаваться на основе набора протоколов TCP/IP. Например, существуют команды, позволяющие определить, находится ли конкретная система сети в рабочем состоянии, просмотреть ее текущую загрузку или получить список доступных в сети служб.

Такие команды очень полезны, но для централизации сетевого управления требуется единый и полный набор команд. В Интернете для этого был разработан простой протокол сетевого управления (Simple Network Management Protocol - SNMP), позволяющий обслуживать любой сетевой узел, начиная от простейшего устройства и заканчивая операционной системой хоста или прикладным программным обеспечением.

2.4.6 Диалоги

Лучшим способом понять работу служб TCP/IP является их применение на практике. Эта глава завершается несколькими краткими примерами интерактивных диалогов, иллюстрирующими работу служб сети. Во всех диалогах вводимые пользователем команды напечатаны полужирным шрифтом. Это соглашение будет применяться по всей книге. Основы работы со службами достаточно просты.

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

2.4.7 Диалог доступа с терминала

Доступ с терминала является примером работы с простейшей службой. В приведенном ниже примере запрашивается соединение по telnet с хостом bulldog.cs.yale.edu . После установки соединения telnet информирует, что комбинация клавиш CONTROL-] служит для возврата к сеансу с локальной системой. Затем удаленный хост выводит приглашение регистрации login :, и с этого момента начинается обычная работа с удаленным хостом, как если бы это был локальный компьютер.

> telnet bulldog.cs.yale.edu
Connected to bulldog.cs.yale.edu

Хотя это очень простой диалог с пользователем, за кулисами происходит достаточно большая работа. Telnet просматривает базу данных DNS и определяет, что адресом требуемой системы является 128.36.0.3. Именно этот адрес и будет использован telnet для соединения с удаленным хостом.

Схемы именования и нумерации TCP/IP будут рассмотрены в главе 5. Однако уже сейчас можно понять, что имя состоит из нескольких разделенных точками слов, а адрес - из четырех цифр, также разделенных точками.

2.4.8 Просмотр имен в базе данных DNS

Как и многие системы TCP/IP, используемый нами локальный хост имеет клиентское приложение nslookup (от network server lookup - просмотр сетевого сервера), которое разрешает пользователю интерактивно запросить базу данных DNS.

Ниже показан пример вывода имени и адреса локального сервера по умолчанию при вводе команды nslookup . Запрос к базе данных формируется при указании имени нужного хоста. В ответе повторяется введенное имя для проверки правильности его набора на клавиатуре.

Default Server: DEPT-GW.CS.YALE.EDU

2.4.9 Диалог при пересылке файла

Далее можно использовать FTP для копирования файла chapter1 из каталога book хоста plum.yale.edu на локальный хост. Начинающиеся цифрами строки - это сообщения от сервера пересылки файлов. Команда cd (change directory - изменить текущий каталог) служит для перехода к каталогу book на удаленном хосте. Команда get (получить) используется для копирования файла.

220 plum FTP server (SunOS 4.1) ready.

331: Password required for icarus


150 ASCII data connection for chapter1 (130.132.23.16,3330) (32303 bytes).
32303 bytes received in 0.95 seconds (33 Kbytes/s)

Пересылка файла упрощается в приложении для настольного компьютера с графическим пользовательским интерфейсом (Graphical User Interface - GUI). На рис. 2.2 показано копирование файла на персональный компьютер в приложении Chameleon компании Netmanage. Перечисленные справа файлы находятся на сервере Unix. Один из них (с именем Index-byname) выбран для копирования. После копирования ему будет присвоено имя index.txt, которое указано в левом окне. Операция копирования запускается щелчком мыши на командной кнопке со стрелкой или при перетаскивании значка файла.


Рис. 2.2. Пересылка файла через приложение для настольного компьютера

2.4.10 WWW

Можно копировать файлы и с серверов WWW, не задумываясь об их реальном размещении. На рис. 2.3 показан экран браузера Netscape Navigator . Новые документы извлекаются щелчком мыши на одной из выделенных фраз. Далее их можно сохранить на локальном диске через меню File/Save.


Рис. 2.3. Использование браузера Netscape

2.4.11 Новости

На рис. 2.4 представлен экран Chameleon для работы с новостями. На нем перечислены группы новостей по темам научных исследований.


Рис. 2.4. Группы новостей по научной тематике

2.4.12 Диалог для доступа к файлу

Рассмотрим последний диалог с пользователем. В этом примере используется компьютер с дисковой операционной системой (Disk Operating System - DOS), подключенный к сети TCP/IP. Мы переключимся на устройство d: локального хоста и просмотрим содержимое корневого каталога:


WPRINT1 344392 11-05-95 13:28p

К этому примеру даже не требуется особых пояснений: файлы, которые отмечены как находящиеся на локальном диске d :, реально читаются с удаленного сервера NFS.

Предположим, что вы плохо владеете сетевыми технологиями, и даже не знаете элементарных основ. Но вам поставили задачу: в быстрые сроки построить информационную сеть на небольшом предприятии. У вас нет ни времени, ни желания изучать толстые талмуды по проектированию сетей, инструкции по использованию сетевого оборудования и вникать в сетевую безопасность. И, главное, в дальнейшем у вас нет никакого желания становиться профессионалом в этой области. Тогда эта статья для вас.


Понятие о стеке протоколов

Задача - передать информацию от пункта А в пункт В. Её можно передавать непрерывно. Но задача усложняется, если надо передавать информацию между пунктами A<-->B и A<-->C по одному и тому же физическому каналу. Если информация будет передаваться непрерывно, то когда С захочет передать информацию в А - ему придётся дождаться, пока В закончит передачу и освободит канал связи. Такой механизм передачи информации очень неудобен и непрактичен. И для решения этой проблемы было решено разделять информацию на порции.

На получателе эти порции требуется составить в единое целое, получить ту информацию, которая вышла от отправителя. Но на получателе А теперь мы видим порции информации как от В так и от С вперемешку. Значит, к каждой порции надо вписать идентификационный номер, что бы получатель А мог отличить порции информации с В от порций информации с С и собрать эти порции в изначальное сообщение. Очевидно, получатель должен знать, куда и в каком виде отправитель приписал идентификационные данные к исходной порции информации. И для этого они должны разработать определённые правила формирования и написания идентификационной информации. Далее слово «правило» будет заменяться словом «протокол».

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

В протоколе Ethernet находятся номер сетевого адаптера отправителя (MAC-адрес), номер сетевого адаптера получателя, тип передаваемых данных и непосредственно передаваемые данные. Порция информации, составленная в соответствии с протоколом Ethernet, называется кадром. Считается, что сетевых адаптеров с одинаковым номером не существует. Сетевое оборудование извлекает передаваемые данные из кадра (аппаратно или программно), и производит дальнейшую обработку.

Как правило, извлечённые данные в свою очередь сформированы в соответствии с протоколом IP и имеют другой вид идентификационной информации - ip адрес получателя (число размером в 4 байта), ip адрес отправителя и данные. А так же много другой необходимой служебной информации. Данные, сформированные в соответствии с IP протоколом, называются пакетами.

Далее извлекаются данные из пакета. Но и эти данные, как правило, ещё не являются изначально отправляемыми данными. Этот кусок информации тоже составлен в соответствии определённому протоколу. Наиболее широко используется TCP протокол. В нём содержится такая идентификационная информация, как порт отправителя (число размером в два байта) и порт источника, а так же данные и служебная информация. Извлечённые данные из TCP, как правило, и есть те данные, которые программа, работающая на компьютере В, отправляла «программе-приёмнику» на компьютере A.

Вложность протоколов (в данном случае TCP поверх IP поверх Ethernet) называется стеком протоколов.

ARP: протокол определения адреса

Существуют сети классов A, B, C, D и E. Они различаются по количеству компьютеров и по количеству возможных сетей/подсетей в них. Для простоты, и как наиболее часто встречающийся случай, будем рассматривать лишь сеть класса C, ip-адрес которой начинается на 192.168. Следующее число будет номером подсети, а за ним - номер сетевого оборудования. К примеру, компьютер с ip адресом 192.168.30.110 хочет отправить информацию другому компьютеру с номером 3, находящемуся в той же логической подсети. Это значит, что ip адрес получателя будет такой: 192.168.30.3

Важно понимать, что узел информационной сети - это компьютер, соединённый одним физическим каналом с коммутирующим оборудованием. Т.е. если мы отправим данные с сетевого адаптера «на волю», то у них одна дорога - они выйдут с другого конца витой пары. Мы можем послать совершенно любые данные, сформированные по любому, выдуманному нами правилу, ни указывая ни ip адреса, ни mac адреса ни других атрибутов. И, если этот другой конец присоединён к другому компьютеру, мы можем принять их там и интерпретировать как нам надо. Но если этот другой конец присоединён к коммутатору, то в таком случае пакет информации должен быть сформирован по строго определённым правилам, как бы давая коммутатору указания, что делать дальше с этим пакетом. Если пакет будет сформирован правильно, то коммутатор отправит его дальше, другому компьютеру, как было указано в пакете. После чего коммутатор удалит этот пакет из своей оперативной памяти. Но если пакет был сформирован не правильно, т.е. указания в нём были некорректны, то пакет «умрёт», т.е. коммутатор не будет отсылать его куда либо, а сразу удалит из своей оперативной памяти.

Для передачи информации другому компьютеру, в отправляемом пакете информации надо указать три идентификационных значения - mac адрес, ip адрес и порт. Условно говоря, порт - это номер, который, выдаёт операционная система каждой программе, которая хочет отослать данные в сеть. Ip адрес получателя вводит пользователь, либо программа сама получает его, в зависимости от специфики программы. Остаётся неизвестным mac адрес, т.е. номер сетевого адаптера компьютера получателя. Для получения необходимой данной, отправляется «широковещательный» запрос, составленный по так называемому «протоколу разрешения адресов ARP». Ниже приведена структура ARP пакета.

Сейчас нам не надо знать значения всех полей на приведённой картинке. Остановимся лишь на основных.

В поля записываются ip адрес источника и ip адрес назначения, а так же mac адрес источника.

Поле «адрес назначения Ethernet» заполняется единицами (ff:ff:ff:ff:ff:ff). Такой адрес называется широковещательным, и такой фрейм будер разослан всем «интерфейсам на кабеле», т.е. всем компьютерам, подключённым к коммутатору.

Коммутатор, получив такой широковещательный фрейм, отправляет его всем компьютерам сети, как бы обращаясь ко всем с вопросом: «если Вы владелец этого ip адреса (ip адреса назначения), пожалуйста сообщите мне Ваш mac адрес». Когда другой компьютер получает такой ARP запрос, он сверяет ip адрес назначения со своим собственным. И если он совпадает, то компьютер, на место единиц вставляет свой mac адрес, меняет местами ip и mac адреса источника и назначения, изменяет некоторую служебную информацию и отсылает пакет обратно коммутатору, а тот обратно - изначальному компьютеру, инициатору ARP запроса.

Таким образом ваш компьютер узнаёт mac адрес другого компьютера, которому вы хотите отправить данные. Если в сети находится сразу несколько компьютеров, отвечающих на этот ARP запрос, то мы получаем «конфликт ip адресов». В таком случае необходимо изменить ip адрес на компьютерах, что бы в сети не было одинаковых ip адресов.

Построение сетей

Задача построения сетей

На практике, как правило, требуется построить сети, число компьютеров в которой будет не менее ста. И кроме функций файлообмена, наша сеть должна быть безопасной и простой в управлении. Таким образом, при построении сети, можно выделить три требования:
  1. Простота в управлении. Если бухгалтера Лиду переведут в другой кабинет, ей по-прежнему понадобится доступ к компьютерам бухгалтеров Анны и Юлии. И при неправильном построении своей информационной сети, у администратора могут возникнуть трудности в выдаче Лиде доступа к компьютерам других бухгалтеров на её новом месте.
  2. Обеспечение безопасности. Для обеспечения безопасности нашей сети, права доступа к информационным ресурсам должны быть разграничены. Так же сеть должна быть защищена от угроз раскрытия, целостности и отказа в обслуживании. Подробнее читайте в книге «Атака на Internet» автора Илья Давидович Медведовский, глава «Основные понятия компьютерной безопасности» .
  3. Быстродействие сети. При построении сетей есть техническая проблема - зависимость скорости передачи от количества компьютеров в сети. Чем больше компьютеров - тем ниже скорость. При большом количестве компьютеров, быстродействие сети может стать настолько низким, что она станет неприемлемой заказчику.
Из-за чего при большом количестве компьютеров снижается скорость сети? - причина проста: из-за большого количества широковещательных сообщений (ШС). ШС - это сообщение, которое, приходя на коммутатор, отправляется всем хостам сети. Или, грубо говоря, всем компьютерам, находящимся в вашей подсети. Если компьютеров в сети 5, то каждый компьютер будет принимать по 4 ШС. Если их будет 200, то каждый компьютер в такой большой сети будет принимать по 199 ШС.

Существует большое множество приложений, программных модулей и сервисов, которые, для своей работы отправляют в сеть широковещательные сообщения. Описанный в пункте ARP: протокол определения адреса лишь один из множества ШС, отправляемый вашим компьютером в сеть. Например, когда вы заходите в «Сетевое окружение» (ОС Windows), ваш компьютер посылает ещё несколько ШС со специальной информацией, сформированной по протоколу NetBios, что бы просканировать сеть на наличие компьютеров, находящихся в той же рабочей группе. После чего ОС рисует найденные компьютеры в окне «Сетевое окружение» и вы их видите.

Так же стоит заметить, что во время процесса сканирования той или иной программой, ваш компьютер отсылает ни одно широковещательное сообщение, а несколько, к примеру для того, что бы установить с удалёнными компьютерами виртуальные сессии или ещё для каких либо системных нужд, вызванных проблемами программной реализации этого приложения. Таким образом, каждый компьютер в сети для взаимодействия с другими компьютерами вынужден посылать множество различных ШС, тем самым загружая канал связи не нужной конечному пользователю информацией. Как показывает практика, в больших сетях широковещательные сообщения могут составить значительную часть трафика, тем самым замедляя видимую для пользователя работу сети.

Виртуальные локальные сети

Для решения первой и третьей проблем, а так же в помощь решения второй проблемы, повсеместно используют механизм разбиения локальной сети на более маленькие сети, как бы отдельные локальные сети (Virtual Local Area Network). Грубо говоря, VLAN - это список портов на коммутаторе, принадлежащих одной сети. «Одной» в том смысле, что другой VLAN будет содержать список портов, принадлежащих другой сети.

Фактически, создание двух VLAN-ов на одном коммутаторе эквивалентно покупке двух коммутаторов, т.е. создание двух VLAN-ов - это всё равно, что один коммутатор разделить на два. Таким образом происходит разбиение сети из ста компьютеров на более маленькие сети, из 5-20 компьютеров - как правило именно такое количество соответствует физическому местонахождению компьютеров по надобности файлообмена.

  • При разбиении сети на VLAN-ы достигается простота управления. Так, при переходе бухгалтера Лиды в другой кабинет, администратору достаточно удалить порт из одного VLAN-а и добавить в другой. Подробнее это рассмотрено в пункте VLAN-ы, теория.
  • VLAN-ы помогают решить одно из требований к безопасности сети, а именно разграничение сетевых ресурсов. Так, студен из одной аудитории не сможет проникнуть на компьютеры другой аудитории или компьютер ректора, т.к. они находятся в фактически разных сетях.
  • Т.к. наша сеть разбита на VLAN-ы, т.е. на маленькие «как бы сети», пропадает проблема с широковещательными сообщениями.

VLAN-ы, теория

Возможно, фраза «администратору достаточно удалить порт из одного VLAN-а и добавить в другой» могла оказаться непонятной, поэтому поясню её подробнее. Порт в данном случае - это не номер, выдаваемый ОС приложению, как было рассказано в пункте Стек протоколов, а гнездо (место) куда можно присоединить (вставить) коннектор формата RJ-45. Такой коннектор (т.е. наконечник к проводу) прикрепляется к обоим концам 8-ми жильного провода, называемого «витая пара». На рисунке изображён коммутатор Cisco Catalyst 2950C-24 на 24 порта:
Как было сказано в пункте ARP: протокол определения адреса каждый компьютер соединён с сетью одним физическим каналом. Т.е. к коммутатору на 24 порта можно присоединить 24 компьютера. Витая пара физически пронизывает все помещения предприятия - все 24 провода от этого коммутатора тянутся в разные кабинеты. Пусть, к примеру, 17 проводов идут и подсоединяются к 17-ти компьютерам в аудитории, 4 провода идут в кабинет спецотдела и оставшиеся 3 провода идут в только что отремонтированный, новый кабинет бухгалтерии. И бухгалтера Лиду, за особые заслуги, перевели в этот самый кабинет.

Как сказано выше, VLAN можно представлять в виде списка принадлежащих сети портов. К примеру, на нашем коммутаторе было три VLAN-а, т.е. три списка, хранящиеся во flash-памяти коммутатора. В одном списке были записаны цифры 1, 2, 3… 17, в другом 18, 19, 20, 21 и в третьем 22, 23 и 24. Лидин компьютер раньше был присоединён к 20-ому порту. И вот она перешла в другой кабинет. Перетащили её старый компьютер в новый кабинет, или она села за новый компьютер - без разницы. Главное, что её компьютер присоединили витой парой, другой конец которой вставлен в порт 23 нашего коммутатора. И для того, что бы она со своего нового места могла по прежнему пересылать файлы своим коллегам, администратор должен удалить из второго списка число 20 и добавить число 23. Замечу, что один порт может принадлежать только одному VLAN-у, но мы нарушим это правило в конце этого пункта.

Замечу так же, что при смене членства порта в VLAN, администратору нет никакой нужды «перетыкать» провода в коммутаторе. Более того, ему даже не надо вставать с места. Потому что компьютер администратора присоединён к 22-ому порту, с помощью чего он может управлять коммутатором удалённо. Конечно, благодаря специальным настройкам, о которых будет рассказано позже, лишь администратор может управлять коммутатором. О том, как настраивать VLAN-ы, читайте в пункте VLAN-ы, практика [в следующей статье].

Как вы, наверное, заметили, изначально (в пункте Построение сетей) я говорил, что компьютеров в нашей сети будет не менее 100. Но к коммутатору можно присоединить лишь 24 компьютера. Конечно, есть коммутаторы с большим количеством портов. Но компьютеров в корпоративной сети/сети предприятия всё равно больше. И для соединения бесконечно большого числа компьютеров в сеть, соединяют между собой коммутаторы по так называемому транк-порту (trunk). При настройки коммутатора, любой из 24-портов можно определить как транк-порт. И транк-портов на коммутаторе может быть любое количество (но разумно делать не более двух). Если один из портов определён как trunk, то коммутатор формирует всю пришедшую на него информацию в особые пакеты, по протоколу ISL или 802.1Q, и отправляет эти пакеты на транк-порт.

Всю пришедшую информацию - имеется в виду, всю информацию, что пришла на него с остальных портов. А протокол 802.1Q вставляется в стек протоколов между Ethernet и тем протоколом, по которому были сформированные данные, что несёт этот кадр.

В данном примере, как вы, наверное, заметили, администратор сидит в одном кабинете вместе с Лидой, т.к. витая пора от портов 22, 23 и 24 ведёт в один и тот же кабинет. 24-ый порт настроен как транк-порт. А сам коммутатор стоит в подсобном помещении, рядом со старым кабинетом бухгалтеров и с аудиторией, в которой 17 компьютеров.

Витая пара, которая идёт от 24-ого порта в кабинет к администратору, подключается к ещё одному коммутатору, который в свою очередь, подключён к роутеру, о котором будет рассказано в следующих главах. Другие коммутаторы, которые соединяют другие 75 компьютеров и стоят в других подсобных помещениях предприятия - все они имеют, как правило, один транк-порт, соединённый витой парой или по оптоволокну с главным коммутатором, что стоит в кабинете с администратором.

Выше было сказано, что иногда разумно делать два транк-порта. Второй транк-порт в таком случае используется для анализа сетевого трафика.

Примерно так выглядело построение сетей больших предприятий во времена коммутатора Cisco Catalyst 1900. Вы, наверное, заметили два больших неудобства таких сетей. Во первых, использование транк-порта вызывает некоторые сложности и создаёт лишнюю работу при конфигурировании оборудования. А во вторых, и в самых главных - предположим, что наши «как бы сети» бухгалтеров, экономистов и диспетчеров хотят иметь одну на троих базу данных. Они хотят, что бы та же бухгалтерша смогла увидеть изменения в базе, которые сделала экономистка или диспетчер пару минут назад. Для этого нам надо сделать сервер, который будет доступен всем трём сетям.

Как говорилось в середине этого пункта, порт может находиться лишь в одном VLAN-е. И это действительно так, однако, лишь для коммутаторов серии Cisco Catalyst 1900 и старше и у некоторых младших моделей, таких как Cisco Catalyst 2950. У остальных коммутаторов, в частности Cisco Catalyst 2900XL это правило можно нарушить. При настройке портов в таких коммутаторах, каждый пор может иметь пять режимов работы: Static Access, Multi-VLAN, Dynamic Access, ISL Trunk и 802.1Q Trunk. Второй режим работы именно то, что нам нужно для выше поставленной задачи - дать доступ к серверу сразу с трёх сетей, т.е. сделать сервер принадлежащим к трём сетям одновременно. Так же это называется пересечением или таггированием VLAN-ов. В таком случае схема подключения может быть такой:

Продолжение следует

Вторая часть этой статьи, где рассматривается практическое применение изложенных здесь основ: Заметки о Cisco Catalyst: настройка VLAN, сброс пароля, перепрошивка операционной системы IOS

Об этой статье

Статья опробована на реальных студентах. Я давал им прочитать часть статьи и оценить на понятность. Затем редактировал и упрощал материал до тех пор, пока он ни стал понятен даже самым отпетым двоечникам.

Службы Windows 7 Simple TCP/IP Services представляют собой набор инструментов, которые могут помочь сетевым администраторам. Полезны они или нет – это отдельный вопрос, но вы в любом случае должны знать о том, что они собой представляют и где их найти. Недавно я просматривал посты на веб форуме, и новый пользователь спрашивал о службах TCP/IP Simple Services. Он говорил о том, что на его машине эти службы были включены, и ему было интересно, что они собой представляют, был ли это вирус, представляют ли они риск для безопасности. Прежде всего, это не вирус. Службы Simple TCP/IP Services существовали в Windows, сколько я себя помню (ну, или, по крайней мере, с Windows NT). Но что это такое? Позвольте мне показать вам, как их устанавливать, что они могут делать и как они могут вам помочь.

Что такое Simple TCP/IP Services?

Simple TCP/IP Services – это набор утилит командной строки. Этот набор включает протоколы "quote of the day", daytime, протокол генератора символов (chargen), протокол echo и discard.

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

Давайте выполним каждый протокол/службу и посмотрим, что каждый из них делает (как говорится в Microsoft TechNet ):

Quote of the Day (QOTD) - основан на RFC 865 - использует порт 17 – возвращает цитаты в виде одной или нескольких текстовых строк в сообщении. Цитаты выбираются случайно из следующего файла: systemroot \System32\Drivers\Etc\Quotes. Примерный файл цитаты устанавливается с Simple TCP/IP Services. Если этот файл отсутствует, данная служба не работает.

Вот что я получил, когда выполнил тест

telnet localhost 17

Daytime - основан на RFC 867 - использует порт 13 – возвращает сообщения, содержащие день недели, месяц, год, текущее время (в формате hh:mm:ss ), а также информацию о часовом поясе. Некоторые программы могут использовать результаты этой службы для отладки и мониторинга изменений времени системных часов или на другом узле.

Результаты команды telnet localhost 13

Рисунок 2

Character Generator (chargen) - основан на RFC 864 - использует порт 19 – отправляет данные, состоящие из 95 печатных ASCII символов. Используется в качестве инструмента отладки для тестирования или диагностики принтеров.

Если вы введете telnet localhost 19 , то получите

Вам нужно будет нажать CTRL-] , затем ввести quit , чтобы прекратить это беспрерывное прокручивание символов (или завершить процесс командой строки).

Echo - основан на RFC 862 - использует порт 7 – возвращает данные эха любого сообщения, которые получает на этот порт сервера. Эхо может быть полезным в качестве инструмента мониторинга и отладки сети.

Ввод telnet localhost 7 выдаст вам

Рисунок 4

На самом деле, эта служба просто возвращает вам эхом все, что вы вводите.

Discard - основан на RFC 863 - использует порт 9 – удаляет все сообщения, принятые на этот порт без ответа и подтверждения. Может использоваться в качестве null порта для получения и пересылки TCP/IP тестовых сообщений во время настройки сети или в некоторых случаях может использоваться программами в качестве функции удаления сообщения.

Попытка подключения к этому порту через протокол Telnet не даст вам НИКАКИХ результатов, поскольку все отправленное на этот порт удаляется.

Как включать или выключать Simple TCP/IP Services?

Чтобы включить или выключить службы simple TCP/IP services, вам нужно перейти в панель управления (Control Panel) , программы (Programs) , а затем включить или выключить функции Windows (Windows Features) . Вам не нужно устанавливать никаких приложений.

Здесь отмечаете флажком Simple TCP/IP Services , как показано на рисунке ниже.

Рисунок 5

Для установки этой службы потребуется всего несколько секунд.

Рисунок 6

После установки вы вернетесь обратно в окно Программы (Programs) . Не будет никаких уведомлений об успешной установке этих служб. После установки simple TCP/IP services вы не сможете включать или отключать отдельные службы. Другими словами – «это все или ничего».

Если вы хотите начать использовать службы прямо сейчас, вам нужно будет перейти в оснастку Службы (Services) в консоли и Запустить службу.

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

Рисунок 7

Как отключать службы? Все очень просто, нужно выполнить действия, противоположенные тем, которые я описал выше. Вам нужно остановить (Stop) службу, затем перейти в список Windows Features и убрать флажок с этой службы. Это отключит службу и деинсталлирует ее.

Чем Simple TCP/IP Services могут быть полезны?

Сегодня службы simple TCP/IP services имеют ограниченную сферу применения. Вот несколько идей по их применению, которые пришли мне в голову:

  1. Обучение - эти службы уходят корнями в Linux / Unix и существуют уже очень давно. Возможно, вы сдаете какой-либо тест, в котором вам нужно знать все о сетевых фикциях. Возможно, вам просто интересно и вы хотите получить опыт работы со всеми возможными сетевыми функциями и протоколами TCP/IP. В любом случае, для работы с simple TCP/IP services требуется совсем немного времени.
  2. Тестирование - возможно, вам нужно включить эти функции на машине, которая находится на брандмауэре, а затем протестировать открывание портов на этой машине.

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