Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Максим Кулъгин
для ПРОФЕССИОНАЛОВ
КОМПЬЮТЕРНЫЕ
СЕТИ
Практика построения
♦ 2-Е ИЗДАНИЕ *
СОЛИТЕР
Москва ■ Санкт-Петербург ■ Нижний Новгород ■ ВоронежРостов-на-Дону ■ Екатеринбург ■ СамараКиев ■ Харьков ■ Минск
2003
5БК 32.988.02
/ДК 681.324
С 90
К 90 Компьютерные сети. Практика построения. Для профессионалов. 2-е изд. / М. В. Кульгин. — СПб.: Питер, 2003. — 462 с.: ил.
ISBN 5-94723-563-3
При создании и обслуживании любой сети возникает масса больших и малых проблем, о решении которых ничего не говорится в теоретических фолиантах. Оказывается, многие из них можно решить, применяя совокупность нескольких технологий или внедряя некоторые технологии там, где они в соответствии со своей целевой функцией не могут быть использованы. В книге основной упор сделан именно на практическую сторону построения и обслуживания сетей, рассмотрены те устройства и технологии, которые на сегодняшний день являются базовыми и основополагающими: маршрутизаторы компании Cisco Systems и их настройка, технология организации очередей, трансляции адресов, построения защитного экрана, настройка протоколов маршрутизации, построение защищенных виртуальных сетей и т. п. Книга рассчитана не только на начинающих администраторов, которые хотят разобраться в основных принципах работы с сетевыми программными и аппаратными комплексами, — опытные специалисты также найдут здесь немало ценной информации.
ББК 32.968.02
УДК 681.324
Информация, содержащаяся в данной книге, получена из источников, рассметриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
ISBN 5-94723-563-3ISBN 5-94723-563-3© ЗАО Издательский дом «Питер», 2003
ISBN 5-94723-563-3
ISBN 5-94723-563-3
Краткое содержание
От автора9
Введение10
Глава 1. Начальная настройка маршрутизатора Cisco Systems14
Глава 2. Настройка протокола IP 72
Глава 3. Дальнейшая настройка маршрутизатора126
Глава 4. Протокол ICMP 139
Глава 5. Настройка протокола TCP189
Глава б. Трансляция адресов и настройка очередей 238
Глава 7. Настройка протоколов маршрутизации 273
Глава 8. Технология Frame Relay в построении распределенной сети . . 320
Глава 9. Настройка базовой безопасности 344
Глава 10. Построение виртуальных частных сетей374
Приложение А. Протоколы442
Алфавитный указатель447
Содержание
От автора9
Введение10
Организация книги11
От издательства13
Глава 1. Начальная настройка маршрутизатора Cisco Systems ... 14
Общие сведения14
Аппаратная архитектура маршрутизаторов Cisco Systems17
Введение в Cisco IOS21
Начальная настройка маршрутизатора22
Пошаговая настройка маршрутизатора25
Интерфейс командной строки Cisco IOS27
Команды Cisco IOS34
Работа с аппаратными интерфейсами маршрутизатора40
Терминальные порты50
Проверка аппаратных ресурсов маршрутизатора 52
Таблицы, буферы и журналы маршрутизатора53
Синхронизация по времени58
Файлы конфигурации маршрутизатора59
Имена и заголовки66
Обеспечение безопасности доступа к маршрутизатору68
Глава 2. Настройка протокола IP72
Протокол IP72
Классы адресов и их маски76
Подсети82
Маска подсети83
Практика выделения IP-подсетей93
Маска подсети переменной длины96
Применение маски подсети переменной длины100
Технология CIDR108
Пример использования технологии CIDR114
Настройка протокола IP на маршрутизаторе Cisco Systems116
Протокол ARP119
Возможность использования протокола ARP для сетевых атак123
Глава 3. Дальнейшая настройка маршрутизатора126
Разрешение адресов маршрутизатором126
Работа с интерфейсами и портами маршрутизатора128
Работа с маршрутизатором через сеанс Telnet133
Протокол СОР135
Работа со встроенным отладчиком137
Глава 4. Протокол ICMP139
Введение139
Перехват информации в сетях141
Сообщения протокола ICMP147
Сообщение ICMP echo request151
Сообщение ICMP source quench (подавление источника)160
Сообщение ICMP destination unreachable164
Сообщение ICMP redirect171
Информационные запросы протокола ICMP176
Сообщение ICMP parameter problem180
Сообщение ICMP time exceeded,181
Фрагментация дейтаграмм IP 183
Глава 5. Настройка протокола TCP189
Введение в протокол TCP189
Атака TCP SYN flooding194
Блок управления передачей протокола TCP 204
Скользящее окно205
Узкие места в сети208
Пропускная способность TCP210
Изменение размера окна на маршрутизаторе214
Управление потоком214
Стратегии отправления и приема данных217
Выборочное подтверждение SACK219
Задержанное подтверждение221
Таймер повторной передачи221
Временные отметки224
Быстрая повторная передача 226
Контроль над перегрузками228
Медленный старт229
Механизм TCP Path MTU234
Глава 6. Трансляция адресов и настройка очередей238
Трансляция адресов238
Настройка очередей на маршрутизаторе246
Очередь типа FIFO246
Качество обслуживания в IP-сетях249
Очередь RED'252
Настройка очередей RED и WRED .■255
Очереди с приоритетами 256
Настройка очередей с приоритетами для маршрутизаторов Cisco258
Настраиваемые очереди261
Очереди на основе классов267
Настройка взвешенной справедливой очереди WFQ267
Рекомендации по выбору стратегии очередей271
Глава 7. Настройка протоколов маршрутизации273
Алгоритмы маршрутизации273
Протокол маршрутизации RIP276
Счет до бесконечности289
Расщепление горизонта290
Мгновенное обновление291
Пример подключения объектов к сети Интернет306
Глава 8. Технология Frame Relay в построении распределенной сети320
Общие сведения о технологии Frame Relay320
Настройка Frame Relay на маршрутизаторах Cisco Systems326
Управление трафиком в сети Frame Relay333
Глава 9. Настройка базовой безопасности344
Списки управления доступом Cisco IOS344
Защита от атак address spoofing358
Безопасность удаленного доступа365
Практическая настройка технологии Cisco AAA369
Глава 10. Построение виртуальных частных сетей374
Введение374
Оборудование удаленных объектов380
Технологии виртуальных частных сетей382
Практика подключения объекта384
Основные принципы работы протокола РРТР389
Методы шифрования информации401
Примеры настройки защитного экрана408
Анализ трафика РРТР на сетевом уровне414
Процедура настройки туннеля427
Приложение А. Протоколы442
Алфавитный указатель447
От автора
О чем эта книга? Прежде всего, это попытка поделиться практическим опытом настройки компонентов компьютерной сети. В книге рассмотрены только те устройства и технологии, которые являются базовыми и основополагающими: маршрутизаторы компании Cisco Systems и их настройка, технология организации очередей, трансляции адресов, построения защитного экрана, настройка протоколов маршрутизации, построение защищенных виртуальных сетей и т. п. Я сознательно старался избежать обширных теоретических рассуждений, переходя сразу к практической работе с этими технологиями. Читатель держит в руках второе издание книги, отличающееся двумя новыми главами, которые, уверен, будут так же интересны, как и остальной материал.
С уважением
Максим Кулъгин. mk@alternativa.spb.ru
Введение
У меня, как и у многих специалистов в области сетевых компьютерных технологий, сложилось вполне определенное мнение о представленной сегодня на книжном рынке литературе по этой тематике. Очень много изданий по программному обеспечению. Гораздо меньше книг по аппаратному сетевому обеспечению. И очень редко появляются книги, в которых даются какие-либо практические рекомендации по внедрению и эксплуатации программного и аппаратного комплексов. Учитывая дефицитность подобной литературы, мне захотелось поделиться со своими коллегами по «компьютерному цеху» теми практическими знаниями, которые я приобрел в процессе создания распределенной компьютерной сети коммерческой фирмы, в которой работаю. Почему я посчитал необходимым представить материал этой книги на широкое обсуждение? Считаю, что он будет интересен и полезен в практической деятельности всех специалистов, работающих с распределенными сетями. Свое утверждение строю па том факте, что подавляющее большинство компьютерных сетей активно работающих коммерческих фирм имеют практически одинаковую конфигурацию и на них возложены схожие задачи. И что очень важно, начиная работу по созданию корпоративной сети или модернизируя старую структуру, хочется или нс хочется, специалисту придется пройти примерно тот же путь, что уже одолел я. А зачем «наступать» на те же «грабли», если можно этого избежать?! Тем, у кого сеть уже работает, также не будет лишним попробовать у себя те технологии, которые работают в сети моей компании.
При создании любой сети возникает масса больших и малых проблем, о способах решениях которых ничего не говорится в теоретических фолиантах. Ведь многие проблемы удается решить, применяя совокупность нескольких технологий или даже внедряя некоторые технологии туда, где они в соответствии со своей целевой функцией не могут быть применены. Описание способов решения некоторых проблем можно найти в этой книге. При этом упор сделан па решение технических вопросов, которые возникали при построении и ежедневном обслуживании сети. Особое внимание уделено вопросам организации связи. За несколько лет практической работы набралось много таких решений, что и позволило создать эту книгу.
Я не ставил своей целью описать как можно больше технологий. Думаю, что все сетевые специалисты согласятся с малой ценностью книг, в которых пусть и коротко, но описано все, что хоть в малой степени можно причислить к сетевым технологиям. В нашей стране уже встал на ноги и заявил о себе большой отряд сетевых специалистов: менеджеров IT, сетевых администраторов и анали-
тиков. И для них такого рода пособия — уже давно пройденный этап. А при подготовке новых специалистов эти книги приносят больше вреда, чем пользы, Молодой специалист, начитавшись такой литературы, думает, что он уже изучил все тонкости своей профессии, и готов на практике воплотить в жизнь приобретенные знания. И очень сильным бывает разочарование, когда он сталкивается с реальными проблемами, разрешение которых требует от него глубоких знаний. Кроме того, можно с уверенностью говорить о том, что в нашей стране еще не сформировалась школа подготовки специалистов в этой области. По этой причине считаю, что издание данной книги (а точнее, ее второй редакции с двумя новыми главами) своевременно и должно принести большую пользу как начинающим, так и зрелым специалистам.
Организация книги
Книга содержит десять глав. Первая и третья главы посвящены вопросам настройки маршрутизаторов. Для наглядности рассматриваются устройства одного производителя — компании Cisco Systems. Выбор именно этой компании связан с тем, что ее маршрутизаторы занимают лидирующее положение на мировом рынке. Необходимость включения этого материала в книгу продиктована тем, что, к сожалению, русскоязычную литературу по маршрутизаторам найти достаточно сложно. Материал первых глав поможет специалисту в начальный период работы с маршрутизатором. Возможно, читатель заметит некоторую странность в изложении материала, а именно искусственный разрыв в описании процесса настройки и включение в этот разрыв второй главы, посвященной настройке протокола IP. Это сделано не случайно и связано с использованием в описании дальнейшей настройки маршрутизаторов некоторых параметров протокола IP. Во второй главе кроме практики настройки адресного пространства организации дано изложение практических методов настройки протоколов IP и ARP на маршрутизаторе. Представлено описание атаки на протокол ARP и методов защиты от нее.
Глава 4 полностью посвящена рассмотрению работы протокола ICMP. Несмотря на то что протокол скорее относится к разряду вспомогательных, с его помощью можно получить много интересной информации о сети. Причем зачастую именно этот протокол используется для сбора информации людьми, которые в дальнейшем могут попытаться осуществить проникновение в сеть. Я постарался сделать материал более понятным, приведя в качестве примеров сетевые перехваты наиболее интересных пакетов. Если администратор запустит в своей сети анализатор трафика, настроенный на перехват пакетов этого протокола, он, скорее всего, будет удивлен их количеством (даже не говоря о таких известных командах, как ping или tracert). Например, серверы Microsoft Exchange 2000 используют это протокол для проверки работоспособности контроллеров домена Active Directory. ■
В пятой главе дано расширенное описание протокола TCP. Некорректная работа почтовой системы Microsoft Exchange в распределенной сети с «облаком»
Frame Relay стала первопричиной для автора обратить самое пристальное внимание на работу этого протокола в сетях Microsoft. Последующий детальный анализ сбоев показал, что все дело вовсе не в почтовой системе, а в громоздком механизме передачи информации. В частности, большинство попыток скопировать Проводником большой объем информации (несколько сотен мегабайтов) с удаленного сервера по сети Frame Relay (CIR = 32 Кбит/с) заканчивались ошибками при передаче. Эти ошибки возникали из-за слишком больших накладных расходов на служебную информацию. Убежденность автора в необходимости подробного рассмотрения протокола TCP усилил факт существования атаки TCP SYN flooding.
Шестая глава содержит описание технологий трансляции адресов (NAT) и настройки адресов на маршрутизаторах, а также обозрение различных технологий организации очередей и практики их применения на маршрутизаторах.
Седьмая глава посвящена вопросам маршрутизации в IP-сетях. Здесь очень подробно рассмотрен протокол RIP (Routing Information Protocol). Освещена практика его конфигурирования на маршрутизаторах. Выбор этого протокола связан с его большой популярностью среди отечественных сетевых специалистов.
Восьмая глава содержит сведения о технологии Frame Relay, спрос на которую в настоящее время все более возрастает. Технология Frame Relay позволяет экономить до 50% средств по сравнению с затратами на аренду выделенных каналов связи. При правильной настройке качество соединения практически не отличается от качества связи по выделенным каналам. По этой причине технология Frame Relay все чаще используется для коммуникации между удаленными объектами, построения корпоративных сетей, доступа в Интернет. В данной главе описаны практические методы настройки этой технологии на граничных маршрутизаторах.
Девятая глава посвящена вопросам базовой безопасности сети. В ней рассмотрены несколько технологий. Большое внимание уделено практическим вопросам создания списков доступа Cisco ACL, которые являются ключевой возможностью операционной системы Cisco IOS. Основное предназначение списков доступа заключается в создании фильтра безопасности, направленного на блокирование трафика, входящего в сеть или покидающего сегмент сети. Однако по мере развития операционной системы IOS компания Cisco Systems расширила синтаксис команд формирования списков доступа для решения и других задач.
Любая крупная сеть предоставляет пользователям возможность задействовать удаленный доступ, в связи с чем очень важно создать систему безопасности удаленного доступа. Этому вопросу в девятой главе также уделено внимание.
Десятая, последняя глава в книге, рассматривает тонкости построения защищенных виртуальных частных сетей (VPN) на основе протокола РРТР и решений компании Microsoft. Данная глава, как и четвертая, появились во втором издании книги, которую читатель сейчас держит в руках. Сегодня наблюдается все больший интерес к построению подобных сетей, так как у многих организаций появляются филиалы, подключение которых традиционными способами представляется либо невозможным, либо непрактичным с точки зрения затрат. В такой ситуации администратор может воспользоваться уже проверенными решениями, позволяющими создать защищенный «туннель» к удаленному филиалу,
проходящий через сеть Интернет. Материал этой главы акцентирован на практическом применении протокола РРТР, поддержка которого входит в операционные системы компании Microsoft. Читатель, помимо помощи по настройке туннеля, найдет также детальный анализ процессов, происходящих на сетевом уровне, что несомненно поможет сделать рассматриваемую технологию более прозрачной для понимания.
В дополнение книга включает в себя приложение, в котором приведены номера портов наиболее популярных программ. Эта информация будет полезной при настройке граничных или внутренних маршрутизаторов (защитных экранов) на блокирование трафика отдельных протоколов.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на web-сайте издательства http://www.piter.com.
1
Начальная настройка маршрутизатора Cisco Systems
Общие сведения
Очень часто в компьютерной литературе можно встретить следующее определение маршрутизатора (английское название — router): «маршрутизатор — это устройство сетевого уровня эталонной модели OSI, использующее одну или более метрик для определения оптимального пути передачи сетевого трафика на основании информации сетевого уровня». Из этого следует, что маршрутизатор прежде всего необходим для выбора дальнейшего пути данных, которые отсылаются в распределенную сеть.
Пользователи для отправки своих данных в сеть указывают лишь адрес абонента. Эти данные уходят в сеть и в точках с разветвлением маршрутов поступают на маршрутизаторы, которые как раз и служат для выбора дальнейшего пути. При этом маршрутизатор выбирает оптимальный путь. Оптимальность пути определяется количественными характеристиками, которые называются метриками. Лучший путь — это путь с метрикой, которая в данном конкретном случае является наиболее подходящей. В метрике могут учитываться несколько показателей, например длина пути, время прохождения и т. д.
Рисунок 1.1 показывает обобщенную схему использования маршрутизатора в сети (рисунок позаимствован с сайта компании Cisco Systems, как и некоторые другие рисунке в этой книге). Здесь видно, что для связи маршрутизатора с Интернетом применяется специальное устройство — модем, который с одной стороны подключается к маршрутизатору, а с другой — к выбранной среде передачи информации (это может быть обычный асинхронный модем, подключаемый к городской телефонной сети).
По критерию производительности маршрутизаторы делят на устройства высшего, среднего и низшего классов. Высокопроизводительные маршрутизаторы являются устройствами высшего класса и служат для объединения сетей предприятия. Они поддерживают множество протоколов и интерфейсов, причем не только стандартных. Устройства такого класса могут иметь до 50 портов локальных или глобальных сетей. ..-.■■,.»
ПКМаршрутизаторCisco 805ПКМаршрутизаторCisco 805Рис. 1.1. Общая схема подключения маршрутизатора к сетиРис. 1.1. Общая схема подключения маршрутизатора к сети
ПКМаршрутизатор
Cisco 805
ПКМаршрутизатор
Cisco 805
Рис. 1.1. Общая схема подключения маршрутизатора к сети
Рис. 1.1. Общая схема подключения маршрутизатора к сети
С помощью маршрутизаторов среднего, промежуточного, класса формируются менее крупные сетевые объединения масштаба предприятия. Стандартная конфигурация включает два-три порта локальных сетей и от четырех до восьми портов глобальной сети. Такие маршрутизаторы поддерживают наиболее распространенные протоколы маршрутизации и транспортные протоколы.
На рис. 1.2 показан общий вариант подключения маршрутизатора к глобальной сети через модем.
В рассматриваемом примере модем подключается к маршрутизатору Cisco 805 при помощи специального кабеля, который следует заказывать отдельно. И хотя на рисунке модем подключен непосредственно к маршрутизатору, часто вместе с модемом производитель поставляет свой кабель, оканчивающийся разъемом интерфейса V.35. В таком случае администратору сети при оформлении заказа на маршрутизатор потребуется заказать кабель с аналогичным разъемом (тут потребуется уточнить тип разъема — male/female, или «папа»/«мама»).
Кроме того, при подключении модема к маршрутизатору следует помнить о максимально возможной длине кабеля, которая зависит от скорости передачи информации и используемого типа п.одключения. Так, при работе на скорости 2 Мбит/с рекомендуемая длина кабеля не должна превышать 15 метров (при использовании интерфейса V.35).
ПРИМЕЧАНИЕ
Интерфейс V.35 предназначен для последовательной передачи данных в синхронном режиме. Этот режим основывается на постоянной активности канала связи: даже если нет данных для передачи, канал заполнен сигналами синхронизации. Синхронный режим более адаптирован к работе с протоколами верхних уровней. Этому способствует структурированность кадра с данными (начало и конец каждого кадра отмечены синхросимволами). Первоначально интерфейс V.35 был ориентирован на соединение оконечного оборудования (Data Terminal Equipment — DTE) и коммуникационной аппаратуры (Data Communications Equipment — DCE) при скорости до 100 Кбит/с. При этом теоретическая дальность связи составляла 1200 метров. Однако интерфейс способен работать и на более высоких скоростях — до 45 Мбит/с. Рекомендуемый режим — 64 Кбит/с на дальности 600 метров.
Интерфейс основывается на дифференциальном приеме и передаче данных и сигналов синхронизации и несимметричной передаче управляющих сигналов. Физически интерфейс V.35 реализован на 34-контактном разъеме с фиксаторами двух типов. Встречается реализация на 25-контактном разъеме.
Маршрутизаторы низшего класса предназначены для локальных сетей подразделений; они связывают небольшие офисы с сетью предприятия. Типичная конфигурация: один порт локальной сети (обычно Ethernet) и один или два порта глобальной сети, рассчитанных на низкоскоростные выделенные или коммутируемые соединения. Тем не менее подобные маршрутизаторы пользуются большим спросом у администраторов, которым необходимо расширить имеющиеся межсетевые объединения.
Маршрутизаторы для базовых сетей и удаленных офисов имеют разную архитектуру, поскольку к ним предъявляются разные функциональные требования. Маршрутизаторы базовых сетей обязательно должны быть расширяемыми. Маршрутизаторы локальных сетей подразделения, для которых, как правило, заранее устанавливается фиксированная конфигурация портов, содержат только один процессор, управляющий работой трех или четырех интерфейсов.
По определению, основное назначение маршрутизаторов — это выбор оптимального пути следования трафика сети. Процесс маршрутизации можно разделить на два иерархически связанных уровня.
Уровень маршрутизации. На этом уровне происходит работа с таблицей маршрутизации. Таблица маршрутизации служит для определения адреса сетевого уровня следующего маршрутизатора или непосредственно получателя. После определения адреса выбирается интерфейс маршрутизатора, через который будут передаваться пакеты. Этот процесс называется определением маршрута. Управление таблицей маршрутизации выполняется протоколами маршрутизации.
Уровень передачи пакетов. Перед тем как передать пакет, необходимо: проверить контрольную сумму заголовка пакета, определить адрес (канального уровня) получателя пакета и произвести непосредственно отправку пакета с учетом очередности, фрагментации, фильтрации и т. д. Эти действия выполняются на основании команд, поступающих с уровня маршрутизации.
По мнению автора, основные принципы работы маршрутизаторов различных производителей практически совпадают друг с другом. По этой причине автор выбрал для иллюстрации материала маршрутизаторы одного производителя. Знание основополагающих принципов работы этих устройств позволяет управ-
лять фактически любым маршрутизатором. В книге рассматривается оборудование компании Cisco Systems и по возможности приводятся примеры работы с другим оборудованием.
ПРИМЕЧАНИЕ Продукция Cisco (часто название фирмы на русском языке произносят как «циско» или «киско») распространяется в 90 странах мира. Приобрести ее можно через дистрибьюторов фирмы, реселлеров с добавленной стоимостью и системных интеграторов Cisco. Центральная штаб-квартира компании расположена в Сан-Хосе, штат Калифорния.
Также крупные отделения Cisco Systems находятся в Research Triangle Park, штат Северная Каролина, и Челмсфорде, штат Массачусетс. Кроме того, Cisco принадлежит более 200 отделений по продажам и поддержке в 54 странах. Компания имеет Европейскую и Азиатскую штаб-квартиры, а также штаб-квартиру в Северной и Южной Америке. За счет деловых союзов, заключаемых Cisco Systems с фирмами-партнерами, и приобретения новых компаний наблюдается активная экспансия фирмы на мировом рынке. Из 15 сегментов сетевого компьютерного рынка, на которых выступает компания, Cisco лидирует в 12.
Общая численность сотрудников компании составляет около 12 100 человек. Примерно 7000 из них работают в Бэй-Ариа (Сан-Франциско). Российское представительство компании Cisco Systems насчитывает на настоящий момент более 30 сотрудников. (Источник: http://www.cisco.com/global/ RU/win/about/general/corporate_structure.shtml.)
Маршрутизаторы компании Cisco Systems занимают лидирующее положение па рынке (компания поставляет более 80% маршрутизаторов, являющихся основой Интернета), однако, к сожалению, литературу по ним найти достаточно сложно. По указанной причине администраторам сети, впервые сталкивающимся с необходимостью настроить маршрутизатор, приходится либо пользоваться англоязычными источниками, либо прибегать к сторонней помощи. Материал, изложенный в этой главе, поможет специалисту в начальный период работы с маршрутизатором.
Аппаратная архитектура маршрутизаторов Cisco Systems '
Маршрутизатор можно рассматривать как специализированный компьютер, который предназначен для выполнения вполне определенных задач. И как всякий компьютер, маршрутизатор имеет собственный центральный процессор (Central Processing Unit — CPU), тип которого может различаться в зависимости от класса маршрутизатора, фирмы-изготовителя, серии маршрутизатора внутри класса (например, это может быть Motorola 68030 или Orion/R46QO). Основная задача процессора маршрутизатора (наряду со многими второстепенными) заключается в обработке входящих пакетов для принятия решений об их дальнейшем перенаправлении. При этом скорость, с которой маршрутизатор способен обрабатывать поступающие пакеты, напрямую зависит от типа используемого процессора.
Другой важной частью маршрутизатора, помимо процессора, является его память, которая поделена по функциональному принципу. Маршрутизаторы компании Cisco Systems поддерживают четыре основных типа памяти: постоянное
запоминающее устройство (Read-Only Memory — ROM), флэш-память (flash memory), память с произвольным доступом (Random-Access Memory — RAM) и энергонезависимую память (Non-Volatile RAM — NVRAM). Из перечисленных типов памяти только RAM является энергозависимой, то есть ее содержимое стирается после выключения питания маршрутизатора. Поэтому память RAM может использоваться только для хранения временных данных при работе маршрутизатора.
Память ROM применяется для хранения загрузочного программного обеспечения (bootstrap software), которое запускается первым в момент включения маршрутизатора и в дальнейшем отвечает за его загрузку. Некоторые типы маршрутизаторов хранят всю операционную систему Cisco ids (Internetwork Operating System) в этой памяти'на случай возникновения сбойных ситуаций, когда другие источники, хранящие образ операционной системы, могут стать недоступными.
Основное назначение флэш-памяти заключается в хранении образа (image) операционной системы (собственно операционной системы Cisco IOS), которая и обеспечивает работу маршрутизатора (в том случае, если маршрутизатор имеет такую память). Администратор может хранить в этой памяти образы нескольких операционных систем, чтобы иметь возможность выбрать тип операционной 1 системы при загрузке маршрутизатора. Рассматриваемый тип памяти реализу- >ется либо на процессорной плате маршрутизатора, либо на карте PCMCIA.
* Основное назначение памяти М^Д^^даанение.г^фигурации маршрутизатора, которая считывается при его загрузке.
Кроме памяти и процессора все маршрутизаторы имеют интерфейсы (interfaces, часто в технической литературе встречается термин «порт маршрутизатора»), которые обязательно поименованы и пронумерованы. При этом полное имя интерфейса маршрутизатора содержит его тип (например, Serial) и номер, отсчитываемый. с нуля. На тех маршрутизаторах, которые имеют предварительно ^ютаповлснное фиксированное количество интерфейсов (например, на модели Cisco 805), нумерация интерфейсов осуществляется в соответствии с их физическим расположением (порядком следования) на корпусе маршрутизатора. Так, например, ссылка на интерфейс EthernetO подразумевает ссылку на первый интерфейс локальной сети. На маршрутизаторах, которые позволяют выполнять смену интерфейсов во время его работы (Online Insertion and Removal — OIR), полное имя интерфейса содержит по крайне мере два числа, разделенных символом /, где первое число определяет номер слота, в который устанавливается интерфейсный модуль, а второе является номером порта. Например, имя интерфейса Ethernet5/0 указывает на первый интерфейс Ethernet в пятом слоте маршрутизатора. Напомним, что отсчет интерфейсов начинается с нуля.
Помимо интерфейсов локальных (Ethernet, Token Ring и т. и.) и глобальных (Serial, ISDN) сетей, все маршрутизаторы компании Cisco Systems имеют кор- сольный порт, предоставляющий асинхронное соединение EIA/TIA-232. Такой порт позволяет с помощью подключения через консольный каоель управлять маршрутизатором с компьютера. Для удобства подключения на стороне маршрутизатора порт оборудован разъемом ^145. Подобный способ подключения очень удобен в том случае, если возможен физический доступ к маршрутизатору,
а также если необходимо провести начальную настройку нового маршрутизатора или маршрутизатора, у которого все предыдущие настройки были сброшены. В комплекте с новыми маршрутизаторами компания Cisco Systems поставляет консольный кабель. Кабель имеет достаточную длину, для того чтобы при подсоединении к компьютеру можно было удобно расположить маршрутизатор, скажем, на соседнем столе. Точнее, поставляется даже не сам кабель, а так называемый serial cable console kit — набор, состоящий из кабеля и соединителей (connector) разного типа. Такой набор позволяет подключаться к консольному порту любого маршрутизатора, произведенного компанией Cisco Systems, и другому оборудованию (например, к коммутаторам). В том случае, если кабеля в комплекте нет (например, когда был куплен бывший в употреблении маршрутизатор без фирменной упаковки), то набор можно просто заказать. На рис. 1.3 представлены составляющие кабельного набора.
ДокументацияДокументацияСиловой кабельСиловой кабельРазъем DB9-RJ45Разъем DB9-RJ45Консольный кабельКонсольный кабельРис. 1.3. Набор кабелей и разъемов, поставляемый с маршрутизаторомРис. 1.3. Набор кабелей и разъемов, поставляемый с маршрутизаторомРазъем DB25-RJ45Разъем DB25-RJ45
Документация
Документация
Силовой кабель
Силовой кабель
Разъем DB9-RJ45
Разъем DB9-RJ45
Консольный кабель
Консольный кабель
Рис. 1.3. Набор кабелей и разъемов, поставляемый с маршрутизатором
Рис. 1.3. Набор кабелей и разъемов, поставляемый с маршрутизатором
Разъем DB25-RJ45
Разъем DB25-RJ45
Кроме консольного порта, большинство моделей имеют порт AUX (auxiliary port —• вспомогательный порт), который, так же как и консольный, является асин-
хронным соединением EIA/TIA-232 и используется для управления маршрутизатором через обычный модем. Удобство такого управления заключается в том, что в случае возникновения проблем с каналами связи на удаленных объектах всегда существует возможность получения доступа к маршрутизатору для выполнения тех или иных настроек. В качестве другого примера можно привести ситуацию, когда-администратор при управлении удаленным маршрутизатором произвел некорректные настройки, результатом которых оказалось то, что связь на сетевом уровне стала недоступной. В этом случае наличие модема, подключенного к порту AUX, поможет исправить последствия допущенных ошибок. Более подробную информацию о портах AUX можно получить в Интернете по адресу http://www.cisco.eom/warp/public/701/6.html. Заметим, что новые маршрутизаторы поставляются с инструкцией (на английском языке), в которой расписаны пошаговые действия для подключения модема к AUX-порту.
На рис. 1.4 показана задняя панель маршрутизатора Cisco 805.. На этой панели расположены (слева направо) следующие пррты: Ethernet, консольный порт и порт Serial. Отметим, что данная модель маршрутизатора не имеет порта AUX.
Рис. 1.4. Задняя панель маршрутизатора Cisco 805
Важной составной частью маршрутизатора, помимо его аппаратных компонентов, являются конфигурационные файлы (configuration files). Конфигурационные файлы будут рассмотрены ниже более детально, а пока ограничимся их кратким перечислением. Существует два типа конфигурации операционной системы Cisco IOS: рабочая (running configuration) и загрузочная (startup configuration). Часто конфигурацию первого типа также называют активной (active), так как она располагается в оперативной памяти маршрутизатора (RAM) и определяет его текущие настройки. Когда администратор выполняет команды конфигурирования, на маршрутизаторе изменяется содержимое именно этой конфигурации. В противоположность рабочей (активной), загрузочная конфигурация размещается в памяти NVRAM маршрутизатора и содержит команды операционной системы Cisco IOS, которые выполняются в момент его загрузки.
Рабочая и загрузочная конфигурации в какой-то степени самостоятельны. Обычно администратор сети, выполнив начальные этапы настройки маршрутизатора и проверив его работоспособность, копирует рабочую конфигурацию в намять NVRAM, формируя таким образом загрузочную конфигурацию. Очевидно, что основной причиной такой последовательности действий является необходимость сохранения сделанных изменений при перезагрузке маршрутизатора.
ИЗ ОПЫТА
Необходимо отметить одну тонкость, связанную с наличием двух типов конфигурации. При повседневной эксплуатации своей сети автор нередко сталкивался с необходимостью выполнить некоторые сетевые настройки удаленных маршрутизаторов. Бывали случаи, когда последние становились недоступными для управления. А так как далеко не всегда есть возможность самому приехать на удаленный объект, то наиболее действенным способом исправления ситуации является простой звонок по телефону с просьбой к сотруднику этого объекта выключить, а затем снова включить питание маршрутизатора. Учитывая, что все настройки выполняются в рабочей (активной) конфигурации маршрутизатора, а загрузочная при этом не затрагивается (если при этом не копировать принудительно рабочую конфигурацию в загрузочную с помощью команд Cisco IOS), то при повторной загрузке маршрутизатор будет использовать именно загрузочную конфигурацию, в которую некорректные команды не попали.
Введение в Cisco IOS
Компания Cisco Systems, создавшая эту операционную систему, активно работает на рынке сетевого оборудования уже в течение многих лет. Говоря об успехах компании, достаточно сказать, что по имеющимся данным большая часть маршрутизаторов, работающих в Интернете, произведены в компании Cisco, и, по признанию самой компании, своими успехами во многом она обязана именно операционной системе для сетевых устройств IOS. В глоссарии журнала для пользователей Cisco Packet дано следующее определение операционной системы IOS (перевод с английского языка): «Программное обеспечение, работающее в продуктах компании Cisco и представляющее их для пользователей и сетевых администраторов единым целым». IOS предназначена для управления активным сетевым оборудованием и является очень мощной операционной системой. При этом опа обеспечивает управление не только через интерфейс командной строки, ио н через браузеры Веб.
Достаточно интересно позиционирование компанией Cisco Systems своей операционной системы IOS. На веб-сервере Cisco Systems операционной системе IOS отводится специальный раздел. О распространении IOS в этом разделе говорится как о распространении самостоятельного продукта. При этом своей главной задачей компания видит установление операционной системы IOS в качестве стандарта для других производителей сетевого оборудования. И это несмотря на то, что практическое освоение операционной системы IOS, включающей не одну сотню команд и настроек, дело достаточно трудоемкое. Говорит о сложности этой операционной системы и тот факт, что IOS объединяет все линии продуктов компании, и их совместимость достигается именно благодаря согласованной работе используемых протоколов и технологий.
Большое внимание в системе IOS уделено группе технологий, направленных на защиту данных в $етя$. При практической настройке маршрутизаторов часто возникает впечатление, что сам процесс маршрутизации является хоть и необходимым, но далеко не единственным процессом в работе маршрутизатора. Достаточно взглянуть на перечень команд, чтобы понять, насколько трудоемкой может быть настройка механизмов защиты. Для того чтобы настроитй'от1^^Жта^ тизации, требуется йе так уж много команд по сравнению с тем случаем, когда
администратор сети начинает ограничивать доступ с помощью списков (access lists), настраивать технологию трансляции адресов (Network Address Translation — NAT), обеспечивать аутентификацию удаленных пользователей по протоколам RADIUS/TACACS+ и т. д. В книге будут рассмотрены основные моменты практической настройки безопасности, но при первом знакомстве с маршрутизаторами Cisco Systems наиболее важным является понимание базовых команд, без которых невозможна дальнейшая работа.
Начальная настройка маршрутизатора
Для выполнения начальной настройки маршрутизатора абсолютно необходимо предварительно получить полную функциональную схему распределенной сети. Более того, если сеть охватывает больше двух объектов, то без детальной прорисовки сети на бумаге или при помощи специализированных программ настрой- ^ ка маршрутизаторов может оказаться очень обременительным делом. При этом * важно не только нарисовать функциональную схему сети, но и разработать адресную схему.
- Компания Cisco Systems предлагает очень удобную и функционально богатую программу CpnfigMaker, позволяющую графически изобразить планируемую сеть, а затем записать автоматически сгенерированные настройки в память маршрутизаторов. Эта программа доступна без ограничений через Интернет с корпоративного сайта компании Cisco Systems. Если необходимость в использовании программы ConfigMaker отсутствует, то администратор может выполнить пошаговую настройку маршрутизатора средствами операционной системы Cisco IOS.
Для того чтобы приводимое описание команд нс было бы чисто теоретическим, автор воспользовался примерами информационных сообщений, полученных с «живых» маршрутизаторов, которые установлены в уже работающей сети одной из петербургских компаний. Сеть сравнительно большая — она связывает . более десяти удаленных объектов по выделенным каналам связи и по сети Frame Relay, имеет выход в Интернет и оборудована сервером доступа для обслуживания удаленных пользователей. В сети в качестве аппаратного обеспечения развернуто оборудование компании Cisco Systems — в основном это маршрутизаторы для средних и малых офисов (Cisco 805, Cisco 1005, Cisco 1601 и т. п.). Можно смело сказать, что перечисленные модели маршрутизаторов являются наиболее распространенными, так как наряду с невысокой стоимостью они предлагают широчайший спектр возможностей, часть из которых остается даже невостребованной в повседневной работе. Далее по тексту книги будут демонстрируются фрагменты сети, которые позволят понять работу рассматриваемых технологий. К сожалению, привести всю схему сети не представляется возможным по нескольким причинам, среди которых самой весомой является тот факт, что по мере работы над книгой сеть меняла свои «очертания» — внедрялись новые технологии, менялся подход к обеспечению связи некоторых объектов и т. д.
Первым шагом настройки маршрутизатора является выбор его имени, которое должно быть уникальным.
СОВЕТ—
По мнению автора, наиболее удобным является указание в имени маршрутизатора данных о его расположении и модели, что нередко помогает администратору сети, так как позволяет не запоминать используемые пароли доступа к маршрутизатору — из его модели и расположения можно легко определить пароль, если, конечно, администратор выбрал такую схему назначения паролей.
Вообще выбранное имя может быть абсолютно произвольным, однако нужно следовать рекомендациям, приведенным в документе RFC 1035. Имя маршрутизатора не должно занимать больше 63 знакомест. Его следует начинать с символа, а заканчиваться оно может либо цифрой, либо символом. При формировании имени следует учесть, что оно является частью приглашения на ввод команд маршрутизатора, а в приглашении будет использовано не более 29 символов имени.
В работе любой распределенной сети самое активное участие принимает протокол сетевого уровня, причем, как правило, этот протокол является маршрутизируемым. Естественно, на маршрутизаторах необходимо проводить его настройку. Поддержка же того или иного протокола зависит от возможностей операционной системы. Например, если используется операционная система Cisco IP Feature Set, то, как видно из ее названия, маршрутизатор будет поддерживать только протокол IP. Если же используется Cisco Enterprise Feature Set, то будет доступен любой маршрутизируемый протокол.
СОВЕТ
Можно вполне определенно сказать, что поддержки только одного протокола IP вполне достаточно для большинства сетей, администраторы которых стремятся к унификации программной базы. Другой достаточно весомой причиной такого выбора является тот факт, что с новыми маршрутизаторами поставляется именно операционная система IP Feature Set.
В процессе выполнения начальной настройки маршрутизатора следует задать пароли, при помощи которых в дальнейшем будет организован доступ. ли доступа чувствительны к регистру (case sensitive) и могут содержать любую комбинацию прописных или строчных букв, цифр и пробелов (последние не должны быть первыми в пароле). Максимальная длина пароля ограничена 25 символами, хотя на практике такие длинные пароли редко находят применение.^4*"*
Для того чтобы настроить новый маршрутизатор, необходимо подключить к нему с помощью консольного порта компьютер и настроить программу эмуляции терминала (terminal emulation software). Подключение выполняется достаточно просто. Любой компьютер имеет по крайне мере два последовательных порта: СОМ1 и СОМ 2. Обычно физические разъемы этих портов имеют марку либо DB9M (DBS Male), либо DM25M (DB25 Male). На небольших по размеру маршрутизаторах (например, Cisco 805) для организации консольного порта используется разъем RJ45. Кроме того, для этих моделей поставляется готовый набор для подключения к компьютеру. В набор входит кабель, который имеет на обоих концах штекеры RJ45, и два специальных переходника, имеющих с одной стороны разъем RJ45, а с другой — разъем DB9F (DB9 Female) или DB25F (DB25 Female). Для подключения маршрутизатора выбирается свободный СОМ-порт на компьютере, а затем к нему подсоединяется кабель с необходимым типом
разъема. Например, если на компьютере свободен порт с разъемом DB9M, то нужно воспользоваться схемой RJ45-DB9F (рис. 1.5).
— К данному разъему подключить переходник
Рис. 1.5. Схема подключения маршрутизатора Cisco 805 к компьютеру
После физического подключения маршрутизатора к компьютеру для проведения процедуры настройки запускается программа эмуляции терминала. Существует множество готовых программных пакетов эмуляции терминала, и часто они поставляются прямо с операционной системой. Например, если на компьютере установлена операционная система Microsoft Windows NT 4.0 или Windows 2000, то можно воспользоваться программой HyperTerminal. Далее необходимо настроить параметры соединения, которые по умолчанию описываются популярной схемой 9600-8N1 (9600 baud, 8 data bits, no parity, 1 stop bits).
Теперь, после подключения маршрутизатора к компьютеру через консольный порт и настройки программы эмуляции терминала можно включать сам маршрутизатор. При этом на маршрутизаторе начинает выполняться загрузочное программное обеспечение (bootstrap software), которое запускает тест самодиагностики (Power-On Self-Test — POST), а затем находит загрузочное устройство (обычно это флэш-память), в котором содержится корректный образ операционной системы Cisco 1OS. Если включение маршрутизатора выполнялось при запущенной программе эмуляции терминала, то сообщения о начальной загрузке будут передаваться на консольный порт. Ниже приведен пример выводимых сообщений при загрузке маршрутизатора Cisco 805.
TinyROM version 1.2(2)
16:36 08/02/99
Copyright (с) 1998-1999 by cisco Systems. Inc.
All rights reserved.
POST OK. SMB DRAM. 4MB Flash.
Booting "c805-y6-mw.120-4.XM" ....
Cisco Internetwork Operating System Software
IOS (tm) C805 Software (C805-Y6-MW). Version 12.0(4)XM, EARLY DEPLOYMENT RELEASE SOFTWARE (fcl)
TAC:Home:SW:IOS:Specials for info
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Thu 17-Jun-99 16:51 by linda
Image text-base: 0x00138000, data-base: 0x00532000
Cisco C805 (MPC850) processor (revision 0) with 46944K bytes of virtual memory Processor board ID JAD035005G4
CPU part number 33
Bridging software.
1 Ethernet/IEEE 802.3 interface(s)
1 Serial(sync/async) network interface(s)
8M bytes of physical memory (DRAM)
8K bytes of non-volatile configuration memory
4M bytes of flash on board
Как видно из приведенного примера, был обнаружен образ операционной системы, после чего началась загрузка (Booting "c805-y6-nnw.120-4.XM" ...,). Далее из выдаваемой на экран информации можно узнать доступный объем памяти на маршрутизаторе, версию загрузочного программного обеспечения и версию самой операционной системы Cisco IOS (Version 12.0(4)ХМ).
Пошаговая настройка маршрутизатора
В процессе загрузки операционной системы Cisco IOS на экране отображается достаточно много информации, из которой можно узнать, например, объем оперативной памяти, объем памяти NVRAM и объем флэш-памяти (эту информацию также можно извлечь с помощью команды show version). В это время операционная система производит проверку памяти NVRAM на наличие в ней информации о конфигурации. На новых маршрутизаторах такой информации о конфигурации нет, и операционная система, обнаружив это, запускает программу пошаговой настройки маршрутизатора. В англоязычной технической литературе для обозначения такой программы используется термин System Configuration Dialog. Кратко рассмотрим процесс настройки маршрутизатора в обозначенной ситуации. Нужно отметить простоту использования программы и возможность получения подсказки от нее по каждому возникающему вопросу.
--- System Configuration Dialog --- ■
Would you like to enter the initial configuration dialog? [yes/no]: yes
At any point you may enter a question mark '?' for help.
Use Ctrl-с to abort configuration dialog at any prompt.
Default settings are in square brackets '[]'.
Работа программы пошаговой настройки маршрутизатора всегда начинается с вывода строк, в которых изложены основные приемы ее использования, после чего запрашиваются различные параметры. Чтобы воспользоваться подсказкой, нужно ввести символ ?. Если администратор сети начал выполнять пошаговую настройку маршрутизатора, а затем решил, что ему пет необходимости продолжать, он вправе нажать комбинацию клавиш Ctrl+C для остановки диалога. Если в процессе выполнения пошаговой настройки были даны ошибочные ответы на вопросы, то возможностей прямого исправления ошибок нет. Для коррекции ошибки есть два варианта действий: либо выключить, а затем вновь включить маршрутизатор и при его загрузке начать пошаговую настройку с выдачей правильных ответов, либо закончить пошаговую настройку, а затем исправить сделанные ошибки вручную, посредством ввода команд операционной системы в командной строке. Программа пошаговой настройки предлагает варианты ответов по умолчанию (которые показываются в квадратных скобках) на большинство задаваемых вопросов. Если ответ по умолчанию подходит для конкретной конфигурации, можно просто нажать клавишу Enter. В процессе пошаговой настройки предлагается изменить имя маршрутизатора. По умолчанию маршрутизатору присваивается имя Router.
Configuring global parameters:
Enter host name [Router]: Cisco805_Wharehouse...
При вводе имени маршрутизатора различаются строчные и прописные буквы (case sensitive). Напомним, что введенное имя маршрутизатора будет присутствовать в приглашениях на ввод команд в разных режимах. Это позволяет быстро идентифицировать конкретный маршрутизатор, с которым ведется работа. Если распределенная сеть построена на нескольких маршрутизаторах, то имя, предлагаемое по умолчанию, рекомендуется изменять, чтобы не путать маршрутизаторы друг с другом.
)ВЕТ — Как уже отмечалось, можно порекомендовать выбрать схему паролей таким образом, чтобы они были связаны с именем маршрутизатора. Удобство такой схемы в том, что не нужно заучивать наизусть пароли для десятка маршрутизаторов. Достаточно подключиться к маршрутизатору, а затем из его имени определить пароль. Естественный недостаток такой схемы связан с тем, что злоумышленник, поняв таким образом логику формирования паролей, сумеет получить доступ ко всем маршрутизаторам.
После ввода имени будет предложено ввести пароли, которые желательно обдумать еще на этапе планирования настроек маршрутизатора.
The enable secret is a password used to protect access to privileged EXEC and configuration modes. This password, after entered, becomes encrypted in the configuration.
Enter enable secret: ******
The enable password is used when you do not specify an enable secret password, with some older software versions, and some boot images.
Enter enable password: ******
% Please choose a password that is different from the enable secret
Enter enable password: ******
The virtual terminal password is used to protect access to the router over a networr interface. Enter virtual terminal password: ******
На каждый задаваемый по паролям вопрос необходимо дать ответ, так как для новых маршрутизаторов на эту группу вопросов нет ответов по умолчанию. Для предотвращения случайного просмотра запрашиваемый пароль enable secret password хранится в зашифрованном виде в конфигурации операционной системы Cisco IOS. а пароль enable password показывается в открытую. Оба этих пароля предназначены для выполнения одной задачи — контроля доступа в привилегированном режиме маршрутизатора, особенности' которого будут рассмотрены ниже. Следует отметить, что пароль enable secret password имеет преимущество перед паролем enable password, но система предлагает вводить их оба, так как старые версии операционной системы Cisco IOS не поддерживают зашифрованный пароль. Пароль доступа к виртуальному терминальному порту VTY (virtual terminal), как можно догадаться из названия, используется при установлении сеанса Telnet с маршрутизатором после выполнения его начальной настройки.
Далее программа пошаговой настройки дает возможность задать параметры интерфейсов. После этого она представит на обозрение получившуюся конфигурацию маршрутизатора и предложит несколько вариантов дальнейших действий. Это может быть, например, запись конфигурации в память NVRAM, как показано в примере ниже.
[0] Go to the IOS command prompt without saving this config.
Return back to the setup without saving this config.
Save this configuration to nvram and exit.
Enter your selection [2]: 0 You can enter the setup, by typing setup at IOS command prompt
Интерфейс командной строки Cisco IOS
После того как администратор выполнил программу пошаговой настройки, может появиться необходимость внести изменения в конфигурацию. Большинство конфигурационных команд выполняются с помощью интерфейса командной строки (Command Line Interface — С LI), который предоставляется операционной
системой Cisco IOS. Поэтому для настройки маршрутизаторов необходимо иметь хорошее представление о том, как им пользоваться. И хотя после приобретения некоторого опыта работа с интерфейсом не будет представлять никаких трудностей, начинающему администратору он вряд ли покажется простым. В этом разделе рассматриваются основные возможности интерфейса командной строки и некоторые задачи настройки маршрутизатора, которые нс зависят от сетевых протоколов, используемых в распределенной сети.
Очевидно, что для работы с маршрутизатором к нему нужно предварительно подключиться. Подключение может быть прямым с помощью консольного порта либо через сеть по протоколу Telnet. При начальной настройке маршрутизатора наиболее распространен первый способ подключения (если, конечно, маршрутизатор физически расположен недалеко от компьютера).
После подключения в случае, если на маршрутизаторе не был настроен пароль доступа по консольному порту, можно просто нажать клавишу Enter и, получив доступ, приступить к вводу команд.
Press RETURN to get started!
<Enter>
Router>
Защита доступа к консольному порту маршрутизатора с помощью пароля является хорошей практикой, по при этом последовательность подключения несколько изменяется — маршрутизатор выдает приглашение к вводу пароля.
Press-RETURN to get started!
<Enter>
User Access Verification
Password: ******
Router>
зовет
При наличии доступа к консольному порту маршрутизатора становится возможным получить доступ к маршрутизатору, даже не зная пароля. Это можно сделать, запустив процедуру восстановления утерянного пароля. Поэтому рекомендуется помещать маршрутизатор в физически защищенное место для снижения вероятности неконтролируемого доступа.
13 ОПЫТА
Очень удобным способом работы с маршрутизатором через консольный порт может быть подключение последнего к какому-либо серверу и запуск на сервере программы Terminal (в случае операционной системы Windows 2000). Здесь имеется ввиду не программа эмуляции виртуального терминала, а компонент, позволяющий пользователям создавать виртуальные сеансы, как будто они работают за локальным компьютером. При установке операционной системы Windows 2000 администратор может установить компонент Terminal Server, который по умолчанию позволяет работать с виртуальными сеансами только пользователям, включенным в состав административных групп.
Подключив сервер к консольному порту маршрутизатора, администратор получает возможность управления маршрутизатором, находясь при этом сколь угодно далеко от него (естественно, при наличии сетевой связи с сервером). Но несмотря на удобство такого подхода, у него есть и недостаток. Если злоумышленник смог получить доступ к виртуальному сеансу на сервере (что само по себе уже крупная неудача для специалиста, отвечающего за безопасность сети), то он сумеет получить доступ и к консольному порту маршрутизатора.
Доступ предоставляется только в случае введения корректного пароля, при этом даются три попытки. После трех неудачных попыток процедура входа начинается заново. Следует отметить, что при работе с маршрутизатором через консольный порт такая ситуация не создает серьезных проблем, так как, выждав несколько секунд перед вторичным нажатием клавиши Enter, можно начать вводить пароль повторно. Маршрутизатор ждет ввода пароля в течение 30 секунд, и если за это время ничего не ввести, то процедуру регистрации нужно будет проходить еще раз.
Администратор может также подключиться к маршрутизатору с помощью сеанса Telnet и после этого ввести корректный пароль. После того как было выдано приглашение к вводу пароля, дальнейшее поведение маршрутизатора полностью аналогично случаю использования консольного порта. Пароль, который предлагается напечатать при использовании сеанса Telnet, указывается при настройке виртуального терминального порта VTY.
User Access Verification
Password:
% Password: timeout expired!‘
Password: ******
Router>
Следует отметить, что хотя в рассмотренных примерах вместо пароля показаны символы *, на практике при его вводе на экране ничего не отображается. Эти символы приведены для наглядности. Так как все примеры были взяты с реально работающего оборудования, то по понятным причинам пароли не указаны.
Приглашение, выдаваемое операционной системой Cisco IOS (в приведенном выше примере — Router>), изменяется в зависимости от режима настройки. Приведем перечень базовых режимов, в которых выполняется большинство конфигурационных команд.
Пользовательский режим (User Mode).
Привилегированный режим (Privileged Mode).
Глобальный режим (Global Configuration Mode).
Режим подконфигурации (Sub-Configuration Modes).
Режим ROM Monitoring (ROM Monitoring Mode).
Рассмотрим каждый из этих режимов и их приглашения к вводу команд, которые и помогают идентифицировать текущий режим. Когда происходит подключение к маршрутизатору, запускается пользовательский режим. При этом в строке приглашения выводится настроенное имя маршрутизатора и символ >. В предыдущем примере при подключении к маршрутизатору посредством сеанса Telnet выдаваемое приглашение показывает, что после авторизации (проверки пароля) работа ведется в пользовательском режиме.
Router>
Возможности, предоставляемые пользовательским режимом, можно охарактеризовать одной фразой: «смотри, но ничего не меняй». Это объясняется тем,
что в данном режиме не предоставляется никаких путей серьезно воздействовать на работу операционной системы Cisco IOS. При этом можно просматривать любую информацию за исключением информации по рабочей (running) и по загрузочной (startup) конфигурации.
Если необходимо выполнить команды, которые потенциально будут влиять на работу маршрутизатора, или просмотреть текущую конфигурацию, то нужно перейти из пользовательского режима в привилегированный, в котором доступны все настройки, предусмотренные в данной операционной системе Cisco IOS. Так, например, можно просмотреть конфигурацию маршрутизатора или перезагрузить его. Для того чтобы перейти в привилегированный режим, следует ввести команду enable, результат которой будет следующий (для подключения через сеанс Telnet):
User Access Verification
Password:******
Router>enable
Password:******
Router#
Как видно из примера, при вводе команды enable операционная система предлагает ввести пароль для перехода в привилегированный режим работы. При наборе корректного пароля меняется выдаваемое приглашение, что указывает на работу в новом режиме — за именем маршрутизатора следует символ #. Начиная с этого момента администратор получает полный контроль над маршрутизатором. Довольно часто в англоязычной технической литературе привилегированный режим называют режимом разрешения (enable mode), очевидно из-за аналогии с командой enable и в противовес режиму запрета (команда disable).
Цель
Команда
Перейти в привилегированный режим работы
enable <пароль>
Получить список доступных команд
Ввод символа ?
Вернуться в пользовательский режим
disable
При начальной настройке маршрутизатора предлагается задать пароль доступа в привилегированный режим. Пароль доступа обозначается на экране словосочетанием enable secret, где слово secret указывает на то, что при просмотре файлов конфигурации пароль отображается на экране в зашифрованном виде.
Кроме этого пароля предлагается задать так называемый enable password, который при наличии первого зашифрованного пароля не несет на маршрутизаторе никакой нагрузки. Однако в том случае, если из конфигурации маршрутизатора изъять зашифрованный пароль, то доступ к привилегированному режиму будет контролироваться именно паролем enable password.
В рассмотренных выше примерах для возврата в пользовательский режим из привилегированного нужно выполнить команду disable.
Router#disable
Router>
Конфигурационные режимы предназначены для ввода команд, управляющих работой маршрутизатора. Основным режимом настройки является глобальный режим (global configuration mode), из которого можно попасть в другие режимы. Все команды, которые вводятся в этом режиме, влияют, на рабочую конфигурацию маршрутизатора (running configuration) и вступают в силу немедленно после их ввода. В глобальный режим можно попасть только из привилегированного. При этом команды, доступные в пользовательском и привилегированном режимах, в глобальном режиме маршрутизатором не воспринимаются.
В глобальном режиме все изменения сказываются на общей, или «глобальной», работе маршрутизатора. Например, в этом режиме допускается смена имени маршрутизатора, установка некоторых паролей и т. п. Для того чтобы перейти из привилегированного режима в глобальный, нужно выполнить команду configure terminal.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Цель
Команда
Перейти в глобальный режим работы
configure terminal
Получить список доступных команд
7
Выйти из глобального режима работы
end, exit или Ctrl+Z
Как видно из примера, приглашение к вводу команд в глобальном режиме состоит из имени маршрутизатора, ключевого слова config, заключенного в скобки, и символа #. В соответствии с рекомендацией, показанной в примере, данный режим можно немедленно покинуть и вернуться в привилегированный режим, если нажать комбинацию клавиш Ctrl+Z. Помимо этого, возврат в привилегированный режим осуществляется также командами end и exit.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#^Z
Router#
Находясь в глобальном режиме, администратор может перейти и в другие режимы конфигурации. Режимы подконфигурации (sub-configuration modes) используются для настройки индивидуальных компонентов, таких, например, как интерфейсы маршрутизатора. При этом сама команда, которая необходима для переключения в тот или иной режим подконфигурации, зависит от настраиваемого компонента. Например, для выполнения настроек интерфейса следует перейти в режим конфигурации интерфейсов (interface configuration mode). Для такого перехода нужно выполнить команду interface, находясь в глобальном режиме. Эта команда требует в качестве параметра полного имени интерфейса и его номера. Задав в качестве параметра знак вопроса, вы увидите список интерфейсов, доступных для настройки.
Router(config)#interface ?
Async BVI Dialer Ethernet Group-Async Lex Loopback Null Serial Tunnel
Async interface
Bridge-Group Virtual Interface
Dialer interface
IEEE 802.3
Async Group interface
Lex interface
Loopback interface
Null interface
Serial
Tunnel interface
Virtual-Tempiate Virtual Template interface
Цель
Команда
Находясь в глобальном режиме, перейти в режим конфигурации интерфейсов
interface <тип интерфейса> сномер интерфейса>
Получить список доступных команд
Например, для того чтобы оказаться в режиме конфигурации интерфейсов и настроить интерфейс SerialO, нужно выполнить следующую команду:
Router(config)#interface serial О
Router(config-if)#
Все режимы подконфигурации имеют приглашение, состоящее из имени маршрутизатора, ключевого слова config и обозначения, указывающего на текущий режим, заключенной в скобки. В приведенном примере обозначение -if свидет тельствует о том, что работа идет в режиме конфигурации интерфейсов. В строке этого приглашения можно вводить команды, влияющие на настройку интерфейса SerialO, а также любые команды, относящиеся к глобальному режиму, так как последние принимаются маршрутизатором в любом из режимов конфигурации. Для того чтобы из режима конфигурации интерфейсов вернуться в глобальный, надо ввести команду exit.
В том случае, если администратор, находясь в режиме подконфигурации, введет команду, которая не регламентирует переход в другой режим, система вернется в глобальный режим. Например, в режиме конфигурации интерфейсов можно ввести команду, изменяющую имя маршрутизатора:
Router(config)#interface serialO
Router(config-if)#hostname Router
Router(config)#
Существуют около двадцати режимов подконфигурации. Наиболее активно используемые будут рассмотрены далее в главах книги, посвященных вопросам безопасности (глава 9), протоколам маршрутизации (глава 7) и технологии Frame Relay (глава 8).
Режим ROM Monitoring (ROMMON) на самом деле не является режимом работы операционной системы Cisco IOS — в этом состоянии маршрутизатор работает, пока операционная система еще не загружена. Если маршрутизатор пы-
тается загрузиться и не находит соответствующего файла загрузки (IOS image), то он переходит в режим ROMMON. Администратор вправе принудить маршрутизатор переключиться в этот режим путем посылки специального сигнала с клавиатуры (обычно следует нажать комбинацию клавиш Ctrl+Break) на консольный порт в течение 60 секунд начиная с момента загрузки. В результате маршрутизатор прервет процесс загрузки и перейдет в режим ROM Monitoring. Как правило, данное переключение выполняется для восстановления утерянного пароля. В этом режиме присутствуют команды, которые позволяют вручную загрузить маршрутизатор с указанием корректного файла загрузки.
Цель
Команда
Перейти в режим ROMMON, находясь в привилегированном режиме (только в нем доступна команда reload, выполняющая принудительную перезагрузку маршрутизатора)
Reload
или нажать комбинацию Ctrl+Break в течение 60 секунд в процессе загрузки маршрутизатора
Получить список доступных команд
- В режиме ROMMON не так много доступных для выполнения команд. Их список можно получить вводом символа ?. Таблица 1.1 содержит перечень команд для навигации по возможным режимам работы маршрутизатора.
Таблица 1.1. Режимы работы маршрутизатора
Режим работы
Метод перехода
Приглашение маршрутизатора
Как покинуть режим
Пользовательский
При вводе пароля на подключение
Router>
Ввод команды logout
Привилегированный
Находясь в пользовательском режиме, ввести команду enable
Router#
Для возврата в пользовательский режим следует ввести команду disable
Глобальный
Находясь в привилегированном режиме, ввести команду configure terminal
Router(config)#
Для выхода в привилегированный режим следует ввести ' команду exit
Конфигурирование интерфейсов
Находясь в глобальном режиме, ввести команду interface с параметрами в виде имени и номера выбранного интерфейса, interface Serial 1
Router(config-if)#
Для выхода в глобальный режим следует ввести команду exit
Конфигурирование подинтерфейсов
Находясь в глобальном режиме, ввести команду interface с параметрами в виде имени и номера выбранного подинтерфейса interface Seriall.l
Router(config-subif)#
Для выхода в глобальный режим следует ввести команду exit
Соманды Cisco IOS
После рассмотрения различных режимов, в которых можно настраивать маршрутизатор, разберем формат команд настройки и метод их ввода. Вообще говоря, использование операционной системы Cisco IOS не должно вызывать особых трудностей — требуется только ввести команду и нажать клавишу Enter, которая инициирует исполнение команды. В том случае, если введенная команда некорректна (например, ошибка в синтаксисе), операционная система укажет на допущенную ошибку. Если команда вводится в пользовательском или привилегированном режимах, операционная система проверяет весь список команд, для того чтобы убедиться в правильности введенной команды. В случае, если такая команда не найдена в списке, операционная система рассматривает ее как имя. удаленного устройства, с которым нужно установить сеанс Telnet. Например, если, находясь в пользовательском режиме, ввести слово customer, которое не является командой операционной системы, то можно получить следующий результат:
Router#customer
Translating "customer"...domain server (192.168.4.253)
% Unknown command or computer name, or unable to find computer address Router#'
Из примера видно, что маршрутизатор пытается преобразовать введенное слово в IP-адрес путем опроса настроенного на нем адреса (192.168.4.253) сервера DNS. Поэтому лучше просто ввести IP-адрес и, если это будет возможно, маршрутизатор установит с указанным устройством сеанс Telnet.
Router#192.168.2.254'
Trying 192.168.2.254 ... Open
User Access Verification
Password:
С помощью команды terminal администратор может контролировать способ выдачи информации и изменять другие настройки, доступные в пользовательском режиме. Любые переопределяемые этой командой параметры действительны только в течение текущего сеанса и не восстанавливаются при следующем подключении к маршрутизатору."
Выше были рассмотрены простые команды, которые практически не требовали указания параметров. Однако для углубленной настройки маршрутизатора могут понадобиться и более сложные команды. В связи с этим полезной будет информация о наиболее эффективных способах работы с командной строкой. Кроме того, без них интенсивная настройка с использованием множества команд может показаться обременительной.
Операционная система позволяет редактировать команды во время их ввода, то есть перемещать курсор по командной строке, добавлять или удалять символы. Каждая вводимая команда ограничена по длине 253 символами, а операционная система для удобства запоминает десять последних введенных команд в буфере истории. Самый удобный способ перемещения курсора между символами вводимой команды — это нажатие клавиш с изображениями стрелок. Эти клавиши
можно использовать в ANSI-совместимых терминальных программах, таких как VT100, VT220 и VT320. .
Отображение накопленных в буфере истории команд производится клавишами с изображением стрелок, направленных вверх и вниз. Итак, в буфере истории сохраняется десять последних введенных команд, а в распоряжении администратора есть две команды настройки — одна меняет размер буфера, а другая запрещает его использование. Для последнего действия нужно выполнить команду terminal no history, а для изменения количества команд, сохраняемых в буфере, предназначена команда terminal history size с параметром, указывающим на количество команд:
Router>terminal history size 15 .
Все вводимые команды и их параметры допускается сокращать до акронима, который однозначно идентифицирует команду. Такое упрощение позволяет значительно сократить время набора и снизить число синтаксических ошибок. В табл. 1.2 перечислены некоторые возможные сокращения.
Таблица 1.2. Возможные сокращения команд
Полное имя команды
Сокращение
Show
sh
Show protocols
Terminal length 0
Enable
sh prot term len 0
en
Configure terminal■
Ethernet
conf t
e
Serial
s
Interface ethernetO
int eO
Quit
q
Следует отметить, что операционная система Cisco IOS обладает очень полезным качеством: она предоставляет обширную справочную информацию. Для того чтобы вызвать необходимую справку, следует вместо команды ввести знак вопроса ? и нажать клавишу Enter. В ответ на это маршрутизатор выведет список команд, которые доступны для выполнения в текущем режиме настройки. В том случае, если знак вопроса записывается в конце набираемой команды, нет необходимости нажимать клавишу Enter, так как операционная система воспримет знак вопроса как конец команды и сразу же выдаст подсказку. Например, можно получить подсказку по командам, допустимым в пользовательском режиме. Отметим, что в данном примере объем выводимой информации искусственно ограничен, в то время как на практике список команд способен простираться на несколько экранов.
Routeo?
Exec commands:
<1-99>Session number to resume
access-enable Create a temporary Access-List entry
clearReset functions
connectOpen a terminal connection
disableTurn off privileged commands
disconnect Disconnect an existing network connection
enable ' Turn on privileged commands
exitExitfrom the EXEC
helpDescription of the interactive help system
lockLockthe terminal
loginLog in as a particular user
logoutExitfrom the EXEC
В следующем примере показана подсказка по командам, доступным в привилегированном режиме работы операционной системы.
Routeoenable
Router#?
Exec commands:
<l-99> access-enable
Session number to resume
Create a temporary Access-List entry
access-template Create a temporary Access-List entry
bfe clear clock configure connect copy debug disable disconnect enable
For manual emergency modes setting Reset functions
Manage the system clock Enter configuration mode Open a terminal connection Copy configuration or image data Debugging functions (see also 'undebug') Turn off privileged commands Disconnect an existing network connection Turn on privileged commands~
Если ввести акроним команды, а за ней без пробела сразу же знак вопроса, то операционная система напечатает список всех доступных команд, которые соответствуют этому сокращению:
Router#co?
configure connect copy
Помимо общего списка доступных команд можно получить рекомендацию по применению конкретной команды, выполняя се со знаком вопроса в качестве параметра. Следующие примеры иллюстрируют работу справочной системы, помогая усвоить действие одной из команд маршрутизатора —■ clock, предназначенной для установки даты и времени на маршрутизаторе.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#clock ?
summer-time Configure summer (daylight savings) time
timezone Configure time zone
Router(config)#clock timezone ?
WORD name of time zone
Router(config)#clock timezone ZONE ?
<-23 - 23> Hours offset from UTC
По мере выполнения все большего числа настроек на маршрутизаторе становится поистине бесценной возможность повторения введенных ранее команд с помощью нажатия клавиши Т. Другой очень полезной функциональностью является использование клавиши табуляции Tab, которая заканчивает вводимую команду после указания нескольких ее первых символов. Другими словами, после того как были набраны несколько первых уникальных символов и нажата клавиша Tab, операционная система Cisco IOS добавит окончание команды самостоятельно. Например, часто приходится вводить команду configure terminal, которая является достаточно длинной, для того чтобы вызвать некоторый дискомфорт для администратора сети при ее частом наборе. Для ускорения набора можно ввести conf t и нажать клавишу Tab.
Следует отметить, что приведенная в примере команда conf t не требует обязательного нажатия клавиши Tab, так как ее первая-составляющая (conf) однозначно идентифицирует команду configure, а вторая составная часть (t) так же однозначно идентифицирует ключевое слово terminal. Используя табуляцию и знак вопроса, можно получить минимально необходимое количество информации для выполнения настройки. Например, с комбинации символов со начинаются три команды, поэтому ввод этих двух символов неоднозначно определяет команду configure. Символов con также недостаточно для ввода команды configure, поскольку существует еще команда connect.
Router#con?
configure connect
Router#conf<Tab>
Router#configure t<Tab>
Router#configure terminai<Tab>
По мере выполнения настройки маршрутизатора администратор может отменить введенную ранее команду. Для этого следует ввести ключевое слово по в начале конфигурационной команды. Практически все команды операционной системы Cisco IOS могут быть отменены таким способом. В следующем примере показана настройка параметра, отвечающего за скорость, доступную на интерфейсе SerialO, а затем отмена этого действия.
Router(conf1g)#jnterface serialO
Router(config-if)#bandwidth 256
Routericonfig-jf)#no bandwidth 256
Наиболее популярная (с точки зрения автора) команда, которая выполняется в пользовательском и привилегированном режимах, — это команда show. Она используется в том случае, когда необходимо получить информацию о работе и настройках операционной системы. Иногда выдаваемые сведения не помещаются
на.один экран, и в этом случае операционная система предлагает вручную управлять выдачей дальнейшей информации. Для этого можно воспользоваться клавишей Enter, после нажатия которой выдается следующая строка текста, или клавишей пробела (Space), которая позволяет вывести еще один экран. При этом объем информации, выдаваемой при нажатии клавиши пробела, зависит от того, сколько строк информации требуется отобразить и на выдачу какого количества строк настроена операционная система. Значение по умолчанию составляет 24 строки — число, приемлемое для большинства случаев. Это значение можно поменять посредством команды terminal length, задав в качестве аргумента желаемое число строк. Обычно необходимости в изменении количества отображаемых строк не возникает, но такая возможность потенциально полезна, например, если при использовании терминальной программы необходимо сохранить результат, выдаваемый в ответ на команду show, в файле. При этом можно запретить выдачу информации поэкранно с помощью команды terminal length 0. После выполнения данной команды операционная система будет отображать информацию самостоятельно без нажатия клавиш, инициирующих продолжение ее отображения. Здесь следует отметить, что по умолчанию все терминальные сеансы работы с маршрутизатором будут автоматически закрываться по истечении 10 минут состояния неактивности. При необходимости это значение можно изменить с помощью команды exec-timeout, которая будет рассмотрена в разделе «Работа с интерфейсами и портами маршрутизатора» главы 3.
Информация о работе маршрутизатора и его возможностях является полезным подспорьем для администратора сети. Например, довольно часто нужно быть в курсе следующих вопросов: насколько загружен процессор маршрутизатора, какой объем памяти доступен и сколько ее задействовано, какая версия операционной системы Cisco IOS задействована на маршрутизаторе, какие протоколы настроены и т. п. Такая информация может быть получена с помощью команды show. Эта команда выполняется либо в пользовательском, либо в привилегированном режиме, причем в пользовательском режиме доступна любая информация, за исключением данных о конфигурации маршрутизатора.
Применяемая в пользовательском и привилегированном режимах команда show version возвращает сведения общего характера о маршрутизаторе. Следующий пример показывает результат работы этой команды для модели маршрутизатора Cisco 1601.
Ciscol601>show version
IOS (tm) 1600 Software (C1600-Y-L), Version 11.3(3)T. RELEASE SOFTWARE (fcl) Copyright (c) 1986-1998 by cisco Systems. Inc.
Compiled Mon 20-Apr-98 19:48 by ccai
Image text-base: 0x08022058. data-base: 0x02005000'
ROM: System Bootstrap. Version ll.l(10)AA. EARLY DEPLOYMENT RELEASE SOFTWARE (fcl).
ROM: 1600 Software (C1600-BOOT-R). Version ll.l(10)AA. EARLY DEPLOYMENT RELEASE'
SOFTWARE (fcl)
Ciscol601 uptime is 6 days. 22 hours. 54 minutes
System restarted by power-on
System image file is "flash:cl600-y-l.113-3.T.bin", booted via flash
cisco 1601 (68360) processor (revision C) with 1536K/512K bytes of memory. ' processor board ID 10510267, with hardware revision 00000000
Bridging software.
X.25,software. Version 3.0.0.,
1 Ethernet/IEEE 802.3 interface(s)
2 serial(sync/async) network interface(s)
System/10 memory with parity disabled
2048K bytes of DRAM onboard
System running from FLASH"
8K bytes of non-volatile configuration memory.
6144K bytes of processor board PCMCIA flash (Read ONLY)
Configuration register is 0x2102
Из результата ее выполнения можно определить, например, версию операционной системы — 11.3(3)Т. Далее можно узнать время непрерывной работы маршрутизатора — Ciscol601 uptime is 6 days, 22 hours, 54 minutes, или имя загрузочного файла маршрутизатора — flash:с!600-у-1.113-3-T.bin. Интересные сведения также помещаются в строку, указывающую на причину последней перезагрузки маршрутизатора. Такой причиной бывает выключение питания (как в нашем примере — System restarted by power-on) или произошедший сбой. В этом случае можно наблюдать следующую запись: System restarted by bus error at... Хочется отметить, что автор с последней ситуацией ни разу не сталкивался.
В последней строке выводится содержимое конфигурационного регистра (Configuration register) в шестнадцатеричном формате. Конфигурационный регистр контролирует, например, процесс загрузки маршрутизатора. Следует сказать, что результат работы команды show version различается в зависимости от модели маршрутизатора и, как уже говорилось, с ее помощью можно получить достаточный объем информации о маршрутизаторе и его программном обеспечении.
Проверка содержимого флэш-памяти осуществляется с помощью команды show flash. Ниже приведен пример выполнения этой команды на маршрутизаторе Cisco 805.
Cisco805#show flash.
Directory of flash:/
0 ----49096May 15 1999 03:55:31 TinyROM-1.2(1)
1 -r-x . 2287176Jun 18 1999 05:18:51 c805-y6-mw.120-4.XM
4194304 bytes total (1835008 bytes free).
Cisco805#
Отсюда видно, что существует некий файл, представляющий собой образ операционной системы Cisco IOS (c805-y6-mw.120-4.XM). При этом флэш-память может содержать несколько файлов — в качестве ограничителя выступает только размер свободного пространства.
Компанией Cisco Systems принята собственная схема именования файлов, в которых размещена операционная система IOS. Эта схема позволяет по имени файла определить версию операционной системы и модель маршрутизатора, для которой она предназначена. Как видно из предыдущего примера, имя файла состоит из нескольких секций, разделенных точкой. При этом первая секция имеет три группы символов, разделяемые знаком -. Первая группа (здесь с805) указывает на платформу маршрутизатора, вторая определяет набор возможностей (feature set), а уб-mw именно указывает на ограниченный набор возможностей по поддержке протокола IP — reduced IP variant. Вторая секция содержит идентификатор версии операционной системы — в нашем примере это 12.0(4). Для более детального ознакомления со схемой именования файлов в операционной системе Cisco IOS необходимо обратиться к документу Cisco IOS Reference Guide, размещенному в Интернете по адресу http://www.cisco.eom/warp/public/620/4.html.
Работа с аппаратными интерфейсами маршрутизатора
Для более наглядного представления о расположении аппаратных интерфейсов приведем рисунок, на котором изображена задняя панель маршрутизатора (рис. 1.6)
Рис. 1.6. Интерфейсы маршрутизатора
В табл. 1.3 представлено подробное описание каждого интерфейса и выполняемые ими функции.
Таблица 1.3. Описание интерфейсов маршрутизатора
Интерфейс
Задачи
ETHERNET 0
10BASEТ
Подключение маршрутизатора к локальной сети на скорости 10 Мбит/с
CONSOLE
Подключение маршрутизатора к компьютеру с помощью консольного кабеля. На стороне маршрутизатора консольный разъем имеет тип RJ45
WIC
Свободный слот для дополнительного интерфейсного модуля, с помощью которого, например, можно организовать еще один интерфейс Serial (скорость передачи до 2 Мбит/с)
FLASH PC CARD
Слот для установки флэш-карты, содержащей образ операционной системы Cisco IOS. Новые маршрутизаторы поставляются с предустановленной картой
SERIAL 0
Для подключения маршрутизатора к выделенным каналам связи (leased lines), сети Frame Relay и т. п.■
В модели маршрутизатора Cisco 1601 присутствует свободный слот для установки дополнительного интерфейсного модуля (WIC). Если после покупки маршрутизатора появилась необходимость в организации еще одного подключения, то администратор может просто докупить нужный ему модуль, что получается дешевле приобретения нового маршрутизатора (рис. 1.7).
.Дополнительный модуль
Рис. 1.7. Установка дополнительного модуля в маршрутизатор
Связь между интерфейсами и внутренними компонентами маршрутизатора осуществляется через контроллеры. Контроллеры предназначены для организации взаимодействия между отдельными компонентами маршрутизатора. Существует множество типов контроллеров, и их наличие или отсутствие зависит от модели маршрутизатора и его внутренней конфигурации.
Для того чтобы просмотреть информацию о контроллерах, например узнать тип аппаратного обеспечения, статистику, версию программного кода и т. п., нужно выполнить команду show controllers. Информация, выводимая этой командой, может размещаться на множестве строк, поэтому в следующем примере ограничимся только первыми несколькими строками.
Ciscol601#show controllers ethernet
QUICC Ethernet unit 0 using SCC1, Microcode ver 4
Current station address 0010.7bef.4478. default address 0010.7bef.4478
idb at 0x207B9A4, driver data structure at 0x2079490
В результате работы этой команды администратор получил информацию о контроллере Ethernet, в который па данной модели маршрутизатора встроена микросхема QUICC. '
Приведем пример работы этой команды для модели Cisco 2511RJ. Как видно, в ней применяется набор микросхем LANCE. Кроме того, из результатов работы команды можно опередить МАС-адрес (аппаратный адрес устройства), присвоенный интерфейсу (station address).
С1sco2511RJ#show controllers ethernet
LANCE unit 0, 1db 0x8E3A4, ds 0x8FE30, regaddr = 0x2130000. reset_mask 0x2
IB at 0x206DAC: mode=0x0000, mcfilter 0000/0000/0100/0000
station address 0010.7b3a.b6de default station address 0010.7b3a.b6de
buffer size 1524
Теперь применим команду show controllers для интерфейса Serial маршрутизатора. По результату работы можно определить тип кабеля, подключенного к данному интерфейсу, — V.35 DTE (Data Terminal Equipment cable). Тут следует отметить, что подразумевается наличие кабеля, свободный конец которого после подключения к маршрутизатору имеет разъем интерфейса V.35 (тип male). В нашем случае к данному разъему подключен модем для физических линий компании RAD, который представляет собой оконечное оборудование (DCE, Data Circuitterminating Equipment) стороны подключения (тип female).
Cisco2511RJ#show controllers serial
HD unit 0, idb = 0x94364, driver structure at 0x98010
buffer size 1524 HD unit 0. V.35 DTE cable
cpb = 0x21. eda = 0x4878, cda = 0x488C
RX ring with 16 entries at 0x214800
В настоящее время предлагаются шесть типов кабелей для интерфейса Serial, которые в англоязычной литературе могут называться serial adapter cables или serial transition cables: EIA/TIA-232, EIA/TIA-449, V.35, X.21, EIA/TIA-530 и EI А/ TIA-530A. Все эти кабели имеют универсальный разъем на конце, подключаемом к маршрутизатору, в то время как другие концы кабелей (так называемые сетевые) отличаются типом разъема. Например, кабель EIA/TIA-232 на сетевом конце завершается популярным разъемом DB-25. Все кабели, за исключением EIA-530, доступны в формах DCE и DTE. Само подключение кабеля выполняется очень просто и требует элементарной аккуратности, так как при подсоединении кабеля к маршрутизатору можно погнуть штырьки на разъеме, а с учетом большой плотности их расположения и немалого количества процесс починки может затянуться надолго (рис. 1.8).
:овет — Более подробную информацию о кабелях и их распайке можно найти, например, по следующему адресу: http://www.cisco.com/en/US/products/hw/routers/ps233/products_installation_and_configuration_ guide_chapter09186a008007elcd.html.
Одним из наиболее популярных типов кабелей, используемых для подключения оборудования к интерфейсу маршрутизатора Serial, является 32-штырьковый кабель интерфейса V.35, хотя в последнее время автор все чаще сталкивался с оборудованием, имеющим разъем DB-25 (например, модемы серии xDSL WATSON). Если администратору нужен именно кабель V.35, то, как уже отмечалось, при его выборе следует обращать внимание на тип разъема оборудования, которое планируется подключить к маршрутизатору. Выбираемый кабель
может заканчиваться разъемом типа female (DCE) или male (DTE). Чаще всего подключаемое оборудование имеет разъем female, что и определяет тип заказываемого кабеля (рис. 1.9).
Универсальный разъем —Универсальный разъем —|— Индикаторы|— ИндикаторыРис. 1.8. Подключение оборудования к интерфейсу Serial маршрутизатораРис. 1.8. Подключение оборудования к интерфейсу Serial маршрутизатора
Универсальный разъем —
Универсальный разъем —
|— Индикаторы
|— Индикаторы
Рис. 1.8. Подключение оборудования к интерфейсу Serial маршрутизатора
Рис. 1.8. Подключение оборудования к интерфейсу Serial маршрутизатора
Рис. 1.9. Разъемы интерфейса V.35 (DTE и DCE)
Помимо просмотра информации об аппаратной части интерфейса на маршрутизаторе часто возникает крайняя необходимость проверить статус интерфейса и получить статистику его работы. Причем после выполнения всех необходимых шагов настройки маршрутизатора и подключения его к действующей сети проверяется именно статус интерфейса. Он состоит из двух компонентов, которые соответствуют требованиям эталонной модели OSI, — статус для физического и канального уровней. Первый компонент, статус физического уровня, указывает на то, что интерфейс прошел диагностику и получил необходимые сигналы от подключенного оборудования.
Следующий компонент статуса, соответствующий канальному уровню, указывает на получение интерфейсом так называемых сообщений keepalive («пока жив»), которые представляют собой небольшие сообщения канального уровня, Рассылаемые сетевыми устройствами для подтверждения своей доступности. Если поддержка этих сообщений не отключена, то по умолчанию они передаются через интерфейс каждые десять секунд. Интерфейсы, подключенные к глобальной
сети, переводятся в рабочее состояние (в информационных сообщениях на маршрутизаторе это обозначается как Up) в том случае, если они получают такие сообщения. На интерфейсах локальной сети маршрутизатор посылает эти сообщения сам себе, и при их получении интерфейс также переходит в рабочее состояние. В табл. 1.4 перечислены комбинации статусов двух компонентов интерфейса с расшифровкой возможных причин их состояний.
Таблица 1.4. Комбинации статусов и причины их установки
Статус физического уровня
Статус канального уровня
Возможные причины
up
Up
Интерфейс находится в рабочем состоянии
up
Down
Физическое подключение интерфейса работает, однако сообщения keepalive не получены
Down
Down
Не работает физическое подключение интерфейса
Administratively Down
Down
Интерфейс был вручную отключен администратором сети (shutdown)
Up
Up (looped)
Интерфейс глобальной сети получает свои собственные сообщения keepalive
Интерфейс, находящийся в рабочем состоянии, обычно обозначается как UP/UP. Это говорит о том, что оба компонента интерфейса работают. В том случае, если используемый протокол канального уровня находится в рабочем состоянии, а интерфейс не получает сообщения keepalive в течение трех временных интервалов, компонент канального уровня изменяет свое состояние на нерабочее (down). Для того чтобы проверить состояние этих двух компонентов интерфейса и просмотреть статистику его работы, можно воспользоваться командой show interface. Выполнение этой команды без указания параметров позволит получить информацию обо всех доступных интерфейсах на маршрутизаторе. Если необходимо проверить какой-либо определенный интерфейс, нужно выполнить рассматриваемую команду с именем интересующего интерфейса в качестве параметра. Из приведенного ниже примера видно, что оба компонента интерфейса маршрутизатора Cisco 1005, подключенного к сети Frame Relay, находятся в рабочем состоянии.
C1scol005#sh in sO
Seri al 0 is up, line protocol is up
Hardware is QUICC Serial
MTU 1500 bytes. BW 1544 Kbit. DLY 20000 usee, rely 255/255. load 1/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 18350. LMI stat reevd 18350, LMI upd reevd 0. DTE LMI up LMI enq reevd 0. LMI stat sent 0. LMI upd sent 0
' LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
Вообще говоря, из результата работы команды keepalive администратор сети может извлечь очень много полезной информации. В рассматриваемом примере
интерфейс SerialO подключен к сети Frame Relay, и на нем настроен подинтерфейс (subinterface). Как видно, статус самого интерфейса выдается в первой строке результата, далее выводится статистика работы протокола LMI (настройка маршрутизаторов для использования в сети Frame Relay будет рассмотрена в главе 8), используемый тип инкапсуляции, значение минимального передаваемого блока (MTU, Maximum Transfer Unit) в байтах, пропускная способность BW (bandwidth), задержка DLY (delay) и т. п.
Следует отметить, что установка значения пропускной способности канала связи на интерфейсе не имеет ничего общего со скоростью самого интерфейса. Данная установка значима для протоколов и приложений верхних уровней. Например, протокол маршрутизации EIGRP привлекает установленное значение пропускной способности для расчета метрики маршрута, а приложение управления сетью по протоколу SNMP может использовать это значение для расчета степени загруженности канала. Пропускная способность устанавливается в килобитах в секунду (Кбит/с). При этом значение по умолчанию составляет 1544 Кбит/с. Для того чтобы изменить значение, заданное по умолчанию, следует воспользоваться командой bandwidth, выполняемой в режиме конфигурирования интерфейсов с новым значением пропускной способности в качестве параметра.
MTU определяет максимальный размер пакета, который может быть получен или передан через данный интерфейс (по умолчанию это значение составляет 1500 байт). Подробнее рассмотрим вопрос оценки оптимального MTU. При выборе MTU необходимо следовать простому правилу: назначать меньшее значение из всех возможных допустимых значений в каналах по пути прохождения пакета. Следствием выполнения данного правила будет повышение пропускной способности канала за счет того, что маршрутизатору не придется разбивать один пакет на несколько, если размер пакета сетевого уровня в следующем канале должен быть меньше, чем в предыдущем. Следует помнить, что назначение заниженного значения MTU также ограничит пропускную способность между двумя конечными станциями или между двумя сетями одного и того же типа.
Из сказанного становится понятно, что присвоение оптимального значения MTU является очень важным этапом настройки сети. Правда, некоторые протоколы сами выбирают значения MTU, которые подходят для всех известных типов сетей (обычно 576 байтов), но опять же за счет сокращения пропускной способности. Иные протоколы обязывают выбирать максимальный размер пакета при конфигурировании драйвера локальной сети на каждом компьютере в сети. Существуют протоколы, производящие анализ пути между двумя узлами во время установления соединения. Они позволяют определить наибольшее значение MTU, при котором не потребуется производить фрагментацию кадров.
Задача усложняется, если путь проходит по каналам глобальной сети. Это относится и к варианту соединения каналов «точка-точка». Конфигурация маршрутизатора содержит параметры MTU для каждого интерфейса глобальной сети, один из которых необходимо установить. Сложность состоит в том, что требуется передавать по глобальной сети как можно большее число пакетов без фрагментации и с минимальным временем задержки за счет сокращения длины пакетов. Необходимо назначать MTU так, чтобы пропускная способность была максимальна, а фрагментация минимальна.
Рассмотрим два сценария передачи файла размером в миллион байтов. В первом сценарии файл отправляется с устройства А посредством 4000-байтовых пакетов; во втором — с устройства В посредством 500-байтовых пакетов. Так как маршрутизатор обрабатывает пакеты по мере поступления и каждый пакет приводит к небольшой, но не нулевой задержке в интерфейсе глобальной сети, то устройство А будет иметь преимущество при передаче от маршрутизатора к маршрутизатору на пути следования просто потому, что его пакеты длиннее. С другой стороны, если размер пакета в глобальной сети ограничен значением 500 байт, то устройство В получит преимущество вследствие дополнительных затрат времени на фрагментацию и сборку пакетов устройством А.
Обобщая сказанное, можно прийти к выводу, что наилучший способ выбора оптимального MTU для интерфейсов маршрутизаторов и компьютеров в сети состоит в определении часто используемых маршрутов передачи данных и настройке значений MTU на выбранных компьютерах и интерфейсов маршрутизаторов до тех пор, пока не будет получен желаемый результат.
Операционная система Cisco IOS поддерживает механизм обнаружения MTU (Path MTU), как это определено в документе RFC 1191. Этот механизм позволяет маршрутизатору автоматически обнаруживать и учитывать различия между максимально допустимыми значениями MTU на различных переходах в распределенной сети. Иногда маршрутизатор не может переслать дейтаграмму протокола IP (главу 2), так как требуется фрагментация. А дейтаграмма имеет больший размер, чем установленное администратором значение MTU для интерфейса. Но в заголовке этой дейтаграммы установлен бит, указывающий на то, что фрагментацию выполнять нельзя (бит Don't Fragment — DF). В таком случае маршрутизатор посылает сообщение отправителю дейтаграммы, в котором говорится о необходимости выполнения фрагментации, с тем чтобы фрагменты подходили к наименьшему значению MTU в пути следования. Механизм обнаружения MTU полезен также в случае, когда один из каналов в распределенной сети выходит из строя. Тогда может быть, например, задействован резервный канал, но с другим значением MTU.
Рассмотрим простой пример, когда дейтаграмма проходит через сеть, где MTU на первом маршрутизаторе равен 1500 байт, а на втором — 512 байт. Если отправитель установил в дейтаграмме бит, запрещающий выполнять фрагментацию, то все дейтаграммы, превышающие по размеру 512 байт, вторым маршрутизатором будут отбрасываться. Этот маршрутизатор пошлет отправителю сообщение протокола ICMP (Destination Unreachable) с указанием необходимости проведения фрагментации. При поддержке механизма PMTU в неиспользуемых полях сообщения ICMP будет содержаться MTU на следующем переходе. Описываемый механизм полезен и в случаях, когда соединение устанавливается в первый раз и отправитель не имеет информации обо всех переходах в сети. Всегда желательно назначать как можно большее значение MTU, так как это позволит повысить производительность. В этом случае потребуется отправлять меньшее количество пакетов и, следовательно, накладные расходы сократятся.
Маршрутизаторы серии Cisco 7000 и Cisco 4000 поддерживают передачу дейтаграмм IP между интерфейсами Ethernet и FDDI. При этом в случае передачи дейтаграмм из сети FDDI в сеть Ethernet без использования механизма PMTU пакеты FDDI с объемом данных более 1500 байт будут фрагментированы
в несколько пакетов для сети Ethernet, что приведет к снижению производительности. Если в сети превалирует объем трафика из сети FDDI, то можно либо пойти на уменьшение размера MTU на устройствах в сети FDDI, либо включить на них поддержку механизма PMTU.
Пропускная способность и задержка используются некоторыми процессами в маршрутизаторе, которые требуют фиксированных значений этих параметров. Следует отметить, что данные параметры не влияют на реальную скорость интерфейса. Дополнительно в результате работы команды show interface можно узнать значение параметра надежности rely (reliability), показывающее, насколько стабильна и надежна работа интерфейса — значение 255 указывает на 100% надежность.
Если для интерфейса был указан адрес протокола liP, то информация о нем также выдается на экран (в предыдущем примере для интерфейса SerialO адрес назначен не был — в данном случае адрес был назначен для подинтерфейса). Кстати, если посмотреть на команду, которая инициирует выдачу информации, то можно увидеть, что используются только первые символы отдельных команд (sh in s0). Это значительно упрощает работу администратора сети за счет экономии времени.
Точно так же команду show interface действует для интерфейса локальной сети Ethernet, и если посмотреть на результат, то можно узнать используемый тип инкапсуляции — в следующем примере это ARPA (Advanced Research Projects Agency). Это значит, что задействован формат кадра Ethernet II технологии Ethernet. Далее видно, что поддержка сообщений keepalive на интерфейсе EthernetO маршрутизатора Cisco 1005 не установлена, в то время как операционная система Cisco IOS ожидает каждые 10 секунд получения этих сообщений по интерфейсу SerialO.
Clscol005#sh int ethO
EthernetO is up. line protocol is up
Hardware is QUICC Ethernet, address is OOeO.le8O.5eaO (Ma 00e0.le80.5ea0) Description: connected to Moskovsky 207 LAN Internet address is 192.168.6.254/24
MTU 1500 bytes. BW 10000 Kbit. DLY 1000 usee, rely 255/255. load 1/255 Encapsulation ARPA, loopback not set. keepalive not set ARP type: ARPA. ARP Timeout 04:00:00
Last input 00:00:34. output 00:00:56. output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40. 0 drops: input queue 0/75. 0 drops
5 minute input rate 0 bits/sec. 0 packets/sec
5 minute output rate 0 bits/sec. 0 packets/sec 49748 packets input. 9071864 bytes. 0 no buffer Received 24409 broadcasts. 0 runts. 0 giants. 0 throttles 0 input errors. 0 CRC. 0 frame. 0 overrun, 0 ignored. O'abort 0 input packets with dribble condition detected 104322 packets output. 48947868 bytes. 0 underruns 43456 output errors, 0 collisions. 2 interface resets 0 babbles. 0 late collision, 5 deferred 43456 lost carrier, 0 no carrier
0 output buffer failures. 0 output buffers swapped out
Из результатов работы команды видно, что счетчики статистики интерфейса (counters) никогда не сбрасывались принудительно (Last clearing of "show Interface" counters never), В следующих строках отображаются собственно сами счетчики данного интерфейса. Основываясь на полученной статистике работы интерфейса, можно определить количество полученных и переданных пакетов, произошедших ошибок при передаче и почерпнуть другую информацию, например о числе коллизий в сети Ethernet. Небольшое число коллизий объясняется тем, что локальная сеть, подключенная к маршрутизатору, состоит всего из нескольких компьютеров, которые большую часть времени находятся в неактивном состоянии.
И хотя сведения об интерфейсах локальной сети могут быть полезными администратору, чаще всего интерес вызывает информация об интерфейсах глобальной сети. Например, если распределенная сеть включает в себя локальные сети сторонних организаций (например, партнеров компании), то администратор, опираясь па статистику работы интерфейса глобальной сети, может собирать информацию для учета и т. п. Остановимся на информации об интерфейсе, через который проходит наибольший объем трафика (подключенном к Интернету на скорости 512 Кбит/с).
Cisco2511RJ#show interfaces serial О
SerialO is up, line protocol is up
Hardware is HD64570
Internet address is 193.125.189.158/30
MTU 1500 bytes. BW 1544 Kbit, DLY 20000 usee, rely 255/255. load 1/255 Encapsulation HDLC, loopback not set. keepalive set (10 sec) Last input 00:00:07, output 00:00:05, output hang never Last clearing of "show interface" counters never
Input queue: 0/75/14 (size/max/drops): Total output drops: 0■
Queueing strategy: weighted fair
Output queue: 0/64/0 (size/threshold/drops)
Conversations 0/15 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec. 0 packets/sec
5 minute output rate 0 bits/sec. 0 packets/sec
3454178 packets input, 1999455824 bytes. 14 no buffer
Received 91212 broadcasts, 0 runts. 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun. 0 ignored. 0 abort 4962814 packets output. 395288471 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
, DCD-up DSR-up DTR=up RTS=up CTS=up
Интерфейс имеет свой собственный адрес сетевого уровня, так как он обслуживает выделенный канал связи и к нему подключен модем для физических линий (модель RAD ASMi-50). Из полученной информации можно узнать используемый тип инкапсуляции — HDLC (High-level Data Link Control), что отличается от инкапсуляции, используемой для интерфейса локальной сети (Encapsulation ARPA) и для интерфейсов, подключенных к сети Frame Relay (Encapsulation
FRAME-RELAY). Исследуемый интерфейс не имеет своего собственного МАС- адреса, а пропускная способность интерфейса составляет 1 544 Кбит/с (или 1,5 Мбит/с), что соответствует пропускной способности канала Т-1.
Инкапсуляция HDLC принята по умолчанию для всех синхронных интерфейсов’маршрутизаторов компании Cisco Systems. Но администратор волен выбирать тФп инкапсуляции для выделенных каналов связи на свое усмотрение. Например, yDLC можно заместить протоколом РРР,, хотя если выполняется подключение к Интернету, то данный вопрос, следует согласовать с интернет-провайдером.
ИЗ ОПЫТА-:--
Автор на опыте столкнулся с ситуацией, когда самым простым техническим решением была смена инкапсуляции с РРР на HDLC. Маршрутизатор Cisco 2511RJ обслуживал внешних пользователей, попадающих в сеть через модем. В качестве протокола канального уровня работал РРР. Для авторизации на маршрутизаторе был настроен протокол TACACS+ в сочетании с внешним сервером с базой данных пользовательских имен и паролей. Однако после настройки маршрутизатора на работу с протоколом авторизации синхронный интерфейс, подключенный к Интернету, переходил в состояние Down. Это было вызвано тем, что операционная система также пыталась провести авторизацию маршрутизатора провайдера, рассматривая его как одного из удаленных пользователей, работающего по протоколу РРР.
Из информации об интерфейсе, которая выводится командой show interfaces, видно также, что включена поддержка сообщений keepalive. Это означает, что рассматриваемый маршрутизатор будет ожидать получения таких сообщений от маршрутизатора провайдера каждые 10 секунд. Команда show interface выдает достаточно большой объем информации, и если нужны лишь ключевые данные о работе интерфейса, можно выполнить команду show ip interface с параметром brief. В результате получим статус всех интерфейсов в виде нескольких строк.
Рассмотрим пример, в котором эта команда была выполнена на маршрутизаторе Cisco 1601, подключенном к локальной сети, к сети Frame Relay и к выделенному каналу связи. Маршрутизатор имеет один интерфейс локальной сети (EthernetO) и два интерфейса глобальной сети (SerialO и Seriall). Интерфейсы Seriall.x являются подинтерфейсами, настроенными на интерфейсе Seriall.
Ciscol601#show ip Interface brief
Interface
IP-Address
OK?
Method
Status
Protocol
EthernetO
192.168.4.254
YES
NVRAM
up
up
SerialO
192.168.4.254
YES
unset
up
up
Seriall
unassigned
YES
unset
up
up
Seri al 1.1
192.168.4.254
YES
unset
up
Up
Seri al 1.2
192.168.4.254
YES
unset
up
up
Seri al 1.3
192.168.4.254-
YES
unset
up
Up
ИЗ ОПЫТА —
Пожалуй, наиболее часто обращаются именно к статистике трафика через интерфейс глобальной сети, в частности через интерфейс, подключенный к Интернету. При использовании выделенного канала связи с провайдером последний чаще всего взимает дань за полученную из Интернета информацию (скажем, за каждый входящий гигабайт). Опираясь на полученную статистику, администратор приобретает в свое распоряжение механизм, позволяющий соотносить объем информации с ее денежным эквивалентом.
Терминальные порты
Компоненты маршрутизатора (как логические, так и физические), которые позволяют осуществить доступ к интерфейсу командной строки маршрутизатора и вводить команды, обобщенно можно назвать терминальными портами (terming lines). Выделяют четыре типа терминальных портов, часть из которых уже была рассмотрена: консольный порт (CTY/CON), порт AUX, асинхронные (TTY) и виртуальные (VTY) порты.
Если консольный порт предполагает наличие физического доступа к маршрутизатору, то в случае, когда маршрутизатор уже настроен и работает на удаленном объекте распределенной сети, можно выполнять необходимые настройки (добавляя новые или изменяя старые) с помощью установления сеанса Telnet. Все, что для этого требуется, — это указать любой IP-адрес маршрутизатору После этого маршрутизатор «попросит» ввести имя и пароль или немедленно войдет в пользовательский режим.
Следует отметить, что по умолчанию в целях повышения безопасности операционная система Cisco IOS не предпринимает попытки подключения к маршрутизатору в сеансе Telnet. Для включения поддержки входящих сеансов Telnet нужно подключиться к консольному порту маршрутизатора и соответствующим образом настроить виртуальный (логический) порт (VTY). Все маршрутизаторы компании Cisco Systems поддерживают пять подобных портов, хотя не исключается и большее их количество, если требуется поддерживать более пяти одновременных сеансов Telnet с маршрутизатором.
Самый простой способ проверки состояния терминальных портов заключается в выполнении команды show line в пользовательском или привилегированном режиме. '
CiSCO160l#show line
Tty Тур
Tx/Rx A Modem
Roty
АссО
AccI
Uses 0
Noise ' 0
Overruns 0/0
0
CTY
* 3
VTY
-
-
-
11206
0
0/0
4
VTY
-
-
-
11220
0
0/0
5
VTY
-
-
29
0
0/0
6
VTY
-
-
-
0
0
0/0
7
VTY
-
-
-
0
0
0/0
Результат работы команды представляется в виде таблицы. Первые два столбца — Tty и Тур — содержат номера портов (аналогично номеру интерфейса), отсчитываемые с нуля, и типы портов. В приведенном примере показаны только два типа терминальных портов. Если бы работали асинхронные порты, то они были бы обозначены и повлияли бы на нумерацию, как это показано в следующем примере для маршрутизатора Cisco 2511RJ, имеющего 16 асинхронных портов для подключения модемов. По результатам работы команды можно определить задействованные порты, которые отмечаются символом *. Видно, что на связи присутствуют два удаленных пользователя, подключившихся по модему, и один пользователь, работающий с маршрутизатором через сеанс Telnet (порт 18 VTY). Администратору могут быть интересны данные в столбце Noise, показывающие количество ошибок при передаче информации через порт.
C1sco2511RJ#show line
Tty Тур
Tx/Rx
А
Modem
Roty
AccO
AccI
Uses
Noise
Overruns
0 CTY
-
-
•
-
-
0
3
0/0
I 1
TTY
115200/115200
inout
-
-
-
115
39
5/0
I 2
TTY
115200/115200
-
i nout
-
-
-
99
11
3/0
*15
TTY
115200/115200
inout
-
-
-
0
0
0/0
*16
TTY
115200/115200
inout
-
-
-
0
0
0/0
17
AUX
9600/9600
-
-
-
-
0
0
0/0
*18
VTY
-
-
-
-
11165
0
0/0
19
VTY
-
-
-
-
-
82
0
0/0
20
VTY
-
-
-
-
70
0/0
21
VTY
-
-
-
-
00
0/0
22
VTY
-
-
-
-
-
00
0/0
Подробную информацию о каком-либо конкретном порте можно получить при помощи команды show line, указав номер порта в качестве параметра:
Cisco2511RJ#show line 2
Tty ТурTx/RxA ModemRotyAccOAccIUsesNoiseOverruns
I 2 TTY115200/115200- inout-- ’-99113/0
Line 2. Location: "connected to Internet Users - 16". Type: ""
Length: 24 lines. Width: 80 columns
Baud rate (TX/RX) is 115200/115200. no parity. 1 stopbits. 8 databits
В том случае, когда необходимо получить информацию о том, кто именно задействовал тот или иной порт, можно выполнить команду show user. В приведенном ниже примере эта команда отработала для маршрутизатора Cisco 2155RJ, и по ее результатам видно, что подключены два пользователя. При этом один пользователь (xuserl) подключен к асинхронному порту, а второй (kulgin) через сеанс Telnet:
Cisco2511RJ_0NE#show users
Line User
Host(s)
Idle Location
7 tty 7 xuserl Async interface
0 connected to Internet Users - 16
9 tty 9
Modem Autoconfigure
0 connected to Internet Users - 16
10 tty 10
Modem Autoconfigure
0 connected to Internet Users - 16
11 tty 11
Modem Autoconfigure
0 connected to Internet Users - 16
12 tty 12
Modem Autoconfigure
0 connected to Internet Users - 16
13 tty 13
Modem Autoconfigure
0 connected to Internet Users - 16
14 tty 14
Modem Autoconfigure
0 connected to Internet Users - 16
15 tty 15
Modem Autoconfigure
0 connected to Internet Users - 16
16 tty 16
Modem Autoconfigure
0 connected to Internet Users - 16
*8 vty 0 kulgin idle
0 proxy.alternativa.spb.ru
Команда show users показывает также (если это возможно) место (location), откуда выполнялось подключение. Для виртуальных портов VTY это может быть отмечено либо IP-адресом, либо именем хоста, с которого был инициирован сеанс Telnet. Как видно из предыдущего примера, пользователь kulgin подключился к маршрутизатору с хоста proxy.alternativa.spb.ru, хотя на самом деле
это не совсем соответствует действительности, В реальности компьютер, с которого инициировался сеанс Telnet, располагался за прокси-сервером (proxy server), в результате чего работа с маршрутизатором велась с использованием адреса и от имени последнего.
Проверка аппаратных ресурсов маршрутизатора
Рассмотрим команды, которые можно использовать для проверки состояния операционной системы Cisco IOS на маршрутизаторе. Выполняемая в пользовательском и в привилегированном режимах команда show processes epu позволяет понять, насколько занят процессор маршрутизатора и какие именно процессы операционной системы Cisco IOS выполняются в данный момент.
Стsco!005#show processes epu
CPU utilization
for five seconds:
12$/10$;
one minute: 24$;
five minutes: 25$
PIDRuntime(ms)
Invoked uSecs
5Sec
lMln5Min
TTY Process
1 41144
1170530 35
0.00$
0.00$0.00$
0 Load Meter
2 272
515333
1.55$
0.21$0.04$
1 Virtual Exec
3 119196568
1052518 113249
0.00$
2.42$2.12$
0 Check heaps
В первых строках показана средняя загруженность процессора за три последних интервала времени: 5 секунд, 1 минуту и 5 минут. При этом результат, соответствующий пятисекундной загрузке, содержит два числа в процентах, разделенных наклонной чертой. Первое число (12%) обозначает среднюю загрузку процессора в течение этого временного интервала, а второе число (10%) показывает долю времени процессора, затраченную на обслуживание прерываний, например прерываний на обработку поступающих пакетов. В следующих строках отображена информация обо всех активных в настоящее время процессах. При этом выводится идентификатор процесса (Process ID — PID), его имя и некоторая статистика. В приведенном примере результаты работы команды представлены в сокращенном виде, так как на маршрутизаторе может быть запущено множество процессов одновременно.
Память в маршрутизаторе, является, пожалуй, наиболее ценным ресурсом. Операционная система предоставляет в распоряжение администратора две команды для просмотра состояния памяти, которые можно выполнять в пользовательском или привилегированном режиме. Следующий пример показывает работу первой из этих двух команд — show process memory.
Ciscol005#show processes memory
Total: 1550152. Used: 816588, Free: 733564
PIDTTY
Allocated
Freed
Holding
Getbufs
Retbufs
Process
0
0
154356
1236
718924
0
0
*Init*
0
0
236
38352
236
0
0
*Sched*
0
0
869276
175864
464
277180
55040
*Dead*
Из первой строки листинга можно получить очень важную информацию о памяти маршрутизатора. А именно наличный объем памяти на маршрутизаторе — Total: 1550152, сколько ее задействовано — Used: 816588 и сколько свободно — Free: 733564. Тот объем памяти, который занимают работающие процессы, можно узнать из столбца Holding. Если с течением времени наблюдается постепенное снижение объема доступной памяти, то можно проверить, какой именно процесс виновен в этой тенденции. Обычно подобные проблемы решаются при обновлении версии операционной системы Cisco IOS. Для получения детальной статистики по использованию памяти предусмотрена команда show memory, которая имеет множество параметров, конкретизирующих результаты ее выполнения:
Cisco2511RJ#show memory ?
<0-4294967294> allocating-process dead
failures
fast free
Dump memory starting at <address: Show allocating process name Memory owned by dead processes Memory failures
Fast memory stats
Free memory stats
Фрагмент результирующего вывода при выполнении команды без параметров приведен ниже. Видно, что результат содержит информацию о распределении памяти для процессора и памяти для процессов ввода/вывода (I/O). Вообще говоря, информация об этих компонентах может быть достаточно подробна, а результат выполнения данной команды может включать в себя сотни строк.
Cisco2511RJ#show memory
Lowest(b) Largest(b)4879725212001511048 ■ 1638128Lowest(b) Largest(b)4879725212001511048 ■ 1638128HeadTotal(b)Used(b)Free(b)
Lowest(b) Largest(b)
487972521200
1511048 ■ 1638128
Lowest(b) Largest(b)
487972521200
1511048 ■ 1638128
Processor489AC17956681246792548876
I/O20000020971524588321638320
Таблицы, буферы и журналы маршрутизатора
Операционная система Cisco IOS имеет множество типов буферов (buffers). Наибольший интерес для администратора сети могут представить буферы сетевых пакетов (network packet buffers). Существуют шесть типов буферов сетевых пакетов, каждый из которых имеет свой собственный размер. Анализ данных буферов может дать ключевую информацию для решения некоторых проблем, например проблем, связанных с потерей или отбрасыванием пакетов. Для проверки буферов служит команда show buffers, выполняемая как в пользовательском, так и в привилегированном режиме.
Каждый буфер сетевых пакетов содержит пакеты, которые обрабатываются операционной системой. Когда пакет поступает на интерфейс маршрутизатора, из подходящего пула (pool) буферов выделяется буфер, и в него помещается пакет. Выбор пула буферов осуществляется на основе размера поступившего пакета,
при этом действует следующее правило: пакет помещается в наименьший подходящий для него буфер. Сами буферы классифицируются по размеру: небольшой (small), средний (middle), большой (big), очень большой (very big), огромный (large) и гигантский (huge). Например, при получении маршрутизатором пакета размером 500 байт операционная система выделит для этого пакета средний буфер (600 байт).
Cisco2511RJ>show buffers
Buffer elements:
499 in free list (500 max allowed) 10097407 hits, 0 misses. 0 created Public buffer pools;
Small buffers. 104 bytes (total 50, permanent 50):
50 in free list (20 min. 150 max allowed) 125533 hits. 0 misses, 0 trims. 0 created 0 failures (0 no memory)
Middle buffers. 600 bytes (total 25. permanent 25):
23 in free list (10 min. 150 max allowed) 41771 hits. 0 misses, 0 trims. 0 created 0 failures (0 no memory)'
Big buffers, 1524 bytes (total 74, permanent 50):
73 in free list (5 min, 150 max allowed)
4794623 hits, 464 misses, 890 trims, 914 created
17 failures (0 no memory)
VeryBig buffers.'4520 bytes (total 10. permanent 10):
10 in free list (0 min. 100 max allowed)
4550 hits. 0 misses. 0 trims. 0 created 0 failures (0 no memory)
Large buffers, 5024 bytes (total 0. permanent 0): 0 in free list (0 min, 10 max allowed)
Как видно из примера выполнения команды show buffers на маршрутизаторе Cisco 2511RJ, первая строка для каждого пула буферов описывает их размер, количество буферов в пуле на данный момент и количество постоянных буферов в пуле. Последние никогда не удаляются из пула и выделяются при загрузке маршрутизатора. Рассмотрим более подробно большие буферы (big buffers), анализируя результат выполнения команды show buffers.
Число, предшествующее словам free list, указывает на количество буферов, которые в настоящее время не используются, или, иными словами, которые не содержат пакетов (73 in free list). Пул содержит 74 больших буфера, из которых доступно 73. Из этого следует, что для обработки пакетов выделен только один большой буфер. Дополнительно выдается информация о минимально и максимально возможном количестве больших буферов (5 min, 150 max allowed). Таким образом, если число больших буферов окажется меньше пяти, операционная система создаст дополнительные буферы. Максимальное количество указывает на то, что поддерживается до 150 больших буферов, которые могут потребоваться для обработки большого объема сетевого трафика. Следующие строки для больших буферов содержат различные счетчики, например счетчики количества попаданий в буфер, пропусков и т. п.
Интересен счетчик, фиксирующий количество попаданий пакетов в буфер (4794623 hits), который также указывает на успешные попытки выделить буфер при необходимости разместить в нем пакет. Нужно отметить, что значение этого счетчика у данного буфера является наибольшим среди всех остальных буферов. На основании этого можно сделать вывод о распределении размеров пакетов, поступающих на маршрутизатор (в среднем 1500 байт). В свою очередь счетчик пропусков (464 misses) указывает на неуспешные попытки выделить буфер. Счетчик обновляется при нехватке доступных буферов в списке свободных. Обычно при этом создаются новые буферы, до тех пор пока не будет достигнуто максимально возможное их количество. Счетчик удаления (890 trims^ показывает количество уничтоженных буферов как неиспользуемых (то есть операционная система выделила буферы под поступающие пакеты, а затем удалила их, когда количество свободных буферов (in free list) достигло количества максимально разрешенных (max allowed)). Счетчик отказов (17 failures) указывает на количество неуспешных попыток выделения буферов из-за их занятости.
Выполняемая в пользовательском режиме команда show stacks дает информацию, которая может быть полезна для выявления причины сбоя маршрутизатора. Подробно на ней останавливаться не стоит, так как в реальной работе команда используется очень редко.'
Очевидно, что основная задача маршрутизатора заключается в принятии решения о дальнейшей обработке поступившего пакета. При этом задействуется таблица маршрутизации (routing table), которая хранится в памяти маршрутизатора и поддерживается операционной системой Cisco IOS. Подобная таблица создается и поддерживается для каждого маршрутизируемого протокола, настроенного на маршрутизаторе. Для того чтобы просмотреть таблицу маршрутизации, следует воспользоваться командой show симя протокола> route, которая требует указания имени протокола (это может быть ip, ipx, appletalk или decnet). Далее приведен результат выполнения данной команды для протокола IP.
C1sco805#show ip route
Codes: C - connected, S - static, I - IGRP. R - RIP. M - mobile. В - BGP
D - EIGRP. EX - EIGRP external. 0 - OSPF. IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 El - OSPF external type 1. E2 - OSPF external type 2. E - EGP 1 - IS-IS. LI - IS-IS level-1. L2 - IS-IS level-2, * - candidate default U - per-user static route, о - ODR. P - periodic downloaded static route T - traffic engineered route
Gateway of last resort is 192.168.101.1 to network 0.0.0.0
R 192.168.4.0/24 [120/1] via 192.168.4.254, 5d00h. SerialO
R 192.168.5.0/24 [120/2] via 192.168.4.254. 5d00h. SerialO
R 192.168.6.0/24 [120/2] via 192.168.4.254. 09:35:44. SerialO
R 192.168.1.0/24 [120/2] via 192.168.101.253, 01:10:23, EthernetO
R 192.168.2.0/24 [120/2] via 192.168.4.254. 5d00h, SerialO
S 192.168.3.0/24 [1/0] via 192.168.101.1
C 192.168.101.0/24 is directly connected. EthernetO •
S* 0.0.0.0./0 [1/0] via 192.168.101.1
Таблица маршрутизации содержит все известные маршруты в распределенной сети. Как видно из результатов работы команды show ip route, перечисляются также сокращения (строка Codes) с соответствующей им расшифровкой. При помощи сокращений отмечается источник получения информации о маршруте. Заметим, что для запроса обобщающей информации о маршрутизации для протокола IP можно воспользоваться командой show ip route summary, которая дает количественную информацию о таблице маршрутизации с указанием объема занимаемой памяти, общем количестве известных сетей и т. п.
Cisco805#show ip route summary
Route Source
Networks
Subnets
Overhead
Memory (bytes)
Connected
1
0
56
144
Static
2
0
112
288
Rip
5
0’
280
720
Total
8
0
448
1152
Самым простым способом просмотреть поддерживаемые и настроенные маршрутизируемые протоколы является выполнение в пользовательском режиме команды show protocols, которая к тому же вернет статус всех настроенных на маршрутизаторе интерфейсов.
Стsco805#show protocols■
Global values:
Internet Protocol routing is enabled■
EthernetO is up, line protocol is up
Internet address is 192.168.101.254/24■
SerialO is up. line protocol is up
Interface is unnumbered. Using address of EthernetO (192.168.101.254)
Результат работы команды можно разделить на две основные части: глобальную (Global values) и интерфейсную (EthernetO, SerialO и т. п.). Глобальная часть показывает маршрутизируемые протоколы, и ее название обусловлено тем, что эти протоколы настраиваются в глобальном режиме маршрутизатора. Маршрутизатор, на котором была выполнена эта команда, работает только с протоколом IP (Internet Protocol routing is enabled).
Интерфейсная часть содержит информацию о статусе всех доступных интерфейсов и данные по настроенным для них маршрутизируемым протоколам. С помощью команды show симя протокола> interface можно получить информацию о протоколе на определенном интерфейсе, указав в качестве параметров конкретный протокол (ip, ipx, appletalk, decnet) и интерфейс. Например, можно просмотреть информацию для интерфейса SerialO, поддерживающего выделенный канал связи (в примере приведена только часть выдаваемого результата).
Cisco805#show ip interface serial 0
SerialO is up. line protocol is up
Interface is unnumbered. Using address of EthernetO (192.168.101.254) Broadcast address is 255.255.255.255
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Ведение журнала (logging) позволяет информировать администратора сети . о происходящих системных событиях с помощью отправки сообщений в предопределенное место. По умолчанию сообщения посылаются на консольный порт маршрутизатора. В операционной системе предусмотрен специальный буфер памяти, в котором сохраняются сообщения. Однако этот буфер имеет небольшой объем, и по мере его наполнения сообщения перезаписываются, начиная с самых старых (то есть можно сказать, что буфер организован циклически). Существуют восемь уровней ведения журнала, которые нумеруются от 0 до 7. Нумерация отражает важность, или приоритет, сообщений. Таблица 1.5 содержит краткое описание уровней сообщений.
Таблица 1.5. Уровни сообщений и их описание
Номер
Имя уровня
Описание
0
Emergencies
Система в нерабочем состоянии
1
Alerts
Требуется немедленное вмешательство
2
Critical
Критические условия работы
3
Errors
Ошибки‘
4
Warnings
Предупреждения
5
Notifications
Извещения
6
Informational
Информационные сообщения
7
Debugging
Отладочные сообщения
Сообщения, которые соответствуют уровням с нулевого по шестой, всегда начинаются с символа % и содержат специальный код. Этим кодом идентифицируется соответствующий процесс. Сообщение само по себе является текстовой строкой, которая описывает происходящие и происшедшие события. Администратор может использовать временные привязки для сообщений, чтобы обеспечить их соответствие точному системному времени. Для того чтобы просмотреть содержимое буфера сообщений, предусмотрена команда show logging. Ниже приведен результат выполнения этой команды на маршрутизаторе Cisco" 2511RJ, по которому можно выяснить статистику смены состояний асинхронных портов маршрутизатора по мере подключения и отключения удаленных пользователей.
Cis.co2511RJ>show logging
Syslog logging: enabled (0 messages dropped, 0 flushes. 0 overruns)
Console logging: level debugging, 6689 messages logged .Monitor logging: level debugging, 0 messages logged
' Trap logging: level informational, 6693 message lines logged Buffer logging: level debugging, 6689 messages logged
Log Buffer (4096 bytes):
• lw5d: ШМК-3-UPDOWN: Interface Async2, changed state to down
lw5d: ^LINEPR0TD-5-UPD0WN: Line protocol on Interface Async3, changed state to down
lw5d: %LINK-5-CHANGED: Interface Async3, changed state to reset
lw5d: &LINK-3-UPDOWN: Interface Async3, changed state to down
lw5d: ^LINK-3-UPDOWN: Interface Asyncl, changed state to up
lw5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Asyncl, changed state to up
Существует возможность настроить получателей сообщений от маршрутиза-^ тора. Такими получателями могут быть: сервер Syslog (сервер, который способен принимать сообщения, посылаемые маршрутизатором по сети), консольный порт, терминал, буфер, станция управления, поддерживающая протокол SNMt\
)ВЕТ С точки зрения автора, наиболее привлекательным решением будет использование сервера Syslog, который может быть организован на компьютере, работающем под управлением операционной системы UNIX (процесс syslogd) или Microsoft Windows NJ. При' этом для получения сообщений необходимо предварительно настроить на маршрутизаторе IP-адрес этого компьютера.
Компания Cisco Systems предлагает программный комплекс CiscoWorks 2000, который включает в себя компонент Resource Manager Essentials, способный принимать сообщения Syslog для их последующего анализа. После того как администратор настроил на всех маршрутизаторах IP-адрес сервера с этим программным обеспечением, он имеет возможность получать не просто текстовые строки с информацией о событиях, а уже обработанную статистику в виде формируемых отчетов.
инхронизация по времени
Каждый маршрутизатор, произведенный компанией Cisco Systems, оснащен внутренними часами. Некоторые модели старшего класса также имеют встроенный системный календарь, питаемый от батареи. Если маршрутизатор не имеет календаря, то его часы начинают отсчет от следующей даты: 1 марта 1993 00:00. На работающем маршрутизаторе доступно несколько способов установки системных часов. Например, они могут быть установлены вручную с помощью команды, выполняемой в привилегированном режиме, или автоматически с помощью протокола NTP (Network Time Protocol) или SNTP (Simple NTP) в зависимости от модели маршрутизатора. Для проверки системного времени предназначена команда show clock, выполняемая в пользовательском режиме. Приведем пример начальной установки времени на маршрутизаторе Cisco 805. На нем нет встроенного системного календаря, поэтому первоначально при его загрузке была установлена приведенная выше дата. Символ * указывает на то, что операционная система не рассматривает установленное время как соответствующее действительности.
Cisco805>show clock
*02:36:23.743 UTC Mon Mar 1 1993
Если в распределенной сети существует необходимость поддерживать строгую синхронизацию времени на всех маршрутизаторах, то администратор может настроить протоколы NTP/SNTP па синхронизацию показаний часов с внешним источником. Процедура настройки этих протоколов выходит за рамки материала данной книги. Подробную информацию можно получить на сайте компании Cisco Systems, например, выполнив поиск по ключевым словам Time, NTP, SNTP. После указания внешнего источника времени (обычно это просто IP-адрес соответствующих серверов в Интернете) информацию о синхронизации можно получить при помощи команды show sntp.
Cisco805#show sntp
SNTP serverStratumVersionLast Receive
192.5.41.20911ld22h
192.5.41.401100:00:01 Synced
Файлы конфигурации маршрутизатора
Важной задачей администратора сети помимо настройки маршрутизатора является управление файлами конфигурации. Как уже упоминалось, рабочая конфигурация (running configuration) содержит настройки, которые являются активными в процессе работы маршрутизатора: когда на маршрутизаторе вводятся команды, они помещаются в файл рабочей конфигурации. Так как эта конфигурация содержится в оперативной памяти маршрутизатора, она удаляется при выключении последнего. В противоположность рабочей, загрузочная конфигурация (startup configuration) хранится в памяти NVRAM, и именно она считывается маршрутизатором при его загрузке. После того как маршрутизатор загрузился, все вводимые команды меняют рабочую конфигурацию, поэтому, чтобы исключить несовпадение конфигураций из-за настроек, сделанных после перезагрузки маршрутизатора, обе конфигурации следует привести к одинаковому виду. Загрузочной конфигурации может и не быть (например, на новых маршрутизаторах). В этом случае при первом включении маршрутизатор перейдет в диалоговый режим настройки (system configuration dialog). Все действия по управлению файлами конфигурации выполняются в привилегированном режиме. При этом они не отличаются от обычных операций над файлами в любой другой операционной системе — это просмотр, обновление, создание резервных копий, замена и т. п.
Выше были рассмотрены несколько вариантов использования команды show, которая показывает те или иные настройки маршрутизатора. Но в некоторых ситуациях наиболее простым способом выяснить текущую настройку маршрутизатора является просмотр файлов конфигурации. Команда show доступна в пользовательском режиме, но из-за того что конфигурационные файлы содержат много важной информации, например пароли и настройки протокола SNMP (Simple Network Management Protocol), просмотр файлов конфигурации, как
уже отмечено, возможен только в привилегированном режиме. Для просмотра рабочей конфигурации следует выполнить команду show running-config.
Cisco805#show running-config Building configuration...
Current configuration: i.
! Last configuration change at 16:58:51 GMT Thu Feb 8 2001 i■
version 12.0 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption i hostname Cisco805 i enable secret 5 $l$mlwA$zZERJF6HloTce3LgEfy.J..
В первой строке результата выводится сообщение Building configuration..., которое говорит о том, что операционная система занята сбором информации о своих настройках и подготовкой ее для представления в удобном виде. Для облегчения восприятия секции, на которые поделены выводимые данные, разделяются символом !. Листинг содержит всю информацию, необходимую для понимания будущего поведения маршрутизатора. Например, видно, что установлено имя маршрутизатора CiscoSOS, которое затем «отражается» как часть приглашения. Далее выводится пароль доступа в привилегированный режим (enable secret password), который устанавливается при начальной настройке маршрутизатора. Для снижения риска неавторизованного доступа пароль представляется в зашифрованном виде.
Загрузочная конфигурация является текстовым файлом, хранимым в памяти NVRAM. В процессе загрузки маршрутизатора операционная система просматривает память NVRAM на предмет наличия этого файла, а^затем копирует е^о неоперативную память. Для того чтобы просмотреть загрузочную конфигурацию маршрутизатора, нужно выполнить в привилегированном режиме команду show startup-config.
Cisco!005#show startup-config Using 879 out of 7506 bytes i version 11.2 service timestamps debug uptime service timestamps log uptime service password-encryption
Так как загрузочная конфигурация хранится в виде текстового файла, готового для отображения на экране, то при выполнении данной команды нет за-
держки, которая присуща команде show running-config. Первая строка результата работы команды show startup-config содержит .размер текстового файла и объем памяти NVRAM (это значение можно проверить с помощью команды show version). Если начальная настройка на новом маршрутизаторе еще не выполнялась, то память NVRAM будет пустой. В таком случае в качестве реакции па команду show startup-config администратор получит от маршрутизатора следующее сообщение:
%% Non-volatile configuration memory has not been set up or has bad checksum.
Изменения, которые администратор сети вносит в настройку маршрутизатора, фиксируются в рабочей конфигурации. Если после внесения этих изменений перезагрузить маршрутизатор, то в его память будет считана загрузочная конфигурация, что приведет к утрате всех выполненных администратором настроек. Для того чтобы не допустить потери настроек, следует скопировать рабочую конфигурацию в загрузочную с помощью команды copy running-config startup-config. В приведенном ниже примере сначала изменяется имя маршрутизатора (в рабочей конфигурации), а затем текущая рабочая конфигурация записывается как загрузочная. Это позволяет нс допустить потери изменений в имени маршрутизатора.
C1scol005(config)#hostname C1scol005_Nevsk
C1scol005_Nevsk#copy running-config startup-config
Building configuration...
[OK]
Существует только один способ заменить рабочую конфигурацию полностью, который заключается в перезагрузке маршрутизатора. Однако администратор может обновлять рабочую конфигурацию маршрутизатора вводом новых команд. Как уже не раз говорилось, эти команды вводятся как простой текст, причем для их ввода существует несколько источников, помимо использования консольного порта: терминальные порты, память NVRAM, сервер ТЕТР, флэш-память и сервер гср. Хотя источником назван сервер ТЕТР, реально при передаче команд работает одноименный протокол ТЕТР (Trivial File Transfer Protocol), позволяющий передавать файлы от сервера к клиенту без какой-либо авторизации. В основе этого протокола лежит протокол UDP, который не обеспечивает надежности пи в доставке данных, ни в средствах управления потоком трафика. Чтобы воспользоваться механизмом обновления конфигурации маршрутизатора, необходимо установить в сети сервер, поддерживающий этот протокол, а маршрутизатор будет играть роль клиента, посылающего серверу запросы па файлы.
Использование сервера гср также позволяет осуществлять передачу файлов от сервера к клиенту, однако его отличие от протокола ТЕТР заключается в том, что в данном случае в качестве транспортного протокола работает протокол TCP, обеспечивающий надежную доставку. Кроме того, при передаче требуется осуществлять аутентификацию, что повышает безопасность. Использование протокола TCP позволяет применять данный метод обновления конфигурации маршрути- .затора через сети, в которых существует вероятность возникновения перегрузок и, как следствие, удаления пакетов. Например, это может наблюдаться в сети Frame Relay при ее существенной загрузке.
Для ввода команд, воздействующих на конфигурацию маршрутизатора, следует перейти в глобальный режим посредством команды configure terminal, которая уже рассматривалась ранее в деталях. В дополнение к простому вводу команд с клавиатуры администратор сети может воспользоваться возможностями буфера обмена. Если существует текстовый файл с командами конфигурации, сохраненный на локальном диске компьютера, с которого осуществляется управление маршрутизатором, то можно просто передать его на маршрутизатор с помощью программы эмуляции терминала. Команды будут выполняться в порядке их расположения в файле.
Как уже упоминалось, память NVRAM содержит загрузочный файл конфигурации, представляющий собой текстовый файл с командами, формирующими рабочую конфигурацию. Администратор сети имеет право с помощью команды copy startup-config running-config обновить рабочую конфигурацию маршрутизатора. Данная команда была документирована в версии 11.0 операционной системы Cisco IOS, хотя и была доступна в более ранних версиях. Оригинальная команда для обновления рабочей конфигурации маршрутизатора из памяти NVRAM — configure memory.
На сервере ТЕТР могут находиться текстовые файлы, команды маршрутизатора или резервная копия рабочей конфигурации. Для обновления рабочей конфигурации с помощью протокола ТЕТР предусмотрена команда copy tftp running-config, которая предписывает маршрутизатору брать строки (команды) из текстового файла на сервере ТЕТР и помещать их в рабочую конфигурацию в порядке чтения.
Router#copy tftp running-config'
Host or network configuration file [host]? host
IP address of remote host [255.255.255.255]? 192.168.3.20
Name of configuration file [Router-config]? commands.txt
Configure using commands.txt from 192.168.3.20? [confirm] у
Loading commands.txt from 192.168.3.20 (via EthernetO): !!!!!
[OK - 2035/32723 bytes]
Router#
В процессе пошагового выполнения данной команды, как видно из примера, маршрутизатор запрашивает тип конфигурационного файла (host or network configuration file). Конфигурационный файл называется host, если он содержит команды, которые специфичны для определенного маршрутизатора.* В том случае, если файл включает в себя команды, общие для множества маршрутизаторов, он называется network. Далее по умолчанию предполагается, что имя файла состоит из имени маршрутизатора и следующего за ним слова -config. Затем маршрутизатор запрашивает адрес IP-сервера, на котором работает программное обеспечение, поддерживающее функции сервера ТЕТР. Вместо указания адреса администратор может ввести имя устройства. Тогда маршрутизатор воспользуется механизмом разрешения имен для получения адреса из имени. После подтверждения обновления маршрутизатор загружает указанный файл с сервера, отмечая успешно скопированные блоки символами I. Для того чтобы избежать ошибок в конце копирования, необходимо в конец текстового файла с команда-
ми поместить команду end, которая необходима для выхода из конфигурационного режима при окончании копирования. Команда copy tftp running-config была документирована в версии 11.0 операционной системы, а оригинальная команда обновления рабочей конфигурации с сервера TFTP носит имя configure network.
Для того чтобы обновить рабочую конфигурацию при помощи сервера гср, администратор сети может воспользоваться командой copy rep running-config., которая указывает маршрутизатору считывать строки текстового файла на сервере и помещать их в рабочую конфигурацию, так, как если бы они вводились вручную. Аналогично случаю с сервером TFTP, последней командой в текстовом файле должна быть команда end. Диалог, который ведет маршрутизатор с администратором сети, подобен диалогу в случае с сервером TFTP. Но поскольку протокол гср требует проведения аутентификации для выполнения копирования, потребуется еще несколько шагов, чтобы маршрутизатор получил доступ к файлам на сервере. Так, на маршрутизаторе необходимо задать имя пользователя, которое будет указываться при доступе, с помощью команды ip remd remote-username. Далее на сервере грс нужно создать пользователя с аналогичным именем и задать ему домашний каталог на сервере, в котором должны размещаться текстовые файлы конфигурации. После этого на сервере в домашнем каталоге пользователя следует создать файл (.rhost), содержащий строки для каждого устройства и учетной записи, которым разрешается доступ к этому каталогу. Но, вообще говоря, рекомендуется обратиться к справочной системе программного обеспечения сервера гср, так как рассмотрение деталей его настройки выходит за рамки книги.
Текстовые файлы, которые были сохранены во флэш-памяти, также подходят для обновления рабочей конфигурации. При этом источником может являться внутренняя флэш-память или память, организованная на карте PCMCIA, вставленной в одноименный слот маршрутизатора. При копировании текстового файла следует указать в команде копирования устройство и имя файла. Формат команды копирования для маршрутизаторов серии Cisco 1600 и Cisco 3600 следующий:
copy device:<HOMep раздела:> <имя файла> running-config.
Ниже приведен пример копирования файла с именем ios-upgrade-1 (filename) из четвертого раздела (partition-number) флэш-памяти в рабочую конфигурацию маршрутизатора серии Cisco 1600.
Router#copy flash:4:ios-upgrade-l running-config.
Copy 'ios-upgrade-Г from flash device
as ’startup-config' ? [yes/no] yes
[OK]
Администратор сети должен рассмотреть вопрос о создании резервных копий конфигурационных файлов маршрутизатора. При этом в его распоряжении имеется несколько получателей, которым можно направить резервную копию. Получатели соответствуют источникам, которые были рассмотрены выше, за исключением локального диска. При создании резервной копии маршрутизатор .строит конфигурацию и форматирует ее как обычный текстовый файл, который затем копируется указанному получателю. При этом все операции аналогичны операциям, связанным с обновлением конфигурации маршрутизатора.
Для того чтобы создать резервную копию рабочей конфигурации в памяти ; NVRAM, следует воспользоваться командой copy running-config startup-config, вы- ; полнение которой приводит к замене загрузочной конфигурации маршрутизатора его рабочей конфигурацией. Данная команда должна выполняться каждый раз после изменения настроек маршрутизатора, чтобы при следующей его загрузке сделанные изменения остались в силе. Эта команда была впервые документирована в версии 11.0 операционной системы Cisco IOS. Оригиналь- 1 ная команда для копирования рабочей конфигурации в память NVRAM — write : memory.
^ Для того чтобы скопировать рабочую конфигурацию в указанный файл на ; л сервер TFTP, в распоряжении администратора есть команда copy running-config ' ■ tftp. Ниже приведен пример работы команды. Эта команда была впервые доку- ;
. ментирована в версии 11.0 операционной системы Cisco IOS. Оригинальная ко- - манда для создания резервной копии рабочей конфигурации на сервере TFTP — i команда write network.:
Router#copy running-config tftp:
Remote host [192.168.3.20]?;
Name of configuration file to write[router-confg]?i
Write file router-confg on host192.168.3.20?[confirm] у■
#.
Writing router-confg!!! [OK]
В качестве сервера TFTP может служить программное обеспечение компании Cisco Systems, которое доступно через Интернет на странице загрузки http:// www.cisco.com/pcgi-bin/tablebuild.pl/tftp. Программа практически не требует никакой настройки и может быть запущена сразу после установки. Описание процедуры установки также можно найти по приведенному адресу. В процессе передачи данных между сервером и маршрутизатором в окне программы выводится информация о процессе передачи и итоговое заключение об успешности результата (рис. 1.10)
^СЬ5Г5тТР5еггеН192Л68^Г201^САРгосна1пТ&^
У® Е^ ^®w |^Ыр
|Мпп Мау 22 16 37:52 2UU0 Rerunviny "ci^colSni cenhal-conig" file from 192 168 "з.РЫ in binary
Mun May 22 16 37:52 2000 Successful
| INUM |
Рис. 1.10. Отображение работы протокола TFTP на сервере
Создание резервной копии на сервере гср выполняется по аналогии с предыдущим примером, за исключением того, что следует пользоваться командой сору running-config гср, создающей текстовый файл на указанном сервере гср. Чтобы создать копию рабочей конфигурации во флэш-памяти, для маршрутизаторов серии Cisco 1600 администратор может прибегнуть к команде copy running-config device:<номер раздела: > <имя файлах Следует отметить, что маршрутизатор не в состоянии записать информацию во флэш-память, если последняя имеет статус «только для чтения» (read-only). Просмотр статуса памяти производится командами show version или show flash.
Ciscol005#show flash
PCMCIA flash directory:
File Length Name/status
11589513 cl005-y-mz.H3-7.bin
[1589580 bytes used. 507572 available. 2097152 total]
2048K bytes of processor board PCMCIA flash (Read/Write)
Ciscol601#show flash
PCMCIA flash directory:
File Length Name/status
14061104 cl600-y-l. ИЗ-З.Т.Ып
[4061168 bytes used. 2230288 available. 6291456 total]
6144K bytes of processor board PCMCIA flash (Read ONLY)
Команды для замены загрузочной конфигурации аналогичны тем, которые используются для рабочей конфигурации. При этом необходимо заменить ключевое слово running-config на startup-config. Однако команды, которые работают с загрузочной конфигурацией, имеют одно отличие, состоящее в том, что они заменяют указанным файлом содержимое памяти NVRAM, в то время как команды, воздействующие на рабочую конфигурацию, заменяют команды в активной конфигурации маршрутизатора.
Наиболее часто администратору сети приходится замешать загрузочную конфигурацию рабочей при проведении в последней любых изменений. Для этого имеется команда, которая уже рассматривалась подробно ранее, а именно сору running-confug startup-config. Напомним, что эта команда заменяет содержимое памяти NVRAM файлом рабочей конфигурации при условии, что в этой памяти достаточно свободного места. Напомним также, что оригинальная команда операционной системы Cisco IOS для замены загрузочной конфигурации рабочей — write memory.
Чтобы заместить содержимое памяти NVRAM файлом с сервера TFTP, можно воспользоваться командой copy tftp startup-config, выполнение которой аналогично работе с сервером TFTP. Администратору сети перед ее выполнением следует узнать адрес сервера и имя файла для копирования. Операционная система маршрутизатора позволит скопировать в память NVRAM любой файл, Даже если он не содержит конфигурационных команд, хотя в последнем случае произойдет сбой при загрузке маршрутизатора. Рассматриваемая команда была впервые документирована в версии 11.0 операционной системы Cisco IOS, а ори-
гинальная команда создания копирования файла в память NVRAM — configure 1 overwrite-network.1
Иногда бывает необходимо начать конфигурацию «с нуля». Когда маршрути- ■ затор стартует без загрузочной конфигурации, его операционная система предполагает, что он не был настроен и переходит в программу пошаговой настройки ' (System Configuration Dialog). То есть, удалив загрузочную конфигурацию мар- ’ шрутизатора, можно начать заново настраивать маршрутизатор. Чтобы удалить ! содержимое памяти NVRAM, администратор сети может выполнить команду j erase startup-config. Пожалуй, наибольшее применение эта команда находит в ла- J бораторных (тестовых) условиях, когда достаточно часто требуется полностью менять конфигурацию маршрутизатора. Команда была впервые документирова- j на в версии 11.0 операционной системы Cisco IOS. Оригинальная команда для : удаления содержимого памяти NVRAM — write erase. Следует отметить, что если ; маршрутизатор настраивается с помощью программы Cisco ConfigMaker, то при : обновлении настроек маршрутизатора его старая конфигурация будет удаляться 1 автоматически.Я
Имена и заголовки|
Вопросы настройки имени маршрутизатора уже рассматривались выше, и были а выработаны некоторые общие рекомендации, смысл которых сводился к необ- 3 ходимости следовать правилам именования, указанным в документе RFC 1035. 1 По умолчанию маршрутизатору присваивается имя Router, однако его рекомен- я дуется изменить на другое, уникальное, приемлемое в распределенной сети. Для | этого можно воспользоваться командой hostname, выполняемой в глобальном 5 режиме настройки маршрутизатора. Эта команда имеет всего один параметр — . новое имя маршрутизатора.5
Router(config)#hostname NewName■;
NewName(config)#)
По умолчанию маршрутизатор будет использовать в приглашении на ввод ко- ( манд только первые 29 символов своего имени, что позволяет быстро идентифи- 1 цировать его. Следует отметить, что длинное имя маршрутизатора хотя и явля- ■; ется более информативным, но способно привести к определенным проблемам. , Это связано с тем, что общая длина приглашения не может превышать 30 символов вместе с ключевым словом, идентифицирующим текущий режим настройки. А операционная система Cisco IOS будет сокращать длину приглашения за счет ключевого слова. В итоге можно увидеть следующее приглашение:
NewName(config)#hostname NewNameOfTheRouterCiscoOS NewName0fTheRouterC1sco05(co)#'
Помимо информативного имени маршрутизатора, в распоряжении администратора есть механизм, позволяющий настроить заголовки (или баннеры, banners), которые предоставляют текстовую информацию при подключении к маршрути- . затору. Рассмотрим возможные типы заголовков: MOTD (Message of The Day), Login и Exec. Первый выдается сразу при подключении к маршрутизатору через
терминальный порт. Заголовок Login также посылается при подключении к маршрутизатору (если последний настроен), однако он следует сразу же за заголовком MOTD. Заголовок Ехес отображается после успешной авторизации пользователя.
Для того чтобы настроить эти заголовки, предусмотрена команда banner с параметрами — названиями заголовков. Команда выполняется в глобальном режиме. После параметра, указывающего тип заголовка, следует собственно текст сообщения, который будет выдаваться маршрутизатором. Текст начинается и заканчивается специальными символами, идентифицирующими начало и конец сообщения и не являющимися его частью. Сообщение может состоять из нескольких строк текста. Чтобы ввести несколько строк, необходимо после указания первого разделительного символа нажать клавишу Enter, а затем вводить текст построчно. Для завершения ввода нужно вновь ввести разделительный символ и нажать Enter.
CiSCO1601(conf1д)#banner motd %
Enter TEXT message. End with the character T.
This is the banner.
%
Ciscol601(config)#
В приведенном примере был настроен заголовок MOTD. Аналогичным образом настраиваются и другие заголовки, которые отображаются в соответствующий момент подключения или авторизации. Если маршрутизатор настраивается программой Cisco ConfigMaker, то можно воспользоваться тем, что она позволяет в диалоговом режиме настроить заголовок MOTD. После этого программа Cisco ConfigMaker добавит необходимые команды (рис. 1.11).
ониони
они
они
General j Conmction^ j Passwords ] ProtocolsJ snmpI:IP Services-1 IOS Conflation j Hardware Colouration:
DeviceDeviceName-Name-Cisco 805|cisco8053V^^^Cisco 805|cisco8053V^^^StatusDevice is ready for delivery.StatusDevice is ready for delivery.^ОСМКУК |Wharehouse W^ОСМКУК |Wharehouse W-Contact—- Contact name pTJelephone #:- ■. ЕтаВ address: | *-Contact—- Contact name pTJelephone #:- ■. ЕтаВ address: | *MOTD Barm,. phsMessag '' **-™nW1 и, -n , -,,, t appears wheMOTD Barm,. phsMessag '' **-™nW1 и, -n , -,,, t appears wheСправкеСправкеMessage Of The Day (MOTD) BannerMessage Of The Day (MOTD) BannerThe Message 01 The 0 ay [M OTO] bwiei appears *ert № topHoihe router,/\The Message 01 The 0 ay [M OTO] bwiei appears *ert № topHoihe router,/\ActionYou need to redeliver the configuration to this device since the information has changed since the last delivery.ActionYou need to redeliver the configuration to this device since the information has changed since the last delivery.Delivery Log:15 32 23 on 05/11 /00 INFO: Cisco805_Wharehouse, COM2.Console deliyery.;.> Deliyer^d successfullyDelivery Log:15 32 23 on 05/11 /00 INFO: Cisco805_Wharehouse, COM2.Console deliyery.;.> Deliyer^d successfully
Device
Device
Name-
Name-
Cisco 805
|cisco8053V^^^
Cisco 805
|cisco8053V^^^
Status
Device is ready for delivery.
Status
Device is ready for delivery.
^ОСМКУК |Wharehouse W
^ОСМКУК |Wharehouse W
-Contact—
- Contact name pT
Jelephone #:
- ■. ЕтаВ address: | *
-Contact—
- Contact name pT
Jelephone #:
- ■. ЕтаВ address: | *
MOTD Barm,. phsMessag '' **-™nW1 и, -n , -,,, t appears whe
MOTD Barm,. phsMessag '' **-™nW1 и, -n , -,,, t appears whe
Справке
Справке
Message Of The Day (MOTD) Banner
Message Of The Day (MOTD) Banner
The Message 01 The 0 ay [M OTO] bwiei appears *ert № topHoihe router,/\
The Message 01 The 0 ay [M OTO] bwiei appears *ert № topHoihe router,/\
Action
You need to redeliver the configuration to this device since the information has changed since the last delivery.
Action
You need to redeliver the configuration to this device since the information has changed since the last delivery.
Delivery Log:
15 32 23 on 05/11 /00 INFO: Cisco805_Wharehouse, COM2.
Console deliyery.;.> Deliyer^d successfully
Delivery Log:
15 32 23 on 05/11 /00 INFO: Cisco805_Wharehouse, COM2.
Console deliyery.;.> Deliyer^d successfully
Рис. 1.11. Настройка заголовка с помощью программы ConfigMaker
Обеспечение безопасности доступа к маршрутизатору
Интерфейс командной строки операционной системы Cisco IOS — это основное место, где осуществляется управление и мониторинг маршрутизатора. Без всяких сомнений, администратор сети будет ограничивать доступ к маршрутизатору. И не только для того, чтобы исключить нежелательное влияние на работу маршрутизатора, но и для защиты статистической информации. Для потенциального взломщика статистика и конфигурации, похищенные с маршрутизатора, могут много сказать о сетевой топологии, характере трафика, подключенных системах и т. п. Следовательно, контроль процесса доступа к маршрутизатору — это больше, чем просто защита устройства, это безопасность всей распределенной сети.
ИЗ ОПЫТА——
Представьте себе ситуацию, когда доступ в Интернет осуществляется по выделенному каналу связи, который заканчивается маршрутизатором. Причем защита внутренней сети обеспечивается отдельно стоящим защитным экраном. В этом случае маршрутизатор просто выполняет свою главную задачу — передачу и прием трафика Интернета. И если внутренняя сеть защищена, и этот вопрос беспокойства не вызывает, то как быть с маршрутизатором? Что мешает злоумышленникам день за днем пытаться получить доступ к маршрутизатору через Интернет — сначала в пользовательский режим, а затем и в привилегированный? Это может быть простой атакой по словарю, когда некая программа просто перебирает варианты паролей, пытаясь установить сеанс Telnet. В случае, если доступ к маршрутизатору получен, достаточно выполнить несколько команд, например стирающих конфигурации маршрутизатора, или изменить пароли на доступ. В целом безопасности сети это не угрожает, но позволит на некоторое время сделать невозможным доступ в Интернет, что не всегда приемлемо. Для защиты от подобных атак можно, например, воспользоваться списками ограничения доступа.
Операционная система Cisco IOS поддерживает множество типов паролей, которые служат для ее защиты от неавторизованного доступа. Все пароли чувствительны к регистру набираемого текста и не должны содержать более 25 символов, при этом символ пробела не может быть частью пароля.
Доступ в пользовательский режим настраивается на терминальных портах, например на консольном и виртуальном. При настройке пароля для пользовательского режима необходимо перейти в режим конфигурации портов (line configuration mode). Каждый терминальный порт может иметь свой собственный пароль, однако, как правило, для доступа требуется один и тот же пароль. Для того чтобы настроить пароль доступа к терминальному порту маршрутизатора, следует воспользоваться командами login и password. Первая команда указывает маршрутизатору на необходимость выполнения проверки паролей, а вторая непосредственно в своем параметре передает пароль доступа.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#line console 0
Router(config-lin)#password ******
Router(config-lin)#!ogin
В этом примере при переходе из глобального режима в режим настройки терминального порта настраивается пароль доступа к консольному порту маршрутизатора (параметр password). Аналогично пароль настраивается на маршрутизаторе и для виртуальных портов VTY. Как правило, для всех портов VTY указывается одинаковый пароль.
СОВЕТ
Если есть вероятность того, что пять активных сеансов Telnet, установленных с маршрутизатором другими людьми, будут препятствовать администратору получить доступ, то можно создать дополнительные порты VTY или, скажем, настроить 2дин пароль для портов с номерами 0-3 и другой пароль для порта 4, который будет задействоваться только в крайних случаях. В последнем'вйри-* анте команда line vty 4 Применима только для настройки порта 4.
При попытке установить с маршрутизатором сеанс Telnet, последний методом случайного выбора выделяет виртуальный порт VTY, вследствие чего невозможно предсказать заранее, к какому порту будет выполнено подключение. В том случае, если все виртуальные порты VTY имеют различные пароли, не исключена ситуация, когда будет неизвестно, какой именно пароль следует указывать.
СОВЕТ
Помимо локальной настройки паролей на маршрутизаторе также применяется внешний сервер авторизации, работающий, например, под управлением программы CiscoSecure ACS. Эта программа, взаимодействуя с маршрутизатором по протоколам TACACS+ или RADIUS, проверяет корректность введенных имен и паролей пользователей. Для решения задачи администратор может также воспользоваться возможностями операционной системы Microsoft Windows 2000, а именно ее компонентом Microsoft IAS (Internet Authentication Service), поддерживающим протокол RADIUS и проводящим авторизацию пользователей, введенных в службу каталогов Active Directory. Такой способ авторизации пользователей очень удобен, например, при создании модемного пула в распределенной сети, где имеются машины под управлением Windows 2000.
Напомним, что, работая в пользовательском режиме, можно только просматривать информацию о работе маршрутизатора, за исключением файлов конфигурации. Полный доступ к маршрутизатору администратор получает лишь при переходе в привилегированный режим. Как уже ранее упоминалось, существуют два пароля, которые предоставляют доступ к привилегированному режиму. Первый из них поддерживается для совместимости со старыми версиями операционной системы Cisco IOS (так называемый enable password). Его особенностью является то, что в файлах конфигурации он хранится в незашифрованном виде. Второй пароль доступа в привилегированный режим (так называемый enable secret password) всегда отображается в зашифрованном виде.
Для настройки этих двух паролей можно обратиться к двум разным командам, которые выполняются в глобальном режиме. Эти команды схожи по названию с паролями, которые они устанавливают: enable password задает незашифрованный пароль, a enable secret — зашифрованный. В обеих командах пароль Указывается в виде параметра. Важной особенностью является то, что если указывается зашифрованный пароль, он получает статус приоритетного. Если данный пароль присутствует в рабочей конфигурации маршрутизатора, он и будет основанием для входа в привилегированный режим. .
Пароль enable password используется только тогда, когда операционная система не поддерживает более надежный зашифрованный пароль или последний просто не настроен. В случае, если ни один из перечисленных паролей не был задан, после выполнения команды enable маршрутизатор не будет предлагать ввести пароль для перехода в привилегированный режим. Сказанное относится к случаю, когда доступ к маршрутизатору осуществляется через консольный порт. Если же работа с маршрутизатором производится через сеанс Telnet, то перейти в привилегированный режим будет невозможно до тех пор, пока не будет присвоен пароль консольному порту.
Очевидно, что два пароля доступа в привилегированный режим следует сделать различными, так как не имеет смысла отображать пароль в зашифрованном виде, если рядом будет существовать незашифрованная версия. При попытке сделать пароли одинаковыми операционная система выдаст предупреждающее сообщение. Но несмотря на предупреждение, одинаковые пароли будут приняты, что можно проверить путем просмотра рабочей конфигурации с помощью команды show running-config.
Router(config)#enable secret ******
Router(config)#enable password ******
The enable password you have chosen is the same as your enable secret.
This is not recommended. Re-enter the enable password.
Router(config)#
Несмотря па то что операционная система Cisco IOS позволяет шифровать все указанные пароли, по умолчанию шифруется только enable secret password. При этом используется однонаправленный (one-way) алгоритм шифрования, что означает невозможность из зашифрованного пароля получить его текстовую версию (выполнить обратное преобразование). Для того чтобы все остальные задаваемые пароли хранились в файлах конфигурации в зашифрованном виде, необходимо выполнить команду, которая указывает операционной системе на необходимость шифрования паролей. Для этого служит команда service passwordencryption, выполняемая в глобальном режиме. Для шифрования же остальных паролей используется двунаправленный алгоритм (two-way), который позволяет из зашифрованной версии получить исходный текст. Если выполнить команду show running-config, можно узнать, какой именно алгоритм шифрования (обозначаемый числом) был применен для тех или иных паролей.
Cisco805#show running-config
Building configuration...
service password-encryption
enable secret 5 $l$mlwO$zZERHd8HloTce7Lcjfy.J.
line vty 0 4■
password 7 03665D070F0956424C191G0B1E1R login
Числа, обозначающие алгоритм шифрования, имеют следующий смысл:
0 7 — пароли зашифрованы с помощью двунаправленного алгоритма;
0 5 — пароли зашифрованы с помощью однонаправленного алгоритма;
ОО — пароли будут отображаться в незашифрованном виде.
Дальнейшая настройка маршрутизатора проводится с активным использованием адресов протокола IP. По этой причине необходимо уделить внимание теории протокола IP (ему посвящена глава 2), а затем продолжить рассмотрение настройки маршрутизатора (в главе 3).
2
Настройка протокола IP
Протокол IP является базовым в корпоративных сетях. На нем, как па фундаменте, выстраивают свою работу практически все остальные сопутствующие технологии. Незнание этого протокола делает бессмысленными все дальнейшие попытки получения знаний в данной области. По означенной причине автор счел необходимым включить в книгу материал по протоколу IP, сделав акцент на практических методах его использования. Кроме того, логика изложения материала книги требует рассмотрения протокола IP именно в этой главе. Для четкого уяснения положения маршрутизаторов в распределенной сети, понимания технологии трансляции адресов, принципов работы протоколов маршрутизации и многих других технологий необходимо твердое знание механизма распределения адресного пространства в протоколе IP.
Протокол IP
Очень кратко рассмотрим основы протокола. Его описание дано в документе RFC 791. IP (Internet Protocol) является базовым протоколом всего стека ТСР/ IP — он отвечает за передачу информации по сети. Информация передается
• блоками, которые называются дейтаграммами. IP является протоколом сетевого уровня, при этом для каждой среды передачи данных, например Ethernet и ATM, определен свой способ инкапсуляции IP-дейтаграмм. Маршрутизаторы пересылают инкапсулированные дейтаграммы по различным сетям, образуя объединение IP-сетей, в пределах которого каждая рабочая станция может поддерживать связь по протоколу IP с любой другой рабочей станцией.
Услуги, предлагаемые протоколом IP, сводятся к негарантированной доставке дейтаграмм. Протокол IP не исключает потерь и дублирования дейтаграмм, доставки дейтаграмм с ошибками, а также нарушения порядка следования дейтаграмм, заданного при их отправлении.
Протокол IP выполняет фрагментацию и сборку дейтаграмм, если принятый размер кадров в рабочей сети (или участке распределенной сети) отличается от размера исходных дейтаграмм. В протоколе IP отсутствуют механизмы повышения достоверности передачи данных, управления протоколом и синхронизации,
которые обычно предоставляются в протоколах более высокого уровня. Протокол IP получает информацию для передачи от протоколов, расположенных по сравнению с ним на более высоком уровне. К этим протоколам, прежде всего, относятся протоколы TCP и UDP. После получения информации протокол IP передает дейтаграммы через распределенную сеть, используя сервисы локальных сетей. Дейтаграмма состоит из заголовка и поля данных, которое следует сразу за заголовком. Длина поля данных определяется полем «Общая длина» в заголовке. На рис. 2.1 показан формат заголовка 1Р-дейтаграммы.
Номер версии (4 бита)
Длина заголовка (4 бита)
Тип сервиса (8 битов)
Общая длина (16 битов)
Идентификатор (16 битов)
Флаги (3 бита)
Смещение фрагмента (13 битов)
Время жизни (8 битов)
Протокол (8 битов)
Контрольная сумма заголовка (16 битов)
Адрес отправителя (32 бита)
IАдрес получателя (32 бита)
• Опции (поле переменной длины) 1 Выравнивание до 32-разрядной границы
Рис. 2.1. Формат заголовка дейтаграммы протокола IP
О Поле «Номер версии» (Version) указывает на версию используемого протокола IP. В настоящее время распространена версия 4, но планируется переход к версии 6.
О Поле «Длина заголовка» (Header Lenght) определяет длину заголовка в 32-разрядных словах. Минимальный размер заголовка — 5 слов (20 байт). Следует отметить, что при увеличении объема служебной информации эта длина может быть увеличена за счет поля «Опции».
О Поле «Тип сервиса» (Type of Service) определяет способ обслуживания дейтаграммы. Протокол IP обрабатывает каждую дейтаграмму независимо от ее принадлежности к тому или иному пакету. При этом используются четыре основных механизма: установка типа сервиса, установка времени жизни, установка опций и вычисление контрольной суммы заголовка. Типом сервиса характеризуется набор услуг, которые требуются от маршрутизаторов в распределенной сети. Эти параметры должны использоваться для управления выбором реальных рабочих характеристик при передаче дейтаграмм. В некоторых случаях передача дейтаграммы осуществляется с установкой приоритета, который дает данной дейтаграмме некоторые преимущества при обработке по сравнению с остальными.
О Поле «Время жизни» (Time to live). При определенных условиях IP-дейтаграммы могут попасть в замкнутый логический контур (петлю), образованный некоторой группой маршрутизаторов. Иногда такие логические контуры существуют в течение короткого промежутка времени, но иногда они оказываются достаточно долговечными. Чтобы избавить сеть от дейтаграмм, циркулирующих в логических контурах слишком долго, протоколом IP устанавливается предельный срок пребывания дейтаграммы в сети. Он задается в поле
«Время жизни» (TTL — Time to Live). Его содержимое уменьшается на единицу при прохождении дейтаграммы через маршрутизатор; при обнулении поля TTL дейтаграмма отбрасывается.
Первоначально спецификации IP включали еще одно требование: поле TTL должно уменьшаться, по крайней мере, один раз в секунду. Поскольку поле TTL является 8-разрядным, это означает, что теоретически дейтаграмма может находиться в сети не более 4,25 минуты. На практике требование ежесекундного уменьшения поля TTL игнорируется, тем не менее в спецификациях многих протоколов следующих уровней (TCP) по-прежнему предполагается, что максимальное время жизни дейтаграммы в сети составляет лишь несколько минут.
О Поле «Идентификатор» (Identification) используется для распознавания дейтаграмм, образованных в результате фрагментации. Все части фрагментированной дейтаграммы должны иметь одинаковое значение этого поля.
О Поле «Общая длина» (Total Length) указывает общую длину дейтаграммы (заголовок и поле данных). Максимальный размер дейтаграммы может составлять 65 535 байт. В подавляющем большинстве сетей такой размер дейтаграмм не используется. По стандарту RFC 791 все устройства в сети должны быть готовы принимать дейтаграммы длиной 576 байт. Эти ограничения необходимы для передачи дейтаграмм в физических кадрах. Передача дейтаграммы в кадре называется инкапсуляцией. С точки зрения низших уровней дейтаграмма выглядит так же, как и любое другое сообщение в сети. Сетевое оборудование не работает с дейтаграммами, поэтому дейтаграмма является частью области данных кадра.
Функции фрагментации и сборки также возложены на протокол IP. Фрагментация — это разделение большой дейтаграммы на несколько отдельных частей. В большинстве локальных и глобальных сетей есть ограничения на максимальный размер единицы передаваемой информации. Эту величину называют максимальной единицей передачи (MTU — Maximum Transfer Unit). Например, в сетях Ethernet данная величина составляет 1500 байт, а в сетях FDDI — 4096 байт.
Когда маршрутизатор переправляет дейтаграмму из одной сети в другую, может оказаться, что размер дейтаграммы окажется недопустимым в новой сети. Спецификация IP предусматривает следующее решение этой проблемы: маршрутизатор может разбить дейтаграмму на мелкие фрагменты, приемлемые для выходной среды, а в пункте назначения эти фрагменты будут объединены в дейтаграмму исходного вида. Формируемые маршрутизатором фрагменты идентифицируются смещением относительно начала исходной дейтаграммы. Дейтаграмма идентифицируется по отправителю, пункту назначения, типу протокола высокого уровня и 16-разрядному полю «Идентификатор». Все это в совокупности должно образовывать уникальную комбинацию.
Следует подчеркнуть связь между полями «Время жизни» и «Идентификатор». Действительно, во избежание смешивания фрагментов двух разных дейтаграмм отправитель IP-данных обязан исключить ситуацию, когда в один пункт на-
значения по одному и тому же протоколу в течение жизненного цикла дейтаграммы будут отправлены две дейтаграммы с совпадающими идентификаторами. В связи с тем, что идентификатор 16-разрядный, а наибольшее время жизни дейтаграммы исчисляется минутами (будем считать, что оно порядка 2 минут), получаем скорость передачи — 546 дейтаграмм в секунду. При максимальном размере дейтаграммы, равном 64 Кбайт, имеем результирующую скорость около 300 Мбит/с.
Проблема эффективного использования битов идентификатора оказалась практически решенной с появлением метода MTU Discovery, позволяющего определить значения MTU на всем пути к пункту назначения.
Фрагментация и сборка производятся автоматически и не требуют от отправителя специальных действий. Каждая фрагментированная часть имеет тот же формат, что и исходная дейтаграмма. Факт фрагментации повышает вероятность потери исходной дейтаграммы, так как утрата даже одного фрагмента приводит к потере всей дейтаграммы. Сборка дейтаграммы осуществляется на месте назначения. Такой метод позволяет маршрутизировать фрагменты независимо..
О Поле «Флаги» (Flags) используется при фрагментации. Нулевое значение первого бита разрешает фрагментацию, а единичное — запрещает. Единичный второй бит указывает па последний фрагмент дейтаграммы.
О Поле «Смещение фрагмента» служит для указания смещения данных во фрагменте относительно начала исходной дейтаграммы. Чтобы получить смещение в байтах, надо умножить значение этого поля на 8. Первый фрагмент всегда имеет нулевое смещение. Поле задействуется при сборке фрагментов дейтаграммы после передачи по сетям с различными MTU.
ПРИМЕЧАНИЕ
Здесь стоит упомянуть об атаке TearDrop Fragmentation. Эта атака относится к типу DoS (глава 5) и направлена на выведение компьютера из строя (общий сбой системы или потерю взаимодействия с другими компьютерами) за счет нестандартной фрагментации дейтаграмм протокола IP. Существуют несколько вариантов этой атаки, такие как NewTear, Nestea, SynDrop и Bonk. Так, есть вариант, при котором атакующий посылает специально сформированную пару фрагментов дейтаграмм IP, которые при сборке на атакуемой системе формируют некорректный пакет протокола UDP. Причем второй фрагмент при сборке перезаписывает данные в середине заголовка UDP, содержащегося в первом фрагменте, таким образом, что результирующая дейтаграмма получается как бы незавершенной, что может, например, вызвать останов операционной системы Windows NT с исключением STOP ОхОООООООА или 0x00000019. Согласно данным компании ISS (Internet Security Systems), уязвимыми для этой атаки являются такие системы, как Windows NT, Windows 95, Linux. Компания Microsoft выпустила исправление, информацию о котором можно найти по следующему адресу (статья Q179129 «STOP ОхОООООООА or 0x00000019 Due to Modified teardrop Attack»): http://support.microsoft.eom/support/kb/articles/ql79/l/29.asp.
О Поле «Протокол» (Protocol) идентифицирует протокол верхнего уровня, которому принадлежит дейтаграмма. При поступлении дейтаграммы это поле указывает, какому приложению следует ее передать. Таблица 2.1 содержит перечень (неполный) возможных протоколов.
Таблица 2.1. Значения поля «
‘Протокол»
Значение поля
Протокол
Пояснение
0
Зарезервировано
1
ICMP
Internet Control Message Protocol, протокол управляющих сообщений
2
IGMP
Internet Group Management Protocol, протокол управления группами
4
IP
Инкапсуляция IP в IP
6
TCP
Transmission Control Protocol, протокол управления передачей
8
EGP
Exterior Gateway Protocol, протокол внешнего шлюза
17
UDP
User Datagram Protocol, протокол пользовательских дейтаграмм
88
IGRP
Interior Gateway Routing Protocol, внутренний протокол маршрутизации
89
OSPF
Open Shortest Path First, «первый кратчайший путь»
О Поле «Контрольная сумма» рассчитывается по всему заголовку. Так как некоторые поля заголовка меняют свое значение, например «Время жизни», при прохождении дейтаграммы через маршрутизаторы контрольная сумма ; проверяется и повторно рассчитывается при каждой модификации заголовка. Определение контрольной суммы заголовка обеспечивает безошибочность пе- ; редачи дейтаграммы через сеть. Перед отправкой дейтаграммы вычисляется ; контрольная сумма, которая вносится в ее заголовок. При получении дейтаграммы вычисляется ее контрольная сумма, которая сравнивается с соответ- , ствующим значением заголовке. При несовпадении дейтаграмма отбрасывается. Контрольная сумма заголовка дейтаграммы применяется и во многих других протоколах, таких как UDP, TCP, ICMP и OSPF.
О Поля «Адрес отправителя» и «Адрес получателя» (Source Address, Desti- । nation Address) имеют одинаковую длину и структуру. Поля содержат 32-раз- рядные IP-адреса отправителя и получателя дейтаграммы.
О Поле «Опции» (Options) не обязательно и обычно используется при настрой- 1 ке сети. В этом поле может быть указан точный маршрут прохождения дейта- ■ граммы в распределенной сети, данные о безопасности, различные временные отметки и т. д. Поле не имеет фиксированной длины, поэтому для выравнивания заголовка дейтаграммы ио 32-разрядной границе предусмотрено следующее поле — поле «Выравнивание» (Padding). При выравнивании поле заполняется нулями.
Классы адресов и их маски
Межсетевая схема адресации протокола IP описана в документах Др^ЭЭО и НРС^д^При разработке протоколов стека TCP/IP рассматривался целый ряд методов идентификации конечных устройств в сети. Окончательным стало решение о присвоении адреса как сети, так и устройствам в этой сети. Основными
доводами в пользу такого подхода явились: возможность задания номеров сетей и устройств в них в широком диапазоне значений и возможность реализации маршрутизации. При этом адреса должны назначаться упорядоченно, для того чтобы сделать маршрутизацию более эффективной.
В сети, построенной на базе протокола TCP/IP, конечные устройства получают уникальные адреса. Эти устройства могут быть персональными компьютерами, коммуникационными серверами, маршрутизаторами и т. д. Некоторые устройства, которые имеют несколько физических интерфейсов, например маршрутизаторы, должны иметь уникальный адрес для каждого из своих интерфейсов. Исходя из схемы адресации и возможности того, что некоторые устройства в сети будут обладать несколькими адресами, напрашивается вывод, что такая схема адресации описывает не само устройство в сети, а определенное соединение этого устройства с сетью. Это приводит к ряду неудобств. Одним из них является необходимость замены адреса устройства при перемещении его в другую сеть. Основной же недостаток в том, что для работы с устройствами, имеющими несколько подключений в распределенной сети, необходимо знать все его адреса, идентифицирующие эти подключения. Незнание хотя бы одного адреса может привести к тому, что эти устройства не получат необходимую информацию при отказе других соединений.
При стандартизации протокола, ip в сентябре 1981 №да его спецификация требовала, чтобы каждое устройство, подключенное к тети, имело уникальный 32-разрядный адрес. Этот адрес разбивается на две части. Первая часть адреса идентифицирует сеть, в которой располагается устройство. Вторая часть однозначно идентифицирует само устройство. Такая схема создает двухуровневую адресную иерархию (рис. 2.2).
1 2 3... ...30 31
| Ключ | Номер сети | Номер хоста |
Рис. 2.2. Формат IP-адреса
В последнее время поле номера сети в адресе называется сетевым префиксом. Это связано с тем, что первый квадрант каждого IP-адреса идентифицирует номер сети. Все хосты в определенной сети имеют один и тот же сетевой префикс, но при этом номера хостов обязаны быть уникальны. Аналогично, два любых хоста, расположенные в разных сетях, должны иметь различные сетевые префиксы, по при этом допускаются одинаковые номера хостов.
Для обеспечения гибкости в присвоении адресов компьютерным сетям разработчики определили, что адресное пространство протокола IP должно быть разделено на три основных различных класса — А, В и С. Каждый из этих основных классов фиксирует границу между сетевым префиксом и номером хоста в различных точках 32-разрядпого адресного пространства. На рис. 2.3 показаны форматы основных классов.
Одно из основных достоинств использования классов заключается в том, что каждый адрес содержит ключ, который идентифицирует точку, расположенную Между сетевым префиксом и номером хоста. Например, если старшие два бита адреса установлены в 1 и 0, то линия раздела пролегает между 15 и 16-м битами.
Адрес класса А
Биты 0 1 2 3......78......31
о
◄Номер сети —► ◄Номер устройства ►
Адрес класса В Биты 02 3......15 16......31
и
<Номер сетиX—Номер устройства —>
Адрес класса С Биты 03......23 24......31
110
•<Номер сети►<— Номер —►
устройства
Рис. 2.3. Основные классы IP-адресов
Недостатком этого метода является потребность изменения сетевого адреса, когда в сетях класса С число устройств становится больше 255. В этом случае возникает необходимость замены адресов класса С на адреса класса В. Изменение сетевых адресов может потребовать от администратора сети больших усилий и достаточно много времени для проведения работ по отладке. Ввиду того что существует четкая граница между классами адресов, администраторы сетей не могут заранее спланировать плавный переход изменения адресов. Вместо этого приходится достаточно жестко вмешиваться в работу сети: вводится запрет на использование некоторых сетевых адресов, производится одновременное изменение всех адресов устройств в этой сети. И только тогда сеть вновь включается в работу. Еще одним недостатком классификации адресов является значительное уменьшение числа теоретически возможных индивидуальных адресов. В текущей версии протокола IP (версия 4) общее их число может составлять 232 (4 294 967 296), так как протокол предусматривает только 32 разряда для задания адреса. Использование части битов в служебных целях уменьшает доступное количество индивидуальных адресов.
Адрес класса А предназначен для больших сетей, где количество компьютеров исчисляется тысячами. Каждый адрес класса А имеет 8-разрядный префикс сети, в котором старший бит установлен в 1, а следующие 7 бит задают номер сети. Для указания номера хоста используются оставшиеся 24 бит. В настоящее время все адреса класса А уже выделены. Сети класса А также обозначаются записью /8, так как адреса этого класса имеют 8-разрядный сетевой префикс (7 + 1 = 8).
Максимальное число сетей класса А, которые можно определить, составляет 126 (27-2). Каждая сеть этого класса поддерживает максимум 16 777 214 (224 - -2) хостов. Так как адресный блок класса А способен содержать максимум 231
(2 147 483 648) индивидуальных адресов, а в протоколе IP версии 4 под них отведено максимум 232 (4 294 967 296) адресов, то адресный диапазон класса А занимает 50% предусмотренного адресного пространства.
Адрес класса В используется в сетях среднего размера, например в сетях крупной организации. Каждая сеть класса В имеет 16-разрядный префикс сети, в котором два старших бита установлены в 1 и 0, а следующие 14 бит задают номер сети. Для указания номера хоста используются оставшиеся 16 бит. Сети класса В также обозначаются записью /16.
Максимально доступное число сетей класса В составляет 16 384 (214). Каждая сеть этого класса поддерживаетмаксимум 65 534 (216-2) хоста. Так как весь адресный блок класса В может содержать максимум 230 (1 073 741 824) индивидуальных адресов, то он занимает 25% предусмотренного адресного пространства.
Адреса класса С используются в сетях с небольшим числом компьютеров. Каждая сеть класса С имеет 24-разрядный префикс сети, в котором три старших бита установлены в 110, а следующие 21 бит используются для задания номера сети. Для задания номера хоста используются оставшиеся 8 бит. Сети класса С также обозначаются записью /24.
Предельно допустимое число сетей ,класса С составляет 2 097 152 (221Х Каждая сеть этого класса поддерживает максимум 254 (28-2) хоста. Так как весь адресный блок класса С может содержать максимум 229 (536 870 912) индивидуальных адресов, он оккупирует 12,5% предусмотренного адресного пространства.
В дополнение к этим трем наиболее популярным классам адресов существуют еще два класса. В классе D старшие четыре бита установлены в 1110. Этот класс используется для поддержки групповой передачи данных. В классе Е старшие четыре бита установлены в 1111, и этот класс является зарезервированным для экспериментальных целей.
Для удобства в технической литературе, в прикладных программах и т. д. адреса протокола IP обычно представляются как четыре десятичных числа, разделенные точками. Каждое из этих чисел представляет значение одного из четырех октетов IP-адреса. При этом один октет соответствует 8 бит адреса. Рисунок 2.4 показывает, как адрес класса В может быть представлен в точечно-десятичной нотации.
Биты 0...
10 010001000010100000001110 0100010000101000000011Рис. 2.4. Пример записи IP-адреса в точечно-десятичной нотацииРис. 2.4. Пример записи IP-адреса в точечно-десятичной нотацииТаблица 2.2 содержит диапазоны десятичных значений трех классов адресов. В этой таблице обозначение XXX представляет собой поле для указания адреса хоста.Таблица 2.2 содержит диапазоны десятичных значений трех классов адресов. В этой таблице обозначение XXX представляет собой поле для указания адреса хоста.* 14S.10.34.3 •<* 14S.10.34.3 •<
10 010001
00001010
00000011
10 010001
00001010
00000011
Рис. 2.4. Пример записи IP-адреса в точечно-десятичной нотации
Рис. 2.4. Пример записи IP-адреса в точечно-десятичной нотации
Таблица 2.2 содержит диапазоны десятичных значений трех классов адресов. В этой таблице обозначение XXX представляет собой поле для указания адреса хоста.
Таблица 2.2 содержит диапазоны десятичных значений трех классов адресов. В этой таблице обозначение XXX представляет собой поле для указания адреса хоста.
* 14S.10.34.3 •<
* 14S.10.34.3 •<
Некоторые IP-адреса зарезервированы для определенных целей и не могут присваиваться конечным устройствам в сети. В табл. 2.3 перечислены зарезервированные IP-адреса.
Таблица 2.2. Диапазоны значений адресов трех классов
Класс адреса
Диапазон значений
А
1.ХХХ.ХХХ.ХХХ-126.ХХХ.ХХХ.ХХХ
В
128.0.ХХХ.ХХХ-191.255.ХХХ.ХХХ.
С
192.0.0.ХХХ-223.255.255.ХХХ
Таблица 2.3. Зарезервированные IP-адреса
IP-адрес
Примечания
Все биты установлены в 0
Данное устройство
Номер сети
Все биты номера хоста равны 0 Данная IP-сеть
Все биты равны 0
Номер хостаУстройство в данной IP-сети
Все биты установлены в 1
Все устройства в данной IP-сети
Номер сети
Все биты номера хоста равны 1 Все устройства в указанной сети
127.0.0.1
Адрес обратной связи
В зарезервированных IP-адресах все установленные в ноль биты соответствуют либо конкретному устройству, либо определенной сети. IP-адреса, все биты которых установлены в 1, предназначены для широковещательной передачи информации. Для ссылки на всю IP-сеть в целом используется адрес с номером хоста, у которого все биты установлены в 0. Сетевой адрес класса А 127.0.0.0 зарезервирован для обратной связи и введен для тестирования взаимодействия процессов на одной машине. Когда приложение использует адрес обратной связи, стек TCP/IP возвращает эти данные приложению, ничего не посылая по сети. Следует отметить, что в сетях, построенных на базе протокола IP, запрещается присваивать устройствам IP-адреса, начинающиеся с числа 127.
Все вышесказанное о классах адресов в протоколе IP и их свойствах можно обобщить в одной таблице (табл. 2.4). Обратите внимание на формат записи адреса для соответствующего класса: N обозначает адрес сети, а Н — адрес хоста в этой сети. Как уже отмечено, класс D используется для групповой доставки информации, а Е — экспериментальный класс.
Помимо возможности направленной передачи информации определенному хосту существует широковещательная передача (broadcasting), при которой сообщения получают все хосты в указанной сети. Положениями стандарта определено, что любой адрес, состоящий из одних единиц, зарезервирован для широковещания. В протоколе IP существуют два типа широковещания: направленное ^(directed) и ограниченное (limited^. Направленное широковещание позволяет хосту^даленной сети передавать одну дейтаграмму, которая будет доставлена всем хостам в адресованной сети. Дейтаграмма с направленным широковещательным адресом может проходить через маршрутизаторы в распределенной сети, при этом исходная дейтаграмма будет доставлена всем хостам только в нужной сети, а не в промежуточных сетях.
Таблица 2.4. Классы адресов и их свойства
Класс адреса
Формат записи
Назначение
Старшие биты
Границы адресов
Количество битов в адресе сети и хоста
Максимальное количество хостов
А
N.H.H.H
Для больших организаций
0
1.0.0.0
126.0.0.0
7/24
16 777 214 (224"2)
В
N.N.H.H
Организации среднего размера
1, 0
128.1.0.0
191.254.0.0
14/16
65 543 (216-2)
С
N.N.N.H
Небольшие организации
1, 1, 0
192.0.1.0
223.255.254.0
22/8
254 (28-2)
D
-
Группы хостов
1, 1, 1, о
224.0.0.0
239.255.255.255
-
-
Е
-
Экспериментальный
1, 1, 1, 1
240.0.0.0
254.255.255.255
-
-
При направленном широковещании адрес получателя содержит корректный номер сети и номер хоста, все биты которого установлены в нули или единицы. Например, адреса 185.100.255.255 и 185.100.0.0 будут рассматриваться как адреса направленного широковещания для сети 185.100.xxx.xxx класса В. Таким образом, направленные широковещательные адреса обеспечивают мощный механизм, позволяющий удаленному устройству посылать одну IP-дейтаграмму, которая будет доставлена в режиме широковещания в указанную сеть. Для получения более подробной информации о направленном широковещании можно обратиться к документу RFC 1812.
СОВЕТ
В рекомендациях компании Cisco Systems по внедрению системы безопасности в распределенной сети предлагается отключать поддержку направленного широковещания на промежуточных маршрутизаторах. В общем случае это отключение не повлияет на работоспособность конечных устройств в сети и на их связь друг с другом. Отключение направленного широковещания может препятствовать попыткам заполнения целевой сети ненужным широковещательным трафиком, который способен помешать нормальной работе. Для отключения этого механизма следует использовать команду по ip directed-broadcast в режиме конфигурирования интерфейсов. Следующие команды отключают направленное широковещание через интерфейс EthernetO: Router(config)#int ethO
R°uter(config)#no ip directed-broadcast
Главным недостатком направленного широковещания является то, что тре- Уется знание номера целевой сети. Вторая форма широковещания, называемая ограниченной, обеспечивает широковещательную передачу для сети отправителя независимо от указанного IP-адреса. Дейтаграмма с ограниченным широко- яещательным адресом никогда не сможет пройти через маршрутизаторы — последние не пропустят ее дальше себя в остальные части распределенной сети.
При ограниченном широковещании биты номера сети и номера хоста состоят i из одних нулей или единиц. Таким образом, дейтаграмма с адресом получателя • 255.255.255.255 или 0.0.0.0 будет рассматриваться как дейтаграмма с ограниченным широковещанием.
Прежде чем использовать в сети (подключенной к Интернету) протоколы сте-' ка TCP/IP, необходимо получить один или несколько официальных сетевых адресов. Все адреса присваивает одна организация — Internet Network Information Centre (InterNIC), что обеспечивает их уникальность. До апреля 1993 года назначением IP-адресов занималась организация Network Information Center (NIC).: В настоящее время эта организация выполняет запросы только для сетей Defense Data Network (DDN), иначе говоря для военных целей. Организация InterNIC назначает только сетевую часть адреса, или сетевой префикс, оставляя ответственность за определение номеров хостов в этой сети самой организации, запросившей адрес. .
Подсети
В 1985 году документом RFC 950 был определен стандартный процесс поддержки формирования подсетей, или разделения единственного номера сети классов А, В и С на составные части. Формирование подсетей было введено для преодоления следующих проблем:'■
О резкого роста размера и количества таблиц маршрутизации в Интернете;
О появления дефицита номеров сетей при необходимости расширения их количества.■
Обе эти проблемы решались путем добавления еще одного уровня иерархии к адресной структуре протокола IP. На рис. 2.5 представлен процесс формирова-j ния подсетей, в котором номер хоста делится на две части: номер подсети и номер хоста в этой подсети.
Двухуровневая иерархия
Рис. 2.5. Формирование подсетей
Формирование подсетей решает проблему роста таблиц маршрутизации, так как конфигурация подсетей корпоративной сети никогда не видна за пределами организации. Маршруты из Интернета в любую подсеть данного IP-адреса одинаковы, независимо от того, на какой подсети расположен получатель. Это стало возможным потому, что все подсети данного номера сети используют один и тот же сетевой префикс, но с разными номерами подсетей. Маршрутизаторам в част-
г
ной сети требуется различать отдельные подсети, а у маршрутизаторов в Интернете все эти подсети определены единственной записью в таблицах маршрутизации. Это позволяет администратору частной сети вносить любые изменения в логическую структуру сети без влияния на размер таблиц маршрутизации у маршрутизаторов в Интернете.
Формирование подсетей также обеспечивает решение второй проблемы, связанной с выделением организации нового сетевого номера или номеров при ее росте. Организации можно выделить один номер сети, после чего администратор получает право произвольно присваивать номера подсетей каждой из своих внутренних сетей. Это позволяет внедрять дополнительные подсети без необходимости получения нового сетевого номера.
На рис. 2.6 показан пример распределенной сети, состоящей из нескольких логических сетей, которые используют концепцию подсетей внутри одного адреса класса В. Граничный маршрутизатор получает весь трафик, адресованный сети 130.5.0.0 из Интернета, и передает его внутренним подсетям, основываясь на информации, содержащейся в третьем октете.
Частная сеть организации
130.5.0.0
Рис. 2.6. Введение подсетей в организации
Формирование подсетей внутри частной сети организации дает следующие преимущества:
О размер глобальных таблиц маршрутизации в Интернете не растет, так как администратор частной сети не нуждается в получении дополнительной адресной информации;
О администратор получает возможность по своему усмотрению внедрять дополнительные подсети без запроса новых номеров сетей;
О изменение топологии частной сети не влияет на таблицы маршрутизации в Интернете, поскольку маршрутизаторы в Интернете не имеют маршрутов в индивидуальные подсети организации — они могут направить данные только в родительскую сеть.
Маска подсети
Если маршрутизаторам в Интернете достаточно для передачи трафика в окружение подсетей только сетевого префикса адреса получателя, то маршрутизаторы внутри этого окружения для передачи трафика индивидуальным подсетям
используют расширенный сетевой префикс. Расширенный сетевой префикс со- ; стоит из префикса сети и номера подсети (рис. 2.7).
Расширенный сетевой префикс ►
: Префикс сети
Номер подсети :
Номер хоста
Рис. 2.7. Расширенный сетевой префикс1
Структуру расширенного сетевого префикса можно представить в виде мае- 1 ки подсети (subnet mask). Маска подсети — это число, двоичная запись которого 1 содержит единицы в тех разрядах, которые должны интерпретироваться как = номер сети. Маска подсети позволяет провести четкую границу между двумя j составляющими IP-адреса. Одна часть идентифицирует номер подсети, вторая J используется для идентификации хостов в этой подсети.i
Хосты и маршрутизаторы используют старшие биты IP-адреса для определе- 1 ния его класса. После того как класс определен, хост может легко найти границу между битами, идентифицирующими номер сети и номер хоста в этой сети. Однако для определения границ битов, указывающих на номер подсети, такая ’ схема не подходит. Для решения этого вопроса используется 32-разрядная мае- ‘ ка подсети, которая помогает однозначно определить требуемую границу. Для ' стандартных классов сетей маски имеют следующие значения:
О 255.0.0.0 — маска для сети класса A;j
О 255.255.0.0 — маска для сети класса В;
О 255.255.255.0 — маска для сети класса С.
Например, пусть адрес класса В 130.5.0.0 и сетевой администратор хочет ис- » пользовать весь третий октет для номера подсети, тогда ему необходимо указать маску подсети 255.255.255.0. Биты в маске подсети задают способ интерпрета- | ции битов адреса: если бит в маске подсети равен 1, то система, проверяющая j адрес, должна рассматривать соответствующий бит в IP-адресе как часть расши- Д репного сетевого префикса. Другими словами, после определения класса IP-ад- 1 реса любой бит в части номера хоста, которому соответствует единичный бит । в маске подсети, принимает участие в идентификации номера подсети. Оставшаяся часть номера хоста, которой соответствует нулевое значение маски подсе- | ти, используется для задания номера хоста. На рис. 2.8 показан пример IP-адре- | са класса В с соответствующей маской подсети.|
Сетевой префикс
Номер подсети
Номер хоста
IP-адрес
130.5.5.25
10000010
00000101
00000101
00011001
Маска подсети
255.255.255.0
11111111
11111111
11111111
00000000
Расширенный сетевой префикс
Рис. 2.8. Пример использования маски подсети
Все сказанное можно проиллюстрировать рисунком, из которого становится понятным механизм формирования маски подсети — происходит простое преобразование двоичной записи в десятичную (рис. 2.9).
1
28
64
32
16
1'
1'
10
)00(
0=| 128|
1
)00(
0= I 192 |
1
)00(
0=| 224|
1
100(
0=| 240 |
1
1
1000=I 248 I
1
1
1
00=| 252 |
1
1
1
L10=| 2541
1
1
1
1
=[255J
Рис. 2.9. Формирование маски подсети
В стандартах, описывающих современные протоколы маршрутизации, часто делается ссылка на длину расширенного сетевого префикса, а не на маску подсети. Данная длина эквивалентна количеству единичных битов в маске подсети. Это означает, что сетевой адрес 130.5.5.25 с маской подсети 255.255.255.0 может быть также записан как 130.5.5.25/24. Число 24 указывает на то, что в маске подсети 255.255.255.0 количество единичных битов равно 24. Такая запись является более компактной и легкой для понимания, чем запись с оформлением маски подсети в традиционной точечно-десятичной нотации. Рисунок 2.10 иллюстрирует пример записи расширенного сетевого префикса.
Сетевой префикс
Номер подсети
Номер хоста
130.5.5.25
10000010
00000101
00000101
00011001
255.255.255.0
11111111
11111111
11111111
00000000
Или эквивалентная запись:
24-разрядный расширенный сетевой префикс
Номер хоста
130.5.5.25/24
10000010
00000101
00000101
00011001
Рис. 2.10. Пример использования расширенного сетевого префикса
Следует отметить, что большинство современных протоколов маршрутизации переносят маску подсети в своих сообщениях. В то же время не существует
стандартного протокола маршрутизации, который имел бы дополнительное од-
побайтовое поле в заголовке своих сообщений, определяющее число битов в рас- 5
ширенном сетевом префиксе. Протоколы маршрутизации передают полную четы-
рехоктетную маску подсети.
Перед тем как разрабатывать сеть на базе протокола IP, сетевому администратору необходимо ответить на следующие четыре важных вопроса.
Сколько подсетей требуется организации сегодня?
Сколько подсетей может потребоваться организации в будущем?
Сколько хостов существует в наибольшей подсети организации сегодня?
Сколько хостов необходимо будет поддерживать в наибольшей подсети организации в будущем?
Первым шагом в процессе планирования является определение максимального количества требуемых подсетей. Данное значение округляется до ближайшей степени числа 2. Когда выполняется эта оценка, важно учесть будущее увеличение количества подсетей. На втором шаге проверяется факт существования достаточного количества адресов хостов в наибольшей подсети организации. И в заключение следует убедиться в том, что выделенный организации класс адреса предоставляет достаточное количество битов, необходимых для форми
рования подсетей.
Рассмотрим пример формирования подсетей в организации. Предположим,
что организация получила сеть класса С 193.1.1.0 и ей необходимо сформировать шесть подсетей. Наибольшая подсеть должна поддерживать 25 хостов. На первом шаге определяется число битов, требуемых для выделения необходи
мых шести подсетей. Округляя число 6 до ближайшей степени 2, получаем, что ■
в данном примере администратор должен определить восемь подсетей (23 = 8), то есть для выделения подсетей будут использованы три бита адреса.
Так как в данном примере выделен адрес класса С с записью расширенного сетевого префикса в виде /24, то полученный после выделения подсетей расширенный сетевой префикс будет выглядеть как /Т1 (24 + 3 = 27). Этот расширенный сетевой префикс эквивалентен маске подсети 255.255.255.224 (рис. 2.11).
Сетевой префикс
Байт для задания номеров хостов в данной сети
Байты для задания номера сети
Биты для номеров подсетей
Биты для номеров хостов
Адрес
193.1.1.0
11000001
00000001
00000001
000
00000
Маска подсети
255.255.255.0
11111111
11111111
11111111
111
00000
Или эквивалентная запись:
Адрес
193.1.1.0/27
11000001.00000001.00000001.000
00000
Рис. 2.11. Определение маски подсети в организации
Необходимо отметить, что номер подсети не обязательно должен располагаться сразу после сетевого префикса. Администратор вправе устанавливать биты в маске подсети независимо от остальной части адреса. В примере с адресом 193.1.1.0/27 третий байт маски подсети вместо (111000002) может быть, например, равен (00011Ю02). Однако на практике в большинстве случаев так не поступают.
Используемый 27-разрядный расширенный сетевой префикс оставляет 5 битов для задания номеров хостов в каждой из подсетей. Это означает, что в каждой подсети может быть выделено до 32 (25 = 32) индивидуальных адресов хостов. Но так как адреса, у которых все биты равны нулю либо единице, являются зарезервированными, то общее число адресов хостов в каждой подсети становится равным 30 (2а - 2 = 30).
Для определения какой-либо подсети администратор помещает двоичное представление ее номера (в данном примере для восьми подсетей это может быть цифра от 0 до 7) в битовое поле номера подсети. Например, для определения подсети #4 администратор просто заносит двоичное представление числа 4 (000001002) в трехбитовое поле номера подсети. Таблица 2.5 представляет все восемь возможных вариантов подсетей рассматриваемого примера.
Таблица 2.5. Возможные варианты подсетей
Точечно-десятичная нотация
Двоичное представление адреса
Базовая сеть
193.1.1.0/24
11000001.00000001.00000001.00000000
Подсеть #0
193.1.1.0/27
11000001.00000001.00000001.00200000
Подсеть #1
193.1.1.32/27
11000001.00000001.00000001.20100000
Подсеть #2
193.1.1.64/27'
11000001.00000001.00000001.01000000
Подсеть #3
193.1.1.96/27
11000001.00000001.00000001.01100000
Подсеть #4
193.1.1.128/27
11000001.00000001.00000001.10000000
Подсеть #5
193.1.1.160/27
11000001.00000001.00000001.10100000
Подсеть #6
193.1.1.192/27
11000001.00000001.00000001.11000000
Подсеть #7
193.1.1.224/27
11000001.00000001.00000001.11100000
Самым простым способом проверки корректности определения подсетей является контроль кратности всех десятичных номеров подсетей номеру подсети #1. В данном примере все номера подсетей кратны 32.
ПРИМЕЧАНИЕ
Компания Cisco Systems включила в свой программный продукт ConfigMaker v2.4 инструмент работы с адресами, называемый IP Subnet Calculator. Администратор, введя адрес и маску подсети, получает полную классификацию (рис. 2.12).
Когда схема введения подсетей была опубликована в документе RFC 950, запрещалось использование номеров подсетей, у которых все биты установлены в единицы или нули. Причиной такого ограничения является необходимость Устранения возможных проблем при работе тех протоколов маршрутизации, которые не переносят в своих служебных сообщениях ни маску подсети, ни
длину расширенного сетевого префикса. Например, если используется протокол
который некоторый немаршрутизации RIP (его первая версия обозначается как RIP-1),
который не
который не
учитывает маску подсети и длину расширенного сетевого префикса, маршруты в разные подсети с адресами 193.1.1.0/27 и 193.1.1.0/24 будут рассматриваться как идентичные. То есть без указания маски подсети маршрутизатор не делает
различий между маршрутом в одну подсеть и маршрутом во всю сеть. Похожая
проблема, но только с определением направ-Тения широковещания возникает
и в случае равенства всех битов единице. Например, один адрес 193.1.1.255 ис- •
пользуется как широковещательный для всей сети 193.1.1.0/24 и для подсети 193.1.1.224/27. Рисунок 2.13 иллюстрирует обе рассмотренные ситуации.
ИЙЙАв^
/®/e////S
ж.;< ^^"АЙта^!^^ЖЖ " Ж ЖЖ® ?4:
И/йИ/ЖЖйВЖ
Ж///1;/ /РТМ^- ф/:;®$ИЙ(
Рис. 2.12. Cisco IP Subnet Calculator
Маршруты в сети
24-разрядный расширенный сетевой префикс
Номер хоста
193.1.1.0/24
11000001
00000001
00000001
00000000
27-разрядный расширенный сетевой префикс
193.1.1.0/27
11000001
00000001
00000001.000
00000
Широковещательные адреса
24-разрядный расширенный сетевой префикс
193.1.1.0/24
11000001
00000001
00000001
11111111
27-разрядный расширенный сетевой префикс
193.1.1.224/27
11000001
00000001
00000001.111
11111
Рис. 2.13. Идентичные маршруты и широковещательные адреса
С разработкой протоколов маршрутизации, переносящих маску подсети (OSPF, IS-IS) с каждым рекламируемым маршрутом, стало возможно вопреки документу RFC 950 использовать подсети, все биты которых установлены в единицу и ноль. По этой причине производители позволяют настраивать подсети с такими номерами на портах своих маршрутизаторов. При этом нужно учитывать следующие два фактора: протоколы маршрутизации внутри корпоративной сети, относящиеся к классу IGP, должны поддерживать маску подсети или расширенный сетевой префикс; необходима поддержка номеров подсетей со всеми единичными и нулевыми битами всеми маршрутизаторами в сети. Кроме того, иногда важно учитывать номер версии программного обеспечения маршрутизатора.
В рассматриваемом примере (табл. 2.6) остается 5 бит для задания адресов хостов в каждой подсети. В результате каждая подсеть может содержать блок из 30 адресов хостов (25 - 2 = 30), которые нумеруются от 1 до 30. Для определения адреса хоста N в сети администратор помещает двоичное представление числа N в поле номера хоста. Например, для определения адреса, который необходимо присвоить хосту #28 в подсети #2, администратор просто вписывает двоичное представление 28 (111002) в пятибитовое поле подсети #2. В табл. 2.6 показаны некоторые возможные комбинации номеров хостов в подсети #2.
Таблица 2.6. Возможные варианты адресации хостов в подсети #2
Точечно-десятичная нотация
Двоичное представление
Подсеть #2
193.1.1.64/27
11000001.00000001.00000001.01000000
Хост #1
193.1.1.65/27
11000001.00000001.00000001.01000001
Хост #2
193.1.1.66/27
11000001.00000001.00000001.01000010
Хост #3
193.1.1.67/27
11000001.00000001.00000001.01000011
Хост #28193.1.1.92/27
Хост #29193.1.1.93/27
Хост #30193.1.1.93/27
Широковещательный адрес для подсети #2
11000001.00000001.00000001.01011100
11000001.00000001.00000001.01011101
11000001.00000001.00000001.01011110
193.1.1.95
11000001.00000001.00000001.01011111
Для того чтобы проверить корректность широковещательного адреса для определенной подсети, можно придерживаться следующего простого правила: во всех случаях широковещательный адрес для подсети #N на единицу меньше, чем базовый адрес для подсети #(N+1). Например, широковещательный адрес для подсети #2 (193.1.1.95) на единицу меньше базового адреса подсети #3 (193.1.1.96).
Перед передачей дейтаграммы хосту необходимо определить слежующее.
И Располагается ли получатель в той же подсети, что и отправитель?
Если существует более чем один маршрутизатор, имеющий маршрут в нужную сеть, какой маршрутизатор должен выбрать отправитель?
До введения подсетей процесс передачи выполнялся путем выделения поля’ сетевого номера из IP-адреса получателя, содержащегося в заголовке IP-дейта-; граммы, и последующего сравнения с собственным IP-адресом хоста. Если сете-; выс номера адреса отправителя и получателя совпадают, то оба располагаются ! в одной локальной сети, и дейтаграмма может быть передана напрямую. Если , номера сетей разные, то дейтаграмму необходимо посылать получателю через; маршрутизатор по умолчанию.
После введения подсетей этот процесс значительно усложнился, так как полу- i чатель может располагаться в другой подсети той же самой сети, что и получатель.. Процесс передачи в этом случае осуществляется при помощи маски подсети. То) есть применяется операция «логическое И» к IP-адресу получателя и маске подсе-' ти. Результат сравнивается с результатом выполнения той же операции, во для соб-: ственного IP-адреса хоста и той же маски подсети. Если результаты обеих операций,! идентичны, то отправитель и получатель находятся в одной подсети и дейтаграмма"' может быть послана напрямую. Если результаты различны, то получатель нахо1) дится в другой подсети. В этом случае дейтаграмма отправляется маршрутизатору. )
В табл. 2.7 и 2.8 представлены некоторые возможные (и наиболее часто ис-‘ пользуемые) варианты выделения подсетей для сетей классов В и С. j
Таблица 2.7. Возможные комбинации выделения подсетей для сети класса В
Маска подсети
Префикс
Биты для подсети
Биты для устройств
Количество подсетей
Количество устройств^
255.255.0.0
/16 ,
0
16
0 (1 сеть)
65 534J
255.255.192.0
/18
2
14
2
16382■
255.255.224.0
/19
3
13
6
8190:
255.255.240.0
/20
4
12
14
4094\
255.255.248.0
/21
5
11
30
2046|
255.255.252.0
/22
6
10
62
10221
255.255.254.0
/23
7
9
126
5101
255.255.255.0
/24
8
8
254
2541
255.255.255.128
/25
9
7
510
1261
255.255.255.192
/26
10
6
1022
621
255.255.255.224
/27
11
5
2046
30i
255.255.255.240
/28
12
4
4094
14!
255.255.255.248
/29
13
3
8190
6:■
255.255.255.252
/30
14
2
16 382
2-j
При рассмотрении примера разделения на подсети сети класса С 193.1.1.0/24, была отмечена рекомендация относительно порядка расположения битов при. выделении подсетей. В документе RFC 1219 описано основное правило, которому: желательно следовать при присвоении номеров подсетям и хостам. Номера под-,, сетей назначают таким образом, чтобы старшие биты в номере подсети устанавли- j вались первыми. Например, если поле номера подсети состоит из четырех битов, j
то первые несколько номеров подсетей должны быть следующими: 8 (10002), 4 (0 1 002), 12 (1Ю02), 2 (00102), 6 (01102) и т. д. Иными словами, единичные биты номеров подсетей рекомендуется устанавливать, начиная с крайней левой позиции. В то время как единичные биты номеров хостов рекомендуется устанавливать, начиная с крайней правой позиции (табл. 2.9).
Таблица 2.8. Возможные комбинации выделения подсетей для сети класса С
Маска подсети
Префикс
Биты для подсети
Биты для устройств
Количество подсетей
Количество устройств
255.255.255.0
/24
0
8
0 (1 сеть)
254
255.255.255.192
/26
2
6
2
62
255.255.255.224
/27
3
5
6
30
255.255.255.240
/28
4
4
14
14
255.255.255.248
/29
5
3
30
6
255.255.255.252
/30
6
2
62
2
Таблица 2.9. Пример присвоения номеров подсетей и хостов
Сетевой префиксНомер подсети
Номер хоста
1111111111111111Збит
Остальные 12 бит
Рекомендуемая схема присвоения адресов
Биты подсетей
Биты хостов
128
1000 0000. 0000 0001
1
64
0100 0000. 0000 0010
2
192
1100 0000. 0000 ООН
3
32
0010 0000. 0000 0100
4
160
1010 0000. 0000 0101
5
96
ОНО 0000. 0000 оно
6
224
1110 0000. 0000 0111
7
Если следовать этому правилу, то на границе между номером подсети и номером хоста будут существовать нулевые биты. Это позволяет менять маску подсети без изменения IP-адреса, присвоенного хосту. Необходимость в изменении маски подсети может возникнуть при расширении числа хостов в каждой подсети, с учетом того, что планируемое число возможных подсетей обычно больше необходимого в настоящий момент. В таком случае существует возможность «заимствования» под номера подсетей некоторых битов из числа зарезервированных. Достоинством описанного правила является то, что администратору Достаточно обновить маску подсети на каждом хосте и не нужно переконфигурировать IP-адреса хостов во всей организации. Изменение адресов потребует больших усилий от администратора, так как в данном случае может потребоваться перенастройка почтовых сервисов, статических таблиц маршрутизации и т. д.
В сети, которая была разбита на подсети, применимы два типа широковещательной передачи информации: направленное широковещание и ограниченное. Направленное широковещание имеет целью передачу дейтаграммы всем хостам в определенной подсети. Для посылки дейтаграммы всем хостам во всех подсетях следует использовать ограниченное широковещание с адресом 255.255.255.255. Однако необходимо учесть, что маршрутизаторы не пропускают дейтаграммы с таким адресом. Существует одно ограничение, накладываемое на направленное широковещание в средах с подсетями. Биты, ответственные за формирование номеров подсетей, обычно являются частью поля номера хоста и не могут быть все сразу установлены в нули или единицы. Например, если есть адрес класса В, в котором третий байт выделен под номера подсетей — 128.1.<Номер подсети>.<Номер хоста>, то в этом случае адрес направленного широковещания не может быть равен 128.1.255.255, 128.1.0.255, 128.1.255.0 и 128.1.0.0.>
Существуют теоретические и практические аргументы, призывающие не использовать «верхние» (все биты единичные) и «нижние» подсети (все биты нулевые) в распределенных сетях (встречается также термин «граничные подсети»). Как уже не раз отмечалось, в теории битовое поле содержит два специальных значения: все биты сброшены в ноль, что обычно означает «данный», например «данное устройство» или «данная сеть», и все биты установлены в единицу, что означает «все», например «все устройства» или «все сети». Ранние документы, регламентирующие адресацию в Интернете, рекомендовали оставлять эти значения в неприкосновенности. Это накладывало запрет на использование адреса нижней сети, состоящего только из нулей, и адреса верхней сети, составленного только из единиц. В результате программное обеспечение, обслуживающее протокол IP на сетевых устройствах, убеждалось в факте настройки пользователем адресации в обход этих правил. На практике использование таких подсетей может быть проблематичным, так как не все устройства, особенно выпущенные давно, поддерживают данного рода настройку. Для того чтобы избежать проблем, следует быть хорошо осведомленным о конкретном устройстве и выяснить, какое адресное пространство оно позволяет настроить. Маршрутизаторы фирмы Cisco Systems допускают настройку на использование рассматриваемых подсетей таким образом, что в свое распоряжение можно получить еще одну подсеть. Для того чтобы задействовать нижнюю подсеть, нужно выполнить команду ip subnet-zero в глобальном режиме конфигурации.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip subnet-zero
В том случае, если администратор сети не вводил эту команду на маршрутизаторе, попытка настроить интерфейс с адресом нижней подсети приведет к появлению сообщения об ошибке:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#no ip subnet-zero Router(config)#interface serial 1 Router(config-if)#ip address 192.168.1.2 255.255.255.224 Bad mask /27 for address 192.168.1.2
Практика выделения IP-подсетей
рассмотрим практические примеры выделения подсетей и назначения адресов устройствам в этих подсетях. Предположим, что организации для ее корпоративной сети предоставлен сетевой адрес 140.25.0.0/16 (или адрес 140.25.0.0 класса В — в существующей технической литературе автор не нашел устоявшегося определения). При этом организация планирует разделить сеть на несколько подсетей, каждая из которых должна поддерживать до 60 устройств.
На первом шаге необходимо определить число битов, требуемых для идентификации 60 устройств в подсети. Адрес конкретного устройства имеет определенное двоичное представление, и верхняя граница адресного пространства для устройств одной подсети выражается степенью числа 2. Это, в частности, означает, что невозможно выделить адресное пространство точно для 60 устройств, так как 60 нс является степенью двойки. Ближайшая сверху степень двойки — это 64 = 2°. На самом деле, к числу устройств нужно прибавить 2, поскольку адреса, содержащие только нули или только единицы, не используются для адресации отдельных устройств. Выбрав эту степень двойки, мы ввели два запасных адреса: (60 + 2 = 62) < 64. Однако, удовлетворяя существующие на сегодня потребности по числу рабочих мест, такой выбор не оставляет адресного пространства для возможного роста подсети. И хотя следующая степень двойки равна 128 (27) и число адресов устройств будет равно 27 - 2 = 126, то есть намного больше требуемого в настоящий момент, сетевому администратору следует выбрать именно это адресное пространство и получить 66 (126 - 60) дополнительных адресов для каждой подсети. Такой выбор означает, что поле адреса устройства займет 7 бит.
На втором шаге определяется маска подсети и длина расширенного сетевого префикса. Поскольку для идентификации устройств из 32-разрядного 1Р-ад- реса решено выделить 7 бит, получаем расширенный сетевой префикс /25 (32 - - 7 = 25). Такой 25-разрядный расширенный сетевой префикс может быть выражен в точечно-десятичном представлении маской подсети 255.255.255.128. Рисунок 2.14 показывает запись маски подсети и расширенного сетевого префикса.
Сетевой префикс
Номер подсети
Номер устройства
140.25.0.0/16
1001100
00011001
00000000.0
0000000
255.255.255.128
11111111
11111111
11111111.1
0000000
Или эквивалентная запись:
25-битовый расширенный сетевой префикс
Номер устройства
140.25.0.0/25
1001100
00011001
00000000.0
0000000
Рис. 2.14. Определение маски подсети и расширенного сетевого префикса
Как видим, 25-разрядный расширенный префикс предполагает выделение 9 6iwj для идентификации подсетей. Теперь можно вычислить количество идентифици-1, руемых подсетей: 29 = 512, то есть 9 бит позволяют назначить адреса 512 подсетям. Понятно, что администратор сети получает в этом случае некоторую свободу действий при определении соотношения числа идентифицируемых устройств и числа подсетей. Выделяя большее количество битов в поле идентификации устройств, администратор становится в состоянии включать в подсеть больше устройств. С другой стороны, чем меньше битов выделено для идентификации' устройств, тем больше подсетей способен создать администратор. Все зависит: от текущих требований организации.j
Выделенные 512 подсетей пронумеруем от 0 до 511. Если использовать 9 раз-' рядов для двоичного представления десятичных чисел от 0 до 511, то получим: О (000000000)2.1 (000000001)2 2 (000000010)2.3 (000000011)2, ..., 511 (111111111)^ Например, для определения подсети номер 3 (#3) сетевой администратор укла-, дывает двоичное представление числа 3 (000000011)2 в 9 битов номера подсети^ Номера подсетей для рассматриваемого примера приводятся ниже. В каждом адре-. се курсивом выделен расширенный сетевой префикс полного адреса, в то врем^, как 9-битовое представление поля номера подсети имеет полужирное выделение:
Базовая сеть:10001100.00011001.00000000.00000000 = 140.25.0.0/16
Подсеть #0:1000//00.000//001.00000000.00000000 = 140.25.0.0/25
Подсеть #1:10001100.00011001.00000000.10000000 = 140.25.0.128/25
Подсеть #2:10001100.00011001.00000001.00000000 = 140.25.1.0/25
Подсеть #3:10001100.00011001.00000001.10000000 = 140.25.1.128/25
Подсеть #4:10001100.00011001.00000010.00000000 = 140.25.2.0/25
Подсеть #5:10001100.00011001.00000010.10000000 = 140.25.2.128/25
Подсеть #6:10001100.00011001.00000011.00000000 = 140.25.3.0/25
Подсеть #7:10001100.00011001.00000011.10000000 = 140.25.3.128/25
Подсеть #3:10001100.00011001.00000100.00000000 = 140.25.4.0/25
Подсеть #9:10001100.00011001.00000100.10000000 = 140.25.4.128/25
Подсеть #510:10001100.00011001.11111111.00000000 = 140.25.255.0/25
Подсеть #511:10001100.00011001.11111111.10000000 = 140.25.255.128/25
Итак, администратор выделил 7 бит для идентификации устройств в каждой. подсети. Это означает, что каждая подсеть имеет 126 адресов для идентификации устройств. Устройства в подсети нумеруются от 1 до 126. Приведем перечень адресов устройств для подсети #3. При этом курсивом выделен расширенный сетевой префикс, а выделение жирным относится к 7-разрядному полю номера устройства:
Подсеть #3:10001100.00011001.00000001.10000000 = 140.25.1.128/25
Устройство #1:10001100.00011001.00000001.10000001 = 140.25.1.129/25
Устройство #2:10001100.00011001.00000001.10000010 = 140.25.1.130/25
Устройство #3:10001100.00011001.00000001.10000011 = 140.25.1.131/25
Устройство #4:10001100.00011001.00000001.10000100 = 140.25.1.132/25
устройство #5:10001100.00011001.00000001.10000101 = 140.25.1.133/25
Устройство #6:10001100.00011001.00000001.70000110 = 140.25.1.134/25
Устройство #62:10001100.00011001.00000001.10111110 = 140.25.1.190/25
Устройство #63:10001100.00011001.00000001.10111111 - 140.25.1.191/25
Устройство #64: 10001100.00011001.00000001.11000000 = 140.25.1.192/25
Устройство #65: 10001100.00011001.00000001.11000001 - 140.25.1.193/25
Устройство #123:10001100.00011001.00000001.11111011 = 140.25.1.251/25
Устройство #124:10001100.00011001.00000001.11111100 = 140.25.1.252/25
Устройство #125:10001100.00011001.00000001.11111101 = 140.25.1.253/25
Устройство #126:10001100.00011001.00000001.11111110 = 140.25.1.254/25
Для подсети #3 широковещательным адресом будет адрес, в котором все биты поля номера устройства установлены в единицу:'
10001100.00011001.00000001.11111111 = 140.25.1.255.
Следует отметить, что широковещательный адрес для подсети #3 ровно на единицу меньше базового адреса подсети #4 (140.25.2.0).
Рассмотрим другую ситуацию. Пусть организации назначен сетевой адрес 132.45.0.0/16. Администратору поручено сформировать 8 подсетей. Для идентификации такого количества подсетей требуется три бита. В этом случае расширенный сетевой префикс будет равен /19 (маска подсети 255.255.224.0). Приведем адреса этих подсетей в двоичном и десятичном представлениях:
Подсеть #0:10000100.00101101.00000000.00000000 = 132.45.0.0/19
Подсеть #1:10000100.00101101.00100000.00000000 = 132.45.32.0/19
Подсеть #2:10000100.00101101.01000000.00000000 = 132.45.64.0/19
Подсеть #3:10000100.00101101.01100000.00000000 = 132.45.96.0/19
Подсеть #4:10000100.00101101.10000000.00000000 = 132.45.128.0/19
Подсеть #5:10000100.00101101.10100000.00000000 = 132.45.160.0/19
Подсеть #6:10000100.00101101.11000000.00000000 = 132.45.192.0/19
Подсеть #7:10000100.00101101.11100000.00000000 = 132.45.224.0/19.
Теперь определим адреса устройств для подсети #3 (132.45.96.0/19, или 10000100.00101101.01100000.00000000):
Подсеть #3:10000100.00101101.01100000.00000000 = 132.45.96.0/19
Устройство #1:10000100.00101101.01100000.00000001 = 132.45.96.1/19
Устройство #2:10000100.00101101.01100000.00000010 = 132.45.96.2/19
Устройство #3:10000100.00101101.01100000.00000011 = 132.45.96.3/19
Устройство #8190: 10000100.00101101.01111111.11111110 = 132.45.127.254/19
Определим широковещательный адрес для подсети #3 (132.45.96.0/19):
10000100.00101101.01111111.11111111 - 132.45.127.255/19
Проделаем те же операции для сетевого адреса 200.35.1.0/24. Пусть также в каждой подсети необходимо предусмотреть адресное пространство для 20 устройств.
Требуется определить расширенный сетевой префикс. Для идентификации устройств требуется минимум пять битов. Поэтому расширенный сетевой префикс будет равен /27 (32-5=27). При этом максимальное количество устройств в каждой подсети — 30 (25-2 = 32-2=30), а максимальное число подсетей равно 8 (23).
Вот номера получившихся подсетей в двоичном и десятичном представлениях:
Подсеть #0:11001000.00100011.00000001.60000000 = 200.35.1.0/27
Подсеть #1:11001000.00100011.00000001.00100000 = 200.35.1.32/27
Подсеть #2:11001000.00100011.00000001.01000000 = 200.35.1.64/27
Подсеть #3:11001000.00100011.00000001.01100000 = 200.35.1.96/27
Подсеть #4:11001000.00100011.00000001.10000000 = 200.35.1.128/27
Подсеть #5:11001000.00100011.00000001.10100000 = 200.35.1.160/27
Подсеть #6:11001000.00100011.00000001.11000000 = 200.35.1.192/27
Подсеть #7:11001000.00100011.00000001.11100000 = 200.35.1.224/27
Приведем список адресов устройств, которые могут быть определены в подсети #6 (200.35.1.192/27):
Подсеть #6:11001000.00100011.00000001.11000000 = 200.35.1.192/27
Устройство #1:11001000.00100011.00000001.11000001 = 200.35.1.193/27
Устройство #2:11001000.00100011.00000001.11000010 = 200.35.1.194/27'
Устройство #3:11001000.00100011.00000001.11000011 = 200.35.1.195/27
Устройство #29:11001000.00100011.00000001.11011101 = 200.35.1.221/27.
Устройство #30:11001000.00100011.00000001.11011116 = 200.35.1.222/27
Широковещательный адрес для подсети 200.35.1.192/27 равен:
11001000.00100011.00000001.11011111 = 200.35.1.223/27
Маска подсети переменной длины
^окумену RFC 1009 от 1987 года сформулировал, каким образом в сетях, состоящих из нескольких подсетей,*можно использовать больше одной маски под- ’ ^ети. В ситуации, когда в распределенной IP-сети назначается' несколь^со^масок . подсетей, она рассматривается как сеть с масками подсетей переменной длины, ■ так как в этом случае расширенные сетевые префиксы в различных подсетях имеют разную длину.
СОВЕТ
Если в сети планируется использовать маску подсети переменной длины (Variable Length Subnet Mask — VLSM), следует включать в работу протоколы маршрутизации OSPF или EIGRP. Протоколы RIP и IGRP относятся к так называемым протоколам маршрутизации на основе классов (classful) и не поддерживают VLSM.
При применении протокола маршрутизации RIP первой версии (RIP-1 IP) , в сети поддерживается только одна маска подсети с каждым адресом (а точнее, ■ - с каждым номером сети), так как протокол не переносит информацию о масках t
подсетей в своих сообщениях об обновлении маршрутизации (сообщения, рассылаемые маршрутизаторами при задействовании протоколов маршрутизации, таких как RIP, IGRP и т. п.). При отсутствии данной информации протокол маршрутизации RIP-1 IP принимает простое решение, выбирая маску подсети, которая соотносится с каждым маршрутом в таблице маршрутизации.
При этом возникает вопрос: каким образом маршрутизатор, работающий по протоколу RIP-1, выбирает, какую маску необходимо сопоставить с новым маршрутом, полученным от соседнего маршрутизатора? Если в полученном маршруте номер адреса сети совпадает с номером адреса сети, присвоенным любому локальному порту маршрутизатора, то будет использоваться маска подсети порта маршрутизатора. Если же номера сетей не совпадают, то за основу будет взята классическая маска подсети.
Покажем это на примере. Предположим, что порту 1 маршрутизатора был присвоен адрес 130.24.13.1 с маской 255.255.255.0 (расширенный сетевой префикс /24), а порту 2 — адрес 200.14.13.2 с такой же маской подсети (тот же расширенный сетевой префикс). Анализируя первые биты адреса порта 1 и маску подсети, маршрутизатор определяет, что это адрес класса В, а третий байт адреса используется для задания номера подсети. Порту 2 присвоен адрес класса С без выделения подсетей. •
Если маршрутизатор получает информацию о маршруте в сеть 130.24.36.0 от соседнего маршрутизатора, он будет работать с маской подсети 255.255.255.0 (расширенный сетевой префикс /24), так как порту 1 присвоен адрес с тем же номером сети — 130.24.0.0. Маска подсети просто наследуется. Но если маршрутизатор получит от соседа информацию о маршруте в сеть 131.25.0.0, он станет использовать стандартную маску подсети 255.255.0.0, так как адрес 131.25.0.0 является адресом класса В, а этому классу соответствует маска подсети 255.255.0.0. Актуальной будет именно эта маска, так как маршрутизатор не имеет дополнительной информации о необходимой маске подсети.
Маршрутизатор, поддерживающий протокол RIP-1 IP, будет включать биты, определяющие номера подсетей, в свои сообщения об обновлении маршрутов только в том случае, если порт, через который предполагается посылать сообщения, настроен на подсеть с тем же номером сети. Если порт настроен с другим сетевым номером, то маршрутизатор станет посылать только сетевую часть адреса.
Продемонстрируем сказанное, продолжая рассмотрение предыдущего примера. Предположим, что маршрутизатор получил информацию от соседа о маршруте в сеть 130.24.36.0. Так как порт 1 настроен на адрес того же класса, то маршрутизатор предполагает, что сеть 130.24.36.0 имеет маску 255.255.255.0. Поэтому, когда наступает время рекламировать данный маршрут, маршрутизатор информирует о маршруте сеть с адресом 130.24.36.0 через свой порт 1, а также в сеть с адресом 130.24.0.0 через порт 2, то есть происходит потеря информации, содержащейся в третьем байте адреса (36).
Протокол RIP-1 IP может использовать с каждым номером сети только одну маску подсети. Возможность назначения одному адресу нескольких масок подсетей дает следующие преимущества:
^ множество масок подсетей позволяет более эффективно обходиться с выделенным организации адресным пространством;
О множество масок подсетей позволяет объединять маршруты, что значитель^ но уменьшает количество маршрутной информации внутри домена маршру. тизации организации.•
Применение маски подсети переменной длины позволяет эффективнее использовать адресное пространство протокола IP, выделенное организации. Ранее 1 единственность маски подсети ограничивала возможности организации, так как номер и размер подсети были фиксированными.
Например, предположим, что администратор намеревается настроить выде- : ленную организации сеть класса В 130.5.0.0 на использование расширенного 1 сетевого префикса /22 (табл. 2.10). Для задания номеров подсетей необходимо и достаточно 6 бит.'
Таблица 2.10. Распределение адресного пространства для префикса /22•
Адрес сети Сетевой префикс (класс В) Номер подсети Номер хоста' ]
130.5.0.0/22100000100000010100000000. 00000000~
Расширенный сетевой префикс /22 ,
Сеть класса В с расширенным сетевым префиксом /22 позволяет организовать - 64 подсети (26 = 64), каждая из которых поддерживает максимум 1022 (210- ;
- 2 = 1022) индивидуальных адреса хостов. Такой вариант может устроить ад- = министратора, если организации нужно некоторое число подсетей с большим j количеством хостов. Однако если организации не нужны подсети с числом хос- ■ тов более 30, то имея фиксированную маску подсети, администратору придется ; эксплуатировать подсети, рассчитанные па большое количество хостов, подклю* чая к ним всего нескольких пользователей. В результате невостребованными . могут оказаться около 1000 допустимых адресов хостов в подсетях. Как видно : из этих рассуждений, ограничение, полученное по причине единственной маски i подсети, отрицательно, причем существенно, влияет на эффективность исполь- , зования адресного пространства.
Основным решением данной проблемы является работа с маской подсети ne- i ременной длины. Рассмотрим другой пример. Предположим, что администратор j хочет установить расширенный сетевой префикс /26. Адрес класса В с таким * расширенным сетевым префиксом позволит поддерживать до 1024 подсетей ; (210 = 1024), каждая из которых охватывает до 62 (2° - 2 = 62) адресов хостов ; (табл. 2.11). Такой расширенный сетевой префикс идеально подходит к небольг шим подсетям с числом хостов порядка 60, в то время как префикс /22 ориенти- ) рован на большие подсети с тысячами хостов.
Адрес сетиСетевой префиксНомер подсетиНомер хоста130.5.0.0/26100000100000010100000000. ООРасширенный сетевой префикс /26000000.ААдрес сетиСетевой префиксНомер подсетиНомер хоста130.5.0.0/26100000100000010100000000. ООРасширенный сетевой префикс /26000000.АТаблица 2.11. Распределение адресного пространства дляТаблица 2.11. Распределение адресного пространства для/26/26
Адрес сети
Сетевой префиксНомер подсети
Номер хоста
130.5.0.0/26
100000100000010100000000. ОО
Расширенный сетевой префикс /26
000000
.А
Адрес сети
Сетевой префиксНомер подсети
Номер хоста
130.5.0.0/26
100000100000010100000000. ОО
Расширенный сетевой префикс /26
000000
.А
Таблица 2.11. Распределение адресного пространства для
Таблица 2.11. Распределение адресного пространства для
/26
/26
Сочетание различных расширенных сетевых префиксов — /22 и /26 — позволило получить два типа подсетей с резким отличием по числу поддерживаемых хостов. Внедрение маски подсети переменной длины позволяет администратору получать в рамках своей организации подсети с необходимыми характеристиками на нужный период времени. Это происходит следующим образом: сначала сеть делится на подсети, затем некоторые из этих подсетей делятся, в свою очередь, на подсети и т. д., то есть происходит рекурсивное дробление количества подсетей.
На рис. 2.15 показан пример, в котором сеть класса А с адресом 10.0.0.0 сначала делится на подсети с расширенным сетевым префиксом /16 (маска подсети 255.255.0.0). Общее количество получаемых подсетей — 254. В каждой подсети поддерживается до 65 534 (216 - 2 = 65 534) адресов хостов. Подсеть с адресом 10.253.0.0 при рекурсии с расширенным сетевым префиксом /24 поддерживает до 254 подсетей, каждая из которых включает в себя до 254 (28 - 2 = 254) адресов хостов. При дальнейшей рекурсии с расширенным сетевым префиксом /27 в состав подсети с адресом 10.253.1.0 войдут 6 подсетей с номерами, кратными 32, каждая из которых будет поддерживать до 30 (25 - 2 = 30) номеров хостов.
10.0,0.0 /810.0,0.0 /810.1.0.0 /1610.253.0.0 /1610.254.0.0 /1610.1.0.0 /1610.253.0.0 /1610.254.0.0 /1610.253.1.32/2710.253.1.64/2710.253.1.96/2710.253.1.128/2710.253.1.160/2710.253.1.192/2710.253.1.32/2710.253.1.64/2710.253.1.96/2710.253.1.128/2710.253.1.160/2710.253.1.192/27Рис. 2.15. Пример рекурсивного размножения адресов подсетейРис. 2.15. Пример рекурсивного размножения адресов подсетей
10.0,0.0 /8
10.0,0.0 /8
10.1.0.0 /16
10.253.0.0 /16
10.254.0.0 /16
10.1.0.0 /16
10.253.0.0 /16
10.254.0.0 /16
10.253.1.32/27
10.253.1.64/27
10.253.1.96/27
10.253.1.128/27
10.253.1.160/27
10.253.1.192/27
10.253.1.32/27
10.253.1.64/27
10.253.1.96/27
10.253.1.128/27
10.253.1.160/27
10.253.1.192/27
Рис. 2.15. Пример рекурсивного размножения адресов подсетей
Рис. 2.15. Пример рекурсивного размножения адресов подсетей
Таким образом, рекурсивное разбиение адресного пространства организации может быть выполнено с учетом пожеланий администратора сети. Кроме возможности рекурсии, внедрение маски подсети переменной длины позволяет значительно уменьшить объем таблиц маршрутизации для маршрутизаторов организации. Каждый маршрутизатор имеет возможность объединять свои подсети в одну запись в сообщении об обновлении. Поскольку структура подсетей не видна вне организации, граничный маршрутизатор рекламирует в Интернете маршрут с адресом 10.0.0.0 (рис. 2.16).
10.253.1.0/2410.253.1.0/2410.0.0.0/810.0.0.0/810.253.0.0/1610.253.0.0/1610.1.0.0/1610.1.0.0/1610.253.0.0/1610.254.0.0/1610.253.0.0/1610.254.0.0/1610.253.1.0/2410.253.1.0/2410.253.253.0/2410.254.254.0/2410.253.253.0/2410.254.254.0/24Рис. 2.16. Объединение маршрутов с помощью VLSMРис. 2.16. Объединение маршрутов с помощью VLSM10.253.1.32/2710.253.1.32/2710.253.253.160/2710.254.254.192/2710.253.253.160/2710.254.254.192/27
10.253.1.0/24
10.253.1.0/24
10.0.0.0/8
10.0.0.0/8
10.253.0.0/16
10.253.0.0/16
10.1.0.0/16
10.1.0.0/16
10.253.0.0/16
10.254.0.0/16
10.253.0.0/16
10.254.0.0/16
10.253.1.0/24
10.253.1.0/24
10.253.253.0/24
10.254.254.0/24
10.253.253.0/24
10.254.254.0/24
Рис. 2.16. Объединение маршрутов с помощью VLSM
Рис. 2.16. Объединение маршрутов с помощью VLSM
10.253.1.32/27
10.253.1.32/27
10.253.253.160/27
10.254.254.192/27
10.253.253.160/27
10.254.254.192/27
При разработке концепции подсетей, определяемых маской подсети перемен- ■ ной длины администратору необходимо убедиться в том, что в предоставляемом j организации IP-адресе свободно достаточное количество битов для формирования требуемого числа подсетей на каждом уровне рекурсии.
Предположим, что сеть организации охватывает несколько удаленных филиа-; лов. Если организация имеет три удаленных сети, то сегодня ей потребуется вы-; делить три бита для формирования подсетей, которых может хватить как сегодня,' так и в обозримом будущем (23 = 8). Но допустим, что администратор хочет i сформировать отдельные подсети внутри каждого филиала. Эти подсети будут; вторым уровнем в иерархии подсетей. Кроме того, внутри каждого филиала необходимо поддерживать отдельные рабочие группы, для которых также нужно '; выделить подсети. Следуя приведенной модели иерархии, верхний уровень опре- • деляется числом удаленных филиалов, второй — количеством зданий во владении каждого филиала, а третий — максимальным числом подсетей в каждому здании и максимальным числом хостов в каждой из подсетей. ■
Для успешного внедрения маски подсети переменной длины требуется вы-; полнить три основных условия:
О протокол маршрутизации должен переносить информацию о маске подсети; в каждом сообщении;!
О все маршрутизаторы обязаны поддерживать алгоритм передачи, основывающийся на технологии наибольшего совпадения (longest match);
О адреса должны присваиваться в соответствии с существующей топологией сети.
Современные протоколы маршрутизации, такие как OSPE и IS-IS, умеют' оперировать маской подсети переменной длины. Это достигается с помощью передачи значения маски подсети в каждом сообщении об обновлении маршрутов, что позволяет рекламировать каждую подсеть с ее маской. Если протокол марш-. рутизации не работает с масками подсети, маршрутизатор либо предполагает,.
что должна использоваться маска подсети, присвоенная его локальному порту,.; либо выполняет поиск в статически настроенной таблице, содержащей всю ин-;
формацию о масках подсетей. Первое решение не в состоянии гарантировать- выбор корректной маски подсети, а статическая таблица не имеет возможности; масштабирования, кроме того, она сложна в управлении и исправлении ошибок,,.;
Таким образом, если требуется задействовать маски подсети переменной;
длины в сложной сетевой топологии, наилучшим вариантом является применение протоколов маршрутизации OSPF и IS-IS, а не RIP-1 IP. Однако при этом
нужно учитывать, что вторая версия протокола RIP (RIP-2 IP), описанная в до
кументе RFC 1388, расширяет возможности первой версии протокола, в том числе и добавлением функциональности переноса маски подсети.
Применение маски подсети переменной длины
Рассмотрим практические примеры работы с маской подсети переменной длины. Предположим, что организации был выделен сетевой адрес 140.25.0.0/16 (IP-адрес класса В), и администратор планирует принять во внимание маски подсети
переменной длины. На рис. 2.17 изображена вероятная схема выделения адресов для подсетей этой организации.
0__1.
Рис. 2.17. Стратегия выделения подсетей
Первый шаг в процессе выделения подсетей состоит в делении основного сетевого адреса (140.25.0.0/16) на 16 адресных блоков равного размера (рис. 2.18). Затем подсеть #1 разбивается па 32 одинаковых по длине адресных блока, а подсеть #14 также делится на 16 одинаковых адресных блоков (подсетей нижнего уровня). Промежуточные сети #2-13 не разбиваются. Полученная подсеть нижнего уровня, например 14-я подсеть в 14-й подсети (обозначим ее как #14-14), делится на 8 адресных блоков (подсетей) равного размера, которые образуют подсети следующего уровня. Таким образом, в сети организации планируется получить 74 подсети, каждая из которых будет поддерживать определенное количество устройств.
Рис. 2.18. Выделение 16 подсетей для адреса 140.25.0.0/16
Так как 16 “ 24, то потребуется 4 бита, чтобы идентифицировать каждую из подсетей. Это означает, что администратор нуждается в 4 битах или в расшивном сетевом префиксе /20, для того чтобы выделить 16 подсетей. Каждая 113 этих подсетей представляет собой смежный блок из 212 (32 - 20 = 12) адресов Устройств. Таким образом, мы получаем 212 - 2 = 4094 устройства. Ниже описы-
ваются 16 подсетей, выделенные из адресного блока 140.25.0.0/16. Все подсети нумеруются от 0 до 15. Курсивом выделен расширенный сетевой префикс, жирным начертанием — 4-разрядный номер подсети:
Базовая сетъ:10001100.00017007.00000000.00000000 = 140.25.0.0/16
Подсеть #0:10001100.00011001.00000000.00000000 = 140.25.0.0/20
Подсеть #1:10001100.00011001.00010000.00000000 = 140.25.16.0/20
Подсеть #2:10001100.00011001.00100000.00000000 = 140.25.32.0/20
Подсеть #3:10001100.00011001.00110000.00000000 = 140.25.48.0/20
Подсеть #4:10001100.00011001.01000000.00000000 = 140.25.64.0/20
Подсеть #13:10001100.00011001.11010000.00000000 = 140.25.208.0/20
Подсеть #14:10001100.00011001.11100000.00000000 = 140.25.224.0/20
Подсеть #15:10001100.00011001.11110000.00000000 = 140.25.240.0/20
Определим адреса устройств, которые могут быть назначены в подсети #3 (140.25.48.0/20) (рис. 2.19).
Рис. 2.19. Определение адресов устройств в подсети #3 (140.25.48.0/20):
Так как поле номера устройства в подсети #3 состоит из 12 бит, возможно ' 4 094 (212 - 2) корректных адреса устройств. Устройства нумеруются от 1 до , 4 094. Адреса устройств для подсети #3 приводятся ниже. Курсивом обозна- ; чается расширенный сетевой префикс, жирным начертанием — 12-разрядный номер устройства.<
Подсеть #3:10001100.00011001.00110000.00000000 = 140.25.48.0/20I
Устройство #1:10001100.00011001.00110000.00000001 - 140.25.48.1/20]
Устройство #2:70007700.00077007.00110000.00000010 = 140.25.48.2/20)
Устройство #3:10001100.00011001.00110000.00000011 = 140.25.48.3/20
Устройство #4093: 10001100.00011001.00111111.11111101 - 140.25.63.253/20 j
Устройство #4094: 10001100.00011001.00111111.11111110 = 140.25.63.254/20 J
Широковещательный адрес для подсети #3 — это тот адрес, в котором все бить! в поле номера устройства установлены в единицу, то есть 10001100.00011001- | 00111111.11111111 = 140.25.63.255.
Следует отметить, что широковещательный адрес для подсети #3 ровно на единицу меньше базового адреса для подсети #4 (140.25.64.0).
Определим подсети нижнего уровня (подсети подсетей) для подсети #14 (140.25.224.0/20). После того как основной сетевой адрес разделен на 16 подсетей, подсеть #14 разбивается на 16 адресных блоков равного размера (рис. 2.20).
Рис. 2.20. Определение подсетей нижнего уровня для подсети #14 (140.25.224.0/20)
Так как 16 = 24, то для того, чтобы идентифицировать каждую из этих 16 подсетей, требуется еще 4 бита. Это означает, что потребуется расширенный сетевой префикс /24. Ниже приводятся 16 подсетей из адресного блока 140.25.224.0/20, которые нумеруются от 0 до 15. Курсивная часть каждого адреса подсети нижнего уровня идентифицирует расширенный сетевой префикс, жирное выделение соответствует 4-разрядному полю подсети нижнего уровня:
Подсеть #14:10001100.00011001.11100000.00000000 = 140.25.224.0/20
Подсеть #14-0:10001100.00011001.11100000.00000000 = 140.25.224.0/24
Подсеть #14-1:10001100.00011001.11100001.00000000 = 140.25.225.0/24
Подсеть #14-2:10001100.00011001.11100010.00000000 = 140.25.226.0/24
Подсеть #14-3:10001100.00011001.11100011.00000000 = 140.25.227.0/24
Подсеть #14-4:10001100.00011001.11100100.00000000 = 140.25.228.0/24
Подсеть #14-14:10001100.00011001.11101110.00000000 = 140.25.238.0/24
Подсеть #14-15:10001100.00011001.11101111.00000000 = 140.25.239.0/24
Теперь следует определить адреса, которые могут быть назначены устройствам в подсетях нижнего уровня, например #14-3 (140.25.227.0/24) (рис. 2.21).
В подсети нижнего уровня #14-3 можно использовать 8 бит для задания адресов устройств. Это означает, что каждая подсеть нижнего уровня #14-х способна поддерживать блок из 254 адресов устройств (28 - 2), которые нумеруются от 1 до 254. Адреса устройств в подсети #14-3 приводятся ниже. Курсивная часть каждого адреса идентифицирует расширенный сетевой префикс, жирным Шрифтом выделен 8-разрядный номер устройства:
Подсеть #14-3:10001100.00011001.11100011.00000000 = 140.25.227.0/24
Устройство #1:10001100.00011001.11100011.00000001 = 140.25.227.1/24
Устройство #2:10001100.00011001.11100011.00000010 = 140.25.227.2/24
Устройство #3:10001100.00011001.11100011.00000011 = 140.25.227.3/24
Устройство #4:10001100.00011001.11100011.00000100 = 140.25.227.4/24
Устройство #5:10001100.00011001.11100011.00000101 = 140.25.227.5/24
Устройство #2 53:10001100.00011001.11100011.11111101 = 140.25.227.253/24
Устройство #2 54:10001100.00011001.11100011.11111110 = 140.25.227.254/24
140.25.0.0/16140.25.0.0/16
140.25.0.0/16
140.25.0.0/16
Широковещательный адрес для подсети #14-3 — это тот, в котором все биты ; в поле номера устройства установлены в единицу: 10001100.00011001.11100011. j 11111111 - 140.25.227.255.;
Чтобы лучше разобраться с назначением подсетей нижнего уровня, рассмот- j рим случай, когда в подсети нижнего уровня (в нашем случае — второго уровня) вводятся подсети.;
После того как подсеть #14 была разделена на 16 подсетей нижнего уровня (под-подсетей), в под-подсети #14-14 (140.25.238.0/24) выделяются 8 адресных . блоков равного размера (рис. 2.22).
Так как 8 = 23, то для того, чтобы идентифицировать каждую из этих 8 подсетей, дополнительно требуется три бита. Это означает, что возникает потребность
в расширенном сетевом префиксе /27. Адреса 8 подсетей из адресного блока 140 25.238.0/24 приведены ниже. Подсети нумеруются от 0 до 7. Курсивная часть каждого адреса под-под-подсети идентифицирует расширенный сетевой префикс, в то время как жирным шрифтом показан 3-разрядный номер под-под-подсети:
Подсеть #14-14:10001100.00011001.11101110.00000000 - 140.25.238.0/24 Подсеть #14-14-0:10001100.00011001.11101110.00000000 = 140.25.238.0/27 Подсеть #14-14-1:10001100.00011001.11101110.00400000 = 140.25.238.32/27 Подсеть #14-14-2:10001100.00011001.11101110.04000000 = 140.25.238.64/27
Подсеть #14-14-3:10001100.00011001.11101110.04400000 = 140.25.238.96/27
Подсеть #14-14-4:10001100.00011001.11101110.40000000 - 140.25.238.128/27
Подсеть #14-14-5:10001100.00011001.11101110.40400000 = 140.25.238.160/27
Подсеть #14-14-6:10001100.00011001.11101110.4 4000000 = 140.25.238.192/27 Подсеть #14-14-7:10001100.00011001.11101110.44400000 = 140.25.238.224/27
Теперь можно определить адреса устройств в подсети #14-14-2 (140.25.238. 64/27) (2.23).
Рис. 2.23. Определение адресов устройств в подсети #14-14-2 (140.25.238.64/27)
Каждая из подсетей третьего уровня в подсети второго уровня #14-14 имеет пять битов для задания адресов устройств. Это означает, что каждая из этих подсетей может поддерживать до 30 адресов устройств (25 - 2), которые нумеруются от 1 до 30. Адреса устройств для подсети #14-14-2 приводятся ниже (жирным шрифтом выделен 5-разрядный номер устройства):
Подсеть #14-14-2:10001100.00011001.11101110.010 00000 = 140.25.238.64/27
Устройство #1:10001100.00011001.11101110.01000004 = 140.25.238.65/27
Устройство #2:10001100.00011001.11101110.01000040 = 140.25.238.66/27
Устройство #3:10001100.00011001.11101110.01000044 = 140.25.238.67/27
Устройство #4:10001100.00011001.11101110.01000400 = 140.25.238.68/27
Устройство #5:10001100.00011001.11101110.01000404 = 140.25.238.69/27
L
Устройство #29:10001100.00011001.11101110.01044404 - 140.25.238.93/27
Устройство #30:10001100.00011001.11101110.01044440 = 140.25.238.94/27
Широковещательный адрес для подсети #1414-2 — тот, в котором все биты' в поле номера устройства установлены в единицу: 10001100.00011001.11011100, 01011111 = 140.25.238.95.
Широковещательный адрес для подсети #14-14-2 ровно на единицу меньше базового адреса подсети #14-14-3 (140.25.238.96).
Немного изменим ситуацию и предположим, что организации был выделен сетевой адрес 140.25.0.0/16, и администратор собирается использовать маски подсети переменной длины. На рис. 2.24 показана планируемая схема выделения подсетей для этой организации.
Первый шаг при организации подсетей состоит в делении основного сетевого адреса на 8 адресных блоков равного размера. Затем подсеть #1 делится на 32 одинаковых по длине адресных блока, а подсеть #6 также разбивается на 16 одинаковых адресных блоков. Далее получившиеся подсети нижнего уровня, например подсеть #6-14, делятся на 8 адресных блоков равного размера. Определим 8 подсетей сети с адресом 140.25.0.0/16:
Базовая сеть: 10001100.00011001.00000000.00000000 = 140.25.0.0/16
Подсеть #0:10001100.00011001.00000000.00000000 = 140.25.0.0/19
Подсеть #1:10001100.00011001.00100000.00000000 = 140.25.32.0/19
Подсеть #2:10001100.00011001.01000000.00000000 = 140.25.64.0/19
Подсеть #3:10001100.00011001.01100000.00000000 = 140.25.96.0/19
Подсеть #4:10001100.00011001.10000000.00000000 = 140.25.128.0/19
Подсеть #5:10001100.00011001.10100000.00000000 = 140.25.160.0/19
Подсеть #6:10001100.00011001.11000000.00000000 = 140.25.192.0/19
Подсеть #7:10001100.00011001.11100000.00000000 = 140.25.224.0/19
Вот список адресов устройств, которые могут использоваться в подсети #3 (140.25.96.0):
Подсеть #3:10001100.00011001.01100000.00000000 = 140.25.96.0/19
Устройство #1:10001100.00011001.01100000.00000001 = 140.25.96.1/19
Устройство #2:10001100.00011001.01100000.00000010 = 140.25.96.2/19
Устройство #3:10001100.00011001.01100000.00000011 = 140.25.96.3/19;
устройство #8189: 10001100.00011001.01111111.11111101 = 140.25.127.253/19
Устройство #8190: 10001100.00011001.01111111.11111110 = 140.25.127.254/19
Теперь определим широковещательный адрес для подсети #3 (140.25.96.0):
■/0001100.00011001.01111111. 11111111 = 140.25.127.255
Определим 16 подсетей нижнего уровня в подсети #6 (140.25.192.0/19):
Подсеть #6:10001100.00011001.11000000.00000000 = 140.25.192.0/19
Подсеть #6-0:10001100.00011001.11000000.00000000 = 140.25.192.0/23
Подсеть #6-1:10001100.00011001.11000010.00000000 = 140.25.194.0/23
Подсеть #6-2:10001100.00011001.11000100.00000000 = 140.25.196.0/23
Подсеть #6-3:10001100.00011001.11000110.00000000 = 140.25.198.0/23
Подсеть #6-4:10001100.00011001.11001000.00000000 = 140.25.200.0/23
Подсеть #6-14:10001100.00011001.11011100.00000000 = 140.25.220.0/23
Подсеть #6-15:10001100.00011001.11011110.00000000 = 140.25.222.0/23
Перечислим адреса устройств, которые могут использоваться в подсети нижнего уровня #6-3 (140.25.198.0/23):
Подсеть #6-3:10001100.00011001.11000110.00000000 = 140.25.198.0/23
Устройство #1:10001100.00011001.11000110.00000001 = 140.25.198.1/23
Устройство #2:10001100.00011001.11000110.00000010 = 140.25.198.2/23
Устройство #3:10001100.00011001.11000110.00000011 = 140.25.198.3/23
Устройство #4:10001100.00011001.11000110.00000100 = 140.25.198.4/23
Устройство #5:10001100.00011001.11000110.00000110 - 140.25.198.5/23
Устройство #509:10001100.00011001.11000111.11111101 = 140.25.199.253/23
Устройство #510:10001100.00011001.11000111.11111110 = 140.25.199.254/23
Определим широковещательный адрес для подсети нижнего уровня #6-3 (140.25.198.0/23):
10001100.00011001.11000111.11111111 = 140.25.199.255
Определим 8 подсетей третьего уровня для подсети второго уровня #6-14 (140.25.220.0/23):
Подсеть #6-14:10001100.00011001.11011100.00000000 = 140.25.220.0/23
Подсеть #6-14-0: 10001100.00011001.11011100.00000000 = 140.25.220.0/26
Подсеть #6-14-1: 10001100.00011001.11011100.01000000 = 140.25.220.64/26
Подсеть #6-14-2: 10001100.00011001.11011100.10000000 = 140.25.220.128/26
Подсеть #6-14-3: 10001100.00011001.11011100.11000000 = 140.25.220.192/26
Подсеть #6-14-4: 10001100.00011001.11011101.00000000 = 140.25.221.0/26
Подсеть #6-14-5: 10001100.00011001.11011101.01000000 = 140.25.221.64/26
Подсеть #6-14-6: 10001100.00011001.11011101.10000000 = 140.25.221.128/26
Подсеть #6-14-7: 10001100.00011001.11011101.11000000 = 140.25.221.192/26
Приведем список адресов устройств, которые могут использоваться в подсети #6-14-2 (140.25.220.128/26):
Подсеть #6-14-2:10001100.00011001.11011100.10000000 = 140.25.220.128/26
Устройство #1:10001100.00011001.11011100.10000001 = 140.25.220.129/26
Устройство #2:10001100.00011001.11011100.10000010 - 140.25.220.130/26
Устройство #3:10001100.00011001.11011100.10000011 = 140.25.220.131/26
Устройство #4:10001100.00011001.11011100.10000100 = 140.25.220.132/26
Устройство #5:10001100.00011001.11011100.10000101 = 140.25.220.133/26
Устройство #61:10001100.00011001.11011100.10111101 = 140.25.220.189/26
Устройство #62:10001100.00011001.11011100.10111110 - 140.25.220.190/26
Определим широковещательный адрес для подсети третьего уровня #6-14-2 (140.25.220.128/26):
10001100.00011001.11011100.10111111 = 140.25.220.191
Технология CIDR
Поддержка маршрутизаторами технологии наибольшего совпадения сводится к выполнению следующего правила: маршрут в таблице маршрутизации с наибольшим расширенным сетевым префиксом описывает меньший набор получателей, чем тот же маршрут с коротким расширенным сетевым префиксом. В результате при передаче трафика маршрутизатор должен выбирать маршрут с наибольшим расширенным сетевым префиксом.
Например, если адрес получателя равен 11.1.2.5 и в таблице маршрутизации существуют три маршрута (табл. 2.12), то маршрутизатор выберет маршрут #1, так как его расширенный сетевой префикс охватывает большее число битов в адресе получателя.
Таблица 2.12. Пример работы технологии наибольшего совпадения
Получатель
11.1.2.5
00001011.00000001.00000010.00000101
Маршрут #1
11.1.2.0/24
00001011.00000001.00000010.00000000
Маршрут #2
11.1.0.0/16
00001011.00000001.00000000.00000000
Маршрут #3
11.0.0.0/8
00001011.00000000.00000000.00000000
Необходимо сделать одно важное замечание. Так как адрес получателя совпадает с тремя маршрутами, он должен быть присвоен хосту, который подключен к подсети 11.1.2.0/24. Если адрес 11.1.2.5 присвоен хосту, который связан с другими подсетями, маршрутизатор не будет передавать трафик этому хосту, так как технология наибольшего совпадения предполагает, что последний является частью подсети 11.1.2.0. Наивысшего внимания требует присвоение адресов хостам с учетом особенностей работы технологии наибольшего совпадения.
Иерархическая маршрутизация, предусмотренная протоколом OSPF, требует, чтобы адреса, присвоенные хостам, отражали актуальную сетевую топологию. Это уменьшает количество маршрутной информации, так как набор адресов, назначенных подсетям региона, можно свести в одно сообщение об обновлении. Иерархическая маршрутизация позволяет выполнять это рекурсивно в различных точках внутри топологии маршрутизации. Если адреса не соответствуют
F
Г ихнология CIDR
топологии, то нельзя выполнить обобщение адресной информации, и размер таблиц маршрутизации не будет уменьшаться. Этот постулат является основополагающим при рассмотрении технологии бесклассовой маршрутизации (Classless Inter-Domain Routing - CIDR),
Концепция бесклассовой междоменной маршрутизации была рфицимлунд. документирована в сентябре 1993 года (RFC 1517, RFC 1518, RFC 1519 и RFC 1520),* Йооявлсийе было инспирировано участившимися кризисами в Интернете. Из-за несовершенства протоколов маршрутизации трафик, вызванный сообщениями об обновлении таблиц маршрутизации, приводил к сбоям магистральных маршрутизаторов. Это было связано с полным задействованием их ресурсов па обработку большого объема служебной информации. Так, в 1994 году таблицы маршрутизации магистральных маршрутизаторов Интернета содержали до 70 000 маршрутов. Внедрение технологии CIDR сократило число записей маршрутов до 30 000.4 Кроме того, дополнительной предпосылкой для внедрения технологии CIDR явилась реальная опасность нехватки адресного пространства при дальнейшем расширении Интернета. Эта технология позволяет реализовать новые, не поддерживавшиеся ранее возможности.
Отход от традиционной концепции разделения адресов протокола IP на классы, благодаря чему можно более эффективно использовать адресное пространство протокола IP версии 4.
Объединение маршрутов. Здесь одна запись в таблице маршрутизации может представлять сотни адресов. Это позволяет контролировать количество маршрутной информации в магистральных маршрутизаторах Интернета.
Технология CIDR позволяет заменить традиционное использование классов адресов протокола IP на обобщенный сетевой префикс. Для определения границ между номером сети и номером хоста в IP-адресе маршрутизаторы выделяют сетевой префикс, вместо того чтобы по первым трем битам адреса определять его класс. В результате CIDR поддерживает организацию сетей произвольного размера, а не сетей со стандартными сетевыми номерами, которые ассоциируются с классами адресов.
В технологии CIDR каждая часть маршрутной информации рекламируется маршрутизаторами совместно с сетевым префиксом. Длина сетевого префикса помогает определить число старших битов, соответствующих номеру сети в записи таблицы маршрутизации.
Например, адрес подсети в таблице маршрутизации с номером сети, занимающим 20 бит, и номером хоста размером 12 бит, будет записан с сетевым префиксом длиной 20 бит, что можно представить как /20. Удобство заключается в том, что рекламируемый маршрутизатором IP-адрес подсети с префиксом /20 может быть адресом любого класса (Л, В или С). Маршрутизаторы с поддержкой технологии CIDR не проверяют обычными методами класс адреса — вместо этого °ни полагаются па информацию о сетевом префиксе, поступившую с рекламируемым маршрутом.
Если отказаться от разделения адресов на классы, то сетевой префикс можно Рассматривать как непрерывный битовый блок в адресном пространстве прото- к°ла IP. Например, рассмотренный выше сетевой префикс /20 предоставляет такое же количество битов для задания адресов хостов, как может быть получено
при разделении адресов на классы, а именно 12 битов. Это обеспечивает поддержку до 4094 (212 - 2 = 4094) адресов хостов. Таблица 2.13 показывает пример использования сетевого префикса /20. ■
Таблица 2.13. Пример использования сетевого префикса /20
Класс А
10.23.64.0/20
00001010.00010111.01000000.00000000
Класс В
130.5.0.0/20
10000010.00000101.00000000.00000000'
Класс С
200.7.128.0/20
11001000.00000111.10000000.00000000
Ввиду того что многие хосты учитывают принадлежность адресов к определенному классу, при их настройке требуется задавать маску подсети. Если администратор вместо маски подсети укажет сетевой префикс, хост не будет его воспринимать. .
Например, проблема возникает в случае, когда необходим адрес 200.25.16.0 с сетевым префиксом /20 для поддержки 4094 хостов (212 - 2 = 4094), так как хосты, не поддерживающие технологию CIDR, будут интерпретировать заданный адрес как адрес класса С с маской 255.255.255.0. При этом битов, оставшихся в поле номера хоста, не хватит для задания требуемого количества адресов хостов. Если хосты «понимают» технологию CIDR, то для данного адреса подойдет любой сетевой префикс.
Отметим, что технология CIDR в настоящее время встроена в магистральные интернет-маршрутизаторы с протоколом BGP4, а обычные хосты в локальных сетях ее не поддерживают.
Технология CIDR позволяет более эффективно использовать адресное пространство протокола IP. Обычно интернет-провайдер выделяет своим клиентам адреса определенных классов, что приводит к некоторой избыточности в одном месте и к дефициту в другом. Обратившись к технологии CIDR, провайдеры получают возможность «нарезать» блоки из выделенного им адресного пространства, которые оптимально подходят под требования каждого клиента, оставляя в то же время возможность его будущего беспроблемного роста.
Предположим, что провайдеру был выделен адрес 206.0.64.0 с сетевым префиксом /18. Тогда для задания индивидуальных адресов остается 14 бит, что позволяет поддерживать до 16 384 (214) хостов. В случае использования классов адресов достижение той же цели требует от провайдера выделения 64 адресов класса С.
Если клиенту, которого обслуживает данный провайдер, для своей сети требуется 800 адресов хостов, то провайдер может выделить ему адресный блок 206.0.68.0/22, то есть блок из 1024 (210) адресов хостов. При таком выделении клиент получает в свое распоряжение 224 дополнительных адреса. Если следовать классовой адресной схеме, то клиенту потребовалось бы выделить или один адрес класса В, или четыре адреса класса С. При предоставлении одного адреса класса В клиент получает более 64 000 дополнительных адресов. При выделении четырех адресов класса С клиент имеет приемлемое количество адре* сов, но заодно увеличивается размер таблиц маршрутизации (добавляются четыч ре записи). Таблица 2.14 иллюстрирует эти рассуждения. Т’
Таблица 2.14. Пример выделения адресов клиенту
"БлоГадресов провайдера
206.0.64.0/18
11001110.00000000,01000000.00000000
Блок адресов клиента
206.0.68.0/22
11001110.00000000.01000100.00000000
Или
Адрес класса С #0
206.0.68.0/24
11001110.00000000.01000100.00000000
Адрес класса С #1
206.0.69.0/24
11001110.00000000.01000101.00000000
Адрес класса С #2
206.0.70.0/24
11001110.00000000.01000110.00000000
Адрес класса С #3
206.0.71.0/24
11001110.00000000.01000111.00000000
Рассмотрим еще один пример. Предположим, что провайдеру был выделен адресный блок 200.25.0.0/16. Нетрудно подсчитать, что этот адресный блок поддерживает до 65 536 (216 = 65 536) индивидуальных адресов хостов. Из данного блока провайдер хочет выделить адресный блок 200.25.16.0/20 в расчете на 4096 (212 = 4096) адресов. Опираясь на классовую схему, провайдер будет вынужден использовать для этой цели 16 адресов класса С (табл. 2.15).
Таблица 2.15. Пример выделения адресного пространства
Сеть #0
200.25.16.0/24
11001000.00011001.00010000.00000000
Сеть #1
200.25.17.0/24
11001000.00011001.00010001.00000000
Сеть #2
200.25.18.0/24
11001000.00011001.00010010.00000000
Сеть #14
200.25.30.0/24
11001000.00011001.00011101.00000000
Сеть #15
■200.25.31.0/24
11001000.00011001.00011111.00000000
Продемонстрировать различие между адресацией на основе классов и на основе технологии CIDR наглядно позволяют круговые диаграммы. В первом случае пример, расписанный в табл. 2.15, можно изобразить в виде круга, разделенного на 16 одинаковых секторов (рис. 2.25). Каждый сектор соответствует одной сети класса С. Изменение в классе адресов в состоянии привести к изменению количества секторов. Секторы в любом случае имеют одинаковые размеры.
200.25.31.0/24200.25.30.0/24200.25.29.0/24200.25.31.0/24200.25.30.0/24200.25.29.0/24200.25.28.0/24200.25.27.0/24200.25.26.0/24200.25.25.0/24200.25.28.0/24200.25.27.0/24200.25.26.0/24200.25.25.0/24200.25.24.0/24200.25.24.0/24200.25.16.0/24200.25.17.0/24200.25.18.0/24200.25.19.0/24200.25.20.0/24200.25.21.0/24200.25.22.0/24200.25.23.0/24200.25.16.0/24200.25.17.0/24200.25.18.0/24200.25.19.0/24200.25.20.0/24200.25.21.0/24200.25.22.0/24200.25.23.0/24Рис. 2.25. Диаграмма деления адресного пространстваРис. 2.25. Диаграмма деления адресного пространства
200.25.31.0/24
200.25.30.0/24
200.25.29.0/24
200.25.31.0/24
200.25.30.0/24
200.25.29.0/24
200.25.28.0/24
200.25.27.0/24
200.25.26.0/24
200.25.25.0/24
200.25.28.0/24
200.25.27.0/24
200.25.26.0/24
200.25.25.0/24
200.25.24.0/24
200.25.24.0/24
200.25.16.0/24
200.25.17.0/24
200.25.18.0/24
200.25.19.0/24
200.25.20.0/24
200.25.21.0/24
200.25.22.0/24
200.25.23.0/24
200.25.16.0/24
200.25.17.0/24
200.25.18.0/24
200.25.19.0/24
200.25.20.0/24
200.25.21.0/24
200.25.22.0/24
200.25.23.0/24
Рис. 2.25. Диаграмма деления адресного пространства
Рис. 2.25. Диаграмма деления адресного пространства
При использовании технологии CIDR провайдер имеет возможность «паре? зать> адресное пространство па секторы произвольного размера. Предположи^ - что провайдер обслуживает четыре организации: А, В, С и D, Организация Д^ претендует на половину всего адресного пространства провайдера. Организаций В необходима четверть, а организациям С и D требуется по одной восьмой oxi всего диапазона.■
Процесс выделения адресного пространства провайдер может провести затри этапа. На нервом шаге адресный блок провайдера 200,25,16.0/20 разделяет;-' ся на две равные части. Каждая из частей включает в себя 2048 (211 - 2048): возможных адресов хостов (табл. 2.16).
Таблица 2.16. Выделение адресного пространства для организации А;
Блок адресов провайдера200.25.16.0/2011001000.00011001.00010000.00000000
■Д'
Организация А200.25.16.0/2111001000.00011001.00010001.00000000 /
Оставшийся резервный блок 200.25.24.0/21 11001000.00011001.00011010.00000000
Сетевой префикс /21 получен следующим образом. Провайдер имеет 4096; исходных адресов хостов. При делении адресного пространства пополам организа*' ция А получает 2048 адресов. Для поддержания этих адресов требуется 11-разряд-: ное поле номера хоста. В результате сетевой префикс получается равным /2.1 (32 - И - 21). ’ :
На втором шаге оставшийся резервный блок разбивается на две равные части. •; Каждая из этих половинок представляет одну четверть всего адресного простран-, ства провайдера и поддерживает до 1024 (210 - 1024) адресов хостов. Сетевой; префикс получается равным /22 (32 - 10 = 22). Выделение адресного пространства организации В показано в табл. 2.17. ' <
Таблица 2.17. Выделение адресного пространства для организации В
Оставшийся после шага 1 резерв
200.25.24.0/21
11001000.00011001.00011000.00000000.
Организация В
200.25.24.0/22
11001000.00011001.00011000.00000000-
Оставшийся резервный блок
200.25.28.0/22
11001000.00011001.00011100.00000000
На третьем шаге образовавшийся резервный блок также разбивается на две рав-1 ные части. Каждая из частей занимает одну восьмую от всего адресного простран-, ства провайдера и поддерживает до512(29 = 512) адресов хостов. Сетевой пре-< фикс для адресов организаций С и D получается равным /23 (32 - 9 = 23). Табл и-, ца 2.18 показывает распределение адресного пространства для организаций С и D. 1
Таблица 2.18. Выделение адресного пространства организациям С и D
Оставшийся после шага 2 резерв 200.25.28.0/22Организация С200.25.28.0/23Организация D200.25.30.0/23Оставшийся после шага 2 резерв 200.25.28.0/22Организация С200.25.28.0/23Организация D200.25.30.0/2311001000.00011001.00011100.00000000 I llOOlOOO.OOOllOOl.OOOlllOO.OOOOOOOO'f llOOlOOO.OOOllOOl.OOOllllO.OOOOOOOQj11001000.00011001.00011100.00000000 I llOOlOOO.OOOllOOl.OOOlllOO.OOOOOOOO'f llOOlOOO.OOOllOOl.OOOllllO.OOOOOOOQj
Оставшийся после шага 2 резерв 200.25.28.0/22
Организация С200.25.28.0/23
Организация D200.25.30.0/23
Оставшийся после шага 2 резерв 200.25.28.0/22
Организация С200.25.28.0/23
Организация D200.25.30.0/23
11001000.00011001.00011100.00000000 I llOOlOOO.OOOllOOl.OOOlllOO.OOOOOOOO'f llOOlOOO.OOOllOOl.OOOllllO.OOOOOOOQj
11001000.00011001.00011100.00000000 I llOOlOOO.OOOllOOl.OOOlllOO.OOOOOOOO'f llOOlOOO.OOOllOOl.OOOllllO.OOOOOOOQj
Круговая диаграмма на рис. 2.26 иллюстрирует разделение адресного пространства провайдера между всеми четырьмя организациями.
Рис. 2.26. Разделение адресного пространства на основе технологии CIDR
Необходимо отметить, что рассмотренные выше примеры работы организаций с провайдерами несколько оторваны от реальной жизни. Это связано с тем, что в настоящее время получить сеть класса В практически невозможно, а связь маршрутизаторов провайдера и организаций осуществляется при помощи статических таблиц маршрутизации, настроенных вручную. Технология CIDR (и протокол BGP4) может быть использована, если организация подключается к Интернету через нескольких разных провайдеров, а адреса ей выделяет InterNIC. Однако если организация имеет свою собственную крупную распределенную сеть, то применение технологии CIDR в ее центре может быть хорошим решением.
Для поддержания работоспособности технологии CIDR необходимо выполнение трех основных условий.
Протокол маршрутизации должен в своих служебных сообщениях передавать дополнительную информацию о сетевом префиксе.
Все маршрутизаторы должны поддерживать алгоритм передачи, основанный на технологии наибольшего совпадения.
Чтобы обеспечить возможность объединения маршрутов, адреса нужно назначить в соответствии с существующей сетевой топологией.
Другим важным достоинством технологии CIDR является возможность контролировать размеры таблиц маршрутизации в Интернете. Для уменьшения размеров маршрутной информации необходимо разделение Интернета на адресные Домены. Внутри каждого домена циркулирует только внутренняя маршрутная информация о всех сетях в домене. Однако вне домена рекламируется только общий сетевой префикс. Это позволяет одной записи в таблице маршрутизации Указывать маршрут во множество индивидуальных сетей.
Необходимо учитывать, что объединение маршрутов не выполняется автоматически. Администратор должен настроить каждый маршрутизатор для выполнения объединения маршрутов. При этом важно помнить, что технология CIDR является частью нового протокола маршрутизации BGP-4. Успешное внедрение технологии CIDR позволит увеличить число индивидуальных сетей, подключенных к Интернету, с сохранением размеров таблиц маршрутизации.
Технологии CIDR и маски подсети переменной длины позволяют рекурсивно делить порции адресного пространства на небольшие части. Основное различие между ними в том, что при использовании маски подсети переменной длины рекурсия выполняется на адресном пространстве, выделенном организации ранее. При этом схема деления пространства остается спрятана внутри организации (то есть, например, для пользователей в сети Интернет подобная схема разделения остается прозрачной и незаметной).
Пример использования технологии CIDR
Рассмотрим на практике работу с технологией CIDR. Для этого выберем адресный блок 200.56.168.0/21. На первом этапе запишем индивидуальные номера сетей для этого блока.'
В двоичном виде блок представляется следующим образом:
200.56.168.0/21 - 11001000.00111000.10101000.00000000.
Маска, определяемая префиксом /21, на три бита меньше, чем традиционная маска для сети класса С (/24). А это означает, что рассматриваемый блок CIDR идентифицирует блок из 8 (23) последовательных (упорядоченных) сетей с префиксом /24:
Сеть #0: 11001000.00111000.10101000.хххххххх — 200.56.168.0
Сеть #1: 11001000.00111000.10101001.ХХХХХХХХ - 200.56.169.0
Сеть #2: 11001000.00111000.10101010.хххххххх200.56.170.0
Сеть #3: 11001000.00111000.10101011.хххххххх — 200.56.171.0
Сеть #4: 11001000.00111000.10101 ЮО.хххххххх - 200.56.172.0
Сеть #5: 11001000.00111000.10101101.хххххххх — 200.56.173.0
Сеть #6: 11001000.00111000.10101110.ХХХХХХХХ - 200.56.174.0
Сеть #7: 11001000.00111000.10101111.хххххххх — 200.56.175.0
Другой пример. Приведем индивидуальные номера сетей, определяемых блоком CIDR 195.24.0/13. Указанный блок CIDR можно записать в двоичном представлении:
195.24.0.0/13 - 11000011.00011000.00000000.00000000
Маска, определяемая префиксом /13, на И бит короче, чем традиционная маска для сети класса С. В рассматриваемом примере это указывает на то, что блок CIDR идентифицирует 2048 (211) последовательных сетей с сетевым префиксом /24:
Сеть #0:11000011.0001 ЮОО.ОООООООО.хххххххх - 195.24.0.0
Сеть #1:11000011.0001 lOOO.OOOOOOOl.xxxxxxxx - 195.24.1.0
Сеть #2:11000011.0001 ЮОО.ООООООЮ.хххххххх - 195.24.2.0
Сеть #2045:11000011.00011111.11111101.ХХХХХХХХ- 195.31.253.0
Сеть #2046:11000011.00011111.lllllllO.xxxxxxxx - 195.31.254.0
Сеть #2047:11000011.00011111.11111111.ХХХХХХХХ - 195.31.255.0
В третьем примере требуется объединить набор следующих четырех адресов с префиксом /24 в максимально вместительный адрес:
212.56.132.0/24
212.56.133.0/24
212.56.134.0/24
212.56.135.0/24
На первом этапе запишем каждый адрес сети в двоичном виде, что поможет в дальнейшем:
0/24 11010100.00111000.10000100.00000000
0/24 11010100.00111000.10000101.00000000
0/24 11010100.00111000.10000110.00000000
0/24 11010100.00111000.10000111.00000000
Общий префикс для всех адресов — 11010100.00111000.10000100.00000000.
Объединение CIDR будет следующим — 212.56.132.0/22.
В четвертом примере объединим набор из других четырех сетей:
0/24‘
212.56.147.0/24
212.56.148.0/24
212.56.149.0/24
Запишем эти адреса в двоичной форме:
0/24 11010100.00111000.10010010.00000000
0/24 11010100.00111000.10010011.00000000
0/24 11010100.00111000.10010100.00000000
0/24 11010100.00111000.10010101.00000000
Следует обратить внимание на то, что рассматриваемый набор из четырех сетей нельзя объединить в адрес с префиксом /23:
0/23 11010100.00111000.10010010.00000000
0/23 11010100.00111000.10010100.00000000
Учитывая это, объединение CIDR будет следующим:
212.56.146.0/23
212.56.148.0/23
Если две сети с префиксом /23 нужно объединить в сеть с префиксом /22, то они должны соответственно «помещаться» в один адресный блок /22. Однако раз каждая из полученных сетей с префиксом /23 является членом различных блоков /22, то они не могут быть объединены в блоке /22, хотя объединение в 222.56.144/21 формально действительно. Но такое объединение включало бы четыре адреса сети, которых не было в исходных сетях. Учитывая все вышеизложенное, отмстим, что объединение, состоящее из минимального количества адресных блоков (два) будет иметь префикс /23.
Завершим практикум еще один примером — объединим набор из 64 адресов сетей класса С в единый блок:. v
0/24;
0/24’
0/24■
202.1.126.0/24
0/24'
0/24*
202.1.129.0/24
0/24;
202.1.159.0/24
Запишем эти адреса в двоичном виде для выявления общего префикса::
0/24 11001010.00000001.01100000.00000000^
0/24 11001010.00000001.01100001.00000000
0/24 11001010.00000001.01100010.00000000'
0/24 11001010.00000001.01111110.00000000
0/24 11001010.00000001.01111111.00000000■
0/24 11001010.00000001.10000000.00000000;
0/24 11001010.00000001.10000001.000000001
0/24 11001010.00000001.10011110.00000000
0/24 11001010.00000001.10011111.00000000:
Следует обратить внимание на то, что все 64 адреса сетей не могут быть объ- 5 единены в блок с префиксом /19:|
0/19 11001010.00000001.01100000.00000000ч
0/19 11001010.00000001.10000000.00000000I
Учитывая это, объединение CIDR будет следующим:
0/19.।
0/19j
По аналогии с предыдущим примером, если два адресных блока /19 нужно J скомпоновать в блоке /18, то они должны «помещаться» в один блок /18. Так как каждый из рассматриваемых блоков входит в разные адресные блоки /18, то , они, соответственно, не могут быть объединены в блоке /18, хотя возможно их 1 слияние в один 202.1.0.0 /16. Однако такое объединение будет включать 192 до- । полнительных адреса сетей, которые не являются частью исходных сетей. ■
Настройка протокола IP на маршрутизаторе • . Cisco Systemsi
Базовым шагом при настройке протокола IP на маршрутизаторах является назначение IP-адреса интерфейсу. После этого интерфейс может участвовать в об- j мене информацией в распределенной сети. Интерфейс маршрутизатора вправе |
иметь только один первичный (primary) адрес, для настройки которого следует оспользоваться командой ip address, выполняемой в режиме конфигурирования интерфейсов. В качестве параметра этой команды следует указать собственно jp-адрес и маску подсети.
Cisco!601#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Ciscol601(config)#interface ethernet 0
Ciscol601 (conf"ig-1 f)#ip address 192.168.3.254 255.255.255.0
Помимо первичного адреса администратор волен настроить неограниченное количество вторичных адресов (secondary), которые могут потребоваться для различных ц^гей. Например, вероятна ситуация, когда выбранная схема выделения подсетей позволяет поддерживать не более 254 устройств в одной логической подсети, в то время как в физической подсети необходимо существование порядка 300 устройств. В этом случае администратор может настроить на маршрутизаторе вторичный адрес, что позволит получить две логические подсети в одном физическом сегменте сети. Следует отметить, что если любой маршрутизатор в сегменте поддерживает вторичные адреса протокола IP, то все другие маршрутизаторы в этом сегменте также должны использовать вторичные адреса с теми же адресами сети или подсети. Для настройки вторичных адресов служит команда ip address <маска 1Р-адреса> secondary.
Ciscol601(config)#interface ethernet О
Ciscol601(config-if)#ip address 192.168.3.205 255.255.255.0 secondary
*• ■ ь. ■,„ .„<
В приведенном выше примере на интерфейсе EthernctO маршрутизатора настраивается вторичный адрес протокола 1Р. До этого такой же командой (только без ключевого слова secondary) был настроен первичный адрес. Таким образом, маршрутизатор (точнее, один из его интерфейсов) имеет два адреса. Если теперь выполнить команду show running-config, то можно увидеть настроенные на интерфейсе адреса.
Ciscol601#show running-config
Interface EthernetO
description connected to Internal LAN - 192.168.3.x
ip address 192.168.3.205 255.255.255.0 secondary
ip address 192.168.3.254 255.255.255.0
no keepalive
В том случае, если для настройки маршрутизатора используется программное обеспечение Cisco ConfigMaker, при создании схемы сети администратору потребуется ввести адреса для интерфейсов маршрутизатора (рис. 2.27). При нажатии кнопки IP... становится доступен калькулятор.
Обычно канал связи между маршрутизаторами требует организации отдельной подсети. Однако такое требование достаточно проблематично удовлетворить, так как впустую расходуется множество возможных адресов устройств. Оптимальным может быть решение, которое заключается в использовании технологии VLSM
и создании небольших, содержащих всего два устройства подсетей (маска под;, сети /30, или 255.255.255.252), или в востребовании специального механизма опеь * рационной системы Cisco IOS, который называется гр unnumbered. В последнем
варианте каналу связи между маршрутизаторами ^ообше не присваивается аДрес, что позволяет говорить об экономии адресного пространства (к тому же^этхг значительно упрощает администрирование сети). Данная возможность применима^ к каналам связи типа «точка-точка» между парами маршрутизаторов, примером; чему служат выделенные каналы связи, постоянные виртуальные соединения; Frame Relay, ATM и т. п. При этом происходит заимствование адреса сетевого! уровня у одного из интерфейсов маршрутизатора (например, EthernetO). л
IE! hernel PropertiesIE! hernel PropertiesММММCEscotSOT ||CEscotSOT ||g^^OjEthernet 0Jg^^OjEthernet 0JrSubnst»asfc:ij 255^255. 255, 0 i$Г* DHCP Server Г DHCP BelayrSubnst»asfc:ij 255^255. 255, 0 i$Г* DHCP Server Г DHCP Belayor Network 6b; ^24 ~фor Network 6b; ^24 ~ф
IE! hernel Properties
IE! hernel Properties
ММ
ММ
CEscotSOT ||
CEscotSOT ||
g^^OjEthernet 0J
g^^OjEthernet 0J
rSubnst»asfc:ij 255^255. 255, 0 i$Г* DHCP Server Г DHCP Belay
rSubnst»asfc:ij 255^255. 255, 0 i$Г* DHCP Server Г DHCP Belay
or Network 6b; ^24 ~ф
or Network 6b; ^24 ~ф
::№®ИетЩ^
Рис. 2.27. Использование Cisco ConfigMaker для назначения адреса
Для того чтобы настроить рассматриваемый механизм, нужно выполнить команду ip unnumbered в режиме конфигурирования интерфейсов. Приведенный ; ниже пример показывает настройку подинтерфейса SerialO.l (отражающий по-, стоянное виртуальное соединение Frame Relay, глава 8) как ненумерованной?; с привлечением адреса интерфейса локальной сети.'1
Cisco805#configure terminal
Enter configuration commands, one per line. End with CNTL/Z./
Cisco805(config)#interface serial 0.1!г
Cisco805(config-subif)#ip unnumbered EthernetO'&
Если для настройки сети используется Cisco ConfigMaker, то администратор сети также может использовать ip unnumbered. На рис. 2.28 показано диалоговое окно, в котором производится настройка соединения двух маршрутизаторов по технологии Frame Relay. Точнее, показано окно мастера настройки, где администратор может выбрать механизм ip unnumbered и указать, адрес какого интерфейса следует задействовать.
I пипе Я<-1ау Wizard (itcolbOt - Specify № tl
fgQi§g§^fgQi§g§^Ф'УРШгй|ЬегШ5а^ф *1«Ф'УРШгй|ЬегШ5а^ф *1«
fgQi§g§^
fgQi§g§^
Ф'УРШгй|ЬегШ5а^ф *1«
Ф'УРШгй|ЬегШ5а^ф *1«
|:|^^Д^
Рис. 2.28. Настройка ip unnumbered в программе Cisco ConfigMaker
Для ненумерованных интерфейсов следует учитывать ряд важных моментов. Интерфейсы, инкапсулирующие данные ио типу HDLC, PPP, LAPB и Frame Relay, могут быть ненумерованными. Кроме того, при инкапсуляции Frame Relay это могут быть только интерфейсы типа «точка-точка». Невозможно использовать рассматриваемый механизм при инкапсуляции Х.25 и SMDS. Другим ограничением является то, что администратор сети не вправе воспользоваться командой ping для определения статуса интерфейса. Выполняя команду show interfaces, можно получить информацию о том, что интерфейс не нумерован, ц^д^ть, какой адрес ему назначен.
C1scol005 #show interfaces serial 0.1
Seri al 0.1 is up, line protocol is up
Hardware is QUICC Serial
Interface is unnumbered. Using address of EthernetO (192.168.6.254)
MTU 1500 bytes. BW 1544 Kbit, DLY 20000 usee, rely 255/255. load 1/255 Encapsulation FRAME-RELAY
Протокол ARP
Протокол ARP (Address Resolution Protocol) — это протокол разрешения адресов, описан в документе ^С. 8^6. Необходимость в протоколе ARP продиктоваНа тем обстоятельством, что IP-адреса устройств в сети назначаются независимо
от их физических адресов. Поэтому для доставки сообщений по сети требуется установить соответствие между физическим адресом устройства и его IP-адресом. Эта процедура называется разрешением адресов (address resolution). В большие стве случаев прикладные программы работают именно с IP-адресами. А так как схемы физической адресации устройств весьма разнообразны, то необходим специальный, универсальный протокол.
Для того чтобы получить адрес протокола IP, зная физический адрес устройст-1 ва, предусмотрена процедура, называемая обратным разрешением адресов (reversei address resolution). Программное обеспечение маршрутизаторов Cisco IOS под* держивает следующие протоколы, связанные с процедурами разрешения адре^ сов: протокол ARP, proxy ARP, reverse ARP, — которые описаны в документах RFC 826, 1027 и 903. Кроме того, поддерживается протокол Probe, разработан-; пый компанией Hewlett-Packard для использования в сетях IEEE-802.3. :
Reverse ARP (или обратное разрешение) работает аналогично протоколу ARP: за исключением того, что в его задачи входит определение физического адресу по известному адресу сетевого уровня. Этот протокол требует наличия в сети' сервера RARP, подключенного к тому же сегменту сети, что и интерфейс марш-, рутизатора. Наиболее часто протокол reverse ARP используется для запуска; бездисковых рабочих станций. Маршрутизатор, работающий под управлением опе^ рационной системы Cisco IOS, примет во внимание этот протокол, если в про^ цессе своей загрузки он обнаружит, что интерфейсу не назначен адрес протоков ла IP. Отметим тот факт, что маршрутизатор может работать как сервер RARP,, отвечая на запросы клиентов.
Разрешение адресов может быть выполнено двумя способами: с помощью пря-- мого отображения и с помощью динамического связывания (dynamic mapping)., Протокол ARP задействует механизм динамического связывания. Фупкциональ-: ность протокола ARP сводится к решению двух задач. Одна часть протокола определяет физические адреса при посылке дейтаграммы, другая отвечает на запросы: устройств в сети. Протокол ARP предполагает, что каждое устройство «знает»; как свой IP-адрес, так и свой физический адрес.
Для того чтобы уменьшить количество посылаемых запросов ARP, каждое; устройство в сети, использующее протокол ARP, должно иметь специальную буферную память. В ней хранятся пары адресов (IP-адрес, физический адрес) устройств в сети. Всякий раз, когда устройство получает ARP-ответ, оно сохра--; пяет в буферной памяти соответствующую пару. Если адрес есть в списке пар, то пет необходимости посылать ARP-запрос. Эта буферная память называется' ARP-таблицей.
В ARP-таблице могут содержаться как статические, так и динамические записи. Динамические записи добавляются и удаляются автоматически, статические заносятся вручную.
Так как большинство устройств в сети поддерживает динамическое разрешение адресов, то администратору, как правило, нет необходимости собственноруч-; но указывать записи протокола ARP в таблице адресов.
Кроме того, ARP-таблица всегда содержит запись с физическим широковещательным адресом (OxFFFFFFFFFFFF) для локальной сети. Эта запись по-; зволяет устройству принимать широковещательные ARP-запросы. Каждая запись, в ARP-таблице имеет свое Время жизни, например для операционной систем^
Microsoft Windows NT оно составляет 10 минут. При добавлении записи для нее активируется таймер. Если запись не востребована в первые две минуты, она удаляется. Если используется — будет существовать на протяжении 10 минут. В некоторых реализациях протокола ARP новый таймер устанавливается после каждого обращения к записи в ARP-таблице.
Для просмотра содержимого таблицы па маршрутизаторе предусмотрена команда show агр, выполняемая в пользовательском режиме. Если необходимо очистить таблицу, следует воспользоваться командой clear arp-cache, доступной в привилегированном режиме.
C1scol60l>show агр
Protocol
Address
Age (mln) Hardware Addr
Type
Interface
Internet
192.168.3.113
160090.2751.c4f0
ARPA
EthernetO
Internet
192.168.3.14
30090.27e0.041e
ARPA
EthernetO
Internet
192.168.3.3
790090.271d.c8ee
ARPA
EthernetO
Internet
192.168.3.5
900a0.c9da.f6f6
ARPA
EthernetO
Internet
192.168.3.4
500a0.c928.2d07
ARPA
EthernetO
Когда требуется изменить время жизни запйсей в таблице, можно обратиться к команде агр timeout, выполняемой в режиме конфигурирования интерфейсов. В качестве параметра указывается временной интервал в секундах.
По умолчанию на маршрутизаторах применяется стандартный тип инкапсуляции протокола ARP, который обозначается ключевым словом ARPA. Администратор сети имеет право изменить метод инкапсуляции на SNAP или HP Probe исходя из требований конкретной сети. Для изменения метода инкапсуляции следует выполнить команду агр в режиме конфигурирования интерфейсов, добавляя к ней параметры arpa, probe, snap. Получить информацию о текущем методе инкапсуляции можно с помощью команды show interfaces.
Стscol601#show Interfaces ethernet О
EthernetO is up. line protocol 1s up
Hardware 1s QUICC Ethernet, address 1s 0010.7bef.4478 (Ma 0010.7bef.4478)
Description: connected to Internal LAN - 192.168.3.x
Internet address 1s 192.168.3.254/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usee, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive not set
ARP type: ARPA, ARP Timeout 04:00:00
Протокол proxy ARP маршрутизатор использует (как это определено в документе RFC 1027) для того, чтобы помочь устройствам, не имеющим информации о маршрутизации, определить физические адреса устройств, находящихся В Другой подсети. Например, если маршрутизатор получает широковещательный запрос протокола ARP для устройства, которое расположено в сети, отличной от сети отправителя запроса, и если этот маршрутизатор знает все маршруты к этому устройству через другие свои интерфейсы, он генерирует ответ ARP с Указанием физического адреса своего интерфейса. Затем устройство, пославшее запрос ARP, будет адресовать свои пакеты маршрутизатору, который и передаст Их Действительному получателю. Данный механизм посредничества включен по
умолчанию, и если его необходимо отключить, то следует воспользоваться к< мандой no ip proxy-arp, выполняемой в режиме конфигурирования интерфейсо, Просмотреть результат работы этого механизма можно с помощью команд show ip interface..
Ciscol601#show ip interface ethernet 0'
EthernetO is up. line protocol is up
Internet address is 192.168.3.254/24
Broadcast address is 255.255.255.255
Proxy ARP is enabled
Сообщения протокола ARP при передаче по сети инкапсулируются в по; данных кадра. Они не содержат IP-заголовка. В отличие от сообщений болт шинства протоколов, сообщения ARP не имеют фиксированного формата зап ловка. Это объясняется тем, что протокол был разработан таким образом, чтоб! он был применим для разрешения адресов в различных сетях. Фактически пре токол способен работать с произвольными физическими адресами и сетевым
протоколами.
Рисунки 2.29 и 2.30 содержат результаты работы анализатора пакетов, кото рые наглядно показывают структуру запросов и ответов протокола ARP. АналФ зируя структуру запроса, можно увидеть, что компьютер с адресом 192.168.3$
делает попытку узнать МАС-адрес компьютера с IP-адресом 192.168.3.12. Дл: этого он посылает широковещательный запрос, содержащий IP-адрес, с МАС-ад ресом, установленным в 00:00:09:00:00:00. Следует обратить внимание на заголово MAC header — точнее, на поле Destination, установка которого в FF:FF:FF:FF:FF:^ как раз и указывает на широковещательный характер запроса. *
Е-& Packet structure
A-й MAC header (Ethernet II)
;; 451 Destination: FF:FF:FF:FF:FF:FF Broadcast
ii ^ Source: 00:D0:B7:BA:BF:19
i ^- ^ Type: 08-06 ARP
Е Й ARP header
# Hardware type = 1 (Ethernet [10Mb]) r ■ # Protocol type = 2048 (08-00 DoD IP) i- • $• Length of hardware address = 6 bytes 5 $ Length of protocol address = 4 bytes • ■■ $ Operation code • 1 (ARP request) : --^ Sender's hardware address - 00:D0:B7:BA:BF:19 ; -^ Sender's protocol address = 192.168.3.2 i- j^ Target hardware address = 00:00:00:00:00:00 ; • -^1 Target protocol address = 192.168.3,12 1#: 0 bytes frame padding
Рис. 2.29. Запрос протокола ARP
Когда компьютер с адресом 192.168.3.12 получает этот широковещательны; запрос, он анализирует IP-адрес, для которого выполняется разрешение. Опр делив, что его адрес совпадает с искомым, он формирует ответ протокола AR. где указывает свой МАС-адрес (рис. 2.30). :
S О Packet structure
i-j-Q MAC header (Ethernet II)
;;-^Destination: 00:D0:B7:BA:BF: 19
:L^Source: 00:A0;C9:4B:30:C5
-- &Type: 08-06 ARP
El Q ARP header
Hardware type = 1 (Ethernet [10Mb]) : ■■ ^ Protocol type = 2048 (08-00 DoD IP) •■■ ^ Length of hardware address = 6 bytes i $ Length of protocol address = 4 bytes : ^ Operation code = 2 (ARP reply)
^ Sender's hardware address = 00:A0:C9:4B:30:C5 ^ Sender's protocol address = 192.168,3.12
^ Target hardware address = 00:D0:B7:BA:BF: 19
••$ Target protocol address = 192.168.3.2 : -^ 18 bytes frame padding
Рис. 2.30. Ответ протокола ARP
Обратите внимание на то, что ответ посылается уже не широковещательно — отправитель знает МАС-адрес инициатора запроса и поэтому передает пакет целенаправленно.
Возможность использования протокола ARP для сетевых атак
Рассмотрев особенности протокола ARP, необходимо остановиться на тех его возможностях, которые он «предоставляет» для проведения компьютерных атак на сеть. Атаки с применением протокола ARP можно отнести к условно активным, так как они требуют выполнения определенных действий в сети (в том время как перехват пакетов с помощью анализатора протоколов можно отнести к пассивным атакам). С точки зрения атакующего, именно активные атаки в состоянии принести ему наибольший успех. Поэтому администратору сети необходимо иметь четкое представление об их механизме. Далее, в главе 5, рассматриваются основы атак типа spoofing (имитация соединений — их можно также отнести к классу атак DoS), которые достаточно популярны и предоставляют злоумышленнику широкие возможности. Но они относительно сложны в реализации, и атакующий, кроме всего прочего, должен надеяться на свою удачу. В противоположность этим атакам, атака на протокол ARP (по аналогии ее Можно также назвать ARP spoofing) несравненно проще в реализации.
Несмотря на то что сама возможность атаки ARP spoofing подразумевает Доступ к сегменту локальной сети, она может быть удачным дополнением при Проведении комплексной атаки, когда атакующий уже выявил существование реши в системе безопасности и получил контроль над одним из компьютеров в сегменте. Собственно, сама вероятность атаки посредством протокола ARP в°зможна ввиду его простоты и отсутствия элементов защиты. Как нетрудно Догадаться, целью атаки является попытка выдать один хост за другой с помощью рассылки ложных сообщений протокола ARP.
Предположим, что атакующий желает выдать свой компьютер сегмента з другой, считая, что последний имеет некоторые привилегии при доступе к сет веру. Один из сценариев проведения атаки подразумевает создание одинаковы IP-адресов. Однако такой подход ненадежен, так как большинство современны операционных систем поддерживают механизм обнаружения совпадающих ад ресов в сети с последующим оповещением пользователей. Такая схема работа необходима для быстрого поиска ошибок в конфигурации IP-адресов.
Однако даже такая ситуация играет на руку атакующему. В Интернете не та] сложно найти программу (например, send_arp.c), которая посылает ответы прото кола ARP на соответствующие запросы, и в этих ответах возвращается требуема: информация — IP и МАС-адреса. Обратите внимание на то, что при отправк сообщений протокола ARP в сеть другие устройства в сети будут их принимат: и учитывать даже в том случае, если не нуждаются в них.
Естественно, из-за устаревания информации в кэше протокола ARP рассы лаемые сообщения следует повторять, причем частота повторения зависит oi конкретной операционной системы, однако 40 секунд должно хватить для большинства систем. Но может возникнуть проблема с некоторыми системами, которые пытаются обновить записи в кэше с помощью посылки целенаправленны! запросов ARP по кэшируемым адресам, для того чтобы убедиться в том, чи адреса активны. Это в силах несколько помешать злоумышленнику, так как н исключается изменение записи ARP для компьютера-жертвы, которая был, только что подменена атакующим.<
ПРИМЕЧАНИЕ?
На маршрутизаторах Cisco Systems администратор имеет возможность вручную установить врем; хранения информации в кэше. Для этого следует воспользоваться командой arp timeout с пара метром, указывающим промежуток времени в секундах. Команда выполняется в режиме конфигури рования интерфейсов и соответственно влияет на записи, относящиеся именно к этому интерфей су. По умолчанию параметр установлен в 14 400 секунд, что соответствует четырем часам. Есл! в качестве параметра указать значение 0, то маршрутизатор не будет помещать записи в кэш Для получения информации о текущем значении таймера выполните команду show Interface: .
Router#sh 1 nt eO
ARP type: ARPA, ARP Timeout 04:00:00'
Рассмотренная атака работает в пределах локальной сети, хотя вообще сфер! ее воздействия ограничена только областью распространения пакетов ARP, Т( есть не очень далеко, так как эти сообщения не маршрутизируются в распреде ленную сеть. Однако одним из расширений рассматриваемой атаки может быть подмена адреса маршрутизатора. Например, вполне допустима ситуация, когда какой-либо пользователь в локальной сети, подменяя маршрутизатор, выдав фальшивое приглашение Telnet администратору сети с просьбой ввести иМ1 и пароль доступа.
Вообще говоря, работа с протоколом ARP предоставляет довольно широки возможности атакующему. Имеются шансы блокировать работу практичен любого компьютера в локальной сети. Самый простой способ, хотя и не сам!
лежный, это анонсирование несуществующего адреса. Его ненадежность в том, что операционная система быстро обнаружит тот факт, что опа не получает ответ и пошлет новый запрос ARP. Оптимальной является подстановка адреса пугого работающего компьютера. Последующее поведение жертвы в этом случае зависит от конкретной реализации операционной системы, но чаще всего она будет посылать различные пакеты некорректному получателю, который будет
их игнорировать.
Другой способ использования особенностей протокола ARP заключается в указании в сообщении одинакового IP-адреса отправителя и получателя. Некоторые системы используют подобные сообщения в то время, когда эта система объявляет о себе в сети и кэширует информацию. Таким образом, одним общением ARP можно нарушить работу всей сети.
СОВЕТ-
Говоря о вероятности атак изнутри, следует также обратить внимание на протокол 802.1 spanning tree, с помощью которого атакующий также способен нарушить работу сети. Но только в том случае, если этот протокол используется в сети.
3
Дальнейшая настройка маршрутизатора
В этой главе продолжается рассмотрение базовой работы с маршрутизатора^ Cisco Systems, причем упор делается на работу со службами стека TCP/IP, ой торых рассказывалось в предыдущей главе. .
Разрешение адресов маршрутизатором
Когда в пользовательском или привилегированном режиме вводятся символьнь данные, операционная система подразумевает, что введенные символы соотве' ствуют команде на выполнение. В том случае, если это не команда, то предпол гается, что это имя хоста (host name), с которым следует установить е!щ 'На сетевом уровне эталонной модели OSI устройства в сети идентифициД^Я с помощью адресов, а не имен. Таким образом, маршрутизатору необходимо буф выполнить преобразование имени в адрес. Если говорить о стеке протоколе* TCP/IP, то существует два способа разрешения адресов (address resolution^ Первый способ использует службу DNS, а второй основан на локальной таблице соответствия имен хостов их адресам (local host table).;
■ Служба системы доменных имен (DNS, Domain Name System) представляем собой приложение, работающее на сервере, которое принимает запросы на прет; образование имен и в ответ высылает найденные адреса хостов. Операционная^ система Cisco IOS способна посылать запрос на сервер имен для установлений сеанса Telnet или выполнения других действий (например, на обработку команд ды ping). Еозможность посылки запросов серверу DNS включена по умолчанию^ при этом адрес сервера соответствует значению 255.255.255.Й5, что являете# Тийро^овешательным адресом протокола IP. То есть если оставить Данные н,^ стройки без изменения, то маршрутизатор будет рассылать широковещательны# , запрос по всем своим интерфейсам. В последнем случае сервер DNS должен н^| 3 ходиться в локальной сети, напрямую подключенной к маршрутизатору.
-* Если администратор сети не настроил адрес сервера DNS и не хочет, что^ маршрутизатор посылал широковещательный запрос на разрешение имени, Й может воспользоваться командой no ip domain-lookup. Соответственно, при выпД
яении этой команды без префикса по маршрутизатор будет осуществлять поиск, что и определено по умолчанию. Ниже приведен пример, в котором с помощью данной команды маршрутизатору запрещается выполнение разрешения имени.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#no ip domain-lookup
Router(config)#exit
Router#ping www.cisco.com
Translating "www.cisco.com"
X Unrecognized host or address, or protocol not running.
Router#
Обычно на маршрутизаторе указывается адрес сервера(ов) DNS, поэтому он посылает запросы напрямую по известному адресу. Следующий пример демонстрирует работу команды ping с указанием имени сервера в качестве параметра. Как видно из примера, маршрутизатор выполнил преобразование имени в адрес с помощью известного сервера DNS.
Router>ping www.cisco.com
Translating "www.cisco.com".. .domain server (193."124.83.69) [OK]
Type escape sequence to abort.
Sending 5. 100-byte ICMP Echos to 198.133.219.25. timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 204/206/212 ms
Администратор сети может настроить до шести известных ему адресов серверов DNS, выполнив команду ip name-server с адресом (адресами) сервера в качестве параметра, в глобальном режиме конфигурирования.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip name-server ?
A.B.C.D Domain server IP address (maximum of 6)
Router(config)#ip name-server 193.124.22.65
Напомним, что есть два варианта разрешения имени, один из которых (использование сервера DNS) был рассмотрен выше. Второй вариант основан на установлении соответствия между именами устройств и их адресами при помощи локальной таблицы. Администратор сети может работать с данной таблицей на маршрутизаторе, помещая в нее записи посредством команды^ip host, выполняемой в глобальном режиме. Эта команда имеет параметры, первый из которых является именем устройства, а остальные соответствуют его IP-адресам. Причем если администратор сети устанавливает сеанс Telnet с устройством по его имени, то маршрутизатор будет по очереди использовать указанные адреса в процессе подключения. А при выполнении таких команд, как ping или traceroute, маршрутизатор примет во внимание только первый адрес.
Router#ping cisco
Translating "cisco"...domain server (193.124.83.69) (193.124.22.65)
% Unrecognized host or address, or protocol not running.
Router#conf1gure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(conf1g)#ip host cisco 198.133.219.25
Router(conf1g)#ex1t
Router#ping cisco
Type escape sequence to abort.Я
Sending 5. 100-byte ICMP Echos to 198.133.219.25, timeout 1s 2 seconds:я
111J
Success rate 1s 100 percent (5/5). round-trip m1n/avg/max = 204/218/276 ms
В варианте локальной таблицы маршрутизатор всегда пытается проверить соответствие имени до того, как отошлет запрос серверу DNS. Администратор сети имеет возможность просмотреть содержимое этой таблицы с помощью ко^ манды show hosts, выполняемой в пользовательском режиме.3
Router>show hosts
Default domain 1s not set Name/address lookup uses domain
service
Name servers are 193.124.83.69.
193.124
22.65
■1
HostFlags
Age
Type
Address(es)
www.c1sco.com(temp. OK)
1
IP
198.133.219
25
cisco(perm. OK)
0
IP
198.133.219
25
1
Результат выполнения команды содержит список устройств с их адресам^ которые известны маршрутизатору. В выходной таблице присутствует столбе! Flags, который указывает на тип записи. Это может быть постоянная запись (perm) которая была вручную добавлена в таблицу с помощью команды ip host, или вр^ менная запись (temp). Временной запись является в том случае, если она был) получена в результате запроса к серверу DNS. Временные записи добавляются в таблицу, так как маршрутизатор кэширует результаты разрешения имен, чтобь не повторять запрос для одного и того же имени устройства. Для очистки Tas’ лицы можно воспользоваться командой clear host с указанием имени устройства запись о котором нужно удалить, или с символом * для удаления всех записей Для выполнения этой команды следует перейти в привилегированный режим, |
Работа с интерфейсами и портами маршрутизатора
Настройка индивидуальных интерфейсов выполняется в режиме конфигурирс вания интерфейсов или подинтерфейсов. Для перехода в эти режимы следуя выполнить команду interface, находясь в глобальном режиме. Упомянутая комая ^ да имеет два параметра: тип интерфейса (подинтерфейса) и его номер. ‘1 ц Все интерфейсы, доступные на маршрутизаторе компании Cisco Systen)] 1, делятся на два_основиых типа: физические и логические. Первый тип характеру ^ зуется тем,^б‘Ън’‘им^8¥‘^8далючетае^вне маршрутизатора (например, это моЖ быть интерфейс Ethernet в локальную сеть, реализованный с помощью рая
ема RJ45). Второй тип существует только в памяти маршрутизатора. Логический ,-.' интерфейс не имеет внешнего физического подключения и присутствует только \ на уровне настроек маршрутизатора. Так, например, подинтерфейсы представля- . ют собой разновидность логического интерфейса..
Наличие разных типов физических интерфейсов зависит от модели маршрутизатора. Если маршрутизатор имеет физический интерфейс, команды для работы с ним доступны, даже если данный интерфейс не используется. Эти команды также должны вводиться в режиме конфигурирования интерфейсов.
Ciscol601#configure terminal
Enter configuration commands, one per Une. End with CNTL/Z.
Ciscol601(config)#interface seriall
C1SCO1601(config-1f)#1p addreds 192.168.10.4 255.255.255.0
В приведенном выше примере показана настройка адреса сетевого уровня протокола IP на интерфейсе Seriall. Как видно, для перехода в режим настройки интерфейса была выполнена команда interface seriall в глобальном режиме маршрутизатора, после чего маршрутизатор изменил приглашение на config-if. Из приглашения, выдаваемого маршрутизатором, нельзя узнать, какой интерфейс сейчас находится в стадии настройки..
Логические интерфейсы, помимо всего прочего, отличаются от физических тем, ^Тог администратор сети может создавать их по мере необходимости. Примерами логических интерфейсов служат интерфейсы loopback и tunnel. Логический интерфейс loopback создается, если требуется интерфейс, ни к чему не подключенный и отвечающий, например, за управление маршрутизатором с консоли по протоколу SNMP. Такое решение обоснованно в случае, если управление маршрутизатором осуществляется через один интерфейс, который периодически переходит в состояние down. При этом система управления способна посчитать, что не работает весь маршрутизатор, а последнее неверно.
Другой логический интерфейс — tunnel — используется для передачи трафи- ■ ка сетевого протокола через распределенную сеть, не поддерживающую работу с соответствующими пакетами. Чаще всего это необходимо для передачи трафика протокола IPX через сеть, понимающую только протокол IP. В такой передаче участвуют два маршрутизатора.
Для создания логического интерфейса также следует воспользоваться командой interface. Вот пример создания интерфейса loopback.
^Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
■ Router(config)#interface loopback 0
Router(config-if)#ip address 192.168.11.1 255.255.255.0
. n ^огические интерфейсы могут иметь любой номер, отсчитываемый с нуля, к представленном выше примере был создан интерфейс loopback с номером 0. Марш- ■ Ь РУтизатор немедленно переводит его в состояние up, делая интерфейс доступным ■ Для работы. Это можно проверить, выполнив команду show interface loopbackO.
■ Router#show interfaces loopbackO■
LoopbackO is up, line protocol is up■
Hardware is Loopback...
Internet address is 1-92.168.11.1/24
При создании распределенной сети с применением таких технологий, ке£ Frame Relay или Х.25, наибольший интерес представляют подинтерфейсы (sub interfaces). Это разновидность логических интерфейсов, привязанных к определен ному физическому. Тип подинтерфейса, в свою очередь, зависит от физической интерфейса. Несмотря на то что подинтерфейсы наследуют некоторые характс ристики физического интерфейса, к которому они привязаны, они могут имет свои собственные настройки сетевого уровня, например индивидуальный 1Р-адре(
ИЗ ОПЫТА
Понимание механизма подинтерфейсов наиболее актуально при подключении маршрутизатора к се-Ц Frame Relay. В такой ситуации на маршрутизатор (точнее, на один физический порт) может замы каться несколько логических (виртуальных) соединений от других маршрутизаторов в сети. Такщ соединения называются постоянными виртуальными соединениями (Permanent Virtual Circuits — PV(j и, как правило, они формируются провайдером услуг сети Frame Relay. Выделяют два типа поди! терфейсов в сети Frame Relay, зависимые от топологии виртуального соединения: «точка-точка (двухточечного, point-to-point) и «точка-группа» (многоточечного, multipoint). Первый тип обслужй вает только одно постоянное виртуальное соединение, в то время как второй —- несколько такй соединений.
г.
- Несмотря на то что подинтерфейсы привязаны к физическому интерфейс^ ■ администратор сети может вручную перевести один из них в нерабочее состО^ „ ние (down). Однако если в нерабочее состояние переходит физический интед фейс, это в полной мере относится и к привязанным к нему подинтерфейсаМ
« В том случае, если подинтерфейс обслуживает одно постоянное виртуальное со единение, которое по каким-либо причинам перестает поддерживаться провай дером, подинтерфейс также переходит в нерабочее состояние.4
Схема именования подинтерфейсов включает в себя имя физического ин-1 терфейса с его номером, за которыми следует другой номер, отделенный точко^ Так, например, если интерфейс маршрутизатора SerialO подключен к сети Frany Relay и нужно настроить подинтерфейс, поддерживающий постоянное виртуал^ ное соединение, то его имя будет SerialO. 1 (нумерация подинтерфейсов начину ется с 1). В приведенном ниже примере показана настройка подинтерфейса с н» мером SerialO.7, который соответствует постоянному виртуальному соединений и имеет тип «точка-точка»..
Router#configure terminal"
Enter configuration commands, one per line.End with(CNTL/Z..
Router(config)#interface serialO1
Router(config-if)#interface serialO.7 point-to-point.
Router(config-sub)#description connected toWharehouse*;
Router(config-sub)#ip unnumbered ethernet 0.
Router(config-sub)#frame-relay interface-dlci 224
Router(config-fr-)#exit&
Вернемся к вопросу инкапсуляции данных сетевого и высших уровней в едИ ницы передачи информации (MTU), использующиеся на канальном ypoBHf
Напомним, что для интерфейсов локальной сети применимы различные виды инкапсуляции, в зависимости от настроенного протокола. Так, для интерфейса Ethernet и протокола IP характерна инкапсуляция ARPA. Для интерфейсов ял^альной сети может использоваться только один тип инкапсуляции, который зависит от устройства, подключенного к маршрутизатору, с которым он взаимодействует на канальном уровне. Применительно к технологии Frame Relay на интерфейсе должна быть задана инкапсуляция Frame Relay. Для того чтобы настроить необходимый тип инкапсуляции, следует выполнить команду encapsulation, в режиме конфигурирования интерфейсов с параметром-словом, указывающим на тип инкапсуляции.
Router#conf1gure terminal
Enter configuration commands, one per Une. End with CNTL/Z. Router(conf1g)#1nterface serial 1
* Router(conf1g-1f)#encapsulat1on ?
atm-dxiATM-DXI encapsulation
frame-relay Frame Relay networks hdlcSerial HDLC synchronous
lapbLAPB (X.25 Level 2)
pppPoint-to-Point protocol ■
smds Switched Megabit Data Service (SMDS) x25X.25
Хорошей практикой является настройка описания (description) на каждом интерфейсе, которое помогает понять, за что отвечает тот или иной интерфейс. Описание представляет собой текстовую информацию, записываемую в конфигурационный файл. Для создания описания предусмотрена команда description, выполняемая в режиме конфигурирования интерфейсов....
Router#configure terminal:
Enter configuration commands, one per Une. End with CNTL/Z.
Router(config)#interface seriall
Router(config-if)#descript1on This Interface 1s shutdown
Администратор сети может ввести любую информацию, но, на взгляд автора, наиболее полезным будет указание места подключения данного интерфейса. При этом администратор ограничен в наборе текста 240 символами. Созданное описание отображается при выполнении команды show Interfaces. Ниже приведен пример выполнения этой команды для подинтерфейса SerialO.7, представ- Дяющего собой постоянное виртуальное соединение сети Frame Relay с удаленным объектом. Как видно, описание помогает легко определить, какой именно объект находится на другом конце данного виртуального соединения.
Router#show Interfaces serial0.7■
Ser1al0.7 1s up. Une protocol 1s up'
Hardware 1s QUICC Serial
Description: connected to Wharehouse
Interface 1s unnumbered. Using address of EthernetO (192.168.3.254)
MTU 1500 bytes. BW 1544 Kbit, DLY 20000 usee, rely 255/255. load 1/255
Encapsulation FRAME-RELAY
Выполняя команду show interfaces, администратор сети «снимает показание различных счетчиков (counters), показывающих объемы передаваемой через hi терфейс информации. В его распоряжении есть команда, которая позволяет о, нудить эти счетчики. Выполнение в привилегированном режиме команды cle counters без параметров приведет к обнулению счетчиков для всех интерфейсе но только после подтверждения этого действия. Можно обнулить счетчики jy
определенного интерфейса, указав его имя и номер в качестве параметра команды.
Ранее мы уже рассматривали терминальные порты, а сейчас остановимся щ их настройке. Для того чтобы начать настраивать терминальный порт, следуем перейти в соответствующий режим (line configuration mode). Для этого предн^ значена команда line, выполняемая в глобальном режиме. При указании номера порта применяется либо абсолютная, либо относительная нумерация. В случай последней обязательно следует указать тип порта, например CON или VTY.i Ниже приведен пример перехода в режим настройки консольного порта.й
Router#configure terminalj
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#11ne console 0i<
Router(config-lin)#h
На маршрутизаторе существует только один консольный порт, следовательно,' его относительный (и абсолютный тоже) номер всегда равен нулю. После выполз нения команды line изменяется приглашение маршрутизатора. Оно указывает на': то, что теперь работа ведется в другом режиме настройки. Настройка порта не: ограничена одним вариантом, например виртуальные порты VTY администратор вправе настраивать как индивидуальный порт или как группу. Как уже отмечаг лось, обычно все порты VTY на маршрутизаторе имеют одинаковые настройки^ следовательно, можно указывать группу номеров, разделяемых пробелом. 1J
Router(config)#line vty 0 4
Router(config-lin)#
^осле 10 минут неактивности маршрутизатор автоматически отключит сеанс, установленный на терминальном порте. Администратор сети имеет возможность; изменить этот интервал с помощью команды exec-timeout, требующей указания, двух параметров. Первый параметр определяет минуты ожидания, а второй -гх секунды. Если задать нулевые параметры, это приведет к тому, что маршрутизатор'] не станет отключать сеанс автоматически, а будет ожидать ручного отключения.у
Router(conf1g)#11 ne console О
Router(config-lin)#exec-timeout О О
В распоряжении администратора есть возможность принудительно завершить , тот или иной сеанс работы с маршрутизатором. Это отключение осуществляется командой clear line. Если администратор обнаружил, что кто-то, не имеющий на: то особых оснований, выполнил подключение к маршрутизатору, например не-,
рез сеанс Telnet, то в его власти выполнить указанную команду с параметром,^1
соответствующим номеру виртуального порта. Покажем это на примере. Пред-
положим, что было осуществлено подключение с удаленного маршрутизатор*
Cisco 805 к центральному Cisco 1601 с адреса 192.168.3.254.
C1sco805#telnet 192.168.3.254
Trying 192.168.3.254 ... Open
Администратор сети, раоотая с центральным маршрутизатором, может просмотреть текущие подключения к нему с помощью команды show users, которая покажет, с каких адресов выполнялось подключение. Символом * отмечено подключение самого администратора. Обнаружив факт подключения с адреса 192.168.7.254, администратор вправе принудительно закрыть сеанс посредством команды clear line 4.
Ciscol601#show usersLineUser*3 vty0idle4 vty1idleC1scol60l#cI ear line 4 [confirmly [OK]Ciscol601#show usersLineUser*3 vty0idle4 vty1idleC1scol60l#cI ear line 4 [confirmly [OK]Hcst(s)Hcst(s)Idle Location 00:00:00 192.168.3.20 00:00:11 192.168.7.254Idle Location 00:00:00 192.168.3.20 00:00:11 192.168.7.254
Ciscol601#show users
LineUser
*3 vty0idle
4 vty1idle
C1scol60l#cI ear line 4 [confirmly [OK]
Ciscol601#show users
LineUser
*3 vty0idle
4 vty1idle
C1scol60l#cI ear line 4 [confirmly [OK]
Hcst(s)
Hcst(s)
Idle Location 00:00:00 192.168.3.20 00:00:11 192.168.7.254
Idle Location 00:00:00 192.168.3.20 00:00:11 192.168.7.254
После этого на удаленном маршрутизаторе появится сообщение, говорящее о том, что соединение было закрыто: Connection to 192.168.3.254 closed by foreign host.
Работа с маршрутизатором через сеанс Telnet
Очень удобным средством управления маршрутизатором является возможность доступа к нему через распределенную сеть путем установления сеанса Telnet на одном из виртуальных портов маршрутизатора. При создании сеанса требуется указать либо адрес, либо имя удаленного маршрутизатора. Причем подключение можно делать как с компьютера, с которого осуществляется управление (из одноименной программы Telnet, например в операционных системах Microsoft Windows NT/2000), так и прямо с маршрутизатора. В последнем случае команда telnet вводится либо в пользовательском, либо в привилегированном режиме.
Ciscol601#te"net 192.168.7.254
Trying 192.168.7.25-1 ... Open
User Access Verification
Password:******
Cisco805>
Если вместо адреса удаленного маршрутизатора было указано его имя, то маршрутизатор, с которого инициируется сеанс Telnet, будет пытаться выполнить процедуру разрешения имени. Хотя в примере вместо пароля указаны сим
; Волы *, на самом деле при вводе пароля на экране ничего не отображается. На- ^ . помним, что если бы на маршрутизаторе Cisco 805 не был настроен пароль 'для .^’ 1 терминальных портов VTY, то установить сеанс Telnet не удалось бы вообще. X
^Ля того чтобы после установления сеанса Telnet с удаленным маршрутизатором /
временно отложить его, необходимо «подавить» (suspend) этот сеанс, которьв остается активным и к нему можно вернуться позже без прохождения повтог ной авторизации. Для подавления сеанса нужно нажать следующую комбинацию^ клавиш: Ctrl+Shift+6 и х (сначала одновременно нажимаются клавиши Ctrl+Shift+6t а затем клавиша х).
Cisco805><Ctr1 -Shift-6><x>
C1SCO1601#с
Хотя после нажатия такой комбинации мы вернулись в приглашение маршру» тизатора Cisco 1601, сеанс Telnet с удаленным маршрутизатором по-прежнему активен, в чем можно убедиться с помощью команды show sessions, которая показывает подавленные сеансы Telnet. '
После подавления одного сеанса Telnet можно установить еще один, а затем подавить его и т. д. В этом случае после выполнения команды show sessions будет показан список всех удаленных устройств, с которыми установлены ceaS сы Telnet. Для примера установим с маршрутизатора Cisco 1601 еще один се* анс Telnet, а затем переведем его в подавленное состояние и выполним команду show sessions. .
С1 sco!601#show sessions
Conn HostAddressByteIdleConn Name
1 192.168.7.254192.168.7.25400192.168.7.254.
* 2 192.168.4.254192.168.4.25400192.168.4.254T'
Следует обратить внимание на символ *. Он указывает на сеанс, который был подавлен последним. Если теперь просто нажать клавишу Enter в пустой командной строке (не вводя никакой команды), маршрутизатор, с которой устанавливались сеансы, восстановит тот из них, который отмечен символом *„
C1scol60l#<Enter>
[Resuming connection 2 to 192.168.4.254 ... ]
Clsco805>
Если требуется восстановить сеанс Telnet, не отмеченный символом *, можно воспользоваться командой resume. В качестве параметра команды нужно указать номер сеанса, полученный из результата выполнения команды show sessions. '
C1scol601#show sessions
Byte Idle Conn Name0 '6192.168.7.25400192.168.4.254Byte Idle Conn Name0 '6192.168.7.25400192.168.4.254Conn HostAddress
Byte Idle Conn Name
0 '6192.168.7.254
00192.168.4.254
Byte Idle Conn Name
0 '6192.168.7.254
00192.168.4.254
1 192.168.7.254192.168.7.254
* 2 192.168.4.254192.168.4.254
Ciscol601#resume 1
[Resuming connection 1 to 192.168.7.254
C1sco805>
Для того чтобы закрыть сеанс Telnet с удаленным маршрутизатором, слет выполнить команду disconnect, с параметром, соответствующим номеру сеанса. Если выполнить команду без параметра, то она завершит сеанс, отмеченный символом *.
Ciscol601#show sessions
Conn Host
Address
Byte
Idle
Conn Name
* 1 192.168.7.254
192.168.7.254
0
0
192.168.7.254
2 192.168.4.254
192.168.4.254
0
3
192.168.4.254
Ciscol601#disconnect
Closing connection to
192.168.7.254
[confirm]y
C1scol60l#show sessions
Conn Host
Address
Byte
Idle
Conn Name
* 2 192.168.4.254
192.168.4.254
0
3
192.168.4.254
Протокол CDP
Протокол CDP (Cisco Discovery Protocol) разработан компанией Cisco Systems и является протоколом канального уровня. По умолчанию он работает на большинстве произведенного компанией оборудования и используется для оповещения соседних устройств о присутствии базовой информации о конфигурации. Так как протокол работает на канальном уровне эталонной модели OSI, он не является маршрутизируемым и работает в любых сетях, поддерживающих тип инкапсуляции SNAP, например Ethernet, FDDI, HDLC, PPP и Frame Relay. Устройства, поддерживающие протокол CDP, периодически рассылают сообщения через интерфейсы, на которых данный протокол настроен. При этом промежуток между посылками сообщений составляет 60 секунд. После получения сообщений в памяти устройства формируется таблица, которая содержит информацию о соседях. Кроме того, запускается таймер, который начиная со 180 секунд ведет обратный отсчет. При достижении таймером нулевого значения запись об устройстве удаляется из таблицы. На маршрутизаторах компании Cisco Systems администратор имеет возможность просмотреть таблицу протокола CDP с помощью команды show cdp neighbors.
Ciscol601#show cdp neighbors
Capability Codes: R - Router. T - Trans Bridge. В - Source Route Bridge S - Switch. H - Host. I - IGMP. r - Repeater
Device ID Ciscol005_l Cisco805_2 Cisco805_3 Ciscol005_4 CiscolOOS 5Device ID Ciscol005_l Cisco805_2 Cisco805_3 Ciscol005_4 CiscolOOS 5HoldtmeCapabilityPlatformPort; ID122R1000Ser0.1124RCisco C805Ser0.1152RCisco C805Ser0.1123R1000Ser0.1125R1000Ser0.1HoldtmeCapabilityPlatformPort; ID122R1000Ser0.1124RCisco C805Ser0.1152RCisco C805Ser0.1123R1000Ser0.1125R1000Ser0.1Local IntrfceSer 0.6Ser 0.5Ser 0.3Ser 0.1Ser 0.2Local IntrfceSer 0.6Ser 0.5Ser 0.3Ser 0.1Ser 0.2
Device ID Ciscol005_l Cisco805_2 Cisco805_3 Ciscol005_4 CiscolOOS 5
Device ID Ciscol005_l Cisco805_2 Cisco805_3 Ciscol005_4 CiscolOOS 5
Holdtme
Capability
Platform
Port
; ID
122
R
1000
Ser
0.1
124
R
Cisco C805
Ser
0.1
152
R
Cisco C805
Ser
0.1
123
R
1000
Ser
0.1
125
R
1000
Ser
0.1
Holdtme
Capability
Platform
Port
; ID
122
R
1000
Ser
0.1
124
R
Cisco C805
Ser
0.1
152
R
Cisco C805
Ser
0.1
123
R
1000
Ser
0.1
125
R
1000
Ser
0.1
Local Intrfce
Ser 0.6
Ser 0.5
Ser 0.3
Ser 0.1
Ser 0.2
Local Intrfce
Ser 0.6
Ser 0.5
Ser 0.3
Ser 0.1
Ser 0.2
По результатам выполнения этой команды на маршрутизаторе Cisco 160 видно, что он соединен с пятью соседними маршрутизаторами, от которых был получены сообщения протокола CDP. Также выдается информация о таймер и о платформе соседнего маршрутизатора (1000, Cisco С805). Кроме того, можн узнать, через какой интерфейс были получены сообщения этого протокола. Дл того чтобы увидеть полное содержимое таблицы, выполним команду show cdp neighbors detail.
C1SCO1601 #show cdp neighbors detail1
Device ID: Cisco805_2
Entry address(es):
IP address: 192.168.4.254
Platform: Cisco C805, Capabilities: Router
Interface: 5erial0.5. Port ID (outgoing port): SerialO.l
Holdtime : 143 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) C805 Software (C805-Y6-MW). Version 12.0WXM, EARLY DEPLOYMENT •!■
RELEASE,s>
SOFTWARE (fcl)й
ТАС: Home :SW: IOS Specials forinfo1(''
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Thu 17-Jun-99 16:51 by Unda
Можно получить и более подробную информацию о соседних маршрутизатф1 рах, такую, например, как адрес сетевого уровня, сведения об используемой ве^' сии операционной системы Cisco IOS. Информация об адресе сетевого уров^- бывает полезной в случае, когда требуется установить связь с маршрутизатором^ адрес которого неизвестен. В дополнение к полному перечню информации о СО,-) седних маршрутизаторах, выполнив команду show cdp entry с параметром, обозначающим имя устройства из таблицы, можно просмотреть индивидуальную запись в таблице CDP. .
Администратор сети в состоянии управлять работой этого протокола на марш^ рутизаторе в целом или только на нескольких его интерфейсах. Если необхо
димо отключить поддержку протокола CDP на определенном интерфейсе, нуж* но выполнить команду no cdp enable в режиме конфигурирования интерфейсов.
Для отключения протокола на всех интерфейсах одновременно следует, находясь в глобальном режиме, ввести команду no cdp run. Кроме того, может потребоваться изменить значение интервала отправки сообщений CDP (update interval),
которое будет воздействовать на все интерфейсы сразу. Это делается с помощьк команды cdp timer, где параметром является количество секунд между обновле
ниями. Для настройки таймера, работающего с таблицей соседей CDP, служи команда cdp holdtime с аналогичным параметром. После выполнения всех настрО
ек протокола можно просмотреть его статус с помощью команд show cdp и show cdp interface.
Ciscol601#show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Ciscol601#show cdp Interface serial0.1■
SerialO.l 1s up. Une protocol 1s up
Encapsulation FRAME-RELAY
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
' Первая команда показывает значения таймера и интервала обновления, а вторая выводит информацию по протоколу CDP для конкретного интерфейса (или всех интерфейсов) маршрутизатора.
СОВЕТ
Следует отметить, что на маршрутизаторах, располагающихся на границе частной сети и Интернета, поддержку протокола CDP обычно отключают, чтобы снизить риск получения злоумышленником важной информации о внутренней структуре сети.
Работа со встроенным отладчиком
Стоит отметить еще одну полезную возможность операционной системы Cisco IOS, а именно получение отладочной информации в целях предсказания реакции операционной системы на определенные действия. Обычно это бывает необходимо для решения возникающих проблем или просто ради эксперимента. Для этой цели предназначена команда debug, позволяющая отслеживать различные типы активности, соответствующие происходящим внутри маршрутизатора процессам.
Чтобы узнать возможные варианты использования этой команды и получить справку, следует ввести после ее имени знак вопроса. По умолчанию вывод отладочной информации включен для консольного порта маршрутизатора. К команде det)ug следует относиться осторожно, так как ее выполнение связано с боль- шои загрузкой маршрутизатора и значительными объемами отображаемой на экране информации. Ниже приведен пример отладочной информации маршрутизатора для протокола TCP (команда terminal monitor позволяет просматривать отладочную информацию при работе в сеансе Telnet).
Router#terminal monitor
Router#debug 1p top packet vty 0
TCP Packet deougging is on for line number 3
. Router#■
t 3w3d: tcp3: 0 ESTAB 192.168.3.20:4175 192.168.3.254:23 seq 2023153705 LDATA 64 ACK 3169145 PSH WIN 2949
3w3d: tcp3: I ESTAB 192.168.3.20:4175 192.168.3.254:23 seq 3169145 ACK 2023153769 WIN 7802
3w3d: tcp3: 0 ESTAB 192.168.3.20:4175 192.168.3.254:23 seq 2023153769 DATA 216 ACK 3169145 PSH WIN 2949
3w3d: tcp3: I ESTAB 192.168.3.20:4175 192.168.3.254:23 seq 3169145 ACK 2023153985 WIN 7586
3w3d: tcp3: 0 ESTAB 192.168.3.20:4175 192.168.3.254:23 seq 2023153985 DATA 217 ACK 3169145 PSH WIN 2949
Если необходимости в отладке нет, этот вывод можно отключить, выпол- i нив команду с префиксом по. Когда для одного маршрутизатора одновременно। включено несколько отладочных терминалов, выключить их все сразу позволя-: ет команда no debug all. ’
■ У
4
Протокол ICMP
Введение
Протокол управляющих сообщений сети Интернет (ICMP, Internet Control Message Protocol) был задуман и реализован как средство для уведомления о возникающих ошибках в Сети и для формирования ответов на простые запросы, в расчете на ненавязчивое потребление сетевых ресурсов и внесение минимальных возмущений в картину общего трафика. Протокол описан в документе RFC 972, а его последующие обновления в документах RFC 896 (Source Quench — подавление источника), RFC 950 (Address Mask Extensions — расширения адресной маски), RFC 1191 (Path MTU Discovery — метод обнаружения MTU в пути до получателя) и RFC 1256 (Router Discovery — обнаружение маршрутизатора).
Без знания теоретических основ трудно осмыслить трафик, порождаемый протоколом ICMP, однако стоит обратить внимание, что в сети протокол будет работать и без понимания администратором принципов его функционирования, то есть его можно воспринимать как данность. Настройки этот протокол практически не требует. По сравнению с другими протоколами ICMP используется реже и полосу пропускания при нормальной работе практически не занимает.
Наибольший интерес представляет нетрадиционное, не предусмотренное разработчиками протокола его использование. И если администратор сети имеет четкое представление, чем оно может обернуться, то ему по силам продумать стратегию защиты и реализовать саму защиту сети от такого применения. По крайней мере, знание особенностей нетрадиционного использования протокола ICMP позволит понять, какие именно цели преследует атакующий. Кстати, для V сбора информации при сканировании из сети Интернет злоумышленники часто прибегают именно к этому протоколу.
Со временем возможности протокола ICMP позволили атакующим взять его на вооружение качестве инструмента противоправных действий. По этой причине важно понимать отличие в работе протокола в легальных условиях от случая проведения злонамеренных (malicious) операций. В процессе рассмотрения материала будут освещены некоторые аспекты работы протокола, начиная, естественно, с базовых сведений о нем. Затем пойдет речь о способах, какими IMP осуществляет поиск работающих устройств (хостов) в сети. А дальше чита- I тель найдет информацию о том, какой трафик этого протокола можно встретить к в локальной сети при нормальных условиях и при его противоправном исполь-
зовании. Опираясь на эту информацию, можно будет попробовать поискать н корректные (не с точки зрения протокола, а с позиций права) сообщения в свое сети. В заключение будут даны практические рекомендации о способах защит сети от входящих из сети Интернет сообщений протокола ICMP с помощь списков управления доступом, настроенных на граничном устройстве.
Сделаю небольшое отступление и напомню,.что широко распространенно протокол TCP (главу 5) примечателен тем, что выполняет массу действий д] гарантированной надежной передачи данных. В противовес ему, протокол UeL хотя и не гарантирует таковую, тем не менее требует наличия на стороне серве* ра порта, с которым он будет взаимодействовать. Простой запрос, например, Ш' прос по определению активности хоста в сети (известен как ping), не нуждается в портах для взаимодействия и в повышенной надежности передачи. Кроме того, представьте ситуацию, когда маршрутизатор в сети обнаружил ошибк;' и ему необходимо известить отправителя о данном факте, то как лучше это еда лать? Протокол TCP — довольно мощный механизм, способный обрабатывав самые разнообразные сбои в пересылке данных. Например, если сервер получи! большой объем информации от клиента, он может установить размер своей окна приема равным нулю, указывая на то, что отказывается принимать даннЫ до тех пор, пока содержимое буфера не будет им обработано. В противополож ность протоколу TCP протоколы UDP и IP не настолько развиты для того, чтр бы обеспечивать подобный уровень контроля за ошибками. По этой причине и» в помощь и создан протокол ICMP, формирующий извещения о возникновений проблемных ситуаций и пересылающий их между хостами или между маршру тизатором и хостом.
ЕЕ№■1№■1Следует думать, что читатель имеет представление о модели OSI и стею протоколов TCP/IP, но не грех напомнить кое-какие базовые понятия. Пользователи, как правило, работают на прикладном уровне, представляющем приложения, например Telnet. Далее (учитывая разницу в теории и практической ре^. лизации) следует транспортный уровень, где такие протоколы, как TCP и UD^ обеспечивают взаимодействие между сетевыми устройствами. Ниже располага-:. ется сетевой уровень, отвечающий за доставку дейтаграмм от отправителя к пс^ лучателю. Именно на этом уровне протокол ICMP нашел себе место — там 5^ где и протокол IP. Несмотря на то, что сообщения протокола ICMP инкапсули^ руются в дейтаграммы IP, примыкая к заголовкам последнего, принято считать что уровни этих двух протоколов одинаковы. Общая структура инкапсуляций сообщений протокола ICMP показана на рис. 4.1.■ ;
Е
Е
№■1
№■1
,22.595014 212.62.17.145 191125^03.1 ICMP tchn(ptofj)r<4jiH‘lt
I
B Frame 2 (98 on wire, 98 captured)
В Ethernet 11
В Internet Protocol, Src Addr: 212.62.17.145 (212.62.17.145), Dst AddH 193.125.203.1 (193.125.203.1)
В Internet Control Message Protocol
®i*SEi$M
77771 .1....77771 .1....8МЁ78МЁ700000090 27 Of 11 6c00 06d7 ее3822 08 00 45 00
77771 .1....
77771 .1....
8МЁ7
8МЁ7
00100054 05 f5 00 002c 0116 66d43e 11 91 cl 7d
ПП9П..^h.n. 1. . ПЯ . 0П. .9?. .?■₽.. *xa . 1 9.... 0.1...ROnono. .fU . Oh . ПЛ . гм
Рис. 4.1. Общая схема инкапсуляции сообщений протокола ICMP
Как видно из рисунка, в данном случае базовым является кадр сети Ethernet. Этот кадр обозначен как Ethernet II, в его полях содержатся МАС-адреса получателя и отправителя. Кроме того, предоставляется информация о типе протокола. В кадр Ethernet «завернута» дейтаграмма протокола IP, которая, в свою очередь, как матрешка, инкапсулировала некое сообщение протокола ICMP.
Перехват информации в сетях
Можно с уверенностью заявить, что многие специалисты сталкивались с ситуацией, когда после изучения какого-либо вопроса путем штудирования специализированной литературы чисто теоретические аспекты становятся предельно ясны, но эта ясность куда-то исчезает, как только начинаешь реализовывать полученные знания на практике. Возникают проблемы, которые раньше и не приходили в голову. Подобная аналогия применима и к сети — по умолчанию она работает и практически не требует к себе особого внимания. На сетевом оборудовании мигают лампочки, битики-байтики снуют туда сюда и, вроде бы, пользователи не имеют повода для недовольства. Но стоит только установить анализатор пакетов, как появляется множество вопросов — а почему от этого хоста в сеть был отправлен такой пакет? Что вызвало его отправку и чем это закончится? Отсюда альтернатива: либо оставить все как есть и не забивать себе голову тем, как это все там происходит и почему, либо разбираться до самого конца. Второй путь тернист и предназначен для пытливых умов. Наградой за этот большой
труд станет полное подчинение всех сетевых процессов вашим желаниям, способность реализовать на практике любые поставленные перед вами задачи.
ээДанная глава (как и глава 10 о виртуальных частных сетях) содержит большое количество примеров с перехваченными сетевыми пакетами. По этой причине имеет смысл рассмотреть инструменты, с помощью которых эти перехваты были выполнены. В процессе подготовки материала для главы автору пришлось опробовать несколько программных продуктов, которые предназначены для решения одной задачи — для перехвата и анализа трафика в сети, но при этом имеют множество отличий как в удобстве пользования, так и в представлении информации. Если администратор сети работает с платформой Microsoft Windows, то он может задействовать входящий в установочный комплект Windows NT/2000 Server программный продукт Microsoft Network Monitor. Но, к сожалению, версия эта слегка «обрезана», и для более детального ознакомления с трафиком пред- лагается продукт, включенный в состав комплекта Microsoft SMS Server.
э
э
Далее, можно приобрести очень мощный программный комплекс Observer компании Network Instrumcns или, например, cEye Iris Network Traffic Analizer. начале автор использовал последний продукт, пятнадцатидневная пробная версия которого доступна всем желающим после регистрации с сервера www.eeye.com. днако при всем удобстве работы с этой программой сохранение перехваченного трафика в читаемом виде было делом нс самым легким — приходилось копиро- вать целиком внешний вид окна программы в буфер обмена, а затем с помощью графического редактора «вырезать» нужные куски (именно таким образом были получены фрагменты сегментов TCP, приведенные в следующей главе данной книги). Кроме того, вопрос правомерности подобных действий был до конца не
ясен. В конечном итоге была выбрана программа WinDump, которая свобод-' но распространяется в сети Интернет. Следует отметить, что сама программ^'. WinDump является версией для платформы Windows популярного инструмент^ TCPdump, ориентированного на системы UNIX. Возможности обеих программ, за/' малым исключением, одинаковы и практически все сказанное далее про WinDump, будет верно и для TCPdump. Сам продукт и дополнительную информацию о спо-*! собах его использования можно найти по адресу http://WinDump.polito.it.*’
Программа WinDump представляет собой простой (но не с точки зрениф* функциональности) и компактный перехватчик сетевого трафика. Кстати, именЭ но компактность в большинстве случаев помогает принять решение о том, какой. * именно инструмент подходит больше прочих. Автору часто приходилось устанав-1- ливать программу на разные компьютеры в сети и, как оказалось, вся она целиков помещается на обычный 3,5-дюймовый гибкий диск, оставляя место под доку-т ментацию. Важно отметить, что перед тем как запустить программу WinDump,^ необходимо установить специальный драйвер WinPcap, который также доступен^ по адресу http://winpcap.polito.it.^
При этом был приобретен опыт установки этого драйвера на критичные сер-’/ веры Windows 2000, который показал отсутствие каких-либо проблем. Справед-у ливости ради следует отметить, что один раз, при сборе программой WinDump ' трафика на защитном экране с двумя сетевыми адаптерами, внезапно появился ’ «синий экран смерти», что было не очень приятно. И вдвойне было досадно то,/ что продолжал действовать параметр разрешения записи дампа (dump) памяти/ при сбое системы, не отключенный заблаговременно. В результате, в то время,; пока пользователи сети звонили и спрашивали, что происходит с Интернетом,.- ■’ автор сидел и смотрел на цифры и символы сгенерированного дампа памяти.,? Важно отметить, что хотя процедура установки драйвера не требует перезагрузи., ки системы, ее рекомендуется выполнить. Вообще говоря, если после прочтения, этого материала появится желание поэкспериментировать, то смело ставьте-, драйвер WinPcap на каждый настраиваемый сервер сети — опыт показал, что/ никаких побочных эффектов, как то снижение производительности или перио-- дические сбои, он не привносит.:.,
Сама программа WinDump не требует процедуры установки. Достаточно про-., сто запустить одноименный файл WinDump.exe, как программа сразу начинает ', выводить на экран проходящий через выбранный интерфейс трафик, естествен-г но, при наличии установленного драйвера WinPcap. Собственно, за выбор нуж^' ного интерфейса, на котором следует производить перехват, выбор типа трафика для перехвата и т. п. отвечают параметры командной строки. Если в системе присутствует несколько сетевых адаптеров, то при запуске WinDump можно, указать тот трафик, который вас интересует. Для этого предназначен параметр -i,'^ за которым указывается имя или номер адаптера. Имя, к сожалению, может*у быть не очень удобным для восприятия, номер в этом смысле выигрывает. А что- у бы его узнать, достаточно набрать WinDump -D, в ответ на экран будут выведены^, имена и номера доступных для работы адаптеров.12,
Обычно весь трафик перехватывать не требуется, да и для анализа это слоЖ-Т но — попробуйте запустить программу на загруженном хосте — экран (а именно на экран по умолчанию выводится информация) моментально заполнится и всеЧ это будет малоинформативно. Поэтому следует воспользоваться фильтрамйд
фильтр — это выражение, которое указывает программе, какой тип трафика пе- хватывать. Выражения формулируются на простом языке, фактически набоР ключевых слов. Например, для сбора только трафика TCP нужно выполнить WinDump.exe tcp. Сейчас не будем останавливаться на разъяснении всех ключевых слов, тем более, что они все описаны в документации. Единственное, что хочется отметить, это параметр -F с указанием имени файла, содержащего настроенный фильтр. Его использование удобно, когда записывать фильтрующее выражение в виде параметра командной строки не хочется.
Как уже было отмечено, по умолчанию программа выводит перехваченный трафик на экран в текстовом виде, как показано ниже.
C:\Program Files>WinDump
WinDump: listening on\Device\Packet_{D63D72F6-785A-451E-A7C7-2C6137CE9634} 13:55:13.091782 beetle.alternativa.spb.ru > ALL-SYSTEMS.MCAST.NET: ICMP: router advertisement lifetime 30:00 1: {beetle.alternativa.spb.ru 0} [ttl 1] 13:55:13.292800 1-mk.alternativa.spb.ru.3398 > bobcat.alternativa.spb.ru.53: 84 + PTR? 1.0.0.224.in-addr.arpa. (40) 13:55:14.219554 a-sbd.alternativa.spb.ru.138 > 192.168.3.255.138:
»> NBT UDP PACKEK138) Res=0xll0E 10=0x8036 IP=192 (0xc0).168 (0xa8).3 (0x3).15 6 (0x9c) Port=138 (0x8a) Length=187 (Oxbb) ReS2=0x0
SourceName=A-SBDNameType=0x20 (Server)
DestName=TONameType=0x00 (Workstation)
Однако для проведения последующего анализа чаще всего программа будет настроена на запись перехваченных данных в двоичном виде в указанный файл (так называемый «сырой» вывод — raw output). Если в текстовом формате представляется не вся возможная информация о пакете, то в двоичном виде пакет записывается целиком, включая поле данных.
Для того чтобы начать собирать трафик в двоичном виде, можно выполнить программу с ключом -w <имя файлах Имя указывается для того файла, в который будут записываться данные. Для того чтобы прочитать сохраненные двоичные данные, добавьте параметр -г <имя файлах после этого данные из файла будут представляться в удобном для восприятия виде. Можно и сразу перенаправлять поток перехваченного трафика именно в текстовый файл, в той форме, как его выводит программа WinDump. Однако, несмотря на то, что информация будет полной, она не станет более удобочитаемой. Например, при рассмотрении принципов работы протокола PPTP (Point-to-Point Tunneling Protocol — протокол сквозного туннелирования; глава 10) очень интересно показывать результа- ^ инкапсуляции дейтаграмм, а также результаты работы алгоритма шифрования именно на примере поля данных.
В результате поисков в Интернете был найден очень удобный анализатор трафика под названием Ethereal. Его уникальность в том, что при своей работе он опирается на предустановленный драйвер WinPcap и умеет показывать в Удобном виде двоичный файл, записанный программой WinDump. Практиче- . СКи ВСе приведенные примеры перехвата в книге выполнялись с помощью про- [ ^^мы WinDump с параметром -w, а затем представлялись в виде дерева вло- I ^Ни^- Саму программу и информацию по ее применению можно найти по адресу к ^PV/www,ethereal.сот. Для отображения перехваченных пакетов использовалась ^ВеРсия Ethereal 0.9.8.
Перед тем как приводить примеры перехватов, остановимся еще на одн параметре, который позволяет указать объем перехватываемых данных. По ум, чанию WinDump нс пытается анализировать всю сохраняемую дейтаграмму для снижения потребления ресурсов. Однако, зачастую для анализа требуе' не только заголовок, но и данные, следующие за ним. Особенно это полезно,: гда сами данные, а не заголовок представляют интерес для анализа (наприм пакет РРТР). Для этого вводится понятие размера перехватываемых дани: (snapshot length). Если программе напрямую не указывается данный параме1 то она выбирает только первые 68 байт.'
Рассмотрим обычный кадр сети Ethernet. Первые его 14 байт занимает за! ловок кадра, за ними следуют 20 байт заголовка дейтаграммы IP, далее, буй считать, что 20 байт заголовка пакета TCP и собственно данные. То есть ; умолчанию из 68 байт, сохраняемых программой WinDump, после вычета вс заголовков остается порядка 14 байт полезной нагрузки. Для того чтобы и менить эту настройку, при запуске программы нужно задать параметр -s ( значением желаемого количества байтов для перехвата. Если требуется запищ вать содержимое всего кадра Ethernet, то это значение следует сделать равны 1514 (максимальный размер кадра Ethernet). Тогда за вычетом 14 байт загола ка кадра, оставшиеся 1500 байт данных и будут представлять собой MTU Д! сети Ethernet. Обобщая сказанное, отмечу, что для перехвата трафика с поел дующим анализом с помощью программы Ethereal предпочтительно набрать ел дующую команду: WinDump -s 1514 -w <имя файлах
Несмотря на то, что чаще всего в книге будут приводиться так называй «экранные снимки» (screenshots) перехватов пакетов, важно понимать форм! текстовых данных, представляемых WinDump. Это становится вдвойне важн если в добавление к простому «ручному» анализу читатель захочет установи: в своей сети систему обнаружения атак Snort, которая существует как для пла формы UNIX, так и для платформы Microsoft Windows. Snort Intrusion Detectit System (IDS) — это бесплатная (freeware) система обнаружения атак, разраб тайная Мартином Ротем, основателем и генеральным директором компанг Sourcefire, первая IDS с открытыми исходными кодами, которая ныне станов! ся все более и более популярной. Существует великолепный сайт www.snortQ содержащий массу подробной информации об установке, настройке, расширен! системы Snort и об использовании готовых сигнатур (signatures). Можно ci зать, что сигнатуры представляют собой описания наиболее популярных ат! количество которых постоянно умножается. В базе данных сигнатур Snort 1 найдете все самые последние поступления. Сама программа Snort невелика размеру. Например, по сравнению с коммерческими продуктами ISS RealSecure
Важность понимания текстового формата вывода информации программе WinDump обусловлена тем, что информация об обнаруженных атаках может за писываться в текстовый файл вместе с заголовками перехваченных пакетов. ОД нако далее я буду приводить всю перехваченную информацию в виде фрагме: тов иерархической структуры, так как такое представление гораздо наглядна чем последовательность текстовых строк. Кроме того, весомыми достоинствам представления данных в перехваченных пакетах анализатором Ethereal являв ся его «интуитивная понятность» и большое количество поддерживаемых пр
токолов. Практически вес приведенные перехваты были получены следующим Боазом — на выбранном сервере ..запускалась программа WinDump.exe с параметрами, указывающими па то, что нужно записывать «сырые» данные в указанный Файл Затем этот файл переносился на компьютер автора, где он анализировался с помощью Ethereal. К слову, размеры файлов зависят от интенсивности проходящего трафика и настроенных фильтров перехвата, по обычно файлы умещались на один гибкий диск. В окне анализатора вид каждого перехваченного пакета зависит от конкретных протоколов, участвовавших в передаче информации. Например, если был осуществлен перехват пакета протокола HTTP, то общая картина может напоминать следующую (рис. 4.2).
Рис. 4,2. Пример перехвата пакета протокола HTTPРис. 4,2. Пример перехвата пакета протокола HTTP
Рис. 4,2. Пример перехвата пакета протокола HTTP
Рис. 4,2. Пример перехвата пакета протокола HTTP
В верхней части окна приводится сводная информация о вложенных протоколах разных уровней после декодирования анализатором. В нижней части та же информация представлена в шестнадцатеричном виде и в кодах ASCII. Перед каждой строкой в верхней половине окна присутствует символ «+», который означает, что соответствующую запись можно отобразить в более детальном виде — это очень полезно, особенно если нужно посмотреть содержимое определенного поля протокола — например, поле контрольной суммы дейтаграммы IP, которая по умолчанию не отображается. Вообще говоря, анализатор отображает только те поля, которые чаще всего используются при анализе. Первая строка содержит общую информацию о перехваченном пакете (рис. 4.3).
ввАД21АД21
в
в
АД21
АД21
"Arrival Time: Dee 25, 2002 16:04:51.197395000
-Time delta from previous packet: 0.000781000 seconds
"Time relative to first packet: 4.757180000 seconds
"Frame Number: 41
"Packet Length: 466 bytes
, _ Capture Length: 96 bytes
gkthernet II, Src: 00=dO:Ъ7:ba:bf: 19, Dst: 00:dO:Ъ7:aS:50:d2.
1 i1 iYinternet Protocol, Src Addr: 192.168.3.39 (192. 168.3.39), Dst Mdr = 192- 168.3.254 (192. 168.3.254) т iransmission Control Protocol, Src Port: 1910 (1910), Dst Port: 8080 (8080), Seq: 3577921704, Ack: Hypertext Transfer Protocol
1 i
1 i
ЙАПЙАПJJЙГаО Ь7 aS 50 d2 00 dO Ь7 ba bf 19 08 00 45 00 01 с4 94 с9 40 00 80 08 ;db f4 с0 а8 03 27 сО а8 03 fe 07 76 If 90 d5 42 eO aS b2 28 6b f7 50 18 fa fO c9 4a 00 00 47 45 .54 20 68 74 74 70 3a 2f V* Л A A A * Ma Al MA ■ A MA A A A A A At A A A
ЙАП
ЙАП
J
J
ТП"
Если развернуть эту строку, то мы увидим информацию о самом кадре: врем! его перехвата программой WinDump, порядковый номер, временные отклон ния от других пакетов и самое интересное — его длину (466 байт). Это общ длина пакета, включая вес вложенные данные. Поскольку пакет был перехвачё в сети Ethernet, то далее приведена информация, относящаяся к кадру Ethern (рис. 4.4). Все перехваченные пакеты, представленные в данной главе, буду иметь такой заголовок.
^41 4.757180 192.168.3.39 192.160.3.254НТТР^^^^^^
■
0 Frame 41 (466 bytes on wire, 96 bytes captured)
В Ethernet II, Src: 00:dQ:b7:ba:bf:19, Dst: 00d0^b7:a8:50d2 Destination: 00:d0:b7:a8:50:d2 (Intel_a8:50:d2) Source: 00:d0;b7:ba:bf:19 (Intel ba:bf:19) Type: ip (0x0800).
0 Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.254 (192.168.3.254) I 0 Transmission Control Protocol, Src Port: 1910 (1910), Dst Port: 8080 (8080), Seq: 3577921704, Acini 0 Hypertext Transfer Protocoli
Я
0000
0010
0020
0030
0040.
00 01
03 fa w
dO Ь7 а8 50 d2 00 d0 Ь7 ba bf 19 08 00 45 00
e4 fe fO 77.
94 07 c9 .80
e9 76
4a Ro.
40 If 00 84
00 90 00 .75
80 d5 47 .m
06
42
45 .70.
db cO
54 9=
f4
a8 20 7Л
eO a8 b2 28 68 74 84..8.Л
03 6b
74 8Q
27 f7
70
74
eO 50
3a 8f
a8 18
2f 7=
P
8.
• E
...v...B ,..(к.Р.
...J..GE Т http:/
/ш I wrlllfqn vtnl t + n ...
Рис. 4.4. Информация о кадре Ethernet
На этом уровне приводятся МАС-адреса (аппаратные) отправителя и ПОг^ лучателя, а также информация о типе вложенного протокола верхнего урон-т’ ня. Она редко будет использоваться, так как имеет практический смысл тольк^ при рассмотрении принципов работы протокола ARP (глава 2). В остальные случаях будем подразумевать, что отправитель владеет информацией о MAQ$' адресе получателя. Для оборудования, имеющего интерфейс Ethernet, аппат^ ратный адрес постоянен и устанавливается на заводе-изготовителе. Каждый^; производитель имеет свой уникальный префикс в адресе, проверяя который^ анализатор может выяснить, кем произведен сетевой адаптер (в нашем слу-'-', чае на компьютере-отправителе и компьютере-получателе кадра установд^^ ны сетевые карты производства компании Intel — префикс 00:d0:b7). Даннй^' префикс занимает первые 24 бит и назначается организацией IEEE (в англо| язычной литературе префикс часто называют vendor code — кодом поставщика)^? Относительно свежий список префиксов, закрепленных за производителями^ можно найти в сети Интернет по адресу http://www.cavebear.com/CaveBear/Ethernett ’ vendor.html (домашняя страница Карла Ауербаха, сотрудника консультационно!^ фирмы CaveBare). Дополнительно к полям МАС-адресов кадр содержит так^ же и поле Туре (тип), идентифицирующее протокол более верхнего уровня^, принимавшего участие в инкапсуляции кадра. Для протокола IP его значений» равно 0x8000.
Далее представлена информация о протоколах следующих уровней — сетевоиМ (протокол IP), транспортном (протокол TCP) и сеансовом (протокол НТТРЖИ
От пакета к пакету эта информация может меняться, но, как правило, всегда будет присутствовать вложенная дейтаграмма IP, поскольку все примеры будут рассматриваться начиная от сетевого уровня и выше. Но вместо протокола TCP вероятно появление протокола UDP, а за ним информации DNS — все зависит ■ от того, какое приложение сформировало и послало пакет в сеть. В книге упомянутые протоколы будут рассмотрены детальным образом, причем только применительно к их практическому действию.
ТЕРМИНОЛОГИЯ
Далее по тексту под термином «пакет» будем иметь в виду весь объем передаваемой информации, включая заголовки всех «вложенных» протоколов, «кадр» — это историческая терминология сетей Ethernet и в данном контексте этот термин по объему данных приравнивается «пакету» и будет употребляться редко и только для того, чтобы подчеркнуть, что речь идет именно о канальном уровне. «Дейтаграмма» — охватывает часть информации в пакете, принадлежащей протоколу IP (то есть все данные за исключением заголовка «кадра» Ethernet). Вся другая информация протоколов более высоких уровней будет также обобщенно называться «пакетом», но с добавлением ключевого слова, указывающего на то, о какой единице данных идет речь, например пакет DNS или пакет UDP. К сожалению, с определением единицы передаваемых данных (не имеет отношения к MTU) есть некая путаница. Так, очень часто в технической литературе встречается термин «дейтаграмма UDP», но в своем материале автор будет придерживаться описанной схемы наименований, чтобы не вводить лишние термины. Исключением является лишь термин «сегмент» TCP, который уже устоялся при рассмотрении принципов работы этого протокола, хотя, по мнению автора, можно смело говорить «пакет» TCP, ведь в конечном итоге оба термина ссылаются на одно и то же.
Сообщения протокола ICMP
Возвратимся к рассмотрению самого протокола ICMP. Так как этот протокол
при своей работе опирается на доставку, осуществляемую протоколом IP, важное место в заголовке дейтаграммы IP отводится полям Source IP (адрес отправителя) и Destination IP (адрес получателя). То есть в распределенной сети дейтаграмма поступает на стек TCP/IP хоста, которому она адресована. Хост анализирует
тип вложенного в дейтаграмму протокола, определяет факт использования протокола ICMP и выполняет определенные действия (или не выполняет). Далее следует заголовок сообщения ICMP. И как видно из рис. 4.5, количество полей : в заголовке значительно меньше, чем в протоколе IP, что еще раз подчеркивает I ) ограниченную функциональность обсуждаемого протокола.
L Протокол ICMP отличается от протоколов TCP и UDP в нескольких аспек- 6 тах. Эти отличия определяются его целями и расположением в стеке — так, про-
токол не требует для своей работы номеров портов. Наибольшее же сходство
Iв Функциональности наблюдается в указании типа и кода сообщения (message
type and code). Это первые два байта в заголовке, которые и идентифицируют
Функцию, возложенную на конкретное сообщение. Поле Туре указывает на тип ■ сообщения, а поле Code содержит код ошибки, интерпретация которого зависит от типа сообщения (табл. 4.1)
148
Глава 4. Протокол 1СмИ
Таблица 4.1. Типы сообщений ICMP
Тип
Обозначение
Код
0
Echo Reply (ответ на запрос echo)
0
1
—(не используется)
0
2
—(не используется)
0
3
Destination Unreachable
(получатель недостижим)
0 — Net Unreachable (сеть недостижима)
1 — Host Unreachable (хост недостижим)„Гя
2 — Protocol Unreachable (протокол недостижим)’^3
3 — Port Unreachable (порт недостижим)• 3
— Fragmentation Needed and Don't Fragment was ■ Set (требуется фрагментация, но установлен бит
«Не фрагментировать»)4 Д
— Source Route Failed (сбой при маршрутизации от источника)
— Destination Network Unknown (требуемая сеть , 3 неизвестна).
— Destination Host Unknown (получатель неизвестен) 'MJ 8 — зарезервировано"^
— зарезервировано^
— зарезервировано;?
И — Destination Network Unreachable for Type'"j
of Service (для указанного типа сервиса целевая. Д
сеть недостижима)J
12 — Destination Host Unreachable for Type of ServiceЯ
(для запрошенного типа сервиса целевой хост,
недостижим)■
13 — Communication Administratively Prohibited)
(взаимодействие запрещено в административном’t-
порядке)- до
4
Source Quench (подавление источника)
0<
5
Redirect (перенаправление)
0 — Redirect Datagram for the Network (перенаправление;!.; дейтаграммы, адресованной в сеть или подсеть) ( Г 1 — Redirect Datagram for the Host (перенаправление ,^ дейтаграммы, адресованной хосту) v
2 — Redirect Datagram for the Type of Service and Network , (перенаправление дейтаграммы для запрошенного типа ? сервиса или сети) '
3 — Redirect Datagram for the Type of Service and Host ; (перенаправление дейтаграммы для запрошенного типа;п сервиса или хоста) -,т-
6
Alternate Host Address (альтернативный адрес хоста)
0»1
4.1
8
Echo request (запрос echo)
0'^
9
Router Advertisement (анонсирование маршрутизатора)
0
—”
Тип
Обозначение
Код
Ло
Router Selection (выбор маршрутизатора)
0
п
Time Exceeded (превышение времени)
0 — Time to Live exceeded in Transit (значение поля TTL превышено)
1 — Fragment Reassembly Time Exceeded (превышено время сборки фрагментов)
12
Parameter Problem (проблема с параметром)
0 — Pointer indicates the error (указание на ошибку)
1 — Missing a Required Option (пропущена требуемая опция)
2 — Bad Length (некорректная длина)
13
Timestamp Request (запрос временной отметки в формате Timestamp)
0
14
Timestamp Reply (ответ на запрос временной отметки)
0
15
Information Request (запрос информации)
0
16
Information Reply (ответ на запрос информации)
0'
17
Address Mask Request
(запрос маски адреса)
0
18
Address Mask Reply (ответ на запрос маски адреса)
0
19
29
Зарезервированы
30
Traceroute (трассировка маршрута)
31
Datagram Conversion Error (ошибка преобразования дейтаграммы)
32
Mobile Host Redirect (перенаправление мобильного хоста)
33
IPv6 Where-Are-You («Где я?» — запрос протокола IPv6)
34
IPv6 I-Am-Here («Здесь» — ответ на запрос)
Для отправки тех или иных сообщений существует ряд условий, отраженных в документе RFC 792. Так, не посылается сообщение об ошибке ICMP в ответ на Получение аналогичного сообщения, чтобы предотвратить возникновение петель. Далее, для фрагментированных дейтаграмм IP сообщения протокола ICMP посылаются только для первого фрагмента. Другое требование заключается в том, что сообщения об ошибках никогда не посылаются в ответ на получение дейтаграммы с групповым или широковещательным адресом, во избежание вещательного
«шторма» трафика в сети. Кроме того, сообщение об ошибке отсутствует в rmO чае получения дейтаграммы с нулевым адресом отправителя, адресом 127.0.d*g| (адрес обратной связи, loopback), широковещательным и групповым адоетма Интересно отметить, что при поступлении на хост сообщения ICMP неизвестД| ного типа это сообщение должно игнорироваться (чтобы снизить вероятности некорректного влияния на хост ложных сообщений).Д
Все сообщения протокола можно условно разделить на две группы — сообще-1' ния об ошибках (error messages — табл. 4.2) и запросы (query messages — табл. 4.^4 Первая группа, как несложно понять из названия, служит для извещения о про-i изошедших ошибках, которые препятствовали доставке дейтаграммы (рекоменду-d ется использовать при возникновении некратковременных проблем доставки — < так называемых non-transient delivery problem. Важно, что каждое сообщение об ошибке включает в себя IP-заголовок (от 20 до 60 байт) и по крайней мере< 8 байт данных дейтаграммы, послужившей причиной отправки сообщения, то-; есть количество присоединяемых байтов исходной дейтаграммы может быть боль
ше. Соответственно, учитывая сам заголовок ICMP, размер получаемых вами!
сообщений об ошибках будет варьироваться от 36 до 72 байт.
Таблица 4.2. Сообщения об ошибках ICMP
Сообщение об ошибке
Тип,
Destination Unreachable (получатель недостижим)
Source Quench (подавление источника)
3
4.
Redirect (перенаправление)5
Time Exceeded (превышение времени)11
Parameter Problem (проблема с параметром)12
На рис. 4.5 показан пример сообщения протокола ICMP об ошибке (Destination \ Unreachable — получатель недостижим). Формат сообщений об ошибке для раз- ‘ личных типов последних мало чем отличается. Так, непременно присутствуют поля Туре (тип — 1 байт), Code (код — 1 байт) и Checksum (контрольная сумма — 1 2 байт). Кроме того, в сообщение обязательно включаются заголовок исходной дейтаграммы (20-60 байт) и первые 64 бит (8 байт) данных.’
Анализируя рис. 4.5, можно увидеть, что перехваченное сообщение об ошибке ; содержит весь заголовок IP и еще 8 байт данных дейтаграммы, следующей за ■ заголовком. В нашем случае в дейтаграмму IP был вложен пакет TCP (начиная с заголовка). Но из всего заголовка TCP было взято только 8 байт. В принци- । пе, для целей анализа причины сбоя подобного объема информации должно быть достаточно. В других типах сообщений об ошибках может присутствовать । другая, специфичная для них информация.■.
Сообщения запросов протокола ICMP (табл. 4.3) используются для посылки» запросов и анализа полученных ответов в целях определения общих характерна j стик сети (как например, доступности определенного хоста или для измеренИЯ1| сетевой задержки — network latency). Для сообщения запросов общими являют^ ся поля Type, Code, Checksum, Identifier (2 байт; идентификатор — для селекций^
сообщений, посланных разным хостам) и Sequence Number (2 байт; номер последовательности — для селекции нескольких сообщений, посланных одному хосту). Размер сообщений запросов отличается в зависимости от их типов. Если размер заголовка постоянен — 8 байт, то общая длина дополнительных полей является переменной.
^72118740.641029 192.168.3.25; I9/.16B 1 49 11 MP №Minullln> UOrWlMitr^72118740.641029 192.168.3.25; I9/.16B 1 49 11 MP №Minullln> UOrWlMitr(70 bytes on wire, 70 bytes captured)(70 bytes on wire, 70 bytes captured)■Frame 72 (70 bytes on wire, 70 bytes captured)■Ethernet II, Src: 00:dO:b7:a9:la:21, Dst: 00:dO:b7:ba:bf:19Internet Protocol, Src Addr= 192.168.3.252 (192.168.3.252), Dst Addr= 192.168.3.39 (192.168.3.39)■Frame 72 (70 bytes on wire, 70 bytes captured)■Ethernet II, Src: 00:dO:b7:a9:la:21, Dst: 00:dO:b7:ba:bf:19Internet Protocol, Src Addr= 192.168.3.252 (192.168.3.252), Dst Addr= 192.168.3.39 (192.168.3.39)Internet-Type:-Code:Internet-Type:-Code:Control Message ProtocolControl Message Protocol3 (Destination unreachable)4 (Fragmentation needed)3 (Destination unreachable)4 (Fragmentation needed)-Checksum: 0x46a2 (correct)-MTU of next hop: 1380tHnternet Protocol, Src Addr: 102.168.3.39 (192. 168.3£ Transmission Control Protocol, Src Port: 1030 (1030)-Checksum: 0x46a2 (correct)-MTU of next hop: 1380tHnternet Protocol, Src Addr: 102.168.3.39 (192. 168.3£ Transmission Control Protocol, Src Port: 1030 (1030)39), Dst № 192-168.12.253 (192.168.12.253) Dst Port: microsoft-ds (445)39), Dst № 192-168.12.253 (192.168.12.253) Dst Port: microsoft-ds (445)MM flOO 10 0020 i 0030 №MM flOO 10 0020 i 0030 №00 dO b7 ba bf 19 00 dO b7 a9 la 21 08 00 45 00 00 38 27 6e 00 00 80 01 8a e3 cO aS 03 fc cO a8 03 27 03 04 46 a2 00 00 05 64 45 00 05 de 00 23 40 00 80 06 63 84 cO a8 03 27 cO aS 0c fd 04 0600 dO b7 ba bf 19 00 dO b7 a9 la 21 08 00 45 00 00 38 27 6e 00 00 80 01 8a e3 cO aS 03 fc cO a8 03 27 03 04 46 a2 00 00 05 64 45 00 05 de 00 23 40 00 80 06 63 84 cO a8 03 27 cO aS 0c fd 04 06ni wni wRRRR„Й„ЙR? RcR? Rc-8’n.. .’..F. @...c. . S »l-8’n.. .’..F. @...c. . S »ldEdEE.E.##
^72118740.641029 192.168.3.25; I9/.16B 1 49 11 MP №Minullln> UOrWlMitr
^72118740.641029 192.168.3.25; I9/.16B 1 49 11 MP №Minullln> UOrWlMitr
(70 bytes on wire, 70 bytes captured)
(70 bytes on wire, 70 bytes captured)
■Frame 72 (70 bytes on wire, 70 bytes captured)
■Ethernet II, Src: 00:dO:b7:a9:la:21, Dst: 00:dO:b7:ba:bf:19
Internet Protocol, Src Addr= 192.168.3.252 (192.168.3.252), Dst Addr= 192.168.3.39 (192.168.3.39)
■Frame 72 (70 bytes on wire, 70 bytes captured)
■Ethernet II, Src: 00:dO:b7:a9:la:21, Dst: 00:dO:b7:ba:bf:19
Internet Protocol, Src Addr= 192.168.3.252 (192.168.3.252), Dst Addr= 192.168.3.39 (192.168.3.39)
Internet
-Type:
-Code:
Internet
-Type:
-Code:
Control Message Protocol
Control Message Protocol
3 (Destination unreachable)
4 (Fragmentation needed)
3 (Destination unreachable)
4 (Fragmentation needed)
-Checksum: 0x46a2 (correct)
-MTU of next hop: 1380
tHnternet Protocol, Src Addr: 102.168.3.39 (192. 168.3
£ Transmission Control Protocol, Src Port: 1030 (1030)
-Checksum: 0x46a2 (correct)
-MTU of next hop: 1380
tHnternet Protocol, Src Addr: 102.168.3.39 (192. 168.3
£ Transmission Control Protocol, Src Port: 1030 (1030)
39), Dst № 192-168.12.253 (192.168.12.253) Dst Port: microsoft-ds (445)
39), Dst № 192-168.12.253 (192.168.12.253) Dst Port: microsoft-ds (445)
MM flOO 10 0020 i 0030 №
MM flOO 10 0020 i 0030 №
00 dO b7 ba bf 19 00 dO b7 a9 la 21 08 00 45 00 00 38 27 6e 00 00 80 01 8a e3 cO aS 03 fc cO a8 03 27 03 04 46 a2 00 00 05 64 45 00 05 de 00 23 40 00 80 06 63 84 cO a8 03 27 cO aS 0c fd 04 06
00 dO b7 ba bf 19 00 dO b7 a9 la 21 08 00 45 00 00 38 27 6e 00 00 80 01 8a e3 cO aS 03 fc cO a8 03 27 03 04 46 a2 00 00 05 64 45 00 05 de 00 23 40 00 80 06 63 84 cO a8 03 27 cO aS 0c fd 04 06
ni w
ni w
RR
RR
„Й
„Й
R? Rc
R? Rc
-8’n.. .’..F. @...c. . S »l
-8’n.. .’..F. @...c. . S »l
dE
dE
E.
E.
#
#
Рис. 4.5. Пример сообщения об ошибке
Таблица 4.3. Сообщения запросов ICMP
Сообщение
Типы
Echo request (запрос echo), Echo Reply (ответ на запрос echo)
Timestamp Request (запрос временной отметки), Timestamp Reply (ответ на запрос временной отметки)
Information Request (запрос информации), Information Reply (ответ на запрос информации)
Address Mask Request (запрос маски адреса), Address Mask Reply (ответ на запрос маски адреса)
8, 0
13, 14
15, 16
17, 18
Сообщение ICMP echo request
; Каждое сообщение протокола ICMP служит для определенных целей и посылается при образовании определенных условий в сети. Рассмотрим наиболее часто встречающиеся типы сообщений и проанализируем причины их возникновения. Начнем с разбора, пожалуй, наиболее «популярного» сообщения echo request (запрос echo — рис. 4.6), генерируемого командой ping. Интересно отметить, что данный тип сообщения является общим для всех операционных систем — документ RFC 1122 требует, чтобы каждый хост предоставлял возможность пользователю отправить запрос echo другому хосту (подразумева- ; ется наличие команды или программы — для других сообщений подобного трё- k бования нет).
ррFrame 3 (74 bytes on wire, 74 bytes captured)Frame 3 (74 bytes on wire, 74 bytes captured)EthernetEthernet|ппдп„, ?7, ,A1, ,R9 r-; м rc, r;i й7|ппдп„, ?7, ,A1, ,R9 r-; м rc, r;i й7Рис. 4.7. Пакет первого сеанса pingРис. 4.7. Пакет первого сеанса pingА 3 3.780249192.160.3.39 192.160.3.254 ICMP Et ho (ping) requwitА 3 3.780249192.160.3.39 192.160.3.254 ICMP Et ho (ping) requwit|<5e 3 3.700249 192.160.3.39 192.160.3254 ICMP Etho (plng)requ«l|<5e 3 3.700249 192.160.3.39 192.160.3254 ICMP Etho (plng)requ«l50 00106b50 00106b00 8002 6d00 8002 6d08 03 637308 03 63730027647400276474b7 baOf 153b 008f 7099 COb7 baOf 153b 008f 7099 COb7 a3 08 69b7 a3 08 6945 cO 65 7545 cO 65 7519 a8 62 7219 a8 62 7200 a8 667600 a8 6676a8 36006aa8 36006adO 01 00 6edO 01 00 6ebf eO 61 71bf eO 61 71dO 3c fe 68dO 3c fe 68d2 00 5c 6cd2 00 5c 6cControl Message Protocol 8 (Echo (ping) request) 0Control Message Protocol 8 (Echo (ping) request) 0ghijkimn opqrstuv iirak^rlo'Ftf highijkimn opqrstuv iirak^rlo'Ftf his Internet-Туре:-Code:s Internet-Туре:-Code:-Checksum: Ox 105с (correct) -Identifier: 0x0200 -Sequence number: 3b:00 l-Data (32 bytes)-Checksum: Ox 105с (correct) -Identifier: 0x0200 -Sequence number: 3b:00 l-Data (32 bytes)....PE..<•6’..V.. ;.abcdef ghijkimn opqrstuv ЛГэЬлЯ а£.я..,К)....PE..<•6’..V.. ;.abcdef ghijkimn opqrstuv ЛГэЬлЯ а£.я..,К)1;E.¥.. l.abcdef1;E.¥.. l.abcdefl&Frame 3 (74 bytes on wire, 74 bytes captured)
р
р
Frame 3 (74 bytes on wire, 74 bytes captured)
Frame 3 (74 bytes on wire, 74 bytes captured)
Ethernet
Ethernet
|ппдп„, ?7, ,A1, ,R9 r-; м rc, r;i й7
|ппдп„, ?7, ,A1, ,R9 r-; м rc, r;i й7
Рис. 4.7. Пакет первого сеанса ping
Рис. 4.7. Пакет первого сеанса ping
А 3 3.780249192.160.3.39 192.160.3.254 ICMP Et ho (ping) requwit
А 3 3.780249192.160.3.39 192.160.3.254 ICMP Et ho (ping) requwit
|<5e 3 3.700249 192.160.3.39 192.160.3254 ICMP Etho (plng)requ«l
|<5e 3 3.700249 192.160.3.39 192.160.3254 ICMP Etho (plng)requ«l
50 00
10
6b
50 00
10
6b
00 80
02 6d
00 80
02 6d
08 03 63
73
08 03 63
73
00
27
64
74
00
27
64
74
b7 ba
Of 15
3b 00
8f 70
99 CO
b7 ba
Of 15
3b 00
8f 70
99 CO
b7 a3 08 69
b7 a3 08 69
45 cO 65 75
45 cO 65 75
19 a8 62 72
19 a8 62 72
00 a8 66
76
00 a8 66
76
a8 36
00
6a
a8 36
00
6a
dO 01 00 6e
dO 01 00 6e
bf eO 61 71
bf eO 61 71
dO 3c fe 68
dO 3c fe 68
d2 00 5c 6c
d2 00 5c 6c
Control Message Protocol 8 (Echo (ping) request) 0
Control Message Protocol 8 (Echo (ping) request) 0
ghijkimn opqrstuv iirak^rlo'Ftf hi
ghijkimn opqrstuv iirak^rlo'Ftf hi
s Internet
-Туре:
-Code:
s Internet
-Туре:
-Code:
-Checksum: Ox 105с (correct) -Identifier: 0x0200 -Sequence number: 3b:00 l-Data (32 bytes)
-Checksum: Ox 105с (correct) -Identifier: 0x0200 -Sequence number: 3b:00 l-Data (32 bytes)
....PE.
.<•6’..
V.. ;.abcdef ghijkimn opqrstuv ЛГэЬлЯ а£.я..,К)
....PE.
.<•6’..
V.. ;.abcdef ghijkimn opqrstuv ЛГэЬлЯ а£.я..,К)
1;E.
¥.. l.abcdef
1;E.
¥.. l.abcdef
EJEthernet II, Src: 00:d0:b7:ba:bf:19, Dst: 00:d0:b7:a8:50:d2
EHnternet Protocol, Src Addr: 192. 168.3.39 (192.168.3.39), Dst Addr: 192. 168.3.254 ( 192. 188.3.254) в Internet Control Message Protocol
-Type: 8 (Echo (ping) request)
-Code: 0
-Checksum: 0x105c (correct)
-Identifier: 0x0200
-Sequence number: 3b:00
-Data (32 bytes)
000000dOЬ7а850d200dOЬ7babf1908004500
001000ЗеаЗ3600008001Of15с0а80327еОа8
002003fe0800105с0200ЗЬ00616263646566
00306768696а6b6с6dбе8f70717273747576
ПМЛ77Й|Й9Й1Й4ЙЙЙЙЙ7ЙЙЙО
Рис. 4.6. Пример сообщения ICMP echo request
Присмотревшись, можно увидеть схему инкапсуляции и 2 байта, идентиф; пирующие само сообщение (на рис. 4.6 они отмечены как type: 8 и code: 0). Пол «Идентификатор» (Identifier) служит для идентификации запросов, направленн различным хостам в сети, а поле номера последовательности (Sequence number задействуется в случае отправки нескольких запросов одному хосту. Так, в доку^ менте RFC 792 оговорено, что «поля идентификатора и номера последовательно; сти могут (may) быть использованы отправителем запроса echo для связывани с поступающими ответами. Например, идентификатор может использоватЫ как порт в протоколах TCP или UDP для идентификации различных сеанс а номер последовательности может увеличиваться при каждом отправленное запросе. В ответе возвращаются те же самые значения, что были в запросе^ В сказанном несложно убедиться на практике путем одновременного запуск двух команд ping из-под операционной системы Microsoft Windows 2000 Pro$ essional Rus (SP3) с указанием двух различных целевых адресов (адрес перво! получателя запросов 192.168.3.254, второго — 192.168.3.253).
^tneijjec II, Src: 00:dO:b7:ba:bf: 19, Dst: 00:d0:b7:a8:50;d2
Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.254 (192.168.3.254)
FIFIoo oo0367oo oo0367Юо 0010 0020 0030
FI
FI
oo oo
03
67
oo oo
03
67
^7714559^92.161^3.39 19Z.lb8.3.253 ICMP Echo (ping) roqueml
5 174 bytes on wire, 74 bytes captured)
Bernet II. Src: 00:d0:b7:ba:bf: 19, Dst: 00:d0:b7:b8:71:e9
Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192-168.3.253 (192.168.3.253)
■Internet Control Message Protocol
Hype: 8 (Echo (ping) request)
-Code: 0
-Checksum: 0x0f5c (correct)
-Identifier: 0x0200
-Sequence number: 3c:00
-Data (32 bytes)
MOO00d0b7b871e900dbb7babf1908004500... .qE.
0010003ca33700008001Of15cOa80327cOa8.<.7
002003fd0800Of5c02003c00616263646566V..<-abcdef
00306768696a6b6c6d6e6f7b717273747576ghijklmnopqrstuv
НМЛ A1 A? Al M. ,AR ,AA Й7 . .AR AQ
Рис. 4.8. Пакет второго сеанса ping
Как видно из примеров (рис. 4.7 и 4.8), значение идентификатора одинаково для обоих сеансов (0x0200), несмотря на предыдущую выдержку из документа RFC (скорее всего цитата подразумевала рекомендацию, что подчеркивалось ключевым словом may). При этом, для того чтобы отличить запросы друг от друга, используется ноле номера последовательности — для каждого запроса значение этого поля уникально, а различие между номерами для двух сеансов равно 0x100 (256 в десятичной системе). Для первого запроса значение номера последовательности ОхЗЬОО (или 15 104), для второго (но другого хоста) — ОхЗсОО (или 15 360). Разница между ними как раз и равна 256 в десятичной системе. Характерно то, что для всех остальных запросов значение этого поля увеличивается на 256, причем для каждого запроса echo request даже в рамках одного сеанса ping (в операционных системах Microsoft Windows команда генерирует 4 запроса ICMP echo request).
Интересно отметить, что помимо идентификации запросов поле идентификатора может служить источником информации о типе операционной системы, . с которой данный запрос был отправлен (особенно это касается семейства Microsoft Windows в свете предыдущего эксперимента).
Так, если запрос проистекал из операционной системы Microsoft Windows NT (с установленным пакетом обновлений Service Pack 6) то поле будет иметь значение (или начинаться) с 0x100, а для семейства Microsoft Windows 2000 — с 0x200 (десятичное 512) либо 0x300 в зависимости от установленного пакета обновлений. Для начального заполнения этого поля в операционных системах Microsoft используется некая константа, различная для разных типов систем. То есть если вы, перехватив запрос ICMP echo, скажем, поступивший на внешний интерфейс вашего защитного экрана, увидите, что поле идентификатора равно 256, 512 или 768 • я Microsoft Windows ME), то можно с высокой долей уверенности утверждать, что запрос был инициирован с одной из операционных систем Microsoft. Другой интересной особенностью является то, что для указанных операционных систем Данное значение будет повторяться и для последующих запросов, в то время как Для ОС семейства UNIX рассматриваемое поле заполняется на основании идентификатора процесса (Process ID, PID) и может меняться от случая к случаю.
Кроме того, как видно из предыдущих перехватов, четко прослеживается заи симость изменений поля номера последовательности для разных сеансов. Я начальной загрузке системы Windows и выполнении первой команды ping 3Э чение этого поля устанавливается равным 0x100 и будет увеличиваться на Охи для каждого следующего запроса. В принципе, можно путем перехвата и делем ем значения поля в перехваченном запроса на число 0x100 узнать, сколько ! просов инициировалось с момента загрузки. Например, если вернуться к рис. 43 то деление значения 15 104 на 256 даст в результате 59. То есть в момент пед хвата система сгенерировала 58 запросов echo request. Эксперименты показал! что самый первый запрос echo request посылается серверу — контроллеру дом® Microsoft Active Directory (естественно, это относится к ситуации, когда рад чая станция входит в домен Active Directory). Для каких целей так сделано, oral ется до конца не ясным, так как запрос посылается уже после того, как сере был опрошен по протоколу LDAP и с ним было установлено соединение ТСИ
Возвратимся к рассмотрению общей схемы работы запроса echo request. В то случае, если па запрос ICMP echo request поступает ответ echo reply, то мож~ сделать вывод о том, что получатель запроса активен в сети и доступен. Но ст; дует отметить, что некоторые защитные экраны способны генерировать отв^ за получателей. Если ответ не поступает, то логично предположить, что ли хост неактивен, либо защитный экран настроен на блокирование входящих Д вне запросов с последующим «молчаливым» их удалением. 5
Если используется операционная система Microsoft Windows с установлений стеком TCP/IP, то для формирования сообщения echo request, как правМ привлекается популярная команда ping с указанием адреса получателя запрдв Эта команда очень популярна и часто описывается в технической литературе^
Поэтому интересно будет остановиться на таком понятии, как ICMP swd" (трудно переводимый термин, поэтому оставим его как есть). Также моя! встретиться термин ping sweep, что означает одно и то же. Если для неболып! сетей команда ping приемлема, то для крупных распределенных сетей подобш метод опроса работающих хостов может показаться утомительным. В этом сл чае подойдут инструменты, которые организуют массовый опрос хостов в cel практикуя принцип ping sweep, который реализуется отправкой множества в просов различным хостам, с последующим анализом результатов. Для реализ ции этой возможности неплохим вариантов будет популярная программа пт: (http://www.insecure.org), запущенная, например, со следующими параметра^ nmap -sP -PI 192.168.3.1-254. Важно отметить, что подобный массирований опрос работающих устройств в сети обнаруживается системами IDS. '
C:\Program Files\nmapNTspl\Nmapnt>nmapnt -sP -PI 192.168.3.1-254
Starting nmapNT V. 2.53 SP1 by ryan@eEye.com eEye Digital Security ( http://www.eEye.com ) based on nmap by fyodor@1nsecure.org ( www.1nsecure.org/nmap/ )-A
Host 192.168.3.3 appears to be up.<f;
Host 192.168.3.6 appears to be up.
Host 192.168.3.7 appears to be up.
Host 192.168.3.11 appears to be up.
... (удалено для краткости)
Nmap run completed -- 254 ip addresses (74 hosts up) scanned in 32 seconds
При выполнении команды nmap, в данном конкретном случае — версии программы для платформы Windows, адаптированной компанией сЕус (www.eeye.com), параметры -sP и -PI указывают программе производить сканирование только с по- мошью запросов ICMP. Следует отметить, что в некоторых случаях сканируемые хосты располагаются за защитным экраном, который блокирует входящие запросы ICMP echo request. Тогда следует отказаться от параметра -PI и программа пшар будет в дополнение к запросам ICMP осуществлять ТСР-скани- рование посредством отправки сегмента с установленным флагом АСК и с портом, имеющим номер 80 (значение по умолчанию). Как будет показано далее в главе 5, рассматривающей особенности протокола TCP, если в ответ поступает сегмент с установленным флагом RST, значит хост активен.
В терминологии протокола ICMP нет таких понятий, как «клиент» и «сервер». Например, если хост получает сообщение этого протокола, указывающего на определенную ситуацию, он может выполнить какие-то определенные внутренние действия, но не обязан делать что-либо для обратного взаимодействия с отправителем — ICMP не дает никаких гарантий относительно доставки сообщения.
Протокол ICMP также примечателен тем, что хосту не требуется поддерживать какой-либо сервис или порт. Практически любая сетевая операционная система может отвечать на запросы ICMP echo request (команда ping). Говоря точнее, в соответствии с рекомендациями, данными в документах RFC, каждое сетевое устройство (хост или маршрутизатор) должно обладать функциональностью, обеспечивающей ответное сообщение echo reply на запрос echo request. Сложности возникают при необходимости как раз изменить обычное поведение протокола, реализованного в той или иной операционной системе — например, отключить отправку ответного сообщения ICMP echo reply на запрос echo request (результат команды ping х.х.х.х, где х.х.х.х — адрес удаленного хоста).
Дополнительной уникальной возможностью протокола является поддержка широковещательного трафика. Так, если протокол TCP опирается исключительно на взаимодействие в стиле «тет-а-тет» между клиентом и сервером, не принимая во внимание другие хосты в сети, то протокол ICMP не столь категоричен. И именно указанная возможность породила такую атаку, как Smurf, которая будет рассматриваться в главе 8. Кстати, читатель может сам попробовать выполнить команду ping х.х.х.255 в своей сети (предполагается, что в сети используется адрес класса С). Например, автор увидел следующие результаты:
C:\>ping -п 10 192.168.3.255
Обмен пакетами с 192.168.3.255 по 32 байт:
Ответ от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числоОтвет от 192.168.3.255: числобайтов=32 время=Юмс TTL=64 байтов=32 время<Юмс TTL=64 байтов=32 времжЮмс TTL=64 байтов=32 времжЮмс TTL=255 байтов=32 времжЮмс TTL=64 байтов=32 время<10мс TTL=64байтов=32 время=Юмс TTL=64 байтов=32 время<Юмс TTL=64 байтов=32 времжЮмс TTL=64 байтов=32 времжЮмс TTL=255 байтов=32 времжЮмс TTL=64 байтов=32 время<10мс TTL=64
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
Ответ от 192.168.3.255: число
байтов=32 время=Юмс TTL=64 байтов=32 время<Юмс TTL=64 байтов=32 времжЮмс TTL=64 байтов=32 времжЮмс TTL=255 байтов=32 времжЮмс TTL=64 байтов=32 время<10мс TTL=64
байтов=32 время=Юмс TTL=64 байтов=32 время<Юмс TTL=64 байтов=32 времжЮмс TTL=64 байтов=32 времжЮмс TTL=255 байтов=32 времжЮмс TTL=64 байтов=32 время<10мс TTL=64
. ■ Все компьютеры в сети, где выполнялась данная команда, автоматически получают адреса (работает служба DHCP) сети класса С — 192.168.3.0/24. Приведен-
■■■■■■■■ная команда десять раз (параметр -п 10) отправляет запрос ICMP echo reque Обратите внимание, что в дейтаграмме IP в качестве адреса получателя устанавл вается 192.168.3.255 (рис. 4.9), являющийся указанием на то, что это направлю ное широковещание (напомню, что есть также и ограниченное широковещани а в кадре сети Ethernet адрес получателя равен FF:FF:FF:FF:FF:FF (сообщен достигает всех устройств в рамках сети).
■■■■
■■■■
1^5 1.131153 192*168.3.39 147 1МП /ЪЬПМР Itho (|Wiq)r«|ui4k
ф-Frame 5 (74 bytes on wire, 74 bytes captured)
^Ethernet II, Src: 00:d():b7:ba:bf: 19. Dst = ff :ff:ff:ff:ff:ff
I-Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
rSource: 00:d0:b7:ba:bf:19 (00:dO:b7:ba:bf:19)
Hype: IP (0x0800),
в Internet Protocol, Src Addr= 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.255 (192. 168.3.255)
-Version: 4
-Header length: 20 bytes
EHype of service: 0x00 (None)
-Total Length: 60
-Identification: 0x449a
EJFlags: 0x00
-Fragment offset: 0
-lime to live: 128
-Protocol: ICMP (0x01)
-Header checksum: 0x6db0 (correct)
-Source: 192.168.3.39 (192.168.3.39)
LDestination: 192.168.3.255 (192.168.3.255)
S Internet Control Message Protocol
-JE»- 000? 0010 0020 0030 ППЛП-JE»- 000? 0010 0020 0030 ППЛПff ff 00 3c 03 ff 67 68 ?? Й1ff ff 00 3c 03 ff 67 68 ?? Й1ft ff ft ffft ff ft ff44 9a 08 00 69 6a Й9 Й144 9a 08 00 69 6a Й9 Й100 39 6b ЙЛ00 39 6b ЙЛ005c 6c ЙЙ005c 6c ЙЙ00 1000 1080 026d ЙЙ80 026d ЙЙ01 006e Й?01 006e Й?b7 ba bf 19 08 00 45 00 6d bO cO aS 03 27 cO aS 12 00 61 62 63 64 65 66 6f 70 71 72 73 74 75 76 ЙЙ ЙОb7 ba bf 19 08 00 45 00 6d bO cO aS 03 27 cO aS 12 00 61 62 63 64 65 66 6f 70 71 72 73 74 75 76 ЙЙ ЙОE.E..<D m.... ’......9V.. ..abcdef shijklmn opctrstuv шоклИ af о- ki.<D m.... ’......9V.. ..abcdef shijklmn opctrstuv шоклИ af о- ki
-JE»- 000? 0010 0020 0030 ППЛП
-JE»- 000? 0010 0020 0030 ППЛП
ff ff 00 3c 03 ff 67 68 ?? Й1
ff ff 00 3c 03 ff 67 68 ?? Й1
ft ff ft ff
ft ff ft ff
44 9a 08 00 69 6a Й9 Й1
44 9a 08 00 69 6a Й9 Й1
00 39 6b ЙЛ
00 39 6b ЙЛ
00
5c 6c ЙЙ
00
5c 6c ЙЙ
00 10
00 10
80 02
6d ЙЙ
80 02
6d ЙЙ
01 00
6e Й?
01 00
6e Й?
b7 ba bf 19 08 00 45 00 6d bO cO aS 03 27 cO aS 12 00 61 62 63 64 65 66 6f 70 71 72 73 74 75 76 ЙЙ ЙО
b7 ba bf 19 08 00 45 00 6d bO cO aS 03 27 cO aS 12 00 61 62 63 64 65 66 6f 70 71 72 73 74 75 76 ЙЙ ЙО
E.
E.
.<D m.... ’..
....9V.. ..abcdef shijklmn opctrstuv шоклИ af о- ki
.<D m.... ’..
....9V.. ..abcdef shijklmn opctrstuv шоклИ af о- ki
Рис. 4.9. Широковещательный запрос echo request
В ответ на одно подобное сообщение ICMP отправитель получает несколь^В ответ на одно подобное сообщение ICMP отправитель получает несколь^откликов. Наиболее удобно отобразить результатоткликов. Наиболее удобно отобразить результатввследующемследующемвиде:виде:3940414243443940414243446.8471636.8481986.8492076.8494066.8496216.8782866.8471636.8481986.8492076.8494066.8496216.878286192.168.3.39 192.168.3.25192.168.3.65 192.168.3.39192.168.3.245192.168.3.39192.168.3.247192.168.3.39192.168.3.248192.168.3.39192.168.3.74 192.168.3.39192.168.3.39 192.168.3.25192.168.3.65 192.168.3.39192.168.3.245192.168.3.39192.168.3.247192.168.3.39192.168.3.248192.168.3.39192.168.3.74 192.168.3.39ICMP ICMP ICMP ICMP ICMP ICMPICMP ICMP ICMP ICMP ICMP ICMPEcho Echo Echo Echo Echo EchoEcho Echo Echo Echo Echo Echo(ping) (ping) (ping) (ping) (ping) (ping)(ping) (ping) (ping) (ping) (ping) (ping)request reply reply reply reply replyrequest reply reply reply reply reply
В ответ на одно подобное сообщение ICMP отправитель получает несколь^
В ответ на одно подобное сообщение ICMP отправитель получает несколь^
откликов. Наиболее удобно отобразить результат
откликов. Наиболее удобно отобразить результат
в
в
следующем
следующем
виде:
виде:
39
40
41
42
43
44
39
40
41
42
43
44
6.847163
6.848198
6.849207
6.849406
6.849621
6.878286
6.847163
6.848198
6.849207
6.849406
6.849621
6.878286
192.168.3.39 192.168.3.25
192.168.3.65 192.168.3.39
192.168.3.245192.168.3.39
192.168.3.247192.168.3.39
192.168.3.248192.168.3.39
192.168.3.74 192.168.3.39
192.168.3.39 192.168.3.25
192.168.3.65 192.168.3.39
192.168.3.245192.168.3.39
192.168.3.247192.168.3.39
192.168.3.248192.168.3.39
192.168.3.74 192.168.3.39
ICMP ICMP ICMP ICMP ICMP ICMP
ICMP ICMP ICMP ICMP ICMP ICMP
Echo Echo Echo Echo Echo Echo
Echo Echo Echo Echo Echo Echo
(ping) (ping) (ping) (ping) (ping) (ping)
(ping) (ping) (ping) (ping) (ping) (ping)
request reply reply reply reply reply
request reply reply reply reply reply
Видно, чтоВидно, что, в данном конкретном случае на один запрос поступило пять от*, ветов ICMP echo reply. Вообще говоря, так как атака Smurf была придуман^; сравнительно давно, многие производители включили в свои операционный системы защиту от подобных запросов, точнее расширения, препятствующий
Видно, что
Видно, что
услужливому реагированию на подобные широковещательные запросы. В сегмен* те сети, в котором выполнялась подобная команда, располагается около 130 компьг ютеров, работающих под управлением Microsoft Windows 2000, Windows 9' и Windows NT. Ни одна из этих операционных систем не откликнулась на запро а ответ прислали маршрутизатор Cisco Systems 805 (программное обеспечен* c805-y6-mw.120-4.XM), коммутаторы Hewlett-Packard ProCurve Switch 4000;
обладающие IP-адресами для управления через сеанс Telnet, и источники бесперебойного питания компании АРС (также имеющие интерфейс для подключения к локальной сети).
Важно отметить, что подобный подход к определению работающих хостов применим только к тем из них, которые работают под некоторыми версиями операционной системы UNIX (насколько известно автору, отвечать будет, например, RedHat Linux 6.2 Kernel 2.2.14 или, нтнример, Solaris 2.8), в то время как все операционные системы Microsoft проигнорируют отправителя. Кстати, если сослаться на стандарты, а именно на документ RFC 1122, содержащий требования к хостам в сети Интернет, то в нем можно увидеть утверждение, что при получении запроса echo request с широковещательным (или групповым) адресом хосты вправе его игнорировать.
Обратите внимание на то, что МАС-адрес получателя запросов широковещательный (FF:FF:FF:FF:FF:FF). Даже если сеть построена исключительно на основе коммутаторов, запрос дойдет до всех локальных хостов, так как по умолчанию коммутаторы передают широковещательный адрес. Кроме того, хочу отметить еще одну особенность, связанную с широковещательным запросом ICMP echo request. В настоящее время многие компании предпочитают использовать модемы серии xDSL, снабженные портом Ethernet. Подобные модемы работают как мосты и, соответственно, таким же образом будут фильтровать широковещательный трафик.
Любопытным свойством протокола ICMP является возможность использования запросов ICMP echo с указанием размера поля данных. Если вернуться к предыдущим рисункам, можно увидеть, что в заголовках есть поле Data, которое, как вы уже догадались из названия, говорит об объеме данных в сообщении протокола. Для сообщений об ошибках протокола поле Data будет содержать часть оригинальной дейтаграммы IP, для которой это сообщение было сформировано. Длина поля данных равна длине дейтаграммы IP, за вычетом ее заголовка.
В качестве примера здесь можно выполнить следующую команду ping:
C:\>ping -1 5000 192.168.3.255
Обмен пакетами с 192.168.3.255 по 5000 байт:
Ответ от 192.168.3.255: число байтов=5000 время=30мс TTL=64
Ответ от 192.168.3.255: число байтов=5000 время=20мс TTL=64
Ответ от 192.168.3.255: число байтов=5000 время=10мс TTL=64
■ В приведенной команде ping параметр -I 5000 определяет как раз объем посылаемых данных в запросе (5000 байт). На сетевом уровне это выглядит следующим образом:
3.057392 192.168.3.39 192.168.3.255 ICMP Echo (ping) request
3.057448 192.168.3.39 192.168.3.255 IP Fragmented IP protocol (proto=ICMP 0x01. off=1480)
3.057473 192.168.3.39 192.168.3.255 IP Fragmented IP protocol (proto=ICMP 0x01, off=2960)
3.057496 192.168.3.39 192.168.3.255 IP Fragmented IP protocol (proto=ICMP 0x01, Off=4440)
Так как протокол ICMP использует дейтаграммы IP, а последние огран] ны максимальным размером кадра сети Ethernet (имея в виду наш конкрет] случай), то выполняется процедура фрагментации, которая ниже будет расе» репа более подробно. Сейчас нужно заострить внимание па том, что в регулы
фрагментации в сети от отправителя запроса передаются четыре кадра Ether™ каждый из которых песет в себе дейтаграмму IP и сообщение ICMP. ПоскольЙ
в команде ping вновь указывался широковещательный адрес, МАС-адрес отпй
вителя всех этих четырех кадров установлен в FF:FF:FF:FF:FF:FF.
Все хосты в сети получают такой запрос, но как уже было отмечено, не i отвечают. Хост с адресом 192.168.3.65 получает все четыре кадра, обнаружив® что это фрагменты одной дейтаграммы, для которой выполнялась фрагмент
ция, собирает в памяти фрагменты в одно целое, а затем, анализируя заголовс
определяет, что тело дейтаграммы несет сообщение ICMP echo request и, слей заложенной в него логике, отправляет ответ. Еще раз поставлю ударение на та что «эхо» содержит в себе тот же объем данных, что был в запросе. В результа в ответный путь также посылаются четыре кадра, возникающие после процед
ры еще одной фрагментации:
66 3.077251 192.168.3.65 192.168.3.39 ICMP Echo (ping) reply
67 3.077278 192.168.3.65 192.168.3.39 IP Fragmented IP protocol (proto=ICMP':;f
0x01. off=1472)-.4]
68 3.077290 192.168.3.65 192.168.3.39 IP Fragmented IP protocol (proto=ICMP Ж
0x01, off=2944)"^K
69 3.077298 192.168.3.65 192.168.3.39 IP Fragmented IP protocol (proto=ICMP'«1
0x01. off=4416)<
Вообще говоря, при ответе на запрос echo request получатель ограничивает^ только лишь изменением типа сообщения на echo reply и пересчетом контро./^ ной суммы заголовка повой дейтаграммы, а остальные поля остаются в непрй- косновспности. ‘
Именно на данной особенности протокола ICMP или, точнее говоря, на еГС реализации во многих операционных системах играет атака Smurf. Легко понята что посылая один запрос размером 5000 байт, нам следует ожидать два (или более) ответа, каждый объемом в те же 5000 байт. К счастью, не все хосты в сетй радушны и отзывчивы, а лишь некоторые. В противном случае в сети из ста компьютеров на один запрос в 5000 байт пришли бы ответы с совокупным раз* мером 100 х 5000 байт, или 500 Кбайт! Ниже атака Smurf будет рассмотрен^ подробнее, но уже сейчас можно сделать предварительный вывод о ее послеД^ ствиях в случае, если атакующий направил в крупную распределенную се^ большой запрос по относительно медленному каналу связи — ответ займет ей полностью. ?
Посмотрите па первый кадр запроса ICMP echo (см. рис. 4.10). Видно, чте поле данных сообщения ICMP равно 1472 байт. Наблюдается соответствий теории, согласно которой максимальный размер кадра в сети Ethernet рав® 1500 (или 1514, если считать 14 байт заголовка самого кадра) байт, заголор®
т
■ соОбщение ICMP echo request
F "
дейтаграммы IP занимает 20 байт, заголовку сообщения ICMP echo request отводится 8 байт. Это объясняет наличие четырех кадров в сети (или одной дейтаграммы IP и трех ее дополнительных фрагментов) от одного запроса размером в 5000 байт — первые три кадра имеют размер 1514 байтов, а третий кадр — 602 байт. В итоге по сети передается 5144 байт (3 х 1514 + 602 =
MSMS= 5144).
MS
MS
; 11 3.057392 192ЛМ.3.39 192.100.3.255 ICMP t<ho (ptnq) t«|Uft«
Frame И (1514 bytes on wire, 1514 bytes captured)
^Ethernet В Internet 0 Internet -Type: -Code:^Ethernet В Internet 0 Internet -Type: -Code:Src: OO:dO:b7:ba=bf:19, Dst: ff:ff:ff:ff:ff:ff
^Ethernet В Internet 0 Internet -Type: -Code:
^Ethernet В Internet 0 Internet -Type: -Code:
Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192-168.3.255 (192-168.3.255) Control Message Protocol
8 (Echo (ping) request)
0
>::«•>: :-.-. ..’••;• •"•••::;:: ;..•• •• :->;: :•:-.;.-••: >ы .•••;-.-: > ■.:•:::-:':•':■■:::--::::.:-•■.•: ■<’"-’:>’Л:<:; ■.-:.•:.-■•■::-■::::■::..:•.-■:::■:;■■-:■: Т"':: к-:;/ "•:•:•:;•: -:у.:-:^;:-::.-; .--•:• ?-:-:.:-ь-:-:^-uxicj-tX;:;:::::::::::^
пппп
ff
ff
ff
ff
ff
ff
00
do
b7
ba
bf
19
08
00
45
00
E-
0010
05
de
5b
2b
211
Lill
811
111
37
8b
ell
a8
113
27
ell
a8
..U% ... 7....’..
0020
03
ff
08
00
fO
4f
02
00
4f
no
61
62
63
64
65
66
,0.. O.abcdef
0030
67
68
69
6a
6b
6c
6d
6e
6f
70
71
72
73
74
75
76
ghijklmn opqrstuv
ПОДИ
77
HI
И 9
И 7
Rd
HR
RR
Й7.
K«
R.u
Ro
RR
Ил
Rd
Ro
w..
mok/'rl of » ki il/lmrin
Рис. 4.10. Сообщение ICMP echo request с максимальным полем Data
-Checksum: 0xf04f
-Identifier: 0x0200
-Sequence number: 4f:00
-Data (1472 bytes)
Уже упоминавшийся документ RFC 792 не определяет, как много данных должно посылаться с запросом ICMP echo request. В нем есть только фраза «добавить некоторые данные», по при этом какие именно данные и в каком количестве должны быть добавлены, не указывается. Тем самым возникает потребность в рассмотрении следующих вопросов — смещение начала порции данных относительно заголовка сообщения ICMP, размер этой порции и содержимое.
В операционных системах семейства Microsoft Windows размер поля данных по умолчанию (если явно не указано другое значение) составляет 32 байт, а общий размер дейтаграммы равен 60 байт (74-14; размер кадра для стандартного сообщения ICMP echo request за вычетом заголовка Ethernet). При этом поле данных начинается сразу за заголовком сообщения ICMP. Для большинства UNIX-систем размер поля данных равен 56 байт, а итоговая дейтаграмма IP включает в себя 80 байт, где первые 8 байт в поле данных служат 1 Для вычисления значения времени кругового обращения (Round-Trip Time — RTT). Аналогично, может отличаться и полезная нагрузка поля данных (напомню. что стандарт не указывает на определенные шаблоны заполнения). Так, Для систем Microsoft шаблон заполнения представляет собой повторяющийся набор символов «abcdefghijkhnnopqrstuvw». На рис. 4.11 показан запрос с акцентом на повторяющееся содержимое поля Data. Кстати, именно на примере такого простого содержимого интересно и наглядно наблюдать процедуру шифрования передаваемых данных (или их сжатия), например с помощью протокола РРТР (глава 10).
Й-Frame 16 ЙEthernet Й Internet В Internet -Type: -Code:Й-Frame 16 ЙEthernet Й Internet В Internet -Type: -Code:003067 68696а6Ьбс6dбе6f 70 71 72 73 74 75 76ghijklmnopqrstuv0040776162636465666768696а6Ь6с6dбе6fwabedefghijklmno0050707172737475767761626364656667 88pqrstuvwabcdefgh006069ба6Ь6с6dбе6f707172737475767761ijklmnopqrstuvwa007062636465666768696а6Ь6с6dбе6f70 71bedefghijklmnopq00807273747576776162636465666768696аrstuvwabcdefghij00906Ь6с6dбе6f7071727374757677616263klmnopqrstuvwabcООаО6465666768696а6Ь6с6dбе6f70717273defghijkImnopqrsООЬО747576776162636465666768696а6Ь6сtuvwabcdefghijklООсО6dбе6f70717273747576776162636465mnopqrstuvwabcde00d0666768696а6Ь6с6dбе6f707172737475fghijklmnopqrstu00е076. 77.6162636465666768696а6Ь6 с6dбеvwabedefrhiiklmn003067 68696а6Ьбс6dбе6f 70 71 72 73 74 75 76ghijklmnopqrstuv0040776162636465666768696а6Ь6с6dбе6fwabedefghijklmno0050707172737475767761626364656667 88pqrstuvwabcdefgh006069ба6Ь6с6dбе6f707172737475767761ijklmnopqrstuvwa007062636465666768696а6Ь6с6dбе6f70 71bedefghijklmnopq00807273747576776162636465666768696аrstuvwabcdefghij00906Ь6с6dбе6f7071727374757677616263klmnopqrstuvwabcООаО6465666768696а6Ь6с6dбе6f70717273defghijkImnopqrsООЬО747576776162636465666768696а6Ь6сtuvwabcdefghijklООсО6dбе6f70717273747576776162636465mnopqrstuvwabcde00d0666768696а6Ь6с6dбе6f707172737475fghijklmnopqrstu00е076. 77.6162636465666768696а6Ь6 с6dбеvwabedefrhiiklmnРис. 4.11. Содержимое поле Data сообщения ICMP echo requestРис. 4.11. Содержимое поле Data сообщения ICMP echo request-Checksum: 0xe64f-Identifier: 0x0200-Sequence number: 59:00-Data (1472 bytes)-Checksum: 0xe64f-Identifier: 0x0200-Sequence number: 59:00-Data (1472 bytes)
Й-Frame 16 ЙEthernet Й Internet В Internet -Type: -Code:
Й-Frame 16 ЙEthernet Й Internet В Internet -Type: -Code:
0030
67 68
69
6а
6Ь
бс
6d
бе
6f 70 71 72 73 74 75 76
ghijklmn
opqrstuv
0040
77
61
62
63
64
65
66
67
68
69
6а
6Ь
6с
6d
бе
6f
wabedefg
hijklmno
0050
70
71
72
73
74
75
76
77
61
62
63
64
65
66
67 88
pqrstuvw
abcdefgh
0060
69
ба
6Ь
6с
6d
бе
6f
70
71
72
73
74
75
76
77
61
ijklmnop
qrstuvwa
0070
62
63
64
65
66
67
68
69
6а
6Ь
6с
6d
бе
6f
70 71
bedefghi
jklmnopq
0080
72
73
74
75
76
77
61
62
63
64
65
66
67
68
69
6а
rstuvwab
cdefghij
0090
6Ь
6с
6d
бе
6f
70
71
72
73
74
75
76
77
61
62
63
klmnopqr
stuvwabc
ООаО
64
65
66
67
68
69
6а
6Ь
6с
6d
бе
6f
70
71
72
73
defghijk
Imnopqrs
ООЬО
74
75
76
77
61
62
63
64
65
66
67
68
69
6а
6Ь
6с
tuvwabcd
efghijkl
ООсО
6d
бе
6f
70
71
72
73
74
75
76
77
61
62
63
64
65
mnopqrst
uvwabcde
00d0
66
67
68
69
6а
6Ь
6с
6d
бе
6f
70
71
72
73
74
75
fghijklm
nopqrstu
00е0
76. 77.
61
62
63
64
65
66
67
68
69
6а
6Ь
6 с
6d
бе
vwabedef
rhiiklmn
0030
67 68
69
6а
6Ь
бс
6d
бе
6f 70 71 72 73 74 75 76
ghijklmn
opqrstuv
0040
77
61
62
63
64
65
66
67
68
69
6а
6Ь
6с
6d
бе
6f
wabedefg
hijklmno
0050
70
71
72
73
74
75
76
77
61
62
63
64
65
66
67 88
pqrstuvw
abcdefgh
0060
69
ба
6Ь
6с
6d
бе
6f
70
71
72
73
74
75
76
77
61
ijklmnop
qrstuvwa
0070
62
63
64
65
66
67
68
69
6а
6Ь
6с
6d
бе
6f
70 71
bedefghi
jklmnopq
0080
72
73
74
75
76
77
61
62
63
64
65
66
67
68
69
6а
rstuvwab
cdefghij
0090
6Ь
6с
6d
бе
6f
70
71
72
73
74
75
76
77
61
62
63
klmnopqr
stuvwabc
ООаО
64
65
66
67
68
69
6а
6Ь
6с
6d
бе
6f
70
71
72
73
defghijk
Imnopqrs
ООЬО
74
75
76
77
61
62
63
64
65
66
67
68
69
6а
6Ь
6с
tuvwabcd
efghijkl
ООсО
6d
бе
6f
70
71
72
73
74
75
76
77
61
62
63
64
65
mnopqrst
uvwabcde
00d0
66
67
68
69
6а
6Ь
6с
6d
бе
6f
70
71
72
73
74
75
fghijklm
nopqrstu
00е0
76. 77.
61
62
63
64
65
66
67
68
69
6а
6Ь
6 с
6d
бе
vwabedef
rhiiklmn
Рис. 4.11. Содержимое поле Data сообщения ICMP echo request
Рис. 4.11. Содержимое поле Data сообщения ICMP echo request
-Checksum: 0xe64f
-Identifier: 0x0200
-Sequence number: 59:00
-Data (1472 bytes)
-Checksum: 0xe64f
-Identifier: 0x0200
-Sequence number: 59:00
-Data (1472 bytes)
<f# 1Ь Ь1618И19?ЛПв^:391Ч2ЛЬ8:3:255Ц-МРЕс1№(р11
(1514 bytes on wire, 1514 bytes captured)
II, Src= 00:d0:b7:ba:bf:19, Dst: ff:ff:ff:ff:ff: ff
Protocol, Src Addr: 192-168-3-39 (192.168.3.39), Dst Addr: 192.168.3.255 Control Message Protocol
8 (Echo (ping) request)
0
Сообщение ICMP source quench (подавление источника)
Протокол ICMP применим в ситуации, когда, например, получатель испыты! ст трудности при обработке объемного трафика от отправителя. В этом слу чае одним из способов избежать проблем может быть обращение к отправите^ с просьбой снизить скорость отправки данных — с помощью посылки сообщей) ICMP source quench (подавление источника). При этом поле Туре устанавлйЬ| ется в значение 4, а поле Code всегда равно нулю. Сообщение source quench.™ жет генерироваться как маршрутизатором, так и конечным хостом. Первый чай означает, что маршрутизатор не имеет свободного буферного, пространств необходимого ему для постановки дейтаграммы в очередь (глава 6 — настрой® очередей на маршрутизаторах) для передачи по каналу связи. Если обратитбад к документу RFC 1812, то там можно найти информацию о том, что маршру* тизатору нс следует (should not) генерировать эти сообщения. Если они все -Я^ посылаются отправителю, то он должен иметь возможность ограничить ск® рость, с которой происходит их отправка. В противном случае не исключаете® что попытки маршрутизатора уйти от перегрузки будут напрасными. Если W сам маршрутизатор получил такое сообщение, то он вправе его игнорировав В том случае, когда сообщение генерируется получателем информации, означает, что дейтаграммы от отправителя поступают слишком быстро — бы® рее, чем они могут быть обработаны.и
Получатель сообщения source quench обязан снизить скорость отправки информации. После получения этого сообщения сигнал о его получении должен быть передан на транспортный уровень протоколам TCP или UDP. Протокол
TCP в состоянии снизить скорость отправки сегментов не прерывая установленное соединение с получателем. На рис. 4.12 показан пример сети (реальной), в которой может задействоваться сообщение source quench. Внутренний хост работает в сети Интернет с неким сервером (например, по протоколу HTTP). Все взаимодействие осуществляется через защитный экран (как именно построен защитный экран, сейчас не суть важно). За защитным экраном располагается маршрутизатор Cisco 1720, который с помощью модема «Натеке» FlexDSL подключается к поставщику услуг Интернета. В какой-то момент, вви
ду интенсивного трафика, некий промежуточный маршрутизатор в сети Интернет переходит в состояние перегрузки и в ответ на поступление дейтаграмм IP посылает сообщение source quench с просьбой снизить интенсивность поступающего трафика. Сообщение отправляется по адресу отправителя трафика и, например, если защитный экран выполняет трансляцию адресов (технология NAT — глава 6), то сообщение ICMP поступит на внешний интерфейс защитного экрана. ‘
Протокол HTTPПротокол HTTPЗащитный экранЗащитный экранFlexDSL V.35 РАМFlexDSL V.35 РАМПромежуточный маршрутизатор Сообщение ICMP source quench
Протокол HTTP
Протокол HTTP
Защитный экран
Защитный экран
FlexDSL V.35 РАМ
FlexDSL V.35 РАМ
Рис. 4.12. Пример ситуации для формирования сообщения ICMP source quench
Рассмотрим пример перехваченного сообщения, иллюстрирующего описанную ситуацию. На рис. 4.13 видно, что устройство с адресом 194.190.134.35 (предположительно, это промежуточный маршрутизатор) отправило поФдресу внешнего интерфейса защитного экрана (193.125.203.1) сообщение ICMP source quench, которое содержит оригинальные заголовки IP и TCP.
е
hl6 5377*385326 MSK MA Rctom "kticlarnrtj Г,, I'*. al, I II "ЧГ'еОт^СфПЧ fl dkl МШ tn
Frame 916 (70 on «ire, 70 captured)
Ethernet ■ Internet ■ Internet
-Type:
-Code:
.E.
M<*
и■
Protocol, Src Addr: MSK-M9-Relarn-4.Relarn.ru (194.190.134.35), Det Addr: 193.125.203.1 (193.125.203.1) Control Message Protocol
4 (Source quench (flow control)) 0
-Checksum: 0x36cd (correct)
I} Internet Protocol, Src Addr: 193.125.203.1 (193.125.203.1), Dst Addr: bspu.secna.ru (212.192.2.193)
& Transmission Control Protocol, Src Port: 61895 (61895), Dst Port: http (80)
[-Source port: 61895 (61895)
•-Destination port: http (80)
loodb009027 OfИ 6c00 06d7 ее382208 0045 cO./
00100038b7 9c00 00f7 0136 07c2be86 23cl 7d-8.
1ПП9ПaUП1ЛЛ.ПЛ.9R«IЛП..ЛП. nn . ЛЛ46ПЛnn .99П a J R. . .
Рис. 4.13. Пример сообщения ICMP source quench
Анализируя их, можно предположить, что некий внутренний хост работ с WWW-сервером в сети (с адресом 212.192.2.193) через защитный экран и в к кой-то момент промежуточный маршрутизатор стал испытывать проблемы с обр; боткой трафика. Отмечу, что в перехваченном пакете адрес отправителя исходно дейтаграммы 193.125.203.1 — это адрес внешнего интерфейса защитного экран который выполняет процедуру трансляции адресов для всех хостов, работающи через него в сети Интернет. После того как маршрутизатор (устройство с адресов 194.190.134.35) определил факт состояния перегрузки, он попробовал «подавить»! интенсивность поступающего трафика, отправив сообщение source quench с указа»?
нием заголовка исходной дейтаграммы, чтобы отправитель сумел понять, интен-; сивность трафика какого сеанса следует снизить. Самым простым способом^ проследить отправителя этого сообщения, точнее определить его место в цепочке, до получателя трафика, является запуск команды tracert (в операционных систем мах Microsoft)..^
7
10 ms
20 ms
10 ms
MSK-KIAE-13.Relcom.EU.net [193.125.152.13]
8
10 ms
20 ms
10 ms
MSK-KIAE-Relarn-4.Relarn.ru [194.85.73.10]
9
10 ms
20 ms
10 ms
MSK-M9-Relarn-1.Relarn.ru [194.226.29.129]
10
30 ms
20 ms
20 ms
MSK-M9-Relarn-4.Relarn.ru [194.190.134.35]
11
*
1813 ms
1732 ms
ARCI-Relarn.Relarn.ru [194.226.29.66]
12
*
972 ms
1231 ms
secna-relarn-el-eO-lOMb.secna.ru [212.192.0
с максимальным
числом
Дальнейшие действия
9].:
C:\>tracert 212.192.2.193
Трассировка маршрута к bspu.secna.ru [212.192.2.193]•*
прыжков 30:
Дальнейшие действия после получения сообщения ICMP source quench в рас-ч сматриваемом примере целиком зависят от защитного экрана. В идеале, он обя^
зан переслать поступившее на его внешний интерфейс сообщение внутренне»^ хосту, который инициировал его отправку. ^ф
Важно отметить, что если сообщение ICMP source quench посылается, то он^ должно иметь в своей дейтаграмме поле IP Precedence установленным в аналб гичное значение той дейтаграммы, которая послужила причиной отправки этог^
сообшения. Забегая вперед, отмечу, что для других сообщений об ошибках протокола ICMP (как то destination unreachable, redirect, time exceeded и parameter blem) они в своих дейтаграммах могут иметь значения 6 (INTERNETWORK
CONTROL) или 7 (NETWORK CONTROL), то есть заполнение поля IP Precedence . дейтаграммы оставляется на усмотрение отправителя сообщения.
В процессе анализа трафика для подбора материала данной главы на границе внутренней сети и сети Интернет автор столкнулся с другим вариантом сообщения ICMP source quench, который немного не вписывается в рамки общепринятой теории (рис. 4.14).
ее| у7(лТз7г5^1Э11 1/1/0,11 ПМГЧяиг qik-mji (OuMoHltrul)| у7(лТз7г5^1Э11 1/1/0,11 ПМГЧяиг qik-mji (OuMoHltrul)■Frame 2261 (70 on wire, 70 captured)■Frame 2261 (70 on wire, 70 captured).-1D1 Xj —.-1D1 Xj —Ethernet■ Internet■ Internet-Type:-Code:Ethernet■ Internet■ Internet-Type:-Code:IIProtocol, Src Addr: 212.5.103.6 (212.5.103.6), Det Addr: 193.125.203.1 (193.125.203.1)Control Message Protocol4 (Source quench (flow control)) 0IIProtocol, Src Addr: 212.5.103.6 (212.5.103.6), Det Addr: 193.125.203.1 (193.125.203.1)Control Message Protocol4 (Source quench (flow control)) 0-Checksum: 0x9cl8 (correct)в Internet Protocol, Src Addr: 193.125.203. 1 (193. 125.203. 1), Det Addr: 212.5. 103.34 (212.5. 103.34)-Version: 4-Header length: 20 bytee^Differentiated Services Field: 0x00 (DSCP 0x00: Default? ECN: 0x00)-Total Length: 596-Identification: 0xd6a5tlFlags: 0x00-Fragment offset: 512-Time to live: 63-Protocol: TCP (0x06)-Header checksum: 0x0000 (incorrect, should be 0xdbl7)-Source: 193.125.203.1 (193.125.203.1)LDestination: 212-5.103.34 (212-5.103.34)LData (8 bytes)-Checksum: 0x9cl8 (correct)в Internet Protocol, Src Addr: 193.125.203. 1 (193. 125.203. 1), Det Addr: 212.5. 103.34 (212.5. 103.34)-Version: 4-Header length: 20 bytee^Differentiated Services Field: 0x00 (DSCP 0x00: Default? ECN: 0x00)-Total Length: 596-Identification: 0xd6a5tlFlags: 0x00-Fragment offset: 512-Time to live: 63-Protocol: TCP (0x06)-Header checksum: 0x0000 (incorrect, should be 0xdbl7)-Source: 193.125.203.1 (193.125.203.1)LDestination: 212-5.103.34 (212-5.103.34)LData (8 bytes)77000000 90 27Of116c0006d7ее3822080045cO001000 38 b2d84000f3010cald4056706cl7d■^..П1..П/|on.0»10nnnnnnnnЛСnnnoГ.ЛJR,b000000 90 27Of116c0006d7ее3822080045cO001000 38 b2d84000f3010cald4056706cl7d■^..П1..П/|on.0»10nnnnnnnnЛСnnnoГ.ЛJR,b.8.-@..8.-@.8"..E.■-g-■}8"..E.■-g-■};|7;|7
е
е
| у7(лТз7г5^1Э11 1/1/0,11 ПМГЧяиг qik-mji (OuMoHltrul)
| у7(лТз7г5^1Э11 1/1/0,11 ПМГЧяиг qik-mji (OuMoHltrul)
■Frame 2261 (70 on wire, 70 captured)
■Frame 2261 (70 on wire, 70 captured)
.-1D1 Xj —
.-1D1 Xj —
Ethernet■ Internet■ Internet
-Type:
-Code:
Ethernet■ Internet■ Internet
-Type:
-Code:
II
Protocol, Src Addr: 212.5.103.6 (212.5.103.6), Det Addr: 193.125.203.1 (193.125.203.1)
Control Message Protocol
4 (Source quench (flow control)) 0
II
Protocol, Src Addr: 212.5.103.6 (212.5.103.6), Det Addr: 193.125.203.1 (193.125.203.1)
Control Message Protocol
4 (Source quench (flow control)) 0
-Checksum: 0x9cl8 (correct)
в Internet Protocol, Src Addr: 193.125.203. 1 (193. 125.203. 1), Det Addr: 212.5. 103.34 (212.5. 103.34)
-Version: 4
-Header length: 20 bytee
^Differentiated Services Field: 0x00 (DSCP 0x00: Default? ECN: 0x00)
-Total Length: 596
-Identification: 0xd6a5
tlFlags: 0x00
-Fragment offset: 512
-Time to live: 63
-Protocol: TCP (0x06)
-Header checksum: 0x0000 (incorrect, should be 0xdbl7)
-Source: 193.125.203.1 (193.125.203.1)
LDestination: 212-5.103.34 (212-5.103.34)
LData (8 bytes)
-Checksum: 0x9cl8 (correct)
в Internet Protocol, Src Addr: 193.125.203. 1 (193. 125.203. 1), Det Addr: 212.5. 103.34 (212.5. 103.34)
-Version: 4
-Header length: 20 bytee
^Differentiated Services Field: 0x00 (DSCP 0x00: Default? ECN: 0x00)
-Total Length: 596
-Identification: 0xd6a5
tlFlags: 0x00
-Fragment offset: 512
-Time to live: 63
-Protocol: TCP (0x06)
-Header checksum: 0x0000 (incorrect, should be 0xdbl7)
-Source: 193.125.203.1 (193.125.203.1)
LDestination: 212-5.103.34 (212-5.103.34)
LData (8 bytes)
7
7
000000 90 27Of116c0006d7ее3822080045cO
001000 38 b2d84000f3010cald4056706cl7d
■^..П1..П/|on.0»10nnnnnnnnЛСnnnoГ.ЛJR,b
000000 90 27Of116c0006d7ее3822080045cO
001000 38 b2d84000f3010cald4056706cl7d
■^..П1..П/|on.0»10nnnnnnnnЛСnnnoГ.ЛJR,b
.8.-@.
.8.-@.
8"..E.
■-g-■}
8"..E.
■-g-■}
;|
7
;|
7
Рис. 4.14. Пример сообщения с некорректной контрольной суммой
На первый взгляд вроде бы все правильно — через защитный экран (или прямо с него) была отправлена дейтаграмма IP, в ответ на которую прислали сообщение с просьбой снизить интенсивность отправки. Но обратите внимание на поле контрольной суммы заголовка в оригинальной дейтаграмме — оно равно 0x0000, чего при нормальных условиях быть не должно. Трассировка до исходного получателя показала, что с большой долей вероятности генератором этого сообщения является маршрутизатор (по крайней мере устройство ответило на запрос Telnet) в пути до получателя. Однако логичнее было бы предположить, что в ответ на дейтаграмму с некорректным заголовком будет послано сообщение ICMP parameter problem.
Если вы установите анализатор пакетов, настроенный на перехват рассматриваемого сообщения ICMP, то увидите, что в большинстве случаев оно инициируется промежуточными маршрутизаторами и, как правило, в ответ на запросы Протокола HTTP (TCP-порт назначения 80). Если говорить конкретно о маршрутизаторах компании Cisco Systems, то они отправляют сообщения ICMP source
quench только при отсутствии буферного пространства, необходимого для хр ния пакета в очереди. Если маршрутизатор не в силах поместить пакет в очег он генерирует такое сообщение и регистрирует сброс пакета. Сказанное q сится к версиям Cisco IOS Software Releases до 11.3; маршрутизаторы, управ мые следующими (более новыми) версиями (11.3 и 12.0), не поддерживают* санную функциональность.
Сообщение ICMP destination unreachable
Протокол ICMP может также использоваться маршрутизатором для щу мирования отправителя данных о возникновении различного рода проблем, пример, он может послать сообщение destination unreachable (получатель н стижим). Получение этого сообщения будет означать, что отправитель пыта передать через маршрутизатор трафик, который настроен на блокирование с п щью списков управления доступом (access lists). В этой ситуации именно i^ шрутизатор выступает в роли отправителя сообщения destination unreachai Кроме того, маршрутизатор вправе известить отправителя о том, что получав не может принять его трафик. Например, если в распределенной сети получат? не активен, он, естественно, не в состоянии ответить, а маршрутизатор имеет пр известить об этом отправителя. Следует отметить, что хотя подобное поведй, маршрутизатора и помогает отправителю, оно попадает под разряд инструмент для проведения негативных действий в сети, например, предоставляя «доброво^ ную» помощь в сканировании. То есть хорошей практикой будет проведение'4 стройки маршрутизатора с запретом формирования сообщения unreachable ^ того, чтобы ограничить атакующего в получении лишней информации. .v
Все сообщения протокола ICMP, относящиеся к информирующим о н( стижимости получателя, имеют в своем заголовке поле Туре равным 3. При проблем с доставкой может быть несколько, и для их более точного указа служит поле Code, принимающее разные значения. Таблица 4.4 содержит пе чень кодов, присваиваемых сообщениям ICMP с типом 3.■
Таблица 4.4. Сообщения ICMP destination unreachable
Код
Значение
Условие отправки сообщения
0
Network Unreachable (сеть недостижима)
Генерируется маршрутизатором, если он не им* информации о маршруте в целевую сеть.
1
Host Unreachable (хост недостижим)
Генерируется маршрутизатором, если хост, подключенный в одну сеть с маршрутизатором/ не достижим (то есть не отвечает на запросы А
2
Protocol Unreachable
(протокол недостижим)
Генерируется, если транспортный протокол, инкапсулированный в дейтаграмму, не поддерживается получателем
3
Port Unreachable
(порт недостижим)
Генерируется, если транспортный протокол не может обработать пакет (например UDP) , с указанным портом
Код
ЗначениеУсловие отправки сообщения
4
Fragmentation needed and DF flag Генерируется, если маршрутизатору нужно Set (требуется фрагментация,выполнить фрагментацию, но был установлен
но установлен флаг DF — don'tфлаг DF
fragment — не фрагментировать)
5
Source Route Failed (ошибкаГенерируется маршрутизатором, который не сумел
маршрутизации от источника)отправить дейтаграмму далее при маршрутизации
от источника
6
Destination Network UnknownДокумент RFC 1812 определяет, что сообщение
(целевая сеть неизвестна)с таким кодом не следует формировать, а следует
использовать сообщение с кодом 0 (сеть недостижима)
7
Destination Host UnknownФормируется, если маршрутизатор смог определить,
(целевой хост неизвестен)что хост — получатель дейтаграммы не существует
8
Source Host Isolated (отправитель Маршрутизатор был настроен так, чтобы запретить изолирован)маршрутизацию от определенного отправителя
9
Communication with DestinationМаршрутизатор настроен на блокирование трафика
Network is Administrativelyдо определенной сети (подсети)
Prohibited (взаимодействие с целевой сетью запрещено,
в административном порядке)
10
Communication with DestinationМаршрутизатор настроен на блокирование трафика
Host is Administratively Prohibited до определенного хоста (взаимодействие с получателем запрещено в административном порядке)
11
Network Unreachable for Type ofМаршрутизатор генерирует это сообщение, если
Service (сеть недостижима длямаршрут в целевую сеть с запрошенным типом
заданного типа сервиса)сервиса недоступен
12
Host Unreachable for Туре Маршрутизатор не может обработать дейтаграмму, of Service (получатель недостижим так как ее маршрут до получателя не соответствует для заданного типа сервиса) требованиям по типу сервиса для этого маршрута
13
Communication AdministrativelyМаршрутизатор не может передать дейтаграмму
Prohibited (взаимодействиедалее, так как на нем настроены соответствующие
запрещено в административномфильтры
порядке)
14
Host Precedence ViolationПосылается первым маршрутизатором в пути,
(запрошенный приоритетсообщающим, что запрошенный уровень приоритета
обработки недопустим)недопустим
15
Precedence cutoff in effect Был установлен минимально допустимый уровень (заниженный уровень приоритета, а дейтаграмма послана с приоритетом приоритета) ниже этого уровня
Рассмотрим некоторые из сообщений destination unreachable с разными кодами, указывающими на разные причины сбоя при доставке дейтаграммы. Начнем с кода 13 — «взаимодействие запрещено». Отмечу, что иные маршрутизаторы Разных производителей могут отключить формирование сообщений с кодами 13, 14 и 15. в таком случае маршрутизатор просто игнорирует (отбрасывает) дейтаграммы, обработка которых запрещена.
ее1587 5903,142984 212.111.64.2 193.12SJ>tr3.1 ICMP Oe^tnahoh tmreachablr
е
е
0 Frame 587 (70 on wire, 70 captured)
0 Ethernet 0 Internet 0 InternetType:Code:0 Ethernet 0 Internet 0 InternetType:Code:II
0 Ethernet 0 Internet 0 Internet
Type:
Code:
0 Ethernet 0 Internet 0 Internet
Type:
Code:
Protocol, Src Addr: 212.111.64.2 (212.111.64.2), Dst Addr: 193.125.203.1 (193.125.203.1) Control Message Protocol
3 (Destination unreachable)
13 (Communication administratively filtered)
Г2ЙГ2ЙChecksum: 0x82af (correct)
Г2Й
Г2Й
0 Internet Protocol, Src Addr= 193.125.203.1 (193-125.203.1), Dst Addr: base96.amt.ru (212-233.69.96)
0 User Datagram Protocol, Src Port: 62789 (62789), Dst Port: 27015 (27015)
RE
0000 00 90 27 Of 11 6с 00 06 d7 ее 38 22 08 00 45 сО . ? . .1. . . .8 ..Е. 0010 00 38 Ь8 61 00 00 f4 01 6с Ь2 d4 6f 40 02 cl 7d .8.a.... l..o@..} ПП9Л aU П1 m ГМ 99 A-F nn nn ПП ЛП ДЬ nn ПП 9C, ПП 1* г v
Рис. 4.15, Пример сообщения ICMP destination unreachable
7140ms141ms130msMSK-M9-10.Rei com.EU.net [193.124.22.75]8140ms180ms141msMTUl-m9-gw.mtu.ru [193.232.246.30]9140ms140ms131msM9-Fex.core.mtu.ru [195.34.53.33]10140ms140ms131msmsk-1ki-csl-fa0-0.agtel.net [193.232.244.75]И140ms131ms130msmsk-amt-csl-a3-0-2.agtel.net [212.111.67.14]7140ms141ms130msMSK-M9-10.Rei com.EU.net [193.124.22.75]8140ms180ms141msMTUl-m9-gw.mtu.ru [193.232.246.30]9140ms140ms131msM9-Fex.core.mtu.ru [195.34.53.33]10140ms140ms131msmsk-1ki-csl-fa0-0.agtel.net [193.232.244.75]И140ms131ms130msmsk-amt-csl-a3-0-2.agtel.net [212.111.67.14][212.111.64.2] сообщает: Заданная сеть недоступна.[212.111.64.2] сообщает: Заданная сеть недоступна.1212amtcs2-e0-0.amt.ruamtcs2-e0-0.amt.ruC:\>tracert 212.233.69.961C:\>tracert 212.233.69.961В примере на рис. 4.15 через защитный экран посылалась дейтаграмма UDP с номером порта получателя 27015 (сетевая игра Counter-Strike) по адресу ■ 212.233.69.96. Генератором исходной дейтаграммы был какой-то внутренний • хост в сети, адрес которого уже трудно восстановить. Но так как дейтаграмма., прошла через защитный экран, то последний отправил ее от себя (техноло- ■ гия NAT) и выполнил трансляцию портов (технология РАТ). Это легко про-л верить, если посмотреть на заголовок протокола UDP — номера портов от-J правителя с номерами большими, чем 60 000, чаще всего указывают на работу.,.^ технологии РАТ. По мере продвижения дейтаграммы к получателю промежу-.^ точный хост с адресом 212.111.64.2 сформировал сообщение ICMP с указанием ^ того, что желаемый получатель недоступен в результате применения адми-..^ нистративного фильтра и вернул в этом сообщении заголовки оригинальной дейтаграммы. Можно более наглядно посмотреть путь дейтаграммы к адресу 5 212.233.69.96, если выполнить команду tracert с указанием в качестве параметра.^ этого адреса.
7
140
ms
141
ms
130
ms
MSK-M9-10.Rei com.EU.net [193.124.22.75]
8
140
ms
180
ms
141
ms
MTUl-m9-gw.mtu.ru [193.232.246.30]
9
140
ms
140
ms
131
ms
M9-Fex.core.mtu.ru [195.34.53.33]
10
140
ms
140
ms
131
ms
msk-1ki-csl-fa0-0.agtel.net [193.232.244.75]
И
140
ms
131
ms
130
ms
msk-amt-csl-a3-0-2.agtel.net [212.111.67.14]
7
140
ms
141
ms
130
ms
MSK-M9-10.Rei com.EU.net [193.124.22.75]
8
140
ms
180
ms
141
ms
MTUl-m9-gw.mtu.ru [193.232.246.30]
9
140
ms
140
ms
131
ms
M9-Fex.core.mtu.ru [195.34.53.33]
10
140
ms
140
ms
131
ms
msk-1ki-csl-fa0-0.agtel.net [193.232.244.75]
И
140
ms
131
ms
130
ms
msk-amt-csl-a3-0-2.agtel.net [212.111.67.14]
[212.111.64.2] сообщает: Заданная сеть недоступна.
[212.111.64.2] сообщает: Заданная сеть недоступна.
12
12
amtcs2-e0-0.amt.ru
amtcs2-e0-0.amt.ru
C:\>tracert 212.233.69.961
C:\>tracert 212.233.69.961
Видно, что последним на пути следования дейтаграммы было устройство I (вероятнее всего это маршрутизатор) с адресом 212.111.64.2. ■;
Рассмотрим еще один пример (рис. 4.16), связанный с работой почтовой и программы. В данном случае была сделана попытка отправить почту (устано-, i вить соединение TCP с портом 25 на стороне получателя) серверу с адресом, j 195.242.2.249. В ответ промежуточный маршрутизатор отправил сообщение, ...1 уведомляя, что взаимодействие с указанным сервером запрещено администрато- >1 ром (скорее всего настроен фильтр на маршрутизаторе, блокирующий пакеты^ на определенные порты). Ав
968 (7U on wire, 70 captured)
я Internet Protocol, Src Addr= 212.113.96.94 (212. 113.96.94), Dst Addr: 193. 125.203.1 (193.125.203. 1)
a Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 13 (Communication administratively filtered)
Checksum: Oxfbla (correct)
0 Internet Protocol, Src Addr: 193.125.203.1 (193.125.203.1), Dst Addr: 195.242.2.249 (195.242.2.249)
В Transmission Control Protocol, Src Port: 61336 (61336), Dst Port: smtp (25)
Source port: 61336 (61336)
Destination port: smtp (25)
ГллПП 00 9U 27 Of 11 6c 00 06 d7 ее 38 22 08 00 45 00 ..’..1.. ,.8"..E. 0010 00 38 ac 8a 00 00 fc 01 50 eb d4 71 60 5e cl 7d .8 P..q-'.}
Innirl “b ni. n^ .u-: th u nn.bo.nn nn <b.nri.nn.M йь.вя r.nw
В
Рис. 4.16. Второй пример сообщения ICMP destination unreachable
Завершим рассмотрение сообщения ICMP destination unreachable последним примером (рис. 4.17).
рУИ)ММЫ^2Л293К1^
™.vlKl
fflFrane 166?7 (82 on wire, 82 captured)
IS Ethernet IB Internet В Internet Type: Code:
Protocol, Src Addr! VG-2-EO-l-core.teieeore.net.ru (213.135.64.$7), Det Addri 193-125.203-{ (193-125.203.1) Control Message Protocol 3 (Destination unreachable) 13 (Communication administratively filtered)
Checksum: 0xa04b (correct)
0 Internet Protocol, Src Addr: {93.125.203-1 (193-125.203.1), Dst Addr: VG-4-53-dialup.access.telecore.net.ru (213.135-65-55)
0 Transmission Control Protocol, Src Port: http (80), Dst Port: 1087 (1087), Seq: 3866958536, Ack: 3313912298
Source port: http (80)
Destination port: $087 ($087)
Sequence number: 3866958536
Header length: 20 bytes
В Flags: 0x0004 (RST)
Vindov size: 0
Checksum: 0xf75c (correct)
7k
Рис. 4.17. Третий пример сообщения ICMP destination unreachable
Здесь обратите внимание на то, что в возвращенном сообщении ICMP включены заголовки IP и TCP и для последнего в оригинальной дейтаграмме номер порта отправителя был установлен в значение 80, а номер порта получателя — 1087. Учитывая то, что номер 80 зарезервирован для протокола HTTP, можно сделать вывод, что сегмент TCP с такими номерами портов был послан внутренним WWW-сервером получателю с адресом 213.135.65.55, находящемуся за защитным экраном. Кроме того, в сегменте TCP был установлен флаг RST. Это Указывает на то, что сервер разрывает логическое соединение с клиентом. С большой долей вероятности можно предположить, что пользователь, работая через Модем с модемным пулом провайдера (если принимать во внимание адреса DNS, то провайдера telecore — полагаю, что имя домена совпадает с именем компании), просматривал содержимое сайта внутри сети, а потом резко отключался от модемного пула. Как правило, серверы доступа, обслуживающие удаленных пользователей, настроены на автоматическое выделение адресов своим клиентам и после рассоединения адрес стал свободен. Так как клиент быстро отклю-
чился, его программа-обозреватель не успела корректно завершить соедине с сервером WWW, и последний после истечения тайм-аута отправил сейм TCP с флагом RST для принудительного завершения сеанса. Однако адрес; которому отправилась дейтаграмма IP с сегментом TCP, был уже недостуй и поэтому сервер доступа сформировал рассматриваемое сообщение ICMP.
Теперь перейдем к другому сообщению, с кодом 1 (host unreachable — «х
недостижим»), пример которого приведен на рис. 4.18.
1^23674 7563426717 195.131 Ф» 1 Н > IA ПР КЧРЩ *rtnid4hmu.wjtw№
iFrame 2367 (70 on wire, 70 captured)
фEthernet 11
фInternet Protocol, Src Addr: 195.131.99.1 (195.131-99.1), Det Addr: 193.125-203.1 (193.125.203.1)■
Ellnternet Control Message Protocol
-Type: 3 (Destination unreachable)•
-Code: 1 (Host unreachable)
-Checksum: 0x690e (correct)
EHnternet Protocol, Src Addr: 193.125.203*1 (193.125-203-1), Dst Addr: ip99-31-adsl.wplus.ru (195-131.99.31)
STransmission Control Protocol, Src Port: http (80), Dst Port: 61035 (61035)
lioobo00 90 27 Of 11 6 c 00 06 17 ее 38 22 08 00 45 00 17ГТГ77ТГЁТ" — 1 0010 00 38 c7 83 00 00 £9 01 47 3d c3 83 63 01 cl 7d .8 G=..c..}
^ЛП^П П1nn nn пп ПП ПП П9 ДЛ
Рис. 4.18. Пример сообщения ICMP host unreachable
Источником сообщения является маршрутизатор, извещающий отправив ля о том, что по каким-то причинам получатель недостижим (маршрутизаи проверяет это, анализируя поступление ответа на запрос ARP). Например,^ указанному IP-адресу не найден активный хост, или же последний времен? не активен, или, например, хост настроен так, чтобы не отвечать на опред ленный трафик (используется персональный защитный экран). Как уже отмен лось, в такой ситуации получатель сам не может послать сообщение об ошиб и маршрутизатор делает это за него. Не трудно понять, что такая информащ о сети очень ценна. Она помогает представить сеть в целом. Кроме того, е^ для сканирования используется специальное программное обеспечение, то п лучение подобного сообщения позволит в будущем не обращать внимание 1 неактивные хосты, сконцентрировав его на активных. Это способствует сокр щению времени сбора информации. Если в распределенной сети используюр маршрутизаторы Cisco Systems, то при настройке на них списков доступа мф но указать ключевое слово no ip unreachable, заставляя маршрутизатор отк заться от генерирования сообщения ICMP host unreachable. Кроме того, им^ смысл рекомендовать на граничном маршрутизаторе настроить фильтр, кот рый будет блокировать исходящие сообщения host unreachable из внутренне сети в Интернет.4
По умолчанию маршрутизаторы Cisco Systems настроены так, что отпр; ляют различные сообщения ICMP unreachable. Например, когда маршрут® тор получает на свой интерфейс нешироковещательный пакет, адресован® самому маршрутизатору с использованием неподдерживаемого протокола, в .< вет посылается ICMP protocol unreachable. При получении дейтаграммы, мар рут которой до получателя не известен, отправителю также посылается 1С^ host unreachable.■■
Администратор может ограничить интенсивность отправки сообщений ICMP destination unreachable с помощью команды ip ICMP rate-limit unreachable (влияет на все интерфейсы и выполняется в глобальном режиме настройки). В качестве параметра команды указывается временной интервал в миллисекундах, в течение которого допускается отправка только одного сообщения ICMP destination unreachable. По умолчанию это значение составляет 500 мс. Другим параметром может быть ключевое слово DF, позволяющее ограничить количество посылаемых сообщений ICMP, эти сообщения будут иметь код 4 («требуется фрагментация, но установлен флаг DF»). Маршрутизатор поддерживает два таймера — один для обычных сообщений ICMP destination unreachable, а второй — для тех же сообщений, но с кодом 4.
В приведенном примере основанием для отправки этого сообщения ICMP был пакет протокола TCP с адресом назначения 195.131.99.31 и портом 80 на стороне получателя (протокол HTTP). Здесь очень велика вероятность того, что некий хост работал (с использованием технологии ADSL) через защитный экран с внутренним сервером WWW и в какой-то момент хост стал неактивен, но сервер, не зная об этом, продолжал посылать пакеты TCP. Промежуточный маршрутизатор с адресом 195.131.99.1, обнаружив факт неактивности хоста, сформировал в ответ на пакеты сообщение ICMP.
Рассмотрим другой пример перехвата сообщения ICMP (рис. 4.19), в котором получатель информирует отправителя о том, что запрошенный порт протокола UDP недостижим (сообщение Port Unreachable). В этом примере отправитель пытался послать информацию по протоколу UDP на порт с номером 53.
I'i'l ЧЫ < /2011 rr, oik wua 143 121 ZU'J.1 ICMP Urittfiatlon uniI'i'l ЧЫ < /2011 rr, oik wua 143 121 ZU'J.1 ICMP Urittfiatlon uniFrame 199 (70 on wire, 70 captured)Frame 199 (70 on wire, 70 captured)Ethernet Internet ■ Internet-Type:-Code:Ethernet Internet ■ Internet-Type:-Code:Protocol, Src Addr = ns.cdessa.ua (195.114.128.50), Dst Addr: 193.125.203.1 (193.125.203.1) Control Message Protocol3 (Destination unreachable)3 (Port unreachable)Protocol, Src Addr = ns.cdessa.ua (195.114.128.50), Dst Addr: 193.125.203.1 (193.125.203.1) Control Message Protocol3 (Destination unreachable)3 (Port unreachable)-Checksum: 0x6759 (correct)^Internet Protocol, Src Addr: 193.125.203. 1 (193, 125.203.1), Dst Addr: ns.odessa.ua (195.114.128.50) &User Datagram Protocol, Src Port: 62950 (62950), Dst Port: domain (53)-Checksum: 0x6759 (correct)^Internet Protocol, Src Addr: 193.125.203. 1 (193, 125.203.1), Dst Addr: ns.odessa.ua (195.114.128.50) &User Datagram Protocol, Src Port: 62950 (62950), Dst Port: domain (53)
I'i'l ЧЫ < /2011 rr, oik wua 143 121 ZU'J.1 ICMP Urittfiatlon uni
I'i'l ЧЫ < /2011 rr, oik wua 143 121 ZU'J.1 ICMP Urittfiatlon uni
Frame 199 (70 on wire, 70 captured)
Frame 199 (70 on wire, 70 captured)
Ethernet Internet ■ Internet
-Type:
-Code:
Ethernet Internet ■ Internet
-Type:
-Code:
Protocol, Src Addr = ns.cdessa.ua (195.114.128.50), Dst Addr: 193.125.203.1 (193.125.203.1) Control Message Protocol
3 (Destination unreachable)
3 (Port unreachable)
Protocol, Src Addr = ns.cdessa.ua (195.114.128.50), Dst Addr: 193.125.203.1 (193.125.203.1) Control Message Protocol
3 (Destination unreachable)
3 (Port unreachable)
-Checksum: 0x6759 (correct)
^Internet Protocol, Src Addr: 193.125.203. 1 (193, 125.203.1), Dst Addr: ns.odessa.ua (195.114.128.50) &User Datagram Protocol, Src Port: 62950 (62950), Dst Port: domain (53)
-Checksum: 0x6759 (correct)
^Internet Protocol, Src Addr: 193.125.203. 1 (193, 125.203.1), Dst Addr: ns.odessa.ua (195.114.128.50) &User Datagram Protocol, Src Port: 62950 (62950), Dst Port: domain (53)
.8\.E.$.r.2.}.8\.E.$.r.2.}33Jg 90' 27 Of 11 6c 00 06 d? ее 38 22 08 00 45 66 :;7;j7 00 38 06 7c 00 00 ef 01 f5 24 c3 72 80 32 cl 7d .8.|.... .ch Л.1 Л-Q П*Э Й9 .50 nn nn . nn nn 4C, nn nn /JU ПЛ Й1 . «V .
.8\.E.
$.r.2.}
.8\.E.
$.r.2.}
3
3
Рис. 4.19. Первый пример сообщения port unreachable
В приведенном перехвате был сделан запрос на разрешение доменного имени с помощью протокола UDP (порт получателя 53). Целевой хост в сети Интернет в ответ отправил сообщение ICMP port unreachable, указывающее на то, Что запросы к требуемому порту им не могут быть обработаны. Можно предположить, что предпринималась попытка разрешить адрес и был послан запрос СеРверу, который по какой-то причине не смог его обработать, хотя его имя косвенно указывает на то, что это сервер разрешения имен (обычно, хотя и не всегДа, в сети Интернет имя хоста ns указывает на то, что это name server — сервер
имен). Точнее говоря, причиной отправки является то, что порт с номером закрыт, но при этом сам хост работает. Следуя подобной логике, можно выбр порт протокола UDP, который заведомо будет закрытым (closed), и послать него пакет. Подобный метод годится для определения злоумышленником н строенных списков управления доступом на граничном маршрутизаторе — е в ответ на наш запрос ничего не поступило, то это может указывать на то, ч маршрутизатор с настроенными списками доступа не пропустил запрос, а е поступает сообщение ICMP port unreahcable, то интересующий хост работай и граничный маршрутизатор не настроен на блокирование входящих пакет с выбранным номером порта, а также на исходящие сообщений ICMP.
Рассмотрим пример пакета (рис. 4.20), который в состоянии повлечь формиЗ рование сообщения ICMP port unreachable. Этот пакет был перехвачен и начальной загрузке одного из компьютеров в сети, работающих под управлец ем Microsoft Windows 2000 Professional. Если обратиться к справочнику пор^ UDP, то можно найти информацию о том, что порт 1900 используется при боте протокола SSDP (Simple Service Discovery Protocol, протокол упрощен службы обнаружения).
1^ 506 5/^64055 192.1 ЬИ.З.ЗЧ 192.169 3.254 StiWM 4ARUM * МГI
IFrame 506 (174 bytes on wire. 174 bytes captured)
Ethernet II, Src: 00:d0:b7:barbf:l9, Dst: 00:dO:b7=a8:50:d2
Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.254 (192.168.3.254)
User Datagram Protocol, Src Port: 1073 (1073), Dst Port: 1900 (1900)
Hypertext Transfer Protocol
-M-SEARCH * HTTP/l.l¥r¥n
HOST: 239.255.255.250:1900¥r¥n
MAH: "ssdp:discover"¥r¥n
MX: 3¥r¥n
ST: urn:schenias-upnp-org:service:lfAHIPConnection: l¥r¥n
Mr¥n
R
0000
0010
0020
0030 nnan
00
00
03
43
dO аО fe 48
Ь7 01 04 20
а8 0с
31 2а
50
00
07
20
d2 00 6с 48
00 do
80 11
00 8с
54 54
Ь7 ЬО
06 50
Ьа cb 16 2f
bf с0 4d 31
19 а8 2d 2е
08
03
53
31
00
27
45 Od
45 00 с0 а8
41 52
0а 48
Р
;Е.
ат на на 1. 9П 19 11 10 9О 19 ш ш 9= 19 ш ш
...1.1.. ..M-SEAK
CH * HIT Р/1.1..Н
П^Т: 910 9ЦЦ W
Рис. 4.20. Пакет протокола SSDP
Этот пакет отправляется хосту с адресом 192.168.3.254, который не по^ держивает упомянутый протокол и, соответственно, порт с номером 1900 ляется закрытым. Сервер также формирует сообщение ICMP port unreachable (рис. 4.21).'
Следует отметить, что протокол TCP имеет возможность известить отправителя о неактивности определенного порта посредством возврата сегмента с уставов^ ленными флагами RST и АСК. А протокол UDP не приспособлен к извещении об ошибках, поэтому он полагается на сообщения ICMP. Этой его несамосто^ тельностью пользуются при сборе информации о сети. Так, посылая дейтаграм мы протокола UDP на различные порты и анализируя ответные сообщен^ ICMP, можно легко сформировать список активных портов на объекте иссл дования.
П00000dOb7babf1900dOb7a850d208004500001000385c7d0000800155d2cOa803fecOa8002003270303eabd00000000450000aO01Oe003000008011bOc9cOa80327cOa803fe0431ППЛПГГ7ArnnSrHR1RП00000dOb7babf1900dOb7a850d208004500001000385c7d0000800155d2cOa803fecOa8002003270303eabd00000000450000aO01Oe003000008011bOc9cOa80327cOa803fe0431ППЛПГГ7ArnnSrHR1R■ 8«.■ 8«... ,.P .. U.. .. ..E.. ,.P .. U.. .. ..EE.E.
П00000dOb7babf1900dOb7a850d208004500
001000385c7d0000800155d2cOa803fecOa8
002003270303eabd00000000450000aO01Oe
003000008011bOc9cOa80327cOa803fe0431
ППЛПГГ7ArnnSrHR1R
П00000dOb7babf1900dOb7a850d208004500
001000385c7d0000800155d2cOa803fecOa8
002003270303eabd00000000450000aO01Oe
003000008011bOc9cOa80327cOa803fe0431
ППЛПГГ7ArnnSrHR1R
■ 8«.
■ 8«.
.. ,.P .. U.. .. ..E
.. ,.P .. U.. .. ..E
E.
E.
.'л!Й^|
Г
Frame 512 (70 bytes on wire, 70 bytes captured)
Fthernet II, Src: 00:d0=b?:a8:50:d2, Dst: 00:d0:b7:ba:bf:19
Internet Protocol, Src Addr: 192.168.3.254 (192.168.3.254), Dst Addr: 192.168.3.39 (192.168.3.39)
Internet Control Message Protocol
I-Type: 3 (Destination unreachable)
-Code: 3 (Port unreachable)
-Checksum: Oxeabd (correct)
^Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.254 (192.168.3.254) tUJser Datagram Protocol, Src Port: 1073 (1073), Dst Port: 1900 (1900)
LHypertext Transfer Protocol
Рис. 4.21. Второй пример сообщения ICMP port unreachable
Например, из сети Интернет можно послать пакеты па различные адреса, принадлежащие интересующей сети. Когда граничный маршрутизатор получит эти пакеты, он проверит адреса получателей и будет принимать решение о дальнейшей обработке. В том случае, когда он не знает, как направить пакеты далее, маршрутизатор сформирует либо сообщение ICMP host unreachable (если получатель не ответил на запрос ARP), либо сообщение ICMP time exceeded. Последнее отправляется по той причине, что обработка пакета выполнялась очень долго и время жизни дейтаграммы истекло. Это может быть вызвано ожиданием ответа на запрос ARP для определения активности хоста, которому адресован пакет. Если обратно не поступило никаких сообщений, то логично предположить, что хост с определенным адресом внутри сети присутствует. Подобное сканирование может выявляться средствами IDS, но ему есть альтернатива — так называемое decoy-сканирование (подстановка адресов). Здесь «военная хитрость» заключается в том, что пакеты отсылаются с различными адресами отправителей, среди которых есть и адрес хоста, с которого осуществляется сканирование. Маршрутизатору, который не знает, какому получателю следует доставить пакет, все равно, кому адресовать сообщение ICMP host unreachable — он отправит его по всем «липовым» адресам (кроме лишнего исходящего трафика это не привнесет никаких проблем), но также и по адресу сканирующего хоста. Такие действия способны значительно затруднить однозначную идентификацию хоста, с которого происходит сбор информации о вашей сети. Поэтому можно поре- 1 комендовать просто запретить формирование сообщений ICMP host unreachable и time exceeded на граничном маршрутизаторе (или защитном экране).
i Сообщение ICMP redirect
I Рассмотрим другое сообщение протокола ICMP, которое также может оказаться ■ Лазейкой для некорректной деятельности в сети. Сообщение redirect (перенаправ- ■ ление) позволяет маршрутизатору известить отправителя информации о том, что он выбрал не оптимальный маршрут для отправки информации к получателю.
Маршрутизатор в любом случае будет передавать трафик получателю, однако отД генерируя сообщение redirect, предлагает отправителю изменить свою таблщЯ маршрутизации в пользу более предпочтительного маршрута. Важно, что маршпд тизатор должен располагаться в той же подсети, что и отправитель информации* В том случае, когда получателем сообщения redirect является маршрутизатор! он вправе игнорировать это сообщение при условии включенной поддержки! протокола маршрутизации. Кроме того, сам хост не должен посылать сообщений redirect — его инициатором может быть только маршрутизатор. Интересно отмЯ тить, что хост после получения сообщения о перенаправлении обязан изменитяй свою таблицу маршрутизации, однако само сообщение может быть проигноргдай ровано, если предложенный новый шлюз не располагается в той же подсети-ийт точнике сообщения и если отправитель этого сообщения на данный момент щя является первым транзитным узлом в пути к подразумеваемому получателю, .'и
Существуют несколько кодов для типа сообщения, равного 5 (redirect). ОнМ перечислены в табл. 4.5.■
Таблица 4.5. Коды для сообщения ICMP redirect
КодОписаниее
ОRedirect Datagram for theNetwork — перенаправление дейтаграммы для сети'*!j
Redirect Datagram for theHost — перенаправление дейтаграммы для хоста...тЗ
Redirect Datagram for the Type of Service and Network — перенаправление дейтаграммы.
для указанного типа сервиса и сетиД
Datagram for the Type of Service and Host — перенаправление дейтаграммыби
для указанного типа сервиса и хоста/И
- 1Ш1ЫЛ1*.',| U.SJS4 1411?Ьги|?П1ЧЛЛ- П Ш" lnhi.il
S-Frame 1886 (70 byfeVVni^ —- - 4
^Ethernet II, Src: 00:10:7Ъ:За:Ъ6:de, Det: 00:90= 27:Of: 11:всО
В Internet Protocol, Src Addr: 193.125.203-29 (193-125.203.29), Dst Addr: 193-125.203.1 (193. 125.203.1)
В Internet Control Message Protocol0
-Type: 5 (Redirect)
-Code: 0 (Redirect for network)0
-Checksum: 0xbc50 (correct)
-Gateway address: 193.125.203.12.
J Internet Protocol, Src Addr: 193.125.203.1 (193.125.203.1), Dst Addr: 193. 125.203.12 (193.125.203. 12) |
В Transmission Control Protocol, Src Port: pptp (1723), Dst Port: 1055 (1055)i
Рис. 4.22. Сообщение ICMP redirect (код 0)Рис. 4.22. Сообщение ICMP redirect (код 0)
Рис. 4.22. Сообщение ICMP redirect (код 0)
Рис. 4.22. Сообщение ICMP redirect (код 0)
На рис. 4.22 показан пример перехваченного сообщения ICMP redirect с кодомчто указывает на то, что перенаправление предлагается для сети. Как и ДРУ01^,сообщения об ошибках протокола ICMP, рассматриваемое включает в себя sawголовок дейтаграммы, вызвавшей отправку сообщения redirect. В данном случаиотправку сообщения вызвал пакет протокола TCP на порт 1723 — этот паке^относится к управляющему соединению РРТР.' '-Я
В распределенной сети, состоящей из нескольких связанных между собой через маршрутизаторы объектов, сообщения ICMP redirect появляются довольно часто. Лело в том, что когда загружается компьютер, работающий под какой-либо операционной системой семейства Microsoft Windows, таблица маршрутизации обычно содержит несколько записей. Например, адрес шлюза по умолчанию, допустим, это маршрутизатор. Тогда, если в сеть отправляется дейтаграмма с компьютера, информация о котором не заложена в таблицу маршрутизации, то она отправляется шлюзу по умолчанию. Однако в распределенной сети вовсе нс обязательно, что оптимальный маршрут до получателя проходит через шлюз по умолчанию. Когда ' шлюз по умолчанию получает дейтаграмму, адресованную получателю, до которого есть другой, более короткий маршрут от отправителя, он извещает последнего об этом маршруте с помощью сообщения ICMP redirect (но исходную дейтаграмму он перешлет сам). При получении сообщения ICMP хост выполняет проверку, чтобы убедиться, что оно получено от шлюза по умолчанию (а точнее, от первого в пути до получателя маршрутизатора — но при изначальной таблице маршрутизации это как раз и будет шлюз по умолчанию) и что отправитель подключен к той же сети, что и сам хост. При выполнении обоих условий новый маршрут ■ вносится в таблицу маршрутизации. Администратор может управлять подобным поведением хоста с помощью параметра Tcpip\Parameters\ EnablelCMPRedirects в реестре Windows (путь HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameter), установка которого в True (или 1; значение по умолчанию) позволит изменять таблицу маршрутизации, получая сообщение ICMP redirect.
Сервер VPNЗащитный192.168.3.252 экран192.168.3.254Сервер VPNЗащитный192.168.3.252 экран192.168.3.254192.168.2.39192.168.2.39Сервер VPN192.168.2.253Сервер VPN192.168.2.253Рис. 4.23. Пример перенаправления на реальной сетиРис. 4.23. Пример перенаправления на реальной сетиТуннель РРТРТуннель РРТРЗащитный экран 192.168.2.254Защитный экран 192.168.2.254Рассмотрим сказанное на примере. На рис. 4.23 показан фрагмент реальной сети, в которой два объекта связаны между собой через Интернет на базе технологии виртуальных частных сетей (VPN — Virtual Private Network). Связь осуществляется с помощью протокола РРТР и поддерживается двумя серверами — по одному на объект, — названных на рисунке серверами VPN (построены на базе Microsoft Windows 2000 Server). Далее в книге технология виртуальных частных сетей (а также протокол РРТР) освещается более детально, а сейчас можно считать, что эти два сервера просто маршрутизаторы, которые знают пути друг к другу.
Сервер VPNЗащитный
192.168.3.252 экран
192.168.3.254
Сервер VPNЗащитный
192.168.3.252 экран
192.168.3.254
192.168.2.39
192.168.2.39
Сервер VPN
192.168.2.253
Сервер VPN
192.168.2.253
Рис. 4.23. Пример перенаправления на реальной сети
Рис. 4.23. Пример перенаправления на реальной сети
Туннель РРТР
Туннель РРТР
Защитный экран 192.168.2.254
Защитный экран 192.168.2.254
Предположим, что хост с адресом 192.168.3.39 выполняет команду ping ^j 168.2.253 (рис. 4.23). Перед тем как отправить по сети дейтаграмму, содер^ щую запрос ICMP echo, хост проверяет свою таблицу маршрутизации и пытает выяснить, какой маршрут следует выбрать (сам хост располагается в сети юс са С 192.168.3.0/24, а получатель запроса — в другой сети 192.168.2.0/24). Л этого хост перебирает свою таблицу маршрутизации, подыскивая маршрут в j левую сеть 192.168.2.0/24. Изначально таблица имеет следующий вид.
C:\>route print -
Сетевой адрес
Маска сети
Адрес шлюза
Интерфейс
Метрику
0.0.0.0
0.0.0.0
192.168.3.254
192.168.3.39
1д
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1 С
192.168.3.0
255.255.255.0
192.168.3.39
192.168.3.39
1 €
192.168.3.39
255.255.255.255
127.0.0.1
127.0.0.1
192.168.3.255
255.255.255.255
192.168.3.39
192.168.3.39
1
224.0.0.0
224.0.0.0
192.168.3.39
192.168.3.39
1 ■
255.255.255.255
255.255.255.255
192.168.3.39
192.168.3.39
lf
Основной шлюз:
192.168.3.254
Как видно, маршрута в сеть 192.168.2.0/24 или прямо до получателя с адр сом 192.168.2.253 в таблице маршрутизации хоста нет, но есть запись шлюзап умолчанию (192.168.3.254). Обнаружив это, хост отправляет запрос ICMP eel по адресу 192.168.3.254 в надежде на то, что шлюз по умолчанию (а в рассматр; ваемой сети это адрес внутреннего интерфейса защитного экрана) знает марпцу в сеть 192.168.2.0/24. Обратите внимание на то, что сама дейтаграмма имеет адр получателя 192.168.2.253, ио на канальном уровне кадр отправляется по МАС-Д ресу, который назначен сетевой карте защитного экрана (то есть той, у котор^ IP-адрес 192.168.3.254). )
^98 33.166404 192.168.3.39 192 Л 68.2.253 ICMP tdto (Ып«) request
Й-Frame 98 Й-Ethernet ЙInternet ЙInternet - Type: -Code:Й-Frame 98 Й-Ethernet ЙInternet ЙInternet - Type: -Code:(74 bytes on wire, 74 bytes captured)'■
Й-Frame 98 Й-Ethernet ЙInternet ЙInternet - Type: -Code:
Й-Frame 98 Й-Ethernet ЙInternet ЙInternet - Type: -Code:
II, Src: 00:d0:b7=ba:bf:19, Dst: 00:d0:b7=a8:50=d2,
Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.2.253 (192.168.2.253) Control Message Protocol
8 (Echo (ping) request)
-Checksum: 0x0f5c (correct)-Identifier: 0x0200-Sequence number: 3c:00LData (32 bytes)-Checksum: 0x0f5c (correct)-Identifier: 0x0200-Sequence number: 3c:00LData (32 bytes)0000 0010 0020 0030 ПП4.П0000 0010 0020 0030 ПП4.П00 d0 00 Зс 02 fd 67 6877 6100 d0 00 Зс 02 fd 67 6877 61b7 ea 08 69 67b7 ea 08 69 67a8 9a 00 6a 64a8 9a 00 6a 645000 Of6b645000 Of6b64d2 00 5c6cd2 00 5c6c0080026d0080026ddO 01 00 6edO 01 00 6eb7 c8 3c 6fb7 c8 3c 6fba bl 0070ba bl 0070RA RR R7 . R8 RQRA RR R7 . R8 RQbf cO61 71bf cO61 7119 08 а8 03 62 63 72 7319 08 а8 03 62 63 72 73002764740027647445 00 c0 a8 65 6675 7645 00 c0 a8 65 6675 76Р.Р.;Е.;Е.V.. t.abcdef ghijklmn opqrstuv . moh.cd й^* Ы .. ..V.. t.abcdef ghijklmn opqrstuv . moh.cd й^* Ы .. ..0
-Checksum: 0x0f5c (correct)
-Identifier: 0x0200
-Sequence number: 3c:00
LData (32 bytes)
-Checksum: 0x0f5c (correct)
-Identifier: 0x0200
-Sequence number: 3c:00
LData (32 bytes)
0000 0010 0020 0030 ПП4.П
0000 0010 0020 0030 ПП4.П
00 d0 00 Зс 02 fd 67 68
77 61
00 d0 00 Зс 02 fd 67 68
77 61
b7 ea 08 69 67
b7 ea 08 69 67
a8 9a 00 6a 64
a8 9a 00 6a 64
50
00 Of
6b
64
50
00 Of
6b
64
d2 00 5c
6c
d2 00 5c
6c
00
80
02
6d
00
80
02
6d
dO 01 00 6e
dO 01 00 6e
b7 c8 3c 6f
b7 c8 3c 6f
ba bl 00
70
ba bl 00
70
RA RR R7 . R8 RQ
RA RR R7 . R8 RQ
bf cO
61 71
bf cO
61 71
19 08 а8 03 62 63 72 73
19 08 а8 03 62 63 72 73
00
27
64
74
00
27
64
74
45 00 c0 a8 65 66
75 76
45 00 c0 a8 65 66
75 76
Р.
Р.
;Е.
;Е.
V.. t.abcdef ghijklmn opqrstuv . moh.cd й^* Ы .. ..
V.. t.abcdef ghijklmn opqrstuv . moh.cd й^* Ы .. ..
Рис. 4.24. Запрос ICMP echo request, направленный удаленному серверу
Сервер с адресом 192.168.3.254 получает дейтаграмму (рис. 4.24) и, в свс очередь, проверяет собственную таблицу маршрутизации, пытаясь найти марпф; в сеть 192.168.2.0/24, где располагается получатель. У него такая запись пр
сутствует (механизм формирования таблиц маршрутизации будет рассмотрен в главе 7) и она указывает на то, что дейтаграмму необходимо доставить хосту с адресом 192.168.2.252 (сервер VPN на рисунке). Дейтаграмма передается далее по данному адресу, и одновременно сервер-защитный экран посылает отправителю дейтаграммы сообщение ICMP redirect, указывающее на то, что есть более предпочтительный маршрут до получателя, который позволяет исключить из маршрута один маршрутизатор. Рисунок 4.25 показывает это сообщение ICMP redirect, которое содержит рекомендуемый адрес нового маршрутизатора и заголовок исходной дейтаграммы (анализатор считает, что контрольная сумма неверная, так как не все поля исходного сообщения ICMP echo, по которым она вычисляется, присутствуют в полученных данных).
!Й 99 33.166641 192.168.3^54 192.160.39 КМР Redn ect!Й 99 33.166641 192.168.3^54 192.160.39 КМР Redn ectFrame 99 Ethernet Internet Internet -Type: -Code:Frame 99 Ethernet Internet Internet -Type: -Code:(70 bytes on wire, 70 bytes captured)II, Src: 00:d0:b7:a8:50:d2, Dst: 00:d0:b7:ba:bf:19Protocol, Src Addr: 192-168.3.254 (192-168.3.254), Dst Addr: 192.168.3.39 (192.168.3.39)Control Message Protocol5 (Redirect)1 (Redirect for host)(70 bytes on wire, 70 bytes captured)II, Src: 00:d0:b7:a8:50:d2, Dst: 00:d0:b7:ba:bf:19Protocol, Src Addr: 192-168.3.254 (192-168.3.254), Dst Addr: 192.168.3.39 (192.168.3.39)Control Message Protocol5 (Redirect)1 (Redirect for host)-Checksum: OxeOfd (correct),-Gateway address: 192.168.3.252tInternet Protocol, Src Addr: 192-168.3.39 (192.168.3.39), Dst Addr: 192.168.2.253 (192.168.2.253) в Internet Control Message Protocol-Type: 8 (Echo (ping) request)-Code: 0-Checksum: 0x0f5c (incorrect, should be 0xb9ff)■Identifier: 0x0200LSequence number: 3c:00-Checksum: OxeOfd (correct),-Gateway address: 192.168.3.252tInternet Protocol, Src Addr: 192-168.3.39 (192.168.3.39), Dst Addr: 192.168.2.253 (192.168.2.253) в Internet Control Message Protocol-Type: 8 (Echo (ping) request)-Code: 0-Checksum: 0x0f5c (incorrect, should be 0xb9ff)■Identifier: 0x0200LSequence number: 3c:00eoo do b7 ba bf 19 00 dO b7 a8 50 d2 08 00 45 00 00 38 fe 2e 00 00 80 01 b4 20 cO a8 03 fe cO a8S0020 03 27 05 01 eO fd cO aS 03 fe 45 00 00 3c ea 9a 4 0030 00 00 80 01 c8 bl cO a8 03 27 cO a8 02 fd 08 00 |пплп пт ц„ n? nn nneoo do b7 ba bf 19 00 dO b7 a8 50 d2 08 00 45 00 00 38 fe 2e 00 00 80 01 b4 20 cO a8 03 fe cO a8S0020 03 27 05 01 eO fd cO aS 03 fe 45 00 00 3c ea 9a 4 0030 00 00 80 01 c8 bl cO a8 03 27 cO a8 02 fd 08 00 |пплп пт ц„ n? nn nn.8..8.vvррЕЕЕ.Е.7-д7-дII
!Й 99 33.166641 192.168.3^54 192.160.39 КМР Redn ect
!Й 99 33.166641 192.168.3^54 192.160.39 КМР Redn ect
Frame 99 Ethernet Internet Internet -Type: -Code:
Frame 99 Ethernet Internet Internet -Type: -Code:
(70 bytes on wire, 70 bytes captured)
II, Src: 00:d0:b7:a8:50:d2, Dst: 00:d0:b7:ba:bf:19
Protocol, Src Addr: 192-168.3.254 (192-168.3.254), Dst Addr: 192.168.3.39 (192.168.3.39)
Control Message Protocol
5 (Redirect)
1 (Redirect for host)
(70 bytes on wire, 70 bytes captured)
II, Src: 00:d0:b7:a8:50:d2, Dst: 00:d0:b7:ba:bf:19
Protocol, Src Addr: 192-168.3.254 (192-168.3.254), Dst Addr: 192.168.3.39 (192.168.3.39)
Control Message Protocol
5 (Redirect)
1 (Redirect for host)
-Checksum: OxeOfd (correct),
-Gateway address: 192.168.3.252
tInternet Protocol, Src Addr: 192-168.3.39 (192.168.3.39), Dst Addr: 192.168.2.253 (192.168.2.253) в Internet Control Message Protocol
-Type: 8 (Echo (ping) request)
-Code: 0
-Checksum: 0x0f5c (incorrect, should be 0xb9ff)
■Identifier: 0x0200
LSequence number: 3c:00
-Checksum: OxeOfd (correct),
-Gateway address: 192.168.3.252
tInternet Protocol, Src Addr: 192-168.3.39 (192.168.3.39), Dst Addr: 192.168.2.253 (192.168.2.253) в Internet Control Message Protocol
-Type: 8 (Echo (ping) request)
-Code: 0
-Checksum: 0x0f5c (incorrect, should be 0xb9ff)
■Identifier: 0x0200
LSequence number: 3c:00
eoo do b7 ba bf 19 00 dO b7 a8 50 d2 08 00 45 00 00 38 fe 2e 00 00 80 01 b4 20 cO a8 03 fe cO a8
S0020 03 27 05 01 eO fd cO aS 03 fe 45 00 00 3c ea 9a 4 0030 00 00 80 01 c8 bl cO a8 03 27 cO a8 02 fd 08 00 |пплп пт ц„ n? nn nn
eoo do b7 ba bf 19 00 dO b7 a8 50 d2 08 00 45 00 00 38 fe 2e 00 00 80 01 b4 20 cO a8 03 fe cO a8
S0020 03 27 05 01 eO fd cO aS 03 fe 45 00 00 3c ea 9a 4 0030 00 00 80 01 c8 bl cO a8 03 27 cO a8 02 fd 08 00 |пплп пт ц„ n? nn nn
.8.
.8.
v
v
р
р
Е
Е
Е.
Е.
7
-д
7
-д
I
I
Рис. 4.25. Пример сообщения ICMP redirect (код 1)
Хост, с которого выполнялась команда ping, получает это сообщение и добавляет новую запись в свою таблицу маршрутизации, указывающую на то, что теперь до получателя 192.168.2.253 есть свой особый маршрут.
C:\>route print
Сетевой адрес0.0.0.0127.0.0.0192.168.2.253192.168.3.0192.168.3.39192.168.3.255192.168.5.253224.0.0.0255.255.255.255Основной шлюз:Сетевой адрес0.0.0.0127.0.0.0192.168.2.253192.168.3.0192.168.3.39192.168.3.255192.168.5.253224.0.0.0255.255.255.255Основной шлюз:Маска сети 0.0.0.0255.0.0.0255.255.255.255255.255.255.0255.255.255.255255.255.255.255255.255.255.255224.0.0.0255.255.255.255192.168.3.254Маска сети 0.0.0.0255.0.0.0255.255.255.255255.255.255.0255.255.255.255255.255.255.255255.255.255.255224.0.0.0255.255.255.255192.168.3.254Адрес шлюза Интерфейс Метрика192.168.3.254192.168.3.391127.0.0.1127.0.0.11192.168.3.252192.168.3.391192.168.3.39192.168.3.391127.0.0.1127.0.0.11192.168.3.39192.168.3.391192.168.3.252192.168.3.391192.168.3.39192.168.3.391192.168.3.39192.168.3.391Адрес шлюза Интерфейс Метрика192.168.3.254192.168.3.391127.0.0.1127.0.0.11192.168.3.252192.168.3.391192.168.3.39192.168.3.391127.0.0.1127.0.0.11192.168.3.39192.168.3.391192.168.3.252192.168.3.391192.168.3.39192.168.3.391192.168.3.39192.168.3.391
Сетевой адрес
0.0.0.0
127.0.0.0
192.168.2.253
192.168.3.0
192.168.3.39
192.168.3.255
192.168.5.253
224.0.0.0
255.255.255.255
Основной шлюз:
Сетевой адрес
0.0.0.0
127.0.0.0
192.168.2.253
192.168.3.0
192.168.3.39
192.168.3.255
192.168.5.253
224.0.0.0
255.255.255.255
Основной шлюз:
Маска сети 0.0.0.0
255.0.0.0
255.255.255.255
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
255.255.255.255
192.168.3.254
Маска сети 0.0.0.0
255.0.0.0
255.255.255.255
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
255.255.255.255
192.168.3.254
Адрес шлюза Интерфейс Метрика
192.168.3.254192.168.3.391
127.0.0.1127.0.0.11
192.168.3.252192.168.3.391
192.168.3.39192.168.3.391
127.0.0.1127.0.0.11
192.168.3.39192.168.3.391
192.168.3.252192.168.3.391
192.168.3.39192.168.3.391
192.168.3.39192.168.3.391
Адрес шлюза Интерфейс Метрика
192.168.3.254192.168.3.391
127.0.0.1127.0.0.11
192.168.3.252192.168.3.391
192.168.3.39192.168.3.391
127.0.0.1127.0.0.11
192.168.3.39192.168.3.391
192.168.3.252192.168.3.391
192.168.3.39192.168.3.391
192.168.3.39192.168.3.391
Обратите внимание, что в данном случае используется сообщение ICMw redirect for host (перенаправление для хоста) и новая таблица маршрутизж ции содержит запись для хоста с адресом 192.168.2.253. Если теперь с того хоста послать запрос ICMP echo по другому адресу — 192.168.3.254, то onJ санная процедура повторится вновь. Причем абсолютно неважно, активен ли получатель запроса или нет — сообщение ICMP redirect будет отправляться в любом случае.J
Администратор, настраивая маршрутизатор Cisco Systems, может воспользар ваться командой ip redirects, которая разрешает маршрутизатору отправлять сф общения ICMP redirect тогда, когда маршрутизатор вынужден переслать входящий пакет через интерфейс, на который он поступил. По умолчанию отправка сообщений ICMP redirect разрешена.
Информационные запросы протокола ICMP
Рассмотренные выше сообщения ICMP echo request не единственный доступ:
ный тип запроса. Так называемые nou-echo-запросы ICMP довольно широко ир пользуются при реализации механизмов сканирования. Помимо наиболее «пр
пулярных» echo request и echo reply (обычная команда ping), уже обсуждений; нами, можно привести следующие типы запросов: timestamp request и reply (запрр< времени), information request и reply (запрос информации), address mask reques и reply (запрос маски), router solicitation и router advertisement (анонсирован^
маршрутизатора). Остановимся на каждом из них подробнее.. i>
Сообщение ICMP timestamp request (поле Type: 13 в запросе, Туре: 14 в ответ
на запрос, рис. 4.26) позволяет опросить хост в сети на предмет определен!
текущего времени, что также помогает отправителю определить степень
держки, вносимой сетью. При формировании запроса отправитель устанавливав временную отметку (originate timestamp) и отправляет запрос. Получатель сраЗ же при получении запроса заполняет временную отметку о получении (receiv timestamp) и передачи (transmit timestamp), изменяет тип сообщения с 13 на t и посылает его в обратный путь. Временная отметка представляет собой числ
миллисекунд, отсчитываемых с полуночи по Гринвичу. Отметка о завершен^ инициализации сообщения (originate timestamp) определяет время, соотве! ствующее моменту последнего изменения сообщения отправителем перед ег
посылкой. Отметка о получении (receive timestamp) указывает на момент врем! ни, когда получатель начал работать с сообщением, а отметка передачи (transm timestamp), соответственно, определяет последний момент перед отправкой в сет
хотя сточкхотя сточкполучателем. Говоря о применении этого сообщения с некорректными цел:
хотя сточк
хотя сточк
можно обнаружитьможно обнаружитьв сети устройства,в сети устройства,которые отвечают на запрос,
можно обнаружить
можно обнаружить
в сети устройства,
в сети устройства,
зрения нанесения явного вреда работающему хосту подобная информация вр ли будет полезной. В основном данный механизм может использоваться Д временной синхронизации на взаимодействующих хостах и измерения задер
ки передачи информации в одном направлении.
-Type: 13 (Timestamp request)-Code: 0-Checksum: OxfOff (correct)-Identifier: 0x0100-Sequence number: 01:00-Originate timestamp: 0-Receive timestamp: 0-Transmit timestamp: 0-Type: 13 (Timestamp request)-Code: 0-Checksum: OxfOff (correct)-Identifier: 0x0100-Sequence number: 01:00-Originate timestamp: 0-Receive timestamp: 0-Transmit timestamp: 0on wire. 54 captured)on wire. 54 captured)hternet Protocol, Src Addr: 192.168.3.174 (192.168.3.174), Dst Addr: 192.168.3.254 (192.168.3.254)hternet Protocol, Src Addr: 192.168.3.174 (192.168.3.174), Dst Addr: 192.168.3.254 (192.168.3.254)И 00 00 00 00 00 00 oolИ 00 00 00 00 00 00 ool[on 00 00 00 00 00|[on 00 00 00 00 00|0020003000200030
-Type: 13 (Timestamp request)
-Code: 0
-Checksum: OxfOff (correct)
-Identifier: 0x0100
-Sequence number: 01:00
-Originate timestamp: 0
-Receive timestamp: 0
-Transmit timestamp: 0
-Type: 13 (Timestamp request)
-Code: 0
-Checksum: OxfOff (correct)
-Identifier: 0x0100
-Sequence number: 01:00
-Originate timestamp: 0
-Receive timestamp: 0
-Transmit timestamp: 0
on wire. 54 captured)
on wire. 54 captured)
hternet Protocol, Src Addr: 192.168.3.174 (192.168.3.174), Dst Addr: 192.168.3.254 (192.168.3.254)
hternet Protocol, Src Addr: 192.168.3.174 (192.168.3.174), Dst Addr: 192.168.3.254 (192.168.3.254)
И 00 00 00 00 00 00 ool
И 00 00 00 00 00 00 ool
[on 00 00 00 00 00|
[on 00 00 00 00 00|
0020
0030
0020
0030
Рис. 4.26. Пример сообщения ICMP timestamp request
Для генерирования запроса, показанного на рис. 4.26, использовалась система NAI CyberCop Scanner, которая после получения приведенного на рис. 4.27 ответа сделала вывод, что хост 192.168.3.254 уязвим, так как отвечает на эти запросы и может предоставить информацию о своем системном времени. Следует отметить, что большинство операционных систем устанавливают receive timestamp и transmit timestamp в одинаковые значения.
6615 4.812312 142 1Ь8 1251 Р12.1Ы1 3 1 /I1ГМР Тнгн-ltwilp reply15 4.812312 142 1Ь8 1251 Р12.1Ы1 3 1 /I1ГМР Тнгн-ltwilp replycmlOl ;X.l:cmlOl ;X.l:Frame 15 (60 on wire, 60 captured)Ethernet IIInternet Protocol, Src Addr: 192.168.3.254 (192.168.3.254), Dst Addr: 192.168.3.174 (192.168.3.174)Frame 15 (60 on wire, 60 captured)Ethernet IIInternet Protocol, Src Addr: 192.168.3.254 (192.168.3.254), Dst Addr: 192.168.3.174 (192.168.3.174)orJTTtprnet Control Message ProtocolorJTTtprnet Control Message Protocol-Type: 14 (Timestamp reply)-Code: 0-Checksum: 0xd574 (correct)-Identifier: 0x0100-Sequence number: 01:00-Originate timestamp: 0-Receive timestamp: 3275934210LTransmit timestamp: 3275934210-Type: 14 (Timestamp reply)-Code: 0-Checksum: 0xd574 (correct)-Identifier: 0x0100-Sequence number: 01:00-Originate timestamp: 0-Receive timestamp: 3275934210LTransmit timestamp: 3275934210яя0020 03 aeоозо seia0020 03 aeоозо seiaT 00 01 00 00 00 00 00 70T 00 01 00 00 00 00 00 7000 00 00 00 00 0000 00 00 00 00 0033
6
6
15 4.812312 142 1Ь8 1251 Р12.1Ы1 3 1 /I1ГМР Тнгн-ltwilp reply
15 4.812312 142 1Ь8 1251 Р12.1Ы1 3 1 /I1ГМР Тнгн-ltwilp reply
cmlOl ;X.l:
cmlOl ;X.l:
Frame 15 (60 on wire, 60 captured)
Ethernet II
Internet Protocol, Src Addr: 192.168.3.254 (192.168.3.254), Dst Addr: 192.168.3.174 (192.168.3.174)
Frame 15 (60 on wire, 60 captured)
Ethernet II
Internet Protocol, Src Addr: 192.168.3.254 (192.168.3.254), Dst Addr: 192.168.3.174 (192.168.3.174)
orJTTtprnet Control Message Protocol
orJTTtprnet Control Message Protocol
-Type: 14 (Timestamp reply)
-Code: 0
-Checksum: 0xd574 (correct)
-Identifier: 0x0100
-Sequence number: 01:00
-Originate timestamp: 0
-Receive timestamp: 3275934210
LTransmit timestamp: 3275934210
-Type: 14 (Timestamp reply)
-Code: 0
-Checksum: 0xd574 (correct)
-Identifier: 0x0100
-Sequence number: 01:00
-Originate timestamp: 0
-Receive timestamp: 3275934210
LTransmit timestamp: 3275934210
я
я
0020 03 ae
оозо seia
0020 03 ae
оозо seia
T 00 01 00 00 00 00 00 70
T 00 01 00 00 00 00 00 70
00 00 00 00 00 00
00 00 00 00 00 00
3
3
Рис. 4.27. Пример сообщения ICMP timestamp reply
В документе RFC 1122 оговорено, что хост может реализовать поддержку запроса ICMP timestamp request и ответа на него. Если поддержка реализована, то выдвигается ряд требований (которые уже должны соблюдаться). Интересна возможность игнорирования запросов с широковещательным и групповым адресом получения (все операционные системы Microsoft Windows не отвечают на ь запросы с широковещательным адресом, в то время как операционная система L inux 2.2.x отвечать будет). Далее, компьютер, работающий под управлением Microsoft Windows NT + Service Pack 6 не станет откликаться па запрос timestamp request (это позволяется документом RFC 1122), в то время как Windows 2000-
Server/Professional будет отвечать, что, собственно, подтверждается вышепи денным перехватом, так как хост 192.168.3.254 работает под управлением \ dows 2000 Server. Обратите внимание, что речь идет о нешироковещатель запросах. Так, ничто нс мешает атакующему выполнить ping sweep с исподы нием поп-ссЬо-запросов (например, timestamp request) и указанием Широкове тельного адреса в качестве адреса получателя. Впрочем ни одна операциок система семейства Windows отвечать на запрос не будет. Размер рассматрив мого сообщения укладывается между 40 и 60 байтами, из которых 20-40 бай" относятся к заголовку дейтаграммы IP, 4 байта занимает заголовок сообще; ICMP и 16 байтов отводятся полю самого сообщения.
Следующий запрос ICMP information request (запрос информации) и ой на него направлены на поддержку систем, требующих выполнения процед1 самоконфигурирования. Это могут быть, например, бездисковые станции, пользующие запрос для определения своих сетевых адресов. При формирова запроса поле получателя в заголовке дейтаграммы IP устанавливается в н (означая «эта сеть»), кроме того, адрес отправителя также может иметь нуле значение. Затем отправитель устанавливает поля идентификатора и номера слсдовательности для сопоставления запросов с поступающими ответами, а п Code сбрасывается в ноль. Содержимое ответа зависит от запроса — если ад^ получателя и отправителя нулевые, то в ответной дейтаграмме эти поля бу) заполнены сетевым адресом. Следует отметить, что в сетях Microsoft Netwo существует более удобный метод назначения адресов. Этот метод исполЫ протокол DHCP (Dynamic Host Configuration Protocol, протокол динами ской настройки хоста). В настоящее время данный тип сообщения ICMP уста и в документе RFC 1812 сказано, что маршрутизатору и хосту не следует гене ровать ответ на сообщение information request. Тем не менее, несмотря на рё мендацию RFC 1812, хосты в сети могут отвечать на такие запросы. А адми: страторам рекомендовано блокировать прохождение запросов и ответов на В через защитный экран, также как и сообщений ICMP timestamp. Кроме то если в сети обнаружены подобные пакеты, следует обратить внимание на их 1 точник — с него может выполняться сканирование сети с целью определен типов операционных систем, работающих на хостах. Например, злоумышлен® способен установить адрес получателя в некое определенное значение, а не в HQj В таком случае некоторые компьютеры (операционные системы) будут отвеч? на запрос предоставления информации ICMP даже если он поступил не из т же сети, где они находятся. Причем несмотря на то, что отправка запроса с ней левым адресом получателя является нарушением требований RFC, формир вание ответа таковым не является, так как в документе не содержатся точ инструкции, как поступать в подобной ситуации. Рассматриваемый запрос мс быть также послан на широковещательный адрес — на него операционные си мы Microsoft Windows отвечать не будут.
Аналогично работает запрос address mask request, который тоже использу бездисковыми станциями для получения адресной информации, точнее, для У вания маски подсети (после того как хосту присвоен конкретный 1Р-адрес).' информация может помочь злоумышленнику заполучить в свое распоряжб
лапример, схему маршрутизации. Размер сообщений address mask request/repl у находится в пределах между 32 и 52 байтами (8 байтов отводятся под иоле данных).
Если следовать документу RFC 1812, то маршрутизатор должен поддерживать сообщение address mask, что помогает идентифицировать маршрутизаторы в пути к целевой сети. Однако RFC 1122 указывает, что использование хостами этого типа сообщения (запрос и ответ) является исключительно добровольным. Таким образом, если маршрутизатор поддерживает рассматриваемое сообщение, то рекомендуется предусмотреть параметры конфигурации, которые определяют для каждого логического интерфейса, должен ли он отвечать па поступающие запросы ICMP address mask request. По умолчанию маршрутизатор не должен их игнорировать, но если он не владеет информацией о корректной адресной маске, то отвечать вовсе не обязан.
Учитывая тот факт, что хост не обязательно получит адресную маску в том случае, если другой маршрутизатор выключен (или нс отвечает на запросы), маршрутизатор-отправитель может периодически посылать широковещательные сообщения ICMP address mask reply на каждый из своих логических интерфейсов, после того как на них были настроены маски адресов. Указанная схема работы имеет все шансы оказаться опасной в случае использования маски подсети переменной длины (VLSM — Variable Length Subnet Mask, глава 2). В результате если маршрутизатор рассылает информацию периодически, то он исключает из этого процесса логические интерфейсы, которые либо настроены на запрет отправки ответов, либо разделяют между собой один физический интерфейс и общие сетевые префиксы.
Xocts, которые при своей загрузке пытаются определить адресную маску с помощью данного типа сообщения ICMP, отправляют его по широковещательному адресу (причем в случае неполучения ответа повторяют это несколько раз). До тех пор пока на посылаемые запросы не поступил ответ, хосту предписано считать, что маска соответствует классу его IP-адресу, или иными словами, что сеть не поделена на подсети. Информация из первого поступившего ответа и будет использоваться для установки маски адреса, а остальные сообщения будут игнорироваться. Отмечу, что факт генерации ответа на запрос address mask request зависит о того, является ли хост авторизованным агентом (authoritative agent), которому позволительно формировать ответы. Агентом может быть как хост (компьютер, работающий под какой-либо операционной системой), так и маршрутизатор — но в любом случае, он при своей инициализации должен широковещательно рассылать сообщения address mask reply.
На защитном экране рекомендуется настроить список блокировки доступа Для сообщений address mask request, поступающих из сети Интернет. Дело в том, что если на запрос поступает ответ, то можно получить информацию нс только О том, что хост активен и доступен, но также и адресную маску той сети, где он Располагается. Так, операционные системы Microsoft Windows 95/98 будут отвечать на запрос address mask (видимо, считая себя авторизованными агентами), в то время как Microsoft Windows 2000 не будет (причем все они обойдут вниманием запрос, посланный широковещательно). Например, посмотрите на перехваченную дейтаграмму (рис. 4.28), которая поступила из Интернета на внешний адрес защитного экрана (193.125.203.1).
^2854 27738.360491 142.1 73.11 S.42 193 12 5.203-1 ICMP Adib:»» ««ад* «
И Frame 2854 (60 on wire, 60 captured)
И Ethernet II
И Internet Protocol, Src Addr: 142-173.115-42 (142.173.115.42). Dst Addr: 193.125.203.1 (193.125.203.1)
В Internet Control Message Protocol
Type: |7 (Address mask request)
Code: 0
Checksum: 0xca7d (correct)
Identifier: 0x0001
Sequence number: 7d:bd
Address mask: 254.2.168.192 (0xfe02a8c0)
RR■vy■vy
R
R
■vy
■vy
^10000 00 90 27 Of 11 6c 00 06 d7 ее 38 22 08 00 45 00 .'Vf.. ,.8"..E. : 0010 00 20 48 ef 00 00 67 01 7c 97 8e ad 73 2a cl 7d . H...g. ...s*.) Ипп9п -Ln: 1i.nn-.-. ча nn ni,. ?d. м. г- .П9.-9 -n nn nn i I .
Рис. 4.28. Пример сообщения ICMP address mask request
Дейтаграмма содержит запрос address mask request для адреса 254.2.168.16 Эта дейтаграмма была перехвачена системой обнаружения атак snort, анализ рующей трафик на внешнем интерфейсе защитного экрана. Обосновать принта отправки запроса сложно, но можно предположить, что запрос был сгенерир ван случайно. При работе с маршрутизаторами Cisco Systems у администратр; есть в распоряжении команда ip mask-reply, выполнение которой разрешит мар! рутизатору отвечать на запросы ICMP mask request. По умолчанию такая вр можность отключена. '
Сообщение ICMP parameter problem
Остановимся на особенностях работы протокола в случае, когда в сети происходи события, вызванные, скорее всего, вмешательством посторонни^. Расширенны методы обнаружения хостов в сети (сканирования) опираются на идею, котораз сводится к тому, что атакующий может заставить хосты разными способами од правлять сообщения об ошибках протокола ICMP. Например, одним из методы является посылка дейтаграммы с некорректными полями в заголовке. В это» случае получатель, обнаружив проблемы с заголовком, пошлет отправителю дей в таграммы сообщение ICMP parameter problem.
Сообщение parameter problem посылается, если маршрутизатор, который обф зан его сформировать, или конечный хост, который способен его сформировать обрабатывая полученную дейтаграмму, испытывает сложности в интерпрета; ции полей ее заголовка. Тогда дейтаграмма отбрасывается (игнорируется), а « отправителю посылается указанное сообщение, с полем Code, равным 0 или Я В первом варианте в заголовке ICMP будет точно указано на байт в заголовй< IP-дейтаграммы, который вызвал ошибку. Второй код используется, если в Шт, лученной дейтаграмме поля «Длина заголовка» или «Общая длина» некорректны* Следует сказать, что указанный метод сканирования активных хостов из се Интернет является довольно мощным, так как хосты могут отвечать сообщен» parameter problem, а маршрутизаторы должны на них откликаться. Тем не и нес, не все маршрутизаторы проверяют правильность всех полей дейтагра
р как это делают конечные устройства. В общем случае, согласно документу yFC 1812, маршрутизатор проверяет только поле контрольной суммы и отбра- пентаграмму, если последняя некорректна. Интересна следующая осо- сывае 1v
бенность: если маршрутизатор удалил дейтаграмму и послал в ответ сообщение rameter problem, то анализируя его «внутренности» можно определить производителя этого маршрутизатора. Администратору сети следует внимательно относиться к сообщениям системы IDS, которая должна среагировать на наличие в сети дейтаграмм с некорректными полями в заголовке.
Также немаловажна возможность сканирования активных хостов с определе- ■ нием доступных портов из сети Интернет. Данная возможность достигается формированием дейтаграммы с некорректными полями в заголовке с последующей инкапсуляцией в нее сегмента TCP или дейтаграммы UDP с установкой желаемых номеров портов. Если ответ на такую дейтаграмму получен, то это может означать, что используемый протокол и указанный порт доступны на получателе, и что сообщение parameter problem может проходить из внутренней сети через защитный экран в сеть Интернет. Кроме того, это может означать, что защитный экран не проверяет поля дейтаграммы на корректность.
Помимо указания неверной длины заголовка, несуществующее значение в поле «Тип протокола» также приводит к ошибке. В итоге получатель, зафиксировав этот факт, пошлет в ответ сообщение ICMP destination unreachable или protocol unreachable. Соответственно, если дейтаграмма поступила из Интернета, то от' сутствие ожидаемого сообщения ICMP может указывать на то, что, например, защитный экран, проверив заголовок, не пропустил дейтаграмму дальше. Администратору сети рекомендуется настроить защитный экран на блокирование сообщений ICMP protocol unreachable, идущих из защищаемой сети в Интернет.
-Сообщение ICMP time exceeded
i Сообщение ICMP time exceeded формируется маршрутизатором, если последний I обнаружил, что поле TTL в заголовке оригинальной дейтаграммы IP, которую । он обрабатывает, равно нулю. В документе RFC 791 замечено, что маршрутиза- г тор должен уменьшать значение этого поля на время, затраченное на обработку, ’ в секундах. Максимальное значения поля TTL равно 255 (то есть 255 секунд), I что соответствует 4,5 минутам. Когда значение поле TTL достигает нуля, дейта- ^грамма отбрасывается маршрутизатором и генерируется вышеуказанное сообше- )ние ICMP с кодом 0 (Time-to-Live Exceeded in Transit). Рисунок 4.29 показыва-
гет пример сообщения, поступившего в ответ на отправку пакета DNS (протокол
। UDP, порт 53). Как видно из рисунка, подобно другим сообщениям об ошибках, | Рассматриваемое также включает в себя заголовок исходной дейтаграммы.
| 1аРа слов о выбранной единице измерения времени (секунды). В настоящее Ь вРе.мя маршрутизаторы обрабатывают дейтаграмму за гораздо меньший проме- 6 ’Куток времени (кроме ситуации, когда маршрутизатор перегружен — в таком ■ случае обработка может занять несколько секунд). Учитывая это, транзитные Маршрутизаторы обычно уменьшают значения поля TTL на 1.
& Frame 226 (70 on wire, 70 captured)fl
П 0-Ethernet II
x ^Internet Protocol, Src Addr: 195.5.53-12 (195-5.53.12), Det Addr: 193.125.203. 1 (193. 125.203. 1) fl Q-Internet Control Message Protocol
: -Type! 11 (Time-to-live exceeded)fl
c -Code! 0 (TIL equals 0 during transit)fl
-Checksum! OxdeSb (correct)
?[} Internet Protocol, Src Addr! 193-125-203.1 (193. 125.203. 1), Dst Addr: 195.5. 13.225 (195.5. 13.225)1
■ 0-User Datagram Protocol, Src Port: 62982 (62982), Dst Port: domain (53)fl
щ^^^^и, J
110000 00 90 '27 Of ii'6e'bo 06 d7 ее 38'22' 0^0015 .'/'LL. ,.8“..E.’ «ЯЯ
: 0010 00 38 b2 db 00 00 f3 01 8f 98 c3 05 35 0c cl 7d .85..}
Рис. 4.29. Пример сообщения ICMP TTL exceeded (на переходе)•*$
Наличие подобного сообщения протокола ICMP, как правило, указывает^ возникновение петель маршрутизации, когда дейтаграмма плутает где-то в с@| Интернет до тех пор, пока не будет удалена. Маршрутизатор может быть насдй он на запрет отправки сообщений ICMP такого рода, но по умолчанию сообщегД TTL exceeded должны отправляться. В то же время производитель маршрут^ тора может предусмотреть возможность отключить отправку подобных сообщ ний для каждого интерфейса.j
Обычное сообщение ICMP TTL exceeded имеет в поле Code значение 0, j если этот код равен 1, это свидетельство того, что время, отведенное на сбоца фрагментированных дейтаграмм, истекло (на английском языке — Fragm^ Reassembly Time Exceeded). Детали фрагментирования будут рассмотрены немно^ ниже, а пока отмечу, что каждый фрагмент отправляется в своей дейтаграмм и маршрутизируется независимо от других фрагментов. Далее, все фрагмент имеют одинаковые значения в поле Identification (идентификация) в заголовку и уникальные значения в поле Offset (смещение), которое позволяет воссозда исходную дейтаграмму на устройстве-получателе. Получатель, принимая й фрагменты (их может быть несколько в зависимости от размера исходной де таграммы и значения MTU в сети), должен собрать их в единое целое, а зат1 передать протоколу более верхнего уровня (TCP, UDP). В том случае, если дв таграмму не удается собрать по причине пропущенных фрагментов, они отбр сываются и генерируется сообщение ICMP TTL exceeded с кодом 1. Такое пой дение способствует сканированию извне, когда хосту специально отправляют! дейтаграммы с пропусками фрагментов."
В операционных системах семейства Windows (и не только в них, естествё но) широко применяется утилита tracert. Она отправляет набор из трех дейт грамм IP по указанному адресу, по при этом устанавливает поле TTL в заголи ках этих дейтаграмм в ноль. В дейтаграммах находятся сообщения ICMP eel request. Маршрутизатор перед обработкой дейтаграммы проверяет это поле если оно нулевое, отбрасывает дейтаграмму и посылает рассматриваемое соо щение его отправителю — в данном случае программе tracert. Затем программ tracert посылает другой набор дейтаграмм, по с увеличенным на единицу поЛ1 TTL, и все повторяется заново. При этом на экран выводится информация о пр межуточных узлах в пути до получателя. Подобные итерации будут продолжат®
тех пор, пока не будет получен ответ на дейтаграммы (не придет ответ ICMP ^о Гер1у или сообщение ICMP destination unreachable). Внутри дейтаграмм вместо сообщений ICMP можно использовать протокол UDP с портом получателя выбранным из числа свободных. При этом появляется возможность проведения анализа правил фильтрации на защитном экране. С помощью tracert (точнее, ее аналога, который умеет посылать UDP-паксты) генерируются пакеты UDP с интересующими номерами портов получателя. Если порт блокирован защитным экраном, то трассировка остановится на нем, иначе (считая, что защитный экран пропустит в Интернет сообщение ICMP TTL exceeded) защитный ' экран на мониторе компьютера появится как еще один переход (иными словами как маршрутизатор). Инструмент, способный! выполнять трассировку с помощью пакетов UDP, можно найти на сайте http://www.packetfactory.net — авторы Майк Шифман и Дэвид Голдсмит (программа Firewalk).
фрагментация дейтаграмм IP
Фрагментирование происходит в тот момент, когда дейтаграмме протокола IP, проходящей по сети, необходимо пересечь сегмент этой сети, в котором значение MTU меньше размера самой дейтаграммы. Например, значение MTU для дейтаграммы в сети Ethernet составляет 1500 байт, и если размер дейтаграммы больше этого значения, потребуется ее фрагментация. Это сделает маршрутизатор, подключенный к сети, в которую нужно доставить дейтаграмму. Кроме маршрутизатора фрагментацию может также выполнить хост, если ему нужно передать дейтаграмму с размером, превышающим MTU. Каждый фрагмент исходной дейтаграммы проходит по сети до получателя, который затем собирает полученные фрагменты вместе, формируя исходную дейтаграмму. Интересно отметить, что сами фрагменты могут еще раз пройти процедуру фрагментации, если на своем пути миновали сегмент сети с еще меньшим MTU, чем их размер. В целом, фрагментация — нормальное явление, однако, как и в случае протокола ICMP, нормальная функциональность может быть востребована для ненормальной деятельности. Например, можно разбивать дейтаграммы на части так, чтобы фрагменты прошли через фильтрующий маршрутизатор, который не поддерживает работу с фрагментами.
Каждый полученный фрагмент должен ассоциироваться с другим фрагмен- I том при помощи общего идентификатора (так называемого common fragment identification number). Для этих целей служит специальное поле в заголовке протокола IP — IP identification number. Далее, каждый фрагмент должен содержать в себе свою позицию (смещение) в оригинальной, нефрагмеитированной Дейтаграмме и дополнительно указывать длину переносимых им данных. И, наконец, каждый фрагмент должен знать, следуют ли за ним еще фрагменты. За это отвечает флаг More Fragments (MF) в заголовке IP. Таким образом, вся необходимая информация для последующей сборки содержится в заголовке дейтаграммы.■
' Наиболее наглядно можно показать механизм фрагментации с помощью пере, Дватов пакетов. Предположим, что используется сеть Ethernet, в которой значение
MTU составляет 1500 байт. Передаваемая в сети дейтаграмма инкапсулирует в кадр сети Ethernet, причем сначала идет заголовок, обычный размер ко! рого равен 20 байт, но может быть и больше в зависимости от настроек. Ес приложение оперирует протоколами верхних уровней, например TCP, то св мент TCP, в свою очередь, инкапсулируется в дейтаграмму после ее заголовка Простая арифметика показывает, что если длина заголовка дейтаграммы соста! ляет 20 байт, то остается еще 1480 байт для упаковки данных других прот^ колов. Для иллюстрации всех этанов фрагментирования предположим, администратор выполняет команду ping, получая следующие результаты:
C:\Program F1les>p1ng -1 4028 192.168.3.254
ОбменОбменОтветОтветОтветОтветпакетами с 192.168.3.254 по 4028 байт:
Обмен
Обмен
Ответ
Ответ
Ответ
Ответ
от 192.168.3.254: число байтов=4028 время=10мс TTL=128
от 192.168.3.254: число байтов=4028 время<10мс TTL=128
Параметр -I 4028 дает указание программе ping сформировать запрос 1СМЙ echo request с размером передаваемых данных, равным 4028 байт. Говоря о нота мальной сетевой активности, подобные запросы ICMP не должны встречаться ОД они чересчур большие. В сети Ethernet результирующая дейтаграмма будб®
поделена на фрагменты по 1500 байт или меньше. Каждый из этих фрагмей тов будет иметь 20-байтовый заголовок дейтаграммы IP, по-прежнему оставлйж
1480 байт для данных (рис. 4.30).
20 байт20 байт8 байт8 байт4000 байт4000 байтЗаголовок IPЗаголовок IPЗаголовокICMPecho requestЗаголовокICMPecho requestДанные в сообщении ICMPДанные в сообщении ICMP4028 байт
20 байт
20 байт
8 байт
8 байт
4000 байт
4000 байт
Заголовок IP
Заголовок IP
ЗаголовокICMPecho request
ЗаголовокICMPecho request
Данные в сообщении ICMP
Данные в сообщении ICMP
Фрагмент 2Фрагмент 2I Фрагмент 3I Фрагмент 3
Фрагмент 2
Фрагмент 2
I Фрагмент 3
I Фрагмент 3
Фрагмент 1(Ethernet MTU = 1500)
Рис. 4.30. Фрагментация дейтаграммы IP
Следует отметить, что в заголовке любой дейтаграммы IP есть поле с назвЙ нием Identification (идентификатор — главу 2), содержащее номер, уникально идентифицирующий каждую дейтаграмму, посылаемую хостом в сеть. Обьгп значение этого поля увеличивается на единицу с каждой следующей дейт граммом. В том случае, когда дейтаграмма делится, все ее фрагменты имет одинаковый номер, который можно так же назвать идентификатором фрагме та. Ниже приведен пример перехвата первого из трех фрагмента дейтаграмм (результат выполнения команды ping -I 4028). Все остальные фрагменты дейт граммы будут иметь тот же номер 0х5Ьс9.,
^7.795959 192-168 • 39 И»-' 168/054 И ЧР t < ho (ping) rrqui-it
59 (1514 bytes on wire, 1514 bytes captured)
II, Src: 00:d0:b7:ba:bf: 19, Dst: 00:d0=b7:a8:50:d2
llnternet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.254 (192.168.3.254)
т
i-Version: 4
-Header length: 20 bytes BType of service: 0x00 (None)
-Total Length: 1500
-Identification: 0x5bc9
SFIags: 0x02
-Fragment offset: 0
-Time to live: 128
-Protocol: ICMP (0x01)
-Header checksum: 0x30e2 (correct)
-Source: 192.168.3.39 (192.168.3.39) ^-Destination: 192.168.3.254 (192.168.3.254)
В Internet Control Message Protocol
000000dOb7a850d200dOb7babf1908004500
001005de5bc92000800130e2cOa80327cOa8
—’03fe08009c1602006700616263646566
70717273717573
0000
Р
Е.
0020 0030 ПОДО
67 68 69
77. R1 R9
6а Rt
6Ь
R4
6с RR
6d RR
бе
R7
Of
RS
RQ
71 72 73 74 75 76
Ra Rb R^ ..RH Rp .Rf
..[. ... 0....’..
g.abcdef ghijklmn opqrstuv „|иаЪлг1е^» bi iVImnq
3
/
Рис. 4.31. Первый фрагмент дейтаграммы IP
Только первый фрагмент дейтаграммы содержит в себе заголовок прото
кола ICMP. Как видно из результата перехвата (рис. 4.31), поле, указывающее на смещение фрагмента (Fragment offset), для первого фрагмента установлено в ноль, а поле данных, следующее за 8-байтовым заголовком ICMP, вмещает в себя 1472 байт (1500 - 20 - 8 = 1472). Флаг More fragments («еще фрагменты») установлен, указывая на то, что за этим фрагментом поступят последующие.
За первым фрагментом следует второй, который показан на рис. 4.32.
00 dO Ь7
05 de 5b
03 fe 61
6f 70 71
RS. RO Ro
9 6017.796005 192-168.3.39192.1603.254 g> Fragmented tt> protocol fprOtO'
I IFrame 60 (1514 bytes on wire, 1514 bytes captured) ^Ethernet II, Src1- 00:dO:b7:ba:bf: 19, Dst: 00=dO:b7:a8=50:d2 ^Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.3.254 (192.168.3.254)
-Version: 4
-Header length: 20 bytes
tHype of service: 0x00 (None)
-Total Length: 1500
Jr Identification: 0x5bc9
UFIags: 0x02
"Fragment offset: 1480
"lime to live: 128
-Protocol: ICMP (0x01)
"Header checksum: 0x3029 (correct)
-Source: 192.168.3.39 (192-168.3.39)
„Destination: 192.168.3.254 (192.168.3.254)
Data (1480 bytes)
5
aS c9 62
72
RK
50 d2
20 Ь9
63 64
73 74
00
80
65
75
dO 01 66 76
Ь7 30 67 77
ba 29 68
61
bf cO 69 62
19 a8 6a 63
08 03
6b
64
00
27
6c
65
45 cO 6d
66
00 aS
6e
67
Re. Rr) , Ro, R-F 7П 71 79 „7.Ч...7Д, .7R,7R77
....PE. ..[. ... 0)...'.. ..abedef ghijklmn opqrstuv wabedefg
1
Рис. 4.32. Второй фрагмент дейтаграммы IP
3
Как уже говорилось, заголовок ICMP будет присутствовать только в пепня фрагменте, тем самым для данных остается на 8 байт больше в последующ Идентификатор второго фрагмента совпадает со значением того же поля в пе вом фрагменте. Установлен бит More fragments, указывая получателю на то, ^ он должен ожидать дополнительные пакеты. Другое отличие последующих фр; ментов от первого заключено в поле Fragment offset. Если для первого фрагмент оно равно нулю, то для остальных оно содержит значение смещения внутри оп гинальной дейтаграммы. Так как при совмещении фрагментов заголовок втоп го фрагмента нам не нужен, поле смещения содержит значение 1480 (1500 1 вычетом 20 байт заголовка). Если в сети был перехвачен второй фрагмент d первого, то невозможно определить тип сообщения протокола ICMP, так ^ его заголовок утерян. Рассмотрим формат третьего, последнего фрагмента в шем примере (рис. 4.33).
j V 61 17.796017 192.168.3.3914Z.lb8.3J.-S4 IP trelented IP pru*orol(nrotn»U
EiFrame 61 (1110 bytes on wire, 1110 bytes captured)
Cl-Ethernet II, Src: 00!dO-b7• ba:bf: 19, Dst: 00:dO:b7:aS:50:d2
^Internet Protocol, Src Addr: 192.168.3.39 (192. 168.3.39), Det Addr: 192.168.3.254 (192.168.3.254)
-Version: 4
-Header length: 20 bytes
В Type of service! 0x00 (Hone)
- Total Length: 1096
-Identification: 0x5bc9
BFlags: 0x00
-Fragment offset: 2960
-Time to live: 128
-Protocol: 1СИР (0x01)
-Header checksum: 0x5104 (correct)
-Source: 192.168.3.39 (192.168.3.39)
I-Destination: 192. 168.3.254 (192.168.3.254)
-Data (1076 bytes)
REZZ)
Ю000001000200030Inrun
00
04
03
77
7П
dO 48 f e
61
b7 5b 69 62
aS c9
6a
63
50 01 6b
64
d2
72
6c
65
00
80
6d
66
dO 01 6e 67
b7 51 6f 68
ba 04
70
69
bf cO
71
6a
19 aS
72 6b
08 03
73 6c
00
27
74
6d
45 cO
75 6e
00 a8 76
6f
....p
•H[..r.. Q.
Е
79 79 7 Л 7П 7R 77 RI R9 R9 ПЛ ПП RR П7 П5
. .ijkliin opqrstuv wabcdefg hijklano nrfre+in/ш oh/vl of o-h
Рис. 4.33. Третий фрагмент дейтаграммы IP
Здесь также имеется заголовок протокола IP со все тем же значением в пот] Identification, однако флаг, указывающий на наличие дополнительных фрагменте! не установлен. Смещение в оригинальной дейтаграмме составляет 2960 ба что равно сумме двух первых фрагментов по 1480 байт. После получения вс трех фрагментов хост собирает их вместе в своей памяти, обнаруживает, что запрос ICMP echo request, и посылает в ответ собранную дейтаграмму, но то ко с новыми заголовками IP и ICMP. То есть в ответ на три фрагмента пост пят тоже три фрагмента с сохраненным содержимым поля данных сообщен» ICMP.:
Важно вновь отметить, что только первый фрагмент из всей цепочки сод жит информацию о передаваемом протоколе, например TCP или ICMP. То е если в сети используется фильтрующее устройство, например маршрутизат то только первый фрагмент будет блокироваться. Это при условии, что устр
&
'„ недостаточно «интеллектуально» для проверки полей в каждом фрагменте.
В идеальном же случае после получения первого фрагмента нужно ожидать по- следуюшие 11 не пропускать их в сеть. К сожалению, при интенсивном потоке тпасЬика выполнять подобную проверку становится очень сложно по причине большой занятости ресурсов. Если блокирующее устройство не отслеживает все жпагменты, то оно отбросит только первый с информацией о переносимом протоколе, а остальные пропустит в сеть. Ведь часто решение о том, пропускать или не пропускать дейтаграмму, принимается при анализе портов на стороне получателя заголовков протоколов TCP или UDP. Кроме того, так как протокол IP не гарантирует доставку, то в распределенной сети существует вероятность того, что первый фрагмент будет потерян. С учетом подобной возможности задача для блокирующего устройства усложняется.
Если необходимо, то фрагментацию дейтаграммы можно не выполнять, и для этого достаточно установить флаг Don’t fragment (DF) в заголовке протокола IP. Если, например, сформировать дейтаграмму, размер которой заведомо больше допустимого MTU в сегменте распределенной сети, то маршрутизатор отбросит подобную дейтаграмму, а в ответ пошлет сообщение ICMP destination unreachable. Это сообщение будет содержать в себе размер MTU сети, которая требует фрагментации. Интересно отметить, что некоторые хосты специально посылают в сеть дейтаграммы с установленным флагом DF с целью определения оптимального . размера пакетов в пути до определенного получателя. Это делается для того, чтобы избежать фрагментации, поскольку сам процесс разбиения на фрагменты и их последующая сборка дополнительно нагружают хосты. Более того, они вносят хоть и небольшие, но дополнительные издержки, так как 20-байтовый заголовок протокола IP посылается с каждым фрагментом. Давайте посчитаем — команда ping -I 4028 четыре раза послала по три фрагмента и четыре раза их приняла. Грубо говоря, накладных расходов было (4x3x20) + (4x3x20) = 480 байт. Из этих 480 байт только малая часть несет полезную информацию, а информация в остальных совпадает. Получается, что при пересылке 4028 байт 240 байт будут служебными, что составляет примерно 6 %. Кроме того, если по каким-либо причинам один фрагмент был потерян, все фрагменты должны посылаться вновь. Если говорить о воздействии па сеть, то атакующий может задействовать бит DF Для определения значения MTU на разных участках распределенной сети.
Как уже отмечалось, фрагментация может использоваться злоумышленником. С помощью очень популярной программы пшар (или nmapnt) нетрудно воплотить все вышеизложенные общие рассуждения в практические действия и вы- • полнить сканирование для определения номеров открытых портов на целевом хосте. Если воспользоваться параметром -f, то программа будет разбивать заголовок протокола TCP (20 байт) на несколько фрагментов с целью избежать Обнаружения сканирования системами IDS. Например, в результате команды nrnapnt -Sf -р 53 host хосту будут посланы на порт 53 фрагментированные запро- . сы SYN. С точки зрения сетевого уровня нельзя с уверенностью сказать, что i Происходит сканирование, из-за наличия большого количества маленьких фраг- । ^нтов. Заголовок дейтаграммы IP повторяется, но заголовок TCP (минималь- 1 над длина 20 байт) разбивается на кусочки. В первом фрагменте посылают- 1Ся 16 байт заголовка TCP, а во втором фрагменте — дополнительные 4 байт.
В зависимости от используемой системы, IDS может и не обнаружить подо! ный тип сканирования.'
В заключение рассмотрения протокола ICMP хочется задержаться на м, менте, связанном с блокированием исходящего и входящего трафика ICMP 1 защитном экране. Если говорить об исходящем трафике, то тут ситуация н сложная — можно блокировать все сообщения ICMP за исключением ICM echo request — именно этот тип используется сетевыми администраторами кг наиболее удобный для проверки работоспособности доступа в сеть Интерне То есть на защитном экране можно разрешить прохождение запросов ICM echo — в зависимости от типа защитного экрана, ответы ICMP reply будут прох< дить автоматически, в рамках одного сеанса. Сказанное относится также и кт пулярной утилите tracert, которая при своем запуске в операционной системе Windows начнет посылать дейтаграммы IP с вложенными сообщениями ICMP echo request, которые также не будут задержаны защитным экраном. Однако если для трассировки используются вложенные сообщения, не относящиеся к ICMP, то нужно скорректировать правила фильтрации. Фильтрация всей типов сообщений ICMP, за исключением echo request, не позволит вашим сера верам реагировать на нештатные или ошибочные ситуации, если трафик прихй* дит из сети Интернет. Другая проблема имеет место тогда, когда внутренний хост (сервер), взаимодействуя с каким-то устройством в сети Интернет, получа^ ет сообщение ICMP, на которое он может прореагировать (например, перестать ■посылать данные в ответ на сообщение ICMP host unreachable). Это сообщен^ будет отфильтровано защитным экраном. Вы не должны рассчитывать, что зй щитный экран будет достаточно «умным», чтобы проанализировать оригинал^ ные заголовки в сообщении ICMP и понять, какие из них «свои», и пропустит^- дейтаграмму во внутреннюю сеть.
5
Настройка протокола TCP
В этой главе дано подробное описание алгоритмов, лежащих в основе протокола TCP, выделены наиболее критичные параметры и определена степень их влияния на производительность TCP. Кроме того, рассмотрена сетевая атака TCP SYN flooding, использующая особенности работы протокола TCP. Освещены методы противодействия этой атаке. В качестве иллюстрации методов настройки протокола приведены примеры настройки для операционных систем Microsoft Windows NT и 2000, причем возможности последней рассматриваются отдельно, так как наиболее широкий список дополнений и расширений протокола TCP компанией Microsoft представлен именно в операционной системе Windows 2000. Эти знания должны помочь администратору оптимально настроить протокол в своей сети с учетом риска потенциальных атак. И конечно, знание процессов, происходящих при транспортировке данных в сетевой среде, является необходимым условием понимания работы в сети в целом.
Введение в протокол TCP
Очень кратко напомним основы протокола TCP (Transmission Control Protocol — протокол управления передачей данных). Описание протокола TCP приводится в документе RFC 793 (в дальнейшем предлагались различные усовершенствования, отраженные во множестве других RFC). Протокол TCP — это основной транспортный протокол в стеке TCP/IP. Он обеспечивает надежную передачу потока данных на базе ненадежного сервиса транспортировки дейтаграмм, предоставляемого протоколом IP. На протокол TCP, в частности, возложена задача управления потоками и перегрузками; этот протокол отвечает за согласованность скорости передачи данных с техническими возможностями получателя и промежуточных устройств на пути прохождения пакетов.
Поступающие данные буферизуются средствами протокола TCP. Для передачи на сетевой уровень из буфера берется определенная непрерывная часть данных, которая называется сегментом. Сегмент является единицей данных протокола TCP. Определение размеров сегментов TCP осуществляет протокол IP. Не все - сегменты, посланные через установленное логическое соединение, будут одного и того же размера. Однако два абонента, осуществляющие связь при помощи
логического соединения, должны договориться о максимальном размере сегмен- vлогического соединения, должны договориться о максимальном размере сегмен- vта, который они будут использовать. Размер сегмента выбирается таким образом, чтобы при его упаковке в IP-дейтаграмму он поместился в нее целиком.Информацию на компьютере-получателе принимает модуль протокола TCP. Этот модуль, в свою очередь, помещает данные сегмента в буфер прикладной программы получателя и оповещает его о прибытии данных. С каждым модулем протокола TCP связан модуль протокола IP, который обеспечивает передачу по локальной сети. При этом происходит инкапсуляция сегмента протокола TCP. в IP-дейтаграмму. Эта дейтаграмма, в свою очередь, помещается в кадр, регламентированный сетевым окружением.та, который они будут использовать. Размер сегмента выбирается таким образом, чтобы при его упаковке в IP-дейтаграмму он поместился в нее целиком.Информацию на компьютере-получателе принимает модуль протокола TCP. Этот модуль, в свою очередь, помещает данные сегмента в буфер прикладной программы получателя и оповещает его о прибытии данных. С каждым модулем протокола TCP связан модуль протокола IP, который обеспечивает передачу по локальной сети. При этом происходит инкапсуляция сегмента протокола TCP. в IP-дейтаграмму. Эта дейтаграмма, в свою очередь, помещается в кадр, регламентированный сетевым окружением.jjНадежная передача данных по протоколу TCP осуществляется благодаря подтверждениям, высылаемым получателем после приема данных, и механизму нумерации. Для этого в заголовке сегмента протокола TCP с общим размером 20 байт выделяется специальное поле «Номер [в] последовательности»Надежная передача данных по протоколу TCP осуществляется благодаря подтверждениям, высылаемым получателем после приема данных, и механизму нумерации. Для этого в заголовке сегмента протокола TCP с общим размером 20 байт выделяется специальное поле «Номер [в] последовательности»з;з;‘г‘г(Sequence Number — SN). Это поле определяет номер первого байта текущего сегмента в общей очереди (или последовательности) байтов. Исключение состав- .» ляют случаи, когда выставлен бит (флаг) синхронизации SYN. Тогда в это поле »j помещается начальный номер последовательности (Initial Sequence Number — „.;j ISN), и первый байт данных получает номер ISN + 1.■ . jТак как все сегменты пронумерованы, то каждый из них может быть опо- '(Sequence Number — SN). Это поле определяет номер первого байта текущего сегмента в общей очереди (или последовательности) байтов. Исключение состав- .» ляют случаи, когда выставлен бит (флаг) синхронизации SYN. Тогда в это поле »j помещается начальный номер последовательности (Initial Sequence Number — „.;j ISN), и первый байт данных получает номер ISN + 1.■ . jТак как все сегменты пронумерованы, то каждый из них может быть опо- 'знан. Механизм распознавания носит накопительный характер, то есть получение и опознание байта с номером N означает, что все байты с предыдущими номера- .^знан. Механизм распознавания носит накопительный характер, то есть получение и опознание байта с номером N означает, что все байты с предыдущими номера- .^ми (N - 1, N - 2, ...) уже получены и опознаны. Этот механизм позволяет реги-ми (N - 1, N - 2, ...) уже получены и опознаны. Этот механизм позволяет реги-сгрировать появление дублирующих байтов при повторной передаче. Диапазон возможных номеров байтов лежит в пределах от 0 до 4 294 967 295 (232 - 1). Так как набор номеров ограничен, то все арифметические операции с номерами последовательностей должны осуществляться по модулю 232.Номера не должны исчерпать все значения до 232, прежде чем связанныесгрировать появление дублирующих байтов при повторной передаче. Диапазон возможных номеров байтов лежит в пределах от 0 до 4 294 967 295 (232 - 1). Так как набор номеров ограничен, то все арифметические операции с номерами последовательностей должны осуществляться по модулю 232.Номера не должны исчерпать все значения до 232, прежде чем связанные
логического соединения, должны договориться о максимальном размере сегмен- v
логического соединения, должны договориться о максимальном размере сегмен- v
та, который они будут использовать. Размер сегмента выбирается таким образом, чтобы при его упаковке в IP-дейтаграмму он поместился в нее целиком.
Информацию на компьютере-получателе принимает модуль протокола TCP. Этот модуль, в свою очередь, помещает данные сегмента в буфер прикладной программы получателя и оповещает его о прибытии данных. С каждым модулем протокола TCP связан модуль протокола IP, который обеспечивает передачу по локальной сети. При этом происходит инкапсуляция сегмента протокола TCP. в IP-дейтаграмму. Эта дейтаграмма, в свою очередь, помещается в кадр, регламентированный сетевым окружением.
та, который они будут использовать. Размер сегмента выбирается таким образом, чтобы при его упаковке в IP-дейтаграмму он поместился в нее целиком.
Информацию на компьютере-получателе принимает модуль протокола TCP. Этот модуль, в свою очередь, помещает данные сегмента в буфер прикладной программы получателя и оповещает его о прибытии данных. С каждым модулем протокола TCP связан модуль протокола IP, который обеспечивает передачу по локальной сети. При этом происходит инкапсуляция сегмента протокола TCP. в IP-дейтаграмму. Эта дейтаграмма, в свою очередь, помещается в кадр, регламентированный сетевым окружением.
j
j
Надежная передача данных по протоколу TCP осуществляется благодаря подтверждениям, высылаемым получателем после приема данных, и механизму нумерации. Для этого в заголовке сегмента протокола TCP с общим размером 20 байт выделяется специальное поле «Номер [в] последовательности»
Надежная передача данных по протоколу TCP осуществляется благодаря подтверждениям, высылаемым получателем после приема данных, и механизму нумерации. Для этого в заголовке сегмента протокола TCP с общим размером 20 байт выделяется специальное поле «Номер [в] последовательности»
з;
з;
‘г
‘г
(Sequence Number — SN). Это поле определяет номер первого байта текущего сегмента в общей очереди (или последовательности) байтов. Исключение состав- .» ляют случаи, когда выставлен бит (флаг) синхронизации SYN. Тогда в это поле »j помещается начальный номер последовательности (Initial Sequence Number — „.;j ISN), и первый байт данных получает номер ISN + 1.■ . j
Так как все сегменты пронумерованы, то каждый из них может быть опо- '
(Sequence Number — SN). Это поле определяет номер первого байта текущего сегмента в общей очереди (или последовательности) байтов. Исключение состав- .» ляют случаи, когда выставлен бит (флаг) синхронизации SYN. Тогда в это поле »j помещается начальный номер последовательности (Initial Sequence Number — „.;j ISN), и первый байт данных получает номер ISN + 1.■ . j
Так как все сегменты пронумерованы, то каждый из них может быть опо- '
знан. Механизм распознавания носит накопительный характер, то есть получение и опознание байта с номером N означает, что все байты с предыдущими номера- .^
знан. Механизм распознавания носит накопительный характер, то есть получение и опознание байта с номером N означает, что все байты с предыдущими номера- .^
ми (N - 1, N - 2, ...) уже получены и опознаны. Этот механизм позволяет реги-
ми (N - 1, N - 2, ...) уже получены и опознаны. Этот механизм позволяет реги-
сгрировать появление дублирующих байтов при повторной передаче. Диапазон возможных номеров байтов лежит в пределах от 0 до 4 294 967 295 (232 - 1). Так как набор номеров ограничен, то все арифметические операции с номерами последовательностей должны осуществляться по модулю 232.
Номера не должны исчерпать все значения до 232, прежде чем связанные
сгрировать появление дублирующих байтов при повторной передаче. Диапазон возможных номеров байтов лежит в пределах от 0 до 4 294 967 295 (232 - 1). Так как набор номеров ограничен, то все арифметические операции с номерами последовательностей должны осуществляться по модулю 232.
Номера не должны исчерпать все значения до 232, прежде чем связанные
с ними данные из отправляемого сегмента получат подтверждение от получате- j ля, а все дубликаты этого сегмента покинут сеть. Иначе двум сегментам могут1$ быть назначены одинаковые номера, что вызовет проблему с идентификацией ; этих сегментов у получателя. При скорости обмена информацией в 100 Мбит/с ; все возможные номера перебираются за 5,4 минуты.'
Кроме того, сегменты несут номера подтверждений, которые являются номера- ■■ ми для следующих ожидаемых байтов данных, передаваемых в обратном направ- : лении. Для этого в заголовке сегмента выделено поле «Номер подтверждения» i (Acknowledgment Number), содержащее номер в последовательности получаемых . подтверждений, который отправитель ожидает в ответ на посылаемый сегмент. Поступление подтверждения означает успешную доставку этого сегмента. При- ; знаком подтверждения служит установленный контрольный бит АСК. Подтвер- 1 ждения (или, как часто говорят, АСК) посылаются постоянно с момента уста- ’ новления соединения TCP и до его закрытия.-
Для определения назначения большинства полей заголовка TCP служат кон- • трольные биты (флаги): URG, АСК, PSH, RST, SYN и FIN. Соединения протоко- i ла TCP переходят из одного состояния в другое в ответ на определенные собы- ■ тия — запросы клиента, приход сегментов с флагами SYN, АСК, RST, FIN —' 5 или по истечении заданного времени. Условно работу соединения можно разде- j
лить на три стадии: установление соединения, рабочее состояние и закрытие соединения. Основное состояние — ESTABLISHED (обе системы готовы к приему и передаче данных приложения). В этом состоянии осуществляется обмен данными между абонентами. При создании соединения происходит так называемая синхронизация номеров.
Рассмотрим, например, процесс взаимодействия сервера и клиента по протоколу TCP. Для установления соединения необходимо выполнить следующие шаги.
Клиент посылает серверу сегмент с флагом SYN и своим номером в последовательности (Sequence Number) N.
Сервер отправляет клиенту подтверждение (Acknowledgment Number): «Ваш номер в последовательности — N», — и сообщает свой номер в последовательности (обозначим его К).
Клиент посылает серверу подтверждение: «Ваш номер в последовательности — К».
Теперь используем реальные номера. Выделим три шага в процессе установления соединения TCP. В этом примере клиент инициирует подключение по протоколу HTTP к серверу с портом назначения 8080. На первом шаге клиент посылает сегмент протокола TCP с установленным флагом SYN и своим номером в последовательности — 1362555259. На рис. 5.1 показаны поля заголовка сегмента TCP на первом этапе установления соединения. Запись получена с помощью анализатора протоколов eEye (полное название cEye Iris Network Traffic Analyzer, пробную версию программы можно получить по адресу www.eeye.com после регистрации).
Packet Decoder" ^ X
S- S Packet structure
H s 1 MAC header (Ethernet II)
TCP headerTCP headerto t-J IPv4 header e-®r
TCP header
TCP header
)- * Source port = 1353 RELIEF
’ — ^ Destination port = 8080 Generic ■ ■■ ^ Sequence number = 1362555259
'^ Aknowledgement number = 0
i w Header length = 7 (28 bytes)
Й El Flags
I . -Sow . .0Urgent pointer = 0
I ^"® ...0.... ACK = 0
i : ® ...,0... Push = 0 . --Ю0.. Reset = 0 Ii- Щ 1. SYN = 1
;©30 FIN = 0
\-% Window = 16384
- - X Checksum = 0x5345 (Correct)
^ Urgent pointer = 0
S £1 TCP Options = Yes
i .■"•^' Max segment: 1460 bytes
i # nop . L■ ♦ nop i i"-^ SACK OK ' © Data (0 bytes)
Рис. 5.1. Первый шаг установления соединения
На втором шаге сервер посылает клиенту сегмент, подтверждающий пол;
ние запроса (флаг АСК = 1) на установление соединения, с указанием своёй(
номера — 88315884. Кроме того, сервер устанавливает поле Acknowledging
Number в значение, которое на единицу больше полученного номера в послед™ вательности — 1362555260. Тем самым сервер показывает, что он ожидает ^ клиента следующий сегмент (рис. 5.2). у
S О Packet structure
IS kJ MAC header (Ethernet II) +3 uJ IPv4 header i-J LJ TCP header
г- Ф Source port = 8080 Generic
••• &• Destination port = 1353 RELIEF- W Sequence number = 88315884
^ Aknowledgement number = 1362555260: ^ Header length = 7 (28 bytes)Ei-® Flags
; M .,0Urgent pointer = 0
:гИ...1....ACK= 1
1Ш.,..0..,Push = 0
;Soil]0,,Reset = 0
;jHoik 1.SYN = 1
:-№0FIN = 0
i ■ §?: Window = 17520 : X Checksum = 0x8194 (Correct) : > Urgent pointer = 0
3 kJ TCP Options = Yes :$Maxsegment: 1460 bytes
•;Wnop
‘^nop
: - :&SACK OK
- <|) Data (0 bytes)
Рис. 5.2. Второй шаг установления соединения
На третьем шаге (рис. 5.3) клиент высылает серверу сегмент, в котором поле:* номера в последовательности устанавливается равным значению поля Acknow- □ ledgment Number, полученного от сервера — 1362555260. Кроме того, клиент !» подтверждает получение сегмента от сервера, присваивая полю Acknowledgment Я Number значение, на единицу больше полученного номера в последовательно- а
сти — 88315885.
Следует обратить внимание на то, что в процессе установления соединения ^ клиент и сервер согласовывают размер скользящего окна (Window = 17520). ДаН"1 ныс при установлении соединения не передаются (Data = 0 bytes). На стороне < клиента работает порт 1925, на стороне сервера — 8080. *
При обмене сегментами в процессе установления соединения полю Maximum ,< Segment Size (MSS) задано значение 1460, что соответствует максимальному^ размеру сегмента. Как будет показано далее, согласованный размер окна (Window 6 л = 17520) должен быть кратен этому значению, что и подтверждается на практики ке (17 520 / 1460 = 12). J
i-'l-fi Packet structure
Б- ^ MAC header (Ethernet II) (&•£□ IPv4 header
El & TCP header
i• Source port = 1353 RELIEF
; ■■■ # Destination port ■ 8080 Generic
I# Sequence number = 1362555260
:# Aknowledgement number = 88315885
।# Header length = 5 (20 bytes)
B-У Flags
: Si .,0Urgent pointer - 0
jk®...1,,..ACK- 1
,;-@....0...Push = 0
I kM0.. Reset = 0
:i -®0.5YN = 0
!L®0FIN - 0
i* Window - 17520
' X Checksum = 0xDE58 (Correct)
id Urgent pointer = 0
,Ф TCP Options = None
I(D Data (0 bytes)•
Рис. 5.3. Третий шаг установления соединения
ПРИМЕЧАНИЕ
Администратор может установить временной интервал, в течение которого маршрутизатор будет ожидать возможных попыток установления соединения по протоколу TCP. В ранних версиях операционной системы Cisco IOS этот интервал времени был фиксирован и равнялся 30 секундам. Такое значение мало для сетей, в которых используются медленные соединения, например асинхронные на аналоговых модемах. Значение этого интервала влияет только на трафик, адресованный самому маршрутизатору, но не на проходящий через него. Для того чтобы изменить интервал ожидания, нужно воспользоваться командой ip tcp synwait-time, выполняемой в глобальном режиме с параметром, задающим количество секунд ожидания синхронизации. Изменять значение по умолчанию стоит только в том случае, если администратор испытывает проблемы связи с маршрутизатором, например при работе с удаленным маршрутизатором по медленному каналу связи через сеанс Telnet.
При передаче протоколом TCP сегментов с данными он помещает их копии в очередь повторной передачи и запускает таймер. После прихода подтверждения для очередного сегмента соответствующая копия удаляется из очереди повторной передачи. Если подтверждение не приходит до истечения срока, заложенного в таймер, то сегмент посылается повторно. Повреждения сегментов при передаче фиксируются за счет добавления к каждому передаваемому сегменту контрольной суммы, проверки ее при получении и последующего удаления дефектных сегментов.
Как уже отмечалось, продолжительность жизни дейтаграммы протокола IP не должна превышать двух минут. Следовательно, когда протокол TCP отправ- -ляет с дейтаграммой протокола IP некоторый байт данных, порядковый номер этого байта сможет быть повторно использован не ранее, чем через две минуты. В результате 32-разрядного номерного пространства при двухминутном цикле Хватает лишь на то, чтобы достичь скорости передачи данных 286 Мбит/с.
Номер в последовательности может рассматриваться как простой 32-разрядя счетчик, который принимает любые значения в интервале от 0 до 4 294 967^ Для администратора сети очень важно понимать, каким образом изначальное бирается значение номера в последовательности и как оно изменяется во врем|| Когда клиент начинает работу, его ISN устанавливается в единицу, и значеЗ счетчика затем увеличивается каждую секунду на 128 000. Сброс счетчика производиться каждые 9,32 часа при условии, что соединение устанавливаться будет. При установлении соединения значение счетчика увеличивается на 64 Я
Следует отметить, что из-за довольно большой популярности атак, основана на предсказании начального номера в последовательности, компания Micros внесла определенные изменения в свою реализацию стека протоколов ТСИ для операционной системы Windows 2000. Процесс увеличения началья номера в последовательности ISN носит непредсказуемый характер. При та используется основанный на алгоритме RC4 механизм генерации случай™ чисел, инициализируемый с 2048-разрядным случайным числом при старте q темы. К сожалению, более подробной информации о механизме формирован ISN в операционной системе Windows 2000 автору найти не удалось. ;
Атака TCP SYN flooding
Рассмотрим механизм атаки TCP SYN flooding («шторм» запросов на устану ние соединения протокола TCP), которая, пожалуй, является наиболее попуя ной в семействе атак типа DoS. Напомним, что установление соединения dif вано на обмене информацией между клиентом и сервером. При этом существ некий максимально возможный предел (лимит) для количества одноврем^ обрабатываемых протоколом TCP запросов SYN. Эта предельная норма назь ется backlog. По сути, она представляет собой очередь, в которую помещай входящие незавершенные запросы па соединение. Предельная норма этой очей объединяет как незавершенные запросы на создание соединения, так и заверф ные запросы на создание соединений, которые еще не переданы приложению с мощью соответствующей процедуры. Если произошло превышение лимйта протокол TCP начнет отбрасывать новые входящие запросы SYN. Это будете должаться до тех пор, пока в очереди нс освободится место. И именно такай работы протокола TCP создает реальную возможность для проведения атак!
ПРИМЕЧАНИЕ:—
Атаки, организованные по типу «отказ в обслуживании» (Denial of Service — DoS) высветили одну проблему в защите, причем такую, для которой простого решения не существует. В, ОД случае атаки этого типа проводятся посредством генерирования большого объема трафика,^ мающего всю полосу пропускания или ресурсы атакуемого компьютера, в результате чего 0Й пользователи не могут получить к нему доступ. Чаще всего атаки направлены против web-ce ров, хотя базовый принцип позволяет проводить атаки практически против любого Д0СрУ™ устройства в сети, которое способно отвечать на посылаемые запросы. Например, это можем массовая посылка запросов ping (точнее, ICMP echo) или запросов на установление соедИЙ) протокола TCP.
^„jraTCPSYN flooding^„jraTCPSYN flooding195
^„jraTCPSYN flooding
^„jraTCPSYN flooding
Стек протоколов TCP/IP, реализованный в операционной системе Windows 2000 для отслеживания запросов к приложениям, взаимодействующим через интерфейс Windows Sockets, использует функцию listen(). Одним из передаваемых параметров при вызове этой функции является параметр backlog, определяющий количество незавершенных запросов, которые приложение хочет поместить в очередь. После того как приложение устанавливает соединение, его запросы удаляются из очереди. В спецификации Windows Socket 1.1 максимальное допустимое значение для backlog равно 5 запросам. Версия операционной системы Windows NT 3.51 могла иметь значение backlog до 100 запросов. Версии NT 4.0/2000 Server допускают до 200 запросов, в то время как NT 4.0 Workstation и Windows 2000 Professional ограничивают это значение числом 5.
Атакующий компьютер посылает огромное количество запросов на установление соединения TCP (или коротко — запросов SYN) компьютеру, который следует вывести из строя. При этом в качестве адреса отправителя указывается любой адрес (может быть адрес 0.0.0.0), так как атака не подразумевает какой-либо обмен между атакуемым и атакующим компьютером. Естественно, если был указан несуществующий адрес, то протокол IP будет информировать TCP о недостижимости получателя. Но протокол TCP будет считать, что эта ошибка должна быть исправлена протоколом IP, например с помощью выбора другого маршрутизатора для отправки, то есть фактически протокол TCP проигнорирует недостижимость. Более того, важна именно сама недостижимость получателя, так как в другом случае атакуемый компьютер будет отправлять сегменты с установленными флагами SYN/АСК (второй шаг в процессе установления соединения) по указанному адресу и в ответ может получить RST, что в силах помешать атаке.
Таким образом, атакующий компьютер, посылая массированные запросы SYN, заполнит очередь протокола TCP на атакуемом компьютере, что приведет к тому, что последний будет игнорировать любые другие запросы на данном порте. Разные реализации протокола TCP имеют разные размеры очереди. Если говорить об операционной системе Windows NT 4.0, то реализация протокола TCP (при конфигурации по умолчанию) посылает в ответ сегменты с флагами SYN/ACK 5 раз, удваивая значение тайм-аута после каждой передачи. Начальное значение таймера устанавливается в 3 секунды, таким образом, повторные запросы будут переданы на 3, 6, 12, 24, и 48-й секундах. После последней повторной передачи должно пройти 96 секунд, по прошествии которых протокол TCP перестанет ожидать ответ и освободит место в очереди. Таким образом, общее время использования ресурсов под открытие несостоявшегося соединения будет составлять 189 секунд. Пользователь, подозревающий, что его компьютер подвергается подобной атаке, в состоянии проверить этот факт, выполняя команду netstat -п -р tcp. В случае организации реальной атаки на экране можно получить результат, ' п°казанный в следующем примере. Этот пример взят из статьи Q142641 Microsoft i Knowledge Base, которая была опубликована 4 июля 2000 года:
TCP TCP TCP TCPTCP TCP TCP TCPProto Local AddressProto Local Address127.0.0.1:1030127.0.0.1:103210.57.8.190:2110.57.8.190:21127.0.0.1:1030127.0.0.1:103210.57.8.190:2110.57.8.190:21Foreign AddressState
TCP TCP TCP TCP
TCP TCP TCP TCP
Proto Local Address
Proto Local Address
127.0.0.1:1030
127.0.0.1:1032
10.57.8.190:21
10.57.8.190:21
127.0.0.1:1030
127.0.0.1:1032
10.57.8.190:21
10.57.8.190:21
127.0.0.1:1032ESTABLISHED
127.0.0.1:1030ESTABLISHED
10.57.14.154:1256SYN_RECEIVED
10.57.14.154:1257SYN RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1258
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1259
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1260
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1261
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1262
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1263
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1264
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1265
SYN_RECEIVED
TCP
10.57.8.190:21
10.57.14.154:1266
SYN_RECEIVED
TCP
10.57.8.190:4801
10.57.14.221:139
TIME WAIT
:$)
Анализируя результат выполнения команды, можно увидеть большое кол:
во состояний SYN_RECEIVED (индикация получения запроса
SYN),
соответс
венно возникает законное подозрение о проведении атаки на данный компьюте
Кроме рассмотренного изменения в реализации стека TCP/IP, компа® Microsoft реализовала еще ряд расширений. Так, администратору доступен ois циальный параметр в реестре операционной системы — SynAttackProtect, устанод которого избавляет администратора от необходимости проводить коррективе ку других значений параметров протокола TCP для достижения максимальн защиты (табл. 5.1). vi
Таблица 5.1. Параметр SynAttackProtect
Название параметра
Ключ в реестре
Тип записи
SynAttackProtect Tcpip\Parameters REG_DWORD
.•.ЦТ'
~мЕ
Диапазон значений
Значение по умолчанию
о, 1, 2
О
и:
По умолчанию этот параметр реестра 0 (защиты от атаки TCP SYN flooding нё в то время как рекомендованным является значение 2. При SynAttackProtect - будут уменьшаться интервалы между повторными передачами и будет задерж ваться создание записи о маршруте соединения — RCE (route cache entry), ей
параметры TcpMaxHalfOpen и TcpMaxHalfOpenRetried адекватны угрозе проведен! атаки (ниже описание этих параметров в реестре). При SynAttackProtect = 2 в Д бавление к действиям, выполняемым при SynAttackProtect = 1, включается йнд кация о задержке для приложений. ' ,, .
При этом, как видно из описания, система будет уменьшать количество повтсф ных передач сегментов с флагами SYN/АСК. Дополнительно будет сокращён
время, в течение которого система поддерживает информацию о соедине
в очереди. Это позволит быстрее очищать очередь от незавершенных соединение Кроме того, выделение записи RCE задерживается до тех пор, пока соедий
ние не будет установлено.
Обратите внимание
на то,
что
этот
защитный
мех
низм начинает работать только тогда, когда превышены значения параметр' TcpMaxHalfOpen и TcpMaxHalfOpenRetried для соединений протокола TCP. Первг параметр (TcpMaxHalfOpen) контролирует количество незавершенных (так наЗ ваемых half-open) запросов на установление соединения до момента, когда о]
пионная система будет считать, что она подвергается атаке TCP SYN flooding. Если параметр реестра SynAttackProtect равен 1, то администратор сети должен бедиться, что значение рассматриваемого параметра меньше, чем размер очереди backlog (табл. 5.2).
5.2. Параметр TcpMaxHalfOpen
Название параметра
TcpMaxHalfOpen
Ключ в реестре
Tcpip\Parameters
Тип записи
Диапазон значений
Значение по умолчанию
REG_DWORD
0x64- OxFFFF
0x64 (100) для Microsoft Windows Professional, Server и 0xlF4 (500) для Advanced Server
Параметр TcpMaxHalfOpenRetried (табл. 5.3) призван контролировать количество незавершенных соединений, для которых была выполнена по крайне мере одна повторная посылка SYN, до того момента как начнет работать защита от атаки. .
Таблица 5.3. Параметр TcpMaxHalfOpenRetried
Название параметра
Ключ в реестре Тип записи
TcpMaxHalfOpenRetried Tcpip\Parameters REG_DWORD
Диапазон значений
Значение по умолчанию
0x50-0xFFFF
0x50 (80) для Microsoft Windows Professional, Server и 0x190 (400) для Advanced Server
Если администратор считает, что установки только этого параметра в реестре недостаточно для защиты от атак TCP SYN flooding, то он может скорректировать другой параметр — TcpMaxConnectResponseRetransmissions, влияющий на количество попыток отправления сегментов с флагами SYN/АСК в ответ на запрос SYN (табл. 5.4).
Таблица 5,4. Параметр TcpMaxConnectResponseRetransmissions
Название параметра Ключ в реестре Тип записи
Диапазон значений ^Значение по умолчанию
TcpMaxConnectResponseRetransmissions
Tcpip\Pa га meters
REG_DWORD
O-OxFFFFFFFF
3
Значение по умолчанию для данного параметра равно 3, но в распоряжении администратора есть еще два режима — 1 и 2. В табл. 5.5 показано поведение пР°токола TCP при различных значениях рассматриваемого параметра реестра.
Таблица 5.5. Влияние параметра TcpMaxConnectResponseRetransmissions на соединение
Значение
Повторные передачи через
Общее время
Сброс незавершенных сеансов через
1
3 секунды
9 секунд
6 секунд
2
3 и 6 секунд
21 секунда
12 секунд
3
3, 6 и 12 секунд
45 секунд
24 секунды
Данный параметр изменяет время по умолчанию, которое требуется для с( са незаконченных сеансов TCP за период времени между 9-й и 45-й секунд и предоставляет администратору возможность более точного контроля. В том^ чае, если на сервер постоянно происходят атаки SYN flooding (факт можно наружить, задействуя систему обнаружения атак — Intrusion Detection Sys IDS), администратор вправе установить данный параметр в 1, максимально ( жая тем самым время сброса незавершенных сеансов. Администратор может у повить параметр и в 0, но в этом случае сегменты с флагами SYN/АСК воо не будут передаваться повторно и соединение будет завершаться через 3 секун Обратите внимание, что, обеспечивая наиболее сильную защиту от атаки § flooding, вы вносите вероятность проблем с удаленными клиентами на пло: линиях связи, когда возможна потеря сегментов при передаче и в процессе у( новления соединения. ;
Приложения, работающие с Windows Sockets, такие как серверы FTP и W$ обрабатывают попытки подключения по протоколу TCP с помощью драйв afd.sys, который был изменен для поддержки большого количества незаверш ных соединений без отказа в обслуживании. Это достигается включением с темный реестр параметров, позволяющих администратору сети настраивать^, намическую очередь backlog.
Параметр реестра EnableDynamicBacklog позволяет глобально включать или в ключать динамическую очередь backlog. По умолчанию этот параметр равен что означает отключение очереди. Однако если система часто подвергается М3 сированным атакам, то рекомендуется выставлять значение 1 (табл. 5.6). /
Таблица 5.6. Параметр EnableDynamicBacklog
Название параметра
Ключ в реестре
Тип записи
EnableDynamicBacklog
\SYSTEM\CurrentControlSet\Services\AFD\Parameters
REG_DWORD
Диапазон значений
0, 1!
Значение по умолчанию
0
Параметр MinimumDynamicBacklog контролирует минимальное количество С бодных соединений, разрешенных па сервере. Если количество свободных единений (или, иными словами, место в очереди backlog) снижается на ве чину, меньшую, чем значение этого параметра, то формируется систем! запрос на создание дополнительных свободных соединений. Значение пара®
a MinimumDynamicBacklog не должно быть большим, так как это может привести к снижению производительности (табл. 5.7).
Таблица 5.7. Параметр MinimumDynamicBacklog
Название параметра
MinimumDynamicBacklog
Ключ в реестре
\SYSTEM\CurrentControlSet\Services\AFD\Parameters
Тип записи
REG_DWORD
Диапазон значений
O-OxFFFFFFFF
Значение по умолчанию
0
По умолчанию значение этого параметра равно 0, по для серверов, которые часто подвергаются атакам, его можно увеличить до 20.
Параметр MaximumDynamicBacklog контролирует количество так называемых квазисвободпых (quasi-free) соединений, разрешенных на сервере. Квазисвободные соединения включают в себя и свободные соединения, и соединения, которые находятся в незавершенном состоянии (SYN_RECEIVED). Сервер не будет пытаться создавать дополнительные свободнее соединения, если это приводит к превышению данного параметра. Значение параметра MaximumDynamicBacklog не должно превышать 5000 для каждых 32 Мбайт памяти, установленной на сервере. Это сделано для того, чтобы избежать возможной нехватки памяти при осуществлении атаки (табл. 5.8).
Таблица 5.8. Параметр MaximumDynamicBacklog
Название параметра
Ключ в реестре
Тип записи
MaximumDynamicBacklog
\SYSTE М \Cu rrentControlSet\Services\AFD\Pa га meters
REG_DWORD
Границы значений
Значение по умолчанию
O-OxFFFFFFFF 0
Параметр DynamicBacklogGrowthDelta задает количество создаваемых свободных соединений, когда необходимы дополнительные соединения. Администратору сети следует очень аккуратно работать с этим параметром, так как большое его значение может привести к взрывному росту объема памяти, выделяемой под свободные соединения. Рекомендованное значение на случай возможной атаки равно 10 (табл. 5.9).
Таблица 5.9. Параметр
Название параметра
DynamicBacklogGrowthDelta
Ключ в реестре
\SYSTEM\CurrentControlSet\Services\AFD\Parameters
Тип записи
REG_DWORD
, Диапазон значений
O-OxFFFFFFFF
• Значение по умолчанию
0
Чтобы получить максимум преимуществ от изменений в драйвере afd.sy™ приложения, работающие с Windows Sockets, при формировании запроса listeraH должны специально запрашивать значение очереди backlog большее, чем значениИ параметра MinimumDynamicBacklog. Приложения, разработанные компанией М1стЯ soft, среди которых наиболее популярным объектом для организации атак явлЯ ется Internet Information Server (IIS), позволяют производить настройку cboiM параметров, причем для IIS размер очереди backlog по умолчанию равен 25. ■
Мы рассмотрели некоторые варианты защиты от атаки TCP SYN floodings! конечных устройствах сети — серверах. Однако на практике редко встпечаеТяИ ситуация, когда серверы, предоставляющие какие-либо услуги внешним пользЯ вателям, были бы установлены в сегменте сети, напрямую подключенном к ИнтеЯ нету без обеспечения защиты.Я
Первый барьер на пути потенциальной атаки можно создать на гранично! маршрутизаторе компании Cisco Systems (или любом другом, который поддеЯ живает нужные функции). Естественно, самым простым способом защиты являЯ ется формирование списка управления доступом на маршрутизаторе, котором будет просто блокировать запросы на установление соединения TCP с опредЯ ленных адресов в сети. Несмотря на абсолютное отсутствие смысла в такой зЯ щите с точки зрения доступности, например, сервера WWW в Интернете, ойЯ может быть неплохим решением, если выявлен постоянный источник ненорма^Я ного количества SYN-запросов TCP.Я
К сожалению, атака может быть организована и со случайно выбранными ресами отправителя. Начиная с версии 11.3 операционной системы IOS админЯ стратору сети доступен механизм TCP Intercept. Настройка TCP Intercept (пЯ рехват) на маршрутизаторе препятствует проведению подобной атаки. Кратки опишем схему работы этого механизма. Граничный маршрутизатор перехватйЯ вает запрос SYN на установление соединения TCP от клиента к серверу. ЗатеЯ маршрутизатор сам устанавливает соединением с клиентом, действуя как бы! вместо сервера с последующим связыванием двух незавершенных соединении! вместе. Происходит это абсолютно прозрачно как для клиента, так и для серве’Я ра. Важным моментом является то, что SYN-запрос протокола TCP от несуще! ствующего клиента в сети никогда не достигнет сервера, тем самым устраняется одно из условий успешной атаки TCP SYN flooding.i Д
При настройке рассматриваемого механизма на маршрутизаторе админист! ратор может указать на необходимость перехвата всех запросов TCP SYN илу только тех, которые приходят из определенных сетей или адресованы конкрет* ному серверу. Важной особенностью работы механизма перехвата является то, что специфичные параметры протокола TCP (например, масштабирование сколь? зящего окна), оговариваемые в процессе установления соединения, не буду! приниматься во внимание маршрутизатором, так как последний, естественно, не обладает информацией о соответствующих возможностях сервера.' -
Для того чтобы включить на маршрутизаторе механизм TCP Intercept, нужНЙ сначала сформировать расширенный список доступа (глава 9), определяющие перечень адресов, для которых необходимо проводить перехват запросов ТСВ SYN. Затем, после определения списка, следует ввести команду ip tcp intercept lid
указанием номера созданного списка. Рассмотрим пример, который показывает процесс формирования расширенного списка доступа с номером 101, указы- ваюшего на необходимость перехвата SYN-запросов, адресованных всем серверам, принадлежащим сети 192.168.3.0/24.
ip tcp intercept list 101
i
access-Hst 101 permit tcp any 192.168.3.0 0.0.0.255
ПРИМ ЕЧАНИ E
Для получения информации о детальной настройке механизма TCP Intercept можно обратиться по адресу http://www.cisco.com/univercd/cc/td/doc/product/software/iosll3ed/113ed_cr/secur_c/scprt3/ /scdenial.htm.
АТАКИ LAND И STREAM.С—
Атака Land относится к атакам типа DoS, и в ее основе лежит отправка массированных запросов SYN (сама атака является развитием атаки TCP SYN Flooding). Причем адрес и номер порта отправителя устанавливаются совпадающими с адресом и портом получателя. Подобная атака может заставить некоторые реализации стека TCP/IP войти в цикл, приводящий к сбою атакуемого компьютера или значительному потреблению ресурсов/что негативно влияет на общую производительность. Обнаружение подобной атаки — довольно простая задача, так как совпадение адресов и портов однозначно указывает на эту атаку. Для противодействия можно порекомендовать настроить граничный маршрутизатор или защитный экран на блокировку входящих пакетов, содержащих адреса организации в качестве отправителей.
Атака stream.c также относится к атакам типа DoS. Она нацелена на выведение уязвимой системы из рабочего состояния путем посылки большого количества ложных сегментов протокола TCP с установленным флагом АСК и указанием случайных номеров портов на стороне получателя. Системы обнаружения вторжений могут идентифицировать этот тип атаки, анализируя значения в заголовке сегмента TCP, искомый набор которых возможен, но очень редко встречается в обычных пакетах.
■ Продолжая разговор о защите от атаки TCP SYN flooding, напомним, что администратор сети в состоянии воспользоваться также возможностями защитного экрана. В настоящее время большинство производителей защитных экранов И. включают необходимые для этого средства в свои продукты. Например, работая с комплексом NetGuard GuardianPro v5.0x, при создании стратегии защиты (здесь под стратегией понимается набор правил фильтрации трафика) администратор может также включить механизм защиты от атаки TCP SYN flooding, ria рис. 5.4. представлен фрагмент окна программного комплекса, которое позволяет регулировать параметры защиты.
Так, администратор может указать промежуток времени в секундах, в тече- ■ ние которого защитный экран будет ожидать завершения трехшагового процесса установления соединения TCP (поле Wait for second TCP ACK for ... seconds) до принудительного сброса соединения.
I Среди других доступных настроек — количество попыток сброса установле- L .Ния соединения TCP по тайм-ауту до того, как защитным экраном будет приня- Ь с^Рсшение о том, что проводится атака (поле Detect SYN flood after... missing TCP — защитный экран проверяет пропущенные сегменты с флагами АСК).
■-l-*^ Commonг s-gS1 Genetai t- iS* Customize:!- Й* Monitored Networks/RangesS Dynamic Networks/Ranges AuthenticationLogs:A Alerts= LHistoryH-iS Filewall:' -й* sf$ltil<$ding^^■i [^ Spoofing Control:■ г- Й* IP source routing protectioni i- Ц§* Invalid Password:Д T e'ne* spawning protection\ ' S Short TCP Sessions:;-Д1 Content Filter Server■-l-*^ Commonг s-gS1 Genetai t- iS* Customize:!- Й* Monitored Networks/RangesS Dynamic Networks/Ranges AuthenticationLogs:A Alerts= LHistoryH-iS Filewall:' -й* sf$ltil<$ding^^■i [^ Spoofing Control:■ г- Й* IP source routing protectioni i- Ц§* Invalid Password:Д T e'ne* spawning protection\ ' S Short TCP Sessions:;-Д1 Content Filter ServerТут следует отметить, что при работе пользователей с внутренними серве; через защитный экран по некачественным каналам связи зачастую происходя регулярная потеря пакетов, что приводит к завершению незаконченного соем нения TCP по тайм-ауту. Это значит, что только относительно большое значегй этого параметра будет служить признаком атаки. При использовании послй него параметра (Reset count every ... seconds) факт атаки подтверждается толь^ в том случае, когда указанное количество пропущенных подтверждений ТС АСК фиксируется в течение заданного промежутка времени.
■-l-*^ Common
г s-gS1 Genetai t- iS* Customize
:!- Й* Monitored Networks/Ranges
S Dynamic Networks/Ranges Authentication
Logs
:A Alerts
= LHistory
H-iS Filewall
:' -й* sf$ltil<$ding^^
■i [^ Spoofing Control
:■ г- Й* IP source routing protection
i i- Ц§* Invalid Password
:Д T e'ne* spawning protection
\ ' S Short TCP Sessions
:;-Д1 Content Filter Server
■-l-*^ Common
г s-gS1 Genetai t- iS* Customize
:!- Й* Monitored Networks/Ranges
S Dynamic Networks/Ranges Authentication
Logs
:A Alerts
= LHistory
H-iS Filewall
:' -й* sf$ltil<$ding^^
■i [^ Spoofing Control
:■ г- Й* IP source routing protection
i i- Ц§* Invalid Password
:Д T e'ne* spawning protection
\ ' S Short TCP Sessions
:;-Д1 Content Filter Server
i SYN FLODDINB PROTECTION .' 1 V ?X P £nable SYN flooring protections
I Trigger ^a
Wa< for second TCP ACT lor IJH seconds
Detect SYN flood after [icj missing TCP ACKi'^ "' .y
Beset count every |з5"™ seconds. яшм* ,
, Г'Action --■ ;—
1 lllllll^
/X iv AleJ
Рис. 5.4. Фрагмент окна настройки защиты от атаки TCP SYN Flooding
В нашем примере защитный экран будет оповещать об атаке, если он в т
ние 30 секунд обнаружитние 30 секунд обнаружит1010пропущенных подтверждений TCP АСК от кли
ние 30 секунд обнаружит
ние 30 секунд обнаружит
10
10
та, необходимых для завершения квитирования соединения. Дополнительно
щитный экран будет принудительно разрывать соединение, если от клиента
поступает третий, завершающий пакет TCP АСК. Эти значения устанавливая^ ся по умолчанию, когда администратор устанавливает флажок Enable SYN floodlS protection. Однако администратору может потребоваться скорректировать даннь параметры, если к нему поступает большое количество оповещений об атам TCP SYN flooding, ввиду того что, скорее всего, это будет «ложная тревога».; ;.;
Администратор сети может настроить защитный экран на отправку по пот извещений об атаках. В Guardian Pro этот механизм действует по некой наког тельной схеме. При этом защитный экран посылает обобщающие сообщен! например, по конкретному адресу электронной почты, не информируя о кажд обнаружении атаки и не нервируя администратора. На рис. 5.5 показано peaj ное письмо с оповещением об атаке. 'У
К сожалению, без дополнительных средств точно отличить факт проведе! атаки от результата работы плохих каналов связи затруднительно. По этойт чине, чтобы своими поспешными выводами не обидеть инициаторов этих с( щений, будем считать, что их причина кроется в некорректной настройке is метров для отслеживания атак TCP SYN flooding (кроме того, стоит приник
Атака TCP SYN flooding
внимание тот факт, что чаще всего при атаке в качестве адресов отправите- Вей указываются либо случайные, либо несуществующие адреса). В этом сообщении также фигурирует адрес атакуемого компьютера (192.168.3.250). Об-
iiггttТе внимание на то, что в сети используется внутренняя адресная схема Утл 168.3.0/24), а взаимодействие с внешним миром осуществляется благодаря технологии трансляции адресов NAT. Но логика работы защитного экрана такова что вначале он преобразует внешний адрес поступающего пакета во внутренний адрес сервера, и только после этого применяет к нему правила фильтрации и проводит анализ на предмет наличия атак. В этом причина того, что в уведомлении указывается внутренний адрес сервера, несмотря на то что инициатором были хосты в Интернете.
i
i
г
г
t
t
Ж!!! ALERTS 1! - Сообщение (Про: i ои текст)
ИИJ '^айя Црввкв $№ Вставка Фодат Сервис Действия ^правка
И
И
От:GuardiavAgentОтравлено: пт 06.04,20010:46
Кону: alert observer,
|Fri Apr 06 01:49:04 2001 SYN-attack from 203.144.223.76 to 192.168.3.250 is detected.
Wed Apr 04 16:12:28 2001 SYN-attack from 195.161.241.228 to 192.168.3.250 is detected.
Wed Apr 04 16:12:24 2001
SYN-attack from 195.161.241.228 to 192.168.3.250 is detected.
Wed Apr 04 16:12:24 2001
SYN-attack from 195.161.241.228 to 192.168.3.250 is detected.
Рис. 5.5. Оповещение об атаке
В ОПЫТА
Вообще говоря, администратору необходим достаточно богатый опыт для уверенной работы со средствами предотвращения атак, и относиться к этой проблеме он должен спокойно. Но и ума- лять проблему нельзя. Как вы думаете, сколько подобных сообщений получает автор при работе Реальной сети? Около 10 за рабочий день. Причем, учитывая накопительных характер оповещении, можно с уверенностью говорить о том, что в среднем сеть подвергается 20-25 атакам сутки. Естественно, как уже не раз отмечалось, очень велика вероятность того, что это просто жные срабатывания. С другой стороны, нельзя не учитывать и достаточную вероятность осу- , Ществления реальных атак, что просто подтверждает их популярность и необходимость для ад- ^ нистратора сети обращать на них самое пристальное внимание. Автор полностью согласен кспертами в области компьютерной безопасности (в частности, с авторами третьего издания 7 таИГИ *^така из Internet»), говорящими о том, что большая часть атак мотивирована элемен- ■ но“НЬ1м ванДализмом, а не преследует цель получения доступа к какой-либо конфиденциаль- ■ инФ°Рмаиии. Иначе довольно трудно объяснить повторяющиеся попытки вывести из строя вР ^WW (а именно этот сервис предоставляет компьютер с адресом 192.168.3.250), так как общедоступен.
Блок управления передачей протокола ТС№<
Одновременное взаимодействие нескольких прикладных программам на одн компьютере с помощью протокола TCP сводится к взаимодействию через coi ты. Для сохранения всей совокупности информации, необходимой для создан и поддержки соединения, каждый раз при установлении соединения создд ся структура данных, называемая блоком управления передачей (Transmissi Control Block — ТСВ). ТСВ содержит ряд переменных, определяющих qi редность отправления и получения сегментов. В частности, к ним относят SND.UNA — посылка не подтверждена; SND.NXT — послать следующий сегме SND.WND — отправить окно; RCV.NXT — получить следующий сегмент. На рис. показана последовательность этапов отправки и приема данных. ’ '
^ Подтверждениеданных^ ПодтверждениеданныхДанные еще _► не подтвержденыДанные еще _► не подтвержденыРазрешеннаяРазрешеннаяпередача данныхпередача данных
^ Подтверждениеданных
^ Подтверждениеданных
Данные еще _► не подтверждены
Данные еще _► не подтверждены
Разрешенная
Разрешенная
передача данных
передача данных
ЧПосылка данных ►
Начальный номерв последовательности(ISN)Начальный номерв последовательности(ISN)SN в последнемполученном АСК(SND.UNA)аSN в последнемполученном АСК(SND.UNA)аСледующий SNдля посылки(SND.NXT)Следующий SNдля посылки(SND.NXT)Граница окна(SND.UNA+SND.WND)Граница окна(SND.UNA+SND.WND)
Начальный номерв последовательности(ISN)
Начальный номерв последовательности(ISN)
SN в последнемполученном АСК(SND.UNA)
а
SN в последнемполученном АСК(SND.UNA)
а
Следующий SNдля посылки(SND.NXT)
Следующий SNдля посылки(SND.NXT)
Граница окна(SND.UNA+SND.WND)
Граница окна(SND.UNA+SND.WND)
Данные полученыи подтвержденыДанные полученыи подтвержденыРазрешеннаяпередача данныхРазрешеннаяпередача данныхДанные ещене подтверждены-*'
Данные полученыи подтверждены
Данные полученыи подтверждены
Разрешеннаяпередача данных
Разрешеннаяпередача данных
Ч Получение данных►
Начальный номер Подтверждение Последний полученный Граница окна^ в последовательности последнегосегмент данных (RCV.NXT
(ISN)сегмента данных(RCV.NXT) +RCV.WND) '
б■
Рис. 5.6. Чередование отправки и приема данных: а — этапы отправки данных, 6 — этапы, приема данных^
.4 г:
Рассмотрим пример использования некоторых переменных. Отправитель с, мощью переменной SND.NXT следит за отправкой следующего сегмента в очере Получатель на основании значения переменной RCV.NXT отслеживает номер< дующего поступающего сегмента. В переменную SND.UNA отправитель помет последний номер сегмента, который уже отправлен, но еще не подтвержу Когда отправитель посылает новый сегмент, он инкрементирует значение с]| переменной SND.NXT. Получатель при поступлении этого сегмента увелич:
значение своей переменной RCV.NXT и отправляет подтверждение. При доставке подтверждения увеличивается значение переменной SND.UNA отправителя. Разность значений переменных SND.NXT и SND.UNA может служить мерой задержки сегментов в сети. Значения переменных изменяются на величину, равную длине поля данных сегмента. Более подробно формат заголовка, описание полей, флаги возможные состояния соединения и переменные описаны в RFC 793.
Скользящее окно
Как и большинство протоколов, осуществляющих управление потоком данных (например, HDLC и Х.25), протокол TCP использует механизм скользящих (или плавающих) окон. Пожалуй, для TCP можно считать этот механизм основополагающим. Протоколы HDLC и Х.25 реализуют его в классическом виде — на каждый отправленный блок данных должно быть получено подтверждение. Протокол TCP несколько отходит от традиционной схемы. Основной недостаток классического варианта заключается в том, что за один сеанс может быть передан только один сегмент. В данном случае-под сеансом понимается посылка сегмента и получение подтверждения его успешного приема. Такая схема не позволяет работать с максимальной производительностью. Эффективность может быть значительно повышена, если разрешить передачу множества сегментов за один сеанс с группировкой всех подтверждений для них в одно.
Рассмотрим этот метод на примере работы двух станций — А и Б, которым необходимо обмениваться данными. Станция Б выделяет буферное пространство для приема п сегментов. То есть можно сказать, что в данный момент времени станция Б готова принять п сегментов, а станция А готова послать те же п сегментов без подтверждения их приема. Для идентификации подтверждений о принятых сегментах каждый из них помечается своим номером в последовательности данных. Станция Б удостоверяет получение текущего сегмента посылкой подтверждения, которое включает в себя номер следующего ожидаемого сегмента в последовательности. Это подтверждение также косвенно извещает станцию А о том, что станция Б готова получить следующие п сегментов начиная с указанного номера последовательности. Очевидно, что можно выслать одно подтверждение на несколько сегментов. Например, станция Б получила сегменты 2, 3 и 4, но задержала подтверждения на сегменты 2 и 3 до получения сегмента 4. После посылки подтверждения с номером 5 станция Б информирует 0 получении сегментов 2, 3 и 4 за один раз. Иными словами, станция А поддерживает список номеров в последовательности, которые ей разрешено посылать, а станция Б — список номеров в последовательности, которые она готова принять. ■ Каждый из этих списков может быть рассмотрен как окно сегментов. Такую схему Работы часто называют «управление потоком с помощью скользящего окна».
Так как номер в последовательности занимает в сегменте одно поле, то очевидно, что он имеет границы. Например, если это поле занимает 3 бита, то номер в последовательности может принимать значения от 0 до 7. Соответственно, , Сегменты нумеруются циклически, по модулю 8, то есть за номером 7 последует L номер 0. Таким образом, для поля номера последовательности, состоящего из
к битов, значения номера лежат в пределах от 0 до (2к — 1), а сегменты ну^^) ются по модулю 2к. В процессе передачи и приема сегменты проходят ряд межуточных состояний (рис. 5.7).
Сегменты в буфере,ожидающие подтверждения
-<►
Окно сегментов, Переданные сегменты►◄ - которые можно —►
передать
б‘
■ Г
Рис. 5.7. Состояния сегментов при приеме и передаче: а — на стороне отправителя, б — на стороне получателя
На рис. 5.7 показаны направления движения границ окон посылки и прйй В примере для простоты используется 3-разрядное поле «Номер в последовате. ности». Затененные прямоугольники указывают на сегменты, которые могут об посланы. В соответствии с рисунком, отправитель может послать 5 сегмент начиная с сегмента с номером 0. Тогда, когда очередной сегмент отправляв в путь, ширина затененной области уменьшается; каждый раз, когда получ подтверждение, ширина затененной области увеличивается. Сегменты, на: щиеся между вертикальной чертой и затененным участком, уже были пос;
Скользящееокно
, еще не были подтверждены. Отправитель должен хранить копии этих сегмен- ^ов в своем буфере на тот случай, если потребуется их повторная передача.
Рассмотрим следующий пример (рис. 5.8), который позволяет проследить за обменом информацией.
Рис. 5.8. Схема обмена информациейРис. 5.8. Схема обмена информациейЗдесь также используется 3-разрядное поле номера в последовательности. Максимальный размер окна в этом случае позволяет работать с 7 сегментами.
Рис. 5.8. Схема обмена информацией
Рис. 5.8. Схема обмена информацией
В начале работы размер окон станций А и Б таков, что станция А может передать 7 сегментов, начиная с сегмента SO, а станция Б — принять такое же количество сегментов. После доставки 3 сегментов (SO, S1 и S2) без подтверждения станция А сокращает размер своего окна посылки до 4 сегментов и сохраняет в буферной памяти копию 3 посланных сегментов. Новый размер окна посылки Указывает на то, что станция А готова передать 4 сегмента, начиная с сегмента S3, танция Б после получения части сегментов отправляет сообщение RR3, из кото- Р°го следует: «Я получила все сегменты по S2 включительно и готова принять ^гмент S3; более того, я готова к приему 7 сегментов, начиная с сегмента S3».
Дя станции А эта информация означает то, что она получила разрешение на
передачу 7 сегментов, начиная с сегмента S3. Кроме того, станция А вправе о стить свою буферную память от копий первых 3 сегментов, поскольку они уса но доставлены. Теперь станция А передает сегменты S3, S4, S5 и S6. Стаю™ отправляет в ответ подтверждение RR4 на получение сегмента S3 и разреш отослать сегменты от S4 до S2 (сегмент S2 относится уже к следующей последа тельности из 7 сегментов). Но на момент получения станцией А этого подтве] дения сегменты S4, S5 и S6 уже были посланы и, следовательно, она может г ширить свое окно посылки и отправить 4 сегмента, начиная с сегмента S7, '
। -
Узкие места в сети
В протоколах канального уровня управление потоком данных с использована плавающего окна дает получателю возможность управлять скоростью раба отправителя. Получатель в этом случае только подтверждает полученные сегм; ты и расширяет свое окно приема в соответствии с наличием свободного буфер! го пространства. Задавать скорость передачи данных можно и при работе с гй токолом TCP. Для простоты рассмотрим классический вариант, когда скорее отправки данных определяется скоростью поступления подтверждения для ^ дыдущего посланного сегмента.. i-
Покажем, что в этом случае скорость поступления подтверждений завиСЙТ наличия так называемых «узких мест» в сети между отправителем и получа лем. Узким местом может быть либо устройство в сети либо часть канала, име щие значительно меньшие параметры быстродействия, чем вся сеть в цел< В том числе вносить задержку способен и получатель. Узкое место, которое £ вает как логическим, так и физическим, может возникнуть в разных точках Э1 сети на пути между отправителем и получателем. На рис. 5.9 представлен й] . мер образования логических и физических узких мест.
Логические узкие места
ОтправительПолучатель
Рис. 5.9. Узкие места в сети•
В этом примере отправитель имеет пропускную способность 10 Мбит/с. Ы< работы протокола TCP канал со скоростью 1,5 Мбит/с между маршрутиза
становится узким местом. Это физическое узкое место, и после достижения стойчивого состояния протокол TCP будет эффективно использовать доступную скорость передачи. Однако наиболее часто узкие места являются логическими и образуются из-за очередей па маршрутизаторах, коммутаторах или получателях Задержки в очередях, как правило, подвержены флуктуациям и усложняют процесс формирования устойчивого потока.
флуктуация задержек, которая имеет место в распределенных IP-сетях, затрудняет выбор политики отправки данных по протоколу TCP на стороне отправителя. Если поток имеет слишком маленькую скорость, то распределенная сеть будет использоваться неэффективно. Если один или несколько отправителей работают на повышенной скорости, то другие потоки TCP будут «стеснены» потоками этих отправителей. Если же множество отправителей TCP используют чрезмерно высокую скорость, то сегменты будут теряться при передачах, приводя к повторным передачам, или подтверждения будут сильно задерживаться, что также влечет ненужные повторные передачи. Более того, повторные переда
чи могут иметь эффект положительный обратной связи: чем больше сегментов посылается заново, тем быстрее растет перегрузка, что, в свою очередь, приводит к дальнейшему повышению задержек и к увеличению числа отброшенных сегментов. Все это имеет следствием увеличение числа повторных передач, что в еще большей степени усугубляет перегрузку.
Рассмотрим случай, когда узкое место находится где-то внутри сети. На рис. 5.10 изображен низкоскоростной канал между отправителем и получателем.
i" Рис. 5.10. Влияние низкоскоростного канала на передачу данныхi" Рис. 5.10. Влияние низкоскоростного канала на передачу данных
i" Рис. 5.10. Влияние низкоскоростного канала на передачу данных
i" Рис. 5.10. Влияние низкоскоростного канала на передачу данных
I Ширина этого канала пропорциональна скорости передачи данных. Отпра- ■ ВИтель и получатель подключены к высокоскоростным сетям. Канал из-за своей ■^зкой пропускной способности изображен на рисунке тонким. Он как раз и соз-
дает «бутылочное горлышко». Каждый посланный сегмент с данными изб ждется на этом рисунке прямоугольником, площадь которого пропорциона количеству байтов информации в сегменте. Поэтому когда сегмент проходи тонкому каналу, он как бы сдавливается им и вытягивается в длину и, соо: ственно, увеличивается время его прохождения по каналу. Время прохожд сегмента через определенную точку медленного канала обозначим РЬ — это мя между моментами пересечений передней и задней границ сегмента. Пре ложим, что, продвигаясь по медленному каналу, сегменты идут вплотную:; к другу, то есть задняя граница первого примыкает к передней границе вто сегмента. Поэтому РЬ будет определять и время пересечения передней грав первого сегмента и передней границы второго сегмента через некоторую, т( в канале. При поступлении сегментов в высокоскоростной канал это время м< передними границами сегментов сохраняется даже с учетом повышения скор передачи данных, так как интервал между поступлениями не меняется. А скольку сегмент на высокоскоростном канале как бы сужается, но увеличив ся в ширину, то теперь это время состоит из времени прохождения черёд; сегмент и паузы до передней границы следующего сегмента, то есть Рг ^ Если получатель подтверждает сегменты в момент поступления, то время ду посылками подтверждающих сегментов (АСК-сегментов) Ат на выходе ц; чателя равно Рг. И, наконец, мы получаем, что Ab = Ат, a As = Ab....
После попытки работать с высоким быстродействием система переходит в yci чивое состояние, в котором скорость отправки сегментов равна скорости . ступления подтверждений. Очевидно, что скорость отправки сегментов Йу зависеть от пропускной способности самого медленного канала. Можно с зать, что протокол TCP автоматически определяет узкое место в сети и ре, лирует свой поток. Этот процесс называется самосинхронизацией (self-clockii В общем, наилучший способ повышения производительности — устранен узких мест в сети.
Пропускная способность TCP
Рассмотрим методы определения максимально возможной пропускной споо ности в соединении протокола TCP. Пропускная способность зависит от раз ра окна отправки, задержки и скорости передачи данных. Используем след щие обозначения:
W — размер окна отправки в байтах;..
R — скорость передачи данных (бит/с) по определенному соединению,) тупная на стороне отправителя;
D — задержка (в секундах) при передаче данных между отправителем и лучателем через определенное соединение.
Предположим, что отправитель начинает передавать последовательность б; получателю через установленное соединение. Для того чтобы первый байт д получателя, потребуется время, равное D секундам. Такое же время — D сек) понадобится для получения подтверждения. В течение этого промежутка
может передать 2 RD битов, или RD/4 байтов. Но отправитель ограничен , , м окна в W байтов и не может сдвигать окно, пока не получит подтвер- ' е Только при W>RD/4 на этом соединении достигается максимально возмож- ■ ^пропускная способность. Если W<RD/4, то близость пропускной способности максимальной определяется отношением W к RD/4. Следовательно, нормированная пропускная способность 5 может быть выражена как:
1, если W > RD/4
4W
—, если W < RD/4.
RD'
На рис. 5.11 представлен пример определения максимальной пропускной способности в зависимости от произведения RD.
Рис. 5.11. Определение максимальной пропускной способности
: Максимальный размер окна может составлять 216 - 1 = 65 535 байт (поле «Окно» (Window) имеет длину 16 бит). Такой ширины окна достаточно для большинства приложений. В качестве примера рассмотрим три различные тех-
. Д°Догии, применяемые для передачи сегментов TCP и использующие означен- г размер окна. Для технологии Gigabit Ethernet с длиной магистрали, равной {0 м, произведение RD будет меньше, чем 103 бит. На больших расстояниях,
пусть даже при более низких скоростях, например в случае использования кана-
I ^Tl (1,5 Мбит/с), произведение RD увеличивается, следовательно, эффектив- I ЙОсть падает. Тем не менее она остается приемлемой — около 0,8. На значительных I ДИстанциях при дальнейшем увеличении скорости (допустим, речь идет о пере- I Даче информации с использованием технологии SDH — канал 155 Мбит/с меж-
Двумя городами) рассматриваемая технология становится крайне неэффек- ■рвной — нормированная пропускная способность падает до 0,1. Очевидно, что
в данном случае размер окна слишком мал. Необходимо другое значения раметра масштабирования окна, которое позволило бы эффективно задейя вать пропускную способность канала. Достаточно увеличить этот параметр! на 4 единицы, и окно будет значительно увеличено — 220 - 1 * 10° байт. J Рассматривая взаимное влияние параметров, можно получить представли о потенциале протокола TCP по повышению производительности. Однако суця вует множество усложняющих факторов, которые следует принять во вниму Во-первых, в большинстве случаев некоторое количество соединений TCP муя плсксируются через один канал, так что каждое соединение получает только 'а доступной пропускной способности канала. Это приводит к снижению скора передачи R и, следовательно, к снижению эффективности работы протоед Во-вторых, множество соединений TCP будет проходить через определенное м честно маршрутизаторов. Тогда время D будет равно сумме задержек в каж сети плюс сумма задержек на каждом маршрутизаторе в отдельности. При а суммарная задержка на маршрутизаторах часто бывает наибольшей составляв общего времени D, особенно в случаях возникновения перегрузок. В-трей значение скорости R, используемое в приведенной выше формуле, опреде®
скорость передачи данных, доступную для этого соединения, только на стоя отправителя. Если эта скорость передачи данных больше, чем скорость на од из переходов в пути от отправителя до получателя, то попытка передачи на мм мальной скорости приведет к образованию узкого места, что неизбежно увели время D. И, наконец, в-четвертых, если любой сегмент будет потерян, то он» жен быть передан вновь, откуда вытекает снижение пропускной способна Влияние потерянных сегментов определяется политикой повторных переда® Для повышения производительности в сетях, для которых характерны Я шие задержки, в операционную систему Microsoft Windows 2000 введен ад ритм масштабирования окна (TCP Receive Window Size Calculation and Wir® Scaling). Этот алгоритм описан в разделе 2.2 документа RFC 1323. При исполЕ
вании параметра масштабирования окна количество байтов данных, определяем полем «Окно», становится кратным 2F, где F — значение параметра масштаб рования окна. Максимальная величина F, которая используется протоколом Т(
равна 14. Следует отметить, что этот алгоритм включается только на время и)
циирования соединения..
В операционной системе Microsoft Windows NT размер окна приема мс возрастать на величину, кратную максимальному размеру сегмента (Maxit
Segment Size — MSS). Размер MSS определяется во время установления нения. По умолчанию окно приема имеет размер 8 Кбайт для Windows
и 16 Кбайт для Windows 2000. Ширина окна устанавливается в реестре оп<
ционной системы параметром TcpWindowSize (табл. 5.10).
Таблица 5.10. Параметр реестра TcpWindowSize
Название параметра
TcpWindowSize...
Ключ в реестре
Tcpip\Parameters, Tcpip\Parameters\Interface\^
Тип записи
REG_DWORD’
Диапазон значений
0-0X3FFFFFFF (1 073 741 823)J
екная способность TCPекная способность TCP
екная способность TCP
екная способность TCP
сетях Ethernet размер окна обычно равен 8760 байт (8192 байт, разме- = - те в 6 сегментах по 1460 байт каждый) для Microsoft Windows NT 4.0 520 байт (16 Кбайт, размещенные в 12 сегментах по 1460 байт) для Microsoft Windows 2000.
' Для операционной системы Microsoft Windows 2000 ширина окна рассчиты- (вается следующим образом: первый запрос на установление соединения, посылаемый удаленному абоненту, регламентирует значение 16 Кбайт (16 384 байт) । данных. После установления соединения размер окна приема округляется до •объема данных, кратного максимальному размеру сегмента (MSS), который был Оговорен в процессе установления соединения. Если размер окна приема опре- ■ иделяет объем данных, близкий к четырехкратному значению MSS, то окно выравнивается до значения 4xMSS. Этот размер окна сохраняется до тех пор, пока . не будет включен алгоритм масштабирования окна.
Анализируя результаты перехвата информации в процессе установления со- “ единения протокола TCP при включенной поддержке алгоритма масштабирования окна, следует иметь в виду, что рекламируемые размеры окон должны быть кратны параметру масштабирования. Этот параметр появляется только в первых двух сегментах при установлении соединения. Например, для размера окна, ' равного 65 535, при параметре масштабирования 3 актуальный размер окна бу, дет составлять 524 280 (или 23 х 65 535). В приведенном ниже примере показан фрагмент перехвата сегмента, который содержит параметры, относящиеся к ра- 1 боте алгоритма масштабирования окна.
+ TCP: Flags = 0x02 : ....5.
TCP: Window = 65535 (OxFFFF)
TCP: Checksum = 0x8565
TCP: Urgent Pointer = 0 (0x0) TCP: Options
+ TCP: Maximum Segment Size Option TCP: Option Nop = 1 (0x1)
■TCP: Window Scale Option
.TCP: Option Type = Window Scale
TCP: Option Length = 3 (0x3)
TCP: Window Scale = 5 (0x5)
,TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
+ TCP: Timestamps Option
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
•^+ TCP: SACK Permitted Option.
i
3^ ® операционной системе Microsoft Windows 2000 окно масштабируется авто- ^^ТИчески, если параметр реестра TcpWindowSize установлен в значение, превы- gnWHiee 64 Кбайт. Масштабирование окна можно запретить вручную парамет- Tcpi3230pts (табл. 5.11).
Таблица 5.11. Параметр реестра Tcpl3230pts
Название параметра
Tcpl3230pts
Ключ в реестре
Tcpip\Parameters
/ 3
Тип записи
REG_DWORD
Возможные значения
0, 1, 2, 3
Значение по умолчанию
3
5
Работать с окном, превышающим 64 Кбайт, можно только с абонентом, к$» рый поддерживает эту опцию. Значение по умолчанию устанавливается как ™ меньшее из следующих: OxFFFF, значение дополнительного параметра рееёЯ GlobalMaxTcpWindowSize, максимум из 4xMSS и числа 16 384, выравненного® значения, кратного размеру поля данных протокола TCP. Значение по умолчаии для сети Ethernet составляет 17 520 байт (в реализации TCP для операционщ системы Microsoft Windows 2000), но может быть немного сокращено, еслй'й единение установлено с абонентом, который поддерживает алгоритмы SAS и временные отметки, так как они увеличивают размер заголовка протоколами сверх обычного (20 байт), оставляя меньше места для данных.'&
Следует отметить, что данный параметр является одновременно и глобад ным параметром. Он устанавливается на каждом интерфейсе в отдельности в | висимости от того, где расположен ключ реестра. Если это значение для onpga ленного интерфейса, то оно перекрывает значение для всей системы. ,^
Параметр Tcpl3230pts может иметь следующие значения:
О0 — запретить использование опций RFC 1323,о,
О 1 — разрешено только масштабирование окна;■ :
0 2 — разрешено использовать только временные штампы;
0 3 — разрешено использовать обе опции.
Изменение размера окна на маршрутизаторе
По умолчанию размер окна протокола TCP составляет 2144 байт. В докуме тации на операционную систему Cisco IOS дана рекомендация не менять Э" значение, до тех пор пока не будет выяснено, что маршрутизатор посылает пай ты данных, размер которых превышает 536 байт. Для изменения размера ок! следует воспользоваться командой ip tcp window-size, выполняемой в глобальНС режиме, а в качестве параметра указать новый размер окна в байтах. г-
Управление потоком
Управление потоком основано на механизме плавающего окна, но кроме эт использует более гибкую схему приема и передачи данных и отправки подтве] дений успешного их приема. Управление потоком осуществляется в соответсп со схемой, устанавливающей предельную норму выделения готового к отпра
уиравлениепотокомуиравлениепотокомсива данных. Согласно этой схеме, каждый индивидуальный передаваемый имеет свой собственный номер в последовательности. Когда протокол TCP ссылает сегмент, он выставляет в поле номера номер первого байта в последо- уательности байтов, размещаемых в поле данных этого сегмента. На стороне по- ■учателя поступивший сегмент подтверждается сообщением, имеющим форму ,. = г; VP = у). Такая запись обозначает следующее: подтверждается получение всех байтов, вплоть до номера (г - 1); следующие ожидаемые байты для приема имеют номер в последовательности г. Кроме того, выдается разрешение на посылку дополнительного окна W (Window — окно) из у данных, где байты данных соответствуют номерам в последовательности от г вплоть до г +у - 1. Рисунок 5.12 иллюстрирует работу этого механизма.
уиравлениепотоком
уиравлениепотоком
Станция АСтанция А...1000...10001001 . ■ ■ ■ 2400 2401...1001 . ■ ■ ■ 2400 2401......1000...100010012400 2401...10012400 2401...А может послать 1400 байтА может послать 1400 байтSN=1001::SN=1201~^' в готовится к получению 1400 байт,**■начиная с 1001SN=1001::SN=1201~^' в готовится к получению 1400 байт,**■начиная с 1001SN=1401SN=1401. ...1000. ...10001001 16012401...1001 16012401...А сокращает окно с каждой передачейА сокращает окно с каждой передачейА=1601, ———W=1000...1600А=1601, ———W=1000...1600...1000...1000100110012001 2401...2001 2401...SN=1601SN=1601SN=1801SN=18011601:1601:2601...2601...Б подтверждает получение 3 сегментов(600 байт) но он готов получить только200 дополнительных байтов свышеначального лимита. То есть Б будет4 получать байты с 1601 по 2600Б подтверждает получение 3 сегментов(600 байт) но он готов получить только200 дополнительных байтов свышеначального лимита. То есть Б будет4 получать байты с 1601 по 2600...1600...16001601 2001 2601...1601 2001 2601...А выравнивает окнос каждым полученнымлимитирующим сообщениемА выравнивает окнос каждым полученнымлимитирующим сообщением...1600...16001601 26001601 26002601...2601...SN=2001 ...1600SN=220bKSN=240b*.SN=2001 ...1600SN=220bKSN=240b*.16011601200120012601...2601...А исчерпывает свой лимитА исчерпывает свой лимит/. ..2600А=2601,W=1400/. ..2600А=2601,W=1400260126014000 4001...4000 4001......2600...2600260126014000 4001...4000 4001...Б подтверждает получение 5 сегментов(1000 байт) и восстанавливаетначальный объем лимитаБ подтверждает получение 5 сегментов(1000 байт) и восстанавливаетначальный объем лимитаСтанция Б
Станция А
Станция А
...1000
...1000
1001 . ■ ■ ■ 2400 2401...
1001 . ■ ■ ■ 2400 2401...
...1000
...1000
10012400 2401...
10012400 2401...
А может послать 1400 байт
А может послать 1400 байт
SN=1001::
SN=1201~^' в готовится к получению 1400 байт,
**■начиная с 1001
SN=1001::
SN=1201~^' в готовится к получению 1400 байт,
**■начиная с 1001
SN=1401
SN=1401
. ...1000
. ...1000
1001 16012401...
1001 16012401...
А сокращает окно с каждой передачей
А сокращает окно с каждой передачей
А=1601, ———
W=1000...1600
А=1601, ———
W=1000...1600
...1000
...1000
1001
1001
2001 2401...
2001 2401...
SN=1601
SN=1601
SN=1801
SN=1801
1601:
1601:
2601...
2601...
Б подтверждает получение 3 сегментов(600 байт) но он готов получить только200 дополнительных байтов свышеначального лимита. То есть Б будет
4 получать байты с 1601 по 2600
Б подтверждает получение 3 сегментов(600 байт) но он готов получить только200 дополнительных байтов свышеначального лимита. То есть Б будет
4 получать байты с 1601 по 2600
...1600
...1600
1601 2001 2601...
1601 2001 2601...
А выравнивает окнос каждым полученнымлимитирующим сообщением
А выравнивает окнос каждым полученнымлимитирующим сообщением
...1600
...1600
1601 2600
1601 2600
2601...
2601...
SN=2001 ...1600
SN=220bK
SN=240b*.
SN=2001 ...1600
SN=220bK
SN=240b*.
1601
1601
2001
2001
2601...
2601...
А исчерпывает свой лимит
А исчерпывает свой лимит
/. ..2600
А=2601,
W=1400
/. ..2600
А=2601,
W=1400
2601
2601
4000 4001...
4000 4001...
...2600
...2600
2601
2601
4000 4001...
4000 4001...
Б подтверждает получение 5 сегментов(1000 байт) и восстанавливаетначальный объем лимита
Б подтверждает получение 5 сегментов(1000 байт) и восстанавливаетначальный объем лимита
А получает новый лимит
Рис. 5.12. Схема управления потоком
Для большей наглядности покажем поток данных, идущий только в одном Вправлении, и предположим, что в каждом сегменте посылается 200 байт данных. а вРемя установления соединения номера в последовательностях отправителя -Получателя синхронизированы и станция А работает, исходя из начального ^мита, равного 1400 байт, начиная с номера байта 1001. После посылки 600 байт i^Pex сегментах станция А уменьшает свое окно отправки до размера 800 байт ^омера от 1601 до 2400). После получения этого сегмента станция Б подтвер-
ждает доставку всех байтов вплоть до 1601-го байта и формирует свое гп® венное окно приема на 1000 байт. Это означает, что станция А может посым байты начиная с номера 1601 по номер 2600, то есть в сумме 5 сегментов. Oai ко к моменту времени, когда сообщение от станции Б доходит до станпиЗ станция А уже успевает выслать два сегмента, содержащие байты с номепя от 1601 до 2000, что было разрешено во время начального назначения Ы дельной нормы. Следовательно, оставшийся резерв станции А на этот момй составляет всего 400 байт или два сегмента. В процессе обмена станция А<* двигает конечную (левую) границу своего окна каждый раз, когда перепЬ сегмент, и смещает начальную (правую) границу окна только тогда, когда пш чает новую предельную норму.
На практике обе стороны одновременно задействуют режимы передачи и пт ема, так как данные могут передаваться в обоих направлениях (режим полито плексной передачи). Механизм выделения лимита достаточно гибок. Наприм рассмотрим ситуацию, когда заключительное сообщение, посланное станцией было: А = г, W = j. Последним байтом данных, полученным станцией Б, ст байт с номером i - 1. В результате для увеличения лимита до значения к, ф@ выполняется условие к > j и еще не поступили дополнительные данные, ст^ ция Б формирует сообщение (А = z, W = к), а для подтверждения входяцм сегмента, содержащего т байтов данных (т <у), без получения дополнителы го лимита станция Б формирует сообщение (А = i + т, W = j - m).
Следует отметить, что от получателя не требуется немедленного подтвержу ния приходящих сегментов — он может ожидать какое-то время, формируя об( щепное подтверждение для некоторого итогового их количества. Получатб должен подчиняться определенной политике, регулирующей объем входн: данных, который он сам позволяет передавать отправителю. Можно выдел! две схемы поведения получателя: консервативную и оптимистическую. Кона вативная схема управления потоком основана на том, что предельная норма в деляется исходя из фактического значения свободного буферного пространен Если это правило применить к ситуации, показанной на рис. 5.12, то первое 3, митирующее сообщение говорит о том, что станция Б готова разместить в сво буфере 1000 байт, а второе — о том, что станция Б в состоянии размести 1400 байт. Консервативная схема управления потоком может ограничить про^ скную способность логического соединения в ситуациях, когда в сети возн$ ют длительные задержки..4
Получатель может увеличивать пропускную способность с помощью оп^ мистического выделения лимита на свободное буферное пространство, которс он на данный момент не имеет. Например, если буфер получателя заполнен, он ожидает, что сумеет освободить 1000 байт буферного пространства за вре прохождения информации между конечными точками соединения, то ош* жет немедленно выделить лимит в 1000 байт. Если получатель в сила»да держивать скорость, заданную отправителем, то такая схема способна повь^ пропускную способность и не принесет вреда. Если же отправитель раей^ быстрее получателя, то некоторые сегменты будут отбрасываться из-за>з®1 тости буфера, что повлечет за собой повторную передачу. А так как пая передача является необходимым атрибутом надежного сетевого серЯ
оптимистическое управление потоком при таком развитии событий может повысить загрузку сети.
Получатель всегда старается увеличить окно приема, если имеет свободное буферное пространство. Отправитель также стремится расширить окно отправки при малейшей возможности и на любую величину. В такой ситуации говорить о стабильном потоке сегментов не приходится. Для того чтобы уберечь отправителя и получателя от соблазна «втиснуть» в канал лишний сегмент, используется алгоритм предотвращения «синдрома глупого окна» (Silly Window Syndrome — SWS). Этот алгоритм описан в RFC 1122. Большой объем данных не отправляется до тех пор, пока получатель не объявит размер окна, достаточный для посылки полного сегмента, или не будет выполнена настройка, запрещающая увеличить окно приема меньше чем на сегмент.
Стратегии отправления и приема данных
При отсутствии данных, помеченных флагом PSH, протокол TCP на стороне отправителя имеет возможность самостоятельно назначать время передачи. Когда данные передаются модулю протокола TCP пользовательским приложением, они записываются в буфер для передачи. Протокол TCP может создавать сегмент для каждой группы поступивших от приложения данных или ожидать накопления большого объема данных, и только после этого формировать и от- ■ правлять сегмент. Актуальность политики отправления всецело зависит от тре, бований к производительности. Если передачи сегментов происходят редко, но [ ,при этом переносятся большие объемы данных, то такая схема вносит неболь- • шие накладные расходы при создании сегмента и его обработке. Если же пере- J дачи происходят часто, а объем передаваемых данных невелик, то такая система 1 обеспечивает быструю реакцию на изменения состояния сети.
' При отсутствии данных, помеченных флагом PSH, протокол TCP на стороне । получателя также может самостоятельно определять время доставки данных ; пользовательскому приложению. Так, он может доставлять данные последова- I тельно при получении каждого сегмента или заносить данные из нескольких ! сегментов в буфер приема. Как и в предыдущем варианте, реальная политика | Доставки будет зависеть от требований к производительности. Если данные приходят редко и имеют большие объемы, то приложение не получит их сразу. Ьсли данные поступают часто и малыми порциями, следует ожидать избыточной обработки информации в протоколе TCP и в приложении.
. Когда сегменты поступают в порядке их отправки по установленному соедиНению, протокол TCP помещает данные в буфер получения для доставки поль- • ЗОвательскому приложению. Вполне возможна ситуация, когда определенный | сегмент поступает не в порядке отправления. В этом случае протокол TCP на I стороне получателя может либо принимать только сегменты, которые приходят 1 в Порядке отправления (другие сегменты просто отбрасываются), либо прини- 6 ^нть все сегменты, номера которых зафиксированы в окне приема (вне зависи- ВМости от порядка получения).
Первый вариант действий упрощает реализацию протокола, но при: возникают излишние накладные расходы на сеть, так как отправитель^ ожидать некоторое время, а затем повторно передаст отброшенные сегм, которые были успешно получены, но затем были отброшены из-за некорре го порядка поступления. Более того, если один сегмент был потерян при пё че, все последующие сегменты необходимо посылать повторно. Во втором ■ анте может быть снижено количество повторных передач, но при этом треб' более сложный алгоритм приема и более запутанная схема сохранения д4 для буферизации и отслеживания порядка принятия данных.1
Протокол TCP поддерживает очередь сегментов, которые были послан еще не были подтверждены. Спецификация протокола говорит о том, ч' будет повторно передавать сегмент, на который не поступило подтвержд в определенный период времени. Реализация протокола TCP поддерживает стратегии повторной передачи.
О Только первый. Используется один таймер повторной передачи дл; очереди. Если получено подтверждение, удаляется первый сегмент из о ди повторной передачи и сбрасывается таймер. Если время таймера ист< повторно передается сегмент из начала очереди и таймер сбрасывается,;
О Пакетная. Поддерживается один таймер повторной передачи для всей р ди. Если получено подтверждение, удаляются все сегменты из очеред; вторной передачи и сбрасывается таймер. Если время таймера истекав вторно передаются все сегменты из очереди и таймер сбрасывается, чк
О Индивидуальная. Поддерживается один таймер для каждого сегмента’! реди. Если получено подтверждение, удаляется первый сегмент из очи повторной передачи и обнуляется соответствующий таймер. Если под к концу время любого таймера, то повторно индивидуально передаетсй ветствующий сегмент и его таймер сбрасывается.п
Первая стратегия повышает эффективность передачи трафика, так как.
ко потерянный сегмент (или сегменты, подтверждения которых были пО ны) передаются повторно. Но из-за того что таймер для второго сегмента^ реди не устанавливается до тех пор, пока не подтвержден первый сегменту i возникать некоторые задержки. Индивидуальная стратегия решает э^ блемы за счет более сложной реализации. Пакетный режим также снижа! роятность длительных задержек, но может привести к ненужным повтО] передачам.р
Реальная эффективность политики повторной передачи зависит отг тики приема сегментов на стороне получателя. Если получатель реализ^ литику приема, в соответствии с которой принимаются только сегменть^ дующие в порядке отправления, то он будет отбрасывать сегменты, полу^ после потерянного сегмента. Такая схема работы хорошо подходит К?$ ной стратегии. Если получатель принимает все сегменты несмотря H^/J док их прибытия, то оптимальными являются стратегии «только первый индивидуальная.
На стороне получателя при поступлении сегмента протокол TCP может выбирать время отправки подтверждения двумя способами.
О Немедленно. Как только данные с определенным номером в последовательности приняты, немедленно передается пустой (без данных) сегмент, содержащий соответствующий номер подтверждения.
Q С накоплением. Когда данные успешно приняты, отмечается необходимость в их подтверждении, но ожидается очередной выходящий сегмент с данными, в котором установлен флаг АСК. Во избежание длительных задержек устанавливается таймер окна. Если время таймера истекает до момента отправки очередного сегмента с подтверждением, то посылается пустой сегмент, содержащий соответствующий номер подтверждения.
Первый вариант прост в реализации и обеспечивает полную информированность протокола TCP на отправляющей стороне, что ограничивает ненужные повторные передачи. Однако такой подход приводит к дополнительным передачам пустых сегментов, использующихся только для подтверждения. Более того, он повышает загрузку сети. Вполне возможна, например, ситуация, когда протокол TCP на принимающей стороне получает сегмент и немедленно посылает подтверждение. А само приложение вдруг расширяет свое окно приема, вызы
вая тем самым посылку еще одного пустого сегмента для предоставления дополнительного лимита отправляющей стороне. Поскольку эта стратегия сопровождается накладными расходами, обычно используется режим работы с накоплением. Следует отметить, что последний приводит к увеличению загрузки на стороне получателя и усложняет задачу отправителя по оценке времени обращения.
Рассмотрим два расширения протокола TCP, реализованные в Window 2000.
Выборочное подтверждение SACK
Это расширение сравнительно недавно утвердила организация IETF (Internet
Engineering Task Force — http://www.ietf.org) (RFC 2018). Оно позволяет подтвер- L Ждать прием данных не в порядке их поступления, как это было раньше, а выбо- I" рочно. Данный подход имеет два главных преимущества. Во-первых, повышается '. эффективность повторной передачи сегментов TCP благодаря сокращению време- : ни на саму процедуру. Протокол TCP использует алгоритм повторной передачи, 1 опираясь на информацию, извлекаемую из упорядоченных подтверждений. Такой ■ подход вполне приемлем, однако в случае его применения на восстановление
каждого потерянного сегмента уходит примерно один цикл обращения. SACK ■ (Selective Acknowledgments — выборочное подтверждение) позволяет осущест- влять повторную передачу сразу нескольких потерянных сегментов в одном Пикле. Во-вторых, благодаря выборочным подтверждениям протокол TCP точ- 8ее оценивает доступную ширину полосы пропускания в условиях нескольких L ПослеДовательных потерь сегментов и способен обойтись без алгоритма медлен- I його старта. SACK играет важную роль для соединений, использующих большой Вфазмер окна TCP. Когда работает SACK (а этот режим включен по умолча- ^^Ию), при потере сегмента или серии сегментов получатель имеет возможность
точно информировать отправителя о том, какие данные были получены усп( но, и указывает на «прореху» в потоке сегментов. Отправитель может теп! выборочно повторить передачу потерянных сегментов и не передавать весь 6j данных. Ниже показан пример работы механизма SACK.
TCP: Source Port = OxO4DA
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 925104 (OxElDBO)
TCP: Acknowledgement Number = 54857341 (Ox345OE7D)J
{Подтверждение получения данных до номера в последовательности 54857341}1
TCP: Optionsj
TCP: Option Nop = 1 (0x1)I
TCP: Option Nop = 1 (0x1)1
+ TCP:Timestamps Option1
TCP: Option Nop = 1 (0x1)
TCP:Option Nop = 1(0x1)j
TCP:SACK Option1
TCP: Option Type= 0x055
TCP: Option Length = 10 (OxA)1
TCP: Left Edge of Block = 54858789 (0x3451425)J
TCP: Right Edge of Block = 54861685 (0x3451F75)J
{Указание на успешно принятые номера в последовательности данныхJ
54858789-54861685}j
В примере показан фрагмент перехвата сетевого монитора (Microsoft Netwi Monitor). Видно, что подтверждено получение данных до номера в последа дельности 54857341, плюс получение данных с номерами в последователь^ сти от 54858789 до 54861685. Данные с номерами от 54857341 до 5485878^ подтверждены. Таким образом, SACK указывает на то, что данные с номера от 54857341 до 54858789 были пропущены и отправителю следует повторить,’ передачу. В реестре Windows 2000 существует параметр SackOpts (табл. 5.1 с помощью которого можно активизировать работу выборочного подтвержден)
Таблица 5.12. Параметр реестра SackOpts
Название параметра Ключ в реестре Тип записи
SackOpts
Tcpip\Parameters;
REG_DWORD
Диапазон значений
0,1 (False, True)
Значение по умолчанию
1 (True)
Операционная система Cisco IOS поддерживает механизм выборочного п тверждения, который включается командой ip tcp selective-ack, выполняемой в г, бальном режиме. Другой возможностью выборочного подтверждения являе'
поддержки временных отметок TCP. Однако следует отметить, что при задействовании механизма сжатия заголовков TCP последние должны быть отключены Это также касается и алгоритма SACK. Для включения механизма временных отметок следует воспользоваться командой ip tcp timestamp, выполняемой в глобальном режиме. Временные отметки и SACK на маршрутизаторах компании Cisco Cystems по умолчанию неактивны (отключены).
Задержанное подтверждение
В соответствии с этим алгоритмом, подтверждения высылаются, если не посылалось подтверждение на предыдущий принятый сегмент и если после принятия сегмента в течение 200 мс не зарегистрирован следующий. Значение таймера отложенных подтверждений можно устанавливать в реестре посредством параметра TcpDelAckTicks (табл. 5.13), который был впервые введен в пакете обновлений 4 (Service Pack 4) для операционной системы Microsoft Windows NT 4.0.
Таблица 5.13. Параметр реестра TcpDelAckTicks
Название параметра
TcpDelAckTicks
Ключ в реестре Тип записи
Tcpip\Parameters\Interfaces\<interface> REG_DWORD
Диапазон значений
0-6
Значение по умолчанию
2(200 миллисекунд)
Значение данного параметра может меняться от 0 до 6 с шагом 100 мс, то есть максимальное время таймера — 600 мс. Установка параметра в 0 запрещает задерживать подтверждения, что приводит к немедленной отправке подтверждений для каждого полученного сегмента.
Таймер повторной передачи
Протокол TCP не формирует явных негативных подтверждений, то есть подтверждений, явно указывающих на произошедшие нарушения. Вместо этого протокол полагается исключительно на положительные подтверждения и на повторную передачу в случаях, когда подтверждение не поступает в течение опре- Деленного интервала времени. К повторной передаче сегмента могут привести Два события.
И Сегмент испорчен при передаче, но тем не менее доставлен получателю. Контрольная сумма, включенная в заголовок, позволяет получателю обнаружить ошибку и отбросить такой сегмент.
Сегмент просто не поступает.
Ri рг
в том и в другом случае посылающая сторона просто не знает о том, что Илка сегмента была неуспешной.
Если на принимающей стороне обнаруживаются ошибки при приеме мента либо он не принимается вовсе, то при этом не формируется и не и лается АСК (подтверждение). В этом случае потребуется повторная пере сегмента. Для принятия решения о времени повторной передачи исполы ся таймер, работающий с каждым посланным сегментом. Если время тай истекает до момента получения АСК для этого сегмента, отправитель да выполнить повторную передачу. Важным параметром в протоколе TCP явля регулируемое время этого таймера. Если значение тайм-аута будет слЙЙ малым, то часто будут осуществляться ненужные повторные передачи, ум шающие полосу пропускания сети. Если это значение будет чересчур $ шим, то работа протокола станет очень инертной при потере сегмента. Ну задать значение времени, немного большее, чем время обращения (RTT, Ra Trip Time).
Существуют два способа определения интервала повторной передачи. В" вом случае используется фиксированное значение, основанное на статист ских данных, характерных для обычного поведения распределенной се^ есть значение, ненамного превышающее среднее значение RTT. Такая страт не способна адекватно и гибко реагировать на резкие изменения в условия боты сети. Как уже отмечалось, если значение таймера слишком велико, рй протокола будет инертной, а если это значение мало, то может сложиться ев ция, при которой перегрузка в сети приведет к повторным передачам, что, больше увеличит перегрузку.
Второй способ — адаптивная схема работы, которая также имеет достойв и недостатки. Предположим, что протокол TCP постоянно отслеживает aj получения подтверждений на посланные сегменты и устанавливает свой тай основываясь па наблюдаемой задержке. Это значение не может полностью ^ летворять всю совокупность требований к транспортному протоколу по слё^ шим причинам: посылка сегмента не обязательно подтверждается немедле: если сегмент был послан повторно; отправителю неоткуда знать, какой сег^ подтверждается полученным АСК — отправленный впервые или еще раз; у вия в сети могут внезапно измениться. Эта проблема не имеет полного рейг^ Всегда будет существовать некоторая неуверенность в оптимальности уста; ки таймера повторной передачи.11
Если происходят какие-либо изменения в поведении сети, велика вёр ность того, что статический таймер повторной передачи неадекватно отрё рует на эти изменения: его значение будет либо слишком мало, либо Сл ком велико. Поэтому все реализации протокола TCP проводят оценку теку! времени передачи, которая осуществляется в процессе наблюдения за хй] тером изменения задержки последних посланных сегментов. Затем уста! ливается значение, которое немного превышает полученную оценку врем передачи..’ '
Рассмотрим один из подходов, который учитывает среднее наблюдаемое^ мя для некоторого количества посланных сегментов. Если это среднее BJ . достаточно точно предсказывает будущие задержки, то соответствующее 3$
г
■ ние таймера повторной передачи приведет к очень хорошей производительности. Усредненное время можно определить, используя следующее выражение:
ARTT(K + I) = —[—YRTT(i),
Л +1 i=l
где RTT(i) — время обращения, наблюдаемое для г-го переданного сегмента, a ARTT(K) — среднее время обращения для первых К сегментов. Это выражение можно представить в другом виде:
ARTT(K +1) = -^— ARTT(K) + —— RTT(K + 1)К + 1К + 1
Следует учесть, что здесь все параметры имеют равный вес, то есть каждый параметр увеличивается на константу 1/(К+1). Как правило, больший вес, или большая степень доверия, дается более новым, последним результатам измерений, так как они наиболее точно отражают будущее поведение сети. Общий ' метод предсказания следующего усредненного значения времени обращения на основе предыдущей серии измерений времени приведен в документе RFC 793.
' В основе метода лежит формула:.
SRTT(K +1) = а х SRTT(K) + (1 - а) х RTT(K + 1) ,
где SRTT(K) (Smoothed Round-Trip Time) — так называемая усредненная оценка : времени обращения. Можно сравнить это выражение с предыдущим. Используя константу а (0 < а < 1), не зависящую от числа последних наблюдений, получа- ( ем условия, при которых все последние значения наблюдений учитываются, но [ более ранние наблюдения имеют меньший вес. Эту константу называют факто- , ром сглаживания.
i Наименьшее значение константы а дает наибольший вес самым последним , наблюдениям. При а = 0,5 наиболее весомыми становятся 4 или 5 последних наблюдений, в то время как при а = 0,875 средний вес распределяется по вы; борке из 10 и более последних наблюдений. Достоинством именно небольшого значения константы а является то, что при этом отражаются быстрые изменения в наблюдаемых величинах. Недостаток заключается в том, что если происходит • короткое волнообразное изменение в наблюдаемых значениях с последующим ■ переходом к усредненному значению, использование небольшого значения константы а приведет к резким изменениям вычисляемого усредненного времени обращения.
Как уже упоминалось, таймер повторной передачи должен быть установлен в значение, большее чем оцененное время обращения. Для вычисления этого превышения можно использовать формулу:
IRTO(K + 1) = SRTT(K + 1) + Д,
1 где RTO (Retransmission Time Ort) — контрольное время повторной передачи 1 (его иногда называют тайм-аутом повторной передачи), а Д — константа. Не- ■ '-Достаток данного способа вычисления превышения состоит в том, что значение ■ 'А не пропорционально значению SRTT. Для больших значений SRTTконстанта Д
относительно невелика. В этом случае флуктуации фактического значения будут приводить к ненужным повторным передачам. Для небольших же а ний SRTT величина константы Д относительно велика и может вызвать не ные задержки при повторных передачах потерянных сегментов. В связи с документ RFC 793 определяет таймер, пропорциональный SRTT, со следу! ми ограничениями: ...
RTO(K +1) = min(UBOUND, max(LBOUND, 0 х SRTT(K +1))),
где UBOUND и LBOUND — фиксированные верхние и нижние границы а ния таймера, а 0 — константа. Ее называют фактором изменения задержки, кумент RFC 793 не рекомендует применение фиксированных значений, но ; водит диапазон изменений параметров: 0,8-0,9 для а и 1,3-2,0 для 0.
Временные отметки
Для соединений, работающих с окнами большого размера, используется алгор! временных отметок (TCP Timestamps), описанный в документе RFC 1323. Э алгоритм помогает проводить точное измерение времени кругового обраще: (RTT). Такие замеры необходимы для корректировки таймера повторной nepi чи. Алгоритм временных отметок определяет два дополнительных поля: Timesti Value и Timestamp Echo Reply. Протокол TCP может включить поле Timesti Value в любой отправляемый сегмент. Когда подтверждается успешное полз ние этого сегмента, то получатель включает в ответный сегмент поле Timesti Echo Reply с тем же значением, что было в поле Timestamp Value. Это позво. ет протоколу TCP выполнять постоянный мониторинг времени обращения. ..
В операционных системах компании Microsoft вплоть до Windows 2000 п, токол TCP определял значение RTT только для одного сегмента в окне, что корректировать значение RTO. При этом для вычисления RTT протокол от; чал время отправки сегмента и время получения подтверждения об успешна получении этого сегмента. Например, если размер окна составлял 8760 б^ (то есть размер 6 сегментов), то для вычисления значения RTT использова^ только один сегмент. Однако при введении поддержки алгоритма масштаб^ вания окна одного сегмента для всего окна становится недостаточно. Наприме при максимальном размере окна и масштабировании до 1 Гбайт в сети Ethera будет задействоваться только одно измерение для каждых 735 440 сегментов.,
В следующем примере показан фрагмент перехвата сетевого монитора с И лями временных отметок. В операционной системе Microsoft Windows 2000 и
"I"Iпользование временных отметок разрешено по умолчанию.
"I
"I
TCP: Timestamps Option
TCP: Option Type - Timestamps
TCP: Option Length = 10 (OxA)
TCP: Timestamp = 2525186 (0x268802)
TCP: Reply Timestamp = 1823192 (0xlBDlD8)
.ученные отметки.ученные отметкиДля определения количества повторных передач в операционной системе ... rosoft Windows 2000 применяется алгоритм, регламентирующий поведение отокола TCP. Протокол TCP запускает таймер повторной передачи (retrans- ission timer) в момент передачи сегмента протоколу IP. Для новых соединений таймер повторной передачи инициируется со значением 3 с. Показания таймера увеличиваются каждый раз при повторной посылке сегмента на значение указанное в параметре реестра TcpMaxConnectRetransmissions (значение по умолчанию для операционной системы Windows NT 2000 равно 2, а для Windows NT 4.0 — 3). Для действующих соединений количество попыток повторных передач управляется в реестре параметром TcpMaxDataRetransmissions (значение по умолчанию равно 5).
.ученные отметки
.ученные отметки
Для оптимизации параметров соединения таймер повторной передачи может корректироваться «на лету» с использованием SRTT. Используя этот алгоритм, протокол TCP сам настраивается с учетом задержек на данном соединении и других факторов работы сети. Соединения TCP в каналах, имеющих большую задержку, требуют большего интервала повторной передачи, чем в быстрых каналах связи.
ггвремя отправ.получат.прот.Флагиописание0.000 10.57.10.32 10.57.9.138TCP.A..,len: 1460, seq: 8043781. ack8153124. win: 8760 0.521 10.57.10.32 10.57.9.138TCP.A...Ten: 1460. seq: 8043781, ack8153124, win: 87601.001 10.57.10.32 10.57.9.138TCP.A...len: 1460, seq: 8043781. ack8153124. win: 87602.003 10.57.10.32 10.57.9.138TCP.A...len: 1460, seq: 8043781, ack8153124, win: 87604.007 10.57.10.32 10.57.9.138TCP.A...len: 1460. seq: 8043781. ack8153124. win: 87608.130 10.57.10.32 10.57.9.138TCP.A...len; 1460. seq: 8043781, ackвремя отправ.получат.прот.Флагиописание0.000 10.57.10.32 10.57.9.138TCP.A..,len: 1460, seq: 8043781. ack8153124. win: 8760 0.521 10.57.10.32 10.57.9.138TCP.A...Ten: 1460. seq: 8043781, ack8153124, win: 87601.001 10.57.10.32 10.57.9.138TCP.A...len: 1460, seq: 8043781. ack8153124. win: 87602.003 10.57.10.32 10.57.9.138TCP.A...len: 1460, seq: 8043781, ack8153124, win: 87604.007 10.57.10.32 10.57.9.138TCP.A...len: 1460. seq: 8043781. ack8153124. win: 87608.130 10.57.10.32 10.57.9.138TCP.A...len; 1460. seq: 8043781, ack8153124. win: 87608153124. win: 8760Ниже приведен пример работы сетевого монитора с алгоритмом повторной передачи в сети Ethernet.•
г
г
время отправ.получат.
прот.
Флаги
описание
0.000 10.57.10.32 10.57.9.138
TCP
.A..,
len: 1460, seq: 8043781. ack
8153124. win: 8760 0.521 10.57.10.32 10.57.9.138
TCP
.A...
Ten: 1460. seq: 8043781, ack
8153124, win: 8760
1.001 10.57.10.32 10.57.9.138
TCP
.A...
len: 1460, seq: 8043781. ack
8153124. win: 8760
2.003 10.57.10.32 10.57.9.138
TCP
.A...
len: 1460, seq: 8043781, ack
8153124, win: 8760
4.007 10.57.10.32 10.57.9.138
TCP
.A...
len: 1460. seq: 8043781. ack
8153124. win: 8760
8.130 10.57.10.32 10.57.9.138
TCP
.A...
len; 1460. seq: 8043781, ack
время отправ.получат.
прот.
Флаги
описание
0.000 10.57.10.32 10.57.9.138
TCP
.A..,
len: 1460, seq: 8043781. ack
8153124. win: 8760 0.521 10.57.10.32 10.57.9.138
TCP
.A...
Ten: 1460. seq: 8043781, ack
8153124, win: 8760
1.001 10.57.10.32 10.57.9.138
TCP
.A...
len: 1460, seq: 8043781. ack
8153124. win: 8760
2.003 10.57.10.32 10.57.9.138
TCP
.A...
len: 1460, seq: 8043781, ack
8153124, win: 8760
4.007 10.57.10.32 10.57.9.138
TCP
.A...
len: 1460. seq: 8043781. ack
8153124. win: 8760
8.130 10.57.10.32 10.57.9.138
TCP
.A...
len; 1460. seq: 8043781, ack
8153124. win: 8760
8153124. win: 8760
В процессе передачи большого файла по протоколу FTP получатель был отключен от сети. Так как значение SRTT для данного соединения было очень мало (соединение между хостами высокоскоростное по сети Ethernet), то первая повторная передача произойдет примерно через 0,5 с. После этого значение таймера будет удваиваться после каждой повторной передачи. Если после пяти повторных передач не поступает подтверждений, то соединение закрывается.
Контрольное время повторной передачи RTO, которое используется отправителем для повторной передачи потерянного сегмента, на практике может быть ольше, чем реальное время обращения RTT. На величину этой разности могут влиять следующие причины.
■ !■ RTO вычисляется на основе предсказания RTT, которое было спрогнозировано исходя из значения предыдущего RTT. Но если задержки в сети флук- ■ туируют, то спрогнозированное RTT может быть значительно больше, чем 1' Реальное RTT.
Если задержки на стороне получателя изменяются, то и в этом случае а ем крайне неточную оценку RTT./
Получатель не подтверждает каждый сегмент, а формирует подтвержд для множества сегментов и посылает его с ответными данными. При Я поведении получателя невозможно точно определить RTT без привлеч.
ччспециальных методов.
ч
ч
Понятно, что при завышенном НТО в случае потери сегментов прот^г TCP становится инертным при проведении повторной передачи. Если прот на стороне получателя использует правило приема «в порядке отправления может быть потеряно множество сегментов. Даже в более благоприятном; чае, когда получатель принимает все указанные в окне отправления сегме медленная повторная передача также не исключает проблем. ''
Покажем это на примере. Предположим, что станция А передала послед тельность сегментов, и в этой последовательности первый сегмент был пота До тех пор пока окно отправки станции А нс станет нулевым и не истечет вй определяемое КТО, станция А и дальше будет продолжать передавать сегме без подтверждения на ранее отосланные. Станция Б получила все сегмента исключением первого. Но станция Б должна отправлять в буфер все новые i
дящие сегменты, пока не получит копию потерянного сегмента: до поступл^ этой копии она не может отправить данные приложению и тем самым очисл свой буфер. Если повторная передача потерянного сегмента будет по какй причинам задержана, то станция Б после заполнения буфера начнет отбр< вать новые входящие сегменты.
Быстрая повторная передача
Для того чтобы уменьшить негативные последствия описанной выше ситуа! был предложен алгоритм быстрой повторной передачи (Fast Retransmit), к рый повышает производительность при неоптимальном выборе RTO. Бый повторная передача определяет следующие правила работы TCP. Если на! нимающую сторону приходит сегмент не в порядке отправления, то немедля формируются подтверждения для последнего сегмента, поступившего в пор! отправления, и для всех предыдущих. При этом подтверждения для каж. сегмента будут посылаться до тех пор, пока не поступит копия пропущен сегмента. После этого протокол переходит в режим отправки накопленных, тверждений для всех сегментов, полученных в порядке отправления.
Когда отправитель получает двойное подтверждение на один из сегме!. (а это последний сегмент, поступивший в порядке отправления), то он MQ интерпретировать данное событие двояко: либо нарушена последовательно получения (по разным причинам), либо произошла потеря сегмента. В nepi случае сегмент в конечном счете может поступить и, следовательно, не обя тельно спешить с повторной передачей. Но с другой стороны, получение ДВ ного подтверждения отправителем может быть расценено как раннее предун ждепие, говорящее о том, что сегмент потерян и необходимо посылать коп Для окончательного принятия решения о посылке копии отправитель до®
LLРис. 5.13. Быстрая повторная передачаРис. 5.13. Быстрая повторная передача
L
L
Рис. 5.13. Быстрая повторная передача
Рис. 5.13. Быстрая повторная передача
тп
одучить еще три подтверждения на один и тот же сегмент (то есть всего четы- е подтверждения). В этом случае, не дожидаясь срабатывания таймера повторной передачи, отправитель посылает копию потерянного сегмента. Рисунок 5.13 емонстрирует работу алгоритма быстрой повторной передачи.
Станция А посылает последовательность сегментов, каждый из которых включает в себя поле данных размером 200 байт. Предположим, что сегмент 1201 ыл потерян, но станция А не будет реагировать на это событие до тех пор, пока Не пройдет время НТО. Она продолжит посылать новые сегменты, пока не за- кР°ется ее окно отправки. Станция Б получает сегмент 1001 (с байтами от 1001
^0) и высылает подтверждение с номером 1201. Затем она получает сегмент 1 (байты от 1401 до 1600). А так как этот сегмент нарушает последовательность отправки, станция Б повторит посылку подтверждения с номером 1201
Удет высылать подтверждение с этим номером при поступлении каждого ■ °вого сегмента. Так будет продолжаться до получения копии сегмента 1201.
За время, прошедшее между отправкой сегмента 1201 и получением чет» подтверждения с этим же номером, станция А успевает отослать 7 сегм После получения четвертого подтверждения с номером 1201 станция A i ленно повторит последовательность сегментов, начиная с 1201.
По умолчанию в Windows 2000 сегмент посылается повторно, если п маются три подтверждения с одним и тем же номером в последовательна и этот номер отстает от текущего. Управление осуществляется с помптыл г метра TcpMaxDupAcks в реестре операционной системы (табл. 5.14).
Таблица 5.14. Параметр реестра TcpMaxDupAcks
Название параметра
TcpMaxDupAcks
Ключ в реестре
Tcpip\Parameters
Тип записи
REG_DWORD
Диапазон значений
1-3
Значение по умолчанию
2
Этот параметр определяет число двойных подтверждений с одним номе; в последовательности, которые должны быть получены, прежде чем начнём ботать алгоритм быстрой повторной передачи. ' ’
Контроль над перегрузками
Контроль над перегрузками в сетях IP достаточно сложно реализовать по
му ряду причин.
ООО Протокол IP не ориентирован на установление соединения. Он не обесп< вает обнаружение состояния перегрузки и по этой причине не может б использован для контроля над ним.
О
О
Хотя протокол TCP и осуществляет управление потоком, он способен
по косвенным признакам определить перегрузку в сети. Более того, так
задержки в распределенных сетях постоянно изменяются и могут быть ot
большими, то информация,большими, то информация,не является достоверной.не является достоверной.полученная на основании косвенных призна
большими, то информация,
большими, то информация,
не является достоверной.
не является достоверной.
О Не существует распределенного алгоритма для связывания вместе разл протоколов TCP. Протоколы на разных компьютерах не могут взаимодей вовать друг с другом для поддержания определенного уровня общего под Более того, на практике они ведут себя «эгоистично» по отношению к : бодным ресурсам канала.if;
Сообщение «Подавление источника» (Source Quench) протокола ICMP, дует рассматривать в качестве грубого инструмента сдерживания трафик отправителя, но его нельзя причислять к эффективным методам контрол# перегрузками. Администратор сети может возложить задачу контроля над i грузками на протокол RSVP (Resource Reservation Protocol — протокол p вирования ресурсов).
^о/тленный старт^о/тленный стартПротокол RSVP, который описан в документе RFC 2205, является протоко- сигнализации для предоставления гарантированного качества обслужива- ция в распределенной сети. Клиенты используют этот протокол для обеспечения оговоренного уровня обслуживания, того, что в англоязычной литературе называется резервированием (reservations). При отправке запроса целью применения протокола является получение информации о необходимом качестве, функциональность клиентов этого протокола может быть встроена в маршрутизатор вместо использования ее на обычных рабочих станциях. Например, если маршрутизатор отвечает за доставку голосового потока от местной телефонной станции через распределенную IP-сеть, то он может использовать протокол RSVP Для резервирования необходимых ресурсов, гарантирующих успешную доставку трафика реального времени через сеть. В свою очередь, резервирова- . ние ресурсов гарантирует необходимый уровень качества обслуживания для потока информации приложений, называемого сеансом. Сеанс является эквива- дентом обычного потока информации по протоколу TCP/UDP, и он может быть единичной передачей дейтаграмм протокола IP (unicast) или многоадресной передачей (групповой — multicast). При резервировании маршрутизатор : гарантирует, что сеанс получит необходимую пропускную способность и при' оритет в очередях, и он будет защищать эти ресурсы от «посягательства» любых : других, не обслуживаемых сеансов. Если маршрутизатор не в силах обеспечить ’ требуемое для работы сеанса качество обслуживания, он посылает клиенту сообщение об отклонении запроса. Этот клиент может повторить запрос позже, изменить желаемые параметры качества или послать свои данные без предварительного резервирования.
^о/тленный старт
^о/тленный старт
Настраивать протокол RSVP в распределенной сети очень просто. Более ' того, чтобы его настроить, даже не требуется глубокого понимания принципов , его работы. Данный протокол устанавливается на интерфейсе маршрутизатора, а не на маршрутизаторе в целом, что дает определенную гибкость. Для того чтобы настроить протокол, следует выполнить на требуемом интерфейсе команды bandwidth и ip rsvp bandwidth.
Протокол TCP может влиять на загрузку сети, управляя потоком данных ■ с помощью рассмотренных выше методов. Но без принятия специальных мер протоколу сложно поддерживать загрузку каналов связи на оптимальном уровне. Для этого разработаны и используются алгоритмы, предотвращающие воз' никновение перегрузки в сети. Эти алгоритмы применяются практически во , всех современных реализациях протокола. К ним относятся: алгоритмы медленного старта и предотвращения перегрузки (Slow Start Algorithm и Congestion ■ Avoidance, RFC 1122), динамическое изменение окна при перегрузке, быстрая ‘ Повторная передача и быстрое восстановление.
еДленный старт
Казалось бы, чем больший размер окна имеет отправитель, тем больше сегмен- •т°в он может отправить до момента получения очередного подтверждения. Но ^ практике все происходит совсем иначе. В устоявшийся период передачи дан-
ных скорость отправки сегментов регулируется за счет самосинхронизации токола. Гораздо сложнее установить начальную скорость передачи данных i же после установления соединения, правильно выбрать алгоритм ее пов ния, с тем чтобы единовременно не заполнить своими сегментами канал с Решить эту проблему можно двояко. Первый способ состоит в том, что о' витсль начинает посылать данные, имея относительно большой размер отправки, с постепенным увеличением его размеров до такого значения, koi оптимально для стационарного режима этого соединения. При таком под всегда существует определенный риск заполнения распределенной сети мн
ством сегментов еще до того момента времени, когда отправитель поймет, он посылает данные со слишком большой скоростью. Очевидно, что ochoi недостаток этого способа — возможность выбрать слишком широкое нач ное окно отправки. Поэтому второй путь заключается в том, что в начала момент функционирования соединения окно отправки открывается с м: мальным размером, который ни при каких обстоятельствах не вызовет i грузку. «Изюминка» — в способе наращивания размера окна отсылки. Им для этого используется медленный старт. Здесь окно называется окном пере) ки, которое измеряется не в байтах, а в количестве сегментов. В любой мо: времени скорость передачи данных по протоколу TCP определяется следую.
соотношением:
AWND = MIN[CREDIT, CWND],
где AWND — разрешенный размер окна отправки в сегментах. Иначе говоря количество сегментов, которое разрешено послать по протоколу TCP на дан? момент без получения подтверждений успешного приема этих сегментов; *
CREDIT — имеющийся па данный момент резерв отправки сегментов, к рый был выдан в самых последних подтверждениях;
CWND — размер окна перегрузки в сегментах. Это окно используется пр колом TCP в начальный период работы и позволяет снизить скорость пер^ данных при наступлении перегрузки.
При создании нового соединения TCP устанавливает размер окна neper ки (CWND) в единицу. Это означает, что отправитель может послать тол один сегмент, а затем должен ожидать подтверждения его успешного при и только после его получения вправе послать следующий сегмент. Каж раз, когда поступает подтверждение, окно CWND расширяется на един) Это происходит до тех пор, пока размер этого окна не достигнет максимальн значения.
В результате медленный старт гарантирует, что не будет послано слиш много сегментов в распределенную сеть, даже если последняя работает на) деле своих возможностей. Ведь только по мере прибытия подтверждении от) витель расширяет свое окно отправки. Таким образом, можно сказать, что 1 принимает в расчет загруженность канала связи. ”
Выше изложен теоретический ход событий. Правильнее было бы наз этот процесс экспоненциальным стартом, так как размер окна CWND н® мом деле нарастает ио экспоненте. Когда прибывает первое подтвержде протокол TCP увеличивает размер окна CWND в два раза и посылает
а сегмента. После этого окно CWND инкрементируется для каждого прихо- тиего подтверждения. Следовательно, после получения подтверждения на два оследних отосланных сегмента отправитель может послать уже 4 сегмента. После того как на эти 4 сегмента поступят подтверждения, протокол может послать 8 сегментов и т. д. На рис. 5.14 показан пример работы алгоритма мед
ленного старта.
Станция БСтанция БCWND = 1CWND = 1CWND = 2CWND = 2CWND = 3CWND = 4CWND = 3CWND = 4CWND = 5CWND = 6CWND = 7CWND = 8CWND = 5CWND = 6CWND = 7CWND = 8CWND = 9CWND = 10CWND = 11CWND = 12CWND = 13CWND = 14CWND = 15CWND = 16CWND = 9CWND = 10CWND = 11CWND = 12CWND = 13CWND = 14CWND = 15CWND = 16Рис. 5.14. Медленный стартРис. 5.14. Медленный стартСтанция А
Станция Б
Станция Б
CWND = 1
CWND = 1
CWND = 2
CWND = 2
CWND = 3
CWND = 4
CWND = 3
CWND = 4
CWND = 5
CWND = 6
CWND = 7
CWND = 8
CWND = 5
CWND = 6
CWND = 7
CWND = 8
CWND = 9
CWND = 10
CWND = 11
CWND = 12
CWND = 13
CWND = 14
CWND = 15
CWND = 16
CWND = 9
CWND = 10
CWND = 11
CWND = 12
CWND = 13
CWND = 14
CWND = 15
CWND = 16
Рис. 5.14. Медленный старт
Рис. 5.14. Медленный старт
В этом примере станция А посылает сегмент длиной 100 байт и по истечет времени, приблизительно равного четырехкратному периоду кругового обраг ния (RTT), станция А получает возможность заполнить канал связи непрерь ным потоком своих сегментов.
Медленный старт работает достаточно эффективно при создании соед ния, позволяя протоколу TCP на стороне отправителя быстро определять опЯ мальный размер окна для данного соединения. А если несмотря на все ме$ предосторожности перегрузка все-таки наступила? Рассмотрим поведение это^ алгоритма в такой ситуации. Предположим, что устанавливается соединен^
с медленным стартом, и до того момента, как размер окна перегрузки CWNle достигает размера предельной нормы, выделенного отправителю другой стореИ ной, происходит потеря сегмента. Этот факт может свидетельствовать о том, ч!гаЯ сеть перегружена. Но не существует никаких свидетельств, позволяющих опенитМ серьезность возникшей ситуации. А раз так, то логичнее и безопаснее всего постучИ пить следующим образом: сбросить размер окна перегрузки CWND до исходнйЯ го единичного значения и начать медленный старт заново.я
Такая схема может показаться вполне приемлемой, но только на первыйя взгляд. Давно получил подтверждение тот факт, что сеть легко перегрузить, ноя сложно восстановить ее нормальную работу. Иными словами, если случаетс^я перегрузка, может потребоваться достаточно длительное время и большие уси-Я лия администратора и участников сетевого обмена, чтобы восстановить рабочие я параметры сети. Следовательно, при экспоненциальном росте размер окна ne-J регрузки CWND способен быстро достичь максимума, но к этому времени сет®| еще не будет восстановлена. Поэтому такой медленный старт не только не об- | легчит ситуацию, а наоборот, за счет слишком агрессивного поведения услож-Л нит процесс восстановления. Для решения этой проблемы был предложен алго-1 ритм медленного, старта с линейным ростом размера окна перегрузки CWND. j Теперь при наступлении перегрузки в сети выполняются следующие действия. ;
Переменной SSTHREST (граница медленного старта) присваивается значение, равное половине текущего размера окна перегрузки, то есть SSTHREST = = CWND / 2.
Устанавливается размер окна перегрузки CWND = 1 и выполняется медленный старт, до тех пор пока размер окна CWND не сравняется с заданным значением переменной SSTHREST (шаг 1). В этой фазе размер окна CWND будет увеличиваться на единицу после получения подтверждения на каждый посланный сегмент.
Если размер окна CWND превысил пороговое значение SSTHREST, то CWND необходимо увеличивать на единицу каждый раз по истечении времени обращения RTT.
Рисунок 5.15 иллюстрирует описанный вариант использования медленного старта.
При этом рис. 5.15, а иллюстрирует динамику роста размера окна перегрузки, аналогичную процессам, показанным на предыдущем рисунке, за исключением того, что последний сегмент потерян.
Станция А Станция Б
CWND = 1
CWND = 2
CWND = 3
CWND = 4
CWND = 5
CWND = 6
CWND = 7
CWND = 8
CWND = 9
CWND = 10
CWND = 11
CWND = 12
CWND = 13
CWND = 14
CWND = 15
CWND = 16
Станция А Станция Б
CWND = 1
CWND = 2
CWND = 3
CWND = 4
CWND = 5
CWND = 6
CWND = 7
]' CWND = 8
CWND = 9
CWND = 10
Рис. 5.15. Использование медленного старта: а — медленный старт, который заканчиваетсяпотерей сегмента, б — предотвращение перегрузки
Рисунок 5.15, б показывает реакцию на потерю сегмента. Значение переменной SSTHREST равно 8. Пока размер окна перегрузки не достигнет этой величины, окно растет по экспоненте. После пересечения этого рубежа размер окна CWND увеличивается линейно. Такое поведение демонстрирует рис. 5.16.
Время обращения
Рис. 5.16. Увеличение размера окна
На рис 5.16 окно CWND размера 8 показано как граничное значение. И е< до наступления тайм-аута прошло время, равное 4xRTT, то для повторного в ждения в этот режим уже потребуется время llxRTT. '
Механизм TCP Path MTU
Маршрутизаторы компании Cisco Systems поддерживают так называемый, ханизм TCP Path MTU Discovery, который позволяет повысить произвр, тельпость передачи информации между двумя абонентами соединения TCP. умолчанию этот механизм на маршрутизаторах отключен. Для его актива! следует выполнить команду ip tep path-mtu-discovery в режиме конфигурирова! интерфейсов. Формат команды предполагает параметры, которые можно он тить при ее выполнении.
Наибольший эффект от применения этой технологии будет получен, если единения TCP в распределенной сети используются для передачи больших о емов данных. Следует отметить, что выполнение указанной команды вклю ет работу рассматриваемого механизма для соединений, которые иницииД маршрутизатор. Полный формат команды:
ip tep path-mtu-discovery <age-timer {minutes | infinite}>
В качестве параметра можно указать временной интервал (age-timer), on] ляющий, как часто протокол TCP должен оценивать параметр Path MTU с большим значением MSS. По умолчанию интервал составляет 10 минут, а
МеханизмТСРРа^МеханизмТСРРа^
МеханизмТСРРа^
МеханизмТСРРа^
Увальное значение — 30 минут. Если указать значение infinite, то таймер будет отключен.
Значение MTU обычно устанавливается в сочетании с MSS и RWIN (TCP Receive Windows — размер окна приема). Напомню, что MSS — это наибольший сегмент данных протокола TCP, передача которого возможна в соединении. MSS олжен быть меньше MTU по крайней мере на 40 байт. RWIN определяет, как много данных получатель готов принять. Если размер окна приема слишком велик это приведет к большим потерям при передаче в случае утери информации. Если же это значение совсем мало, например IxMSS, передача будет слишком медленной. Обычно значение RWIN равно 4х, 6х или SxMSS.
Когда в распределенной сети пользователь работает с удаленным сервером
или приложением, его производительность может снижаться за счет выполнения фрагментации передаваемой информации (точнее, фрагментации дейтаграмм протокола IP). Например, если по крайней мере один маршрутизатор в пути имеет значение MTU, равное 576 байт (что зависит от физической среды передачи), а пользователь работает в операционной системе Microsoft Windows 95, для которой значение MTU по умолчанию составляет 1500 байт, эго приведет к тому, что будет выполняться фрагментация.
' При передаче информации по протоколу TCP последний может устанавливать бит DE (Don’t Fragment) в заголовке дейтаграммы IP. Любой маршрутизатор в пути следования сегментов может иметь значение MTU, отличающееся от того, которое используют абоненты в разных частях распределенной сети. Если значение MTU в пути следования сегмента меньше, чем длина маршрутизируемой дейтаграммы протокола IP, маршрутизатор будет пытаться выполнить фрагментацию. Однако она запрещена установкой соответствующего бита, и с этого момента маршрутизатору следует информировать отправителя о том, что дейтаграмма не может быть передана далее без выполнения фрагментации. Данная функция возложена на протокол 1СМР.
Большинство маршрутизаторов также могут указывать значение MTU для следующего перехода, помещая информацию в незадействованиые поля. После получения сообщения ICMP протокол TCP выравнивает значение MSS до указанного MTU с учетом байтов заголовков TCP и IP. Таким образом, остальные пакеты, посылаемые по этому соединению, не будут превышать MTU в пути следования. Однако некоторые маршрутизаторы могут просто отбрасывать большие дейтаграммы, которые они не умеют фрагментировать. Если это происходит, следует выполнить настройку маршрутизатора па поддержку механизма PMTU (глава 1).
В реестре Microsoft Windows 2000 есть два параметра, которые помогают операционной системе работать с подобными маршрутизаторами (табл. 5.15 и 5.16).
^блица 5.15. Параметр EnablePMTUBHDetect
EnablePMTUBHDetect Tcpip\Parameters REG_DWORD 0, 1 (False, True) 0 (False)EnablePMTUBHDetect Tcpip\Parameters REG_DWORD 0, 1 (False, True) 0 (False)Название параметра
EnablePMTUBHDetect Tcpip\Parameters REG_DWORD 0, 1 (False, True) 0 (False)
EnablePMTUBHDetect Tcpip\Parameters REG_DWORD 0, 1 (False, True) 0 (False)
■ Ключ в реестре
I тип Записи
I Диапазон значений
I _3начение по умолчанию
Равенство параметра EnablePMTUBHDetect единице (true) заставляет прот TCP в процессе выполнения операции PMTU discovery (обнаружение РМ делать попытки выявлять так называемые «черные дыры» в виде маршрутиз ров. Это маршрутизаторы, которые не возвращают сообщения ICMP Destina Unreachable, если необходимо выполнять фрагментацию дейтаграммы, но уста) лен бит DF. При включении параметра EnablePMTUBHDetect протокол пытаё послать сегменты без установленного бита DF, если несколько повторных п< дач одного сегмента не были подтверждены. Если этот сегмент подтверждав то MSS снижается и бит DF устанавливается для следующих пакетов. Актг ция механизма обнаружения «черных дыр» повышает максимальное количес повторных передач, которые выполняются для данного сегмента.
Таблица 5.16. Параметр EnablePMTUDiscovery■
Название параметра
Ключ в реестре
EnablePMTUDiscovery
Tcpip\Parameters
Тип записи
REG_DWORD — Boolean
Диапазон значений
0, 1 (False, True)
Значение по умолчанию
1 (True)
Когда параметр EnablePMTUDiscovery (табл. 5.16) равен 1 (true), протокол пытается обнаружить MTU в пути следования до удаленного абонента. Этот ^
метр включен по умолчанию, поскольку его установка помогает повысить пр< водительность. Сброс параметра в 0 заставляет предположить, что в распреде^ ной сети используется значение MTU, равное 576 байт, что и будет учитывав
для всех соединений с удаленными сетями.
Администратор имеет возможность вывести значение MTU между дв]
ping. Форматping. Форматустройствами вручную, используя популярную команду
ping. Формат
ping. Формат
манды в операционной системе Microsoft Windows NT для обнаружения
следующий:
ping -f-n <количество попыток> -I <размер> <адрес получателях;
Как показано далее, изменяя значение параметра <размер> , можно выяС1 соответствующий MTU. В качестве размера указывается объем посылаемых ных без включения заголовка. При этом заголовок протокола ICMP состав. 8 байт, а заголовок протокола IP — 20 байт. В приведенном ниже примере в. няется, что максимальный посылаемый объем данных составляет 1472 байт. I к этому значению прибавить 28 байт, то получим максимальное значение Л в пути до удаленного компьютера, которое равно 1500 байт:
C:\>p1ng -f -n 2 -1 1472 192.168.7.254'
Обмен пакетами с 192.168.7.254 по 1472 байт:■
Ответ от 192.168.7.254: число байтов=1472 время=591мс TTL=254
Ответ от 192.168.7.254: число байтов=1472 время=591мс TTL=254
r-\>ping -f -n 2 -1 1473 192.168.7.254
Обмен пакетами с 192.168.7.254 по 1473 байт:
Требуется фрагментация пакета, но установлен запрещающий флаг, Требуется фрагментация пакета, но установлен запрещающий флаг.
С:\>
Далее, в примере работы анализатора пакетов протокола IP возвращает сообщение об ошибке Destination unreachable протокола ICMP. Если одна из «черных дыр» в пути до получателя только притворяется маршрутизатором, то команда ping не получит ответа, если размер данных превышает MTU, которое может обработать этот маршрутизатор. Приведенный перехват был получен при выполнении команды ping с указанием размера буфера 1000 байт. При этом в сети находится маршрутизатор, который поддерживает MTU, равный 576 байт. В ответном сообщении об ошибке указывается, что размер наибольшей дейтаграммы, которую можно передать, составляет 576 байт (0x240).
Src Addr Ost Addr Protocol Description
192.168.3.20 192.168.8.1
10.99.99.10 10.99.99.9 ICMP Destination Unreachable: 192.168.3.20
See frame 3
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP; ID = 0x4401: Proto = ICMP: ten: 56
ICMP: Destination Unreachable: 192.168.3.20 See frame 3
ICMP: Packet Type = Destination Unreachable
ICMP: Unreachable Code = Fragmentation Needed, DF Flag Set
ICMP: Checksum = 0xA05B
ICMP: Next Hop MTU = 576 (0x240)
ICMP: Data: Number of data bytes remaining = 28 (0x0010
ICMP: Description of original IP frame
6
Трансляция адресов : и настройка очередей ;
В этой главе будут рассмотрены две технологии, которые хотя и нельзя наз| базовыми, они тем не менее являются достаточно важными при построении! пределенной сети. Первая рассматриваемая технология — трансляция адрес® призвана значительно облегчить задачу администратора сети по подключу организации к Интернету. Вторая — технология очередей — становится все» лее актуальной при наличии интерактивного трафика, который нужно каким образом выделять при передаче для обеспечения требуемого качества. л
Трансляция адресов и
При применении технологии трансляции сетевых адресов (Network Add^ Translation, NAT) администратор сети в состоянии расширить доступное^ адресное пространство путем определения так называемых внутренних (частив адресов (private addresses) и последующего преобразования их в открытые (pUj addresses) адреса. Технология NAT становится очень полезной в случае, Кб; организации, имеющей крупную распределенную сеть, выделяют ограничен® блок зарегистрированных адресов, например одну сеть класса С. При этом ЗД8 нистратор может провести дробление одной сети класса С на множество небо; ших, например при помощи технологии VLSM. Другой путь — попытаться пй чить новые открытые адреса от интернет-провайдера, что не всегда получает!
Внутренние адреса — это блок общего адресного пространства протокола? которое было выделено интернет-сообществом для использования в сетях, не ИМ ших связи с самой сетью Интернет. Эти блоки определены документом RFC IS О 10.0.0.0-10.255.255.255/8 / О 172.16.0.0-172.31.255.255/12 1 О 192.168.0.0-192.168.255.255/16 .
Любая организация вправе без ограничений использовать эти адреса без предварительной регистрации. Очевидно, что при таком подходе множество) ганизаций смогут их задействовать в своих частных сетях. Но эти организм должны понимать, что узловые маршрутизаторы в Интернете не будут марЯ тизировать их трафик, связанный с такими адресами. Для работы с указании
рсными блоками при выделении подсетей, применении технологии VLSM т п все оговоренные правила и подходы сохраняются. На практике ввиду абсолютной доступности этих блоков администратору сети редко приходится вымять подсети — гораздо проще задействовать еще одну сеть целиком, несмотря на большую избыточность.
Р Остальные адреса, не входящие в это адресное пространство, управляются и координируются специальными организациями. Эти адреса маршрутизируемы в Интернете. Очевидно, что каждый открытый адрес протокола IP является уникальным. Если организация владеет достаточным количеством открытых адресов, то внедрение частных адресных блоков в сеть не является для нее прямой необходимостью.
Следует отметить, что адресная схема протокола IP имеет ограниченный набор возможных уникальных адресов, и в настоящее время становится все труднее получить большое количество открытых адресов ввиду ужесточения контроля над их распределением. На помощь приходит технология NAT, позволяющая при необходимости производить трансляцию частных адресов в открытые и обратно.
Разработано множество аппаратных и программных решений, обеспечивающих технологию NAT. Эту технологию поддерживают известные программные комплексы Checkpoint Firewall-1, операционная система Windows 2000 с приложением RRAS (Routing and Remote Access Service), маршрутизаторы Cisco Systems. Установленные па границе сети маршрутизаторы Cisco Systems могут выполнять динамическую трансляцию частных адресов в открытые, тем самым разрешая устройствам частной сети полноценно взаимодействовать с Интернетом. При этом для внутренних устройств подобная трансляция остается полностью прозрачной.
■ Администратор сети может настроить маршрутизатор для управления пулом открытых адресов, в котором адресов меньше, чем внутренних устройств сети, имеющих соединение с Интернетом. Маршрутизатор с настроенным пулом адресов будет динамически, по мере необходимости, выделять адреса для сеансов, а затем освобожденные адреса возвращать обратно в пул доступных адресов. При этом наиболее интересной особенностью с точки зрения безопасности является то, что устройства в Интернете работают с открытыми адресами из пула Маршрутизатора и не имеют представления о том, что взаимодействие с ними
осуществляется с частных адресов. Рассмотрим на примере общую схему работы технологии NAT (рис. 6.1).
В приведенной на рис. 6.1 сети хосту с частным адресом 192.168.3.1 необходимо взаимодействие с Интернетом, в частности с сервером. Администратор Сети предварительно настроил технологию NAT на маршрутизаторе. В результа-
схема трансляции будет работать следующим образом.
। Хост передает трафик, адресованный находящемуся в Интернете серверу. Так f Как хост не знает маршрута к серверу, трафик посылается маршрутизатору по • Умолчанию (он один в этом примере). На данном этапе адрес отправителя тра- г фика — 192.168.3.1, и он является частным адресом в блоке 192.168.3.0 /24. к Маршрутизатор, получая пакеты от хоста, обнаруживает, что последний принад-
У
лежит частной сети и, следовательно, необходима трансляция адресов. Для этого маршрутизатор просматривает настроенный пул открытых адресов и выбирает доступный адрес (193.125.203.1), который заменит собой адрес отправителя.
СерверСерверАдрес отправителя193.125.203.1Адрес отправителя193.125.203.1Адрес отправителя192.168.3.1Адрес отправителя192.168.3.1NATNATEthOEthOАдрес получателя193.125.203.1Адрес получателя193.125.203.1Рис. 6.1. Общая схема работы технологии NATРис. 6.1. Общая схема работы технологии NATХостХостАдрес получателя192.168.3.1Адрес получателя192.168.3.1
Сервер
Сервер
Адрес отправителя
193.125.203.1
Адрес отправителя
193.125.203.1
Адрес отправителя
192.168.3.1
Адрес отправителя
192.168.3.1
NAT
NAT
EthO
EthO
Адрес получателя
193.125.203.1
Адрес получателя
193.125.203.1
Рис. 6.1. Общая схема работы технологии NAT
Рис. 6.1. Общая схема работы технологии NAT
Хост
Хост
Адрес получателя
192.168.3.1
Адрес получателя
192.168.3.1
После замены адресов маршрутизатор передает пакеты в Интернет. Эта кеты маршрутизируются узловыми маршрутизаторами до получения пак сервером.
Сервер после обработки пакетов отвечает по адресу 193.125.203.1, не зад; ваясь о том, что действительный адрес хоста, работающего с ним, соверш< другой. Ответы сервера маршрутизируются в Интернете и в финале пост ют на граничный маршрутизатор, который хранит в своей памяти инфо; цию о выполненном преобразовании..;
Граничный маршрутизатор после получения пакетов с адресом получа' 193.125.203.1 вновь выполняет трансляцию адресов, но теперь уже меняв рес получателя на 192.168.3.1, и передает пакеты далее во внутреннюю! Следует отметить, что хотя в рассматриваемом примере сеть 192.168.3.1
напрямую подключена к маршрутизатору (считаем, что по протоколу Ethei на практике между граничным маршрутизатором и хостом могут присутстве
и другие маршрутизаторы, формирующие распределенную внутреннюю' организации. Из-за того что граничный маршрутизатор сначала выпоЛ трансляцию и только после этого приступил к выполнению функции мар! тизации пакета, для промежуточных маршрутизаторов трансляция адресе
будет заметна.
Граничный маршрутизатор содержит таймер неактивности (idle timer), торый в течение определенного времени отслеживает момент, после кото]
хост перестает посылать пакеты в Интернет. Тогда маршрутизатор вернет 193.125.203.1 в пул свободных адресов. При необходимости администратор’ жет настраивать значение этого таймера.
Для рассмотренного примера настройка маршрутизатора может быть дующей:(
1р nat pool name 193.125.203.1 193.125.203.254 prefix-length 24 ip nat inside source 2 pool name overload
interface serialO
•jр nat outside
interface ethernetO
Tp nat inside.
i■
access-list 2 permit 192.168.3,0 0.0.0.255
Первая команда (ip nat pool name 193.125.203.1 193.125.203.254 prefix-length 24) создает адресный пул для реализации технологии NAT — так называемые внутренние глобальные адреса (inside global addresses). Адресный пул содержит 254 адре- "са начиная со 193.125.203.1 и заканчивая 193.125.203.254. Эти адреса являются зарегистрированными открытыми адресами в Интернете. Именно этими 254 адресами маршрутизатор будет впоследствии заменять внутренние адреса частной сети (так называемые inside local addresses). Данный пул именованный, его имя — name.
Следующая команда (ip nat inside source 2 pool name overload) настраивает маршрутизатор на выполнение трансляции внутренних частных адресов, которые соответствуют списку доступа с номером 2 (более подробно о списках доступа — в главе 9). При этом используется предварительно созданный пул с именем name. Трафик, который ие соответствует списку доступа с номером 2, не подвергается трансляции адресов, а маршрутизируется без всяких изменений.
СОВЕТ
Если в рассмотренном примере не выполнять трансляцию адресов, то маршрутизатор будет передавать трафик с адресами отправителей из частной сети 192.168.3.0/24 в Интернет, и трафик дойдет до получателя. Важно только указать корректный адрес получателя. Но обратно пакеты уже не поступят — узловые маршрутизаторы будут игнорировать маршруты в частные сети. На этом факте часто строятся атаки типа DoS, когда атакующий должен указать только корректный адрес получателя, абсолютно не заботясь об адресе отправителя.
Во второй команде ключевое слово overload говорит маршрутизатору, что он может использовать один открытый адрес для представления множества" хостов с частными адресами. Такая возможность рассматривается как разновидность мультиплексирования. Подобные средства могут потребоваться в случае, когда пул открытых адресов исчерпается из-за большого количества активных сеансов. При мультиплексировании маршрутизатор будет задействовать уникальные номера портов протоколов TCP/UDP для выделения множества внутренних хостов. Учитывая, что для каждого адреса протокола IP доступно более 64 000 портов этих протоколов, теоретически можно поддерживать до 10 000 внутренних хостов на один публичный IP-адрес, хотя практический лимит будет Достигнут быстрее.
®ЕТ Если задействовать ключевое слово overload, можно создать пул адресов, состоящий только Из одного открытого адреса. Этот адрес может быть также назначен одному из интерфейсов Маршрутизатора.
Команда ip nat outside, вводимая в режиме конфигурирования для интерфи са SerialO, указывает маршрутизатору, что данный интерфейс подключен к бальной сети (чаще всего это сеть Интернет). Соответственно, команда ip nat 1пя для интерфейса EthernetO указывает маршрутизатору на внутреннюю сеть — иными словами, на расположение хостов, для которых предполагается трансиц ция адресов.■ '
Последняя команда (access-list 2 permit 192.168.3.0 0.0.0.255) создает списй доступа с номером 2, определяющий устройства, для которых требуется вып<у
пять трансляцию. Маршрутизатор идентифицирует пакеты, покидающие вв
реннюю сеть и входящие в нее, посредством сравнения адресов отправителей списком доступа. Если найдено совпадение (то есть найден адрес отправит в сети 192.168.3.0 с маской 255.255.255.0), то маршрутизатор выделяет откр адрес из пула адресов с именем name, транслирует адреса и передает пакет в тернет.
Если в пуле нет свободных адресов, маршрутизатор не может выпол
трансляцию. В данной ситуации он будет отбрасывать все пакеты и посы устройству во внутренней сети сообщение протокола ICMP Host Unreachab Для решения этой проблемы можно увеличить размер пула или уменьшить-^ чение таймера так, чтобы адреса возвращались в пул быстрее.
rV
ОВЕТ
При использовании динамической маршрутизации во внутренней сети следует настроить филы маршрутов таким образом, чтобы избежать рассылки внутренних маршрутов в Интернет.
У администратора сети может возникнуть потребность в статической, а динамической трансляции адресов. Подобное решение будет особенно востр( ванным для тех устройств, которые должны быть достижимы из Интернету, фиксированным адресам (например, серверов WWW). Поставленная цель^ стигается следующей командой, выполняемой в глобальном режиме:
Router(config)#1p nat inside source static 192.168.3.251 193.125.203.111
Эта команда формирует постоянное соответствие внутреннего адреса168.3.251 устройства, находящегося во внутренней сети, с открытым адреи193.125.203.111.j
S'
ЭИМЕЧАНИЕ
Технология NAT позволяет повысить защищенность внутренней сети, однако для организй полнофункционального защитного экрана ее нужно использовать вместе с другими решен и организационными мероприятиями, направленными на обеспечение безопасности сети. .
Выше рассматривался вариант, в котором граничный маршрутизатор дос администратору сети для управления. Однако бывают ситуации (и, на вз автора, довольно часто встречающиеся), когда интернет-провайдер сам наст вает маршрутизатор и управляет им. С точки зрения потребителя, подо подход предоставляет массу преимуществ, снимая все заботы по техническ обслуживанию граничного маршрутизатора. Вместе с тем решение вопроса ляции адресов может потребовать другого подхода.■'
Выбор технического решения зависит от множества факторов. Предположим, интернет-провайдер выделил организации сеть класса С 193.125.203.0/24 по договору самостоятельно выполняет управление маршрутизатором (это мо” бЫТь маршрутизаторы производства таких компаний, как ЗСот или Nortel). Кпоме того, учитывая возрастающий интерес к семейству технологий xDSL, вероятно применение устройства, совмещающего в себе функциональные возможности маршрутизатора и модема, предназначенного для работы по медным проводам выделенных линий. Но и здесь сохраняется необходимость трансляции адресов, и одним из решений может быть установка выделенного защитного экрана, который помимо фильтрации трафика поддерживает технологию NAT.
' В качестве примера рассмотрим программный продукт GuardianPro v5 компании NetGuard, работающий под управлением операционной системы Windows NT 4.0. На рис. 6.2 показана функциональная схема фрагмента сети с ис, пользованием этого продукта.
Адрес отправителя193.125.203.1ЧАдрес отправителя193.125.203.1ЧАдрес отправителя192.168.3.1Адрес отправителя192.168.3.1Маршрутизатор провайдераМаршрутизатор провайдераNAT/NARNAT/NARАдрес получателяАдрес получателя192.168.3.1 >192.168.3.1 >Адрес получателя193.125.203.1►Адрес получателя193.125.203.1►
Адрес отправителя
193.125.203.1
Ч
Адрес отправителя
193.125.203.1
Ч
Адрес отправителя
192.168.3.1
Адрес отправителя
192.168.3.1
Маршрутизатор провайдера
Маршрутизатор провайдера
NAT/NAR
NAT/NAR
Адрес получателя
Адрес получателя
192.168.3.1 >
192.168.3.1 >
Адрес получателя
193.125.203.1►
Адрес получателя
193.125.203.1►
Рис. 6.2. Использование защитного экрана с поддержкой технологии NAT
• В рассматриваемом примере за маршрутизатором провайдера установлен защитный экран, представляющий собой сервер на базе платформы Intel с операционной системой Microsoft Windows NT 4.0. Сервер содержит две сетевые платы, которые подключены ко внутренней сети и к сети, непосредственно связанной с Интернетом. Так как во внутренней сети используются частные адреса, то на защитном экране необходимо настроить технологию NAT. Следует отметить, что начальная настройка технологии NAT имеет много общего с настройкой маршрутизатора, и при этом большинство программных защитных экранов предоставляют Удобный графический интерфейс, в то время как при настройке маршрутизатора Щсо Systems администратор ограничен командной строкой. Рисунок 6.3 показывает окно управляющей программы защитного экрана NetGuard GuardianPro, с Помощью которого осуществляется в том числе и настройка трансляции адресов.
* шы»?йу (мы и* шы»?йу (мы иS-даAwighmbrit TypeS-даAwighmbrit TypeDYNAMIC ASSIGNMENTSSternal Network sbie^ I ?E Klernal Network object:! Priority:DYNAMIC ASSIGNMENTSSternal Network sbie^ I ?E Klernal Network object:! Priority:xx*4 Sialic a»ignmenle ■J* Pynaieip Meigmnentt:Ji Single addre» assignment:*5 Public accessible server*4 Sialic a»ignmenle ■J* Pynaieip Meigmnentt:Ji Single addre» assignment:*5 Public accessible serverря NM hKMfeO'^J) "l^a NLIря NM hKMfeO'^J) "l^a NLIHfjhHfjh^g| ENG29Уa RCV37^g| ENG29Уa RCV37EXT NETLow^ EXT NETLowEXT NETLow^ EXT NETLowЯ>i^^ЖЯ>i^^Ж
* шы»?йу (мы и
* шы»?йу (мы и
S-да
Awighmbrit Type
S-да
Awighmbrit Type
DYNAMIC ASSIGNMENTS
Sternal Network sbie^ I ?E Klernal Network object:! Priority:
DYNAMIC ASSIGNMENTS
Sternal Network sbie^ I ?E Klernal Network object:! Priority:
x
x
*4 Sialic a»ignmenle ■
J* Pynaieip Meigmnentt:
Ji Single addre» assignment:
*5 Public accessible server
*4 Sialic a»ignmenle ■
J* Pynaieip Meigmnentt:
Ji Single addre» assignment:
*5 Public accessible server
ря NM hKMfeO'^J) "l^a NLI
ря NM hKMfeO'^J) "l^a NLI
Hfjh
Hfjh
^g| ENG29
Уa RCV37
^g| ENG29
Уa RCV37
EXT NETLow
^ EXT NETLow
EXT NETLow
^ EXT NETLow
Я>
i^^
Ж
Я>
i^^
Ж
Рис. 6.3. Настройка технологии NAT на защитном экране
Первоначально администратор настраивает так называемые сетевые (NET) q| екты — сети, подсети, хосты и т. п. Каждый объект имеет символьное найме! вание. При этом рекомендуется называть объекты таким образом, чтобы пот было удобно ориентироваться в их названиях. В рассматриваемом случае объе NET 192.168.3.0 соответствует сети класса С — 192.168.3.0/24, а объект EXTNE как можно догадаться из названия, охватывает открытые адреса (193.125.203.10 193.125.203.200/24). Рисунок 6.4 показывает окно для создания этого объек представляющего собой внешний пул из 100 открытых адресов.
Artwork Range Pr<Artwork Range Pr<
Artwork Range Pr<
Artwork Range Pr<
Notes: |~Stas IP address:Notes: |~Stas IP address:End IP address:End IP address:
Notes: |~
Stas IP address:
Notes: |~
Stas IP address:
End IP address:
End IP address:
193.125.203.100193.125.203.100193.125.203.200193.125.203.200
193.125.203.100
193.125.203.100
193.125.203.200
193.125.203.200
>
Рис. 6.4. Создание сетевого объекта
Когда объекты определены, администратор переходит в меню настройки № и определяет правила трансляции с указанием приоритета. Приоритет (Нч Medium, Low) позволяет установить порядок использования пула открытых*^ рогов в случае их нехватки. Как и в случае с маршрутизатором компании Gij
с terns, администратор может устанавливать соответствие как для сетей, так для отдельных устройств. Так, в рассматриваемом примере серверу ENG29 сопоставляется пул внешних адресов, благодаря чему защитный экран получает возможность автоматически подбирать свободный адрес в пуле. Этот сервер неположен в отличной от 192.168.3.0/24 сети, где только ему требуется доступ в Интернет. В таком случае нет необходимости в создании объекта, охватывающего всю сеть, к которой принадлежит сервер, а достаточно определить выполнение трансляции только для этого сервера.
Администратор сети вправе также создать объекты, соответствующие внут
ренним маршрутизаторам, и предписать защитному экрану выполнять трансляцию и для них. Это может быть оправдано в случае настройки на маршрутизаторах, например, протокола SNTP для синхронизации времени со внешним источником. .
ИЗ ОПЫТА
Если администратор обслуживает распределенную сеть, состоящую из нескольких удаленных объектов, с использованием маршрутизации трафика, то при выборе программного обеспечения защитного экрана следует обратить внимание на возможность динамической маршрутизации (иными ■ словами, на поддержку протоколов RIP v2, IGRP и т. п.). Если защитный экран устанавливается на компьютере, оснащенном несколькими сетевыми платами, например предназначенном для разграничения доступа в Интернет, зону DMZ (DeMilitarized Zone, демилитаризованная зона) и частную сеть, то при отсутствии динамической маршрутизации маршруты придется вводить вручную. А этот способ требует очень пристального внимания при изменении адресной схемы сети.
Продолжая разговор о защи тном экране компании NetGuard, следует отметить одну из его дополнительных возможностей, которая называется NAR (Network Address Retention). Этот механизм дает возможность защитному экрану работать как proxy ARP (посредник для протокола ARP). Тогда защитный экран отвечает на все запросы протокола ARP, посылаемые маршрутизатором для разрешения адресов устройств, находящихся в защищаемой внутренней сети. Технология NAR может настраиваться администратором как дополнительная и чаще всего задействуется в случаях, когда по каким-либо соображениям нельзя изменять конфигурацию маршрутизатора или к нему пет доступа. Маршрутизатор поддерживает таблицу протокола ARP, устанавливающую соответствие между МАС- адресами устройств и их IP-адресами. После настройки технологии NAR на защитном экране таблица протокола ARP па маршрутизаторе будет выглядеть следующим образом:
Router#show агр'
Protocol
Address
Age (mln)Hardware Addr
Type
Interface
Internet
193.125.203.119
90
00d0.b7bd.1290
ARPA
EthernetO
Internet
193.125.203.118
90
00d0.b7bd.1290
ARPA
EthernetO
Internet
193.125.203.117
90
00d0.b7bd.1290
ARPA
EthernetO
Internet
193.125.203.116
90
00d0.b7bd.1290
ARPA
EthernetO
Internet
193.125.203.115
90
00d0.b7bd.1290
ARPA
EthernetO
Отсюда видно, что нескольким адресам соответствует только один МАС-адРес (столбец Hardware Addr), который как раз и принадлежит внешнему сетевому
адаптеру защитного экрана. В примере показаны первые несколько строк резу тата выполнения команды show агр. На практике же выдается гораздо боль информации — по записи для каждого адреса из диапазона от 193.125.203 ■ до 193.125.203.200.'
Совместное использование технологии NAR и технологии NAT предостав ет администратору дополнительные возможности: при обеспечении транслят внутренних адресов в открытые ему не требуется выполнять никаких изме ний в настройке маршрутизатора..
Важной особенностью технологии NAT является то, что при изменении ресов отправителя и получателя в заголовке дейтаграммы IP не проверяв' и не модифицируется поле данных этой дейтаграммы. В результате приложен передающие адреса отправителей или получателей в поле данных дейтаграм! могут испытывать трудности при трансляции адресов. Это связано с тем, чтй’ умолчанию поле данных не будет проверяться и изменяться ни защитным эк ном, ни маршрутизатором с поддержкой NAT. Учитывая такое ограничен? компания Cisco Systems постоянно, от версии к версии, увеличивает возмс ности NAT по проверке содержимого поля данных для некоторых прилов ний. В настоящее время поддержку обеспечивают такие приложения, как Н.Э RealAudio, VDOLive, NetBIOS поверх TCP/IP и т. д. (для получения полис перечня поддерживаемых приложений следует посетить сайт www.cisco.com). ''
СОВЕТ=7
Следует обратить особое внимание на ресурсы маршрутизатора, требуемые для выполнения траь ляции адресов. Если наблюдения показывают значительную загруженность процессора, то мож. посоветовать остановиться на других решениях, например на специализированном защитном экД не Cisco FIX Firewall.:
Настройка очередей на маршрутизаторе
Очереди па маршрутизаторе используются для хранения исходящих пакете если канал связи находится в состоянии перегрузки. Когда маршрутизатор npi нимает пакеты и затем обрабатывает их быстрее, чем их можно передать чер исходящий канал связи, он временно помещает их в область памяти, называ мую очередью. Эта очередь назначена исходящему интерфейсу. По выходу ) состояния перегрузки канала маршрутизатор удаляет пакеты из очереди и п сылает их в линию связи. Существует достаточно много способов организаш очередей. Рассмотрим некоторые из них.
Очередь типа FIFO
Если маршрутизатор получает пакеты быстрее, чем он может отправить их чер какой-либо порт, он помещает пакеты в очередь. Затем, в простейшем случг они отправляются дальше в порядке поступления,' то есть реализуется принт «первым пришел, первым ушел» — FIFO (First In, First Out). Алгоритм FlF является основополагающим в технологии очередей. ' ?
Этот алгоритм довольно эффективен, но опыт управления сетями показывает что он далеко не оптимален. Будучи самым простым в реализации, он создает тем не менее серьезные проблемы. Основной недостаток такой стратегии том, что она не позволяет ввести несколько уровней качества обслуживания.
При организации очереди в порядке поступления для каждого порта используется только одна выходная очередь, поэтому все потоки трафика оказываются смешаны. В связи с этим возникают две главные проблемы. Первоочередной интерактивный трафик может быть легко блокирован объемной передачей данных, а переполнение очереди чревато потерей пакетов во всем трафике, а не только в том, который переполнил очередь. Типичным является следующий пример: из-за того что трафик транзакций замедлен происходящей одновремен" но передачей файла по протоколу FTP, возможен разрыв сеанса связи, что приведет к неработоспособности приложения, отвечающего за транзакции. Это наиболее очевидный недостаток очереди FIFO.
' Вторая проблема опасна не меньшими трудностями. Когда происходит переполнение очереди, могут быть потеряны пакеты от всех смешанных потоков трафика. Это заставляет все проходящие потоки протокола TCP (напомним, что так как сегмент TCP инкапсулируется в дейтаграмму IP, можно говорить о потоках TCP) выполнять повторную передачу, что будет сопровождаться последующими всплесками трафика. В этих условиях алгоритмы протокола TCP «Медленный старт» и «Предотвращение перегрузки» могут не помочь. Такие короткие синхронизированные волны трафика усугубляют переполнение на маршрутизаторах.
Попытки упредить переполнение очереди за счет увеличения размера самой очереди вызывают другие проблемы. Большая разница между задержкой при ■ пустой очереди и задержкой при полной очереди увеличивает флуктуации трафика в сети. Повышенная флуктуация требует наличия большего буфера для своего «гашения» на принимающей стороне. По этой причине при использова- • нии больших промежуточных очередей почти невозможно выполнить требования трафика реального времени. Когда маршрутизатор удаляет старые пакеты из очереди, то сначала он удаляет пакеты, поступившие раньше других («ста- • рые» пакеты). Такая стратегия характерна для FIFO. Обвгая схема работы с оче- ; редями показана на рис. 6.5..
Рисунок 6.5, а иллюстрирует ситуацию, когда исходящий капал связи нахо- 1 Дится в состоянии перегрузки. При этом пакет 1 не покинул маршрутизатор . полностью, а другой пакет (пакет 2) только поступает в маршрутизатор. Маршрутизатор за оставшееся время до полного выхода первого пакета может обра- . ботать второй пакет, но медленный канал задерживает первый пакет. Так как ;. Исходящий интерфейс перегружен, то маршрутизатор, руководствуясь заданной I СтРатегией очередей, вместо удаления (dropping) пакета (в данном случае вто- ■ Рого) помещает этот пакет в очередь. Теперь он может быть отправлен только 1 п°сле того, как пакет 1 полностью пройдет через исходящий интерфейс. Время, К которое необходимо пакету, для того чтобы покинуть маршрутизатор, называет- 3аДержкой сериализации (serialization delay).
Исходящий интерфейсИсходящий интерфейсббРис. 6.5. Очередь FIFO: а — исходящий канал в состоянии перегрузки, б — освобождение очереди снизуРис. 6.5. Очередь FIFO: а — исходящий канал в состоянии перегрузки, б — освобождение очереди снизу
Исходящий интерфейс
Исходящий интерфейс
б
б
Рис. 6.5. Очередь FIFO: а — исходящий канал в состоянии перегрузки, б — освобождение очереди снизу
Рис. 6.5. Очередь FIFO: а — исходящий канал в состоянии перегрузки, б — освобождение очереди снизу
При «взрыве» трафика в сети (traffic bursty, означающем превышение^ вместной скорости поступления пакетов и скорости их обработки маршрут! тором над пропускной способностью (bandwidth) исходящего канала связи, п исходит перегрузка этого канала связи и пакеты поступают в очередь. Таю в приведенном примере используется стратегия организации очередей FI. пакеты покидают очередь в том порядке, в котором они туда поступили. СлеЛ отметить, что если количество появившихся за короткий промежуток врем
пакетов слишком велико, то соответственно повышается и скорость запол пия очереди до максимального размера, то есть очередь быстрее переполняем В этом случае маршрутизатор будет отбрасывать следующие поступающие кеты, до тех пор пока в очереди не освободится место для новых. Такое пове ние маршрутизатора называется «сбросом хвоста» (tail drop conditiQQ). Так j сам факт удаления пакетов не является положительным явлением (он привод к еще большему «наплыву» пакетов из-за повторных передач информации): в хорошо продуманных и разработанных сетях необходимо приложить мат' мум усилий для снижения вероятности появления описанной ситуации. Од! если подобная ситуация возникает, то администратору сети следует по вози ности оценить активность и тип трафика, проходящего через маршрутизатор.' необходимо для выявления и контроля источника «взрывоопасного» траф
Рис. 6.6. Пример сети с перегрузкойРис. 6.6. Пример сети с перегрузкойВозможно, придется увеличить пропускную способность исходящего канала связи чтобы пакеты могли покидать очередь с большей скоростью. Рассмотрим имер гипотетической сети, в которой маршрутизатор передает пакеты из двух локальных сетей в глобальную сеть (рис. 6.6).
Рис. 6.6. Пример сети с перегрузкой
Рис. 6.6. Пример сети с перегрузкой
В этой сети несколько клиентов подключены к интерфейсам маршрутизато- : ра. Как видно из рисунка, пропускная способность исходящего канала связи ; равна Т1 (1,544 Мбит/с), что значительно меньше, чем скорость на интерфейсах . локальной сети (10 Мбит/с). В случае, если клиенты локальной сети начинают 1 генерировать значительный объем трафика, направленного в глобальную сеть , через маршрутизатор (что, в общем, является типичной ситуацией для большин. ства удаленных офисов), то канал связи с глобальной сетью быстро достигнет состояния перегрузки. Это заставит маршрутизатор отправлять пакеты в очередь и, естественно, задерживать их доставку получателям. Если интерфейс глобальной сети маршрутизатора использует очередь FIFO, то в результате пакеты от одного клиента (даже если они короче по размеру и их общее количество мень- 1 Ше) будут вынуждены ожидать ухода пакетов от других клиентов, которые начали работать несколько раньше. Если предположить, что этот клиент работает с сеансом Telnet (например, это администратор сети, управляющий удаленным маршрутизатором), то слишком большой интервал между обменами информацией может привести к тому, что администратор не сможет работать в предполагаемом интерактивном режиме.
I Качество обслуживания в IP-сетях
I Перед рассмотрением других алгоритмов очередей необходимо остановиться на ■ возможностях протокола IP. В заголовке каждой дейтаграммы присутствует В Поле «Тип сервиса» (Type of Service), состоящее из двух подполей. Первое, соДержащие три бита (с 0 по 2), называется IP Precedence и служит руководством
маршрутизатору при выделении ресурсов для обрабатываемой дейтаграммы. ( дующие четыре бита (с 3 по 6) определяют способ выбора следующего пере: для дейтаграммы. В англоязычной технической литературе эти четыре бита зывают подполем TOS (Type Of Service — здесь может быть некая путаница, ; как часто все поле в заголовке обозначают как TOS). Бит 7 нулевой (рис. 6.7
012
3
45
6
7
: IP Precedence:
0
111 — Network Control
110 — Internetwork Control
101 — Critical
100 — Flash override
011 — Flash
010 — Immediate
001 — Priority
000 — Routine
1000 — Minimize delay
0100 — Maximize throughput
0010 — Maximize reliability
0001 — Minimize monetary cost 0000 — Normal service
Рис. 6.7. Поле «Тип сервиса»
Остановимся более подробно на подполе TOS. Обычно это подполе устан ливается отправителем дейтаграммы для определения требуемого качества служивапия, которое по возможности должно быть обеспечено. На практ) маршрутизаторы часто игнорируют его содержимое. Однако если проверка держимого этого подполя па маршрутизаторе выполняется, то предполагаю1 три способа реагирования.
Принимается решение о маршрутизации. Например, любую дейтаграмму с прошенной минимальной задержкой (значение 1000) не следует передав по маршруту, включающему спутниковый канал связи.
При маршрутизации дейтаграммы маршрутизатор вправе запросить треб мые параметры качества обслуживания у распределенной сети, возможир; которой наилучшим образом соответствуют значению в этом подполе. Н§ торые технологии распределенных сетей, например ATM, поддерживают, боры совпадающих параметров при предоставлении качества обслуживая
Маршрутизатор может учитывать значения в этом подполе для принятия ре ния о способе обработки дейтаграммы с. использованием технодд^шуу] дей. Например, маршрутизатор может обеспечить предпочтительную оораос в очереди для дейтаграммы, запрашивающей минимальную задержку, или оборот, попытаться избежать отбрасывания дейтаграммы, лля которой за шивается максимальная надежность (значение 0010).'
Два документа — RFC 1349, определяющий интерпретацию поля «Тип виса» в заголовке дейтаграммы, и документ RFC 1812, содержащий требов; к маршрутизаторам, — указывают на первый из трех вариантов реагирова: а именно на выбор маршрута. Однако способ, с помощью которого маршрут тор определяет, какие маршруты в распределенной сети будут поддерживать прашиваемые параметры, выходит за рамки этих документов. В основном, ( две альтернативы. Во-первых, администратор сети может предварительно а<
иповать разные маршруты с разными параметрами подполя TOS. Во втором ае протокол маршрутизации в состоянии динамически отслеживать подпо- в сочетании с другими параметрами, такими как задержка, пропускная способность каналов связи и количество отброшенных дейтаграмм (примером такого протокола маршрутизации служит OSPF).
Подполе IP Precedence определяет степень срочности, или приоритет, присвоенный дейтаграмме, и этот приоритет ограничивается наибольшим дн&чени- ем Network Control и наименьшим Routine. Первый предполагается использовать только внутри распределенной сети для передачи служебной информации. Предшествующий наивысшему уровень Internetwork Controlтакже ориентированна йёредачу служебных данных, но сфера его%рименения ограничена - информацией, относящейся к задачам маршрутизации, например сообщениями маршрутизации. Оставшиеся уровни не имеют строгого целевого определения.
Отметим вновь, что на практике маршрутизаторы могут игнорировать подполе IP Precedence. Как и в случае подполя TOS, если маршрутизатор поддерживает IP Precedence, он вправе предпринять одно из трех ответных действий: выбор маршрута, организацию очереди и запрос параметров качества обслуживания от нижележащей сети. Например, среди, нескольких маршрутов с одинаковой метрикой может быть выбран тот маршрут, для которого меньше очередь на маршрутизаторе. Однако наибольший эффект от использования этого подполя достигается совместно с правильным выбором стратегии для очереди.
Если вернуться к документу RFC 1812, то там можно найти следующие рекомендации (следует обратить внимание на то, что практически все высказывания носят именно рекомендательный характер, оставляя широкое поле деятельности конкретным производителям).
Маршрутизатору рекомендуется реализовывать стратегию очереди с учетом подполя IP Precedence. В этом случае при выборе следующего пакета для отправки через интерфейс с настроенной очередью выбирается пакет с наибольшим значением приоритета срочности. Кроме того, любой маршрутизатор может реализовывать другие процедуры управления пропускной способностью, опираясь на значения этого подполя, однако он должен предоставлять команды для отключения таких процедур. В том случае, если маршрутизатор получает пакет, который уже нельзя поместить в очередь ввиду ее заполненности, он должен отбросить этот или другие пакеты. Причем маршрутизатор может отбросить пакет, даже если он только что поступил, и это является самой простой, но не самой лучшей политикой. В идеале, маршрутизатор должен выбирать пакет из того потока, который наиболее загружает исходящий канал связи.
Рекомендованная стратегия в распределенной сети, построенной на базе протокола IP и очередей FIFO на маршрутизаторах, следующая: ^аршрутрзадор.йь- ■ВйЧ^т случайно выбранный пакет из очереди. Если же используется «справедливая» очерёдь, тЪ*пакет Отбрасывается из наиболее заполненной очереди. Маршрутизатор может использовать вышесказанное для выбора отбрасываемого
-Маршрутизатор «^ц!®^
ь р- Ритета. Иными словами, следует проводить некую селекцию перед отбра- кс®Ня&иемпак^га. Кроме того, маршрутизатор может защищать от отбрасывания
пакеты, в которых заголовок протокола IP запрашивает максимальную няяи ность (0010, maximize reliability), за исключением ситуаций, когда это прав] вступает в противоречие с предыдущим. Далее, маршрутизатор может з фрагменты дейтаграммы IP, опираясь на тот факт, что отбрасыванйе одного^ЙЕ мента опасно дальнейшей перегрузкой в сети, так как потребуется повтор] передача всех фрагментов. И последнее правило указывает на то, что маршрут затор может защищать пакеты со служебной информацией для предотвращ ’ нежелательных эффектов, например образования петель маршрутизации.
Простая арифметика показывает, что три бита подполя IP Precedence.^ доставляют 8 значений приоритета (от 0 до 7, или ООО до 111 в двоичном в Стратегии очередей WFQ, CAR и RED, которые будут подробно рассмотри ниже, используют эти значения для предоставления определенным пакей (точнее, дейтаграммам) лучшего качества обслуживания, чем другим. Напо что такая функциональность маршрутизатора, как policy routing, позволяет, ) мимо прочего, устанавливать значения битов приоритета в дейтаграммах.
Установка перечисленных битов является удобным способом деления,; фика на 8 классов. Однажды установленное значение для пакета остается Bi по мере его маршрутизации по распределенной сети. На каждом из переход (hop) в пути следования пакета до получателя маршрутизаторы могут пр( рить значения данного поля в пакете и осуществить предопределенное дейс (например, выполнить высокоприоритетное обслуживание, отбросить пф< установить новое значение данного поля и т. п.). В том случае, если маршр$ затор не поддерживает предоставление обслуживания на основании содерж го этого поля, пакеты просто передаются далее по маршруту вне зависимости класса. Можно сказать, что средства, предоставляемые данным полем, являю базой для внедрения качества обслуживания в сети.
Чувствительные к качеству обслуживания приложения продолжают развив^ ся, и вполне вероятно, что использование приоритетов в дейтаграммах и ана^ гичные стратегии будут оставаться определяющими в достижении требуем^ качества обслуживания в пакетных сетях. Дополнительно, с помощью сохра^ ния относящейся к качеству обслуживания информации в самом пакете вме использования списков критериев, настраиваемых непосредственно на к из маршрутизаторов в сети, становится возможным расширить предоставлен качества обслуживания (Quality of Service — QoS) по всей распределенной с
Очередь RED
Случайное раннее обнаружение (Random Early Detection — RED) представ^ собой альтернативу очередям FIFO. Этот метод позволяет смягчить эфф< потери пакетов даже при очень больших нагрузках. В оегю^та °'
до-дрежнему лежит принцип FIFO, но пакеты отсеиваются случаиным_о (вместо того чтобы отбрасывать сообщения из конца очереди),'^ длина очереди за данный промежуток времени превосходит установленное^ чение. Этим достигается оптимизация заполнения очереди. Данный алгори был изначально создан для протокола TCP, но он может быть применен к?^ фику любого протокола, когда сеть не гарантирует доставки.
Г Алгоритм контролирует размер исходящей очереди и отбрасывает пакеты I некоторых потоках трафика до того, как произойдет переполнение очереди.
I д и таКой «потере» пакетов срабатывает механизм определения перегрузки прото- * I кола тсР и скорость потока временно уменьшается. Таким образом, в жертву ' приносятся только несколько потоков, которые вынуждены производить повторную передачу и включать алгоритм медленного старта (slow start). Тем самым удается избежать возникновения волн глобальной синхронизации (global synchronization), когда множество потоков начинают одновременную ретрансляцию, вызванную потерей пакетов при переполнении буфера. Ясно, что работа алгоритма RED зависит
■ от алгоритмов протокола TCP «Медленный старт» и «Предотвращение перегрузки». Использование очередей, к которым вынуждены прибегать маршрутизаторы и граничные устройства, не имеющие возможности непосредственно управлять
. непрерывными потоками трафика, в свою очередь порождает некоторые проблемы, которые решены только частично. Есть проблемы, которые не могут быть реше, ны никакими методами организации очереди, включая взвешенные справедливые очереди WFQ и другие недавние разработки.
Технология RED на маршрутизаторе старается избегать состояния перегруз. ки за счет использования стратегии потоков для протокола TCP. То есть можно сказать, что RED — это механизм нс управления перегрузками, а их прсдотвра- , щения.
г По мере увеличения трафика на исходящем интерфейсе маршрутизатора , очередь на нем заполняется пакетами. Как уже говорилось, заполнение очереди 1 происходит из-за того, что низкая пропускная способность исходящего канала 1 связи не позволяет ему успешно справляться с возрастающим объемом посту- < лающего трафика. И если объем трафика продолжает нарастать со скоростью, превышающей скорость исходящего канала, то вполне возможна ситуация, когда в системе не останется пи одной незаполненной очереди. Когда это происходит, . маршрутизатор не имеет альтернативы, кроме удаления всех новых поступающих ' пакетов. Такое вынужденное поведение маршрутизатора называется «сбросом . хвоста». Следует отметить, что это состояние может наступить как для очереди
FIFO, так и для остальных стратегий очередей. Процесс сброса пакетов приводит к нежелательному результату, поскольку пакеты из всех потоков сбрасыва- . ются маршрутизатором в одно время и продолжают сбрасываться им до тех пор, пока система очередей частично не освободится. Потоки, которые используют
. протоколы, подобные TCP, будут вновь и вновь передавать те пакеты, которые были отбракованы маршрутизатором. Другие потоки, например потоки протокола UDP, напротив, никогда не передадут снова непринятые пакеты, так как эта функция возлагается на протоколы более высокого уровня. Другим потокам может вообще не потребоваться повторная отправка информации, например приложениям, передающим аудио- и видеоинформацию в реальном времени.
Для распределенной сети, построенной на базе протокола IP, нормально наличие нескольких потоков протокола TCP. И если эти потоки подвержены влиянию «сброса хвоста» маршрутизатором, то все отправители информации, переносимой этими потоками, начинают повторную передачу информации (по истечении
[ 3аДанного промежутка времени), причем часто это происходит в одно и то же ■ время. Такие повторные передачи и приводят к крайне нежелательному явлению
в сети — эффекту глобальной синхронизации. Важной особенностью прото TCP является его уникальная способность выполнять медленный старт- означает, что конечные станции в начале сеанса или повторной передачи высь ют небольшие пакеты, а затем, по мере того как пакеты поступают получат без сбросов на промежуточных узлах сети, постепенно наращивают скоросп правки информации. Более подробно механизм медленного старта описыва в главе 5, а сейчас рассмотрим увязку его работы со стратегией RED.
Сочетание глобальной синхронизации и медленного старта протокола ' может привести к еще более разрушительным результатам. Когда у множе потоков TCP сброшены маршрутизатором один или несколько пакетов, все правители этих потоков начинают процедуру медленного старта в одно и те время. Это означает, что все такие потоки одновременно снижают свою: рость, что, естественно, приводит к резкому спаду интенсивности трафика в; (в данном случае подразумевается, что в сети «господствует» трафик TCP), тем отправители начинают постепенно наращивать скорость отправки и де вовать также одновременно, что будет продолжаться до тех нор, пока скор< потоков не достигнут максимума, что вновь приведет к перегрузке и сбросай кетов, и т. д.д
Алгоритм RED случайным образом удаляет пакеты, основываясь на их к< честве в очереди на интерфейсе. По мере того как объем заполняемой оче{ близится к своему максимуму, RED начинает сбрасывать пакеты более аг тивно, чтобы уйти от процедуры «сброса хвоста». Таким образом, вместо on всех новых пакетов при заполнении очереди происходит управление глуби очереди с помощью случайного сброса некоторых пакетов. При пропаже па: приложение, которому этот пакет принадлежал, снижает скорость потока 1 и начинает процедуру медленного старта. Такое взаимодействие помогает с дить скачкообразные взрывы трафика и повышает общую производительн! системы. Следует отметить, что на низкоскоростных каналах связи страте RED может привести к нежелательным результатам. Это связано с тем, что, правило, при работе па низких скоростях приложению желательно полное утилизировать доступную полосу пропускания. В такой ситуации RED мо своей активностью препятствовать этому.
Полностью поддерживая стратегию предоставления качества обслужива RED в первую очередь сбрасывает низкоприоритетные пакеты. Выявление 1 оритстов пакетов осуществляется на основании содержимого поля TOS загол( дейтаграммы IP. Таким образом, приложения, генерирующие высокоприори ный трафик, будут меньше «страдать» от утечки пакетов. Естественно, зн; телыю сократится число медленных стартов. Достижение требуемого каче обслуживания выполняется механизмом RED посредством варьирования бин очередей, причем для каждого уровня приоритета используется индивз альная граница глубины очереди. По мерс заполнения очереди и превыше границы ее глубины уровень приоритета, ассоциированный с этой границей, № наст приближаться к уровню, при котором возможен случайный сброс паке Соответственно, высокий уровень приоритета сочетается с более высоким» ничным значением. Такая комбинация механизма случайного раннего обг ■ жеиия с механизмом назначения приоритета дейтаграммам IP называется W*i
/Weighted RED) — взвешенным случайным обнаружением. Технология WRED сосчитана на работу на высоких скоростях и, как правило, реализуется на маршрутизаторах средних и верхних уровней.
Настройка очередей RED и WRED
Для того чтобы настроить WRED на маршрутизаторе, нужно выполнить команду random-detect по отношению к выбранному интерфейсу. После этого маршрутизатор автоматически настроит границы для очередей разных уровней приоритета.
Ciscol601#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
- Ciscol60l(config)#1nterface serial 1
Ciscol60l(config-1f)#random-detect
Следует отметить, что различий между технологиями RED и WRED немного. Последняя просто добавляет возможность использования поля приоритета дейтаграмм IP. Когда весь трафик в распределенной сети имеет один и тот же уровень приоритета (имеется в виду трафик протокола IP), работает стратегия RED, иначе уровень приоритета сигнализирует WRED о наличии трафика разной важности. После этого пакеты низкоприоритетного трафика сбрасываются ранее, чем высокоприоритетного, по мере заполнения очереди.
В большинстве случаев администратору сети нс потребуется изменять настройки стратегии WRED, принятые по умолчанию. Однако если все же имеется необходимость произвести некоторые настройки в сети, то можно выполнить команду random-detect precedence, как показано ниже.
Ci sc0I601(conf1g)#interface seri al 1
Ciscol60l(config-1f)#random-detect precedence 0 15 35 10
В последней команде значение 0 указывает нулевой уровень приоритета. Трафик с таким приоритетом и является объектом данной команды. Приемлемое значение находится в пределах между 0 и 7 (ограничения поля TOS). Следующие значения —15 и 35 — определяют минимальную и максимальную границы глубины очереди, измеренные в количестве пакетов. Стратегия WRED управляет статистикой средней глубины очереди, оценивая количество пакетов на интерфейсе. Когда средняя глубина не превышает минимальной границы (в нашем примере 15 пакетов), пакеты не отбрасываются маршрутизатором. В том случае, если глубина превышает минимальное значение, маршрутизатор начинает отбрасывать пакеты. По мере увеличения среднего значения глубины очереди из-за усиления состояния перегрузки маршрутизатор начинает удалять пакеты более агрессивно. Свыше максимальной границы (35 пакетов) сбрасываются все пакеты, относящиеся к указанному уровню приоритета. Последний параметр в данной команде указывает, как быстро пакеты начинают сбрасываться, когда средняя глубина очереди достигнет максимальной границы. Значение в примере говорит . о том, что здесь отсеивается один из каждых 10 пакетов.
После того как стратегия WRED настроена, проверить сделанные настройки Можно с помощью команды show interface, как показано ниже. В качестве примера команда выполнялась на интерфейсе, настроенном на работу с сетью Frame
Relay при помощи команды random-detect. Следует отметить, что формат в димых этой командой данных может отличаться в зависимости от использу( версии Cisco IOS.
C1scol60l#show interfaces serialO
SerialO is up, line protocol is up
Hardware is QU ICC Serial
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set. keepalive set (10 sec)
Input queue: 0/75/0 (size/max/drops); Total output drops: 63
Queueing strategy: random early detection(RED)
mean queue depth: 0
drops by precedence:
class
drops
threshold
0
63
20
1
0
22
2
0
24 '
3
0
26
4
0
28
5
0
31
6
0
33
7
0"
35
Очереди с приоритетами
Технология очередей с приоритетами (priority queuing) была разработана ; того, чтобы решить одну из главных проблем очередей FIFO: она предоставл. отдельные выходные очереди для различных классов трафика па одном и’1 же выходном порте. Очереди с приоритетами требуют, чтобы первоочередг потоки трафика были специально обозначены, например с использованием ф TOS, в заголовке дейтаграммы. Кроме того, администратор сети вправе наэ! чить высокий приоритет для трафика, направленного по определенным сетев адресам или к портам. Пакет из обычной очереди не может быть передан, е есть пакеты в более приоритетных очередях. Недостаток такой организм очереди состоит в том, что менее приоритетные очереди могут нуждаться в I пускной способности как раз в тот момент, когда сеть перегружена. Тем са» они способны усугубить ситуацию с перегрузкой, пытаясь инициализиро! повторные передачи для своих низкоприоритетных потоков трафика. .
Очевидное усовершенствование этого метода состоит в том, чтобы всем ОЧ' дям выделить надлежащую долю полосы пропускания. Такой метод называе справедливой организацией очереди (Fair Queuing — FQ). Справедливая очер гарантирует, например, что трафик транзакций будет проходить через мари тизаторы своевременно, причем без полной блокировки канала связи для / гих пользователей. 1
Очередь с приоритетами —- это подход, при котором несколько очере FIFO или RED образуют одну очередь. Трафик распределяется между этими i редями в соответствии с заданными критериями. При этом трафик отправл
в порядке строгой очередности: сначала — трафик с высоким приоритетом, затем — со средним и т. д.
Применение на практике очередей с приоритетами вместо очередей FIFO позволяет настраивать маршрутизатор на отправку пакетов, которым на основании гибкой системы критериев присвоены различные приоритеты. Маршрутизатор отправляет высокоприоритетные пакеты быстрее, чем пакеты с более низким приоритетом. Следует отметить, что эта схема приводится в действие только в том случае, если исходящий интерфейс маршрутизатора входит в состояние перегрузки и пакеты начинают посылаться в очередь. Когда перегрузки нет, маршрутизатор просто пересылает пакеты с той скоростью, с которой он в состоянии их обработать, не обращая внимания па уровень приоритета. Такая стратегия ведения очередей (как и стратегия настраиваемых очередей — custom queuing, рассматриваемая далее) разработана для назначения приоритета трафика только в низкоскоростных каналах глобальной сети, что делает ее особенно привлекательной для нашей страны, когда большинство фирм использует именно низкоскоростные соединения со своими удаленными объектами по причине большой стоимости высокоскоростных. Основное объяснение такому разделению заключается в том, что стратегии очередей с приоритетами и настраиваемых очередей создают дополнительные высокие накладные расходы, которые также ложатся бременем на центральный процессор маршрутизатора. В зависимости от модели маршрутизатора каналы связи со скоростью менее 512 Кбит/с — хорошие претенденты на предоставление этого уровня качества обслуживания.
При использовании стратегии очередей с приоритетами выделяется четыре уровня очередей: с высоким приоритетом, средним, нормальным и низким. Помимо этого на маршрутизаторе реализуется так называемый классификатор (classifier), который отвечает за разделение поступающих пакетов по перечисленным четырем уровням, основываясь на заданных критериях. После того как маршрутизатор определил требуемое качество обслуживания для пакета, он помещает его в соответствующую очередь на исходящем интерфейсе. В случае если данная очередь достигает своего максимального объема, маршрутизатор удаляет пакет. По умолчанию действует нормальный тип очереди — если маршрутизатор не смог классифицировать пакеты, то он помещает их в очередь данного типа. При настройке маршрутизатора на использование стратегии очередей с приоритетами можно указать маршрутизатору классифицировать пакеты на основе различных критериев: размера пакета в байтах, номеров портов в протоколах TCP/UDP, номеров интерфейсов, на которые поступили пакеты, соответствующих правил, заданных в стандартных или расширенных списках доступа (standard or extended access list) и т. п.
Стратегия освобождения очереди и отправки пакетов через исходящий интерфейс следующая: всегда происходит первоочередное освобождение высокоприоритетной очереди по отношению к очереди со средним приоритетом; эта очередь освобождается раньше, чем очередь с нормальным приоритетом; а очередь с нормальным приоритетом обслуживается раньше очереди с низким приоритетом. Это простая стратегия означает, что пока существует пакет в очереди с высоким приоритетом, любые другие пакеты из очередей с более низким при-
оритетом не обслуживаются. Иными словами, очередь со средним приорите сможет начать освобождаться от ожидающих отправки пакетов только при у вии пустой высокоприоритетной очереди. Если новый поступающий пакет к
сифицирустся для поступления в высокоприоритетную очередь, обслужива очереди со средним приоритетом приостанавливается. Однако следует учитыв что при большом объеме высокоприоритетного трафика приложения, тра; которых классифицирован как низкоприоритетный, просто не смогут норм; но функционировать из-за значительных задержек. Подобная ситуация (об;
живанис очереди с низким приоритетом приостанавливается на длительное мя) называется «голоданием очереди» (queuing starvation). Как следствие внедрении в распределенной сети стратегии очередей с приоритетами появл ся необходимость контроля обслуживания низкоприоритетного порождав!
приложениями трафика.
Настройка очередей с приоритетами а для маршрутизаторов Cisco
Настройка очередей с приоритетами начинается с определения списка прио тетов (priority list), в котором указывается уровень приоритета для кажд типа пакета, который необходимо классифицировать. Допустимые форматы1' манды priority-list приводятся в табл. 6.1.
КомандаPriority-list <номер списка> protocol <имя протокола> (high | medium | normalI low} < ключевое слово очереди >Priority-list сномер списка> interface стип интерфейса> сномер интерфейса> (high | medium | normal | low}Priority-list сномер списка> default (high | medium | normal | low}КомандаPriority-list <номер списка> protocol <имя протокола> (high | medium | normalI low} < ключевое слово очереди >Priority-list сномер списка> interface стип интерфейса> сномер интерфейса> (high | medium | normal | low}Priority-list сномер списка> default (high | medium | normal | low}РезультатРезультатТаблица 6.1. Формат команд для настройки очередей с приоритетами
Команда
Priority-list <номер списка> protocol <имя протокола> (high | medium | normal
I low} < ключевое слово очереди >
Priority-list сномер списка> interface стип интерфейса> сномер интерфейса> (high | medium | normal | low}
Priority-list сномер списка> default (high | medium | normal | low}
Команда
Priority-list <номер списка> protocol <имя протокола> (high | medium | normal
I low} < ключевое слово очереди >
Priority-list сномер списка> interface стип интерфейса> сномер интерфейса> (high | medium | normal | low}
Priority-list сномер списка> default (high | medium | normal | low}
Результат
Результат
Назначение приоритетов на основании типа w протокола
Настройка приоритетов для пакетов, поступаю!^' с указанного интерфейса<>
Указание приоритетной очереди для пакетов, не соответствующих другим правилам в списке приоритетов' ■;
В качестве примера можно привести следующие команды, вводимые Вч бальном режиме маршрутизатора (табл. 6.2).
Таблица 6.2. Примеры команд
КомандаРезультат
priority-list 1 protocol ip medium list 101priority-list 1 protocol ip medium list 101priority-list 1 protocol ip high tep telnetpriority-list 1 protocol ip high tep telnetдоступа под ,доступа под ,Требуем от маршрутизатора классифицироватьj
priority-list 1 protocol ip medium list 101
priority-list 1 protocol ip medium list 101
priority-list 1 protocol ip high tep telnet
priority-list 1 protocol ip high tep telnet
доступа под ,
доступа под ,
пакеты, соответствующие списку
номером 101, как трафик со средним приорит!
Указываем маршрутизатору классифицировать пакеты сеанса Telnet протокола TCP как #. высокоприоритетный трафик
команда"^ritydist 1 interface EthernetO lowкоманда"^ritydist 1 interface EthernetO lowpriority-list 1 default normalpriority-list 1 default normalРезультатРезультат
команда
"^ritydist 1 interface EthernetO low
команда
"^ritydist 1 interface EthernetO low
priority-list 1 default normal
priority-list 1 default normal
Результат
Результат
Требуем от маршрутизатора классифицировать пакеты, поступающие на его интерфейс EthernetO, как трафик с низким приоритетом
Сообщаем маршрутизатору, что все другие пакеты, которые не соответствуют ни одному из перечисленных выше правил, следует классифицировать как трафик с нормальным приоритетом. Данную команду можно не вводить, так как это действие по умолчанию
При добавлении нового классифицирующего правила в список приоритетов оно помещается в конец списка. В процессе анализа трафика маршрутизатор сравнивает поступающие на него пакеты с заданным списком начиная с первого правила. При нахождении соответствия пакет помещается в надлежащую очередь. В том случае, если пакет не удовлетворяет первому правилу, он сравнивается со вторым правилом в списке и т. д. Как уже отмечалось, последняя из приведенных команд является командой по умолчанию, и она не отобразится при просмотре настроек маршрутизатора по команде show running-config. После того как список приоритетов был определен, его следует присвоить соответствующему интерфейсу для активации очередей с приоритетами. Например, для того чтобы присвоить список с номером 1 интерфейсу Serial 1, нужно ввести следующие команды:
C1scol60l#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
C1scol60l(config)#1nterface serial 1
Ci SCO160K config-if )#priority-group 1
Необходимость данных команд объясняется тем, что список приоритетов, по сути, является простой таблицей правил, и маршрутизатор не будет распределять исходящий трафик согласно приоритетам, до тех пор пока созданный список не будет привязан к нему с помощью команды priority-group.
Можно привести другой пример использования очередей с приоритетами. Допустим, в некоторой сети удаленные объекты подключены к центральному •офису по сети Frame Relay и получают почту по протоколу POP3, а администратор часто управляет удаленными маршрутизаторами по протоколу Telnet. Для того чтобы обеспечить минимальные задержки при получении почты удаленными пользователями (в ущерб сеансам Telnet), администратор может настроить на центральном маршрутизаторе следующий список приоритетов:
priority-11st 1 protocol ip high tcp рорЗ
priority-11st 1 protocol ip low tcp telnet
interface serialO priority-group 1
Как видно из последовательности команд, теперь центральный маршрутизаТоР будет помещать пакеты протокола РОРЗ в очередь с высоким приоритетом, а пакеты Telnet, соответственно, в очередь с низким приоритетом. Интерфейс МарщруТИзатора SerialO подключен к сети Frame Relay, и на нем настроены
подинтерфейсы. Следует отметить, что команда priority-group доступна дл#' полнения только на интерфейсе, но не на подинтерфейсе. Для того чтобы,i верить факт установки очередей с приоритетами на маршрутизаторе, необхо мо выполнить две команды: show queuing priority и show interfaces serialO:'
Ciscol601#show queuing priority
Current priority queue configuration:
List Queue Args 1highprotocol iptcp port pop3
lowprotocol iptcp port telnet
Ciscol601#show interfaces serialO
SerialO is up, line protocol is up Hardware is QUICC Serial
MTU 1500 bytes. BW 1544 Kbit. DLY 20000 usee, rely 255/255. load 1/255
Encapsulation FRAME-RELAY, loopback not set. keepalive set (10 sec)
LMI enq sent 182. LMI stat reevd 182. LMI upd reevd 0. DTE LMI up
LMI enq reevd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
Broadcast queue 0/64. broadcasts sent/dropped 126/0. interface broadcasts 0J‘
Last input 00:00:04. output 00:00:04. output hang never■ -
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops): Total output drops: 0
Queueing strategy: priority-list 1
Output queue: high 0/20/0, medium 0/40/0, normal 0/60/0, low 0/80/0
указывают^’указывают^’Эти команды проверяют настроенные правила в списке приоритетов под но; ром 1 и подтверждают факт активности данного списка на интерфейсе Sep;
указывают^’
указывают^’
Выделенные жирным шрифтом строки (например, high 0/20/0)
высокую приоритетность очереди. Три цифры, разделенные косыми черт;
признак того, что:
О в настоящее время в высокоприоритетной очереди нет пакетов;
О эта очередь способна вместить в себя до 20 пакетов;
ОО<<ни один из пакетов не был удален из очереди с момента последнего сбрЕ счетчиков, который может быть выполнен либо перезагрузкой маршрут® тора, либо командой clear counters.
О
О
<
<
Максимально возможное количество пакетов в очереди (иными слова глубина очереди) изменяется командой priority-list queue-limit. Эта команда,. полняемая в глобальном режиме маршрутизатора, устанавливает глубину-', высокоприоритетной, средней, нормальной и низкоприоритетной очередей,; занного списка:.
Ciscol601#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ClSCO1601(conf1g)#priority-11 st 1 queue-limit 25 55 70 85’
Ciscol601#sh interfaces serialO’W
Seri al 0 is up. line protocol is up
Queueing strategy: priority-11st 1
Output queue: high 0/25/0. medium 0/55/0, normal 0/70/0. low 0/85/0
Следуя рекомендациям, приведенным в технической литературе по маршрутизаторам фирмы Cisco Systems, без крайней необходимости лучше избегать изменения глубины очереди, оставляя ее равной значению по умолчанию. Эти значения позволяют предоставить расширенную производительность для высокоприоритетных приложений, оставляя достаточно ресурсов другим, менее важным приложениям. Как уже отмечалось, с помощью команды show interfaces можно контролировать количество отброшенных пакетов в очередях. Если по результатам работы данной команды видно, что пакеты в низкоприоритетной очереди отбрасываются маршрутизатором в определенном постоянном количестве, то налицо характерный признак того, что в сети присутствует высокоприоритетный трафик с неизменяемым объемом, который монополизирует канал связи. В таком случае простое увеличение размера низкоприоритетной очереди не всегда решает проблему, так как даже очень большая очередь может быть заполнена, хотя на это и потребуется больше времени. Один из подходов к решению означенной проблемы заключается в пересмотре списков приоритетов на маршрутизаторе (точнее, правил) с целью снизить количество пакетов, проходящих через высокоприоритетную очередь. Можно попытаться использовать другую стратегию очередей, например настраиваемые очереди. Если низкоприоритетная очередь требует лишь небольшого увеличения своей глубины и при этом исключается случайный «взрыв» объема высокоприоритетного трафика, то есть смысл лишь немного увеличить глубину этой очереди, скажем на 5-10 пакетов. При тонкой настройке очередей важно избегать создания очень глубоких очередей, которые могут удерживать в себе пакет длительное время, оказывая тем самым негативное влияние на работу приложения.
В заключение рассмотрения очередей с приоритетами необходимо отметить, что они больше всего подходят к тем сетям, которым требуется только два уровня качества обслуживания: высокий уровень для нескольких критичных приложений и нормальный уровень для остального трафика. Жестких правил нет — все зависит от объема высокоприоритетного трафика и приемлемости полученных задержек для низкоприоритетных приложений.
Настраиваемые очереди
Настраиваемые очереди (custom queuing) отличаются от очередей с приоритетами по ряду показателей. Так, например, при работе с настраиваемыми очередями администратор сети имеет возможность определить до 16 очередей на один интерфейс маршрутизатора, что существенно снижает ограничения, которые вводятся очередями с приоритетами. Это способствует решению проблемы «голодания очереди» (queue starvation), так как настраиваемые очереди не являются . Ст°ль строгими, как приоритетные. Далее, вместо использования заранее пред- ОпРеделенных, именованных очередей (high, medium, normal и low), настраиваемые очереди просто нумеруются от 1 до 16. Здесь следует отметить, что
предоставляемая возможность настройки столь большого количества очере; тесно связана с большими усилиями. Поэтому рекомендуется настраивать им но столько очередей, сколько требуется для’предоставления желаемого качес обслуживания в сети. Это правило поможет в выборе классификационных кр! риев и, в конечном итоге, повысит производительность сети в целом.
Самое существенное различие между настраиваемыми и приоритетными < редями в том, как происходит обслуживание их содержимого. Как уже упомг лось ранее, «голодание очереди» имеет место, когда высокоприоритетная очег удерживает один или несколько пакетов длительный промежуток времени. В личис от приоритетной очереди, настраиваемая обслуживается по алгорвд известному под названием round-robin fashion. При этом маршрутизатор обе живает последовательно все очереди, освобождая в каждой определенное вд честно байтов. После того как последняя очередь была обслужена, цикл пр; ряется вновь начиная с первой очереди. Такая стратегия позволяет устрар
монополизацию канала, однако недостатком является некоторое снижениемонополизацию канала, однако недостатком является некоторое снижениеизводительности высокоприоритетных приложений по сравнению со сл;изводительности высокоприоритетных приложений по сравнению со сл;использования приоритетных очередей. На рис. работы настраиваемой очереди.использования приоритетных очередей. На рис. работы настраиваемой очереди.6.86.8показанпоказанобщийобщийпринцпринцИсходящий интерфейсИсходящий интерфейсРис. 6.8. Принцип работы настраиваемой очередиРис. 6.8. Принцип работы настраиваемой очереди
монополизацию канала, однако недостатком является некоторое снижение
монополизацию канала, однако недостатком является некоторое снижение
изводительности высокоприоритетных приложений по сравнению со сл;
изводительности высокоприоритетных приложений по сравнению со сл;
использования приоритетных очередей. На рис. работы настраиваемой очереди.
использования приоритетных очередей. На рис. работы настраиваемой очереди.
6.8
6.8
показан
показан
общий
общий
принц
принц
Исходящий интерфейс
Исходящий интерфейс
Рис. 6.8. Принцип работы настраиваемой очереди
Рис. 6.8. Принцип работы настраиваемой очереди
Как и в случае очередей с приоритетами, классификатор в маршрутиза^ сортирует пакеты на основе предопределенных правил и помещает их в сослг ствующую очередь. Маршрутизатор может освободить из высокоприоритет очередей больше байтов за один цикл, чем из низкоприоритетных. Параметра оритета задается при настройке очереди, и не следует путать номер очереди приоритетом — номер не имеет специального значения. При классификацй кетов в настраиваемой очереди применимы те же критерии, что и при р: с приоритетными очередями. Кроме того, как и очереди с приоритетами, нар ваемые очереди наиболее эффективны на низкоскоростных каналах связи,, задержка и борьба за полосу пропускания скорее правило, чем исключение
Для настройки этого типа очередей применяется команда queue-list, вводимая глобальном режиме маршрутизатора, имеющая следующий формат (табл. 6.3).
Таблица 6.3. Формат команды queue-list
Команда
Результат
queue-list <номер списка> protocol
<имя протокола> <номер очереди>
<ключевое слово очереди>
queue-list <номер списка> interface
<тип интерфейса> <номер интерфейса>
<номер очереди >
queue-list <номер списка> default
<номер очереди>
Устанавливает приоритеты на основе указанного типа протокола
Устанавливает настраиваемую очередь на основе интерфейса, на который поступают пакеты
Для тех пакетов, которые не соответствуют другим критериям, указывает номер очереди по умолчанию
Ниже показана последовательность шагов для настройки очереди на маршрутизаторе:
Ciscol601#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Ciscol601(config)#queue-list 3 protocol ip 1 list 101
C1scol601(config)#queue-list 3 protocol ip 2 tcp telnet
Ciscol601(config)#queue-list 3 protocol ip 3
Ciscol601(config)#queue-11st 3 interface ethernetO 4
CiSCO1601(config)#queue-1ist 3 default 3
Данные команды определяют список под номером 3 для четырех очередей, которые нумеруются от 1 до 4. Смысл команд следующий:
О пакеты, соответствующие списку доступа под номером 101, помещаются в очередь 1;
О пакеты сеанса Telnet помещаются в очередь 2;
О пакеты, поступающие на интерфейс маршрутизатора EthernetO, направляются в очередь 4;
О самая последняя команда указывает маршрутизатору помещать все остальные пакеты, которые не соответствуют вышеперечисленным правилам, в очередь 3 вместе с трафиком протокола IP, который также помещается в эту очередь.
В том случае, если администратор сети не уточнил очередь по умолчанию, Маршрутизатор будет использовать очередь 1. Как и в случае очередей с приоритетами, маршрутизатор проверяет заданные классификационные правила поочередно, и когда обнаруживается совпадение, пакет помещается в соответствующую очередь.
После того как задано соответствие типов пакетов очередям, необходимо определить то количество байтов, которое маршрутизатор может освободить из очереди за один цикл обслуживания. Это осуществляется с помощью команды queue-list, Имеющей следующий формат:
queue-list <номер списка> queue <номер очереди> byte-count <количество байтов>
Здесь параметр byte-count означает максимальное количество байтов для ждой очереди. Приведем пример настройки:■,
C1scol60l#configure terminal'
Enter configuration commands, one per line. End with CNTL/Z.’
Ciscol601(config)#queue-list 3 queue 1 byte-count1000.
Ciscol601(config)#queue-list 3 queue 2 byte-count 2000
Ciscol601(config)#queue-list 3 queue 3 byte-count 1500
Ciscol601(config)#queue-list 3 queue 4 byte-count 500
Из примера видно, что маршрутизатор настроен на освобождение 1000 б за одни цикл из очереди 1, что в два раза меньше, чем для очереди 2. Сле вательно, трафик приложений, обслуживаемых очередью с номером 2, обслуз вается с вдва раза большей пропускной способностью, чем трафик приложен обслуживаемого очередью 1. Остальные очереди настраиваются на освобо» ние 1500 байт (очередь 3) и 500 байт (очередь 4). Необходимо отметить, ’ маршрутизатор не будет следовать буквально этому строгому правилу и ocboi ждать, например, ровно 1500 байт из очереди 3 за один цикл обслуживай], Если 1500-й байт расположен в середине пакета, маршрутизатор опорожн, очередь больше чем на 1500 байт, чтобы не «разрывать» этот пакет. ■
При настройке очередей очень важно учитывать представленную особе ность, так как настройка на слишком малое количество байтов может привес к тому, что в очереди за один цикл будет обслуживаться только один пакет (и малое их количество), а это прямой путь к ухудшению предоставляемого кач ства обслуживания в сети. Другой крайностью будет указание на освобожден за один цикл слишком большого количества байтов. Здесь маршрутизатор буд тратить больше времени на освобождение байтов из одной очереди, задержив обработку следующей. То есть потребуется значительно больше времени на? вершение цикла обслуживания очередей, что опасно «взрывом» трафика. ■ 1
Не существует строгих инструкций на ввод ограничений по количеству выс: бождаемых байтов, так как это количество зависит от многих факторов. К н можно отнести, например, следующие: средний размер пакета для каждого П] ложения, сетевую производительность, которую администратор хочет получт для каждого из приложений, количество используемых очередей и т. п. В качес рекомендации можно привести следующую схему настройки: очередь с сам: низким приоритетом настраивается на освобождение двух или четырех паке- (не байтов) за один цикл обслуживания; очереди с более высоким приоритет масштабируются последовательно с учетом этих установок. На практике это к глядит следующим образом: сначала необходимо получить с помощью сетев: анализатора некоторые характеристики сети, в частности средний размер пак для низкоприоритетного трафика. Затем умножить полученный размер на чй пакетов (скажем, от 2 до 4) для обработки маршрутизатором на каждом ЦЮ В результате получим число байтов для освобождения из низкоприоритет! очереди. Для достижения требуемого качества обслуживания в более прис тетных очередях необходимо рассчитывать число передаваемых байтов отШ тельно очереди с низким приоритетом. Например, если одна из этих очер' должна иметь в два раза большую полосу пропускания, чем низкоприорите)
следует вдвое увеличить количество освобождаемых байтов для последней. В результате получим количество высвобождаемых за один цикл байтов для высокоприоритетной очереди. После создания списка очередей его нужно привязать к требуемому интерфейсу, провести наблюдение за работой приложений и, если требуется, подкорректировать настройки очередей.
Следует исключить из практики настройку освобождаемого количества байтов с таким значением, которое значительно превышает размер пакетов. Например, если таковой для приложения составляет 500 байт, не следует настраивать маршрутизатор на освобождение, скажем, 15 Кбайт за один цикл. Это правило позволяет удовлетворительно работать в большинстве случаев, однако лучше всего соотносить настройку работы настраиваемых очередей с реальным трафи- ’ ком. В последнем рассмотренном примере для очереди #4 указано наименьшее значение для хранения байтов, и хотя за один цикл из этой очереди маршрутизатор освободит 500 байт, она никогда не столкнется с проблемой своего игнорирования, так как определенное обслуживание гарантируется в каждом цикле.
Настроенную очередь необходимо привязать с помощью команды customqueue-list к нужному интерфейсу. Как это сделать, показано ниже:
Ciscol601#configure terminal'
Enter configuration commands, one per line. End with CNTL/Z.
C1SC016O1(conf1g)#interface serial0
Ciscol601(config-if)#custom-queue-list 3
Однако перед тем как выполнять данную команду, следует убрать привязку приоритетной очереди к этому интерфейсу, в противном случае будет выдано сообщение Must remove interface priority queueing (необходимо удалить приоритетную очередь).
Еще раз напомним, что очереди активизируются только при возникновении состояния перегрузки. В нормальном состоянии (при приемлемом объеме трафика) маршрутизатор просто передает пакеты по мере их поступления. После привязки очереди к интерфейсу можно проверить факт ее активности с помощью команд show queuing custom и show interfaces:
C1scol60l#show
queueing custom
Current custom
queue configuration:
List
Queue
Args
3
3
default
3
1
protocol ip
3
2
protocol ip
3
3
protocol ip
3
4
interface EthernetO
3
1
byte-count 1000
3
2
byte-count 1000
3
4
byte-count 500
Ciscol601#show
interfaces serialO
Serial
0 is up.
line protocol is up
list 101
tep port telnet
Queueing strategy: custom-list 3 Output queues: (queue#: size/max/drops) 0: 0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0‘ '
0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0;
0/20/0 16: 0/20/0'
-т
Информация, полученная выполнением этих команд, показывает, что н9 страиваемая очередь активна па интерфейсе SerialO и что существует 16 очере дей, пронумерованных с 1 по 16 (несмотря на то, что очередей 16, трафик от дет классифицироваться только для настроенных очередей). Информация (Й определенной очереди имеет общий вид 0/20/0. Это означает, что на момент вы полнения команды в очереди не было пакетов; очередь может содержать в сео максимум 20 пакетов (это значение по умолчанию); с момента последнего сбрр са счетчика из очереди не удалялся ни один пакет. Необходимо обратить внима ние на то, что существует 17-я очередь с номером 0 — она называется системно! очередью и резервируется для управляющих пакетов, таких как контрбльЙЫ пакеты протокола маршрутизации. Данная очередь обслуживается раньййгвре, прочих..
Если необходимо изменить значение глубины очереди, заданное по умолча нию, это можно сделать с помощью команды queue-list queue limit. Например, за данная в глобальном режиме настройка, показанная ниже, устанавливает макси мальное количество пакетов в очереди 1 равным 40.■*'!
Ciscol601#configure terminalJ
Enter configuration commands, one per line. End with CNTL/Z., ]
Ciscol601(config)#queue-"list 3 queue 1 limit 40
C1scol60l#show interfaces serialOт
SerialO is up. line protocol is up■...ri
Queueing strategy: custom-list 3■
Output queues: (queue #: size/max/drops)
0: 0/20/0 1: 0/40/0 2: 0/20/0 3: 0/20/0 4: 0/20/0. 1
0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0. i ’
0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0'
Как уже упоминалось, при настройке очередей с приоритетами не cyniecTBJi гт абсолютно жесткого регламента на установку лимита глубины очереди. В новном следует стараться не изменять значения, заданные по умолчанию в марш эутизаторах Cisco Systems, особенно если настраиваемая очередь не являете, определяющим фактором при достижении требуемого качества обслуживание Если полученная статистика показывает, что иногда пакеты отбрасываются И низкоприоритетных очередей, можно попробовать поэкспериментировать с тичением глубины очереди на небольшое количество пакетов (на 5-10). j
' очереди на основе классов
Очереди на основе классов (ClassBased Queuing — CBQ) — это подход, при ко. тором трафик делится на несколько классов. Каждый класс имеет собственную очередь, и ему выделяется некоторая часть полосы пропускания канала. Взвешенная справедливая очередь (Weighted Fair Queuing — WFQ) — частный случай очередей CBQ, когда классам соответствуют независимые потоки. Каждому классу сопоставлена одна очередь FIFO, и ей отводится некоторая часть полосы пропускания канала. При этом происходит перераспределение пропускной способности между потоками. Выделение дополнительной пропускной способности для больших потоков позволяет уменьшить задержку при их обработке. Взвешенная справедливая организация очереди является усовершенствованием очереди FQ (Fair Queuing, справедливая организация очереди). Она разбивает потоки на группы и назначает приоритет каждой группе потоков в зависимости от того, какую часть полосы пропускания те используют. Группы потоков со скромными ■ требованиями к ширине полосы пропускания получают более высокий приоритет. При этом время ответа для таких потоков (вероятно, это или интерактивный трафик, или трафик реального времени) значительно улучшается. Кроме того, потокам внутри каждой группы также назначаются приоритеты. Механизм WFQ достаточно эффективен, поэтому во многих случаях использование раз- ■ личных индикаторов приоритета (например, полей «Тип сервиса» в протоколе ' IP или сетевых адресов или портов) не обязательно. Как следствие, от администратора требуется меньше усилий по настройке приоритетов вручную.
" Обработка любой очереди производится каждым сетевым устройством в изо- ■ ляции от других устройств, и нет никакого метода (отличного от сообщения «Подавление источника» (Source Quench) протокола ICMP) передачи информации между промежуточными сетевыми устройствами, чтобы они могли совместно воздействовать на скорость передачи. Поэтому все, что могут дать очереди, — это буферизация пакетов (с неизбежной задержкой), а промежуточным устройствам, не имеющим буферов, остается надеяться, что повторные передачи, вызванные ошибками, не приведут к замедлению трафика.
Настройка взвешенной справедливой очереди WFQ
Взвешенная справедливая очередь — это изощренный процесс организации очере. Деи, который сам по себе требует очень незначительных усилий по конфигура- . Ции, так как динамически распределяет потоки трафика между приложениями и автоматически организует различные очереди для этих потоков. В терминах Данной стратегии очередей эти приложения называют собеседниками (наиболее лизкий перевод английского термина conversations), которые могут быть сеансом Telnet, передачей файла по протоколу FTP, потоками видеоинформации по । протоколу IP, потоками TCP/UDP между клиентом и сервером. Эта стратегия, • Реализуемая на маршрутизаторах, рассматривает пакеты на предмет принадлеж- _ ности определенным собеседникам. Принадлежность определяют по различной I Информации, например по адресам отправителя и получателя, по номерам пор- 1 Тов TCP или UDP и т. п. После определения собеседников и идентификации 1 принадлежащих им пакетов автоматически создается очередь для данного по- Причем при наличии более одного потока на одном интерфейсе маршру-
тизатора организуются дополнительные очереди для каждого потока, a nai
отправляются в соответствующие очереди на основе принадлежности к пото
Так как данная стратегия реализации очередей создает очереди и помещает в
пакеты автоматически, администратору сети не требуется вручную настраив: список классификаций для идентификации различного типа трафика, какч было необходимо в случаях использования очередей с приоритетами и настп
ваемых очередей. Однако, как и в случае использования этих стратегий, вз шенная справедливая очередь начинает работать только при возникновении '
регрузки на исходящем канале связи.у
Для того чтобы применить на практике эту стратегию очередей, достат но на нужном интерфейсе выполнить команду fair-queue. Вообще говоря, ную команду можно не вводить, так как рассматриваемая стратегия очепе; включается по умолчанию на интерфейсах маршрутизаторов компании Q Systems, работающих на скоростях 2 Мбит/с и ниже. При этом даннаякома) не будет отображаться при просмотре настроек маршрутизатора, выполняв^ при помощи команды show running-config. Просмотреть текущие параметры о реди на интерфейсе можно, выполнив команду show queue:
ч
С1sco2511RJ#show queue serial О
Input queue: 0/75/48 (size/max/drops): Total output drops: 4
Queueing strategy: weighted fair
Output queue: 0/64/0 (size/threshold/drops) Conversations 0/2 (active/max active) Reserved Conversations 0/0 (allocated/max allocated)
Если при настройке определенного интерфейса выполнить команду no.fi queue, запрещая тем самым использование взвешенной справедливой очере; на маршрутизаторе будет реализована стратегия очередей FIFO (с учетом.^ что не принимаются во внимание настраиваемые или приоритетные очереди^ Для того чтобы понять, что происходит внутри самого маршрутизатора Щ работе взвешенных справедливых очередей, сначала рассмотрим работу взвешу ных очередей, которые являются базовой формой WFQ (рис. 6.9).
Маршрутизатор обнаружил новый потокМаршрутизатор обнаружил новый потокОчереди освобождаются на равных (fair queuing) или различных (WFQ) скоростяхОчереди освобождаются на равных (fair queuing) или различных (WFQ) скоростяхРис. 6.9. Принцип работы взвешенных очередейРис. 6.9. Принцип работы взвешенных очередей
Маршрутизатор обнаружил новый поток
Маршрутизатор обнаружил новый поток
Очереди освобождаются на равных (fair queuing) или различных (WFQ) скоростях
Очереди освобождаются на равных (fair queuing) или различных (WFQ) скоростях
Рис. 6.9. Принцип работы взвешенных очередей
Рис. 6.9. Принцип работы взвешенных очередей
На рисунке показаны четыре активных потока информации между собеседниками, которые проходят через интерфейс маршрутизатора, и новый поток, который маршрутизатор только что обнаружил. Каждый поток имеет свою собственную очередь на маршрутизаторе, поэтому маршрутизатор динамически создает новую очередь для нового потока, а затем помещает пакеты данного потока во вновь созданную очередь. Например, маршрутизатор заталкивает все пакеты, принадлежащие сеансу Telnet, в третью очередь, а пакеты сеанса FTP между клиентом и сервером — в четвертую очередь. По умолчанию максимальное количество динамически создаваемых очередей на интерфейсе маршрутизатора на заданный момент времени составляет 256. Однако администратор сети может изменить это значение с помощью команды fair-queue, которая должна быть выполнена применительно к нужному интерфейсу. Например, после выполнения команды fair-queue 64 128 можно задать максимум 128 очередей, с ограничением в 64 пакета в одной очереди. Так как каждый отдельный поток между собеседниками имеет свою собственную очередь, то он не сумеет негативно повлиять на производительность других потоков при резком изменении объема передавае- мЗи информации — это создаст перегрузку только в его собственной очереди. Кроме того, если все существующие очереди освобождаются маршрутизатором с одинаковой скоростью, то все очереди получают равные полосы пропускания, доступные им на исходящем канале связи. Это означает, что ни один из потоков не сможет монополизировать полосу пропускания на интерфейсе. Можно проиллюстрировать воздействие взвешенных очередей на трафик разной интенсивности и показать различие между очередями, построенными на базе стратегии FIFO, и взвешенными очередями (рис. 6.10).
Рис. 6.10. Различия очередей с разными стратегиями
На рисунке рассматриваются два типа трафика: пакеты, предлежащие сеансу Telnet (1, 2), характеризующиеся сравнительно небольшой интенсивностью поступления, и пакеты, имеющие отношение к сеансу FTP (А, В, С, D), которые,
напротив, подразумевают высокую интенсивность, то есть формируют траф значительного объема. В рассматриваемом примере два типа потоков проход через интерфейс маршрутизатора, настроенного на использование стратей очереди FIFO. Предположим, что исходящий канал связи перешел в состояв перегрузки до поступления рассматриваемых пакетов (1, 2, А, В, С и D) »j остается в этом состоянии все время, в течение которого эти пакеты поступя^ Естественно, что они будут помещены в очередь. Пакет 1 пришел первым, и мар! рутизатор помещает его в очередь, после этого поступили четыре пакета сеа^ FTP и маршрутизатор помещает их в очередь вслед за пакетом 1. И, накощ последним поступает пакет 2, который оказывается в самом конце очереди. И смотрим теперь, что происходит в процессе выхода из состояния перегруз и начале освобождения очереди. Так как рассматривается стратегия FIFO, май рутизатор просто начинает отправлять пакеты далее по их маршруту по м^ поступления. В том случае, если исходящий канал связи имеет невысокую й рость, потребуется некоторое время для передачи больших пакетов, принадЗ жащих сеансу FTP, что задержит пакет 2. И если эта задержка значителы то пользователь, работающий с сеансом Telnet, ощутит появление пауз меж моментом нажатия клавиш и моментом появления информации на экране.
Изменим ситуацию: рассмотрим использование на маршрутизаторе взвей? ной очереди вместо FIFO. В этом случае пакеты поступают на маршрутизат в том же порядке. Маршрутизатор получает и помещает в очередь пакет 1, но в4 же самое время направляет пакеты сеанса FTP (А, В, С, D) в другую очере* так как они принадлежат другому распознанному потоку. Затем поступает1I кет 2 и помещается в очередь, уже содержащую пакет 1. После того как перегта ка будет устранена, маршрутизатор начнет освобождение очередей. При эт каждой очереди будут предоставлены одинаковые шансы и, следовательно, рави полоса пропускания, доступная на интерфейсе. Это означает, что маршрута тор станет освобождать одинаковое количество байтов из каждой очереди. ЕС предложить, что пакеты 1 и 2 значительно меньше пакетов сеанса FTP по рам ру, то освобождение одинакового количества байтов из каждой очереди пред дет к тому, что несколько небольших пакетов будут выталкиваться параллель с одним большим. Таким образом, после освобождения пакетов 1 и 2 марщ( тизатор освободит пакет А. Но если при этом для сеанса Telnet поступит el несколько небольших пакетов (3, 4 и т. д.), то некоторые из них будут освоС ждены после пакета А, но перед пакетом В. То есть в нашем примере порЯД освобождения очереди будет следующим: 1, 2, А, В, С и D.
Рассмотренный пример показывает, что при использовании взвешенных о* редей низкоинтенсивный трафик (например, сеанс Telnet) не будет блокировав ся серией пакетов, принадлежащих высокоинтенсивному трафику. Более тй даже если подобный трафик поступает на маршрутизатор с очень высокой с^ ростью, он не будет оказывать сильного воздействия па очередь трафика с низ^ интенсивностью.'<
Вместо того чтобы давать каждой потоковой очереди равную долю погр пропускания, существует возможность предоставить некоторым очередям № ответственно, их потокам большую часть полосы пропускания по сравни® с другими. При этом вступает в роль фактор взвешенности, заложенный в1 тегию очередей WFQ. В данном случае маршрутизатор проверяет поле ТОз
головках дейтаграмм протокола IP и рассчитывает так называемый вес (weight) для каждого пакета, который затем используется для определения очередности выхода данного пакета из очереди. Весом является простое число, обычно имеющее значение в пределах между 512 и 4096, которое значимо только по отношению к другим весам. Наименьший вес приводит к наиболее быстрому опорожнению очереди. Например, если очередь потока содержит пакеты с весом 2048, то она будет освобождаться с удвоенной быстротой (байтов в секунду) по сравнению с очередью, пакеты которой имеют вес 4096. При этом размер пакетов во внимание не принимается. Данная схема работы означает, что необходимо только помечать пакеты с требуемым значением приоритетов для организации нужного качества обслуживания.
"Формула для вычисления веса очень простая:
Вес = 4096 / (значение поля TOS + 1)
Например, при значении приоритета, равном двум, вес пакета составит 1365. На старших моделях маршрутизаторов копании Cisco Systems, например Cisco 7500 с установленным модулем VIP, данная стратегия очередей может работать в распределенном режиме, известном как DWFQ (Distributed WFQ). Эта стратегия очередей призвана функционировать на очень высоких скоростях (от 45 Мбит/с ЛО, 155 Мбит/с).
Использование взвешенных справедливых очередей вместе с установкой приоритетов позволяет существенно упростить внедрение технологии качества обслуживания в крупных сетях. Как уже говорилось, если каждый пакет содержит внутри себя биты задания приоритета, он автоматически хранит информацию о требуемом качестве обслуживания. Маршрутизаторы в пути следования пакета от отправителя к получателю проверяют только поле приоритета для получения инструкций о том, как пакет следует обслуживать.
Рекомендации по выбору стратегии очередей
Выбор наиболее подходящей схемы организации очередей включает в себя следующие важные этапы.
•1. Определить, находится ли в состоянии перегрузки канал связи с глобальной сетью. В том случае, если перегрузки нет, нет необходимости в дополнительных действиях. Однако если наблюдаются периоды значительной загрузки канала, то существует возможность формировать пакеты по очередям с помощью нескольких стратегий.
На следующем этапе следует выяснить, требуется ли строгий контроль над делением трафика согласно приоритетам и является ли автоматическая настройка маршрутизатора приемлемой. Следует отметить, что корректная настройка , очередей вовсе не простая задача. Для того чтобы выполнить ее с наибольшей эффективностью, администратор сети должен проанализировать типы трафика, проходящего через рассматриваемый интерфейс, выяснить, как различать разные потоки трафика, и определить относительные приоритеты. Кроме того, следует помнить о том, что характер трафика с течением времени меняется. А это требует регулярного выполнения подобного анализа.
Стратегия очередей основывается на проведенном анализе трафика и опр< лении относительных его приоритетов (обсуждается на шаге 2).
На последнем шаге нужно определить, насколько терпим выделенный - фик к задержкам.
На рис. 6.11 представлен алгоритм действий администратора сети при вй ре типа очереди.
Рис. 6.11. Алгоритм выбора типа очереди
.Ф'1
•W
7
Настройка протоколов маршрутизации
fifiКак известно, существует довольно много протоколов маршрутизации. Но в этой главе рассмотрен только один из них — RIP (Routing Information Protocol). Описание протокола дополнено материалом практической настройки его на маршрутизаторах. Выбор этого протокола не случаен. Пожалуй, трудно ошибиться, утверждая, что протокол RIP в настоящее время является наиболее широко используемым протоколом маршрутизации класса ЮР в частных распределенных сетях, в том числе и в нашей стране. Ведь именно этот протокол в силу своей простоты чаще всего востребуется нашими специалистами.
f
i
f
i
Алгоритмы маршрутизации
[ Определение маршрута передачи данных происходит программно. Соответствую- 1 щие программные средства носят названия протоколов маршрутизации. Логика | их работы основана на алгоритмах маршрутизации. Алгоритмы маршрутизации [ вычисляют стоимость доставки и выбирают путь с наименьшей стоимостью. | Простейшие алгоритмы маршрутизации определяют маршрут на основании наи- I меньшего числа промежуточных (транзитных) узлов на пути к адресату. Более I сложные алгоритмы в понятие «стоимость» закладывают несколько показателей, . например задержку при передаче пакетов, пропускную способность каналов связи или денежную стоимость связи. Основным результатом работы алгоритма ' маршрутизации является создание и поддержка таблицы маршрутизации, в которую записывается вся маршрутная информация. Содержание таблицы маршрутизации зависит от используемого протокола маршрутизации. В общем случае таблица маршрутизации содержит следующую информацию:
' О Действительные адреса устройств в сети;
О служебную информацию протокола маршрутизации;
| О адреса ближайших маршрутизаторов.
■• Основными требованиями, предъявляемыми к алгоритму маршрутизации,
являются:
1 О оптимальность выбора маршрута;
простота реализации;
о о оо о оустойчивость;,,,быстрая сходимость;jгибкость реализации.'Алгоритмы маршрутизации должны быть просты в реализации и требонустойчивость;,,,быстрая сходимость;jгибкость реализации.'Алгоритмы маршрутизации должны быть просты в реализации и требонкак можно меньше ресурсов. Они также должны быть устойчивыми к| зам оборудования на первоначально выбранном маршруте, высоким нагр^ и ошибкам в построении сети.как можно меньше ресурсов. Они также должны быть устойчивыми к| зам оборудования на первоначально выбранном маршруте, высоким нагр^ и ошибкам в построении сети.Г*Г*Основной характеристикой алгоритма маршрутизации является скорость 1 димости. Сходимость — это процесс согласования между маршрутизаторами^ формации о топологии сети, приводящий ее в стабильное состояние. Если ой деленное событие в сети приводит к тому, что некоторые маршруты станов^ недоступны или возникают новые маршруты, маршрутизаторы рассылают cd щения об этом друг другу по всей сети. Получив эти сообщения, маршрутйза ры выполняют переназначение оптимальных маршрутов, что, в свою очей может породить новый поток сообщений. Данный процесс должен завершим причем достаточно быстро, иначе в сетевой топологии могут появиться п& или сеть вообще перестанет функционировать. Алгоритмы маршрутизации aoj ны быстро и правильно учитывать изменения в состоянии сети (напримерлОсновной характеристикой алгоритма маршрутизации является скорость 1 димости. Сходимость — это процесс согласования между маршрутизаторами^ формации о топологии сети, приводящий ее в стабильное состояние. Если ой деленное событие в сети приводит к тому, что некоторые маршруты станов^ недоступны или возникают новые маршруты, маршрутизаторы рассылают cd щения об этом друг другу по всей сети. Получив эти сообщения, маршрутйза ры выполняют переназначение оптимальных маршрутов, что, в свою очей может породить новый поток сообщений. Данный процесс должен завершим причем достаточно быстро, иначе в сетевой топологии могут появиться п& или сеть вообще перестанет функционировать. Алгоритмы маршрутизации aoj ны быстро и правильно учитывать изменения в состоянии сети (напримерлказ узла или сегмента сети).каз узла или сегмента сети).о о о о оо о о о оАлгоритмы маршрутизации могут быть: статическими или динамическими; одномаршрутными или многомаршрутными; одноуровневыми или иерархическими; внутридоменными или междоменными; одноадресными или групповыми.Алгоритмы маршрутизации могут быть: статическими или динамическими; одномаршрутными или многомаршрутными; одноуровневыми или иерархическими; внутридоменными или междоменными; одноадресными или групповыми.эцэц
о о о
о о о
устойчивость;,,,
быстрая сходимость;j
гибкость реализации.'
Алгоритмы маршрутизации должны быть просты в реализации и требон
устойчивость;,,,
быстрая сходимость;j
гибкость реализации.'
Алгоритмы маршрутизации должны быть просты в реализации и требон
как можно меньше ресурсов. Они также должны быть устойчивыми к| зам оборудования на первоначально выбранном маршруте, высоким нагр^ и ошибкам в построении сети.
как можно меньше ресурсов. Они также должны быть устойчивыми к| зам оборудования на первоначально выбранном маршруте, высоким нагр^ и ошибкам в построении сети.
Г*
Г*
Основной характеристикой алгоритма маршрутизации является скорость 1 димости. Сходимость — это процесс согласования между маршрутизаторами^ формации о топологии сети, приводящий ее в стабильное состояние. Если ой деленное событие в сети приводит к тому, что некоторые маршруты станов^ недоступны или возникают новые маршруты, маршрутизаторы рассылают cd щения об этом друг другу по всей сети. Получив эти сообщения, маршрутйза ры выполняют переназначение оптимальных маршрутов, что, в свою очей может породить новый поток сообщений. Данный процесс должен завершим причем достаточно быстро, иначе в сетевой топологии могут появиться п& или сеть вообще перестанет функционировать. Алгоритмы маршрутизации aoj ны быстро и правильно учитывать изменения в состоянии сети (напримерл
Основной характеристикой алгоритма маршрутизации является скорость 1 димости. Сходимость — это процесс согласования между маршрутизаторами^ формации о топологии сети, приводящий ее в стабильное состояние. Если ой деленное событие в сети приводит к тому, что некоторые маршруты станов^ недоступны или возникают новые маршруты, маршрутизаторы рассылают cd щения об этом друг другу по всей сети. Получив эти сообщения, маршрутйза ры выполняют переназначение оптимальных маршрутов, что, в свою очей может породить новый поток сообщений. Данный процесс должен завершим причем достаточно быстро, иначе в сетевой топологии могут появиться п& или сеть вообще перестанет функционировать. Алгоритмы маршрутизации aoj ны быстро и правильно учитывать изменения в состоянии сети (напримерл
каз узла или сегмента сети).
каз узла или сегмента сети).
о о о о о
о о о о о
Алгоритмы маршрутизации могут быть: статическими или динамическими; одномаршрутными или многомаршрутными; одноуровневыми или иерархическими; внутридоменными или междоменными; одноадресными или групповыми.
Алгоритмы маршрутизации могут быть: статическими или динамическими; одномаршрутными или многомаршрутными; одноуровневыми или иерархическими; внутридоменными или междоменными; одноадресными или групповыми.
эц
эц
Для статических (неадаптивных) алгоритмов маршруты выбираются зар^й и заносятся вручную в таблицу маршрутизации, где хранится информация oJ(™ па какой порт следует отправлять пакет с определенным адресом. Протокол разработанные на базе статических алгоритмов, называют немаршрутизируем^ протоколами. Примером немаршрутизируемых протоколов может служить прет кол LAT (Local Area Transport — транспортный протокол для локальных ооди тей) фирмы DEC. Обычно с этими протоколами работают мосты, так как онэд различают протоколов сетевого уровня. Ч1
При использовании динамических алгоритмов таблица маршрутизации авИи тически обновляется при изменении топологии сети или трафика в ней.ДЗД мические алгоритмы различаются по способу получения информации о ссм^И нии сети, времени изменения маршрутов и используемым показателям онеч маршрута.
Одномаршрутные алгоритмы определяют только один маршрут. Он не веет оказывается оптимальным. Многомаршрутные алгоритмы предлагают несК&су маршрутов к одному и тому же получателю. Такие алгоритмы позволяю^ редавать информацию получателю по нескольким каналам одновременной означает повышение пропускной способности и надежности сети. <.$■
| Длгоритмы маршрутизации могут работать в сетях с одноуровневой или иерар- i веской архитектурой. В одноуровневой сети все ее фрагменты имеют одинаковый приоритет, что, как правило, обусловлено схожестью их функционального назначения. Иерархическая сеть содержит подсети (фрагменты сети). Маршрутизаторы нижнего уровня служат для связи фрагментов сети. Маршрутизаторы верхнего уровня образуют особую часть сети, называемую магистралью. Маршрутизаторы магистральной сети передают пакеты между сетями нижнего уровня.
Иерархическая структура в больших и сложных сетях позволяет значительно упростить процесс управления сетью, облегчает изоляцию сегментов сети и т. д.
Некоторые алгоритмы маршрутизации действуют только в пределах своих доменов (внутридоменная маршрутизация), другие — как в пределах своих доменов, так и в смежных с ними (междоменная маршрутизация). В данном случае домен означает область маршрутизации, в которой работает один или несколько протоколов маршрутизации. В разных доменах работают разные протоколы. Если необходима связь доменов, используется междоменная маршрутизация.
Одноадресные алгоритмы маршрутизации предназначены для передачи конкретной информации (по одному или нескольким маршрутам) только одному получателю. Многоадресные (или групповые) алгоритмы способны передавать информацию многим получателям одновременно.
Когда маршрутизатор получает пакет, он считывает адрес назначения и определяет, по какому маршруту отправить пакет. Обычно маршрутизаторы хранят данные о нескольких возможных маршрутах. Выбор маршрута зависит от нескольких факторов, в числе которых:
' О применяемая система измерения длины маршрута (его метрика);
О маршрутизируемый протокол высокого уровня;
О топология сети.
На уровне маршрутизации существуют три основные группы протоколов
маршрутизации (деление на группы определяется типом реализуемого алгорит
ма выявления оптимального маршрута):
О протоколы длины вектора;
О протоколы состояния канала;
О протоколы политики маршрутизации.
Протоколы длины вектора — самые простые и самые распространенные. Данная группа включает в себя RIP IP, RIP IPX, AppleTalk RTMP и Cisco IGRP. Свое название этот тип протокола получил от соответствующего способа обмена информацией. Маршрутизатор с определенной периодичностью извлекает данные из своей таблицы маршрутизации и помещает их в рассылаемые соседям сообщения об обновлении (можно сказать, что он рекламирует имеющуюся ин. . Формацию). Соседние маршрутизаторы сверяют полученные данные со своими i собственными таблицами маршрутизации и вносят необходимые изменения. По- I Сле этого они сами рассылают сообщения об обновлении. Таким образом, каждый 1 МарщруТИЗаТ0р получает информацию о маршрутах во всей сети. При очевидной
простоте алгоритма говорить о полной его надежности нельзя. Он может тать эффективно только в небольших сетях. Это связано с тем, что в кру сетях поток сообщений между маршрутизаторами на порядок интенсийЙ? этом большинство сообщений являются избыточными (так как изменения вой топологии происходят довольно редко). Как следствие — действитель; обходимая информация подчас долго «гуляет» по всей сети, и маршрутиз обновляют свои таблицы с большой задержкой. Так, уже не существу: маршрут может долго оставаться в таблицах маршрутизации, а трафик, н! ленный по такому маршруту, не достигнет своего адресата.
Протоколы состояния канала были впервые предложены в 1970 году ром Дейкстрой. Эти протоколы значительно сложнее, чем протоколы вектора. Вместо рассылки соседям содержимого своих таблиц маршруты каждый маршрутизатор осуществляет широковещательную рассылку сд маршрутизаторов, с которыми он имеет непосредственную связь, и списка нг мую подключенных к нему локальных сетей. Эта информация является ча информации о состоянии канала и рассылается в специальных сообщениях,, ме того, маршрутизатор распространяет сообщения о состоянии канала тр* в случае его изменения или по истечении заданного интервала времени. П^ колы состояния канала трудны в реализации и нуждаются в значительном) еме памяти для хранения служебной информации. Примерами этих протоку служат OSPF, IS-IS, Novell NLSP и Cisco EIGRP.
По Дейкстре, топология сети представляется в виде неориентированного гра Каждому ребру приписывается некоторое значение. В процессе работы алго^ ма вычисляется сумма показателей для ребер, сходящихся в каждом узле грг Эта оценка называется меткой узла. При определении пути подсчитывается cyi меток на возможном пути и выбирается путь с наименьшей суммарной метк
К третьей группе протоколов относятся протоколы политики (правил) мд рутизации. Такие протоколы наиболее эффективно решают задачу достд информации получателю. Данная категория протоколов используется при м^ рутизации в Интернете и позволяет провайдерам получать информацию о ш рутизации от соседних провайдеров на основании специальных критер) Таким образом, в процессе обмена вырабатывается список разрешенных ма; рутов (путей). Алгоритмы политики маршрутизации опираются на алгориз длины вектора, но информация о маршрутах базируется на списке оператор Интернета. Примерами протоколов данной категории могут служить BGP и ЕС
Протокол маршрутизации RIP,
Протокол RIP достаточно прост. Протоколы этой группы очень часто назьгв протоколами Беллмана-Форда (Bellman-Ford), так как они опираются на ритм выбора кратчайшего пути (shortest path computation algorithm), описа! еще,в 1957 году. Протоколы длины вектора использовались в некоторых п ных сетях. Наиболее известной в России является сеть ARPAnet. В Инте протокол RIP был изначально внедрен как компонент BSD UNIX. 11
Итак, RIP является протоколом длины вектора. Для того чтобы объяснить принцип действия протокола, рассмотрим простую сеть, состоящую из 5 маршрутизаторов и 6 каналов связи (рис. 7.1).
Рис. 7.1. Пример сети из 5 маршрутизаторов
Отмстим, что эта конфигурация сети выбрана только с целью пояснения работы протокола, по, опираясь на теорию и полученную практику, можно внедрить протокол RIP практически в любой среде, учитывая только его ограничения. Для рассмотрения принципов действия не будем обращать внимания как на типы каналов, связывающих маршрутизаторы, так и па сами маршрутизаторы. В этой сети может работать оборудование компании Cisco Systems или, например, это могут быть программные маршрутизаторы на базе Windows NT/2000.
В реальной сети каждый маршрутизатор будет идентифицировав с помощью IP-адреса и с помощью имени (первое, естественно, важнее с точки зрения сетевой идентификации). Для того чтобы далее при рассмотрении примера было проще ссылаться на конкретные устройства, присвоим всем маршрутизаторам символьные обозначения (А, В, С, D и Е), которые в реальной ситуации и будут их адресами. Кроме того, каждый канал связи между маршрутизаторами также получает свой номер (1-6).
Каждому маршрутизатору при начальном запуске необходимо определить собственный адрес и подключенные к нему каналы связи. Эту информацию можно охарактеризовать как локальную, так как в данный момент времени маршрутизаторы знают только о своем внутреннем состоянии и полностью игнорируют окружающую их сетевую топологию. Маршрутизатор «не знает» о том, сколько помимо него существует в сети маршрутизаторов. У него нет даже информации ° том, какое устройство расположено на другом конце канала связи. В этом начальном состоянии работы маршрутизатора его таблица маршрутизации содержит только одну запись — запись о самом себе. Таким образом, таблица маршРутизации маршрутизатора А будет следующей.
А кКаналСтоимость
*ЛокальныйО
Обратим внимание на третью колонку таблицы (стоимость), поскольку д по тексту мы будем постоянно пользоваться понятием стоимости марщр Длина вектора А = О, или, другими словами, первоначальная стоимость март та равна нулю. После того как маршрутизатор А загрузился и привел в дейс протокол RIP, он начинает рассылать эту таблицу всем своим соседям, или более точно, он инициирует рассылку на все подключенные к нему каналы зи (интерфейсы). В результате оба маршрутизатора В и D получат эту ин< мацию и пополнят свои знания о сетевой топологии.
Рассмотрим теперь маршрутизатор В. До получения сообщения от марг тизатора А его таблица маршрутизации также состояла из одной записи.
От В кКаналСтоимость
ВЛокальныйО
Маршрутизатор В получает через канал с номером 1 стоимость А = 0. П получения этого сообщения он обновляет свои записи, добавляя к ним стоим локального канала (на данном этапе предположим, что она равна 1), преобр; полученное сообщение в А = 1. После обновления стоимости маршрутизак проверит свою таблицу маршрутизации и узнав, что она не содержит инфо; ции о маршрутизаторе А, добавит одну запись.
От В кКаналСтоимость,
ВЛокальный0,
А11.■/
---
Затем маршрутизатор В сформирует свою собственную запись о стоим< маршрутов (В = 0, А = 1) и пошлет ее через подключенные к нему каналы 0 мерами 1, 4 и 2. Так как маршрутизатор А отправил свою таблицу не тол маршрутизатору В, но и маршрутизатору D, то последний также обновит сз таблицу маршрутизации и разошлет обновленную запись о стоимости мари тов (D = 0, А = 1) через каналы 3 и 6.д
От D к
Канал
СтоимостьДД
D
Локальный
0■
*
А
3
1
Сообщение от маршрутизатора В получат маршрутизаторы А, С и Е. А' маршрутизатора D — маршрутизаторы А и Е. Для того чтобы упростить иЖ
жение, предположим, что сообщение от маршрутизатора В поступило перз
Приняв это сообщение,Приняв это сообщение,маршрутизатормаршрутизаторА обновит свою запись и устанО
Приняв это сообщение,
Приняв это сообщение,
маршрутизатор
маршрутизатор
стоимости маршрутов равными В = 1, А = 2. Обнаружив стоимость маршрУ равную 2, что больше, чем значение в локальной таблице маршрутизации, м рутизатор А проигнорирует эту информацию и добавит в таблицу только за В = 1. Затем, приняв сообщение от маршрутизатора D, он также присоед: запись D = 1, формируя следующую таблицу. *
От А к
Канал
Стоимость
А
Локальный
0
в
1
1
D
3
1
Маршрутизатор С получит запись о стоимостях В = О, А = 1 через канал 2 И обновит свою таблицу следующим образом.
От С к
Канал
Стоимость
С
Локальный
0
в
2
1
А
2
2
Маршрутизатор Е также получит запись В = 0, А = 1 через канал 4 и обновит свою таблицу.
ОтЕ к
Канал
Стоимость
Е
Локальный
0
В
4
1
А
4
2
Кроме того, маршрутизатор Е затем получит запись D = О, А = 1 через канал с номером 6, обновит стоимости маршрутов D = 1, А = 2 и затем обнаружит, что информация о маршрутизаторе D отсутствует в его таблице маршрутизации и, следовательно, должна быть вставлена. Расстояние до маршрутизатора А через канал 6 равна расстоянию до этого маршрутизатора через канал 4. Предположим, что в таком случае маршрутизатор воздержится от обновления своей таблицы. Результирующая таблица маршрутизации примет следующий вид.
ОтЕ к
Канал
Стоимость
Е
Локальный
0
В
4
1
А
4
2
D
6
1
После того как маршрутизаторы А, С и Е сформируют свои локальные таблицы МаРшрутизации, они обобщат информацию и вычислят новые стоимости маршрутов, которые вновьбудут посланычерез подключенные к ним каналы связи.
О от А через каналы1 и 3: А =О, В= 1, D =1;
от С через каналы2 и 5: С =О, В= 1, А =2;
от Е через каналы4, 5 и 6: Е= О,В = 1, А= 2, D = 1.
Получение соседними маршрутизаторами новой информации вызовет мирование следующих таблиц.
От В кКаналСтоимость
ВЛокальныйО
А11
D12
С21
От D к
Канал
Стоимость
D
Локальный
о-
А
3
14
В
3
20
Е
6
.а
От Е кКаналСтоимость
ЕЛокальныйО
В41
а42
D61
С5 1_____*.
Маршрутизаторы В, D и Е теперь могут подсчитать свои собственные ст мости:. /
ОотВ через каналы 1, 2и 4: В - О, А = 1, D - 2, Е = 1;
ОотD через каналы 3 и6: D = О, А = 1, В = 2, Е = 1;3
ОотЕ через каналы 4, 5и 6: Е = О, В = 1, А = 2, D = 1.
Эти стоимости будут разосланы в сообщениях, заставляя маршрутизаторы. С и D обновить свои таблицы.
От А кКаналСтоимость
АЛокальныйОГ
В11
D31
С12
От с К
Канал
Стоимость
С
Локальный
0
в
2
1
А
2
2
Е
5
1
D
5
2
ОтОк
Канал
Стоимость
D
Локальный
0
А
3
1
В
3
2
Е
6
1
С
6
2
На этой стадии можно говорить о том, что наступил момент схождения, так как несмотря на то что маршрутизаторы вновь подготовят свои стоимости маршрутов и разошлют их соседям в своих сообщениях, это не повлечет за собой каких-либо изменений в таблицах маршрутизации. Фактически, все маршрутизаторы в рассматриваемой распределенной сети определили сетевую топологию.
После того как маршрутизаторы построили свои таблицы, они знают марш* руты во все сети (если отойти от введенных обозначений и возвратиться к адресной схеме протокола IP). Рассматриваемая сеть предполагает некоторую избыточность. Так, например, от маршрутизатора Е к маршрутизатору А ведут два разных пути. В реальной же жизни такое бывает нечасто (гораздо чаще встречается противоположная ситуация — избыточность каналов связи отсутствует). Поэтому очень важно рассмотреть такой крайний случай, как поведение протокола маршрутизации RIP при обрыве канала связи. Предположим, что произошел обрыв канала с номером 1. В результате сетевая топология примет вид, показанный на рис. 7.2.
Рис. 7.2. Обрыв канала связи
Это возможно, если.Это возможно, если.связи 1 проблемысвязи 1 проблемыДопустим, что маршрутизаторы А и В обнаруживают возникшие с к;
Это возможно, если.
Это возможно, если.
связи 1 проблемы
связи 1 проблемы
например, отслеживается работосп
ность подключенного сетевого оборудования. В этом случае они должны ц ленно обновить свои таблицы маршрутизации с учетом того, что канал 1 i
теперь стоимость, равную «бесконечности», и что все другие маршрутиза' до того достижимые через капал 1, теперь недоступны. Новые таблицы мар тизации примут следующий вид.
От А к
Канал
Стоимость
А
Локальный
0
В
1
Inf (оо)
D
3
1
С
1
Inf (со)
Е
1
Inf (оо)
От В к
КаналСтоимость
В
Локальный0■• ня
А
1Inf (ос)
D
1Inf (оо),
С
21.Щ
Е
41’«Ц
Маршрутизаторы А и В подготовят и пошлют свои новые стоимости: ? О от А через канал 3: А = О, В = Inf, D = 1, С = Inf, Е = Inf;'
О от В через канал 2 и 4: В = О, А = Inf, D = Inf, С = 1, Е = 1.,
Сообщение от маршрутизатора А будет получено маршрутизатором
обнаружит.обнаружит.торый обновит стоимости маршрутов, принимая во внимание стоимость кг связи с номером 3: А = 1, В = Inf, D = 2, С = Inf, Е = Inf. Эта запись буд№
обнаружит.
обнаружит.
МаршрутизаторМаршрутизаторйена с записями в таблице маршрутизации.
Маршрутизатор
Маршрутизатор
все стоимости больше или равны значений в соответствующих записях
лицы. Исключение составит канал 3, только через который и можно дос’ маршрутизатора В, и поэтому запись для маршрутизатора В должна быт§
новлена. Новая таблица примет такой вид.
От О к
Канал
Стоимость
D
Локальный
0
А
3
1
В
3
Inf (со)
Е
6
1
С
6
2_
I
■ Аналогично, маршрутизаторы С и Е обновят свои таблицы.
От С к
Канал
Стоимость
С
Локальный
0
в
2
1
А
2
Inf (=о)
Е
5
1
D
5
2
От Е К
Канал
Стоимость
Е
Локальный
0
В
4
1
А
4
Inf (=о)
D
6
1
С
5
1
Эти три маршрутизатора подготовят и вышлют свои новые стоимости маршрутов:
О от D через каналы 3 и 6: D = О, А = 1, В = Inf, Е = 1, С = 2;
• О от С через каналы 2 и 5: С = О, В = 1, А = Inf, Е = 1, D = 2;
О от Е через каналы 4, 5 и 6: Е = О, В = 1, А = Inf, D = 1, С = 1.
Сообщения, содержащие информацию о стоимости маршрутов, приведут к обновлению таблиц маршрутизации на маршрутизаторах А, В, D и Е:
От А к
Канал
Стоимость
А
Локальный
0
в
1
Inf (оо)
D
3
1
С '
3
3
Е -
3
2
От В к
Канал
Стоимость
В
Локальный
0
А
1
Inf (со)
D
4
2
С
2
1
Е
4
1
к
От D кКаналСтоимость
D
Локальный
0
А
3
1J
В
6
2‘^
Е
6
С
6
2
От Е к
КаналСтоимость.«
Е
Локальный0J
В
41
А
62
D
61?
С
51'
Получив очередные сообщения, маршрутизаторы А, В, D и Е вышлют.^ новые стоимости маршрутов:„'
О от А через канал 3: А = О, В = Inf, D = 1, С = 3, Е = 2;
О от В через канал 2 и 4: В = О, А = Inf, D = 2, С = 1, Е = 1;
О от D через каналы 3 и 6: D = О, А = 1, В = 2, Е = 1, С = 2;/
О от Е через каналы 4, 5 и 6: Е = О, В = 1, А = 2, D = 1, С = 1.■. ■'
Эти сообщения приведут к обновлению таблиц маршрутизации. ’
От А к
КаналСтоимость-
А
Локальный0
В
33■
D
31
С
33
Е
32_
От В к
КаналСтоимость
В
Локальный0
А
43
D
42
С
21
Е
41
нрлтокол маршрутизации RIP
285
"6т С к
Канал
Стоимость
Т
Локальный
0
в
2
1
А
5
3
Е
5
1
D
5
2
Маршрутизаторы А, В и С подготовят и вышлют свои собственные стоимости маршрутов, по это не приведет к изменению таблиц. В результате новые маршруты полностью определены и общая связь в распределенной сети восстановлена.
Возвратимся к теме избыточных (резервных) каналов связи. Теоретически ничто не мешает их построению, однако в реальности администратор столкнется со множеством разнообразнейших факторов, мешающих реализации подобной идеи по месту. Прежде всего, сегодня у нас практически невозможно детально спланировать распределенную сеть с учетом всех каналов связи, их скорости и т. п. Этот тезис вступает в противоречие с многочисленными утверждениями англоязычных авторов о том, что сеть с самого начала надо планировать, и планировать как можно детальнее. Не исключено, что, например, в США или в Европе создание и практическая реализация подробного плана распределенной сети вполне осуществима, однако сегодня в России — сомнительно. Ситуация, когда крупная компания заключает договор с провайдером услуг связи и в дальнейшем продолжает работу только с ним, может быть отнесена, скорее, к исключительной. Но спрашивается: все ли готовы платить высокую арендную плату за такого рода услуги? Вот и получаются ситуации, когда сеть в конечном итоге начинает походить на некую «окрошку» из выделенных каналов связи, технологий Frame Relay, ISDN и т. д. Причем, что характерно, под влиянием внешних факторов технологии постоянно вытесняют, заменяют друг друга. В ход идет все, что дешевле и, соответственно, выгодней компании. То же говорит и собственный опыт управления и развития сети, первоначально построенной только с использованием каналов Frame Relay, — по прошествии достаточно короткого промежутка времени остро встал вопрос о повышении скоростей передач. На взгляд западного специалиста естественным решением может быть простая заявка своему провайдеру на повышение скорости. У нас это дорого. Поэтому мы «пошли другим путем» и попробовали своими силами организовать связь объектов, используя прямые провода и модемы серии xDSL. Работает. Однако если в технологии Frame Relay соединения являются виртуальными и задействуют только один физический интерфейс, то для подключения модемов xDSL требуется отдельный интерфейс и, следовательно, при этом частично меняется схема 5?ти. Таким образом, вопрос избыточности обычно упирается в технические возможности и готовность платить деньги.
'И М ЕЧ АН И Е——
Технология xDSL (Digital Subscriber Line) — это обобщенное название группы технологий. Веет логии этой группы делятся в основном по способу разделения встречных потоков данных (чг ное разделение потоков данных, метод эхоподавления и т. д.). При этом встречные потоки i
быть как симметричными, так и асимметричными. Технология xDSL позволяет передавать вой сигнал по телефонной сети общего назначения. "*“* Для этого на концах абонентской линии устанавливаются разделительные фильтры. Фильтр назначены для отделения высокочастотной составляющей, на которой работают мод®ьп
низкочастотной составляющей (до 3,5 кГц) для телефонного оборудования общего назначен^? модемов xDSL на высокой частоте позволяет им значительно превысить скоростной предел ра<
обычных модемов, который составляет 56 Кбит/с. Например, технология ADSL (Asymmetric D Subscriber Line — асимметричный DSL) позволяет поддерживать скорость к абоненту до 6,1 Мо а от абонента — до 640 Кбит/с. Кроме того, технология xDSL позволяет одноврёМёЙЙ8*^^| по одной и той же телефонной'линии цифровые данные и вести обычные телефонные перегов Использование обычных модемов не позволяет делать этого. Установка модемов технологии: на абонентской стороне ничем не отличается от установки обычных модемов. На территорий' провайдер развертывает оборудование, соединяющее абонента с базовой сетью передачи дани Более широкую полосу пропускания можно получить при использовании выделенных линий- пример, медной пары между объектами, перекрещенной на промежуточных АТС). Для этого q ствуют специальные модемы, которые, работая на больших расстояниях, обеспечивают ско|х до 2 048 Кбит/с. Эти модемы могут взаимодействовать как в синхронном, так и в асинхронной жимах. Дальность передачи зависит от качества физической линии, в частности от диаметра.^ ния проводов, от количества проводников в линии и от скорости передачи. ,,;
Для простоты изложения стоимость всех каналов связи была равна единю На практике все сложнее: некоторые каналы медленнее других или, напри^ их использование дороже в денежном выражении. Предположим, что стоимр1 канала с номером 5 равна 10, в то время как стоимость всех остальных канал остается равной 1. а
Рассмотрим маршруты от разных частей сети к маршрутизатору С. В стаби! но работающей сети после успешного запуска всех маршрутизаторов будут1 т вестны следующие маршруты. ' :‘т-
НЕ
Направление
Канал
Стоимость’
А-С
1
2
В-С
2
1
D-C
3
3
■К
Е-С
4
2
Теперь допустим, что канал связи с номером 2 становится недоступна Этот сбой немедленно обнаруживает маршрутизатор В, и через некоторое вре маршруты к маршрутизатору С будут выглядеть так. ’?
Направление
Канал
СтоимостьТ
А-С
1
2Д
В-С
2
Inf
D-C
3
3'.
Е-С
4
2j
Предположим, что перед тем как маршрутизатор В отправит свою запись 0 стоимостях своим соседям, маршрутизатор А посылает свою таблицу маршрутизаторам В и D. Большинство реализаций протоколов, использующих алгоритм длины вектора, подразумевают, что сообщения должны посылаться регулярно через определенные интервалы времени. Это нужно для того, чтобы справиться с потерями пакетов в сети в случае возникновения непредвиденных ситуаций. Такая ложная передача вполне может иметь место. Это сообщение маршрутизатора А не существенно для маршрутизатора D, так как указываемые стоимости маршрутов уже находятся в его таблице. Но маршрутизатор В добавит стоимость, равную 1, к стоимости 2, рассылаемой маршрутизатором А, и поймет, что конечная стоимость, равная 3, меньше, чем стоимость, равная бесконечности, которая была записана в его таблице. В результате он обновит таблицу с указанием заведомо ложной стоимости маршрута к маршрутизатору С. Новая таблица указывает на то, что маршрутизатор С стал достижим через канал связи 1 со стоимостью 3. Теперь маршрутизатор В начнет рекламировать новую запись своим соседям — маршрутизаторам А и Е. Эти сообщения поступят к ним через каналы с номерами 1 и 4, и маршрутизаторы обновят свои таблицы следующим образом.
Направление
Канал
Стоимость
А —С
1
4
В-С
1
3
D-C
3
3
Е —С
4
4
Следует обратить внимание на то, что с текущего момента таблица маршрутизации содержит петлю (loop) — пакеты от маршрутизатора С будут достигать маршрутизатора В, затем «отскакивать» от него и двигаться между А и В до тех пор, пока время их жизни в сети не кончится. Это явление называется эффектом прыжка (bouncing effect). Оно прекратится только тогда, когда сеть перейдет в стабильное состояние (сойдется) и стоимости маршрутов будут правильно отображаться в таблицах маршрутизации.
Если в этот момент маршрутизатор С известит о своей стоимости маршрутов через канал связи 5, то маршрутизатор Е добавит стоимость 10 к входящей стоимости, равной 0. При этом он обнаружит, что итоговая стоимость в таблице маршрутизации превышает текущую, и проигнорирует полученные сообщения. Теперь, если маршрутизаторы А и Е разошлют свои новые стоимости маршрутов, это приведет к обновлению таблицы маршрутизации на В и D.
НаправлениеКанал
Стоимость
А-С1
В-С1
D —С3
4
5
5
^С4
4
L
После того как маршрутизатор В передаст
■ свою собственную запись о crtutJ
стих, стоимость маршрута к маршрутизатору
С на маршрутизаторе А ува^^Д
до 6. Маршрутизатор А будет рекламировать новую стоимость маршрутов к D ™
Направление
Канал
Стоимость
А —С
1
6
В-С
1
7
D-C
Е — С
3
4
7
6Л
На этой стадии сообщения, посылаемые
маршрутизатором С, будут игнвм
роваться маршрутизатором Е, так как стоимость маршрута к С на нем всеЛ меньше 10. На самом деле при каждом обмене маршрутами стоимость марптаД
до С будет увеличиваться на 2 на каждом из маршрутизаторов А, В, D и Е, Л
еле следующего
«раунда» обмена таблица преобразуется к следующей. Ж
Направление
Канал
Стоимость
А —С
1
8
В-С
1
9
D —С
3
9
Е-С
4
8"<9
Очередное сообщение от маршрутизатора В приведет к обновлению запи
о стоимости маршрута на маршрутизаторе
А. Она станет равной 10. Марта
тизатор Л перешлет новое значение маршрутизаторам В и D, которые увелМ
свои стоимости до 11. Затем маршрутизатор
В передаст значение стоимости,
нос 11, маршрутизаторам А и Е. Текущая картина такова.
Направление
Канал
Стоимость
А-С
1
12
В-С
1
11
D-C
3
И"^
Е-С
4
12
Теперь уже маршрутизатор Е, получая сообщение от маршрутизатора С, Я
мет его во внимание и вычислит новые значения.
Направление
Канал
Стоимость^
А-С
1
12
В-С
4
11
D-C
6
Е-С
5
10j
Наконец можно сказать, что все вычисления закончены. На постепенное увеличение стоимостей маршрутов потребовалось несколько шагов. Учитывая, что один раунд обмена увеличивает стоимость маршрута на 2 единицы, нам потребуется 5 таких раундов для достижения значения стоимости, равного 10, которое необходимо для перехода к следующему шагу. Следует отметить, что это случайный процесс, так как результат может варьироваться в зависимости от порядка передачи сообщений маршрутизаторами. Также важным обстоятельством является то, что промежуточная стадия может оказаться очень «болезненной» для сети. Это связано с тем, что при образовании петель может возникнуть перегрузка каналов связи. Кроме того, в этот период вполне вероятна потеря пакетов, в том числе пакетов, содержащих информацию о новых стоимостях маршрутов, что также приведет к задержке достижения сходимости.
Счет до бесконечности
Предположим, что в нашей распределенной сети произошел обрыв двух каналов связи — 1 и 6. При этом маршрутизаторы А и D окажутся изолированными от остальных маршрутизаторов в сети. Остановимся на процессах, происходящих на маршрутизаторах А и D. Последний после обнаружения обрыва обновил свою таблицу маршрутизации следующим образом.
От D к
Канал
Стоимость
D
Локальный
0
А
3
1
В
6
Inf
Е
6
Inf
С
6
Inf
Если маршрутизатор D получит возможность немедленной передачи своих стоимостей маршрутов, то маршрутизатор А по поступлении сообщения от маршрутизатора D обновит свою таблицу и обнаружит, что все маршрутизаторы, за исключением D, в настоящий момент недостижимы. Однако если А передаст раньше свои последние стоимости маршрутов (А = 0, В = 3, D = 3, С = 3, Е = 3), то таблица маршрутизации па маршрутизаторе D примет следующий вид.
От D к
Канал
Стоимость
D
Локальный
0
A
3
1
В
3
4
E
3
4
C
3
4
В результате образуется логическая петля, как и в предыдущем примере 'б фектом скачка. Однако так как маршрутизаторы В, С и Е теперь изолиров: то эта сеть не имеет шансов самостоятельно перейти в стабильное состоя На каждом шаге обмена сообщениями стоимости маршрутов к марщрутиа рам В, С и Е увеличиваются на 2 единицы. Такой процесс называется счета бесконечности (counting to infinity), и он может быть остановлен только пре ригельным соглашением о том, каким значением будет представляться беско ность. Когда стоимости достигнут этого значения, записи в таблицах маршрут ции будут восприниматься как записи, указывающие на бесконечность, и т; маршруты будут считаться недостижимыми. Как и в предыдущем примере, добный постоянный обмен может привести к повышению загрузки каналов зи и возможным потерям пакетов. -
Расщепление горизонта
Возможность появления эффекта счета до бесконечности и эффекта скачи как результат, резкое снижение скорости сходимости являются серьезными достатками протоколов длины вектора. Для решения этих проблем были ра* ботаны специальные технологии, среди которых выделяются технологии pat пления горизонта (английский термин split horizon — в книге используе один из возможных переводов) и мгновенного обновления (triggered updai реализованные в протоколе RIP. • •
Механизм расщепления горизонта опирается на очень простое правило;:® маршрутизатор А передает пакеты по адресу некоторого хоста и эти пакеты п ходят через маршрутизатор В, маршрутизатору В нет смысла пытаться ис: маршрут к данному хосту через маршрутизатор А. При введении этого npai необходимые изменения в оригинальной версии протокола минимальны: вм того, чтобы рассылать одну и ту же стоимость маршрута через все свои ин фейсы, маршрутизаторы будут посылать разные версии этого сообщения, j можны два варианта работы. В первом (простейшем) маршрутизатор просто ключает из своих сообщений всякую информацию о получателях, достижй! через канал связи. Такой подход основан на том, что маршруты никогда анонсируются, или на том, что старые сведения удаляются с помощью меха! ма тайм-аута. Второй вариант называется split horizon with poisonous rev- (можно перевести как «расщепление горизонта с обратным исправление и он более агрессивен: маршрутизаторы будут включать маршруты до всех лучателей в рассылаемые сообщения, но станут устанавливать расстояний некоторых получателей в бесконечность. В результате логические петли ме. двумя маршрутизаторами будут удаляться немедленно. Можно показать на.: стом примере, что подобная стратегия способна устранить проблему счет бесконечности. Однако эта технология не защищает от всех возможных сп бов образования петель.
Чтобы проиллюстрировать сказанное, вернемся к рассмотрению ситуг в сети с обрывом двух каналов связи. Сразу после обрыва канала связи м< маршрутизаторами Е и D (канал 6) таблицы маршрутизации на В, С и Е б, иметь следующий вид. ■"
"НаправлениеКанал4C-D5E-D6"НаправлениеКанал4C-D5E-D6Стоимость22InfСтоимость22Inf
"Направление
Канал
4
C-D
5
E-D
6
"Направление
Канал
4
C-D
5
E-D
6
Стоимость
2
2
Inf
Стоимость
2
2
Inf
Маршрутизатор Е обнаруживает обрыв канала и посылает сообщения через каналы 4 и 5, указывая на то, что расстояние до маршрутизатора D в настоящий момент равно бесконечности. Предположим, что это сообщение получает маршрутизатор В, но далее, например по причине сбоя, оно не достигает маршрутизатора С. Теперь записи в таблицах следующие.
Направление
Канал
Стоимость
В—D
4
Inf
C-D
5
2
Е —D
6
Inf
Теперь представим, что маршрутизатору С пришло время рассылать свои сообщения об обновлении. Маршрутизатор С будет действовать совершенно иначе: рассылать сообщение о бесконечности расстояния до маршрутизатора Е через канал 5. А через канал 2 он будет отправлять сообщение о стоимости маршрута, » равной 2. В результате маршрутизатор В обновит свою таблицу маршрутизации и затем разошлет своим соседям сообщения о бесконечности расстояния через канал 2 и о стоимости маршрута, равной 3, через канал 4. Записи в таблицах маршрутизации примут вид.
Направление
Канал
Стоимость
В—D
2
3
С —D
5
2
Е—D
4
4
Как видно, существует петля между маршрутизаторами С, В и Е. Легко показать, что следующий обмен сообщениями об обновлении приведет к постепенному увеличению расстояний без изменения инфраструктуры маршрутизации, что возвращает нас к проблеме счета до бесконечности.
Мгновенное обновление
Во всех приведенных ранее примерах был успешно обойден один очень важный вопрос: когда следует посылать сообщения о доступных маршрутах своим соседям. Решение этого вопроса на самом деле зависит от следующих факторов: своевременности информации, необходимости ожидания полного набора сообщений об обновлении до того момента, как будет принято решение, сопротивляемости потерям пакетов, отслеживания доступности соседей и т. п.
Некоторые реализации протоколов длины вектора, в том числе и протай RIP, полагаются на регулярную отправку сообщений об обновлении. Это ходимо как для мониторинга соседей, так и для корректировки случаев пои пакетов. С каждой записью в таблице маршрутизации ассоциируется, тяйш Если информация не обновлена по получении нового сообщения до ист^Я времени этого таймера, то маршрутизатор полагает, что сосед недоступен, и считать расстояние до получателя равным бесконечности. Таким образом,'и чение таймера должно быть выбрано так, чтобы оно превышало время перёя информации от одного маршрутизатора к другому. Кроме того, было бы нер^ ным помечать некий маршрут как недостижимый только после потери од!Й сообщения. Например, протокол RIP полагает, что таймер должен быть устам лен в шестикратное значение интервала передач сообщений. Поэтому марки в таблице маршрутизации остается рабочим, если по крайней мере одно изпйд сообщений было получено. На самом деле маршрутизатору необходимо прЗ
мать во внимание загруженность сети, обусловленную повторением своих ,с< щений, и этот период не может быть слишком коротким.' >
Большой интервал между сообщениями, однако, имеет негативное влия?
если изменение в сети произошло сразу после посылки сообщений, то маршрй затору все равно придется ждать окончания промежутка до момента получен извещения о произошедших изменениях у своих соседей. Механизм «мгно'м ного обновления» пытается ускорить реакцию протокола за счет нринудй^ ной рассылки маршрутизаторами сообщений в самое короткое время с моМЙ^ обнаружения изменений в своих таблицах маршрутизации без ожидания чания периода рассылки сообщений. Этот механизм значительно повышает Л рость сходимости сети. В документации па протокол RIP (RFC 1058) сказЯ что немедленная рассылка информации приведет к тому, что маршрутизЯ будет поддерживать актуальность информации, препятствуя тем самым обр™ ванию петель маршрутизации. Очевидно, что негативные эффекты работы,^ токола длины вектора вызваны именно ложными сообщениями, которые пр^ не говорят ничего нового о состоянии своих таблиц на текущий период вред ни. Тем не менее существуют ситуации, особенно обусловленные потерями5? общений о маршрутизации в сети, когда даже использование рассматривай® механизмов неспособно предотвратить возникновение логических петель май рутизации. Такие ситуации будут разрешаться методом счета до бесконечно Однако даже и в последнем случае механизм мгновенного обновления спОсЭД несколько смягчить ситуацию, так как потребуется значительно меньше вред ни для работы механизма счета до бесконечности при условии, конечно, ЧТО вые сообщения посылаются немедленно, без задержки.л
Уже отмечалось, что протокол RIP изначально был разработан в каче^ одного из компонентов для операционной системы UNIX BSD и реализед в виде программы routed. В своей первой версии он был достаточно прост вфЭД те и, соответственно, в реализации. Протокол использовался в различных^ дуктах и был документирован в RFC 1058 в 1988 году (автор Йапльз Хе2Щ Этот документ внес некоторые улучшения в начальную реализацию протоЗД К улучшениям, в частности, можно отнести технологии расщепления гори®™ и мгновенного обновления.
Протоколы семейства длины вектора отличаются друг от друга множеством факторов. Например, различия проявляются в используемых метриках, структуре адресации и т. п. Протокол RIP относится к классу IGP и призван работать внутри автономной системы для сетей относительно небольшого размера.
Запись в таблице маршрутизации для протокола RIP может соответствовать хосту, сети или подсети. Для этого протокола нет понятия типа адреса — ему требуется провести анализ адреса, чтобы получить информацию о методе работы с ним. Сначала он отделяет сетевую часть адреса протокола IP от части «подсеть + хост» посредством анализа класса адреса (А, В или С). Если последняя часть равна нулю, то запись представляет сеть, иначе она представляет либо подсеть, либо хост. Для четкого определения содержимого последней части маршрутизатору необходимо знать маску подсети. Если после применения маски часть адреса хоста равна нулю, то это адрес подсети.
По умолчанию протокол RIP использует очень простую метрику маршрута: расстояние равно количеству каналов связи в пути до получателя (другими словами, количеству переходов). Это расстояние выражается числом в интервале между 1 и 15. Значение 16 соответствует бесконечности. В документе RFC 1058 присутствует информация о том, как можно применить более сложную метрику для выделения предпочтения тому пли иному каналу связи. Но при этом значительно возрастает сложность реализации с учетом выбранного ограничения по количеству переходов. С другой стороны, выбор большего значения продлит состояние несвязности в маршрутах при выполнении счета до бесконечности, что достаточно опасно в рабочей сети.
Протокол RIP может работать как на каналах типа «точка-точка», так и в широковещательных сетях (например, Ethernet). Для передачи своих сообщений (как для получения, так и для отправки) протокол RIP опирается на протокол UDP (схема инкапсуляции RIP -» UDP -» IP) с номером порта 520. По умолчанию сообщения рассылаются широковещательно, и в результате они будут доступны всем маршрутизаторам, подключенным к этой широковещательной сети. В.нор- М{Ы№Ном состоянии пакеты рассылаются каждые 30 секунд. В случае включения механизма мгновенного обновления это происходит быстрее. Если запись в таблице маршрутизации (маршрут) не обновляется в течение 180 секунд, расстояние устанавливается равным бесконечности и эта запись удаляется из таблицы.
Каждая запись в таблице маршрутизации содержит по крайней мере следующие значения:
О адрес получателя;
О метрика, ассоциированную с этим получателем;
адрес следующего получателя в пути до достижения конечного;
Другие таймеры.
■ При получении сообщения маршрутизатор по очереди проверяет записи в таблице маршрутизации. Он убеждается, например, в том, что это адрес корректно- г° класса, что это не сеть 127 или 0 (за исключением маршрута по умолчанию °-0.0.0), далее, что часть адреса хоста не является широковещательным адресом и что метрика не «превышает бесконечность». Некорректные записи игнори-
руются. Документ RFC 1058 рекомендует рассматривать их наличие как ф; ошибки. Если в сообщении метрика не равна бесконечности, то она увелич! ется на единицу для учета перехода. Затем таблица проверяется на присутст записи, относящейся к этому получателю, и выполняется механизм генера] длины вектора.
Сообщения посылаются регулярно каждые 30 секунд или при каждом новлении таблицы. В реальной ситуации мгновенные обновления могут выз! интенсивный сетевой трафик. В связи с этим документ RFC 1058 определ набор мер предосторожности для снижения трафика. Сообщения не должны сылаться немедленно после получения обновлений о маршрутах.. Огш^д£ля быть отосланы через некоторый небольшой случайный промежуток време длительностью от 1 до 5 секунд. Это позволяет среагировать на информацию обновлениях, получаемую от других соседей, и обобщить ее в одном следуюп сообщении. Такое поведение положительно, хотя и немного, влияет на снижен нагрузки в сети. Кроме того, администратор сети может ограничить скорой с которой мгновенные обновления будут посылаться через выбранный канат!
Сообщения, подготавливаемые для всех подключенных интерфейсов, м< отличаться друг от друга. По причине, например, работы механизма расщй ния горизонта, а также в случае обобщения подсетей. Сообщения обычно col жат адреса и метрику для всех записей в таблице. Однако когда сообщение сылается в качестве мгновенного обновления, нет необходимости дублирО! все записи в таблице — достаточно включить в нее только те, которые изме лись. Максимальный размер сообщения выбран равным 512 байт, что позвот передать до 25 записей. Адрес отправителя сообщения должен быть всегда рг IP-адресу интерфейса, через который посылается сообщение.
Записи о подсетях следует анонсировать только в тех случаях, когда/ терфейс принадлежит к той же сети, что и подсеть. Для других интерфейсов записи о подсетях должны быть обобщены в одну сетевую запись. Записи cj конечной метрикой необходимо анонсировать только тогда, когда они были давно обновлены. В таком случае нет опасности их постепенного исчезновС из таблиц маршрутизации соседей по истечении времени таймеров, а это вс? выгодно с точки зрения снижения нагрузки. То же правило применимо к 3, сям, которые имеют бесконечную метрику, когда работает механизм расще: ния горизонта — они могут быть проигнорированы, если информация о сле^ щем маршрутизаторе в пути не была обновлена.s
Помимо посылки сообщений протокол RIP может рассылать запросы, к рые обычно используются при начальном запуске маршрутизатора. Эти зап необходимы для получения информации от соседей при построении таб. маршрутизации. Существуют всего два типа запроса: один для получения таблицы, второй для получения только определенных записей. В первом с в запросе указывается адрес 0.0.0.0 с метрикой, равной бесконечности, и,.о' будут такие же, как при нормальной работе, включая обработку результате тода расщепления горизонта. Запросы второго типа обычно не нужны пр! мальной работе, а используются в процессе отладки.j
В архитектуре сети Интернет существует четкое разграничение между хостами и маршрутизаторами. Первые обычно не выполняют функции маршрутизации, хотя могут иметь несколько сетевых интерфейсов. Но в любом случае маршрутизация — «дело рук» самого маршрутизатора. В результате только маршрутизаторы должны «осознавать» присутствие протокола RIP, но это в идеальном случае. На самом деле ввиду того, что сам протокол не новый — его история исчисляется уже десятилетием и захватывает период времени, когда не было четкого различия между хостами и маршрутизаторами, — протокол грешит некоторой «неразборчивостью». В связи с этим разработчики предположили, что достаточно удачным решением будет рассылать информацию протокола широковещательно. В этом случае хосты могут отслеживать сообщения протокола и формировать на их основе свои собственные таблицы маршрутизации. Напомним, что таблица маршрутизации есть даже у простого компьютера с единственным сетевым адаптером. Кроме того, хосты с несколькими сетевыми картами смогут принимать на основе этой информации решения о выборе маршрута для некоторого получателя в случае, когда несколько маршрутизаторов подключены к одной локальной сети. Подобные хосты способны посылать запросы на получение информации, но они никогда не отвечают собственными сообщениями. По этой причине они были описаны в документе RFC 1058 как «молчаливые» (silent hosts). .
Такая стратегия работает по крайней мере при использовании протокола RIP первой версии (RIP-1). Однако, учитывая в настоящее время доступность и других протоколов (RIP-2, IGRP и т. п.), появилось опасение, что подобные Аосты не сумеют поддерживать корректные таблицы маршрутизации. Поэтому в сообществе Интернета выработано единогласное решение против применения подобных «молчаливых» хостов. Нормальная работа хоста заключается в посылке пакетов удаленному получателю с помощью маршрута по умолчанию.
Деятельность протокола RIP на маршрутизаторе всегда подразумевает наличие некоторых конфигурационных этапов. В самом простом варианте протокол изучает список локальных интерфейсов маршрутизатора, соответствующие им адреса и маски подсетей. При отсутствии другой информации протокол будет инициализировать таблицу маршрутизации только с одной записью для каждого интерфейса и с метрикой, равной 1 (устройства на этих подсетях расположены на расстоянии одного перехода относительно локального маршрутизатора). Ио итогам обследования протокол будет рассылать запросы своим соседям для формирования таблиц и начала полноценной работы.
Однако существуют причины, по которым администратор сети вправе отказаться от широковещательной рассылки сообщений этого протокола на все локальные интерфейсы. Например, может быть только один маршрутизатор на вЗ^РДсеть. В таком случае широковещательная рассылка в эту подсеть приведет к ненужному расходованию ресурсов. Может, например, возникнуть необходимость в поддержке иных протоколов маршрутизации на других интерфейсах. Естественно, нужно учитывать и такой фактор, как безопасность — рассылка со- ощений протокола в состоянии раскрыть адресную структуру всей распределенной сети. Кроме того, если используется технология dial-on-demand (наприМеР, для каналов ISDN), то регулярные сообщения протокола будут заставлять Маршрутизатор устанавливать соединение, что приведет к лишним затратам.
Учитывая это, администратор может назначать выбранные интерфейсы мар, тизатора в качестве пассивных (passive interface) с точки зрения протокола В качестве примера рассмотрим работу протокола в сети (рис. 7.3). .
Рис. 7.3. Использование пассивного интерфейса
В приведенном примере сети маршрутизатор Cisco 1601 является как быс ревалочным пунктом — через его синхронные интерфейсы осуществляется а частей распределенной сети. К нему непосредственно подключается локаль сеть, в которой используются адреса класса С 192.168.4.0/24. В такой конф! рации маршрутизатор должен принимать и отправлять сообщения протокол^ * через интерфейсы SerialO, Serial 1, по поддержка протокола RIP на интерфб EthO не является обязательной. Это связано с тем, что в подключенной сети' устройств, опирающихся на работу протокола RIP, — установлены только о® ные клиентские компьютеры. Настроив интерфейс EthO как пассивный, моя запретить протоколу посылать свои сообщения через указанный интерф^ Для этого предусмотрена команда passive-interface, выполняемая в режиме! стройки протокола RIP:
C1scol60l#conf term/
Enter configuration commands, one per line. End with CNTL/Z.>
C1scol601(config)#router rip
Ciscol601(config-rout)#passive-interface ethernet 0।
Несмотря на то что эта команда запрещает посылку сообщений прото® RIP через интерфейс, она не блокирует прослушивания маршрутизатором эт интерфейса на наличие поступающих сообщений протокола. Для выполне последнего действия нужно использовать фильтрацию маршрутов (route flit Администратор сети может проверить факт работы команды — для этого ну выполнить команду отладки debug ip rip..
Перечисляя все ситуации, когда может потребоваться отключение рассь сообщений протокола RIP через определенный интерфейс, логично выде.
■еше одну- Если рассматривать сеть, в которой связь объектов организована че-
[ ез прямые провода по технологии xDSL, то кроме решения, заключающегося - в использовании маршрутизаторов с подключенными к ним модемами, у адми- ' нистратора есть альтернатива — модемы со встроенными портами Ethernet. При ■ этом модемы работают как двухпортовые мосты: один порт — Ethernet, второй — канал xDSL. Преимущества такого подхода очевидны: стоимость модемов ‘ с портами Ethernet меньше, чем стоимость аналогичных модемов с портом, например V.35, а также не требуется покупать маршрутизаторы и заниматься J их настройкой. Но, как всегда и бывает, простота самих устройств и создает [ . определенные недостатки — трудно контролировать передаваемый через них I трафик. Невозможно настроить приоритеты для разных типов трафика, недос- (■ тупна блокировка определенных пакетов и т. п. Однако если вопрос цены был | определяющим и на этом основании принято решение использовать именно ■ эти модемы, то администратору стоит обратить внимание еще на один фактор: модемы работают как мосты и, соответственно, не блокируют широковещательный i трафик, каковым, например, является трафик протокола RIP. Если к локальной ! сети подключен маршрутизатор (маршрутизаторы), а также подобные модемы, ; то будет разумным на маршрутизаторе командой1 passive-interface запретить транс- г ' ляцию широковещательного трафика в локальную сеть. Обычно в локальной .сети существует множество других источников широковещательного трафика . (например, протокол ARP), которые по сравнению с протоколом RIP генерируют его в большем объеме, но если из-за плохого качества выделенной пары проводов не удастся добиться высокой скорости, то и столь малый вклад тоже может быть полезным.
Когда администратор сети настраивает связь на двух маршрутизаторах и ука- ■ зывает на каждом интерфейсе маршрутизатора IP-адрес, в этом случае мар- ^, шрутизаторы немедленно получают в свое распоряжение информацию о непосредственно подключенных к ним сетях. Так, если на интерфейсе EthernetO ' маршрутизатора настроен, например, адрес 192.168.4.254 с маской 255.255.255.0, j то отсюда следует, что маршрутизатор подключен к сети, в которой используется адресная схема класса С 192.168.4.0/24. Эта информация важна, так как . если на любой другой порт маршрутизатора придет пакет, адресованный в сеть / 192.168.4.0/24, то маршрутизатор просто пошлет запрос протокола ARP на свой ; ■ порт EthernetO, а затем напрямую по выявленному МАС-адресу отправит пакет \ ■ конечному получателю.
" ■ Рассмотрим в действии работу протокола маршрутизации RIP. Для этого ' в качестве примера рассмотрим сеть, в которой 6 объектов связаны между собой через сеть Frame Relay и выделенные каналы связи (рис. 7.4).
. Здесь используется внутренняя адресация на базе сетей класса С (192.168. (1-Ю1).0/24) и, аким образом, на каждом порте Ethernet маршрутизатора Г настроен адрес соответствующей сети, заканчивающийся на .254, с маской ■ • 55.255.255.0 — это также указывает на используемый класс адреса в под- ■ . ключенном сегменте сети (например, если адрес маршрутизатора 192.168.1.254, К то предполагается, что подключенной сети Ethernet выделены адреса класса Ж С 192.168.4.0/24).
Cisco 805192.168.6.254Cisco 805192.168.6.254Cisco 805192.168.1.254Cisco 805192.168.1.254PPPPPP192.168.101.253192.168.101.254Ethernet192.168.101.253192.168.101.254Ethernet192.168.101.0/24192.168.101.0/24Рис. 7.4. Пример реальной сетиРис. 7.4. Пример реальной сети
Cisco 805
192.168.6.254
Cisco 805
192.168.6.254
Cisco 805
192.168.1.254
Cisco 805
192.168.1.254
PPP
PPP
192.168.101.253192.168.101.254
Ethernet
192.168.101.253192.168.101.254
Ethernet
192.168.101.0/24
192.168.101.0/24
Рис. 7.4. Пример реальной сети
Рис. 7.4. Пример реальной сети
В том случае, если на маршрутизаторах еще не настроена схема маршрутизац] (статическая или динамическая), они обладают только информацией о локаль: подключенных сетях. Этот факт можно подтвердить, выполнив команду show route на любом маршрутизаторе в сети (например, Cisco 1601)..
Ciscol601#show ip route
Codes: С - connected. S - static. I - IGRP. R - RIP, M - mobile. В - BGP : D - EIGRP. EX - EIGRP external, 0 - OSPF. IA - OSPF inter area Ml - OSPF NSSA external type 1, N2 - OSPF NSSA external’ type 2
El - OSPF external type 1, E2 - OSPF external type 2. E - EGP . , i - IS-IS. LI - IS-IS level-1. L2 - IS-IS level-2, * - candidate detail U - per-user static route, о - ODR
Gateway of last resort is not set
C 192.168.4.0/24 is directly connected. EthernetO ■
Символы (коды), которые выведены в начале листинга, помогают определи способ обнаружения маршрута. Код С (connected) показывает, что маршрут изв тен, так как он напрямую подключен к маршрутизатору. Поскольку на вновь 1 страиваемых маршрутизаторах динамическая маршрутизация по умолчанию задействуется, то в рассматриваемой сети без дополнительных конфигурационн команд маршрутизаторы не будут владеть информацией о возможных маршрзр Предположим, что администратор сети, работая с командной строкой маршр;
тора Cisco 1601, выполняет команду ping 192.168.1.254. Маршрутизатор проверит свою таблицу маршрутизации для поиска маршрута в сеть 192.168.1.0/24 и, не найдя таковую, не сможет выполнить команду ping и выдаст ошибку.
Настройка протокола RIP на маршрутизаторах компании Cisco Systems достаточно проста и предполагает использование только двух команд: router rip и network. Начиная с модели Cisco 1601 настройка протокола будет осуществляться еле-' дуюшим ооразом:
CiSC016O1#сопf1gure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Ciscol601(config)#router rip
CiSC016O1(confi g-router)#network 192.168.4.0
Команда router rip активизирует протокол маршрутизации RIP и изменяет строку приглашения на (config-router)#. Следующая команда — network 192.168.4.0 — дает инструкцию маршрутизатору выполнить обработку динамической маршрутизации для сети 192.168.4.0, или, иными словами, указывает маршрутизатору па необходимость посылки и приема сообщений протокола RIP на всех интерфейсах, являющихся частью этой сети. В рассматриваемом примере это интерфейсы EHiernetO, S1 и S0. Интерфейсы SerialX также .будут рассматриваться маршрутизатором в качестве части сети 192.168.4.0. Это обусловлено тем, что на них используется механизм сохранения адресов, настроенный с помощью команды ip unnumbered EthernetO.
ВНИМАНИЕ
При вводе команды network указывается адрес сети, а не подсети.
Аналогичным образом настраиваются и другие маршрутизаторы. Понятно, что в качестве параметра команды network записываются другие адреса сетей (например, network 192.168.1.0), то есть адреса напрямую подключенных сетей.
совет—:—
В том случае, если маршрутизатор имеет два порта Ethernet, как, например, модель Cisco 1605R, и к каждому из них подключены сети, например класса В, 172.16.1.0/24 и 172.16.2.0/24, то при настройке протокола RIP на этом маршрутизаторе следует ввести команду network 172.16.0.0.
После того как на всех маршрутизаторах будет включена поддержка протокола RIP, они начнут обмениваться информацией, рассылаемой каждым из них всем своим соседям (точнее говоря, на все свои интерфейсы). Эта информация включает в себя записи о напрямую подключенных сетях и о сетях, обнаруженных с помощью протокола RIP в сообщениях от других маршрутизаторов. Маршрутизаторам в сети потребуется некоторое время для получения сведений обо всех доступных маршрутах. Впоследствии администратор может проверить результат работы протокола RIP, выполняя команду show ip route.
Ciscol601#show ip route•
Codes: C - connected. S - static, I - IGRP, R - RIP, M - mobile. В - BGP
0 - EIGRP, EX - EIGRP external. 0 - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
El - OSPF external type 1. Е2 - OSPF external type 2, E - EGP
1 - IS-IS, LI - IS-IS level-1. L2 - IS-IS level-2, * - candidate defaiji U - per-user static route, о - ODR/
Gateway of last resort.is 192.168.101.254 to network 0.0.0.0
C192.168.4.0/24is directlyconnected. EthernetO
R192.168.5.0/24[120/1]via192.168.5.254, 00:00:06,Seriall.3
R192.168.6.0/24[120/1]via192.168.6.254. 00:00:23.Seriall.2
R192.168.1.0/24[120/3]via192.168.101.254. 00:00:25. SerialO
R192.168.2.0/24[120/1]via192.168.2.254. 00:00:15,Seriall.l
R 192.168.101.0/24 [120/1] via 192.168.101.254. 00:00:25. SerialO
R* 0.0.0.0/0 [120/1] via 192.168.101.254. 00:00:25, SerialO
Каждая запись в таблице маршрутизации помечается кодом, указывающя на источник информации. Все записи, полученные с помощью протокола R? помечаются кодом R. Рассмотрим для примера одну из записей:4
R 192.168.1.0/24 [120/3] via 192.168.101.254, 00:00:25, SerialO.Ц
Эта запись говорит о том, как можно достичь сети 192.168.1.0/24, что и"6 ляется маршрутом до получателя. Маршрутизатор, принимая пакет с адрес* получателя в сети 192.168.1.0/24, проверяет таблицу маршрутизации, наход рассматриваемую запись и анализирует ее. Анализ показывает, что искомая с< находится на расстоянии трех переходов от маршрутизатора, что обозначает записью [120/3], где 120 подразумевает административно заданное расстояг (administrative distance), а цифра 3 определяет метрику маршрута (3 переход Административное расстояние определяет уровень приоритета и значимо, уг маршруты получены с использованием нескольких протоколов маршрутизап Метрика в протоколе RIP отражает количество переходов, или, иными слова количество маршрутизаторов, которое пакет минует по пути в сеть 192.168 /24. Запись 00:00:25 указывает на «возраст» маршрута — 25 секунд назад ма) рутизатор получил информацию об этом маршруте. Учитывая, что прото: RIP рассылает сообщения каждые 30 секунд, значения в данной записи ш дятся в интервале от 0 до 30 секунд при нормальной работе сети. В том слу если, например, сеть 192.168.1.0/24 перестанет быть доступной по каким л причинам, маршрутизатор увеличит этот интервал до 240 секунд, а затем удали маршрут из таблицы маршрутизации. Следующая запись в маршруте — Serial©,^ уведомляет маршрутизатор, что пакеты, адресованные в сеть 192.168.1.0/: следует передавать через интерфейс SerialO.
Остановимся более подробно на рассмотрении понятия расстояния, опре ленного в административном порядке, которое используется, если в распре ленной сети работают несколько протоколов маршрутизации, то есть когда ма| рутизатор получает сообщения от нескольких протоколов. Естественно, вс* вопрос: если маршрутизатор получает сообщения протоколов RIP и OSP^i в конечном итоге каким именно маршрутам он должен отдать ппелпоите$ Ответ на этот вопрос осложняется еще тем, что данные протоколы использ различные метрики и маршрутизатор просто не может выбрать нужный марШ,
основываясь на простом их сравнении. Именно в таком случае он проверяет административные расстояния.
^'Предположим, что маршрутизатор на два своих интерфейса (SerialO, Serial 1) получает сообщения от двух протоколов маршрутизации RIP и OSPF, рекламирующих маршрут в одну сеть 192.168.1.0/24. При этом для выбора маршрута маршрутизатор сличит соответствующие административные расстояния и выберет тот маршрут, для которого таковое будет меньше. Далее маршрут будет занесен в таблицу для использования при достижении получателя. В нашем примере маршрутизатор отдаст предпочтение протоколу OSPF перед протоколом RIP, так как у первого административное расстояние меньше. Значения административных расстояний для каждого протокола маршрутизации приведены в табл. 7.1. При этом по умолчанию все маршруты от одного протокола будут иметь равные административные расстояния (120 для протокола RIP).
Таблица 7.1. Административные расстояния по умолчанию
Источник маршрута
Административное расстояние
Подключенный интерфейс Статический маршрут Enhanced IGRP (EIGRP) IGRP
0
1
5
100
OSPF
110
IS-IS
115
RIP
120
EGP
Неизвестный
140
255
Команду show ip route можно выполнить па любом маршрутизаторе в сети, и результаты будут похожи, за исключением, естественно, метрик и значений таймеров. Например, выполняя данную команду на маршрутизаторе с адресом 192.168.5.254, получим результат, из которого видно, что для достижения сети 192.168.1.0/24 пакету потребуется пересечь 4 маршрутизатора в пути своего следования (запись 192.168.1.0/24 [120/4] via 192.168.4.254, 00:00:16, SerialO.l).
Cisco805#show ip route
Gateway of last resort is 192.168.4.254 to network 0.0.0.0
R192.168.4.0/24[120/1]via192.168.4.254.00:00:06.SerialO.l
C192.168.5.0/24is directlyconnected. EthernetO
R192.168.6.0/24[120/2]via192.168.4.254.00:00:06.SerialO.l
R192.168.1.0/24[120/4]via192.168.4.254.00:00:16,SerialO.l
R192.168.2.0/24[120/2]via192.168.4.254.00:00:23,SerialO.l
R 192.168.101.0/24 [120/2] via 192.168.4.254: 00:00:04. SerialO.l
R* 0.0.0.0/0 [120/2] via 192.168.4.254, 00:00:08, SerialO.l
СОВЕТ—
Обратите внимание на то, через какой интерфейс следует передавать пакеты в целевые сешм Установлен интерфейс SerialO.l. Это объясняется тем, что на маршрутизаторе настроен протей кол Frame Relay для связи с другими объектами и SerialO.l является логическим подинтерфейсом I Однако с точки зрения протокола RIP разницы по сравнению, например, с физическим интерфейс сом SerialO нет никакой. Кроме того, следует заострить внимание на том, как пакеты от маршрутйч затора 192.168.5.254 будут достигать, например, сети 192.168.2.0 /24: для этого им придется сделать «крюк» — сначала дойти до маршрутизатора Cisco 1601. Очевидно, что это определяет^ выбранной схемой постоянных виртуальных соединений в сети Frame Relay. Если условия дим туют необходимость снижения задержек при передаче информации между двумя точками в раД пределенной сети, то и схему постоянных виртуальных соединений нужно выбирать соответси вующим образом (глава 8).Я
В том случае, если наблюдаются проблемы при работе протокола RIP, адм®! нистратор сети может включить на маршрутизаторе режим отладки. Для этом следует воспользоваться командой debug ip rip, предварительно настроив выда^ отладочных сообщений по сеансу Telnet с помощью команды terminal monitor (есЯ подключение к маршрутизатору осуществляется с помощью терминального пои та, то последнюю команду выполнять не требуется). -дЯ
Отдельно следует остановиться на рассмотрении маршрута по умолчаний (default route), который позволяет масштабировать сеть и сокращать ресурсы, за#! действованпые на промежуточных маршрутизаторах. Основная задача маршрут® по умолчанию заключается в выработке указания о способе достижения неизвестя ного получателя — получателя, информация о котором отсутствует в таблиц^ маршрутизации, так как она не была введена вручную или не получена из пр^Я токола маршрутизации. Если на маршрутизаторе настроен маршрут по умолчан нию, то он при обнаружении пакетов к неизвестному ему получателю передала их тому маршрутизатору, который был указан в маршруте по умолчанию. Есл^ же маршрут по умолчанию нс был настроен, то пакет будет отброшен.
Не следует расценивать маршрут но умолчанию как способ избавления от ошм бок маршрутизации. Его присутствие позволяет не хранить на маршрутизатор® всю адресную информацию о сети, снижая тем самым объем задач по упраВу лению и обслуживанию. При этом размер таблицы маршрутизации снижаетсш| и на ее анализ требуется меньше циклов процессора маршрутизатора. Наиболее! часто используется маршрут по умолчанию при подключении распределенной сети к Интернету. П
Так, представим, что организация, имеющая сеть, состоящую из нескольКИ^З удаленных объектов, хочет подключиться к Интернету. Одним из вариантов поДч ключения может быть покупка и установка граничного маршрутизатора, од^ интерфейс которого подключается к внутренней сети, а другой — к интерне$я провайдеру. После этого администратор сети настраивает на маршрутизаторе маршрут по умолчанию, отмечая необходимость отправки трафика по неизвестная ему адресам в Интернет. Здесь следует отметить, что трафик будет передавать^ маршрутизатору на стороне провайдера. В ситуации, когда граничный марпвдЯ тизатор соединяет с Интернетом только одну локальную сеть, этого будет досТМ точно, но при наличии множества удаленных объектов потребуется приложи»
Рис. 7.5. Использование маршрута по умолчанию
■ В рассматриваемом примере корпоративная сеть подключается к Интернету [ и для этого используется граничный маршрутизатор с настроенным маршрутом
' по умолчанию. В результате ему не требуется хранить информацию обо всех воз, можных получателях в глобальной сети. С этой точки зрения, граничный маршру- . тизатор выполняет свою задачу, ио как быть другим маршрутизаторам? Они I также должны владеть информацией о маршруте по умолчанию, иначе пакеты, I адресованные в Интернет, будут отбрасываться маршрутизаторами, так как они г не знают этого маршрута. Для информирования остальных граничный марш- L рутизатор включает описание маршрута по умолчанию в сообщения протоко- [ ла маршрутизации так же, как информацию о других маршрутах. Каждый ' маршрутизатор, участвующий в работе протокола маршрутизации, получает । маршрут по умолчанию, помещает его в свою таблицу и может отправлять тра- I фик в Интернет.
I Если в распределенной сети используется протокол RIP, то чтобы граничный ’маршрутизатор сумел проводить рассылку маршрута по умолчанию, потребуется
■настройка самого маршрута по умолчанию на этом маршрутизаторе, а осталь
ное протокол RIP сделает сам. Рассмотрим пример сети с защитным экраном 1 (рис. 7.6).
К В рассматриваемом примере сети подключение к Интернету выполняется ■ . с помощью защитного экрана, который помимо функций фильтрации трафика ■ ^выполняет также задачи маршрутизации. Но защитный экран предоставляет ■ лишь минимальные возможности по маршрутизации, ограниченные поддержкой ■ статических записей в таблице. Кроме поддержки правил фильтрации трафика ■ на защитном экране настроена технология NAT, позволяющая выполнять динами- ■ ческую трансляцию внутренних адресов (192.168.Х.Х) во внешние адреса, зарегите стрированные в Интернете. В данном случае защитный экран работает на сервере Под управлением операционной системы Windows NT и имеет три сетевые карты Ethernet, одна из которых связана с Интернетом (способ подключения пока не
важен), а две других — к внутренним сетям. В принципе, можно было бы oi тись только двумя сетевыми картами, но рассмотренный способ позволяет;; лучить больший контроль над доступом в Интернет с удаленных объектов (q 192.168.3.0/24 рассматривается как сеть центрального офиса). С точки зрег удаленных маршрутизаторов для отправки информации в Интернет им и сто потребуется передать пакеты защитному экрану, который затем пере правит их в Интернет. В данном примере защитный экран стоит рассматрива как маршрутизатор, поддерживающий только статическую маршрутизацию, в ■ время как остальные маршрутизаторы используют протокол RIP. Из этого ел дует, что на одном из маршрутизаторов, подключенных к сети 192.168.101.0/2 нужно настроить маршрут по умолчанию, указывающий на интерфейс .чаши ного экрана с адресом 192.168.101.1. Для этого на нем требуется ввести комац ip route 0.0.0.0 0.0.0.0 192.168.101.1., ,
S0.1S0.1.50.1.50.15050HDLCHDLC192.168.4.254/Cisco 1601 i192.168.4.254/Cisco 1601 iFrame RelayFrame RelayPVCPVCCisco 805 192.168.2.254Cisco 805 192.168.2.254Cisco 805 192.168.5.254Cisco 805 192.168.5.25450.150.1£У££У£PVCPVC•i•iCisco 805192.168.1.254Cisco 805192.168.1.254Cisco 805 192.168.6.254Cisco 805 192.168.6.254Cisco 805 192.168.101.253Cisco 805 192.168.101.253Cisco 805 192.168.101.254 и 192.168.101LCisco 805 192.168.101.254 и 192.168.101Lаа
S0.1
S0.1
.50.1
.50.1
50
50
HDLC
HDLC
192.168.4.254/
Cisco 1601 i
192.168.4.254/
Cisco 1601 i
Frame Relay
Frame Relay
PVC
PVC
Cisco 805 192.168.2.254
Cisco 805 192.168.2.254
Cisco 805 192.168.5.254
Cisco 805 192.168.5.254
50.1
50.1
£У£
£У£
PVC
PVC
•i
•i
Cisco 805
192.168.1.254
Cisco 805
192.168.1.254
Cisco 805 192.168.6.254
Cisco 805 192.168.6.254
Cisco 805 192.168.101.253
Cisco 805 192.168.101.253
Cisco 805 192.168.101.254 и 192.168.101L
Cisco 805 192.168.101.254 и 192.168.101L
а
а
Интернет:;: >■
192.168.3.0/24
Защитный экран
Рис. 7.6. Пример сети с защитным экраном
Данная команда настраивает статический маршрут, но использует спец^ ные адреса сетей с маской подсети, состоящей из одних нулей. Для маршрут
тора он и будет являться маршрутом по умолчанию, а защитный экран будет последним маршрутизатором в пути (не совсем точный перевод английского термина gateway of last resort). Проверить корректность ввода маршрута по умолчанию можно с помощью команды show ip route, выполняемой, например, на маршрутизаторе с адресом 192.168.101.254. Далее следует обратить внимание на запись Gateway of last resort...
Cisco805#show ip route
Gateway of last resort is 192.168.101.1 to network 0.0.0.0
R192.168.4.0/24[120/1]via192.168.4.254,00:00:21,SerialO
R192.168.5.0/24[120/2]via192.168.4.254,00:00:19,SerialO
R192.168.6.0/24[120/2]via192.168.4.254,00:00:03,SerialO
R192.168.1.0/24[120/2]via192.168.101.253, 00:00:16, EthernetO
R192.168.2.0/24[120/2]via192.168.4.254,00:00:09,SerialO
S192.168.3.0/24 [1/0] via 192.168.101.1
C192.168.101.0/24 is directly connected,EthernetO
S*0.0.0.0/0 Ll/0] via 192.168.101.1
Первая запись результата выполнения команды подтверждает корректность установки маршрута по умолчанию (Gateway of last resort is 192.168.101.1 to network 0.0.C.0). Обратите внимание на последнюю запись в таблице маршрутизации. Она имеет код S*, что указывает на то, что запись в таблице статическая и содержит информацию о маршруте по умолчанию. Сразу после настройки маршрута по умолчанию протокол RIP начинает информировать о нем соседние маршрутизаторы. Здесь важно отметить один момент. Маршрут по умолчанию является статическим, а для рассылки в своих сообщениях статических маршрутов протоколу RIP нужно дать прямое указание на это с помощью команды redistribute static. Но маршрут в сеть 0.0.0.0 с маской 0.0.0.0 является исключением — про-’ токол будет рассылать о нем информацию, даже если указанная команда пропущена.- ■■ ■ ■
"’" Вводя команду show ip route на других маршрутизаторах распределенной сети, можно убедиться, что они обладают информацией о маршруте по умолчанию. Ниже приведен результат работы этой команды на маршрутизаторе с адресом 192.168.5.254.■
Cisco805#show ip route
Gateway of last resort is 192.168.4.254 to network 0.0.0.0
- R192.168.4.0/24[120/1]via192.168.4.254.00:00:11,SerialO.1
C192.168.5.0/24is directlyconnected. EthernetO
R192.168.6.0/24[120/2]via192.168.4.254.00:00:33.SerialO.1
R192.168.1.0/24[120/4]via192.168.4.254,00:00:12,SerialO.1
R192.168.2.0/24[120/2]via192.168.4.254,00:00:23.SerialO.1
R192.168.3.0/24[120/2]via192.168.4.254,00:00:12,SerialO.1
R 192.168.101.0/24 [120/2] via 192.168.4.254. 00:00:08, SerialO.1
R* 0.0.0.0/0 [120/2] via 192.168.4.254. 00:00:16. SerialO.1
АТАКИ RIP ENTRY ADDED И RIP ENTRY TIMEOUT№
Атака RIP Entry Added основывается на перехвате сообщений протокола RIP и добавлении в । информации (например, обновление таблицы маршрутизации в результате добавления новых тей). Естественно, это приведет к тому, что маршрутизаторы (как программные, так и аппаратй в сети будут владеть информацией о новых сетях. Подобный факт появления новых сетей o6i няется по-разному. Во первых, администратор мог подключить к сети новый объект и включ новую сеть в общую схему сети. Другим объяснением может быть то, что некая сеть стала вн достижимой после некоторых проблем со связью. Есть еще одно объяснение, а именно то, ^l кто-то пытается получить доступ к сети, внося в таблицы маршрутизации ложную информаций К сожалению, протокол RIP (первая его версия) не использует аутентификацию, таким образе маршрутизаторы нетрудно обмануть, перехватывая и модифицируя сообщения этого протокол В качестве меры противодействия можем рекомендовать периодическую проверку таблиц на пре мет новых записей, точнее их источников. В том случае, если источником был какой-либо компь тер в сети, стоит проверить причину, по который он добавил маршрут. Здесь просто не исключа( ся и установка дополнительной сетевой карты с настройкой протокола RIP.. -
В основе атаки RIP Entry Timeout лежит проверка сообщений протокола RIP и поиск в них инфе мации о том, что некая сеть стала недостижимой. Причин этому может быть несколько, первой них, естественно, будет та, что сеть стала недостижимой по причине сбоя в канале связи и маршрутизатора. Впрочем, вероятно, что просто кто-то пытается добавить ложную информащ в таблицы маршрутизации. Действия для проверки могут быть теми же, что и в случае атаки I Entry Added. Продолжением этой атаки иногда является атака RIP Metric Change Decode, при koi рой перехватываются и модифицируются сообщения протокола RIP, а именно расстояния до сет (метрики).
В заключение для сравнения очень коротко остановимся на настройке прот кола IGRP на маршрутизаторе. Он, так же, как и протокол RIP, относится к мейству протоколов длины вектора. Практическая настройка протокола IG-B так же проста, как и настройка протокола RIP. Это все те же две базовые комаз ды router igrp и network. Разница в том, что при вводе команды router igrp нуж! указать номер автономной системы в качестве параметра — это может бы; любое число в интервале от 1 до 65 535. Маршрутизаторы, на которых .^ пользуется один номер автономной системы, будут обмениваться иифрр.м§Щ$ друг с другом. Иначе они не смогут взаимодействовать, считая, что принадл жат к разным автономным системам. Ниже приведен пример настройки прот кола IGRP на маршрутизаторе Cisco 1601 (номер автономной системы — 100)
Ciscol601#confIgure terminalV;
Enter configuration commands, one per line. End with CNTL/Z.
Ciscol601(config)#router igrp 100'
CiSC016O1(confi g-router)#network 192.168.4.0
Пример подключения объектов
< сети Интернет
Остановимся на рассмотрении практического примера подключения к сети тернет с помощью динамической маршрутизации. Для этого представим не: организацию, перед администратором которой встала задача обеспечить быст
доступ в сеть Интернет, желательно минимизируя затраты на саму связь. Собственно, если обратиться к какому-либо крупному провайдеру, который возьмет на себя все заботы по подключению и организации связи (например, протянет оптоволоконный кабель), то такой подход позволит значительно смягчить «головную боль» администратора. Но, предположим, было принято решение самостоятельно сделать подключение и для этого заказать формирование медной пары проводов от места расположения компании до провайдера услуги Интернет (дополнительную информацию о подобном методе подключения можно найти в главе 10). А теперь отвлечемся от гипотетических мыслей и посмотрим, как это происходило некоторое время назад в одной из реально существующих организаций.
Можно сказать, что компании повезло, так как провайдер территориально оказался рядом и до него можно было «дотянуться» прямым проводом. Для самой организации связи была взята на тестирование, а затем закуплена пара модемов ASMi-50 производства компании RAD Data, Communication (www.rad.com). На момент покупки это была новая модель, ну а сейчас, естественно, производитель предлагает и другие варианты. Рисунок 7.7 взят с сайта производителя, и на нем показаны три типа исполнения модели, слева и внизу — ведущий, вверху — ведомый, где к модему можно подключить внешний жидкокристаллический дисплей (опционально). В правой части рисунка представлено исполнение модема, предназначенное для установки в специальное шасси (как правило, на стороне провайдера).
Рис. 7.7. Модем ASMi-50 компании RAD Data Communication
Как видно из рисунка, один из модемов поставляется со встроенным жидкокристаллическим дисплеем, с помощью которого можно управлять параметрами связи (например скоростью передачи). Этот модем является «ведущим» (master), и он был установлен в помещении компании. Второй модем из этой пары работает в качестве «ведомого» (slave), и он был установлен на стороне провайдера. Модемы приобретались с интерфейсом V.35 (тип разъема «мама»), с помощью ; которого они подключаются к маршрутизатору. Сами модемы поставлялись без L Кабеля V.35, и при заказе маршрутизатора нужно об этом помнить. Кстати, то, 1 что интерфейс V.35 смонтирован с модемом, очень удобно. В моделях других
производителей такое конструктивное исполнение встречается довольно ред^И Обычно модем имеет разъем типа DB9 или DB 25 и для их подключения ° зывается специальный кабель, на одном конце которого находится разъем DB^a DB25 для подключения к модему, а на другом конце разъем V.35 (тип разъемы «мама») для коммутации с разъемом V.35 («папа») кабеля, приходящего маршрутизатора. В результате общая длина составного кабеля способна досД тигнуть 3 метров, и по этой причине его приходиться скручивать, формируя толстое кольцо. Это кольцо можно повесить на направляющие коммутационно! го шкафа или положить на полку.’ К
Скорость передачи удалось поднять до 512 Кбит/с при длине провода пщДИ близительно в 2 км и сопротивлении 1000 Ом. При этом время простоя составляя! ориентировочно 2-3 часа в 3 месяца (квартал), а иногда еще меньше. ЕстествениХ! все будет зависеть от сформированного прямого провода и его характеристик Хотя были ситуации, когда в результате крупных неполадок на телефонном трассах доступ в сеть Интернет отсутствовал пару дней. Хочется отметить, в Санкт-Петербурге подключение к сети Интернет по выделенному каналу обьиЕЯ но как раз и организуется по прямому проводу. Как альтернатива может бь^Я подключение по технологии Frame Relay, но если абстрагироваться от самой! технологии, то физически подключение останется прежним — провайдер сффЯ мирует медную пару проводов (или, как часто говорят, «пару» или «прямоо провод») от ближайшей АТС, где у него размещено оборудование Frame Relate а затем установит свое оборудование. В том случае, если выход в сеть ИнтернкЯ очень важен для компании или в планах предусмотрена такая потребность, им^1 ет смысл заказать прокладку оптоволоконного кабеля..
Несколько слов относительно доступа в сеть Интернет по технологии ADSLJj или асимметричной цифровой абонентской линии (Asymmetric Digital Subscrib^M Line). В настоящее время эта технология становится все более популярной, та^ как позволяет передавать данные по обычным телефонным линиям, занимая не^ используемый обычной телефонией частотный диапазон. Представьте, как эт^л удобно — па объекте есть телефон и нужно сделать доступ в сеть Интернет. В TQM случае, если требуется высокоскоростной доступ, то следует либо заказывать^ прямой провод от ближайшего узла провайдера, либо принести в жертву теле-1 фон (если возможность проложить дополнительный прямой провод отсутствуй! ет, то провайдер может попросить отказаться от телефона и занять освободив*^ шийся кабель). В варианте ADSL решение находится гораздо проще. Как видно 1 из названия технологии, передача данных происходит па различных скоростях,| причем, как правило, скорость в направлении к абоненту выше чем в противо-Я иоложном. Это очень удобно для работы с сетью Интернет, поскольку обычнОл в такой ситуации объем входящего трафика гораздо больше исходящего, ^дн^ ко наблюдения за работающим web-сайтом показали, что при его определенное популярности соотношение меняется на противоположное, причем разница ОЫ | вает двукратной, и это нужно учесть, если есть желание разместить сайт а подключение сделано по ADSL — внешние пользователи могут ощущать суШтем ственные задержки.' , Д
Вернемся к действиям нашей организации. Первоначально в качестве марта| рутизатора для доступа в Интернет использовалась модель Cisco 1005, ко^М рая имеет один порт Ethernet и один порт Serial (поддерживается скорость
едачи ДО 2 Мбит/с). Постепенно компания стала расширяться и открыла еще офис в городе, с которым нужно было также организовать связь. Причем в обоих офисах сотрудники должны были иметь возможность работать в Интернете. Для связи были выбраны маршрутизаторы 1720 компании Cisco Systems, которые изначально поставляются с одним портом 10/100 Ethernet и двумя слотами расширения. Для каждого маршрутизатора был заказан модуль WIC-2T, который имеет два синхронных порта (Serial) и каждый такой порт поддерживает передачу со скоростью до 2 Мбит/с (рис. 7.8).
Объект 2Объект 2s0, v35s0, v35Watson SDSLWatson SDSLWatson SDSLWatson SDSLsO, v35sO, v35fethOfethOCisco 1720Cisco 1720
Объект 2
Объект 2
s0, v35
s0, v35
Watson SDSL
Watson SDSL
Watson SDSL
Watson SDSL
sO, v35
sO, v35
fethO
fethO
Cisco 1720
Cisco 1720
'Объект 1
I vРис. 7.8. Связь двух сетевых объектов
f .
1 Учитывая тот факт, что для осуществления доступа в сеть Интернет используются прямые провода, которые не обеспечивают достаточной надежности, было принято решение организовать два канала в сеть Интернет из двух объектов. Кана; Лы не зависят друг от друга, хотя оба они заканчиваются на площадках одного и того же провайдера. Оба канала работают одновременно и в то же время обеспечивают обоюдное резервирование на случай возникновения проблем со связью.
I Например, если в какой-либо момент времени с объекта 1 пропадает связь с Ин- 1 тернетом, то сетевой трафик будет автоматически переадресован в Интернет через
■ объект 2 — при этом на пути трафика просто возникнет дополнительный переход К (между объектами удалось сформировать прямой провод и были установлены
модемы Watson компании SCHMID TELECOM AG). Детали организации под< ной схемы резервирования будут рассмотрены далее, а пока отметим, что тщ подключение требует активного участия провайдера и может быть выполне с помощью протокола динамической маршрутизации, например OSPF. ,
Организация канала в сеть Интернет для объекта 2 выполнялось точно так з как и для объекта 1 — была написана заявка в отдел ПТС (Петербургская тез фонная сеть), занимающийся выделением прямых проводов, и после оплаты бы сформирована одна пара медного провода с сопротивлением порядка 1000 Q Для организации канала были закуплены модемы «Натеке» FlexDSL с модул цией РАМ и портами V.35. На сформированном прямом проводе максимальн; поддерживаемая скорость составляла порядка 1,8 Мбит/с, но при такой скор стп наблюдалась периодическая рассинхронизация между модемами. На скор сти 1,6 Мбит/с модемы работали довольно устойчиво. К слову, время восст новления синхронизации между модемами составляет порядка 15—20 секунд.
ПРИМЕЧАНИЕ—^
Модемы FlexDSL РАМ основаны на самой современной линейной технологии из ряда DSL —ТС-рД ТС-PAM была разработана для одновременного решения двух задач — достижения максимально дальности работы и обеспечения электромагнитной совместимости с другими DSL-устройстваб1 работающими по соседним парам. Технология ТС-PAM лежит в основе первого всемирного стандар ITU на высокоскоростную симметричную передачу по одной паре — G.shdsl. При заданной дли; абонентской линии использование ТС-PAM обеспечивает увеличение скорости на 15-45% по ера нению с САР или 2B1Q. При фиксированной скорости использование ТС-PAM обеспечивает увел чение дальности на 10-20% по сравнению с другими технологиями (данные компании «Натеке*^
Сама настройка модемов «Натеке» FlexDSL выполняется с помощью кабеля подключаемого к COM-порту компьютера. При настройке можно указать ск^ рость и другие параметры, в частности уточнить, какой модем будет работах как «ведущий» (master), а какой — как «ведомый» (slave). В рассматриваем^ модели предоставлены очень удобные возможности управления «ведомым» МО демом непосредственно с ведущего (после того как модемы установили дру с другом связь). Кроме того, скорость передачи данных меняется только ф ведущем модеме, и если параметры прямого провода позволяют, ведомый полу, чает эту информацию автоматически. В описываемой схеме построения сет) можно рекомендовать устанавливать ведущий модем в корпоративной сети, а в^ домый отдать поставщику услуг Интернета. Такое решение позволит операти^*' но менять скорость, если внезапно произошло ухудшение параметров прямого провода. Также к достоинствам этой модели модемов можно отнести отсутствий’ внешнего блока питания (хотя обычно модемы поставляются с внешним блоко питания).
Как уже было сказано, модем подключается к маршрутизатору с помощь интерфейса V.35. Для этого при приобретении маршрутизатора нужно не заб№ включить в заказ кабель. В обсуждаемой сети на объекте 2 установлен маршй тизатор Cisco 1720, для которого дополнительно был закуплен модуль WIC-Z предоставляющий два синхронных порта. Эти два порта при настройке марЩр тизатора обозначены как SerialO и Serial 1. Для подключения к сети Интерг или, иными словами, к модему FlexDSL, использовался порт Seriall (S1 — . краткости). Непосредственно настройка порта на маршрутизаторе очень проб*
В том случае, если в вашей сети будет только один канал в сеть Интернет, то следует обсудить с провайдером схему адресации и тип протокола канального уровня (например РРР или HDLC), который будет работать между вашим маршрутизатором и маршрутизатором провайдера. В реальности ситуация усложнялась тем, что существовали два канала в сеть Интернет, хотя и к одному провайдеру (на его разные площадки, связанные друг с другом). Провайдер выделил IP-адрес для интерфейса S1 (212.113.96.142, маска 255.255.255.252 или /30), а в качестве протокола канального уровня согласовали использование протокола HDLC. Этот протокол работает по умолчанию на маршрутизаторах Cisco Systems, и по
этому не отображается при просмотре конфигурации. Кроме того, на интерфейсе указан вес (метрика) для протокола маршрутизации OSPF — это требуется для поддержания работоспособности двух каналов в сеть Интернет:
।
interface Seriall
ip address 212.113.96.142 255.255.255.252
ip ospf cost 20
i
Если модемы были настроены правильно и маршрутизаторы «увидели» друг друга, то при выполнении команды show interface seriall (в нашем случае) будет выведена следующая информация.:
cisco-1720-object2#sh Int si
Seriall 1s up, Une protocol 1s up
Hardware is QUICC Serial
Internet address is 212.113.96.142/30
MTU 1500 bytes, BW 1544 Kbit. DLY 20000 usee.
reliability 186/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
798740 packets input, 245195353 bytes, 0 no buffer•
Received 9185 broadcasts, 0 runts, 0 giants. 0 throttles
128807 input errors, 37397 CRC. 49704 frame. 0 overrun. 0 ignored. 41706 abort
292075 packets output. 38991848 bytes. 0 underruns
output errors, 0 collisions, 20 interface resets
output buffer failures, 0 output buffers swapped out
carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
Самое важное отображается в первой строке результата — Seriall is up означает, что порт маршрутизатора «видит» подключенный к нему модем и получает от него необходимую сигнализацию по интерфейсу V.35 (DCD=up DSR=up DTR=up RTS=up CTS=up), а строка line protocol is up указывает на то, что протокол канального уровня HDLC (Encapsulation HDLC) успешно обменивается информацией между маршрутизатором организации и маршрутизатором на стороне провайдера.
Кстати, довольно интересную информацию можно почерпнуть из счетчиков ошибок на интерфейсе. Они в определенной мере отражают качество физиче-
ского канала между модемами. Чем меньше скорость, установленная на мо мах, тем меньше должно быть количество ошибок. Тут следует найти нек компромисс между скоростью и качеством.
Абсолютно аналогично было осуществлено подключение к сети Интернет о: екта 1, за исключением того, что использовались другие модемы (RAD ASM!-: и скорость канала была меньше (512 Кбит/с). Ну и естественно, на интерфей был назначен другой адрес IP — а именно 193.125.189.158/30.•
Наличие двух независимых каналов в сеть Интернет продиктовано тем, Ч' несмотря па относительную дешевизну применения прямых медных проводе для организации связи, вероятность возникновения различных проблем довод по высока. Нужно учитывать, что качество соединения может резко ухудшить» при изменении климатических условий (в Санкт-Петербурге с его непредсД зуемой погодой подобное происходит часто), могут проводиться ремонтные р боты или замены кабеля и т. и. Поэтому когда оценивались разные решения р ганизации доступа, выбор был сделан в пользу организации двух независим^ каналов. В общем, по опыту эксплуатации, можно утверждать, что это решен] работоспособно и позволяет при относительно небольших затратах получи: высокие скорости и приемлемую надежность.,
Разумеется, идея поддержания двух независимых каналов потребовала оче] тесной интеграции с провайдером услуг сети Интернет. Его специалисты пре дожили использовать протокол динамической маршрутизации OSPF, которь помимо всего прочего позволяет очень быстро реагировать на изменения в сёТ вой топологии. Перед гем как рассматривать технические детали организащ- связи, остановимся па адресной схеме.,4.
Очевидно, что для организации нормального доступа в сеть Интернет нужн.С использовать зарегистрированные адреса протокола IP, которые, как правилу выдаются провайдером. Количество выделяемых адресов зависит от множеств^ факторов. Определяющим, как правило, является конкретное техническое реш^г пне для организации доступа в сеть Интернет. Например, если для доступа ирг^ пользуется одновременно технологии NAT и РАТ, то достаточно будет имет§; один зарегистрированный (внешний) адрес IP. Если же принято решение о вне* дрении только технологии NAT (Network Address Translation) без осуществлен пия трансляции портов протоколов TCP/UDP (технология РАТ — Port Address, Translation), то количество адресов будет зависеть от количества одновременна; работающих с Интернетом внутренних пользователей сети. В нашем примере npHj заключении договора провайдер выделил целиком сеть класса С — 193.125.203.fr, /24. Вначале такое количество адресов казалось чересчур большим, но потому при развитии сети и увеличении количества объектов практически все адресно^ пространство было задействовано.’ J
Выделенный провайдером пул адресов можно назвать внешним или зар гистрированным. Иными словами, если в сеть Интернет отправить дейтаграмм с адресом отправителя из диапазона выделенных адресов и с корректным адр сом получателя, то последний может послать ответную дейтаграмму, и она бла получно дойдет до адресата. Однако администратор для своих внутренних се' вправе использовать специальные адреса, которые являются зарезервирован! ми и не маршрутизируются в сети Интернет. Например, к таким адресам от
сятся адреса из пула 192.168.*.*. Символ * указывает на то, что в данной позиции может быть любое приемлемое число (1-254). Использование подобных внутренних адресов предоставляет администратору очень удобную возможность распределять адреса так, как ему нравится. Например, если на одном из объектов корпоративной сети имеется не более десяти компьютеров, то для них можно выделить целиком сеть 192.168.2.0/24. При этом останется много неиспользуемых адресов, но так как данная сеть будет прочно ассоциироваться с данным объектом, то останется запас на будущее развитие.
Внутренние адреса не будут работать, если они будут установлены в качестве адресов отправителей дейтаграмм, уходящих в сеть Интернет. Точнее, дейтаграмма встретится с получателем (промежуточные маршрутизаторы будут проверять только целевой адрес) в сети Интернет, но вот ответа ждать не приходится. Интересно выполнить команду tracert с указанием любого адреса из внутреннего пула и посмотреть, как «далеко» дойдет дейтаграмма.
C:\>tracert 192.168.10.10
Трассировка маршрута к 192.168.10.10 с максимальным числом прыжков 30
<10 мс <10 мс <10 мс beetle.alternativa.spb.ru [192,168.3.254]
<10 мс <10 мс <10 мс 193.125.203.30
<10 мс <10 мс 10 ms StPetersburg-BM-l.Relcom.EU.net [212.113.96.141]
<10 мс 10 ms <10 мс StPetersburg-R-l.Relcom.EU.net [212.113.96.81]
<10 мс 10 ms <10 мс fa0-0-l.SPB-4.Relcom.net [193.125.15.134]
10 ms 20 ms 20 ms sl-0.M9-16.Relcom.net [193.124.254.41]
* * * Превышен интервал ожидания для запроса.
Маршрутизация дейтаграммы с адресом получателя 192.168.10.10 выполняется следующим образом. Сначала она отправляется к шлюзу по умолчанию в локальной сети (192.168.3.254 — в рассматриваемой сети это адрес внутреннего интерфейса защитного экрана с именем beetle), который, проверив свою таблицу маршрутизации и нс найдя маршрута в целевую сеть, отправляет ее по адресу шлюза по умолчанию, настроенного на нем (193.125.203.30), и так продолжается до 6-го перехода, на котором, по всей видимости, дейтаграмма просто отбрасывается маршрутизатором. А теперь выполним ту же самую операцию, но для зарегистрированного адреса.
C:\>tracert www.rbc.ru
Трассировка маршрута к www.rbc.ru [194.186.36.154] с максимальным числом прыжков 30:
<10 мс <10 мс <10 мс beetle.alternativa.spb.ru [192.168.3.254]
<10 мс <10 мс <10 мс 193.125.203.30
<10 мс 10 ms <10 мс StPetersburg-BM-l.Relcom.EU.net [212.113.96.141]
<10 мс 10 ms <10 мс StPetersburg-R-l.Relcom.EU.net [212.113.96.81]
10 мс 10 ms <10 мс fa0-0-l.SPB-4.Relcom.net [193.125.15.134]
10 ms 20 ms 20 ms sl-0.M9-16.Relcom.net [193.124.254.41]
311 ms 30 ms 741 ms M9-10.Relcom.Net [193.125.15.10]
10 ms 20 ms 21 ms ciscol2.Moscow.ST.NET [193.232.244.43]
Видно, что дейтаграмма минует 6-й переход и маршрутизируется дальше до ее окончательного получателя.
В том случае, если бы вся распределенная сеть находилась за защитным:^ раном, то, учитывая возможность реализации технологии NAT/PAT, можно бый| бы обойтись всего одним зарегистрированным адресом. Принимая во внимян^ то, что в технологии РАТ теоретически доступно более 64 000 портов для граней ции, мы получаем в свое распоряжение поддержку такого же количества вн^В ренних пользователей. На практике, скорее всего, возникнут проблемы с мот! ностью защитного экрана.
На рис. 7.8 видно, что оба маршрутизатора Cisco 1720 находятся в зоне Интед нета, или иными словами, они полностью открыты для доступа извне. К порта! Fast Ethernet (на рисунках порты обозначаются как fethO — нулевой интерфейс этих маршрутизаторов подключаются соответствующие локальные сети, которы защищаются с помощью защитных экранов. В принципе, при соответствуют^ настройке маршрутизаторы могут выполнять также роль и защитных экря-^Д но в рассматриваемой схеме на них возложена функция просто граничных мари рутизаторов, которые отвечают за поддержание доступа в Интернет. То ёсЯ учитывая тот факт, что провайдер выделил одну сеть класса С, каждому из ДВУ объектов для доступа в сеть Интернет нужно присвоить свои блоки зарегистД рованных адресов. Одним из способов реализации этого является разделена сети 193.125.203.0/24 на подсети, которые затем назначаются объектам. ;
Покажем в деталях процесс разделения. Изначально, сеть класса С обладав некоторыми обобщенными характеристиками, представленными в табл. 7.2. е^
Таблица 7,2. Первичные показатели выделенной провайдером адресной сети
Характеристика
Значение
Сетевой адрес
193.125.203.0
а
Класс
С
Адрес подсети
193.125.203.0 (совпадает с адресом сети)
Маска подсети
255.255.255.0
Битовая маска
HOnnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh
Число битов в поле адреса подсети
24
Число битов в поле адресов хостов
8
Количество хостов в подсети
254
п
При выделении подсетей следует оценить два важных показателя — скольку нужно подсетей и сколько доступных адресов должно быть в каждой (подробное^ в главе 2). Например, можно разбить сеть на две подсети, по 126 адресов в каждой При этом битовая маска подсети примет вид — ИОппппп.пппппппп.пппппШад nhhhhhhh. То есть для выделения подсетей будет использован один бит (стаи ший) из поля адресов узлов. В результате такого разделения администраТУ получит две подсети 193.125.203.0/25 и 193.125.203.128/25. В рассматриваек^ компании было принято решение о разбиении на 8 подсетей, по 30 адресов в ждой. Такое количество адресов удовлетворяет насущным задачам и оставляй
резерв на будущее, что важно. После разделения в распоряжении администратора появились следующие блоки адресов:
Подсеть 193.125.203.0 193.125.203.32 193.125.203.64 193.125.203.96 193.125.203.128 193.125.203.160 193.125.203.192 193.125.203.224Подсеть 193.125.203.0 193.125.203.32 193.125.203.64 193.125.203.96 193.125.203.128 193.125.203.160 193.125.203.192 193.125.203.224Маска255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224Маска255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224255.255.255.224Диапазон адресов хостовДиапазон адресов хостов193.125.203.1 -193.125.203.33193.125.203.65193.125.203.97193.125.203.129193.125.203.161193.125.203.193193.125.203.225193.125.203.1 -193.125.203.33193.125.203.65193.125.203.97193.125.203.129193.125.203.161193.125.203.193193.125.203.225193.125.203.30■ 193.125.203.62■ 193.125.203.94■ 193.125.203.126- 193.125.203.158- 193.125.203.190- 193.125.203.222- 193.125.203.254193.125.203.30■ 193.125.203.62■ 193.125.203.94■ 193.125.203.126- 193.125.203.158- 193.125.203.190- 193.125.203.222- 193.125.203.254
Подсеть 193.125.203.0 193.125.203.32 193.125.203.64 193.125.203.96 193.125.203.128 193.125.203.160 193.125.203.192 193.125.203.224
Подсеть 193.125.203.0 193.125.203.32 193.125.203.64 193.125.203.96 193.125.203.128 193.125.203.160 193.125.203.192 193.125.203.224
Маска
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
Маска
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
255.255.255.224
Диапазон адресов хостов
Диапазон адресов хостов
193.125.203.1 -
193.125.203.33
193.125.203.65
193.125.203.97
193.125.203.129
193.125.203.161
193.125.203.193
193.125.203.225
193.125.203.1 -
193.125.203.33
193.125.203.65
193.125.203.97
193.125.203.129
193.125.203.161
193.125.203.193
193.125.203.225
193.125.203.30
■ 193.125.203.62
■ 193.125.203.94
■ 193.125.203.126
- 193.125.203.158
- 193.125.203.190
- 193.125.203.222
- 193.125.203.254
193.125.203.30
■ 193.125.203.62
■ 193.125.203.94
■ 193.125.203.126
- 193.125.203.158
- 193.125.203.190
- 193.125.203.222
- 193.125.203.254
Процедура выделения такая же, как в примере из двух подсетей, за исключением того, что из поля адресов хостов задействуются три бита, а не один — HOnnnnn.nnnnnnnn.nnnnnnnn.nnnhhhhh. То есть допустимо ссылаться на одну из подсетей следующим образом — 193.125.203.128/27 (27 бит занимает поле адреса подсети).
После того как подсети были выделены, их можно назначать соответствующим объектам. К этому моменту было выполнено подключение еще двух объектов в дополнение к существующим (например, для подключения объекта 4 использовался маршрутизатор Cisco 1601, а для подключения объекта 3 — дополнительный модуль Ethernet, к которому подключаются модемы серии xDSL с портом Ethernet, а не V.35 — глава 10). На рис. 7.9 приведен возможный вариант схемы подсетей, хотя, по большому счету, все это зависит от предпочтений администратора.
В рассматриваемой сети маршрутизаторы не выполняют дополнительных функций (например, трансляции адресов) и, соответственно, с точки зрения расположения, например, объект 2 прозрачно доступен из сети Интернет. Аналогично и для других показанных на рисунке объектов. В результате, их локальные сети необходимо защищать с помощью определенных методов.
Например, можно установить защитный экран с двумя сетевыми адаптерами и настроить па нем технологию трансляции адресов. При этом нужно только учитывать, что в каждой подсети доступно до 30 адресов для задействования, из которых пара адресов выделяется для адреса интерфейса Ethernet маршрутизатора и внешнего интерфейса защитного экрана. В том случае, если используется технология NAT совместно с технологией РАТ, защитный экран транслирует внутренние адреса отправителей в один адрес своего внешнего интерфейса и одновременно меняет номера портов на стороне отправителя. Здесь будет достаточно двух адресов и при разделении сети на подсети, таким образом, можно было бы в поле адресов хостов оставить только два бита — HOnnnnn.nnnnnnnn.nnnnnnnn.nnnnnnhh, отдавая 30 битов для поля адреса подсети. Тогда общее количество подсетей составило бы 64. Кстати, такое решение вполне применимо для назначения адресов синхронным интерфейсам маршрутизатора — если зарезервированные адреса нельзя использовать по каким- либо причинам. ■
sOsOeth1eth1Рис. 7.9. Назначение подсетей разным объектамРис. 7.9. Назначение подсетей разным объектам
sO
sO
eth1
eth1
Рис. 7.9. Назначение подсетей разным объектам
Рис. 7.9. Назначение подсетей разным объектам
Важно отметить, что для хостов, отправляющих извне данные в сеть 193.1 203.*, разделение на подсети абсолютно прозрачно. То есть, например, дейтагрг ма с адресом получателя 193.125.203.100 поступает на интерфейс S1 маршрут
затора Cisco 1720 (сейчас не важно, на какой именно из двух), а он, проверя свою таблицу маршрутизации, определяет, на какой интерфейс нужно отправил дейтаграмму дальше, чтобы она достигла получателя. Ведь, несмотря на то, ЭД сеть была поделена на 8 подсетей, адреса остаются уникальными и не пересев ются друг с другом и факт разделения на подсети остается неизвестным отпр| вителям в сети Интернет.■'*
После того как каждой части корпоративной сети были назначены подсуй приходит время назначить конкретные адреса нужным сетевым интерфейс^ Можно порекомендовать один раз подробно нарисовать схему распределения,^ ресного пространства, а потом постоянно обновлять ее — это пригодится при ративном решении различных проблем. Естественно, вопрос назначения адредй интерфейсам сетевых устройств полностью зависит от воли администратора, J лучше придерживаться какой-то заранее отработанной схемы. Например, автд старается присваивать интерфейсам Ethernet граничных маршрутизаторов нЯ большие адреса из перечня возможных в подсети. В нашем примере послё^Я значения адресов схема будет выглядеть, как это показано на рис. 7.10. Ля
193.125.203.62/27193.125.203.33/27193.125.203.62/27193.125.203.33/27192.168.101.2/24192.168.101.1/24192.168.101.2/24192.168.101.1/24193.125.203.222/27193.125.203.222/27eth1 193.125.189.158/24eth1 193.125.189.158/24Рис. 7.10. Пример назначения адресов интерфейсам сетевых устройствРис. 7.10. Пример назначения адресов интерфейсам сетевых устройств
193.125.203.62/27193.125.203.33/27
193.125.203.62/27193.125.203.33/27
192.168.101.2/24
192.168.101.1/24
192.168.101.2/24
192.168.101.1/24
193.125.203.222/27
193.125.203.222/27
eth1 193.125.189.158/24
eth1 193.125.189.158/24
Рис. 7.10. Пример назначения адресов интерфейсам сетевых устройств
Рис. 7.10. Пример назначения адресов интерфейсам сетевых устройств
Адреса интерфейсов, непосредственно подключаемых к сети Интернет, как правило, назначаются провайдером услуг. Обратите внимание на то, что па каналах между маршрутизаторами используются адреса из сети класса С (192.168.100.0 и 192.168.101.0/24), принадлежащие к зарегистрированным адресам. Другим вариантом может быть реализация так называемого механизма безадресных интерфейсов с помощью команды ip unnumbered. В рассматриваемой сети задействован первый способ для корректной работы протокола маршрутизации OSPF.
Как уже было отмечено, для организации двух одновременно работающих каналов в сеть Интернет используется протокол OSPF. Обратимся еще раз к схеМе организации связи. Для того чтобы оба канала были одновременно рабочими
и обеспечивали взаимное резервирование друг друга при доступе в Интер» нужно сделать так, чтобы шлюз по умолчанию (default gateway) на каждом мар рутизаторе менялся в ответ на изменение в сетевой топологии. Если то особо оговорено, при нормальной работе всех каналов (двух каналов в сеть Интерн и каналов между маршрутизаторами Cisco 1720), шлюз по умолчанию на кажд, маршрутизаторе указывает на интерфейс S1, или, иными словами, на ближа ший к нему маршрутизатор провайдера. В такой ситуации трафик, наприме поступающий из локальной сети объекта 2 на интерфейс fethO (Fast Ethernet С будет (если иных маршрутов не прописано) передаваться через интерфейс 5 в сеть Интернет. Схема его дальнейшего движения не принципиальна, так к; этот вопрос остается на «совести» провайдера (рис. 7.11).
Шлюз по умолчанию►Шлюз по умолчанию►• Объект 2Cisco 1720•.s0, v35• Объект 2Cisco 1720•.s0, v35Watson SDSLWatson SDSL
Шлюз по умолчанию►
Шлюз по умолчанию►
• Объект 2Cisco 1720
•.s0, v35
• Объект 2Cisco 1720
•.s0, v35
Watson SDSL
Watson SDSL
Рис. 7.11. Рассылка маршрутов по умолчаниюРис. 7.11. Рассылка маршрутов по умолчанию
Рис. 7.11. Рассылка маршрутов по умолчанию
Рис. 7.11. Рассылка маршрутов по умолчанию
li
Теперь предположим, что канал в сеть Интернет с объекта 2 пропал. В рез; тате, трафик должен автоматически перенаправляться через интерфейс S0 на
логичный маршрутизатор, но уже на объекте 1, который и отправит его дальше в сеть Интернет. Причем подобное переключение должно производиться автоматически и как можно быстрее. Для этого и используется протокол маршрутизации OSPF. поддержка которого включена также и на стороне провайдера. Технические детали организации взаимодействия маршрутизаторов на двух разных площадках провайдера нс суть важны, но с точки зрения логики получается некий контур из четырех маршрутизаторов и связующих их каналов. Если один из этих каналов перестает работать, то протокол маршрутизации фиксирует это и вносит соответствующие изменения в таблицу маршрутизации. К слову, протокол OSPF характеризуется довольно быстрым реагированием на изменение сетевой топологии.
Эксперименты показывают, что при пропадании одного из каналов в сеть Интернет маршрутизаторам требуется порядка 10 секунд (период прохождения сообщений keepalive) па то, чтобы перестроить свои таблицы маршрутизации. В течение этого времени доступ у клиентов, само собой, работать не будет, но это вовсе не большой срок простоя. Правда, к сожалению, для туннеля РРТР (глава 10) такого перерыва вполне достаточно, чтобы считать, что туннель виртуальной частной сети нарушен, и приступить к его восстановлению.
При искусственном отключении канала с объекта 2 в сеть Интернет на консоль маршрутизатора выдается сообщение:
lw2d: №PF-5-ADJCHG: Process 2121, Nbr 212.113.96.141 on Serial 1 from FULL to DOWN. Neighbor Down: Dead timer expired (протокол маршрутизации ospf не получил сообщения от удаленного (адрес 212.113.96.141) маршрутизатора через интерфейс Serial 1)
lw2d: ^LINEPR0T0-5-UPD0WN: Line protocol on Interface Seriall. changed state to down (протокол канального уровня на интерфейсе Seriall перешел в состояние down)
После обнаружения изменений в сетевой топологии таблица маршрутизации обновляется и теперь маршрут по умолчанию будет указывать на интерфейс SerialO.
cisco-1720-object-2#sh ip route
0*E2 0.0.0.0/0 [110/80] via 192.168.100.2. 00:00:18. SerialO
. Однако когда канал восстанавливается вновь, для клиентов переключение на основной канал происходит незаметно. При тестировании этот момент удалось • обнаружить только при наблюдении за изменением времени отклика для коман- . ды ping (добавился еще один переход и время ответа чуть-чуть возросло).
ИЗ ОПЫТА
При настройке работающего маршрутизатора, подключая его к работающему компьютеру через консольный порт, рекомендуется быть предельно осторожным, так как можно вывести из строя порт на маршрутизаторе. Автор столкнулся с подобной ситуацией, когда настраивал связь двух маршрутизаторов (Cisco 1601 и Cisco 1720) с одного компьютера через модемы FlexDSL с портами v35. Поскольку компьютер был один, а маршрутизаторов вдвое больше, приходилось поочередно подключаться к каждому из них. И в какой-то момент консольный порт на Cisco 1720 перестал работать. Этот маршрутизатор пришлось отдавать в ремонт. Правильнее было бы использовать на компьютере Два последовательных порта с двумя кабелями, каждый из которых подключается к маршрутизатору.
Технология Frame Relay в построении распределенной сети
В этой главе рассматриваются теоретические и практические вопросы исполу вания технологии Frame Relay, которая является одной из наиболее попудй ных в нашей стране. Отдельно будет обсуждена настройка управления тррф ком, что может быть востребовано при наличии низкоскоростных соединен и интенсивного обмена информацией. Основное внимание будет уделено имё но практической стороне работы Frame Relay.
Общие сведения о технологии Frame Relay
Так как в большинстве случаев организации пользуются услугами провайдер сети Frame Relay, администратору нет особой необходимости досконально зна всю подноготную технологии Frame Relay. Но понимать все параметры, опред ляющие предлагаемый сервис, методы оптимизации этих параметров он додже А с учетом большого количества таких параметров задача определения серви становится достаточно сложной. И чтобы отношения с провайдером не дост;
ляли массу хлопот, администратор должен иметь представление, какие момен1 не следует упускать из виду при согласовании этих параметров и настройке се
его граничащего с сетью Frame Relay устройства.
Как и многие другие средства и технологии связи, Frame Relay появилг в исследовательском подразделении Bell Labs компании AT&T. В 1988 году rq токол Frame Relay был включен в стандарт ISDN в качестве рекомендации 1.1
и утвержден подкомитетом по стандартам Международного консультативно
комитета по телеграфии и телефонии (CCITT). К моменту появления okoi тельного варианта стандарта на технологию ISDN рекомендация 1.122 преврати лась в независимый протокол со своей практической областью применения.. * *,
Эта технология разрабатывалась с учетом высокоскоростной передачи дани! и низкого уровня ошибок современных сетевых средств. Первые сети с комм тацией пакетов были рассчитаны на скорость передачи 64 Кбит/с, в то вре! как сети Frame Relay предназначались для гораздо больших скоростей. ДостИ повышения скорости передачи помогло исключение накладных расходов, кот рые неизбежны при контроле ошибок.
Издержки при пакетной коммутации вызываются контролем вызовов, поиском ошибок и контролем потоков. В технологии Х.25, которая в настоящее время практически не используется, но ранее была довольно популярна, пакеты управления вызовами, используемые для установления и разрыва виртуальных соединений, переносятся по тому же соединению, что и пакеты данных. Фактически вся передача сигналов осуществляется по основному каналу (так называемая передача in-band).
В сети Frame Relay передача сигналов контроля вызова осуществляется по виртуальному соединению (Virtual Circuit), отличному от используемого для передачи пользовательских данных. В пользовательском интерфейсе один канал управления соединением служит для контроля всех коммутируемых соединений передачи данных. Так как в настоящее время провайдеры услуг Frame Relay предлагают в большинстве своем только постоянные виртуальные соединения (Permanent Virtual Circuit, PVC), то промежуточным коммутирующим узлам нет необходимости поддерживать таблицы состояний или обрабатывать управляющие вызовы для каждого соединения в отдельности.
Наиболее очевидно преимущество Frame Relay над Х.25 в управлении потоками и контроле ошибок. Технология Х.25 задействует физический, канальный и сетевой уровни, то есть три нижних уровня эталонной модели OSI. На канальном уровне осуществляется контроль ошибок в транзитных узлах сети с коммутацией пакетов. При этом каждому узлу присваивается порядковый номер. После проведения контроля одновременно с передачей данных на следующий узел предыдущему передастся подтверждение приема. На сетевом уровне происходит мультиплексирование нескольких потоков данных разных виртуальных соединений в единый поток к пользователю. Для этого каждый передаваемый кадр имеет свой номер виртуального соединения, который используется для маршрутизации и коммутации трафика. Управление потоком и контроль ошибок на всем пути следования пакетов от отправителя до получателя осуществляются при помощи схемы нумерации сетевого уровня.
Основное различие между технологиями Frame Relay и Х.25 состоит именнов- механизме коррекции ошибок. Так как технология Х.25 разрабатывалась более 20 лет назад для передачи данных через аналоговые каналы связи, которые характеризовались плохим качеством, то требовались различные механизмы коррекции ошибок и алгоритмы повторной передачи потерянных данных.
. В соединениях Frame Relay мультиплексирование осуществляется на канальном уровне модели OSI, а контроль ошибок и управление потоком вовсе отсутствуют. Каждый кадр канального уровня содержит номер логического соединения, который используется для маршрутизации и коммутации трафика. Порядковые номера для управления потоком и контроля ошибок не используются. При этом контроль правильности передачи данных от отправителя получателю должен осуществляться на более высоком уровне модели OSI (например, протоколом TCP).
Как и технология Х.25, Frame Relay выполняет статическое мультиплексирование передаваемых кадров с данными от различных отправителей и направляет их через один канал связи. При Этом могут поддерживаться скорости передачи между 56 Кбит/с и 45 Мбит/с (в то время как скорость сети Х.25 составляет 56 или 64 Кбит/с). Другой возможностью, унаследованной от технологии Х.25,
является механизм передачи, ориентированный на предварительное устат ние виртуального соединения между взаимодействующими абонентами.
Причиной того, что технология Frame Relay столь стремительно заним' нишу локальных сетей, является ее экономическая эффективность. Frame Re не требует построения новой коммуникационной инфраструктуры. Обычно ’ что требуется, — это программное обновление существующих маршрутизив
щих систем или незначительная модернизация программно-аппаратного об© чения систем коммутации кадров Х.25.
Технология Frame Relay имеет много общего с ATM (Asynchronous Tra Mode — асинхронный режим передачи). Основное различие между ними на т не организации блоков информации состоит в том, что в первой длина ка переменна, а во второй —■ постоянна и равна 53 байт. Большинство соврем© сетей Frame Relay рассчитаны на максимальную длину кадра в 1024 байт, из торых от 6 до 8 байт занимают служебные данные. ■
Структура кадра передачи данных в сетях Frame Relay достаточно npd (рис. 8.1). Данные помещаются между полем заголовка (часто все поле загс® ка называется DLCI — Data Link Connection Identifier, идентификатор de с источником данных), которое может занимать от 2 до 4 байт, и полем конт^Е ной суммы в конце кадра (FCS), призванного обнаруживать любые битовые ой ки. Числовое значение, записанное в полях DLCI, служит для идентификй виртуального соединения между абонентами. В одном кадре может быть пер но до 8000 байт пользовательских данных. ■
Байт 1Байт 2Байт 1Байт 2DLCI — Data Link Connection Identifier, .C/R — Command/Response Field Bit (не изменяется внутри сети Frame Relay)FECN —■ Forward Explicit Congestion NotificationяBECN — Backward Explicit Congestion Notification'iDE — Discard Eligibility Indicator„EA — Extension Bit (бит, указывающий на больший заголовок)'DLCI — Data Link Connection Identifier, .C/R — Command/Response Field Bit (не изменяется внутри сети Frame Relay)FECN —■ Forward Explicit Congestion NotificationяBECN — Backward Explicit Congestion Notification'iDE — Discard Eligibility Indicator„EA — Extension Bit (бит, указывающий на больший заголовок)'
Байт 1Байт 2
Байт 1Байт 2
DLCI — Data Link Connection Identifier, .
C/R — Command/Response Field Bit (не изменяется внутри сети Frame Relay)
FECN —■ Forward Explicit Congestion Notificationя
BECN — Backward Explicit Congestion Notification'i
DE — Discard Eligibility Indicator„
EA — Extension Bit (бит, указывающий на больший заголовок)'
DLCI — Data Link Connection Identifier, .
C/R — Command/Response Field Bit (не изменяется внутри сети Frame Relay)
FECN —■ Forward Explicit Congestion Notificationя
BECN — Backward Explicit Congestion Notification'i
DE — Discard Eligibility Indicator„
EA — Extension Bit (бит, указывающий на больший заголовок)'
Рис. 8.1. Формат кадра Frame Relay
Поскольку можно передавать как короткие, так и очень большие кадры, ■
ствует вероятность того, что большие кадры вызовут увеличенную зад< между передачей двух коротких кадров. Однако несмотря на это обстоят во, следующие несколько лет технология Frame Relay будет играть важ)
в локальных сетях, хотя ее использование для типичных широкополосных служб с изменяющимся профилем трафика ограничено.
С уверенностью можно сказать, что сегодня технология Frame Relay — это зрелая и чрезвычайно популярная, в том числе и в нашей стране, технология создания сетевой магистрали. Ее основное назначение состоит в выполнении роли связующего звена между узлами корпоративной сети. При построении корпоративной сети на базе технологии Frame Relay, как правило, рассматриваются три основных варианта ее организации.
Частная сеть на базе выделенных линий. Организация арендует линии связи и приобретает необходимое оборудование (например, коммутаторы, маршрутизаторы или мультиплексоры). Построенная на их базе сеть является ее собственностью и находится под полным контролем и управлением.
Виртуальная частная сеть. Организация покупает услуги сетей Frame Relay у компаний, предоставляющих телекоммуникационные услуги. Таким образом, организация создает частную корпоративную сеть, обращаясь к услугам сетей Frame Relay общего пользования, и осуществляет полный контроль над сетью и административное управление ею.
Соглашение с внешней организацией о создании и управлении сетью. Существующая корпоративная сеть передается телекоммуникационной компании, которая проводит административное управление этой сетью в интересах фирмы-клиента, а также предоставляет услуги связи, оборудование и реализует поддержку сети. За рубежом существует ярко выраженная рыночная тенденция к таким соглашениям; на данной основе в мире функционирует 30 % корпоративных сетей. Это обусловлено в большинстве случаев неспособностью организации самостоятельно управлять сложной по эксплуатации корпоративной сетью.
Однако независимо от способа создания корпоративной сети администратору необходимо иметь представление о средствах и приемах управления такой сетью, способах оптимизации режимов работы. Причем технология для магистрали корпоративной сети должна отвечать трем основным требованиям.
Надежность. В случае если организация не владеет всей сетью, а пользуется ' услугами телекоммуникационных компаний, то соединение, скажем, меж. Ду офисами характеризуется некоторой неопределенностью из-за отсутствия контроля над линиями связи. Технология Frame Relay предоставляет достаточную отказоустойчивость благодаря обеспечению динамической перемаршрутизации в случае отказа постоянного виртуального соединения. Физически сети Frame Relay образованы соединением коммутаторов в ячеистую структуру. Одно из преимуществ такой структуры состоит в том, что она обеспечивает хорошую степень отказоустойчивости. Если выходит из строя используемый постоянным виртуальным соединением коммутатор, то соседний коммутатор создаст новый путь для этого соединения. В результате характеристики пеРедачи могут лишь несколько ухудшиться. Другим достоинством такой структуры является возможность направлять кадры в обход перегруженных коммутаторов.
2.2.Доступность. Frame Relay является вполне доступной со стороны локалы сети, так как поддерживает пакетный трафик. Frame Relay позволяет пер< вать кадры относительно большого размера, которого достаточно для кетов Ethernet и Token Ring (максимальная длина для них составляет 1Доступность. Frame Relay является вполне доступной со стороны локалы сети, так как поддерживает пакетный трафик. Frame Relay позволяет пер< вать кадры относительно большого размера, которого достаточно для кетов Ethernet и Token Ring (максимальная длина для них составляет 1и 4096 байт соответственно). Благодаря этому пакеты не надо фрагмен-и 4096 байт соответственно). Благодаря этому пакеты не надо фрагмен-вать при передаче, соответственно на сегментацию и сборку.вать при передаче, соответственно на сегментацию и сборку.FrameFrameRelay лишенаRelay лишенанакладных расхо.накладных расхо.3. Удобство. Соединение по глобальной сети должно поддерживать различи скорости передачи исходящего и входящего трафика. Ввиду того что вхо щий трафик к узлу локальной сети отличается от исходящего трафика, г бальная сеть должна поддерживать асимметричный режим работы. Крс того, для обеспечения необходимого управления потоком технология глоба3. Удобство. Соединение по глобальной сети должно поддерживать различи скорости передачи исходящего и входящего трафика. Ввиду того что вхо щий трафик к узлу локальной сети отличается от исходящего трафика, г бальная сеть должна поддерживать асимметричный режим работы. Крс того, для обеспечения необходимого управления потоком технология глобаной сети должна поддерживать стек протоколов TCP/IP на верхних уров)ной сети должна поддерживать стек протоколов TCP/IP на верхних уров)моделимоделиOSI. ТехнологияOSI. ТехнологияFrameFrameRelayRelayотвечаетотвечаетэтимэтимтребованиямтребованиямза счет вза счет в
2.
2.
Доступность. Frame Relay является вполне доступной со стороны локалы сети, так как поддерживает пакетный трафик. Frame Relay позволяет пер< вать кадры относительно большого размера, которого достаточно для кетов Ethernet и Token Ring (максимальная длина для них составляет 1
Доступность. Frame Relay является вполне доступной со стороны локалы сети, так как поддерживает пакетный трафик. Frame Relay позволяет пер< вать кадры относительно большого размера, которого достаточно для кетов Ethernet и Token Ring (максимальная длина для них составляет 1
и 4096 байт соответственно). Благодаря этому пакеты не надо фрагмен-
и 4096 байт соответственно). Благодаря этому пакеты не надо фрагмен-
вать при передаче, соответственно на сегментацию и сборку.
вать при передаче, соответственно на сегментацию и сборку.
Frame
Frame
Relay лишена
Relay лишена
накладных расхо.
накладных расхо.
3. Удобство. Соединение по глобальной сети должно поддерживать различи скорости передачи исходящего и входящего трафика. Ввиду того что вхо щий трафик к узлу локальной сети отличается от исходящего трафика, г бальная сеть должна поддерживать асимметричный режим работы. Крс того, для обеспечения необходимого управления потоком технология глоба
3. Удобство. Соединение по глобальной сети должно поддерживать различи скорости передачи исходящего и входящего трафика. Ввиду того что вхо щий трафик к узлу локальной сети отличается от исходящего трафика, г бальная сеть должна поддерживать асимметричный режим работы. Крс того, для обеспечения необходимого управления потоком технология глоба
ной сети должна поддерживать стек протоколов TCP/IP на верхних уров)
ной сети должна поддерживать стек протоколов TCP/IP на верхних уров)
модели
модели
OSI. Технология
OSI. Технология
Frame
Frame
Relay
Relay
отвечает
отвечает
этим
этим
требованиям
требованиям
за счет в
за счет в
можности предоставления асимметричных виртуальных соединений.
Для защиты от сбоев на уровне узла провайдеры Frame Relay часто предла ют запасное постоянное виртуальное соединение. При этом оно имеет суще венно меньшую оговоренную скорость передачи (Committed Information Ra*
CIR), чем основное. В экстренных случаях запасное виртуальное соединен: будет активизировано практически немедленно.
CIR — минимальная полоса пропускания, гарантированная каждому пос1!
явному или коммутируемому виртуальному соединению. Эта скорость (из» ряется в битах в секунду) заявляется абонентом в соответствии с объемом д< ных, которые он собирается передавать по сети, и гарантируется провайдер услуги Frame Relay (обычно этот параметр отмечается в договоре на предоср
ление услуги). ,
Скорость может варьироваться от 16 Кбит/с до 44,8 Мбит/с. Если скоро* отправки кадров не превосходит скорость порта подключения абонента (так 1 зываемую AR — Access Rate) и пропускная способность сети Frame Relay в Д1 ный момент имеет резерв, то абонент может превысить согласованное значег CIR. Скорость, с которой абонент посылает данные при наличии достаточв пропускной способности, называется oversubscription rate (то есть скорое превышающая ранее оговоренную).
Предположим, что организация получила выделенный канал, имеют максимальную скорость передачи 128 Кбит/с, но заключила договор на С в 64 Кбит/с, то есть канал позволяет передавать пакеты со скоростью 128 Кбит
но сеть не дает гарантии на успешность такой передачи. Кадры, которые пере, ются на скорости большей, чем CIR (в данном случае 64 Кбит/с), называю! избыточными кадрами и помечаются специальным битом (бит DE — Р)^ Eligibility) в заголовке. Эти кадры могут быть доставлены адресату при налич на данный момент неиспользуемой части полосы пропускания. Поскольку Й вайдер не гарантирует передачу информации с большей скоростью, чем оговор ная, используется метод справедливого сброса кадров. При возникновении! регрузки коммутаторы Frame Relay будут в первую очередь отбрасывать име кадры с установленным битом DE. Это, забегая вперед, можно показать н#
альном примере, запрашивая статистику по постоянному виртуальному соединению на маршрутизаторе Cisco Systems:
Router#sh fr pvc
PVC Statistics for interface Seriall (Frame Relay DTE)
DLCI = 18. DLCI USAGE = LOCAL. PVC STATUS = ACTIVE. INTERFACE = Seri al 1.1
Input pkts 785864 out bytes 420859843 in BECN pkts 0 in DE pkts 12361 out beast pkts 96186 pvc create time 5w5d,Input pkts 785864 out bytes 420859843 in BECN pkts 0 in DE pkts 12361 out beast pkts 96186 pvc create time 5w5d,output pkts 673709 in bytes 106316635
Input pkts 785864 out bytes 420859843 in BECN pkts 0 in DE pkts 12361 out beast pkts 96186 pvc create time 5w5d,
Input pkts 785864 out bytes 420859843 in BECN pkts 0 in DE pkts 12361 out beast pkts 96186 pvc create time 5w5d,
dropped pkts 134in FECN pkts 0
out FECN pkts 0out BECN pkts 0
out DE pkts 0
out beast bytes 15421788
last time pvc status changed 02:42:20
В результате работы команды присутствует статистика полученных по виртуальному соединению кадров Frame Relay с установленным битом DE (in DE pkts 12361). Эта информация может служить неким измерителем загруженности магистральной сети провайдера Frame Relay, так как позволяет оценить, с каким увеличением скорости относительно CIR сеть может принять данные на выбранном промежутке времени. Кроме того, следует обратить внимание на параметр dropped pkts, указывающий количество пакетов, которые были отброшены маршрутизатором па уровне Frame Relay, например по причине перегрузки постоянного виртуального соединения. Для того чтобы очистить статистику, можно воспользоваться командой clear counters.
Важно отметить, что из-за того, что пользователям позволено передавать кадры с превышением скорости CIR, может оказаться так, что сеть Frame Relay будет не в состоянии обработать кадры всех пользователей, если многие из них станут передавать информацию одновременно.
Когда коммутатор в сети Frame Relay испытывает перегрузку, он начинает вставлять биты явного оповещения о перегрузке для отправителя BECN (Backward Explicit Congestion Notification) и получателя FECN (Forward Explicit Congestion Notification) в кадры Frame Relay. Установленный бит BECN информирует устройство отправителя (маршрутизатор) о возникновении перегрузки в виртуальном соединении на пути к получателю. Получив предупреждение, • устройство отправителя уменьшает скорость передачи или даже временно приостанавливает передачу, в зависимости от выбранной политики управления трафиком. Если говорить об информировании получателя, то последний может предпринимать лишь некоторые косвенные действия в ответ на состояние перегрузки.
Рассматриваемый механизм извещений имеет свои недостатки. Во-первых, он должен быть явно включен (для оборудования Cisco Systems). Во-вторых, важно знать время и тип реакции оборудования пользователей на эти сообщения, а также знать, будет ли оно вообще реагировать. Но на перегрузку надо реагировать в любом случае, иначе ситуация может только ухудшаться. По этой причиНе введен механизм пометки кадров, которые будут отбрасываться с момента Наступления перегрузки до момента срабатывания аппаратуры пользователей, по и здесь есть свои проблемы. Вероятность того, что будут отбрасываться толь- ^Й-КЗдры, помеченные битом DE, в разных сетях различна. Это связано с тем,
что для поддержки ожидаемого уровня трафика каждый провайдер строит свя сеть по-своему. Ввиду отсутствия стандартов на архитектуру сети или управлеш. перегрузками, таковые могут возникнуть при разных уровнях интенсивном трафика в зависимости от возможностей и особенностей коммутаторов пЫ пускной способности каналов связи между ними и топологии сети. Таким образец при выборе провайдера и заключении с ним договора необходимо иметь предстш ление о том, какой гарантированный процент пакетов кадров не будет отброше и достигнет получателя. Сеть Frame Relay может отбрасывать любые кадры, п этому необходимо знать процентное соотношение отбрасываемых помеченнь и не помеченных битом DE кадров. Эту информацию следует получить у прова дера или определить самим, используя методы управления и мониторинга сев
Сервис сети Frame Relay характеризуется тремя основными параметрами: цр пускной способностью CIR, гарантированным объемом кадров Вс (Commit] Burst size) и Be (Excess Burst). Каждый из этих параметров привязан к опре, ленному интервалу времени (Т). Как указывалось выше, CIR — это скорое с которой провайдер обязуется передавать данные за период времени Т. Вс пре ставляет собой максимальное число битов, которое сеть может передавать время Т, а Be — это максимальное число битов сверх Вс, которое сеть способ в принципе принять за время Т. Соотношение между Т, Вс и CIR следующей
Т = Вс / CIR
Если принять интервал времени равным одной секунде, как это делают м$й гие провайдеры, то в предыдущем равенстве значение CIR равно Вс. Несмоя на то что большинство провайдеров используют длительность в одну секум интервалы времени не стандартизованы. Д
Выбор конкретного значения того или иного параметра целиком зависим тех целей, которые преследует организация, используя сеть Frame Relay. Hati; мер, для передачи чувствительной к задержкам информации необходима сета встроенной организацией очередей и гарантированной задержкой, а также cj вольно высокими значениями CIR в расчете на виртуальное соединение, в же сеть используется главным образом для передачи обычных данных, задерз не является критичным параметром. В этом случае высокоскоростной ка с малым или даже нулевым значением CIR способен обеспечить необходим
пропускную способность.
Настройка Frame Relay на маршрутизатора? Cisco SystemsJ
Базовая настройка маршрутизатора при его подключении к сети Frame Relay # полагает выполнение следующих простых шагов. На первом этапе требу^Хй® брать интерфейс, на котором будут производиться настройки, и перейти в р конфигурирования этого интерфейса. Далее указывается тип инкапсу" данных. Выбор осуществляется посредством выполнения команды encag frame-relay, а в качестве ее параметра указывается собственно тип инкапс^
Им может быть тип cisco (значение по умолчанию) или ietf. Первый тип используется, если па другом конце соединения осуществляется подключение к оборудованию компании Cisco Systems.
СОВЕТ
Перед изменением типа инкапсуляции компания Cisco Systems рекомендует принудительно отключить интерфейс с помощью команды shutdown.
Далее следует указать тип протокола LMI (Local Management Interface — интерфейс локального управления), который настроен на установленных у провайдера коммутаторах Frame Relay. Тип инкапсуляции и тип протокола LMI должны сообщаться представителями провайдера на этапе начальной настройки оборудования.
Настройка LMI осуществляется с помощью команды frame-relay Imi-type с указанием необходимого протокола, которым может быть ansi, cisco или q933i. При использовании операционной системы Cisco IOS версии 11.2 и старше не обязательно уточнять тип LMI, так как маршрутизатор умеет определять его автоматически. В следующем примере интерфейс Serial! маршрутизатора подключен к оборудованию провайдера услуг Frame Relay, и на нем указывается тип инкапсуляции (frame-relay) и тип используемого протокола LMI (ansi).
Router#configure terminal•
Enter configuration commands, one per Une. End with CNTL/Z.
Router(config)#interface serlall
Router(config-if)#no ip address
Router(config-1f)#encapsulation frame-relay
Router(config-if)#frame-relay Imi-type ansi
ПРИМЕЧАНИЕ
Если при настройке синхронного интерфейса администратор дал команду не использовать сообщения keepalive, то протокол LMI остановится. Напомним, что сообщения keepalive посылаются через соединение для подтверждения его активности.
Следует отметить, что корректная настройка протокола LMI является одним из условий правильной работы с сетью Frame Relay. В случае возникновения проблем со связью рекомендуется, в числе прочего, проверить функционирова- . ние этого протокола с помощью команды show frame-relay Imi:
Router#sh fr Imi
LMI Statistics for interface Serlall (Frame Relay DTE) LMI TYPE = ANSILMI Statistics for interface Serlall (Frame Relay DTE) LMI TYPE = ANSIInvalid Unnumbered info 0Invalid dummy Call Ref 0Invalid Status Message 0Invalid Information ID 0Invalid Report Request 0Invalid Unnumbered info 0Invalid dummy Call Ref 0Invalid Status Message 0Invalid Information ID 0Invalid Report Request 0Num Status Enq. Sent 182568Num Update Status Rcvd 0Num Status Enq. Sent 182568Num Update Status Rcvd 0Invalid Prot Disc 0Invalid Msg Type 0Invalid Lock Shift 0Invalid Report IE Len 0Invalid Keep IE Len 0Num Status msgs Rcvd 182535Num Status Timeouts 33Invalid Prot Disc 0Invalid Msg Type 0Invalid Lock Shift 0Invalid Report IE Len 0Invalid Keep IE Len 0Num Status msgs Rcvd 182535Num Status Timeouts 33
LMI Statistics for interface Serlall (Frame Relay DTE) LMI TYPE = ANSI
LMI Statistics for interface Serlall (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0
Invalid dummy Call Ref 0
Invalid Status Message 0
Invalid Information ID 0
Invalid Report Request 0
Invalid Unnumbered info 0
Invalid dummy Call Ref 0
Invalid Status Message 0
Invalid Information ID 0
Invalid Report Request 0
Num Status Enq. Sent 182568
Num Update Status Rcvd 0
Num Status Enq. Sent 182568
Num Update Status Rcvd 0
Invalid Prot Disc 0
Invalid Msg Type 0
Invalid Lock Shift 0
Invalid Report IE Len 0
Invalid Keep IE Len 0
Num Status msgs Rcvd 182535
Num Status Timeouts 33
Invalid Prot Disc 0
Invalid Msg Type 0
Invalid Lock Shift 0
Invalid Report IE Len 0
Invalid Keep IE Len 0
Num Status msgs Rcvd 182535
Num Status Timeouts 33
В перечне отображаемых параметров следует обратить внимание на два: Status Enq. Sent и Num Status msgs Rcvd, которые показывают количество отпр ленных и полученных маршрутизатором статусных сообщений протокола Ц Значения этих параметров при нормальной работе должны увеличиваться с р ной скоростью.
После того как выполнена настройка маршрутизатора на работу с техноло1 ей Frame Relay, администратор сети может проверить корректность выполю ных настроек с помощью команды show. Так, например, команда show interf покажет информацию о типе инкапсуляции, статусе первого и второго ypoi модели OSI и т. п.
Router#show interfaces si
Seriall is up. line protocol is up
Hardware is QUICC Serial
MTU 1500 bytes. BW 1544 Kbit. DLY 20000 usee, rely 255/255, load 1/255 Encapsulation FRAME-RELAY, loopback not set. keepalive set (10 sec) LMI enq sent 9570. LMI stat reevd 9563, LMI upd reevd 0, DTE LMI up LMI enq reevd 0. LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
Выполнение рассмотренных команд позволяет настроить на определенш интерфейсе технологию Frame Relay и проверить ее функционирование. Но д начала практической работы этого будет недостаточно. Необходимо настрой на выбранном интерфейсе подинтерфейсы, которые будут представлятьсоо
отдельные виртуальные соединения. Для этого очень важно четко представля логическую топологию объектов. " '
Технология Frame Relay позволяет связывать удаленные объекты разнообр ными способами. Например, может быть создана логическая звезда, когда в Ц< тре выделяется главный офис, а все удаленные офисы подключаются к н^ с помощью постоянных виртуальных соединений. С точки зрения затрат (| административных, так и финансовых) это наиболее выгодная топология, так i она требует наименьшего количества соединений для своей реализации. В^1 лях повышения надежности могут существовать дополнительные связи меж некоторыми удаленными филиалами, но следует учесть, что дополнительр
виртуальные соединения придется оплачивать. В случае топологии звездЦ
одном физическом интерфейсе центрального маршрутизатора будет настрое; несколько виртуальных соединений.*
объектыобъектынесмотря на большие затратнесмотря на большие затратДругим вариантом может быть полносвязная топология, при которой в
объекты
объекты
несмотря на большие затрат
несмотря на большие затрат
связаны друг с другом. Такой подход,
(как прямые, так и косвенные — административные), обеспечивает наикцатч шую связь между объектами без промежуточных переходов между нд^. Q видно, что при увеличении количества связываемых объектов сложность возрастает. Можно определить общее количество соединений в полносвя: топологии при помощи формулы: (п(п - 1))/2, где п — это количество св ваемых объектов.1
у ОПЫТА
Полносвязная топология характеризуется повышенной надежностью. Но это — теория. А что же происходит на практике? Если говорить о принятом у нас подходе (в частности, в Санкт-Петербурге), то подключение к сети Frame Relay осуществляется следующим образом. Провайдер запрашивает адрес объекта, который планируется подключить к сети. При этом часто просят дать информацию о наличии на объекте телефона и о его номере. Это необходимо для того, чтобы уточнить, через какую АТС проще организовать подключение. Затем провайдер формирует прямой провод от этой АТС до объекта. Причем ввиду нехватки магистральных кабелей вполне возможен вариант когда занимается какой-либо телефонный номер. Далее провайдер ставит свое оборудование и предоставляет разъем V.35 (типа female) для подключения маршрутизатора клиента. Собствен- Й6 говоря, на этом процедура физического подключения и заканчивается. Клиент не знает, какая топология получилась в результате. Затем провайдер у себя на магистральных коммутаторах Frame Relay настраивает запрошенные виртуальные соединения межу объектами и предоставляет уомера DLCI для дальнейшей настройки на сторонах маршрутизаторов клиента. При этом несколько виртуальных соединений будут организованы на одном прямом проводе. Если теперь говорить о надежности, то следует помнить, что обрыв этого прямого провода приведет к тому, что все виртуальные соединения, замкнутые на объект, становятся неактивными. Если средства позволяют и надежность является критичным фактором, то можно привлечь еще одного провайдера услуг Frame Relay, который организует дополнительное физическое подключение.
По умолчанию интерфейсы, которые поддерживают технологию Frame Relay, являются групповыми (multipoint). Подобный тип соединения не создает проблем, если работает только одно постоянное виртуальное соединение на одном интерфейсе. Однако могут возникнуть проблемы, когда множество постоянных виртуальных соединений настраивается на одном физическом интерфейсе. В этой ситуации сообщения протоколов маршрутизации, поступающие на1 Маршрутизатор, не могут широковещательно рассылаться на удаленные объекты (рис. 8.2). Это связано с тем, что технология Frame Relay не поддерживает рассылку широковещательных сообщений, так как принадлежит к сетям NBMA (Non-Broadcast Multiple Access — нешироковещательные сети множественного доступа). "
Рассмотрим пример фрагмента сети, в которой три удаленных маршруты тора подключаются к маршрутизатору в центральном офисе по технологии Frat Relay с помощью постоянных виртуальных соединений. Алгоритм расщеплен горизонта (split horizon — глава 7) будет препятствовать рассылке централ ным маршрутизатором сообщений протокола маршрутизации через терфейс, через который они поступили. Удаленные объекты никогда не полу» сообщений протокола маршрутизации друг от друга и от центрального марщр газатора.д
Таким образом, возникают два ограничения на использование множества^ стоянных виртуальных соединений на одном интерфейсе — технология пастпепя ния горизонта и поддержка широковещательных сообщений. Однако Широкове™ ние не создает проблем, если существует только одно постоянное виртуал&й соединение на интерфейсе, так как это простое соединение типа «точка-точка!
Далее, если маршрутизатор поддерживает множество виртуальных соедин пий на одном физическом интерфейсе, то это приводит к тому, что он додж рассылать обновления маршрутов для протоколов маршрутизации на виртуальное соединение. Ожидаемый результат — их чрезмерная загрузка. О ним из решений проблемы расщепления горизонта являются подинтерфейс, которые рассматриваются ниже.„
Казалось бы, наиболее простым решением проблем, связанных с технологи расщепления горизонта, могло быть простое отключение этого механизма, о^ ко и здесь существуют «подводные камни». Во-первых, означенный мехацщ можно отключить только для протокола IP, а для протоколов IPX и Apple'S нельзя. Во-вторых, с повышенной вероятностью можно ожидать появления^ тель (loops) маршрутизации в сети. Для того чтобы все же пользоваться М можностыо передачи широковещательных сообщений об обновлении марш® тов в сети, администратор сети может настроить подинтерфейсы (subinterfagg| которые являются логическими компонентами физического интерфейса мар| рутизатора. В распределенной сети, использующей механизм расщепления X ризонта, сообщения обновления маршрутов, полученные на один подиВД^йЙй могут быть переданы на другие подиптерфейсы. При этом каждое постоя#^ виртуальное соединение можно настроить как соединение типа «точка-точЦ что позволяет подинтерфейсу работать по аналогии с выделенным каналом^ зи с гарантированной скоростью CIR..
Главная цель применения подиптерфейсов в том, чтобы протоколы марпф газации, в основе которых лежит алгоритм длины вектора, могли корректно ] ботать в среде совместно с механизмом расщепления горизонта. Маршрут» тор, получая, например, широковещательный пакет на подинтерфейс^^^Щр способен передать ту же информацию об обновлении маршрутов даде<аый| интерфейсы Serial0.2 и 0.3.J
Администратор сети имеет право настроить подинтерфейсы для поддета следующих типов соединений: «точка-точка» (point-to-point) и «точка-груи (multipoint). В первом варианте один подинтерфейс поддерживает постодаН виртуальное соединение с удаленным маршрутизатором. В соединении ка-группа» подинтерфейс используется для установления множества посту ных виртуальных соединений с удаленными маршрутизаторами.у
Для того чтобы настроить подинтерфейс на физическом интерфейсе, следует выполнить следующие шаги.
1 Выбрать интерфейс, на котором планируется настраивать подинтерфейсы, а затем войти в режим его настройки:
Router#conf term
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface seriall
Удалить все адреса сетевого уровня (например, адреса протокола IP), назначенные этому интерфейсу. Если физический интерфейс имеет адрес, то подинтерфейсы корректно функционировать не будут.
Настроить инкапсуляцию Frame Relay, как было показано ранее (команда Router(config-if)#encapsulation frame-relay).
Выбрать подинтерфейс для последующей настройки. В рассматриваемом примере конфигурируется подинтерфейс Serial 1.2, являющийся интерфейсом «точка-точка»:
Router(config)#interface seriall.2 point-to-point
Router(config-subi)#
Обратите внимание, что строка приглашения маршрутизатора изменилась и указывает на то, что работа ведется в режиме подинтерфейса (приглашение Router(config-su bi) #).
Настроить адрес сетевого уровня па подинтерфейсе. В нашем случае интерфейс типа «точка-точка» и мы планируем использовать протокол IP. В такой ситуации можно сохранить адресное пространство, задействуя команду ip unnumbered симя интерфейсах В качестве параметра можно указать интерфейс EthernetO:
Router(config-subi)#ip unnumbered EthernetO
Далее нужно настроить на подинтерфейсе номер DLCI, кдторый обычно предоставляется провайдером услуги Frame Relay для обоих концов постоянного виртуального соединения, с помощью команды frame-relay interface-dlci с пара-
метром в виде номера DLCI:
Router(config-subi)#fname-relay interface-dlci 22
‘ Если на маршрутизаторе уже настроено постоянное виртуальное соединение с аналогичным номером, то маршрутизатор выдаст сообщение об ошибке: %PVC already assigned to sub-interface Seriall.2. Указание номера DLCI является обязательным условием для технологии Frame Relay с учетом того факта, что протокол LMI не располагает никакой информацией о подинтерфейсах.
После выполнения приведенного набора команд настройку технологии Frame Relay можно считать завершенной. В большинстве случаев их вполне достаточно для того, чтобы начать работу. Выполненные настройки можно проверить с помощью команды show running-config, результат выполнения которой должен походить на следующий пример:
interface Serial!
по ip address
encapsulation frame-relay
frame-relay Imi-type ansi i
interface Serial!.1 point-to-point ip unnumbered EthernetO frame-relay interface-dlci 18
interface Serial!.2 point-to-point ip unnumbered EthernetO
frame-relay interface-dlci 22
В этом примере к сети Frame Relay физически подключен интерфейс Serial на котором настроены два подинтерфейса — Serial!.1 и Seriall.2 со своими нов! рами DLCI, то есть каждый подинтерфейс соответствует отдельному постоянй му виртуальному соединению. Следует отметить, что с точки зрения протокол! маршрутизации подинтерфейсы рассматриваются как обычные интерфейс* при помощи которых можно достичь определенных получателей (в этом мож1 убедиться, выполнив команду show ip route). Администратору сети также досту на команда show interface с номером подинтерфейса в качестве параметра, выдф щая следующий результат:1'1
Router#show interfaces Sl.l-С,
Serial!.1 is up. line protocol is up
Hardware is QUICC Serial,
Interface is unnumbered. Using address of EthernetO (192.168.4.254)^.l
MTU 1500 bytes. BW 1544 Kbit. DLY 20000 usee, rely 255/255. load 1/255 J Encapsulation FRAME-RELAY
В распоряжении администратора сети имеется также команда show frame-i pvc, которая выводит статус каждого настроенного постоянного виртуально соединения и статистику по нему. В рассматриваемом далее примере эта Й манда выполняется вместе с указанием номера DLCI виртуального соедий ния Frame Relay. Информация выводится только для этого соединения, а б указания номера она будет расширена для всех настроенных виртуальных соед нений.
Router#show frame-relay pvc 18^л
PVC Statistics for interface Serial! (Frame Relay DTE)•-•>#
DLCI = 18. DLCI USAGE = LOCAL. PVC STATUS = ACTIVE. INTERFACE = Seriall.l ^
input pkts 10759 out bytes 2628143 in BECN pkts 0 in DE pkts 523 out beast pkts 2626 pvc create time ld02h.input pkts 10759 out bytes 2628143 in BECN pkts 0 in DE pkts 523 out beast pkts 2626 pvc create time ld02h.output pkts 11160 in bytes 2465757 dropped pkts 14in FECN pkts 0
input pkts 10759 out bytes 2628143 in BECN pkts 0 in DE pkts 523 out beast pkts 2626 pvc create time ld02h.
input pkts 10759 out bytes 2628143 in BECN pkts 0 in DE pkts 523 out beast pkts 2626 pvc create time ld02h.
out FECN pkts 0out BECN pkts 0
out DE pkts 0 out beast bytes 530028
last time pvc status changed 03:16:03
Администратор волен настраивать нужное ему количество подинтерфейсов, несмотря на то что их поддержка в сети Frame Relay обеспечиваться не будет. В этом случае статус соединения при выполнении команды show frame-relay pvc явится указателем на это. В следующем примере активным является интерфейс Serial 1.1 (PVC STATUS = ACTIVE) и по нему маршрутизатор может отправлять и получать информацию. Другой подинтерфейс — Serial 1.3 — является неактивным (PVC STATUS = DELETED), он не поддерживается провайдером услуг, однако маршрутизатор продолжает его поддерживать и отслеживать его состояние. Например, если провайдер изменит конфигурацию и включит соответствующее постоянное виртуальное соединение с номером DLCI = 21, то состояние подинтерфейса Serial 1.3 автоматически изменится. Такая модель работы может оказаться полезной в ситуации, когда распределенная сеть состоит из множества объектов и администратор сети решил модернизировать логическую топологию связи. Следует обратить внимание, что если используются протоколы маршрутизации, они автоматически начнут информировать соседние маршрутизаторы о доступных маршрутах, как только виртуальное соединение поменяет свой статус.
Router#show frame-relay pvc
PVC Statistics for interface Seriall (Frame Relay DTE)
DLCI = 18. DLCI USAGE = LOCAL. PVC STATUS = ACTIVE. INTERFACE = Seriall. 1
input pkts 780679 out bytes 418481876 in BECN pkts 0 in DE pkts 12344 out beast pkts 95801 pvc create time 5w5d.input pkts 780679 out bytes 418481876 in BECN pkts 0 in DE pkts 12344 out beast pkts 95801 pvc create time 5w5d.output pkts 669218 in bytes 105683698 dropped pkts 134 in FECN pkts 0 out FECN pkts 0 out BECN pkts 0 out DE pkts 0
input pkts 780679 out bytes 418481876 in BECN pkts 0 in DE pkts 12344 out beast pkts 95801 pvc create time 5w5d.
input pkts 780679 out bytes 418481876 in BECN pkts 0 in DE pkts 12344 out beast pkts 95801 pvc create time 5w5d.
out beast bytes 15359940
last time pvc status changed 00:39:48
DLCI = 21. DLCI USAGE = LOCAL. PVC STATUS = DELETED. INTERFACE = Seri al 1.3
input pkts 0output pkts 8inbytes0
out bytes 1624dropped pkts 0inFECN pkts0
in BECN pkts 0out FECN pkts0out BECNpkts0
in DE pkts 0out DE pkts 0
out beast pkts 8 out beast bytes 1624
pvc create time 5w5d, last time pvc status changed 02:49:52
Управление трафиком в сети Frame Relay
Начиная с версии 11.2 операционной системы Cisco IOS администратору сети Доступен очень мощный механизм управления трафиком (traffic shaping — обратите внимание, что иногда в технической литературе может встретиться перевод сформирование трафика», что в сущности то же самое). Как можно понять из названия, основная цель этого механизма заключается в предоставлении способов контролировать скорость, с которой маршрутизатор обрабатывает поток
334
трафика на своих интерфейсах. Данный механизм может работать как на физ ческих (например, интерфейс SerialO, к которому подключен модем серии xDSl так и на логических интерфейсах (например подинтерфейсы Frame Relay) марх рутизатора, обеспечивая большую гибкость в применении. Последний факт она важен, так как именно он в определенной мере способствует внедрению техн логии передачи голосового и другого чувствительного к задержкам трафика 1 сети Frame Relay. Разработчики добавили удобный механизм работы с технол гией управления трафиком — она либо используется на выбранном по опре,” ленным критериям трафике, либо обслуживает весь проходящий через марщ, тизатор трафик, определяемый с помощью списков доступа (глава 9).,
Вообще говоря, операционная система Cisco IOS предоставляет админист тору два механизма регулирования потока трафика. Первый ориентирован ограничение скорости передачи (rate-limiting) и реализован в технологии С, (Committed Access Rate), а второй — уже упомянутый в предыдущем абзаце 1 ханизм управления трафиком. Важно отметить, что в самой системе управлев трафиком выделяют два компонента: так называемый Generic Traffic Shapi (GTS — базовая система управления трафиком) и Frame Relay Traffic Shapi (FRTS — управление трафиком в сетях Frame Relay).'
Принципы работы указанных двух механизмов отличаются друг от друг Например, в случае реализации технологии CAR на маршрутизаторе после, ний будет либо отбрасывать пакеты, либо изменять поле «Тип сервиса» в заг ловке дейтаграмм. В противоположность этому, технологии управления тр фиком обычно задерживают трафик, привлекая буферную память или систе» очередей для хранения пакетов и «сглаживания» потока трафика в том случг если скорость поступления данных больше, чем ожидается. Например, технол гия GTS использует взвешенную справедливую очередь (WFQ, см. главу 6 да получения детальной информации) для хранения пакетов, a FRTS может оп рировать очередью с назначением приоритетов, настраиваемой очередью ю очередью FIFO в зависимости от выполненных настроек. Далее в книге буд рассматриваться именно механизм управления трафиком. Следует отметить, 4 обе технологии могут работать сообща и в основе их взаимодействия лежит теор! «ведра с меткой» (не совсем точный перевод английского термина token buck< но как будет видно далее, довольно точно отражающий суть).v(
Как уже отмечалось, администратор сети может воспользоваться двумя Mi ханизмами управления трафиком — GTS и FRTS. Их базовая реализация имеб много общего, хотя команды для настройки отличаются (как и используемые ся мы очередей). Кроме того, FRTS поддерживает формирование трафика на ypoi не DLCI, в то время как GTS настраивается на интерфейсе или подинтерфейс Следует отметить, что администратор может настроить GTS для выполнения- же функций, что и FRTS, при выделении одного DLCI на подинтерфейс (чг всего так и делается) и задействуя технологию извещения о перегрузках BE* При настройке технологии GTS администратору также доступны списки досТ для выбора управляемого трафика. GTS работает с большим количеством техно гий канального уровня, включая Frame Relay, ATM, Ethernet и SMDS (Swit" Multimegabit Data Service — служба коммутируемой мультимегабитовой I дачи данных). При использовании Frame Relay технология GTS может дий
чески адаптироваться к доступной пропускной способности путем отслеживания уведомлений BECN или же просто ограничивать трафик заранее определенной скоростью. Технология FRTS, в отличие от GTS, ориентирована на работу с технологией Frame Relay и призвана повысить качество обслуживания именно в таких сетях.
При рассмотрении общей теории работы «ведра с меткой» выделяют два параметра. Параметр R определяет скорость поступления информации (или скорость потока) в течение относительно длительного периода времени; параметр В определяет размер «ведра», или, иными словами, величину, на которую поток данных способен превысить значение R за короткий промежуток времени. Более точное условие следующее: в течение любого периода Т количество посылаемых данных не может превысить ^RT + В). Применительно к трафику протокола IP работу «ведра с меткой» можно рассматривать следующим образом. Само «ведро» представляет собой счетчик, указывающий на разрешенное количество байтов данных, которые могут посылаться в любое время. При этом «ведро» заполняется со скоростью R (то есть счетчик увеличивается R раз в секунду) до достижения края «ведра» (иными словами, до максимального значения счетчика). Дейтаграммы протокола IP поступают и помещаются в очередь для обработки, и они обрабатываются маршрутизатором, если есть свободное место в «ведре». В этом случае дейтаграмма маршрутизируется и «ведро» опорожняется. В том случае, если места в «ведре» нет, дальнейшая судьба дейтаграммы зависит от конкретной реализации рассматриваемой технологии на маршрутизаторе. Следует обратить внимание, что в течение длительного времени при наличии задержек в потоке данных наполнение «ведра» может освобождаться, так что оно в состоянии принять дополнительные В байтов свыше оговоренного количества. Следовательно, В является, скажем так, показателем максимального «взрывного» объема трафика, который система сумеет принять.
На маршрутизаторах Cisco Systems принцип «ведра с меткой» определяется такими величинами, как средняя битовая скорость (average bit rate, также называется CIR), взрывной объем трафика (traffic burst size — Вс) и временной интервал (time interval — Т), связанными между собой выражением:
CIR = Вс / Т
" Это означает, что для любого временного интервала исходящий поток трафика не должен превышать среднюю скорость. По умолчанию объем взрывного трафика устанавливается равным битовой скорости, деленной на 8, что приводит к временному интервалу 1/8 с или 125 мс. Учитывая, что средняя битовая скорость определяется за определенный интервал времени и она не постоянна в Целом, реальная скорость передачи будет меняться значительно, пока общий объем передаваемых за этот интервал данных не больше, чем взрывной объем трафика.
Покажем это на примере. Предположим, что администратор сети настраивает управление трафиком для ограничения исходящего трафика по виртуальному соединению Frame Relay до 64 Кбит/с. Скорость подключения к сети Frame Relay составляет 256 Кбит/с. Так как исходящий трафик может передаваться на скорости подключения (то есть 256 Кбит/с), технология управления трафиком
должна понижать эту скорость каждый раз по истечении временного интерд Предположим, что в рассматриваемом примере взрывной объем трафика у навливается в 8000 бит (64 Кбит/с / 8 с), а временной интервал равен 125 Это означает, что каждые 125 мс интерфейс будет передавать 8000 бит дат через виртуальное соединение. Однако так как интерфейс работает на ско сти 256 Кбит/с, то потребуется 31,25 мс для передачи выделенных 8000 бит- Обобщая сказанное, получаем, что маршрутизатор будет каждые 125 мс перг ' давать по виртуальному соединению 8000 бит за 31,25 мс, а затем он будет оа дать оставшиеся 93,75 мс до передачи следующих 8000 битов. Важно отмети что маршрутизатор будет завершать передачу кадров, не обращая внимания то, что количество оставшихся битов в кадре превысит настроенное значет взрывного объема трафика. Иными словами, если последний равен 8000 ( и маршрутизатор уже успел передать 7500 бит в течение заданного времени интервала, а следующий кадр имеет размер 1500 байт, то маршрутизатор бу передавать этой кадр длиной 1500 байт не дожидаясь следующего времени интервала..
Для настройки технологии GTS администратор может воспользоваться мандой traffic-shape rate bit-rate [burst-size [excess-burst-size]], выполняемой в pea ме конфигурирования интерфейсов. Параметр bit-rate определяет желаемую с рость передачи исходящего трафика и указывается в битах в секунду (то е если нужно ограничить скорость значением 64 Кбит/с, то следует вводить ч:„, ло 64 000). Следующий, необязательный параметр burst-size определяет коли^ ство битов, разрешенных к передаче за заданный интервал времени. В том сд чае, если данный параметр не определен, маршрутизатор получает это значеНИ путем деления параметра bit-rate на 8. И последний необязательный парам81 excess-burst-size определяет максимальное количество битов, которые могут прй вышать Вс в первом интервале в случае появления перегрузки в сети. Если тМ нология управления трафиком настраивается на подинтерфесах Frame Relays т битовая скорость (bit-rate) должна быть равна CIR, количество битов, разрешай ных к передаче (burst-size), приравнивается Вс, а максимальное количество биШ (excess-burst-size) равно Be для настраиваемого виртуального соединения.
Технология управления трафиком в сети Frame Relay (то есть FRTS) назд дит применение в нескольких случаях. Например, если существующая сетев^ топология имеет высокоскоростной доступ в сеть в центральном офиср^и^ВГ сколько низкоскоростных соединений на удаленных объектах. Также техноя! гию управления трафиком можно использовать тогда, когда существуют ЯЯ сколько виртуальных соединений на одном физическом интерфейсе. Еще одй« причиной регулирования трафика может стать периодическое нахождение ей Frame Relay в состоянии перегрузки. При этом существует постоянная необи димость передачи трафика различных приложений с гарантией того, что раз» типы трафика получат определенную долю полосы пропускания.
В первом случае из-за разницы в скоростях не исключено возникновЬг11 «узких мест» на виртуальных соединениях между удаленными объектами и; тральным офисом. Технология управления трафиком дает возможность пр дительно ограничить скорость отправки данных по виртуальным соединен из центрального офиса.'
Если имеют место периодические перегрузки сети, можно дать команду маршрутизатору приостановить трафик до его отправки в сеть, что позволит сгладить проблему потери кадров. В этом случае маршрутизатор отслеживает получение сообщений BECN из сети и па основе принятой информации формирует отправляемый трафик. Собственно говоря, сам процесс формирования трафика заключается в том, что маршрутизатор помещает пакеты, принадлежащие этому трафику, в очередь, снижая тем самым скорость их отправки в сеть. Но заодно возрастает задержка, что бывает критичным для определенного типа трафика.
Довольно часто встречаются ситуации, когда требуется по одному виртуальному соединению передавать трафик различных приложений или протоколов. Тогда администратор может извлечь из своего арсенала настраиваемые очереди (custom queuing). Причем до версии 11.2 операционной системы Cisco IOS настраиваемые очереди поддерживались только на уровне интерфейса, а с выходом новой версии они могут быть определены на уровне виртуального соединения (то есть подинтерфейса).
Для настройки технологии FRTS необходимо выполнить несколько шагов. На первом шаге администратору следует сформировать карту класса (map class) с помощью команды map-class frame-relay, которой в качестве параметра необходимо указать имя класса:'
Router#conf term
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#map-class frame-relay classl
Router(config-map-)#■
О самом классе можно говорить как о некоем наборе параметров, определяющих поведение технологии FRTS. Как видно из примера, маршрутизатор переходит в режим настройки класса, что отображается в приглашении. Далее определяем сам класс. А именно: пиковую и среднюю скорость (в битах в секунду), которые разрешены для виртуального соединения, связанного с этим классом; указываем на то, что маршрутизатор должен динамически менять скорость отправки в зависимости от полученных сообщений BECN; уточняем тип очереди (либо настраиваемая, либо с заданным приоритетом) применительно к виртуальному соединению. Параметры, вводимые при настройке класса, будут рассмотрены отдельно.
После того как определен класс с соответствующими параметрами, следует включить поддержку технологии Frame Relay на интерфейсе с помощью команды encapsulation frame-relay. Далее на очереди активация механизма управления трафиком па интерфейсе с помощью команды frame-relay traffic-shaping. Ее выполнение включает этот механизм на всех постоянных и коммутируемых виртуальных соединениях, настроенных на данном интерфейсе:
Router#conf term
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface serial 1
Router(config-if)#fname-relay traffic-shaping
И на последнем этапе связываем настроенный класс с виртуальным соединением на данном интерфейсе (точнее, подинтерфейсе). Выполнение этой про-
цедуры производится командой frame-relay class с указанием в качестве параметр ра имени класса, которое было назначено на первом шаге. Следует отметиГ^ЭД^ класс может быть связан как с интерфейсом, так и с выбранными подинтерфейя/
"%"%сами отдельно:
"%
"%
Router(config)#int sl.l
■ Ti.■^f■ Ti.■^fRouter(config-subi)#frame-relay class classl
■ Ti.
■^f
■ Ti.
■^f
Существуют несколько подходов к определению класса для управления тра& фиком. Первый (так называемый Rate Enforcement) заключается в задании среди ней и пиковой скорости передачи информации, если данные посылаются быстрей чем получатель может их принять. Для настройки этих скоростей предназна* чена команда frame-relay traffic-rate, ожидающая в параметрах значения средн^ и пиковой скоростей. Скорости указываются в битах в секунду. Средняя скс рость эквивалентна согласованному с провайдером услуг значению CIR, а пике вая скорость равна сумме:•г
CIR + Ве/Т = CIR + (1 + Ве/Вс) = CIR + EIR
Рассмотрим пример настройки этого метода управления трафиком. Предпс ложим, что существует распределенная сеть, построенная на базе Frame Rel^ к которой подключен центральный офис на скорости 1,5 Мбит/с, а два удадеущ офиса используют низкоскоростное подключение (например 9,6 Кбит/с). Адми нистратор сети заказал создание постоянных виртуальных соединений межд удаленными и центральным офисами со значением CIR = 9,6 Кбит/с. В органи зованной сети данные из центрального офиса могут посылаться на максималй
ной скорости, равной 1,5 Мбит/с, несмотря на то что гарантируемая скорость виртуальных соединениях значительно ниже. Если сеть Frame Relay справ™ с передачей данных на столь высоких скоростях, то при их поступлении на удале,
ные маршрутизаторы может возникнуть состояние перегрузки, так как скорое поступления данных выше, чем скорость, на которой эти данные могут быть пр, няты. Естественно, одним из решений предполагается снижение скорости подкл] чения центрального офиса, однако при использовании технологии управлен! трафиком администратор вправе определить скорость отправки маршрутизат)
ром данных индивидуально для каждого виртуального соединения. Шаги настройки маршрутизатора в центральном офисе следующие.
Сначала следует определить класс и перейти в режим его настройки:,(
Router(conflg)#map-cl ass frame-relay <имя-класса>
Далее нужно задать скорости передачи информации:.^
Router(config-map-class)#frame-relay traffic-rate <средняя пиковая скорость*^
Средняя скорость передачи эквивалентна значению CIR, а пиковая, как уЖ отмечалось, вычисляется по формуле: CIR + Ве/Т = CIR * (1 + Ве/Вс). умолчанию пиковая скорость равна скорости подключения к сети Frame Rel^ и это значение задается как аргумент команды bandwidth. Для рассматривай мого примера средняя скорость может быть установлена равной 9600 биИ| а пиковая — 18 000 бит/с.
Следующий шаг — включение поддержки управления трафиком для всех виртуальных соединений на выбранном интерфейсе:
Router(conf1g-1f)#fname-relay traffic-shaping
И последним действием нужно выполнить связывание настроенного класса с интерфейсом или подинтерфейсом:
Router(config-1f)#frame-relay class <имя-класса>'
Следует обратить внимание на то, что все виртуальные соединения, созданные на интерфейсе, будут наследовать все параметры, определенные в классе.
Помимо явного задания скорости передачи администратор может настроить более гибкий механизм, позволяющий маршрутизаторам автоматически реагировать на возникновение перегрузки в сети (метод Dynamic Enforcement).
Маршрутизаторы Cisco допускают два режима: либо они игнорируют сообщения BECN/FECN, либо изменяют поток трафика при их получении. Для включения поддержки этих сообщений необходимо воспользоваться командой frame-relay adaptive-shaping, при настройке классов. Если маршрутизатор получает сообщение BECN в течение определенного промежутка времени, он уменьшает скорость передачи информации на 25%. Причем уменьшение скорости будет продолжаться с каждым полученным сообщением BECN, до тех пор пока скорость трафика не достигнет наименьшего приемлемого значения (так называемое значение MINCIR).
После того как скорость передачи снижена, маршрутизатор будет выжидать 16 временных интервалов, в течение которых, если при этом не получит ни одного сообщения BECN, он станет постепенно увеличивать скорость передачи информации. Приращение скорости будет производиться на величину (Be + Вс) /16 или, что более точно, на величину Byte Limit/16. Значение Byte Limit можно узнать, выполняя команду show traffic-shape в глобальном режиме:
Router#sh traffic-shape
Access
Target
Byte
Sustain
Excess
Interval
Increment Adapt
I/F
List
Rate
Limit
bits/int
bits/int (ms)
(bytes)
Active
Sel.l
56000
875
7000
0
125
875
BECN
Sei. 2
56000
7875
56000
56000
125
875
BECN
Sei. 3
56000
7875
56000
56000
125
875
BECN
Отсюда ясно, что маршрутизатору потребуется гораздо больше времени для достижения значения скорости, равной CIR, чем для ее снижения до величины MINCIR (алгоритм очень напоминает алгоритм технологии медленного старта Для протокола TCP). Одним из способов сокращения этого временного интервала будет установка значенггя Be в семикратное значение Вс. Такая установка гарантирует немедленное достижение скорости передачи, равной CIR, при отсУТствии сообщений BECN в течение 16-кратного временного интервала.
Рассмотрим поэтапно пример использования этого механизма. Предположим, что выполняется подключение к сети Frame Relay с физической скоростью
Кбит/с. При этом заключено соглашение с провайдером, согласно которому по- гдедний обеспечивает гарантированную скорость передачи CIR, равную 16 Кбит/с.
Но при таком подключении маршрутизатор в случае отсутствия перегрузки в се Frame Relay способен передавать данные с максимальной скоростью 64 Кбит/с'
На первом этапе настраиваем интерфейс маршрутизатора (в примере — Senator который физически подключен к сети Frame Relay. Для этого интерфейса указы»; ваем тип инкапсуляции и сообщаем маршрутизатору при помощи команды fram® relay traffic-shaping о необходимости использования технологии управления траи фиком: i
interface SerialO no ip address encapsulation frame-relay frame-relay traffic-shaping frame-relay Imi-type ansi
На втором этапе выполняем настройку класса с именем class2 с указани! скорости, с которой маршрутизатор должен посылать данные при отсутстй) перегрузки в сети. Это мы осуществим командой frame-relay cir 64000, где чий 64 000 обозначает скорость в битах в секунду.
Далее указываем с помощью команды frame-relay be 8000 количество байт (8000), которые должны быть отосланы в течение интервала Т. Рекомендует устанавливать это значение равным 1/8 значения CIR. Напомним, что значе!| Вс определяет количество битов данных, посылаемых за каждый интервал Т„;
Затем с помощью команды frame-relay be 0 задаем максимальное количест данных, посылаемое в первом интервале. В том случае, если маршрутизатор у: посылает данные на скорости подключения, это значение должно быть равно
Последним действием будет выполнение команды frame-relay mincir 16000, J торая устанавливает значение MINCIR, то есть значение, до которого маршрута тор будет снижать скорость передачи в случае обнаружения перегрузки в cei В нашем примере это значение соответствует значению CIR, которое соглассй но с провайдером услуг Frame Relay и равно 16 Кбит/с.■ -о
В технологии управления трафиком Frame Relay временной интервал о. ределяется значением Т, равным отношению (Bc/CIR). Длительность это# временного интервала для эффективной работы технологии управления трафико нс должна быть больше 1/8 с. В нашем примере Т = 8000 / 64 000 = 1/8 с. Таю образом, маршрутизатор будет передавать следующие порции данных кажД 1/8 с: 8000 (Вс+Ве), 8000 (Вс), 8000, 8000, 8000, 8000, 8000, 8000, что и со< ветствует значению скорости в 64 000 бит/с. Если бы скорость доступа 6i равна 128 Кбит/с, а Be = 64 000, то маршрутизатор передавал бы следую! порции: 72 000, 8000, 8000, 8000 ....
Обобщая все вместе, можно конкретизировать этапы настройки механи: управления трафиком.
Создаем именованный класс (имя класса class2):,
Router(config)#map-class frame-relay class2
: 71: 71Router(config-ma)#frame-relay cir 64000
: 71
: 71
Router(config-ma)#frame-relay be 8000
Router(config-ma)#frame-relay be 0
Router(conf1g-ma)#fname-relay mincir 16000 Router(config-ma)#frame-relay adaptive-shaping been
Применяем созданный класс на выбранном подинтерфейсе (в нашем примере SerialO.l):
Router#conf term
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int sO.l
Router(config-su)#frame-relay class class2
Убеждаемся в правильности произведенных настроек с помощью команды show frame-relay pvc:
Router#sh fr pvc
PVC Statistics for interface SerialO (Frame Relay DTE>
DECI = 19. DECI USAGE = LOCAL. PVC STATUS = ACTIVE. INTERFACE = SerialO.l
input pkts 24767 out bytes 4720420 in BECN pkts 0 in DE pkts 374 out beast pkts 7385 Shaping adapts to BECN pvc create time ldl5h.
output pkts 24681in bytes 5100026
dropped pkts 4in FECN pkts 0
out FECN pkts 0■out BECN pkts 0
out DE pkts 0
out beast bytes 989410
last time pvc status changed 08:48:32
Как видно, в процессе выполнения данной команды администратор сети получает значения множества параметров. Таблица 8.1 содержит их описание.
Таблица 8.1. Описание результатов команды show frame-relay pvc
Поле
Описание
DECI
Идентификатор постоянного виртуального соединения
DECI USAGE
Значение SWITCHED, если маршрутизатор работает как коммутатор Frame Relay, или LOCAL, если маршрутизатор выступает в роли DTE
PVC STATUS
Статус PVC: ACTIVE, INACTIVE или DELETED
INTERFACE = SerialO.l
Подинтерфейс, ассоциированный с этим номером DLCI
Input pkts
Количество полученных пакетов по PVC
Output pkts
Количество переданных пакетов по PVC
In bytes
Количество полученных байтов
Out bytes
Количество переданных байтов
dropped pkts
Количество пакетов, которые маршрутизатор отбросил на уровне Frame Relay
in FECN pkts
Количество полученных пакетов с установленным битом FECN
in BECN pkts
Количество полученных пакетов с установленным битом BECN
_out FECN pkts
Количество отправленных пакетов с установленным битом FECN
'продолжение Ц>
Таблица 8.1 (продолжение)]
Поле
ОписаниеT
out BECN pkts
Количество отправленных пакетов с установленным битом BECN
in DE pkts
Количество полученных DE-пакетов (помечены для удаления) '
out DE pkts
Количество отправленных DE-пакетов
outbeast pkts
Количество отправленных широковещательных пакетов
outbeast bytes
Количество байтов в оправленных широковещательных пакетах
pvc create time
Время создания данного PVC
last time pvc status changed
Время изменения статуса PVC
4
Кроме того, администратор сети может просмотреть настроенные параметр] управления трафиком, выполнив команду show traffic-shape:
Router#show traffic-shape
Access Target ByteSustainExcessIntervalIncrementAdapt ;
I/FList Rate Limitbits/intbits/int(ms)(bytes)Active
SeO.l64000 1000 800001251000BECN
Таблица 8.2 содержит описание значений параметров, выдаваемых в резуад тате выполнения команды show traffic-shape.”
Таблица 8.2. Описание результатов выполнения команды show traffic-shapeJ
Поле
Описание
Target Rate Byte Limit Sustain bits/int Excess bits/int Interval (ms)
Скорость, на которой происходит управление трафиком (бит/с) Д Максимальное количество байтов, передаваемых за интервал Настроенное значение количества битов, передаваемых за интервал Настроенное количество дополнительных битов в первом интервале j Интервал для внутреннего использования. Он может быть меньше, а чем Bc/CIR, если маршрутизатор определяет, что поток трафика будет более стабилен с меньшим интервалом
Increment (bytes)
Adapt Active
Количество байтов, которые поддерживаются на каждом интервала^
Содержит BECN, если была включена поддержка BECN adaptation ■ .J
Рассмотрим более детально результат команды show traffic-shape для еле, щих данных:
Target Rate = CIR = 64 000 бит/с
Mincir = CIR/2 = 64 000 / 2 = 32 000 бит/с
Sustain = Вс = 8000 бит/интервал
Excess = Be = 8000 бит/интервал
Interval (Т) = Bc/CIR = 8000 / 64 000 = 125 мс
Increment = Вс/8 = 8000 / 8 = 1000 байт
Byte Limit = Increment + Вс/8 = 1000 + 8000 / 8 = 2000 байт
При настройке этих параметров для управления трафиком в технологии Frame Relay результаты, выдаваемые командой show traffic-shape, можно представить в виде последовательности (рис. 8.3). .
МАХ=Вс+ВеBeМАХ=Вс+ВеBeBc=TcxCIRBc=TcxCIRBout er# show traffic access TargetI/Flist BateSe3/3100000Bout er# show traffic access TargetI/Flist BateSe3/3100000Byte Sustain Excess Interval Limit bits/int bits/int (ms)Byte Sustain Excess Interval Limit bits/int bits/int (ms)Z000 8000800080Z000 8000800080Increment Adapt (bytes) Active 1000-Increment Adapt (bytes) Active 1000-▼CIR▼CIR▼Be▼Be▼Tc=Bc/CIR▼Tc=Bc/CIR
МАХ=Вс+ВеBe
МАХ=Вс+ВеBe
Bc=TcxCIR
Bc=TcxCIR
Bout er# show traffic access Target
I/Flist Bate
Se3/3100000
Bout er# show traffic access Target
I/Flist Bate
Se3/3100000
Byte Sustain Excess Interval Limit bits/int bits/int (ms)
Byte Sustain Excess Interval Limit bits/int bits/int (ms)
Z000 8000800080
Z000 8000800080
Increment Adapt (bytes) Active 1000-
Increment Adapt (bytes) Active 1000-
▼
CIR
▼
CIR
▼
Be
▼
Be
▼
Tc=Bc/CIR
▼
Tc=Bc/CIR
Рис. 8.3. Пример результата выполнения команды show traffic-shape
Наконец, в арсенале администратора имеется третий метод определения класса для управления трафиком — метод с использованием очередей (настраиваемых или с заданным приоритетом). В этом случае маршрутизатор будет руководствоваться настроенной стратегией очередей для формирования стабильного потока трафика. Для настройки этого метода администратору сети следует воспользоваться командой frame-relay custom-queue-list (в случае настраиваемой очереди) с номером очереди в качестве параметра. Соответственно, если было принято решение в пользу очереди с заданным приоритетом, то синтаксис команды меняется: frame-relay priority-group <номер> (детальное описание команд для каждого типа очереди в главе 6).
9
Настройка базовой безопасности
Все рассмотренные ранее настройки различных технологий, все усилия сетево! администратора могут быть сведены на нет при попытке несанкционированнсй проникновения в вашу сеть. В связи с этим функции обеспечения безопасност встроенные в Cisco IOS, являются, несомненно, важнейшим средством, напраз ленным па создание сети с эффективной защитой.
Списки управления доступом Cisco IOS
Списки доступа (access control list — ACL) являются основным инструмент^ операционной системы Cisco IOS по обеспечению безопасности, и их сцн^гакй используется для реализации множества функциональных возможностей марш^ тизатора. Из названия нетрудно понять, что основное предназначение списй( управления доступом заключается в создании фильтра безопасности, направят ного на блокирование трафика, входящего в сеть или покидающего часть сей Однако по мере развития операционной системы IOS компания Cisco System расширила синтаксис команд формирования списков доступа для решение ДЙ гих задач. К ним относятся:'■.
О формирование фильтров маршрутов;
О классификация пакетов приложений для предоставления качества обслуж вания и для реализации стратегии очередей;
О задачи шифрования и маршрутизации по запросу (dial-on-demand routing).
Такой широкий спектр задач и определяет всю важность понимания работ списков контроля доступа и синтаксиса их команд.
Наиболее широко списки доступа используются при фильтрации трафика,) интерфейсах маршрутизатора. Работая как фильтр, список доступа определи* трафик, который запрещен пли, наоборот, разрешен к прохождению через инте] фейс. После составления списка доступа, отвечающего потребностям фильтр ции, администратор сети применяет его на выбранном интерфейсе (или на мВ жестве интерфейсов). В результате маршрутизатор проверяет следующий чер интерфейс трафик и отбрасывает запрещенные к передаче пакеты. Важно отц тить, что фильтрация пакетов осуществляется либо во входящем (inbound) И правлении, либо на исходящем (outbound). Для фильтрации в обоих направд ниях необходимо применение двух списков доступа.J
V
Рисунок 9.1 иллюстрирует простое применение списка доступа, который проверяет поступающий трафик на интерфейсе SO маршрутизатора и отбрасывает трафик, приходящий из сети компании Б.
на интерфейсе SO
Рис. 9.1. Проверка трафика по спискам доступа
Трафик из компании А Проходит через интерфейс и может достичь двух сегментов сети, подключенных к маршрутизатору через порты EthernetO и Ethernet 1. Если же на интерфейс маршрутизатора поступает трафик от других компаний, то дальнейшая его судьба целиком будет зависеть только от деталей составления списка доступа. Например, установленные правила могут разрешать прохождение только трафика от компании А, а остальной трафик (включая компанию Б) запрещать. Другим примером могут быть соглашения, разрешающие любой трафик, за исключением трафика от компании Б. Синтаксис команд, формирующий правила управления доступом, достаточно гибок и позволяет создавать правила поведения маршрутизатора любой сложности. Отметим, что в примере сознательно для наглядности используются названия компаний (хотя и весьма условные), в реальности же администратор работает с такими параметрами, как номера портов протоколов, адреса сетей, подсетей и т. п. При хорошо разработанной схеме документирования создаваемых списков доступа работа с этими параметрами не вызывает больших проблем.
Рассмотренный пример показывает действие входящего списка доступа (inbound access list), анализирующего трафик, поступающий на интерфейс SerialO. Администратор может настроить также и исходящий список доступа (outbound access hst) для трафика, покидающего определенный интерфейс (рис. 9.2).
В рассматриваемом примере исходящий список доступа применяется на интерфейсе Ethernetl (Ethl) маршрутизатора. Правила таковы, что только трафику компании Б запрещено проходить в подсеть 2, в то время как подсеть 1 имеет полный доступ через маршрутизатор, так как нет списков доступа, блокирующих доступ к ней на интерфейсах EthernetO или SerialO (SO).
- Список доступа на интерфейсе Ethl
Рис. 9.2. Настройка списков доступа для подсети 2
Таким образом, каждый список доступа состоит из набора правил (rules), и струкций, определяющих политику доступа. Каждое правило описывает^ЦЩ^1 для совпадения (это может быть адрес протокола IP, тип протокола и т.пХх^ ведение маршрутизатора (пропустить пакет или отбросить). Важно'отметй что правила в списке доступа обрабатываются маршрутизатором последователь: Когда маршрутизатор принимает пакет, соответствующий инструкции, он вый( няет предопределенное действие и останавливает обработку списка доступа $ данного пакета.'
Списки доступа являются очень гибкой технологией — администратор мс^ настраивать их с высокой степенью детализации или, наоборот, оставлять оче широкими, всеохватывающими, в зависимости от потребностей. Напримец,^ но создать список доступа, запрещающий прохождение через маршрутиз^дц^ са Telnet с определенного устройства в сети.v
При создании списка доступа ему присваивается номер или имя. Имя назь чается в случае использования именованных списков. Присвоенный pg^lgyB зволяет ссылаться на список доступа как на единый объект в операционной си теме IOS, что повышает удобство его применения на интерфейсах. Наприм' можно однажды создать список доступа, а затем применять его на необходим количестве интерфейсов. Следует отметить, что существуют ограничения^ДаЩ рации списков доступа. Диапазон допустимых номеров зависит от типа фи труемого протокола. Например, для протокола IP существуют два типа спис доступа, каждый со своим числовым диапазоном:.,
О стандартный список доступа IP (standard IP access list) — можно назнач
номера от 1 до 99;\
О расширенный список доступа IP (extended IP access list) — разрешенные,, мера от 100 до 199.й
Другие диапазоны номеров списков доступа зарезервированы для фильтрации трафика таких протоколов, как IPX, AppleTalk, DECNet и т. д. Таблица 9.1 представляет диапазоны нумерации, предназначенные для фильтрации трафиков различных протоколов.
Таблица 9.1. Диапазоны номеров списков доступа для протоколов
Протокол
Диапазон номеров
IP
1-99 и 1300-1999
Extended IP
100-199 и 2000-2699
Ethernet type code
200-299
Ethernet address
700-799
Transparent bridging (тип протокола)
200-299
Transparent bridging (код производителя)
700-799
Extended transparent bridging
1100-1199
DECNet and extended DECNet
300-399
XNS
400-499
Extended XNS
500-599
AppleTalk
600-699
Source-route bridging (тип протокола)
200-299
Source-route bridging (код производителя)
700-799
IPX
800-899
Extended IPX
900-999
IPX SAP
1000-1099
Standard VINES
1-100
Extended VINES
101-200
Simple VINES
201-300
Ввиду того что в книге рассматривается только один сетевой протокол из перечисленных — IP, акцент будет сделан именно на списках доступа для протокола IP. Стандартный список доступа фильтрует трафик, основываясь только на адресах отправителя. При этом каждое правило в списке доступа содержит некий битовый шаблон (bit pattern), аналогичный записи IP-адреса в точечно-десятичной нотации. Этот шаблон маршрутизатор сравнивает с адресами отправителей поступающих пакетов. Если адрес отправителя совпадает с настроенным битовым шаблоном, маршрутизатор выполняет предопределенное действие — отбрасывает либо пропускает пакет. Администратор сети может формировать правила, которые работают не только с одним устройством в сети, а охватывают подсети или сети целиком.
Для создания стандартного списка доступа сначала следует выбрать номер в интервале от 1 до 99, который будет идентифицировать список доступа на маршрутизаторе. При этом абсолютно неважно, какое именно число будет выбрано,
хотя для простоты последующего управления большим количеством списка доступа рекомендуется нумерацию осуществлять с единицы.J
Создание списка доступа начинается с объявления правил (одного или скольких), которые добавляются последовательно. При этом администратор дй| жен будет использовать команду access-list, выполняемую в глобальном режи^ работы (табл. 9.2).
Таблица 9.2. Синтаксис команды access-list
Цель
Команда;
Определить стандартный список доступа, используя адрес отправителя и маску
Определить стандартный список доступа, используя сокращение для отправителя и маску, равную 0.0.0.0 255.255.255.255
access-list <номер списка доступа> (deny | permit
<отправитель> [маска] [log]11
access-list <номер списка доступа> (deny | permfl
any [log][
Для того списка доступа, который разрешает прохождение трафика (ключ вое слово permit) с устройства в сети с адресом 192.168.3.2, можно выполни следующие команды:
Clsco805#conf1gure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cisco805(config)#access-list 1 permit 192.168.3.2 0.0.0.01
В рассматриваемом примере число 0.0.0.0 является маской (mask — B-aj лоязычной литературе может также встретиться название wildcard) для шабт на 192.168.3.2. Маска указывает маршрутизатору на те биты в шаблоне, котор:
следует сравнивать с адресом отправителя, и те, которые можно проигнорировав
соотвесоотвеТо есть маска 0.0.0.0То есть маска 0.0.0.0Как и маска в схеме адресации протокола IP, маска в списке доступа состоит;
соотве
соотве
То есть маска 0.0.0.0
То есть маска 0.0.0.0
32 бит, записанных в точечно-десятичной нотации.
ствует следующему двоичному представлению: (00000000)2(00000000)2(0000000( (00000000)2. Нулевые биты в маске списка доступа указывают маршрутизато] на необходимость сравнения этих битов — иными словами, нужно сопоставля биты в адресе отправителя пакета с аналогичными битами в шаблоне. Соотве ственно, единичные биты указывают на то, что сравнение проводить не нужн Таким образом, маска 0.0.0.0 в сочетании с шаблоном 192.168.3.2 указывав маршрутизатору на то, что он должен проверять все 32 бит на соответствие, и в^ зультате только адрес 192.168.3.2 будет считаться удовлетворяющим правив
списка доступа.
Используя единичные биты в маске, администратор получает в свое распоряЖ ние очень гибкий инструмент, оперирующий не отдельными адресами, а их ди; зонами. В следующем примере список разрешает доступ с адреса 192.168.L по адрес 192.168.1.159 включительно.
Router(config)#access-list 2 permit 192.168.1.128 0.0.0.31
Точечно-десятичная нотация не позволяет понять, как именно будет работа данное правило в списке доступа. Для более наглядного представления следу преобразовать последний байт шаблона и соответствующей маски в двоичН' представление и проверить биты, установленные в единицу. В нашем приме
де требуется приведения первых трех байтов в двоичную запись, так как все биты в маске нулевые. Если представить последний байт маски в двоичном виде, то результат будет указывать маршрутизатору на то, что необходимо сравнивать 3 младших бита и игнорировать 5 старших.
Шаблон: 192.168.1.128 соответствует 192.168.1.(10000000)2.
Маска: 0.0.0.31 соответствует 0.0.0.(00011111)2.
Накладывая друг на друга шаблон и маску, получаем следующее правило для сравнения: 192.168.1.(100ХХХХХХ)2, где символ X указывает на биты, которые не учитываются при сравнении. То есть 5 младших битов в адресе отправителя могут быть любой комбинацией нулей и единиц в пределах от 192.168.1.(10000000)2 до 192.168.1.(10011111)2, что как раз и соответствует диапазону адресов в десятичном представлении с 192.168.1.128 по 192.168.1.159.
Рассмотрим другой пример. Предположим, администратор сети настроил список доступа на маршрутизаторе, разрешающий прохождение пакетов с шаблоном 172.30.16.0 и маской 0.0.15.255.
Router(conf1g)#access-11 st 3 permit 172.30.16.0 0.0.15.255
Предположим также, что устройство с адресом 172.30.20.32 пытается передавать пакеты через интерфейс маршрутизатора, на котором был применен этот список доступа. В этом случае маршрутизатор выполняет следующее сравнение (табл. 9.3).
Таблица 9.3. Схема № 1 сравнения маски и шаблона
Адрес устройства
172.30.20.32
(1О1О11ОО).(ООО1111О).(ООО1
0100).(00100000)
Шаблон
172.30.16.0
(1О1О11ОО).(ООО1111О).(ООО1
ОООО).(ОООООООО)
Маска
0.0.15.255
(ОООООООО).(ОООООООО).(ОООО
llll).(llllllll)
Биты сравниваются
Биты игнорируются
В результате сравнения маршрутизатор разрешит передачу трафика, отправителем которого является устройство с адресом 172.30.20.32, так как нулевые биты маски у адреса устройства и у шаблона совпадают.
Теперь представим, что через интерфейс маршрутизатора с установленным списком доступа начинает передавать информацию устройство с адресом 172.30.32.8. Результаты сравнения, выполняемого маршрутизатором, показаны в табл. 9.4.
Таблица 9.4. Схема № 2 сравнения маски и шаблона
Адрес устройства
172.30.32.8
(1О1О11ОО).(ООО1111О).(ОО1О
ОЮО).(ООООЮОО)
Шаблон
172.30.16.0
(1О1О11ОО).(ООО1111О).(ООО1
ОООО).(ОООООООО)
Маска
0.0.15.255
(00000000).(00000000).(0000
llll).(llllllll)
—
Биты сравниваются
Биты игнорируются
По результатам сравнения маршрутизатор будет отбрасывать пакеты от устройства, так как последние два сравниваемых бита в адресе устройства и в шаблоне Не одинаковы. ■
ЮВЕТ _
Для простоты восприятия маску списка доступа можно рассматривать как реверсивную маску i сети для протокола IP. В то время как маска списка доступа начинается с серии нулей и зака вается серией единиц (например, 0.0.255.255), маска подсети начинается с единичных битов а" канчивается нулевыми (255.255.0.0).'-’^
Как уже не раз отмечалось, список управления доступом формируется на осн ве правил, и если хотя бы одно из них охватывает все потребности в фильтрат трафика (как в рассматриваемых примерах), то на этом формирование спит доступа можно считать завершенным. Однако довольно часто одним правила процесс формирования списка доступа не ограничивается — могут потребовать еще несколько дополнительных соглашений, пропускающих или отбрасываклцй пакеты (например, для нескольких классов адресов). Для добавления правЙ к списку доступа администратор просто продолжает вводить команды, соотйф ствующие правилам, с тем же самым номером списка доступа. Например, есЯ продолжить рассмотрение примера списка доступа с номером 1 (access list 1), т можно добавить к нему новые правила.
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#access-11st 1 permit 192.168.3.2 0.0.0.0
Router(config)#access-list 1 permit 192.168.3.101 0.0.0.0
После того как формирование списка доступа с номером 1 полностью завер/ шено, можно выполнить команду show running-config для просмотра правил.-^ тересной особенностью является то, что администратор сети вправе создав^ сколько угодно правил, не тревожась о времени простоя, так как маршрутизап не будет фильтровать пакеты до тех пор, пока списки доступа не будут прим йены к выбранным интерфейсам.'^
Cisco805#show running-config
Building configuration...
access-list 1 permit 192.168.3.101
access-list 1 permit 192.168.3.2
Дополнительно существует более удобный способ проверки созданных списК! доступа. Он реализуется командой show access-lists с указанием номера сфорМ рованного списка. Следует отметить, что операционная система опускает мао списка доступа при выводе на экран, если она была установлена в О.О.О.О. Kpoi того, администратор, создавая список доступа, работающий только с одним устр® ством, может также не вводить маску, состоящую из одних нулей.
Cisco805#show access-lists 1
Standard IP access list 1
permit 192.168.3.101 permit 192.168.3.2
Если необходимо создать правило, работающее только с конкретным сом, то администратор вправе не вводить маску вообще, а включить в koi
ключевое слово host, которое указывает маршрутизатору, что следующий за этим словом параметр будет соответствовать адресу отправителя, с которым будет работать данное правило.
Cisco805(config)#access-list 1 permit host ?
Hostname or A.B.C.D Host address
Cisco805(config)#access-11st 1 permit host 1-mk
Translating "1-mk"...domain server (192.168.3.252) [OK]
Как видно из примера, можно вместо конкретного адреса ввести имя хоста. Маршрутизатор, на котором настроена служба разрешения имен, автоматически преобразует имя в соответствующий адрес.
Помимо правил с указанием определенных адресов или их диапазонов, во власти администратора так называемое «разрешающее все» правило. Для этого в качестве шаблона следует указать 0.0.0.0, а маску установить равной 255.255.255.255. Данное правило будет предписывать маршрутизатору игнорировать все 32 бита в адресах отправителей поступающих пакетов. Для упрощения ввода подобной команды операционная система IOS позволяет использовать ключевое слово any, которое не требует после себя никаких параметров в виде адресов.
Cisco805(conf1g)#access-11 st 4 permit any
На практике чаще всего сначала настраиваются правила, ограничивающие доступ (deny), которые заканчиваются разрешающим правилом (permit). Иными словами, обычно формируются списки доступа, которые запрещают доступ определенным устройствам, но разрешают всем другим.
Как уже говорилось, до тех пор пока администратор не применил созданный список доступа на нужном интерфейсе, маршрутизатор не будет фильтровать трафик. Для применения созданного списка доступа на интерфейсе можно воспользоваться командой ip access-group, выполняемой в режиме конфигурирования интерфейса и имеющей формат:
ip access-group (сномер списка доступа | имя>} (in | out}
В следующем примере на интерфейсе EthernetO маршрутизатора команда ip access-group применяется к списку доступа с номером 4, для которого разрешено прохождение любого трафика (правило permit any).
Cisco805#conf term
Enter configuration commands, one per line. End with CNTL/Z.
C1sco805(config)#interface ethernet 0
Cisco805(conf1g-if)#ip access-group 4 in
Как видим, сначала выполняется переход в режим настройки интерфейса, причем интерфейс выбирается исходя из того, что именно на нем будет затем проверяться список доступа. В качестве параметра команды ip access-group указывается одно из ключевых слов — in или out, указывающих на направление фильтрации трафика. В нашем случае маршрутизатор будет фильтровать согласно списку доступа входящий на интерфейс EthernetO трафик. Соответственно, С помощью ключа out можно вынудить маршрутизатор фильтровать покидающий интерфейс трафик.
После создания и применения списка доступа разумно проверить корреед* ность результата. Для этого воспользуемся командой show ip interface с указаний ем имени и номера интерфейса, к которому был применен список доступа. г .
Cisco805#sh ip interface ethO'
EthernetO is up. line protocol is up■
Internet address is 192.168.101.254/24
Outgoing InboundOutgoing Inboundaccess list is not set access list is 4
Outgoing Inbound
Outgoing Inbound
Есть несколько важных моментов, которые следует помнить при разработкам списков доступа. Прежде всего это то, что правила в списке доступа обрабатьь ваются последовательно, то есть маршрутизатор сравнивает пакеты соглаеЖ правилам от начала списка доступа, и если пакет не удовлетворяет усчопитА,' маршрутизатор продолжает сравнение с другими правилами, до тех пор покайе' найдет подходящее. При этом первое единственное правило, которое оказалбСь.; действительно, и определит дальнейшую судьбу пакета — маршрутизатор лй® пропустит его, либо отбросит. 11 »
После того как определенные в правиле действия с пакетом выполнены, марш-: рутизатор прекращает обработку списка доступа для данного пакета и не прове*; ряет оставшуюся часть. Однако, когда поступает следующий пакет, весь процесс проверки па соответствие правилам начинается заново, с самого первого прави.[1<р
Очевидно, что при довольно интенсивном трафике маршрутизатор буд^ тратить значительную часть своих ресурсов на контроль соответствия пакету спискам доступа. Отсюда следует рекомендация формировать правилен спиейН доступа таким образом, чтобы большая часть трафика требовала сравнения тодБу ко с первыми несколькими правилами в списке доступа. В этом случае большинство пакетов будет быстро обработано, а меньшее их количество будет сравйй- ваться со всеми объявленными правилами. Такой подход позволит значительно^ ускорить обработку списков доступа па маршрутизаторе. ч
Следует отметить, что при составлении списка доступа каждое правило встану ляется в конец списка в порядке своего добавления. Администратор не моЖ&" вставить правило произвольно между двумя другими или в начало суЩбО^. вующего списка. Для этого потребуется удалить весь список доступа и создать, его заново.
СОВЕТ-f^
При написании списка доступа не вводите его сразу в маршрутизатор. Воспользуйтесь любым текстовым редактором и формируйте список сначала там. После того как все задачи, задуманные ДЛЯ данного списка доступа, определены, можно простым копированием текстовых строк через буфер обмена операционной системы перенести список в маршрутизатор. Это также упростит задачу бавления новых правил не в конец списка. Полученный текстовый файл имеет смысл сохрани для дальнейшего использования, причем лучше его хранить в безопасном месте, так как фактЩ ски его можно рассматривать как настройку защитного экрана. Для удаления списка доступу конфигурации маршрутизатора достаточно в глобальном режиме выполнить команду no access^ с указанием номера списка.
Операционная система Cisco 1OS не позволяет удалять правила, уже существующие в списке. Как и в ситуации со вставкой правил, для удаления конкретных правил из списка потребуется аннулировать список целиком и создать заново с нужными исправлениями. Также следует обратить внимание на то, что при создании правила, отбрасывающего определенные пакеты, нужно убедиться, что среди ранее созданных (находятся ближе к началу списка) нет такого, которое по ошибке разрешает прохождение пакетов, так как будет использоваться первое правило, совпадающее с пакетом.
Очень важной особенностью является то, что все пакеты будут совпадать по крайней с мере одним правилом в списке доступа, поскольку это последнее правило в списке существует по умолчанию и оно невидимо. Данное правило заставляет отбрасывать все пакеты; оно не отображается при выполнении команд show access-list и show running-config, но оно есть данность и отключить его невозможно. Последнее правило будет отбрасывать все пакеты-претенденты, которое прошли через цепочку правил и не нашли своего совпадения. Применительно к ранее показанному примеру (access list 1) фактический список доступа будет выглядеть следующим образом:
access-11 st 1 permit 192.168.3.2 0.0.0.0
access-list 1 permit 192.168.3.101 0.0.0.01
(access-list 1 deny any)
Здесь невидимое правило access-list 1 deny any (что подразумевают скобки) автоматически вставляется в конец каждого списка доступа, включая расширенные списки доступа, о которых будет сказано немного ниже. Это делается с целью поддержания дополнительных мер предосторожности, чтобы исключить бреши в системе безопасности, если при создании списка доступа были допущены ошибки.
ИЗ ОПЫТА При формировании списка доступа не забывайте про служебный трафик, которым обмениваются маршрутизаторы (например, протокол RIP). Если подобный трафик не учесть при создании списка, то он будет блокирован невидимым правилом в конце списка.
Важно помнить, что списки доступа являются однонаправленными. Когда администратор применяет список доступа к интерфейсу, он должен указать направ- " ление передачи пакетов. В этом случае маршрутизатор будет сравнивать соответственно входящие или покидающие интерфейс пакеты. Когда же направление не указано, подразумевается исходящий трафик (out). Если необходимо фильтровать ' как входящий, так и исходящий потоки, следует создать и применить два отдельных списка доступа, или же использовать один список доступа, но для двух направлений.
СОВЕТ Не делайте список слишком большим, так как при большом количестве правил производительность маршрутизатора может быть резко снижена — он будет вынужден сравнивать всякий поступающий пакет с каждым правилом в списке доступа. Естественно, что длина списка доступа зависит от производительности конкретной модели маршрутизатора и пропускной способности, которую нужно поддерживать на канале связи. Лучше находить разумный компромисс между безопасностью и скоростью работы.
Расширенные списки доступа позволяют администратору формировать точные правила для фильтрации трафика, чем это позволяют делать стандартный списки. В то время как стандартные списки при фильтрации опираются толькб на адрес отправителя, расширенные списки доступа могут сравнивать: адрёса*!у. правителя и получателя, транспортные протоколы (ICMP, TCP, UDP, EIGRP OSFP и т. п.), протоколы верхнего уровня (FTP, HTTP, SMTP и т. п.) й*др, В следующем примере приведены протоколы, работающие поверх TCP, для которых при формировании расширенного списка доступа допускается использовать сокращения наименований.
Ciscol601(config)#access-list 101 permit tcp any any eq ?,
<0-65535>
Port number
bgp
Border Gateway Protocol (179)
chargen
Character generator (19)
cmd
Remote commands (rcmd. 514)
daytime
Daytime (13)
discard
Discard (9)
domain
Domain Name Service (53)
echo
Echo (7)
exec
Exec (rsh. 512)
finger
Finger (79)
ftp
File Transfer Protocol (21)
ftp-data
FTP data connections (used infrequently. 20)
gopher
Gopher (70)
hostname
NIC hostname server (101)
ident
Ident Protocol (113)
1 rc
Internet Relay Chat (194)
klogin
Kerberos login (543)
kshel1
Kerberos shell (544)
login
Login (rlogin. 513)
Ipd
Printer service (515)
nntp
Network News Transport Protocol (119)
pim-auto-rp
PIM Auto-RP (496)
pop2
Post Office Protocol v2 (109)
pop3
Post Office Protocol v3 (110)
smtp
Simple Mail Transport Protocol (25)
sunrpc
Sun Remote Procedure Call (111)
syslog
Syslog (514)
tacacs
TAC Access Control System (49)
talk
Talk (517)
telnet
Telnet (23)
time
Time (37),
uucp
Unix-to-Unix Copy Program (540)
whois
Nicname (43)
WWW
World Wide Web (HTTP, 80)
Формат команды для работы с расширенным списком доступа привел?
в табл. 9.5.
Таблица 9.5. Синтаксис команды создания расширенного списка доступа
Цель
Команда
Определить расширенный список доступа с указанием его номера и критериев фильтрации. Ключевое слово log позволяет вести журнал работы списка
access-list сномер списка доступа* {deny |.
permit} симя протокола* сотправитель* смаска* сполучатель* смаска* [precedence precedence] [tos tos] [established] [log]
И хотя синтаксис команды может показаться слишком сложным, ее суть остается такой же, как и для стандартного списка доступа. В данном случае предлагается много опций для достижения большей гибкости при создании правил. Рассмотрим следующий пример.
access-list 100 permit ip 192.168.3.0 0.0.0.255 192.168.25.0 0.0.0.31
Число 100 является номером расширенного списка доступа. Этот номер должен находиться в пределах от 100 до 199 включительно. Любой номер из диапазона 100-199 будет подходить к расширенному списку доступа, если он, конечно, не конфликтует с другими номерами. В примере команды запись 192.168.3.0 0.0.0.255 имеет такое же значение, как для стандартного списка доступа, и охватывает адреса отправителей. Напомним, что подобная запись говорит маршрутизатору о необходимости сравнивать первые три байта в шаблоне 192.168.3.0 с адресами отправителей поступающих пакетов. Последний байт не принимается в расчет, так как используется маска 0.0.0.255. Запись 192.168.25.0 0.0.0.31 является шаблоном для сравнения адресов получателей, границы которых определяются той же маской. Данное правило работает следующим образом: маршрутизатор будет пропускать дейтаграммы, адреса отправителей и получателей которых совпадут с определенными в правиле.
Для упрощения работы, как и в случае стандартного списка доступа, администратор может использовать ключевые слова any и host.
access-list 101 permit ip any host 192.168.25.10
Ввод подобной команды маршрутизатор воспримет как указание пропускать пакеты любого отправителя, адресованные устройству с адресом 192.168.25.10. Здесь не обязательно указывать маску, как уже оговаривалось при рассмотрении стандартных списков доступа (табл. 9.6).
Таблица 9.6. Синтаксис команды access-list с указанием сокращений протоколов
ЦельКоманда
Определить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 255.255.255.255, и сокращение Для получателя с аналогичной маскойОпределить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 (этот хост), и сокращение Для получателя с аналогичной маскойОпределить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 255.255.255.255, и сокращение Для получателя с аналогичной маскойОпределить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 (этот хост), и сокращение Для получателя с аналогичной маскойaccess-list сномер списка доступа* {deny | permit}* симя протокола* anyaccess-list сномер списка доступа* {deny | permit}* симя протокола* anyaccess-list сномер списка доступа* {deny | permit} симя протокола* host сотправитель* host сполучатель*access-list сномер списка доступа* {deny | permit} симя протокола* host сотправитель* host сполучатель*
Определить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 255.255.255.255, и сокращение Для получателя с аналогичной маской
Определить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 (этот хост), и сокращение Для получателя с аналогичной маской
Определить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 255.255.255.255, и сокращение Для получателя с аналогичной маской
Определить расширенный список доступа используя сокращение для отправителя с маской, Равной 0.0.0.0 (этот хост), и сокращение Для получателя с аналогичной маской
access-list сномер списка доступа* {deny | permit}* симя протокола* any
access-list сномер списка доступа* {deny | permit}* симя протокола* any
access-list сномер списка доступа* {deny | permit} симя протокола* host сотправитель* host сполучатель*
access-list сномер списка доступа* {deny | permit} симя протокола* host сотправитель* host сполучатель*
Если администратор планирует осуществлять фильтрацию трафику, Qm ясь на информацию о протоколе, он также формирует список допустимых правителей и получателей трафика и указывает тип протокола для сравни Например, можно предъявить требование маршрутизатору блокировать траф] принадлежащий сеансу Telnet, следующими командами:' t ■
access-list 102 deny tep 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq Telnet
access-list 102 permit ip any any’
Параметр tep заставляет маршрутизатор пропускать только пакеты протоку ла TCP. Первый шаблон и маска (192.168.1.0 0.0.0.255) являются критериям для сравнения адресов отправителей пакетов, а критерием для сравнения адр< сов получателей является 192.168.2.0 0.0.0.255. Кроме того, указывается допо; нителыюе условие для сравнения — eq Telnet, а именно дается указание на т что порт на стороне получателя должен быть равен 23 (протокол Telnet). Kj чевое слово eq является оператором сравнения, и в данном случае происхо; проверка равенства. Администратор сети также может задействовать следуюв операторы сравнения: neq (не равно), gt (больше чем), It (меньше чем) и га (для указания диапазона номеров портов).
C1scol60l(config)#access-list 101 permit tep any any ? Eq Match only packets on a given port number Established Match established connections Gt Match only packets with a greater port number.
Log Log matches against this entry log-input Log matches against this entry, including input interface ItMatch only packets with a lower port number
neqMatch only packets not on a given port number
precedence Match packets with given precedence value range Match only packets in the range of port numbers tos Match packets with given TOS value ''
Если возвратиться к предыдущему примеру, то можно видеть, что в кои списка присутствует правило access-list 102 permit ip any any, которое разреша прохождение любого трафика, противоречащего первому правилу списка дрф па (ограничение протокола Telnet). Разрешающее условие необходимо, так к иначе невидимое правило автоматически блокирует любой трафик..
В итоге работу списка доступа 102 можно свести к следующим действиям. О блокировать трафик, адресованный из сети 192.168.1.0 в сеть 192.168.,.
(сравниваем первые 24 бита, согласно маске 0.0.0.255), где номер порта п] токола TCP равен 23 (Telnet);-
мар Темар ТеО весь остальной трафик протокола IP пропускаем (рис. 9.3)., ,
мар Те
мар Те
Применение списков доступа с номером 102 на интерфейсе Ethernetl рутизатора приведет к тому, что маршрутизатор будет блокировать сеансы
инициированные устройством в сети 192.168.1.0 и адресованные любому пол телю в сети 192.168.2.0. Однако из последней сети сеансы Telnet блокиро^а
не будут. Чтобы запретить их, нужно применить список доступа также.и Bi
тивоположиом направлении.
— Список доступа с номером 102 ■ применен на интерфейсе Ethl для направления out:
interface Ethernetip access-group 102 out
Рис. 9.3. Работа списка доступа
СОВЕТ;
Администратор сети может использовать другой способ ограничения доступа к маршрутизатору по протоколу Telnet. Для этого нужно создать список доступа и применить его к виртуальным портам VTY, разрешая только доступ с определенных адресов. В данном примере доступ по протоколу Telnet ограничивается только с хостов, адреса которых принадлежат сети 192.168.3.0/24. Команда access-class 10 in применяет список доступа с номером 10 сразу на всех пяти виртуальных портах VTY (0-4):
access-list 10 permit 192.168.3.0 0.0.0.255
line vty 0 4
access-class 10 in
Иногда возникает потребность в ведении журнала, фиксирующего факты отбрасывания маршрутизатором трафика, как определено расширенным списком доступа. Это особенно полезно в случае использования списков доступа для формирования политики безопасности и для намеренного блокирования сетевого взаимодействия, которое может представлять угрозу. Операционная система Cisco IOS позволяет вести журнал, указав ключевое слово log в правилах расширенндго списка (для стандартных списков такая возможность отсутствует).
access-list 103 deny ip 192.168.6.254 0.0.0.0 192.168.3.254 log
access-list 103 permit ip any any
После активации журнала записываемые события доступны для просмотра с помощью команды show logging, или, если предварительно были сделаны соответствующие настройки, в журнале syslog-сервера.
СОВЕТ——_.-
В том случае, если в регистрируемых сообщениях отсутствуют временные отметки, можно настроить маршрутизатор на их использование с помощью команды service timestamps log datetime выполняемой в глобальном режиме.'■
Маршрутизатор поддерживает счетчики пакетов для каждого задействованного правила. Такая возможность особенно полезна при решении проблем со списками доступа и для проверки их работы. Статистику по сравнению пакетов-' со списками доступа позволяет получить команда show access-list.
СОВЕТ'
Если необходимо очистить счетчики, связанные со списками доступа, выполните команду clear counters,! находясь в привилегированном режиме. Важно отметить, что статистика прохождения информации через интерфейсы локальных и глобальных сетей также будет сброшена, что не всегда желательно.''
Особенно в случае счетчиков на интерфейсах, например для подключенных сторонних компаний; j
Защита от атак address spoofing
Остановимся более подробно на том, как использовать списки доступа для предот
вращения атак типа address spoofing (подмена адресов), смысл которых заключает-.’
ся в том, что атакующий «втирается в доверие», используя адрес из списка допйь щенных к прохождению через маршрутизатор. Хотя это только один тип атаки и^, множества аналогичных, считается, что он является одним из самых популярны^;
Наиболее часто списки доступа, блокирующие подобную атаку, настраиваю'
на маршрутизаторах, подключенных к Интернету. Опираясь на примеры, приве»; денные ниже, администратор может создавать и более изощренные списки ДйН1 ступа для защиты от сложных нападений, так как очевидно, что список доступа» эффективный против атаки spoofing, не сумеет обезопасить сеть от других атаК»; и, как правило, его следует использовать в сочетании с выделенным защитны^' экраном. Это может быть, например, Checkpoint Firewall-1 или маршрутизатр] со специализированным программным обеспечением Cisco IOS Firewall FeatUX Set. Выделенные защитные экраны усиливают защиту от атаки address spoofing реализуемую обычным списком доступа.,
Рассмотрим пример, когда атакующий пытается выдать себя за хост, находя! щийся во внутренней сети с адресом 192.168.1.0/24. формируя, таким образу атаку address spoofing (рис. 9.4).
Для предотвращения подобной атаки был создан список доступа с ном^ ром 101, который затем был применен на интерфейсе Serial0 для направления (фильтруется входящий трафик).
Interface Seri al 0^
ip address 193.125.45.34 ip access-group 101 in
access-list 101access-list 101access-list 101access-list 101access-list 101access-list 101access-list 101access-list 101deny ip 192.168.1 deny ip 192.168.2 deny ip 127.0.0.0 permit ip any anydeny ip 192.168.1 deny ip 192.168.2 deny ip 127.0.0.0 permit ip any any0 0.0.0.255 any0 0.0.0.255 any0.255.255.255 any0 0.0.0.255 any0 0.0.0.255 any0.255.255.255 any
access-list 101
access-list 101
access-list 101
access-list 101
access-list 101
access-list 101
access-list 101
access-list 101
deny ip 192.168.1 deny ip 192.168.2 deny ip 127.0.0.0 permit ip any any
deny ip 192.168.1 deny ip 192.168.2 deny ip 127.0.0.0 permit ip any any
0 0.0.0.255 any
0 0.0.0.255 any
0.255.255.255 any
0 0.0.0.255 any
0 0.0.0.255 any
0.255.255.255 any
EthOEthOEthlEthl192.168.2.0192.168.2.0Атакующий компьютерАтакующий компьютерСписок доступа с номером 101 применен на интерфейсе S0: для направления out:Список доступа с номером 101 применен на интерфейсе S0: для направления out:
EthO
EthO
Ethl
Ethl
192.168.2.0
192.168.2.0
Атакующий компьютер
Атакующий компьютер
Список доступа с номером 101 применен на интерфейсе S0: для направления out:
Список доступа с номером 101 применен на интерфейсе S0: для направления out:
interface SerialOip access-group 101 ininterface SerialOip access-group 101 in— Сообщает, что его IP-адрес = 192.168.1.100
interface SerialOip access-group 101 in
interface SerialOip access-group 101 in
Рис. 9.4. Защита от атаки address spoofing
Этот список доступа «просеивает» входящий трафик из Интернета на интерфейсе SerialO. Первые два правила в списке доступа заставляют маршрутизатор блокировать весь трафик из Интернета, который имеет адреса отправителей, принадлежащих внутренним сетям (192.168.1.0/24 и 192.168.2.0/24). Такой фильтр создается из-за того, что администратор сети не ожидает поступления пакетов с внутренними адресами на внешний адрес SerialO маршрутизатора, подключенного к Интернету. Очевидно, что любой пакет, поступающий из Интернета с адресом отправителя из внутренней сети, будет подозрителен. В рассматриваемом примере существуют две внутренние сети класса С, для которых и работают первые два правила в списке доступа. Если сеть компании состоит из большего количества сетей, то для каждой в отдельности нужно будет создать соответствующее правило.
Третье правило в списке доступа (access-list 101 deny ip 127.0.0.0 0. 255.255.255 any) вынуждает маршрутизатор отбрасывать все дейтаграммы, у которых первый байт адреса равен 127 (это адреса обратной связи — loopback — для всех устройств в сети). Подобные пакеты никогда не должны появляться из Интернета и передаваться по внутренней сети. Некоторые подтипы атак address spoofing используют данные зарезервированные адреса как адреса отправителей.
Продолжая разговор о возможных атаках из Интернета, следует остановиться на атаке smurf, которая является относительно новой в категории атак на сетевом Уровне и относится к типу DoS. В этом случае атакующий посылает большое количество запросов протокола ICMP echo (команда ping), адресованных широковещательно. Причем все запросы имеют ложный адрес отправителя (тут есть варианты — можно использовать адреса отправителей из внутренней сети для проникновения через списки доступа, случайные или существующие, как будет показано далее). Если граничный маршрутизатор, с помощью которого организа-
ция подключается к Интернету, поддерживает передачу трафика с широковещг тельным адресом, выполняя трансляцию широковещания на уровне протокол IP в канальный уровень, то большинство компьютеров во внутренней сети буду, принимать эти запросы и отвечать на каждый из них, генерируя большой суммар ный трафик. Кстати, родственной атакой является fraggle, когда вместо прото кола ICMP используется протокол UDP, точнее одноименный запрос echo, вы полняющий те же функции. i
Успех атаки зависит от способности граничного маршрутизатора, обслужи' вающего большую сеть, транслировать широковещание па уровне IP (напримет адрес 10.255.255.255) в широковещание на канальном уровне (например для сел Ethernet FF:FF:FF:FF:FF:FF). Если обратиться к документу RFC 1812, содержаще му требования к маршрутизаторам для протокола IP, то там можно найти еде дующий текст: .^
VV«Маршрутизатор может поддерживать возможность, которая запрещает полу** чение широковещательных пакетов (направленного вещания — network-prefix^ directed broadcasts) на сетевом уровне, и должен предоставлять настройку для запрещения трансляции полученного широковещательного трафика. Маршрутизатор по умолчанию обязан поддерживать получение и трансляцию Широкове^
V
V
щательных пакетов сетевого уровня».
Естественно, что, настраивая маршрутизатор, администратор должен отклто чить рассматриваемую возможность, чтобы защитить сеть от атаки. Если в сет: используются маршрутизаторы Cisco Systems, то рекомендуется на них всех вЫ полнить команду no ip directed-broadcast. Обратите внимание, что команда доступ на в режиме настройки интерфейсов, следовательно, рекомендуется выполнят ее на всех интерфейсах. Кроме того, на маршрутизаторах с операционной сист^ мой Cisco IOS версии 12.0 и старше данная команда срабатывает по умолчания}
С целью защиты от рассматриваемой атаки можно настроить компьютеры и блокирование формирования ответов на запросы ICMP echo, если в качеств: адреса получателя указывается широковещательный адрес. В документе RFC Ц^ описывающем требования к конечным хостам, говорится: «Запросы протокол ICMP echo, адресованные широковещательно... могут игнорироваться без ув< домления отправителя...».
Однако большинство реализаций стека TCP/IP были разработаны с учета ответа на запросы ICMP echo, несмотря на риск пострадать от атаки smurf, злее для конечных компьютеров предпочтительнее было бы просто игнорировать 98 просы. Администратору следует проверить наличие дополнительных пакетов ДД используемых в организации операционных систем, которые после установи нового программного обеспечения меняют поведение стека в этом аспекте. -
Учитывая особенность атаки, можно выделить два сетевых объекта, подвер женные риску в наибольшей степени: атакуемая система и система с адресам; которые были указаны в качестве адресов отправителя. Рассмотрим пример се из 100 компьютеров, имеющей высокоскоростной канал подключения к ИнтерЕ ту. Теперь предположим, что атакующий генерирует постоянный поток запрос ICMP echo на скорости 768 Кбит/с с ложными адресами. Все 100 компьютер< получая запросы, будут формировать ответы на них, причем в совокупности отв ты могут занять полосу пропускания ориентировочно 78 Мбит/с, и весь эт
совокупный трафик будет посылаться по указанному в запросах адресу. Таким образом, атакующий может опосредованно воздействовать на объект нападения. Можно отметить исследования Крейга Хьюгена, который показал, что для локальной сети, состоящей из 200 компьютеров, оказалось возможно сгенерировать трафик объемом 80 Мбайт/с, направленный на стороннюю организацию. Столь большие объемы легко объяснимы: при отправке потока запросов со скоростью 400 Кбит/с широковещательно ответы умножаются на количество компьютеров в сети. Обратите внимание, что атакующему не нужно иметь высокоскоростное подключение к Интернету — в рассматриваемом примере хватит скорости в 512 Кбит/с (тут уже можно судить об особенностях атаки — работая по модему, ее организовать затруднительно).
Здесь следует отметить одну интересную особенность, связанную со списками доступа на маршрутизаторах Cisco Systems. Блокирование трафика атаки smurf списком доступа выполняется относительно медленно, так как в некоторых случаях требуется посылка отправителю (точнее, по указанным адресам — предполагается, что атакующий редко будет демонстрировать свой реальный адрес) сообщений ICMP unreachable. Блокирование входящих запросов ICMP echo на граничном маршрутизаторе защитит внутреннюю сеть, но не поможет снизить нагрузку на канал подключения к Интернету, поскольку хотя запросы и будут блокироваться маршрутизатором, в ответ могут генерироваться сообщения, указывающие на недостижимость получателя. Учитывая это, администраторам сетей, подвергающимся рассматриваемой атаке, стоит посоветовать обратиться в группу технической поддержки провайдера с просьбой выполнять фильтрацию трафика па их маршрутизаторы (если это, конечно, возможно организационно и технически). Кстати, принцип больших объемов ответного трафика, лежащий в основе этой атаки, можно использовать, например, для «финансового давления». Часто при подключении по высокоскоростному каналу к Интернету организация платит за входящий трафик, поэтому атакующий, указывая в широковещательных запросах адреса отправителей этой организации, способен неприятно удивить последнюю крупными счетами от провайдера. Обнаружение атаки можно усложнить, если организовывать ее ночью в надежде, что у жертв выключены программные комплексы обнаружения атак. Днем большие объемы необъяснимого трафика обнаружить несложно простым наблюдением за индикаторами на интерфейсах маршрутизатора (конечно, это не самый удобный способ).
При использовании списков доступа для фильтрации входящего трафика администратор может включить опцию ведения журнала (ключевое слово log при формировании правил списка доступа). Однако ведение журнала требует задействования ресурсов на маршрутизаторе, и при массированной атаке это опасно тем, что центральный процессор будет заниматься только журналом. Более того, если сообщения "Перенаправляются на сервер syslog, то во время атаки их количество может превысить размер допустимого.
■ Если в сети используется система обнаружения атак (Intrusion Detection System - IDS), то факт осуществления атаки выявляется довольно просто — по повышенному количеству запросов и ответов протокола ICMP. Однако если в сети для административных целей посылается большое количество запросов РШд, то это может привести к ложному срабатыванию системы обнаружения
атак. Другим критерием обнаружения может быть присутствие данных в запроЛ се ICMP echo (для увеличения объема трафика).
Для противодействия атаке рекомендуется настроить граничный маршруту' затор или защитный экран на блокирование прохождения в сеть запросов 1СМ@ echo. Кроме того, в настоящее время большинство производителей маршрутиз^ торов встраивают команду, позволяющую блокировать прохождение так на? зываемых spoofing-пакетов во внутреннюю сеть, проверяя помимо адресов полу*, чателей также адреса отправителей, чтобы убедиться, что обратный путь пакета,'' будет проходить через тот же интерфейс маршрутизатора, через который он бы®' получен. ,,'
Следует отметить, что схожий принцип используется в атаке Ping Flooding (шторм запросов ping), когда атакующий пытается нарушить работу сети, формируя постоянный поток направленных запросов ICMP echo. . Д
АТАКА CISCO IDENT
Некоторое оборудование, произведенное компанией Cisco Systems, поддерживает очень простой протокол идентификации, который годится для определения типа этого оборудования. Когда .j»’ таком маршрутизаторе устанавливается соединение протокола TCP с портом назначения 19^j маршрутизатор высылает сегмент TCP с установленным флагом RST (нормальное поведение)',! а в поле данных этот сегмент будет содержать слово cisco. Противодействие атаке может заклй-; чаться в блокировании порта 1999 для протокола TCP на граничном маршрутизаторе, что будет препятствовать атакующему опрашивать оборудование.. > Я
Продолжая рассмотрение вопросов защиты внутренней сети от внешних атак, у следует обратить внимание на возможности дополнительного программной обеспечения маршрутизатора Cisco IOS Firewall Feature Set, которое приобретем ется отдельно и после установки добавляет к маршрутизатору функции защитМ ного экрана. Использование этого программного обеспечения особенно привлй*^ кательно в тех ситуациях, когда в компании уже установлены маршрутизатор^! Cisco Systems и ей требуется улучшить безопасность на внешних подключениях.'. Такое решение позволяет совместить функциональные возможности маршрутй- ; затора и защитного экрана в одном устройстве.л ч
АТАКА, ОСНОВАННАЯ НА ФРАГМЕНТАЦИИ ДЕЙТАГРАММ IP^j
Дейтаграмма протокола IP иногда может фрагментироваться при передаче по сети. Эти фрагменты, будут собираться на стороне получателя и сформируют полную дейтаграмму. Некоторые маршрутй* j заторы, которые выполняют функции фильтрации трафика, основываясь на информации в заголо^ j ке протокола TCP, проверяют только первый поступивший фрагмент дейтаграммы, а остальное, пропускают без проверки. Учитывая такой подход, атакующий может создать фрагменты образом, что они будут как бы перекрывать друг друга. В результате не исключена перезапи»; частей заголовка протокола TCP при сборке фрагментов получателем. При этом фильтрующий^ маршрутизатор будет считать, что пакет адресован разрешенному порту. Очевидно, что подобнаяj атака в первую очередь ориентирована на прохождение через списки доступа на граничном мар^( рутизаторе или на защитном экране.. .5
Если обратиться к практике, то, по опыту автора, администратор сети ДОЯj жен учитывать три основных составляющих защиты сети: установку защитно^ экрана, внедрение системы обнаружения атак и использование сканера безопаМ
носги. Хотя, пожалуй, подобные меры призваны в большей степени защитить от атак извне (чаще всего из Интернета), так как защита изнутри помимо технических мер опирается на организационные мероприятия, приучающие пользователей обращать повышенное внимание на вопросы безопасности. Действительно, если, например, конкурент задастся целью получить некую конфиденциальную информацию о компании (цены, списки дебиторов и кредиторов и т. п.), то гораздо проще, например, подкупить одного из сотрудников и с его помощью проникнуть в сеть изнутри, чем нанимать профессиональных взломщиков для организации проникновения снаружи. Тем более, что традиционно сотрудники технических отделов оказывают больше внимания защите от атак извне, и по этой причине взломать сеть будет достаточно сложно.
Однако следует учесть участившиеся факты простого вандализма, когда за попыткой вывести из рабочего состояния корпоративный web-сервер стоят не коммерческие, а «познавательные» цели. Именно для этого стоит обращать внимание на организацию грамотной защиты периметра сети. Сначала рекомендуется выбрать подходящий защитный экран, тем более что в настоящее время рынок переполнен предложениями для разных платформ и размеров сетей. Если средства не позволяют, то можно просто настроить граничный маршрутизатор на совместное использование технологии NAT и списков доступа. Этого бывает вполне достаточно, учитывая, что большинство программных защитных экранов, собственно говоря, и представляют собой такую комбинацию, интегрируясь в операционную систему и перехватывая пакеты на одном из нижележащих уровней стека TCP/IP в соответствии с определенными загодя правилами.
АТАКА PING OF DEATH Эта атака относится к типу DoS и заключается в добавлении очень большого объема информации к запросу протокола ICMP echo, что может привести к сбою операционной системы. Следует обратить внимание, что хотя при нормальной работе сети и возможно появление сообщения ICMP echo с большим объемом дополнительных данных (более 4000 байт), на практике это очень редкая ситуация. Кроме того, если атакующий инициирует направленную атаку данного типа на защищенную систему, то ответы также будут относиться к типу Ping Of Death. Для противодействия можно настроить граничный маршрутизатор на блокирование входящих запросов ICMP echo. Однако здесь стоит обратить внимание на некоторые моменты, связанные с работой списков доступа, которые можно найти в описании принципов атаки smurf.
Другим важным элементом системы защиты является система обнаружения атак. Архитектура подобной системы часто строится из агентов и станции управления, на которую поступает информация. Причем типы агентов могут отличаться предполагаемым местом их установки. Так, компания ISS (Internet Security System — www.iss.net) предлагает продукт ISS RealSecure, который и призван обеспечить обнаружение и реагирование на атаки. Относительно атак из Интернета, по мнению автора, наиболее удачным будет использование агента Network Scanner, входящего в состав продукта. Этот агент устанавливается на выделенный компьютер, работающий, например, под управлением операционной системы Windows NT, и анализирует трафик на сегменте сети, к которому он подключен (рис. 9.5).
маршрутизатормаршрутизаторЗащитный экран
маршрутизатор
маршрутизатор
Рис. 9.5. Использование агента Network Scanner-i
В данном примере трафик, поступающий из Интернета, будет проходить чег^ рез граничный маршрутизатор и защитный экран, причем последний будет либ^ отбрасывать его, либо пропускать. Учитывая, что связующим звеном выступает концентратор, который по характеру своей работы передает весь проходящие трафик на все свои порты, то агент системы обнаружения атак сможет анализ™ ровать не только трафик, направленный ему, но также и весь трафик, напрам ленный в защищаемую сеть. В общих чертах работу агента можно охарактеризм вать следующим образом: он выполняет сравнение трафика с так называемыми сигнатурами известных типов атак, и если находит совпадение, то производим определенные действия (например, посылает письмо администратору сети). В лкж бом случае, агент ведет журнал событий, который является источником доволь-Ч но ценной информации о предпринимаемых попытках воздействия на сеть. Д
АТАКА SYN FLOODING (ШТОРМ ЗАПРОСОВ TCP SYN)«
Данный тип атаки был уже рассмотрен в главе 5, посвященной протоколу TCP. Обобщая, отметиИм что атака относится к типу DoS и является ее классическим представителем (по крайней мерей если судить по количеству материала в Интернете). При использовании в сети системы IDS важная иметь в виду, что существование посещаемого WWW-сервера в компании может вызывать ложный срабатывания из-за большого количества сеансов протокола TCP, устанавливаемых с сервером^ короткий интервал времени. Работая с системой ISS RealSecure, администратор сети при наличии! фактов ложных срабатываний может настроить параметры агента. Роль потенциальной жертвИ атаки в принципе способно играть любое устройство в сети, принимающее запросы протокола Тита и имеющее ограниченную очередь незавершенных запросов. Самым простым способом протия водействия этой атаке является обычная перезагрузка атакуемого компьютера, так как это оеввта бождает очередь запросов на установление соединения TCP. Если используется система IDS, М рационально настроить на уничтожение неактивных соединений. Естественно, излишне говори^ о необходимости установить последние обновления от производителя операционной системы, как в настоящее время большинство популярных операционных систем (точнее, реализация стает TCP/IP в них) поддерживают механизмы, позволяющие в той или иной мере противодействовал^ атаке SYN Flooding.
Следует отметить, что в настоящее время некоторые возможности систем си наружения атак встроены в защитные экраны. Так, например, защитный экр® GuardianPro v5.02 обнаруживает и блокирует атаки address spoofing. При эта факт подобной атаки записывается в журнал. Также допустимо настроить Я
правку электронной почты. При настройке стратегии защиты на защитном экране администратор сети может включить защиту от атаки spoofing и указать, какие именно адреса следует защищать.
На рис. 9.6 показано окно настройки стратегии безопасности. Здесь администратор может настроить защитный экран на выполнение контроля атаки address spoofing (Enable Spoofing control) с прямым указанием охраняемых сетей (Protected addresses).
& 4^ Common::iiЙGeneral|11Й*Customize g■'-Й*Monitored Networks/R<$Dynamic Networks/RarAuthenticationiiLogsIti A Alerts;t‘- HistorytFt @ Firewallit:i- Й* SYN flooding attack preh1i' Й’ЙМШЮЙii!।- Й*IP source routing protect’:-Й*Invalid Password rifTelnet spawning protect Short TCP Sessionsi:' Й* Content Filter Serverit3 Bandwidth Control-NAT& 4^ Common::iiЙGeneral|11Й*Customize g■'-Й*Monitored Networks/R<$Dynamic Networks/RarAuthenticationiiLogsIti A Alerts;t‘- HistorytFt @ Firewallit:i- Й* SYN flooding attack preh1i' Й’ЙМШЮЙii!।- Й*IP source routing protect’:-Й*Invalid Password rifTelnet spawning protect Short TCP Sessionsi:' Й* Content Filter Serverit3 Bandwidth Control-NATSpoofing controlSpoofing controlP Enable Spoofing control; Networks/RangeS --P Enable Spoofing control; Networks/RangeS --iiisfoMZ NetworkiiisfoMZ NetworkInternal Network.Internal Network.RefreshRefreshpyrw A.pyrw A.Acton oh'5popfir^'iiti«^: :■ tActon oh'5popfir^'iiti«^: :■ tProtected addresseeЩШшК—MProtected addresseeЩШшК—MP^ov=All|P^ov=All|
& 4^ Common::
iiЙGeneral|
11Й*Customize g
■'-Й*Monitored Networks/R<
$Dynamic Networks/Rar
Authenticationii
LogsI
ti A Alerts;t
‘- Historyt
Ft @ Firewallit
:i- Й* SYN flooding attack preh
1i' Й’ЙМШЮЙii
!।- Й*IP source routing protect
’:-Й*Invalid Password ri
fTelnet spawning protect Short TCP Sessionsi
:' Й* Content Filter Serverit
3 Bandwidth Control-
NAT
& 4^ Common::
iiЙGeneral|
11Й*Customize g
■'-Й*Monitored Networks/R<
$Dynamic Networks/Rar
Authenticationii
LogsI
ti A Alerts;t
‘- Historyt
Ft @ Firewallit
:i- Й* SYN flooding attack preh
1i' Й’ЙМШЮЙii
!।- Й*IP source routing protect
’:-Й*Invalid Password ri
fTelnet spawning protect Short TCP Sessionsi
:' Й* Content Filter Serverit
3 Bandwidth Control-
NAT
Spoofing control
Spoofing control
P Enable Spoofing control
; Networks/RangeS --
P Enable Spoofing control
; Networks/RangeS --
iiisfoMZ Network
iiisfoMZ Network
Internal Network.
Internal Network.
Refresh
Refresh
pyrw A.
pyrw A.
Acton oh'5popfir^'iiti«^: :■ t
Acton oh'5popfir^'iiti«^: :■ t
Protected addressee
ЩШшК—M
Protected addressee
ЩШшК—M
P^ov=All|
P^ov=All|
Рис. 9.6. Настройка GuardianPro на защиту от атаки address spoofing
Безопасность удаленного доступа
Продолжая разговор о базовой безопасности, следует отметить, что, как правило, любая крупная сеть предоставляет пользователям возможность работать с удален-
. ным доступом. При этом наиболее популярным решением организации удаленного доступа является использование аналоговых модемов, подключенных к какому-ли- • бо серверу доступа. Сам выбор сервера доступа напрямую зависит от количест- . ва претендентов, желающих воспользоваться таким сервисом. Однако помимо организационной выгоды от предоставления удаленного доступа необходимо обратить пристальное внимание на такие вопросы, как аутентификация (authentication), авторизация (authorization) и учет (accounting). В англоязычной литературе эти меры часто обозначают как «строенное А» (trippie А —^ХАА).
Аутентификация заключается в проверке пользовательского имени и^ароля. Данная задача и, собственно, ее реализация является центром любой системы безопасности удаленного доступа, и именно аутентификация отвечает за доступ пользователя в сеть, опираясь на тот факт, что система знает этого пользоватеЛя- Для последнего процесс аутентификации представляется проверкой его име- I ни (login, username) и пароля (password).
Авторизация призвана ограничить действия пользователя в сети, обычно прД средством добавления пользователя в какую-либо группу с наложенными огр®* ничениями. Это могут быть ограничения, связанные со временем разрешенною® ' входа в сеть (день, час), тип используемого протокола (IP, IPX), максимальное 1 количество одновременных сеансов для одной учетной записи (точнее, для од* ’ ной комбинации имени и пароля) и т. п. ;
С помощью учета, как можно понять из названия, отслеживается, что пользовав тель делает или делал в процессе работы с сетью, работая в режиме удаленного,'- доступа. Обычно наибольшее внимание уделяется ведению журнала, содержащего^ информацию о начале и конце сеанса удаленного доступа, о количестве полу*,; ченных и переданных байтов, о том, по какой линии передавались данные и т. п,-
ПРИМЕЧАНИЕ
Применительно к маршрутизаторам и серверам доступа компании Cisco Systems технология AAA пр* мимо управления доступом удаленных пользователей в сеть может также использоваться для контро* ля доступа технического персонала к интерфейсу командной строки IOS на сетевых устройствах.
Ключевым компонентом технологии ААА является централизованная б; данных, располагаемая на выделенном сервере и содержащая такую инфорМа* цию, как имена пользователей и соответствующие пароли, группы и связанны® с ними правила и т. п. Централизованное хранение информации помогает зна* чительно упростить администрирование сети, если администратор вынуждай поддерживать множество точек доступа в сеть. Альтернативой централизован* ного доступа может быть поддержка локальных баз данных на каждом маршру* тизаторе, однако последний подход не обеспечивает всей гибкости и возможно* стей централизованного управления.
Внедряя технологию ААА в сети, следует обратить особое внимание на меха= : низм взаимодействия маршрутизаторов и сервера ААА — для этого были разраб ботаны специализированные протоколы, наиболее популярными среди котор^ являются RADIUS (Remote Access Dial-In User Service) и TACACS+ (Terming . Access Controller Access Control System). Несмотря на некоторые технически расхождения в методе их работы, которые будут рассмотрены далее, ^эсновщ
WWЦель остается неизменной — они обеспечивают передачу запросов и ответов й^ жду клиентом (в нашем случае маршрутизатором) и сервером ААА для выпс^ нения аутентификации, авторизации и учета.,
W
W
Поддержка протокола RADIUS была введена в операционную систему Ci
IOS начиная с версии 11.1, и это позволяет, задействуя оборудование компащ Cisco, строить крупные центры обработки удаленных пользователей. Чаще вс< подобное решение востребовано компаниями, предоставляющими удален
пользователям доступ в Интернет.
Изначально протокол RADIUS был представлен компанией Livingston Enter prises как средство для аутентификации и учета. Затем, поддержанный раздав ными производителями оборудования для удаленного доступа, он был пр в качестве стандарта. ^ 1996 году спецификация протокола была передана* утверждение организаций iSTf1, и в настоящее время полное описание ст та можно найти в документах RFC 2058 и RFC 2059.
Работа самого протокола опирается на популярную модель «клиент-сервер». При этом сервер доступа (например, Cisco 2511) с точки зрения протокола выступает клиентом и отвечает за передачу пользовательской информации к выделенному серверу и затем принимает дальнейшее решение на основе ответа от сервера. Сервер RADIUS может предоставлять функции аутентификации и учета для множества клиентов, и он отвечает за получение запроса на подключение удаленного пользователя, его аутентификацию и отправку клиенту информации, которая необходима для предоставления требуемого уровня сервиса.
В настоящий момент существует множество программных средств разных производителей, реализующих сервер RADIUS, причем для разных платформ. Компания Cisco Systems предлагает свое собственное решение CiscoSecure, которое также поддерживается для платформ UNIX и Microsoft Windows. Хочется отметить, что, по опыту автора, наиболее удобной является реализация, поддерживающая различные методы хранения информации о пользователях, так как при относительно большом количестве клиентов встает вопрос о введение некой схемы оплаты предоставляемых услуг. При этом возможность, например, размещать информацию имени пользователя и его пароле в базе данных SQL часто является решающим фактором при выборе программного обеспечения с функциональностью сервера RADIUS (сказанное также относится и к серверу TACACS+).
Взаимодействие между клиентом и сервером RADIUS опирается на протокол UDP. Выбор именно этого протокола в качестве базового был продиктован тем, что вопросы повторной передачи утерянных пакетов, обработка временных задержек и т. п. обеспечиваются клиентом и сервером протокола RADIUS. Кроме того, наиболее популярной конфигурацией является ситуация, когда клиент и сервер RADIUS связаны надежной локальной сетью. Хотя, конечно, нет никаких ограничений на расположение клиента и сервера в разных частях распределенной сети.
Говоря обобщенно, проверка имени и пароля пользователя состоит в отправке запроса Access-Request (запрос на доступ) от клиента к серверу RADIUS и последующих ответов Access-Accept (доступ разрешен) или Access-Reject (доступ запрещен) от сервера. Пакет Access-Request содержит в себе имя пользователя, зашифрованный пароль, IP-адрес клиента RADIUS (сервера доступа) и номер порта, на который обратился пользователь. Кроме того, в данный пакет включена служебная информация о типе сеанса, которую запрашивает пользователь: например, если подключение выполняется по протоколу РРР, то поле Service-Type (тип сервиса) устанавливается в значение Framed-User, а поле Framed-Type — в значение РРР.
Когда сервер1 получает запрос от клиента на проверку пользователя, он проверяет наличие последнего в своей базе данных учетных записей. Если указан-
пая комбинация имени и пароля не присутствует в базе данных, то сервер сразу посылает сообщение Access-Reject, которое может также сопровождаться дополнительным текстовым сообщением, объясняющим причину отказа в доступе В том случае, если имя пользователя найдено и его пароль корректен, сервер возвращает сообщение Access-Accept, включающее в себя список атрибутов которые определяют параметры для данного сеанса. Обычные параметры это тип протокола, адрес IP для пользователя (статический или динамический), список доступа для применения к этому пользователю или статический маршрут, добавляемый к таблице маршрутизации сервера доступа.
Аутентификация пользователя является наиболее сложным аспектом обеспечения безопасности. Стандартная реализация протокола RADIUS поддерживает разные методы аутентификации, включая протоколы РАР и CHAP. Однако решения различных производителей могут добавлять поддержку других протоколов.'
ПРИМЕЧАНИЕ ■
Компонент IAS компании Microsoft, входящий в состав операционной системы Windows 2000 ’ Server, поддерживает следующие протоколы: PAP, CHAP, MS-CHAP версий 1 и 2 и ЕАР (Extensible ’ Authentication Protocol). Протокол ЕАР предоставляет организации целую инфраструктуру обес* печения безопасности, поддерживая такие возможности, как пластиковые карты, клиентски^ ' сертификаты и т. д.’;
В противоположность протоколу RADIUS, TACACS+ шифрует весь пакет, оставляя в открытом виде только заголовок, в котором присутствует поле, указывающее на то, зашифровано или нет тело сообщения. При нормальной работе тело сообщения шифруется полностью.
Практическая настройка технологии Cisco AAA
Для того чтобы аутентифицировать пользователя, администратор сначала должен определить так называемый аутентификационный список, формирующий последовательность действий, которые обязан предпринять маршрутизатор для проверки пользовательского имени и пароля. Например, список может указать сначала попробовать обратиться к протоколу RADIUS, а если попытка его применения не будет успешной, проверить локальную базу имен и паролей. После того как список создан, он применяется на интерфейсах маршрутизатора, на которые обращаются пользователи.
Для того чтобы включить поддержку технологии ААА на маршрутизаторе, администратору следует ввести в глобальном режиме команду ааа new-model. Далее нужно создать именованный список аутентификации с помощью команды ааа authentication.
Cisco2511RJ#conf terminal
Enter configuration commands, one per line. End with CNTL/Z.
C1sco25llRJ(conf1g)#aaa new-model.
C1sco25llRJ(config)#aaa authentication ppp LI radius local
В приведенном примере создается новый список с именем L1, указывающий, что в качестве первого метода аутентификации необходимо выбрать протокол RADIUS (точнее, сервер безопасности, поддерживающий протокол RADIUS), а если сервер нс удастся использовать (например, он выключен), то маршрутизатор будет пытаться проверить имя пользователя и пароль в своей локальной базе (ключевое слово local). Следует обратить внимание, что список создается для проверки пользователей, подключившихся по протоколу PPP (Point- to-Point Protocol), который в настоящее время наиболее популярен для подключения удаленных пользователей и офисов компании через коммутируемые соединения.
Создав список, его следует применить на интерфейсе, который будет принимать входящие звонки. Для асинхронного интерфейса последовательность команд может быть следующей:
Ci sco2511RJ(conf1g)#int async 16
C1sco25llRJ(?onfig-if)#ppp authentication chap LI
В команде ключевое слово chap указывает на задействуемый протокол передачи имени и пароля от удаленного пользователя к маршрутизатору. В нашем случае таким будет одноименный протокол CHAP (Challenge Handshake Authentication Protocol), который шифрует передаваемую информацию. В распоряжении администратора также есть протокол PAP (Password Authentication Protocol), выполняющий те же функции, что и CHAP, за исключением шифро-
вания передаваемых данных (пароль передается открытым текстом). Список доступных для использования протоколов можно получить с помощью команды ppp authentication ?.
В примере выше созданный список аутентификации применялся только на одном интерфейсе (номер 16), в то время как на практике чаще всего приходится работать с группой асинхронных интерфейсов, что позволяет снизить затраты по управлению. Так, на маршрутизаторе может быть создан логический интерфейс group-Async 1, который объединяет все 16 физических асинхронных интерфейсов. Это осуществляется с помощью команды group-range с указанием начального и конечного номеров объединяемых интерфейсов.
Cisco2511RJ(conf1g)#1nt group-Async 1
Cisco2511RJ(config-if)#group-range 1 16
Cisco2511RJ(config-1f)#ppp authentication chap LI
11Вместо создания именованных списков аутентификации администратор вправе определить список по умолчанию (default authentication list), который иденти-
1
1
фицируется с помощью ключевого слова default. Маршрутизаторы Cisco Systems J будут использовать список по умолчанию, если администратор не определил Л именованных списков. Следующий пример показывает настройку списка ауте№ 1 тификации по умолчанию с двумя методами проверки пользователей (первый J с помощью протокола RADIUS, второй с помощью локальной базы пользовате- ■
лей) и включает поддержку протокола CHAP на асинхронном интерфейсе. '
Router#conf terminalС
Enter configuration commands, one perline.EndwithCNTL/Z.i
Router(config)#aaa new-model.<j
Router(config)#aaa authentication pppdefaultradiuslocal?Uj
Router(config)#int async 1^
Router(config-if)#ppp authentication chap.ri
Следует отметить, что AAA — это не только способ контроля подключений; удаленных пользователей к сети. Администратор сети вправе применить эт$ технологию также и для контроля доступа к маршрутизаторам. Если сеть обслу^ живается силами одного специалиста, то такой подход может быть избыточным,' однако все его достоинства проявляются, если существует группа специалистов занятых управлением и настройками маршрутизаторов. С помощью технологи#' ААА можно проверять каждого отдельного технического специалиста и вест# журнал изменений. Даже если задачи ведения журнала не очень важны для ор* ганизации, сам факт предоставления каждому пользователю имени и пароля? доступа является хорошей политикой безопасности по сравнению с поддержка^ одного пароля для команды enable. Кроме того, внедрение ААА позволит выпоЛ^
нять периодическое централизованное изменение паролей доступа.
Контроль доступа к командной строке маршрутизатора аналогичен заД1 чам, решаемым при контроле доступа с помощью протокола РРР для удалс] ных пользователей: необходимо создать список аутентификации и примени^ его на консольном порте (console) и виртуальных портах VTY. Следуют^
пример показывает настройку списка и применение его к виртуальным портам с номерами 0-4.
Router#conf terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#aaa new-model
Router(config)#aaa authentication login L3 radius line enable
Router(config)#line vty 0 4
Router(config-line)#login authentication L3
Здесь команда aaa authentication login L3 radius line enable создает именованный список аутентификации L3 для проверки доступа к командной строке маршрутизатора. Созданный список заставляет маршрутизатор проверять имя пользователя и пароль с помощью протокола RADIUS (если указать ключевое слово tacacs+, то маршрутизатор будет использовать сервер TACACS+), а если проверка будет неуспешной по любым причинам, то предписывает проверить пароль, присвоенный виртуальным портам VTY (доступ с помощью протокола Telnet). Если же пароль доступа не был настроен, то маршрутизатор будет пытаться использовать пароль enable. Важно отметить, что использование пароля enable в качестве «последней инстанции» очень рекомендуется, так как помогает предотвратить ситуацию, когда доступ к маршрутизатору станет невозможным ввиду проблем с сервером RADIUS (или TACACS+).
Если администратор по каким-либо причинам не может задействовать протоколы RADIUS/TACACS+, то в его распоряжении есть возможность поддерживать базу данных пользователей локально на маршрутизатору (так называемая local username database). Такая возможность полезна в ситуации, если необходимо обслуживать небольшое количество пользователей, так как в этом случае все удобства централизованной базы будут отсутствовать. Важно отметить, что локальная база может работать как резервный источник аутентификации. Для этого нужно настроить список аутентификации с ключевым словом local, следующим за ключевыми словами radius или tacacs+.
Router(config)#aaa authentication ppp L4 radius local
Для создания локальной базы пользовательских имен и паролей следует выполнить команду username, вводимую в глобальном режиме. В качестве параметра команды указываются имя и пароль (непосредственно пароль после ключевого слова password).
Router(config)#username userl password passl
Router(config)#username user2 password pass2
Для того чтобы введенные пароли хранились в зашифрованном виде, предусмотрена команда service password-encryption, также вводимая в глобальном режиме.
Как уже отмечалось, задача авторизации (authorization) в технологии ААА заключается в определении тех действий, которые пользователю позволено выполнять во время сеанса. Администратор вправе контролировать доступ, например, в соответствии со временем и днем недели, используемым протоколом
и т. д. в зависимости от возможностей сервера ААА. При этом сервер доступа, работая клиентом по протоколу RADIUS/TACACS+, будет получать информацию об авторизации и назначать указанные привилегии пользователю.
Чтобы настроить маршрутизатор на опрос сервера ААА для авторизации пользователей, работающих по протоколу РРР, следует выполнить команду ааа authorization network, как показано в следующем примере (если протоколом авторизации является TACACS+, нужно ввести ключевое слово tacacs+ вместо radius).■
Router(config)#aaa authorization network radius none;
В этой команде ключевое слово none указывает маршрутизатору на необ- . ходимость успешно заканчивать авторизацию даже в том случае, если сервер ■) RADIUS недоступен. Аналогично, для настройки авторизации доступа к коман- а дной строке маршрутизатора следует вместо network указать ключевое слово exec j
Router(config)#aaa authorization exec radius none. i
Как и при авторизации, возможности третьего А — учета (accounting) значив 1 тельно зависят от реализации сервера ААА. В любом случае, как и для автори/^ зации, администратор должен напрямую указать маршрутизатору использоват^Л команды учета протоколов RADIUS или TACACS+. Операционная система! Cisco IOS поддерживает три метода ведения учета.
Первый метод (stop-only) предполагает, что маршрутизатор посылает учет-$ ную информацию (accounting records) серверу ААА по протоколу RADIUS илм TACACS+ только в том случае, когда пользовательский сеанс завершается. Оче,; л видно, что этот метод предоставляет минимальные возможности для ведения;1 учета. Второй метод (start-stop) подразумевает, что учетная информация посы^ лается в начале и конце пользовательского сеанса. Третий метод (wait-star^i предполагает, что записи посылаются серверу ААА в начале сеанса, а затейЗ маршрутизатор ожидает подтверждения от сервера для начала обслуживания пользователя. Учетная информация также посылается при завершении УД^Я ленного сеанса.
Сама учетная информация передается в служебных пакетах протоколр^я RADIUS/TACACS+ и включает в себя время начала и конца сеанса, его длитедмя ность, количество переданных и полученных байтов, вводимые команды и т.
Для настройки функции учета на маршрутизаторе администратору следуМд выполнить команду ааа accounting, вводимую в глобальном режиме. Следую1ЩЯ|Я пример показывает настройку учета на основе протокола RADIUS для пользе^™ вателей, работающих по протоколу РРР./Я
Router(config)#aaa accounting network start-stop radius
■ Ключевое слово start-stop указывает маршрутизатору посылать серверу RADl№M информацию о начале и конце сеанса пользователя, как было отмечено ранс^И Если следует вести учет для пользователей, работающих с командной строксиш маршрутизатора, следует вместо network указать ключевое слово ехес.
После того как администратор настроил все три элемента технологии ему остается информировать маршрутизатор, какой сервер (и протокол)
вителен при проверке пользователей. Для этого нужно указать IP-адрес сервера и специальный закрытый ключ (security key) для обеспечения безопасности взаимодействия. Без этих двух параметров маршрутизатор не сможет работать с сервером по протоколу RADIUS или TACACS+. Закрытый ключ предназначен для шифрования передаваемых данных и для аутентификации клиента (маршрутизатора) на сервере. Следующий пример показывает настройку рассмотренных параметров на маршрутизаторе.
Router(config)#radius-server host 192.168.3.253
Router(config)#radius-server key dybvfybt
При вводе команды radius-server host можно вместо адреса ввести имя хоста, и если на маршрутизаторе настроена поддержка DNS, он выполнит преобразование имени в адрес и подставит последний. Вторая команда указывает закрытый ключ (в нашем примере dybvfybt). Если администратор склонился в сторону протокола TACACS+, то для него нужно ввести аналогичные команды, только вместо ключевого слова radius-server указать tacacs-server.
1 О Построение JL w виртуальных частных сетей
Введение"
В данной главе детально рассматриваются вопросы построения виртуальных Ч! ных сетей на базе протокола PPTP (Point-to-Point Tunneling Protocol — прото: туннелирования «точка-точка»), поддержка которого входит в задачи операцй ной системы Microsoft Windows 2000 Server (как, впрочем, и в маршрутизак Cisco Systems). Необходимость применения технологии виртуальной част сети (Virtual Private Network — VPN) наиболее часто возникает, когда нео£ димо подключить один или несколько удаленных объектов, которые невозм но (или нецелесообразно экономически) подключать традиционными метод (например, привлекая провайдера услуг связи). Основным материалом для) ной главы послужила практика подключения одного из удаленных объев к корпоративной сети. Кроме того, материал главы будет отталкиваться от оп автора по построению сети на основе самостоятельного формирования кана связи по прямым медным проводам (в масштабах Санкт-Петербурга). Читат может показаться, что связи между прямыми (от объекта до объекта) пров< ми и технологией VPN нет, по как будет показано далее, одно вытекает из I гого, особенно если было принято решение строить сеть своими силами.
При создании распределенной компьютерной сети организация высокое ростной связи является наиболее сложной частью общей задачи. При этом р идет только о высокоскоростных каналах, а не о связи с использованием ан<1 говых модемов. Конечно, как вариант, в некоторых случаях и аналоговые м(| мы могут обеспечить соединение, но при этом следует помнить о том, что : минимум необходим свободный телефонный номер на удаленном объекте, и скорость и качество соединения будут невысокими. Естественной альтерна вой является цифровая связь, которая, в свою очередь, имеет альтернатив): решения. Например, для связи объектов можно использовать такие технолог как ISDN, Frame Relay или даже ATM. Выбор конкретной технологии завй от потребностей компании и от ее финансовых возможностей по оплате ключения и ежемесячной оплате услуг.
Первоначально при создании сети, некоторые решения из которой А в основу материала данной книги, использовалась технология Frame
(см. главу 8), услуги которой в Санкт-Петербурге предлагали несколько компаний. Эта технология к тому времени была довольно надежной и с достаточно развитой структурой, что позволяло надеяться на работу без проблем. Но внедрение этой технологии предполагает достаточно серьезные финансовые затраты. Причем уровень затрат напрямую связан с требуемой скоростью передачи данных. Однако, в виду ценовой политики провайдера, компания была вынуждена ограничить максимальную скорость передачи 32-64 Кбит/с, что не всегда соответствовало запросам. Самое главное — это препятствовало внедрению идеи передачи голоса по сети IP. С учетом таких скоростных и ценовых ограничений, а также того факта, что ПТС (Петербургская телефонная сеть) предлагала услугу формирования прямых медных проводов в городе, было принято решение приступить к работам по постепенному переходу от технологии Frame Relay к технологии xDSL. Кстати, если говорить о затратах, то еще одним доводом в пользу xDSL может быть тот факт, что существуют модемы для физических линий, интегрирующие в себе функциональность моста и поставляемые с портом 10Base-T — идеальное решение для связи двух локальных сетей, если не требуется более гибкое управление трафиком. В последнем случае лучше остановиться на моделях с портом V.35 и подключить их к маршрутизатору (например, Cisco Systems).
В специализированной литературе технология xDSL описана достаточно подробно, поэтому ее детальное рассмотрение останется за рамками книги. Технология действительно удивительная — она позволяет при помощи одной или двух пар прямых проводов между двумя объектами добиться пропускной способности до 2 Мбит/с (уровень достигаемой скорости существенно зависит от качества медной пары).
Для организации соединения xDSL между двумя объектами (как правило, эта технология работает для двухточечной связи) оформляется заявка в местную телефонную сеть, в которой указаны адреса объектов и номера городских телефонов (описывается процедура применительно к городу Санкт-Петербург). В заявке предлагается организовать одну или две пары прямого провода между объектами. Опыт показывает, что лучше также дать дополнительную информацию, например перечислить телефонные коробки, установленные в здании (естественно только те, к которым есть доступ). Такая информация может уменьшить время проверки возможности выделения проводов. Через некоторое время приходит ответ. Если поставщик услуг согласен, то необходимо оформить договор и после его оплаты на кросс-узлах промежуточных АТС формируют прямой провод (часто црд термином «прямой провод» понимают одну медную пару проводов). Естественно, описан идеальный вариант развития событий, в то время как на практике часто появляются проблемы. Если прямой возможности нет, то можно провести дооборудование объекта или, иными словами, расширить за свой счет кабельные емкости оператора связи по его указанию. Автор сталкивался с необходимостью провести дооборудование нескольких объектов — были проложены десятипарные телефонные кабели от коммуникационных шкафов, включая установку телефонных коробок. Только после этого были выделены прямые провода.
Выделенный в ваше распоряжение прямой провод необходимо проверит: так как его качество будет очень существенно влиять на надежность и скорое канала связи. Простую проверку можно провести с помощью обычного тестег При этом с одной стороны замыкают концы у выделенного провода, а на другой измеряют суммарное сопротивление. Естественно, тестер не должен показывать, «бесконечность». Если все в порядке, то стрелка должна остановиться в интерн вале между 100 и 1500 Ом. Опыт показывает, что в большинстве случаев, есл^ сопротивление проводов больше 1500 Ом, модемы работать не будут. На прям^' тике есть еще масса характеристик провода, влияющих на работоспособность' К ним относятся: диаметр жил, наличие переходов между сечениями, емкостям* составляющие и т. п.J
Теперь можно взять пару модемов на пробу. Хорошо бы уделить проверь хотя бы два дня (вообще говоря, чем дольше, тем лучше) и за это время прове ти мониторинг. Следует помнить, что периодически, особенно на плохих пров дах, модемы могут терять синхронизацию и канал связи «падает». После разрг ва связи модемы будут пытаться восстановить соединение. Длительность такт перерывов зависит от модели модема. Иногда бывает так, что модемы восстана ливают связь, но через пару секунд теряют несущую, затем цикл повторяет! вновь. Учитывая, что на большинстве моделей модемов есть визуальная инд: кация, то этот процесс легко наблюдать. Что касается рекомендаций о примем нии того или иного типа модемов, то дать ее трудно, так как не все типы мод мов были доступны для тестирования и по этой причине рекомендация будет; совсем объективна. Так, хорошо показали себя на «сложной» линии модеь FlexDSL компании «Натеке» с модуляцией РАМ, хотя была ситуация, кот после очередной потери синхронизации они не смогли восстановить связь б принудительного выключения питания на обоих концах. Так же очень хорог работали модемы компании SCHMID TELECOM AG серии Watson и модек PairGain (ADC) Megabit Modem MM300S.■
Модемы могут иметь различные типы интерфейсов для подключения к Hi сетевого оборудования, но чаще всего для связи локальных сетей используют! интерфейсы V.35 или lOBaseT. В последнем случае модем работает либо к; мост, что бывает чаще, либо как малофункциональный маршрутизатор, возмЬз иостей которого, однако, достаточно для подключения, например, к сети Интё нет. Существуют модемы с портами Ethernet, которые имеют свой собственна IP-адрес для дистанционного управления ими через Telnet. Хочется особо от тить удобство использования модемов с портом lOBaseT, работающих в режг моста. В рассматриваемой сети работает модем PairGain (ADC) Megabit Mod MM300S, который, несмотря па невысокую стоимость (порядка $1200 за, штуки), обеспечивает качественное соединение на скоростях до 2 Мбит/с.
То есть в простейшем варианте, когда нужно связать две территориалз разнесенные локальные сети, модемов с портами 10Base-T будет вполне до< точно. Кроме того, как показывает опыт, даже при числе объектов более дес* модемы с функциональностью моста не создают никаких проблем, хотя i планировании сети были сомнения на случай появления широковещательн трафика с присущим ему большим объемом. Однако в действительности ) вонь широковещания в сети не превышал допустимых" пределов. На что, в *
ности, повлияли коммутаторы компании Hewlett-Packard, которые поддерживают технологию ABC (Automatic Broadcast Control — автоматический контроль широковещательных пакетов), позволяющую снизить уровень общего трафика.
В подобных модемах не предусмотрено никакого внешнего управления через компьютер, которое, например, доступно для модели FlexDSL, но они позволяют проводить регулировку скорости с помощью специальных переключателей на задней панели. Существуют ситуации, когда такой регулировкой приходится пользоваться. Например, в результате ухудшения качества линии (а это может произойти после дождя) модемы постоянно теряют синхронизацию. Для более устойчивой их работы можно позвонить на удаленный объект и попросить любого сотрудника с помощью отвертки установить указанную вами скорость. Более «продвинутые» модели модемов позволяют провести корректировку скорости только на одном из них — на ведущем (master), а второй удаленный модем (slave или ведомый) должен автоматически утвердить предложенную скорость или же не принять ее, если качество провода не позволяет. Как правило, управление подобными модемами осуществляется через консольный (последовательный) порт (RS-232) компьютера с помощью программы терминала. В этом месте хочу несколько отвлечься от темы и отметить, что были ситуации, когда для управления модемами компании «Натеке» пришлось своими руками монтировать кабель для подключения модема к компьютеру — все имеющиеся у нас кабели не обладали соответствующий распайкой. Впрочем, это не должно вызывать больших трудностей, так как схема нужного кабеля приводится в документации на модем.
Переход от технологии Frame Relay выполнялся постепенно. В общей сложности, процесс перехода занял более двух лет, хотя, конечно, можно было сделать это быстрее. Сложности возникли с самым удаленным объектом, который находился на расстоянии 30 километров от ближайшего объекта, к которому можно было доступиться по прямому проводу. В конечном итоге и эта удаленная точка была подключена по технологии VPN (виртуальных частных сетей). Но это стало возможным после появления провайдера услуги ADSL (асимметричная цифровая абонентская линия — Asymmetric Digital Subscriber Line, провайдер WebPlus — http://www.wplus.net). Кстати, следует отметить, что подключение по ADSL со скоростью 64 Кбит/с (входящий поток) и 16 Кбит/с (исходящий поток) с последующей шифрацией трафика в туннеле по протоколу РРТР ничуть не хуже, чем виртуальное соединение Frame Relay со скоростью подключения 64 Кбит/с (Access Rate, AR) и гарантированным CIR (Committed Information Rate) в 16 Кбит/с. Но это если не брать во внимание вопросы надежности — туннель РРТР, работающий через сеть Интернет, иногда имеет свойство отказывать 2-3 раза в день, хотя время восстановления составляет всего пару минут. Более того, иногда при управлении через терминал удаленным сервером, работающим под Windows 2000, кажется, что стало даже лучше, быстрее.
Сначала выбор был сделан в пользу модемов с портом V.35 для того, чтобы можно было задействовать имеющиеся маршрутизаторы, которые использовались с технологией Frame Relay. После того как все маршрутизаторы оказались в связке с модемами с портом V.35, мы стали приобретать модемы с портами
10Base-T. Хочу сразу отметить их недостаток — сложно отслеживать проходящая через канал объем трафика. Если используются маршрутизаторы, то достаточщм подключиться через сеанс Telnet и вывести статистику по интерфейсу (для марщ/^ рутизатора Cisco Systems с помощью команды show interface ...) или запустить ' инструменты сбора статистики по протоколу управления SNMP. Многие адми* нистраторы предпочитают программу MRTG (http://people.ee.ethz.ch/~oetike$ i webtools/mrtg), отображающую в графическом виде уровень проходящего TpgiJ фика. Для модемов с портами 10Base-T это невозможно. Кроме того, при hc* j пользовании модемов с функцией моста, в том случае если IP-адрес им не н^ значается, сложно провести мониторинг работоспособности удаленного каналЙ связи, особенно когда на другом конце нет постоянно работающих устройств с фиксированным IP-адресом. В результате, в распределенной сети получилас^ некоторая «солянка» из разных типов модемов. Однако постепенно по мере рей лизации идеи передачи голоса поверх сети IP, модемы с портами Ethernet сйЙ ли замещаться на связку из маршрутизатора (Cisco Systems) и модема с портд^ V.35. Основная причина замены не в том, что модемы с портами V.35 лучп^ чем модемы с портами Ethernet, а в том, что передача речи очень критична кзЙ^ держкам, и если по одному каналу одновременно передаются и голос и даннь^ то крайне необходимо голосовому трафику назначать больший приоритет п$$Й передаче. С такой задачей могут справиться маршрутизаторы, но не в силах cd^J владать модемы. Правда и стоимость организации связи увеличивается на цеН$ двух маршрутизаторов, хотя, как вариант, можно приобрести бывшие в употрёб$ лении устройства (рекомендую посетить сайт www.usedcisco.ru).
Переход на выделенные каналы xDSL ознаменовался для компании высоки^ ми скоростями (от 64 Кбит/с до 2 Мбит/с) и резким снижением затрат — аб^Й
В1В1нентская плата за одну пару прямого провода составила примерно 500 рублей в месяц (хочу сразу отметить, что приводимые в книги денежные величи верны только на момент написания книги и, естественно, могут меняться временем). А затраты на связь всех объектов по городу с выходом в сеть Интё! нет составили приблизительно 5000 рублей в месяц. Помимо экономически целесообразности отказа от услуг Frame Relay существует и скоростная соста ляющая — связь со скоростью менее чем 64 Кбит/с не проводится ни с од из объектов. Сегодня руководство компании проявляет все больший интерн к внедрению местной голосовой связи с удаленными объектами с применений технологии VoIP. И очень отрадно, что существующая инфраструктура сет благодаря своим высоким скоростям позволяет провести внедрение этой логии без больших затрат.
В1
В1
Для этого существует несколько решений. Например, компания Cisco 5 предлагает модели телефонов, которые подключаются напрямую к локаль сети. В этом случае необходимо провести следующие работы: приобрести который с одной стороны включается в центральную офисную телефонную цию головного офиса (УАТС), а с другой стороны — в локальную сеть; на удаленный объект приобретается необходимое количество IP-телефонов; уст ливается сервер с работающим программным обеспечением Cisco CallMan (или аналог), выполняющий задачи телефонной станции, но только для IP- После этого на удаленных объектах пользователи могут принимать вне
и внутренние звонки и выполнять их сами. Причем высокоскоростные каналы связи в большой степени и определяют успех проекта — в зависимости от используемых кодеков один телефонный разговор может занимать разную полосу пропускания (например, 32 Кбит/с), и чем выше скорость каналов, тем больше одновременных разговоров будет поддерживаться (ну и, разумеется, тем будет выше качество голосового соединения). Если у компании нет возможности приобрести подобные модели телефонов, то можно предложить другой вариант — использовать предложенную компанией Cisco Systems модель Cisco АТА 186, которая позволяет подключать к сети IP обычные аналоговые телефонные аппараты.
Ранее говорилось о достоинствах создания каналов связи своими силами, теперь необходимо отметить и недостатки такого пути. Самый существенный из них — низкая надежность, особенно при работе на критических расстояниях. Модемы могут под воздействием внешних факторов потерять контакт друг с другом, после этого нужна как минимум пара минут для восстановления связи. Зачастую проблемы со связью возникают из-за ремонтных работ, которые проводились в телефонных колодцах. В таких случаях время простоя может достигать нескольких дней. То есть если надежность связи является строго обязательным условием, то настоятельно рекомендуется обратиться к провайдеру и заказать оптоволоконный канал для организации связи.
Могут возникнуть и вовсе мистические неполадки. Такая ситуация в течение длительного периода времени наблюдалась на одной из удаленных точек. Постоянно связь с ней была очень неустойчива — модемы могли проработать 2-3 часа, а затем потерять синхронизацию на 5-6 часов. Неоднократные вызовы кабельщиков-монтажников решали проблему только временно и перебои со связью повторялись регулярно — проблема заключалась в том, что вносились сильные помехи через проложенный рядом силовой кабель. Ко всему прочему, в один прекрасный момент охотники за цветными металлами вырезали кусок кабеля, проложенного внутри здания до телефонной коробки. Поставленный взамен новый кабель погрызли крысы и т. п. Но бывает и иначе, когда провод работает месяцами даже без намека на сбои, а если они и случаются, то очень редко, и модемы сами восстанавливают синхронизацию. Периодические проблемы со связью становятся еще более ощутимыми, если в компании планируется внедрить IP- телефонию. Как показывает практика, построение распределенной сети своими силами является оптимальным выходом только на определенном этапе ее развития. По мере того, как в сети внедряются все новые решения, которые подразумевают повышенные требования к надежности и качеству, пользователи могут все серьезнее ощущать на себе недостатки медных проводов.
Хочется отметить, что к моменту появления необходимости подключения первого территориально-удаленного объекта (который было невозможно подключить с помощью прямого провода из-за значительного расстояния) все другие точки уже были связаны между собой с помощью прямых проводов. Опыт создания виртуальной сети оказался столь успешным, что в последующем он применялся для подключения даже тех объектов, которые можно было бы просто замыкать на сеть центрального офиса. Почему? Дело в том, что всегда было желание сделать удаленные объекты максимально автономными и независимыми от перебоев со связью. Ведь прямые провода, как и любые каналы связи, перио-
дически перестают работать. И чем независимее точка, тем меньше будет npd блем с пользователями."
Так вот, успех с первым объектом подтолкнул к пересмотру схемы всей pacimi деленной сети — теперь объекты представляют собой некие «островки», связа ные между собой туннелями РРТР, и при этом остаются автономными. А ме островками «штормит океан» сети Интернет. Безусловно, у такого подхода ев^ и недостатки: необходимо устанавливать защитные экраны (или другие фильтр щие устройства), настраивать туннели, планировать и поддерживать политик удаленного доступа и т. п. К достоинствам же можно отнести уже отмече автономность объектов, контроль доступа из удаленного объекта в центральна сеть офиса (можно настраивать ограничения на доступ для удаленных по вателей), контроль доступа в Интернет для каждого объекта и, как следствй
отдельный учет полученного и переданного трафика (как в сети Интернет, тд
и между туннелями), возможность быстро и безболезненно разорвать тунн^п^^В между объектами в любой момент времени и т. п. Несмотря на то, что туннет^^В подразумевают некоторое административное вмешательство, но по сути, раз настроив их, можно практически забыть об их существовании.
-4j-4jОборудование удаленных объектов
-4j
-4j
м tм tНа удаленных объектах с небольшим количеством компьютеров не всегда ц^ сообразно выделять место под серверную комнату. Во-первых, зачастую м«
м t
м t
является дефицитом (скажем, ваша компания открыла магазин и для этик лей арендует помещение — как правило, все пространство тотчас же будет з£ то под упаковку и т. п.), во-вторых, на небольшое количество пользователей' нужды создавать емкую сетевую инфраструктуру.
Те специалисты, кто сталкивался с подобной задачей, согласятся, что н шим решением будет установка оборудования в коммуникационные шкафы, торые имеют защиту от пыли и могут закрываться на ключ. Шкафы помогу защитить оборудование от внешнего воздействия, не говоря уже и о несанк^ нированном доступе. Если важность их использования очевидна, то интере< остановиться на том, какие именно шкафы нужны. По мнению автора, заю дорогих фирменных стоек не всегда оправданна, особенно если не выдвигав очень жесткие требования по защите оборудования от окружающей среды. В б^ шинстве случаев таких требований нет, и все что нужно, это укрыть аппара от любопытных глаз, пыли, грызунов и насекомых (как правило, от тарану и крыс, если последние присутствуют, конечно). Например, тараканы имеют ву ную привычку забираться внутрь оборудования и застревать между допасу охлаждающих вентиляторов. Защита от пыли также важна, особенно если оо# территориально удален и туда нет возможности ездить каждый месяц, что; прибрать помещение. Одним из возможных решений может быть покупка 1 лического шкафа, или антресоли, с шириной и высотой от 1000 мм, а глу<# от 400 мм. По крайней мере, в Санкт-Петербурге были найдены именно^ шкафы, которые хорошо подходят для размещения двух серверов, одногО"»
тора и другого небольшого по размеру сетевого оборудования. В этот шкаф обязательно нужно поставить вентилятор (вытяжной), питаемый от обычной сети 220 В. В противном случае температура внутри шкафа может достигнуть критической для оборудования отметки. Щели в шкафу желательно залить герметиком, а на дверцу навесить замок. Подобное решение обойдется гораздо дешевле, чем покупать фирменный коммуникационный шкаф, который иногда по стоимости сопоставим со стоимостью сервера. Обратите внимание на то, что если шкаф будет стоять рядом с местом «дислокации» местных работников, то они его обязательно приспособят под чайный столик и несколько раз обольют кофе. Поэтому желательно шкаф размещать так, чтобы кофе на нем пить было дискомфортно, пусть даже в ущерб собственным удобствам. При нормально работающем оборудовании профилактику достаточно делать 1-2 раза в год, приезжая с пылесосом и мокрой тряпкой. Для отвода кабелей (силовых, компьютерной сети и т. и.) в шкафу можно сделать несколько отверстий и установить специализированные вводы кабелей с защитой от пыли. Также неплохо иногда проверять температуру внутри сервера (многие серверные материнские платы позволяют делать это удаленно), чтобы «отловить» момент, когда вентилятор шкафа перестает работать.
Рис. 10.1. Пример ящика под оборудование
Обратите внимание, что размер ящика под оборудование зависит от планируемого количества устройств, которые будут там установлены. Например, если применяется шкаф, показанный на рис. 10.1, то на нижнюю полку можно поставить серверы (так получалось разместить до двух небольших серверов), а на верхнюю — небольшие источники бесперебойного питания и другое некрупногабаритное сетевое оборудование (концентраторы и т. п.). В этом варианте компоновки предполагается, что монитор будет стоять на самом ящике. Если количество серверов в ящике будут больше 1, то рекомендую приобрести переключатель «мони- тор-клавиатура-мышь» на 2 или 4 порта. Это позволит управлять серверами, не
открывая сам ящик — просто переключаясь на нужный порт. Как правило, если принято решение размещать оборудование в подобной мебели, то предполагав» ся, что оно будет обслуживаться довольно редко. Тогда, как уже было отмечен^ необходимо монтировать выдувной вентилятор (а лучше 2 — были случаи, «^ гда вентилятор выходил из строя и температура в ящике достигала критичного, максимума) и накрывать монитор полиэтиленовым мешком (обычно новые мон^ч торы поставляются уже в таких упаковочных мешках). Это некоторой степе^^ будет способствовать борьбе с пылью. Отмечу, что не всегда размещение монито») ра на самом ящике будет удачным решением — на практике автор сталкивало^-: с ситуациями, когда не следовало привлекать внимание к факту, что на объе^^ есть иное компьютерное оборудование, за исключением офисных ПК. В так^! случае можно приобрести аналогичный ящик просто больших размеров. ■ -^
Технологии виртуальных частных сетей <1
Автор не ставил задачей в полном объеме осветить все теоретические вопросы организации виртуальных частных сетей, для этого вам достаточно просмотреть^ архив соответствующих публикаций по сетевой тематике. Самое интересное, ни мой взгляд, это «спуститься» на сетевой уровень и взглянуть на примеры реаль-Я ных перехватов трафика. Тогда такие вопросы, что же на самом деле представая ляет собой туннель, не будут вызвать недопонимания — многие нюансы стануЯ полностью ясны. Отмечу, что в этой главе рассматривается только протокол РРТЙ хотя в последнее время все больше говорят об IPSec. Последний считается боле® надежным и современным, хотя на взгляд автора этот протокол гораздо более сложен в реализации, чем протокол РРТР.-^
Технически реализация защищенных виртуальных сетей стала возможно^ уже достаточно давно. Инкапсуляция использовалась раньше и применяется се^ час для передачи немаршрутизируемого трафика через маршрутизируемые сет$^ а также для ограничения многопротокольного трафика одним протоколом. Т^ нологии шифрования также появились задолго до широкого внедрения глобаЛ^ ных сетевых технологий. Однако общепринятые протоколы для создания защй^ щенных виртуальных сетей разработаны недавно и сейчас продолжается рабо’Г^ над их совершенствованием и расширением. Они являются открытыми или, ин$Й ми словами, свободными для распространения и реализации.М
Для независимости от прикладных протоколов и приложений защищенн^ виртуальные сети формируются на одном из более низких (по сравнению с пр кладным) уровней модели OSI — канальном, сетевом или сеансовом.
(второму) уровню соответствуют такие протоколы, как РРТР (о нем, собствен^ и пойдет речь в этой главе), L2F (Layer-2 Forwarding — предлагался кож нией Cisco Systems и рядом других производителей) и L2TP (Layer-2 Tunnel Protocol — протокол туннелирования 2-го уровня; был предложен как komi миссное решение между двумя первыми предложениями); сетевому (д уровню — IPSec (IP Security — безопасный протокол IP; в последнее получает все большую популярность в связи с увеличением количества оор
г
дования и программного обеспечения, его поддерживающего), а сеансовому (пятому) уровню — SSL/TLS и SOCKS.
Чем ниже уровень эталонной модели, на котором реализуется защита, тем она прозрачнее для приложений и незаметнее для пользователей. Однако при снижении этого уровня уменьшается набор реализуемых услуг безопасности и становится сложнее организация управления. Чем выше защитный уровень в соответствии с моделью OSI, тем шире набор услуг безопасности, надежнее контроль доступа и проще конфигурирование системы защиты. Однако в этом случае усиливается зависимость от используемых протоколов обмена и приложений.
Для стандартного формирования криптозащищенных туннелей на канальном уровне модели OSI компанией Microsoft при поддержке компаний Ascend Communications, 3Com/Primary Access, ECI-Telematics и US Robotics был разработан протокол туннелирования PPTP, представляющий собой расширение протокола PPP (Point-to-Point Protocol — протокол связи «точка-точка»), В протоколе РРТР не специфицируются конкретные методы аутентификации и шифрования передаваемых данных. Клиенты удаленного доступа в операционных системах Windows NT 4.0 и Windows 98 (с компонентом Dial-Up Networking) поставляются с версией шифрования DES компании RSA Data Security, получившей название «шифрование Microsoft для канала "точка-точка"» (Microsoft Point-to-Point . Encryption — МРРЕ).
■ Канальному (второму) уровню модели OSI соответствует также протокол туннелирования L2F (Layer-2 Forwarding), разработанный компанией Cisco 1 Systems при поддержке компаний Shiva и Northern Telecom. В данном протоколе также не специфицируются конкретные методы аутентификации и шифрования. В отличие от протокола РРТР протокол L2F позволяет использовать для удаленного доступа к провайдеру не только протокол РРР, но и другие протоколы, например SLIP (на настоящее время устарел и практически не встречается). При формировании защищенных каналов по глобальной сети поставщикам услуг Интернета не нужно выполнять конфигурирование адресов и аутенти- ' фикацию. Кроме того, для переноса данных через защищенный туннель мо- 1 гут использоваться различные протоколы сетевого уровня, а не только IP, как в протоколе РРТР.
. Протоколы РРТР и L2F были представлены в организацию Internet Engineering 1 Task Force (IETF) и в 1996 году соответствующие комитеты решили их объединить. Получившийся в результате протокол, вобравший в себя все лучшее из РРТР и L2F, был назван протоколом туннелирования второго уровня (Layer-2 Tunneling Protocol — L2TP). Его поддерживают компании Cisco Systems, Microsoft, ЗСош, Ascend и многие другие производители оборудования и программ. Как и предшествующие протоколы канального уровня, спецификация L2TP не описывает методы аутентификации и шифрования. Протокол L2TP является Расширением РРР на канальном уровне и может поддерживать любые высоко' Уровневые протоколы.
■ Спецификацией, где описаны стандартные методы для всех компонентов и ■ Функций защищенных виртуальных сетей, является протокол Internet Protocol К Security (IPSec), соответствующий сетевому уровню модели OSI и входящий в соК став новой версии протокола IP — IPv6. Протокол IPSec иногда еще называют
протоколом туннелирования третьего уровня (Layer-3 Tunneling). IPSec преивЗ сматривает стандартные методы аутентификации пользователей или Компьютерра при инициализации туннеля, стандартные способы шифрования конечными тр*д ками туннеля, формирования и проверки цифровой подписи, а также типоад^ методы обмена и управления криптографическими ключами между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнении каждой задачи. Выбранные средства для достижения одной цели обычно не за? j висят от методов реализации других задач. Для функций аутентификации TP§^ поддерживает цифровые сертификаты популярного стандарта Х.509.'
Практика подключения объекта
Очевидно, что первым этапом создания виртуальной частной сети являет/ подключение объекта (или нескольких объектов) к сети Интернет. При этом риантов подключения имеется множество. Остановимся на одном из ретпенД которое предлагает при небольших затратах обеспечить относительно высока скорости — технологии ADSL. Само подключение по технологии ADSL о _ , ствляется с помощью провайдера услуг сети Интернет, который имеет д^щуда вание па ближайшей к объекту АТС. Физически подключение сводится к дам шагам (рассмотрим на практическом примере подключения одного из объектов) ,- формированию прямого провода от объекта до кросс-узла указанной пров ром АТС и последующей проверке этого провода на качество с помощь ра. Следует отметить, что технология ADSL может работать и по медно к которой, подключаются обычные городские телефоны (кстати, именно т решение наиболее распространено). Отдельное формирование прямого пров^ для работы технологии ADSL может быть оправдано, если, например, ваш те| фон параллельно используется для сигнализации во вневедомственную охрйД или установлено оборудование уплотнения.
Здесь специалисты провайдера гарантировали, что их оборудование AD компании Siemens будет вполне стабильно работать при величине сопротивл^ ния провода до одного килоома. После этого приехал специалист от прова и поставил модем ADSL. Модем имел два порта — один порт RJ12.^ ключения в линию, а второй, RJ45 — порт Ethernet для соединения с лок сетью. Этот порт напрямую включался во внешний интерфейс защитного экра с помощью так называемого кросс-кабеля, причем этот кабель был предоставл провайдером. В нашем случае модем выполнял еще и роль маршрутиз^ умолчанию, па который должен передаваться весь трафик. Поэтому ему, своей IP-адрес. Причем адрес назначался провайдером и настраивался ме специалистами его службы технической поддержки. Скорость передачка каналу ADSL составляла 64 Кбит/с в локальную сеть (направление «к ту») и 16 Кбит/с в сеть Интернет (направление «от клиента»). Как видим, ас хронность этой технологии очевидна — пользователь получает информ из сети Интернет в большем объеме, чем передает, и по этой причине скора к нему больше, чем от него. Это правило очевидно, когда некая локальна^, просто подключается к Интернету и не подразумевается наличие туннеля ^
гой удаленной сетью. В таком варианте характер распределения трафика может быть кардинально другим — все зависит от используемых приложений.
Естественно, что как только было выполнено подключение объекта к сети Интернет, сразу появилась необходимость в установке защитного экрана (в принципе, можно обойтись и без защитного экрана, если, например, на удаленном объекте работает только один компьютер). Причем важно отметить, что защитный экран должен иметь либо встроенную поддержку организации сетей VPN, либо просто иметь возможность поддерживать необходимые протоколы. В нашем случае для организации VPN используется протокол РРТР компании Microsoft. В качестве защитного экрана тестировался продукт Kerio WinRoute Pro (более подробную информацию о котором можно получить по адресу www.kerio.com), который без проблем поддерживает протокол РРТР. Но на момент подготовки материала главы было одно ограничение — нельзя было создавать туннель с того же сервера, на котором работал продукт WinRoute Pro, из-за особенностей реализации последнего. Если же в сети присутствует другой защитный экран, который обеспечивает создание туннеля прямо с него (то есть он должен быть конечной точкой туннеля), то такое решение является еще более привлекательным. В рассматриваемом примере полагаем, что сеть защищается отдельным защитным экраном (это, разумеется, может быть как программное решение, так и специализированное устройство, например Cisco PIX Firewall), а для организации виртуальной частной сети используется сервер VPN, находящийся внутри защищаемой сети (рис. 10.2).
Защитный Сервер VPN экран
Рис. 10.2. Пример подключения объекта к сети Интернет
Существующие методы и подходы по защите сетей от несанкционированного доступа подробно описаны в большом количестве источников. По этой причине подробно на общих подходах останавливаться нет необходимости. Следует отметить только, что, на взгляд автора, самый «навороченный» защитный экран не обязательно будет работать лучше, чем простое и дешевое решение. Кроме того, опыт проведения работ по защите сети показал, что чем понятнее внутренняя логика работы защитного экрана, тем, в конечном счете, защита оказывается крепче. В конце концов, настройку экрана выполняет специалист, который должен Досконально разбираться в вопросах его функционирования. Автор пробовал работать с программными продуктами NetGuard Guardian Pro 5.0х, Microsoft ISA Server и Kerio WinRoute Pro. Под термином «работать» имеется в виду непо-
средственная эксплуатация этих продуктов в сети в течение определенного вре7 мени. Несмотря на то что все протестированные продукты функционировали великолепно и нареканий не вызывали, больше всего симпатий вызвал продукт Kerio WinRoute Pro (на момент написания главы предлагалась версия 4.2.2, кото
рая, кстати, поставляется па различных языках, включая русский). Такое отношение проистекает из-за прозрачной и понятной логики его работы. Сам продукт умещается на дискету, интуитивно понятен в использовании и очень произво- ' дителен. И именно на этом продукте я и остановился. Естественно, есть у него ’ и определенные недостатки. На взгляд автора, самым серьезным можно считать ■ отсутствие удобных средств для анализа журналов работы пользователей. Иногда , наличие таких средств просто необходимо. Например, если в компании прово- . дится политика, согласно которой за потребление ресурсов сети Интернет раздельно платят разные отделы компании в соответствующей пропорции. Такая . •; политика начинает работать, когда объем потребляемой информации превыша- .. ет какой-то минимум, а в компании есть несколько отделов, в разной степени пользующихся ресурсами сети Интернет.
Продолжая разговор о продукте Kerio WinRoute Pro, хочется отметить и другую проблему, связанную с построением виртуальных сетей на базе операционной системы Microsoft Windows 2000. Учитывая, что защитный экран размещается на границе сети, вполне понятно желание на его основе построить и туннели f VPN с удаленными объектами, а точнее с аналогичными защитными экранами.
В случае Microsoft ISA Server это возможно и более того, есть мастер (wizard), ' который поэтапно и с подсказками поможет это сделать. Но при использовании продукта Kerio WinRoute Pro в качестве защитного экрана такое решение не i представляется невозможным, по крайней мере, в обсуждаемой версии — 4.2.2. „i
В версии 4.2.4 появилась поддержка транзитного трафика IPSec. Этот факт ■
прояснился после отправки запроса в службу технической поддержки. Как оказа- ) лось, существует конфликт между службой RRAS и Kerio WinRoute Pro (точнее j с возможностью dial-on-dcmand службы RRAS). По этой причине и было пред- л ложено устанавливать серверы VPN за защитным экраном. Последнее решение '
было протестировано и доказало свою полную работоспособность. К слову, тех- ., ническая поддержка пользователей вызывает только восхищение — по меньшей V
мере ни один из моих вопросов, отправленных в службу технической поддерЖ- '.
ки, не остался без внимания. Так, например, по ходу тестирования этого защит-^
ного экрана было выявлено его странное поведение в случае, если объем прохо- J
дящих через него небольших дейтаграмм протокола UDP достигал некоторого.':! порогового значения. Это, кстати, вполне нормальная ситуация для большинст--'
ва компьютерных игр, предлагаемых на серверах в сети Интернет (в частностй' Counter-Strike). Так вот, после отправки запроса в службу технической поддерж-г
ки с описанием проблемы ответ пришел на следующий день с четким указанием1; как и что нужно делать.
Одним из возможных вариантов расширения функциональности защитного экрана может быть установка на сервере программного продукта Microsoft ISA:
Server, который настроен только на выполнения кэширования запросов к сай-
там (один из вариантов установки — в другом режиме он будет сам работать каг защитный экран). Этот компонент помогает решить две задачи — контроль до*
ступа и ускорение доступа к сайтам Интернета за счет хранения последних загруженных страниц в памяти и дисковом кэше.
Контроль доступа достигается следующим образом. Сервер, выполняющий роль защитного экрана, включается в домен (хотя это и может противоречить основным рекомендациям по организации защитных экранов), а затем при настройке сервера Microsoft ISA Server указывается, что запросы могут проходить только от определенной группы пользователей домена (например, домена Windows 2000 Active Directory). Далее, пользователи указывают в настройках своих браузеров (например, Internet Explorer), что следует работать через прокси-сервер (proxy server, часто также встречается термин сервер-посредник), и указывают номер порта (по умолчанию для сервера Microsoft ISA Server номер порта — 8080). Впоследствии все запросы на просмотр страниц будут перенаправляться прокси-серверу, который либо вернет данные из кэша, либо самостоятельно получит их из сети Интернет. Для пользователей подобная схема работы абсолютно прозрачна. И после всего на защитном экране настраиваются правила фильтрации, в соответствии с которыми запрос протокола TCP на порт назначения с номером 80 (протокол HTTP) могут проходить только от прокси-сервера, который работает на самом защитном экране или на отделено стоящем сервере.
Прозрачность для пользователей достигается тем, что при отправке запроса на доступ к определенной HTML-странице на выбранном сайте браузер в ответ на запрос получает от настроенного на нем прокси-сервера информацию о том, что требуется аутентификация. После того как прокси-сервер проверил права пользователя и убедился в том, что последнему позволено воспользоваться его услугами, он начинает работать как бы за него, отправляя приходящие от клиента запросы HTTP в сеть Интернет. Безусловно, подобная организация доступа в сеть Интернет позволит контролировать доступ только.для протоколов HTTP и FTP, которые являются наиболее популярными у пользователей. Для других протоколов в рассматриваемой схеме контроль невозможен, и если он необходим, то администратору придется ориентироваться исключительно на адреса IP. Основным преимуществом программного продукта Microsoft ISA Server является возможность проверять принадлежность пользователя к определенной группе перед тем, как отправить его запрос в сеть Интернет. Причем параллельно ведется полный журнал работы, что позволит далее выполнять аналитический разбор трафика.
Кроме установки перечисленных программных продуктов на защитный экран, можно порекомендовать обратить внимание на средства, контролирующие задачи, которые пользователи выполняют, работая в сети Интернет. В частности, довольно полезной является возможность проводить классификацию сайтов, посещаемых пользователем, с последующей генерацией отчетов посещений. Автор тестировал продукт компании SurfControl (http://www.suRFControl.com), который интегрируется с Microsoft ISA Server. Компания SurfControl выпускает несколько версий своего продукта для работы с разными защитными экранами (в частности есть версия для Checkpoint Firewall-1). В общем случае схема настройки защитного экрана очень проста — вслед за установкой операционной системы Windows 2000 Server устанавливается продукт ISA Server, а затем SuperScoute for ISA Server. Далее все запросы пользователей, проходящие через прокси-сервер,
минуют так называемый подключаемый модуль (plug-in) системы SuperScoute и автоматически причисляются к той или иной категории. Для этого ведется специальный файл (формат Microsoft Access), на основе которого затем можно получать очень удобные отчеты. Кроме того, к несомненным достоинствам панно-, го продукта следует отнести возможность создания групп пользователей с даль-^ нейшей генерацией отчетов по созданным группам. Например, руководство для, минимизации затрат имеет право поинтересоваться, сколько времени провели в Интернете отдельные пользователи и какой объем трафика (за который, как, правило, приходиться платить) был получен из сети Интернет разными отдела-) ми. Кроме того, довольно интересна возможность классифицировать посещаемые пользователями сайты по разным категориям, например, таким как «сайтц, для взрослых», «развлечения», «спорт» и т. п. Дополнительно с продуктом поя ставляется большая база уже классифицированных сайтов, доступная для o6hqb% ления, а также можно воспользоваться другим продуктом, который самостоятель-^ но пытается приписать неизвестные сайты к той или иной категории (на основе анализа набора ключевых слов в ответах протокола HTTP — правда, с русски^ языком могут быть проблемы).
Шаги настройки защитного экрана, если были выбраны описанные продук?-, ты, следующие. Сначала на компьютер под управлением Windows 2000 Server устанавливается Microsoft ISA Server 2000. При его установке указывается ре-, жим «только кэшировать» (cache-only — в этом режиме отключается функциот.-, нальность защитного экрана программного продукта Microsoft ISA Server 200Q, и он будет работать только как сервер-посредник для запросов протоколов НТТ-^ и FTP). Это важно, так как сам продукт имеет функциональность защитного э^ рана и его можно использовать, если администратор не выбрал другой продув В противном случае, во избежание проблем несовместимости между двумя за?; щитными экранами, следует устанавливать продукт с функциональностью серией ра-посредника. Далее, если необходимо, можно установить программное обеспе-* чение учета работы пользователей в сети Интернет, а затем прикрыть все сверху защитным экраном (скажем, Kerio WinRoute Pro). Отметим, что подобная с^® ма установки была проверена только для защитного экрана Kerio WinRoute Рп$ и при использовании других решений она может претерпеть изменения. ■ -tn, Если для построения виртуальной частной сети был сделан выбор в пользой решения РРТР от компании Microsoft, то на удаленном объекте может потребой ваться установить сервер, который будет выполнять задачи шифрации и дешифра- ■ ции трафика (далее по тексту он будет называться сервером VPN). Опыт показа^ что сервер в состоянии выполнять более широкие функции, чем просто обслужив вание туннеля РРТР. Так, он может быть контроллером домена Active DirectpSM- сервером почты Microsoft Exchange 2000, сервером баз данных Microsoft SQ1"1 а также поддерживать другие, менее ресурсоемкие службы, такие как DNS, DHC и т. п. Учитывая, что количество пользователей на удаленном объекте, как прав ло, невелико (обычно порядка 10-15), то один сервер вполне справится с указ! ной нагрузкой. Можно посоветовать в этой ситуации устанавливать память, компьютер-сервер 512 Мбайт и больше, так как при решении на сервере так' количества задач резко повышаются требования к памяти, в то время как про? сор занят незначительно: на 7-15%. Кроме перечисленных задач сервер моз
гг389389Основные принципы работы протокола РРТР
г
г
389
389
Рис. 10.3. Туннель между двумя объектами (трафик шифруется)Рис. 10.3. Туннель между двумя объектами (трафик шифруется)взять на себя функции сервера VPN, и для этих целей на нем должна быть запушена служба RRAS (Routing and Remote Access — маршрутизация и удаленный доступ), входящая в состав операционной системы Windows 2000 Server. Служба позволяет выполнять множество важных задач, таких как маршрутизация трафика между интерфейсами, поддержка протоколов динамической маршрутизации (например, RIP), поддержка организации виртуальных частных сетей и т. п.
Рис. 10.3. Туннель между двумя объектами (трафик шифруется)
Рис. 10.3. Туннель между двумя объектами (трафик шифруется)
На рис. 10.3 показан пример связи двух объектов через туннель, «проложенный» по сети Интернет. Это пример типовой, и само собой, в конкретных реализациях ожидаемы изменения в приведенной схеме. Видно, что на каждом из объектов присутствует защитный экран (программное или аппаратное решение) и сервер VPN. Как уже было отмечено ранее, защитный экран должен поддерживать протокол РРТР — в рассматриваемом случае он просто обеспечивает прохождение IP-дейтаграмм, содержащих зашифрованные данные (или, иными словами, дейтаграмм, передаваемых по туннелю РРТР). Непосредственно процедуру шифрования и дешифрования данных выполняют серверы VPN, и для прочих пользователей в сетях это происходит абсолютно прозрачно. В идеале, после настройки туннеля эти две сети можно рассматривать как неразрывную сущность, части которой просто находятся на расстоянии двух переходов (hop) друг от друга (как будет показано далее, серверы VPN будут здесь играть роль маршрутизаторов с виртуальными интерфейсами РРТР). Для объектов на концах соединения вся промежуточная сеть Интернет будет как бы скрыта.
Основные принципы работы протокола РРТР
Виртуальная частная сеть, в основе которой лежит протокол РРТР, представляет собой простой канал связи между двумя серверами, которые просто выполняют шифрование данных при передаче их в туннель и дешифрование при получении данных из туннеля и передаче их в локальную сеть. Процедура настройки туннеля между двумя серверами не вызывает сложностей и требует выполнения
3-4 шагов. Проще может быть только настройка удаленного клиента на подклад, чение к серверу через туннель. Для того чтобы два сервера могли установить между собой туннель, необходимо сначала настроить и запустить на них службу RRAS. При первом запуске этой службы предлагается воспользоваться услугами мастера, но как показала практика, настраивать лучше все самостоятельно как будет показано ниже.г
Сам по себе туннель РРТР является двусторонним — то есть каждый сервер самостоятельно устанавливает соединение с удаленным партнером, и только когда оба сервера выполнили эту процедуру, туннель считается рабочим. При настройке туннеля на каждом сервере необходимо указать имя и пароль пользователя, которые затем проверяются на другом конце соединения. Учитывая то, ч®о . все серверы могут входить в один домен, следует рекомендовать создать отдельную учетную запись в домене для каждого из них, которая затем и будет использо- ' ваться обоими серверами. Такой подход позволит легко управлять отдельными туннелями и получать статистику их работы — служба RRAS способна вести , учет (журнал) работы указанного удаленным сервером пользователя при установ-; лении туннеля. Пароль желательно выбрать сложно предсказуемым (например, генератором паролей), а помнить его не обязательно — единожды настроенные параметры соединения на интерфейсе DOD (Dial-on-Demand — «дозвон» по требованию) запоминаются сервером и используются автоматически в случае восста-;( новления туннеля после проявления проблем со связью. Важным компоненте^ туннеля является виртуальный интерфейс DOD, который администратор должен) настроить на двух серверах-партнерах по туннелю (учитывая то, что интерфейс;1 DOD может обслуживать не только туннель виртуальной частной сети, а такжец например, интерфейс с подключенным аналоговым модемом для автоматическое го установления соединения, далее в главе будет употребляться термин «DG^>
VPN», подчеркивающий то, что речь идет именно о туннеле).
В принципе, настройка интерфейса DOD VPN и подразумевает под собой ^ стройку туннеля. Впоследствии DOD VPN будет фигурировать на сервере (в час®* ности, в консоли службы RRAS) как обычный интерфейс, который может уч#* вовать в передаче и получении данных, а также в маршрутизации. Естествен# таких интерфейсов на сервере VPN может быть более одного, в зависимой^ от того, сколько туннелей сервер поддерживает. Например, на рис. 10.4 показа! пример консоли службы RRAS, на которой настроено 10 интерфейсов О^ VPN, каждый из которых обслуживает свой туннель. Процедура настройки бу^ в деталях показана далее в главе, а пока отметим, что для удобства админист рирования есть возможность гибко назначать имена интерфейсам. В привел ном на рисунке примере каждое имя (L138, SH4 и т. п.) соответствует выб ной схеме именования удаленных объектов (например, по адресу в городе по кругу задач).
После того как были созданы интерфейсы DOD VPN на серверах-партн< по туннелю, а между последними установлено соединение, их можно рассма вать как обычные маршрутизаторы, несмотря на то, что физически каЖ по-прежнему будет иметь один сетевой интерфейс (в принципе, сервер мс быть оснащен и несколькими физическими сетевыми интерфейсами). Од!
огромное удобство организации туннеля средствами Microsoft RRAS как раз в том, что он позволяет маршрутизировать трафик между физическими интерфейсами и интерфейсами DOD VPN, которые в нашем случае являются логическими (виртуальными) интерфейсами.
Д Routing and Remote Access
ij Дсбрп View |^ 4» * [ ©1Щ 0 E§> S
Treej
Routing and Remote Access
Server Status/
Й- Й BOBCAT (local)J
LAM snd Demand CaaUr#ert‘ace$:
Ф&Щк-м
i Connection Sts
^1138
#SH4
Demand-dial Demand-dial
Disabled Enabled
Unreachable i
Connected i
Interfaces
^GRDIOS
Demand-dial
Enabled
Connected i
: -^ Remote Access Clients (9) i
$?RCV37
Demand-dial
Enabled
Connected i
S Portsi
§?R3
Demand-dial
Enabled
Connected i
$ “Л IP Routing:^
?^M207
Demand-dial
Enabled
Connected ■
Ф ^ Remote Access Policies $
^ENG29
Demand-dial
Enabled
Connected =
Ф-Sa Remote Access Logging $
Local Area Connection
Dedicated
Enabled
Connected ;
^mz30
Demand-dial
Enabled
Connected *
^N175
Demand-dial
Enabled
Connected ?
^LIGSO
Demand-dial
Enabled
Connected •
^Internal
Internal
Enabled
Connected ?
■^ Loopback
Loopback
Enabled
Connected :
<1 'hl
«1
J '
Рис. 10.4. Пример настроенных интерфейсов DOD VPN
Протокол РРТР для своей работы создает логическое соединение протокола TCP между двумя серверами-партнерами (или клиентом и сервером, если, например, в сеть пытается получить доступ мобильный клиент с переносным компьютером), участвующими в процессе создания туннеля. Первоначально в этом соединении номер порта получателя протокола TCP устанавливался в значение 5678, но позже он был изменен на 1723. Этот номер и используется в настоящее время (официально зарегистрирован в IANA). В терминологии протокола это соединение называется управляющим (Control Connection). Однако это только «рельсы» туннеля, отвечающие за служебные функции, в то время как для передачи самих данных используются протоколы РРР и GRE (Generic Routing Encapsulation — общая инкапсуляция при маршрутизации). Само по себе управляющее соединение поддерживается с помощью сообщений keepalive («пока живой»), посылаемых серверами, и такой подход позволяет быстро отслеживать перебои в связи. Туннель (то есть дейтаграммы, передающие предварительно зашифрованные данные) и управляющее соединение неотъемлемы друг от друга и совокупно формируют то, что называется туннелем РРТР между двумя объектами (или серверами на объектах).
Для лучшего понимания протокола GRE (документы RFC 1701 и RFC 1702) и его роли в создании и поддержании работы туннеля полезно рассмотреть структуру пакета этого протокола. (Тут может возникнуть некая путаница, так как название GRE не несет в себе термин «протокол», но указанные стандарты
392392Г лава 10. Построение виртуальных частных сетейуя 11
392
392
ооРис. 10.5. Формат инкапсуляции дейтаграмм IPРис. 10.5. Формат инкапсуляции дейтаграмм IPопределяют помимо всего прочего заголовок пакета и метод инкапсуляции данных в него. То есть можно с уверенностью говорить «протокол GRE».) Сам протокол был разработан как удобный способ решения общих задач инкапсуляций данных, посылаемых через сеть IP (то есть сфера его применения не ограничена только туннелем РРТР). После того как управляющий сеанс протокола РРТР был установлен (он, как будет показано далее, организуется в первую очередь при установлении туннеля), протокол GRE используется при инкапсуляции данных для последующего шифрования. Формат пакета протокола GRE показан на рис. 10.5.
о
о
Рис. 10.5. Формат инкапсуляции дейтаграмм IP
Рис. 10.5. Формат инкапсуляции дейтаграмм IP
Данные, которые должны пройти через туннель (исходная дейтаграмма, от-- ; правляемая через интерфейс DOD VPN) снабжаются заголовком протокола PPP-' (напомним, что протокол РРТР — это расширение протокола РРР, и поэтому* >"j заголовок этого протокола добавляется к результирующей дейтаграмме), а за-. • тем помещаются внутрь пакета GRE, который потом переносится между двумя*/ точками виртуальной сети (или между двумя серверами) внутри новой дейта— граммы IP. После того как пакет GRE достиг противоположной точки виртут.?.; альной сети, его заголовок удаляется и упакованная дейтаграмма отправляется ( ее изначальному получателю. Фактически, сервер VPN, получая исходную де&*-; таграмму, создает еще одну — новую, в которую инкапсулируется исходная. Прв^-- токол GRE не имеет возможности устанавливать сеансы и обеспечивать защитит данных от злоумышленников. Для этого эксплуатируется способность РРТР соз-л) давать управляющее соединение. Применение GRE в качестве метода инкапсу-^; ляции ограничивает поле действия РРТР только сетями IP.■’<'
Заголовок протокола GRE содержит информацию о подтверждениях и ноМёд) рах в последовательности, предназначенную для того, чтобы обеспечить некий? уровень контроля перегрузок и обнаружения ошибок в туннеле, ^роме тоМ*. управляющее соединение используется для определения скорости отправки и п^. раметров буферизации для контроля потока пакетов РРР определенного сеансам Сам протокол РРТР не предлагает конкретных алгоритмов для контроля переё грузок и протокола, но в стандартах можно найти рекомендованные методы опрег деления адаптивных тайм-аутов для восстановления потерянных данных.
Рисунок 10.5 показывает общую, теоретическую схему инкапсуляции дани] но для понимания деталей работы туннеля необходимо рассмотреть происходя процессы на сетевом уровне с помощью иллюстрации перехваченных в сети П тов. На сетевом уровне новая дейтаграмма, передаваемая по туннелю (и несу
в себе предварительно зашифрованную оригинальную дейтаграмму), выглядит, как показано на рис. 10.6. Видно, что в нее инкапсулирован пакет протокола GRE, а в него вложен пакет протокола РРР, за которым следуют зашифрованные данные (в рассматриваемом примере —165 байт, а размер всего кадра Ethernet составляет 216 байт). .
|4630 903.35.1242 193.125.203.1 1Ч2.1ЬН.1 ^Mi1Ы0ПМ PPI* run|4630 903.35.1242 193.125.203.1 1Ч2.1ЬН.1 ^Mi1Ы0ПМ PPI* run0 Frame 4030 (21В on wire, 216 captured)0 Frame 4030 (21В on wire, 216 captured)0 Ethernet 110 Internet Protocol, Src Addr: 193-125.203.1 (193.125.203.1), Dst Addr: 192.168.1.2530 Ethernet 110 Internet Protocol, Src Addr: 193-125.203.1 (193.125.203.1), Dst Addr: 192.168.1.2530 Generic Routing Encapsulation 0 Flags and version: 0x30810 Generic Routing Encapsulation 0 Flags and version: 0x3081(PPP)(PPP)0.0..1...1 .... 0000 1000 0...0010.0..1...1 .... 0000 1000 0...001= Mo= No= Mo= Nochecksum routingchecksum routing= Key= Sequence number= No strict source route= Recursion control: 0= Acknowledgment number= Flags: 0= Version: 1= Key= Sequence number= No strict source route= Recursion control: 0= Acknowledgment number= Flags: 0= Version: 1Protocol Type: PPP (0x880b)Pay load length: 166Call ID: 16384Sequence number: 1356Acknowledgement number: 954E Point-to-Point ProtocolProtocol: compressed packet (OxOOfd)Data (165 bytes)Protocol Type: PPP (0x880b)Pay load length: 166Call ID: 16384Sequence number: 1356Acknowledgement number: 954E Point-to-Point ProtocolProtocol: compressed packet (OxOOfd)Data (165 bytes)0000009027еО 04 1е 003048 21аа36 08 00 45 00»..0 HI.6..E.А001000са4f22 00 00 7с2f9f beС17d cb 01 сО а8..0".,|/ ...}....ПП9П,Л1ЧЛQ1 QQ ЛК ПЛфйлл ллллЛЛ ЛЬ . Л А. лл лл....л./}0000009027еО 04 1е 003048 21аа36 08 00 45 00»..0 HI.6..E.А001000са4f22 00 00 7с2f9f beС17d cb 01 сО а8..0".,|/ ...}....ПП9П,Л1ЧЛQ1 QQ ЛК ПЛфйлл ллллЛЛ ЛЬ . Л А. лл лл....л./}//Рис. 10.6. Формат дейтаграммы с зашифрованными даннымиРис. 10.6. Формат дейтаграммы с зашифрованными данными
|4630 903.35.1242 193.125.203.1 1Ч2.1ЬН.1 ^Mi1Ы0ПМ PPI* run
|4630 903.35.1242 193.125.203.1 1Ч2.1ЬН.1 ^Mi1Ы0ПМ PPI* run
0 Frame 4030 (21В on wire, 216 captured)
0 Frame 4030 (21В on wire, 216 captured)
0 Ethernet 11
0 Internet Protocol, Src Addr: 193-125.203.1 (193.125.203.1), Dst Addr: 192.168.1.253
0 Ethernet 11
0 Internet Protocol, Src Addr: 193-125.203.1 (193.125.203.1), Dst Addr: 192.168.1.253
0 Generic Routing Encapsulation 0 Flags and version: 0x3081
0 Generic Routing Encapsulation 0 Flags and version: 0x3081
(PPP)
(PPP)
0
.0
..1
...1
.... 0
000
1
000 0...
001
0
.0
..1
...1
.... 0
000
1
000 0...
001
= Mo
= No
= Mo
= No
checksum routing
checksum routing
= Key
= Sequence number
= No strict source route
= Recursion control: 0
= Acknowledgment number
= Flags: 0
= Version: 1
= Key
= Sequence number
= No strict source route
= Recursion control: 0
= Acknowledgment number
= Flags: 0
= Version: 1
Protocol Type: PPP (0x880b)
Pay load length: 166
Call ID: 16384
Sequence number: 1356
Acknowledgement number: 954
E Point-to-Point Protocol
Protocol: compressed packet (OxOOfd)
Data (165 bytes)
Protocol Type: PPP (0x880b)
Pay load length: 166
Call ID: 16384
Sequence number: 1356
Acknowledgement number: 954
E Point-to-Point Protocol
Protocol: compressed packet (OxOOfd)
Data (165 bytes)
0000
00
90
27
еО 04 1е 00
30
48 21
аа
36 08 00 45 00
»
..0 HI.6..E.
А
0010
00
са
4f
22 00 00 7с
2f
9f be
С1
7d cb 01 сО а8
..0".
,|/ ...}....
ПП9П
,Л1
ЧЛ
Q1 QQ ЛК ПЛ
фй
лл лл
лл
ЛЛ ЛЬ . Л А. лл лл....
л.
/}
0000
00
90
27
еО 04 1е 00
30
48 21
аа
36 08 00 45 00
»
..0 HI.6..E.
А
0010
00
са
4f
22 00 00 7с
2f
9f be
С1
7d cb 01 сО а8
..0".
,|/ ...}....
ПП9П
,Л1
ЧЛ
Q1 QQ ЛК ПЛ
фй
лл лл
лл
ЛЛ ЛЬ . Л А. лл лл....
л.
/}
/
/
Рис. 10.6. Формат дейтаграммы с зашифрованными данными
Рис. 10.6. Формат дейтаграммы с зашифрованными данными
В реализации протокола РРТР используется слегка измененная версия протокола GRE, которая была изначально описана в документах RFC 1701 и RFC 1702. Не останавливаясь на подробностях базовой реализации этого протокола, отмечу, что новшеством является поле Acknowledgement Number (номер подтверждения), которое используется для подтверждения, что определенный пакет (или группа пакетов) была успешно доставлена удаленному серверу по туннелю. Помимо этого поля, заголовок GRE включает в себя еще несколько полей, некоторые из которых не изменяются, а другие могут отличаться от пакета к пакету. Так, есть поле Call ID (идентификатор сеанса) которое позволяет отличать пакеты, принадлежащие определенному туннелю (или в терминологии стандарта протокола РРТР — сеанса) — ведь на одном сервере VPN могут поддерживаться множество туннелей с удаленными серверами. Поле Protocol Туре (тип протокола) всегда установлено в значение 0x880b, уто соответствует инкапсулированному протоколу РРР. Сам вложенный пакет протокола РРР содержит только два поля — Protocol (указывает на содержимое поля данных) и непосредственно
поле Data — данные. Последнее поле и объемлет предварительно зашифрова] ную исходную дейтаграмму.
Для того чтобы показать в деталях происходящее во мраке туннеля, рассмо рим следующую схему связи двух объектов (рис. 10.7). На каждом из объект есть защитный экран, реализованный на базе сервера, работающего под упр лением Microsoft Windows 2000 и программного продукта Kerio WinRoute J Серверы имеют по две сетевые карты, одна из которых включается во внутренн] сеть, а другая в сегмент, подключенный напрямую к сети Интернет. В кяжг, сети также присутствует сервер VPN, который будут заниматься шифрований и дешифрованием передаваемых данных. Далее, в каждой сети использую*! адреса из диапазонов 192.168.3.0/24 (объект 1) и 192.168.2.0/24 (объект 2). Д реса могут назначаться администратором или выделяться по протоколу DHQ В последнем случае серверы VPN способны выполнять и эту задачу, впроч- как и многие другие задачи (быть контроллером домена Active Directory, ц товым или SQL-сервером и т. п.). Опыт показал, что никаких ограничений функциональность нет, за исключением повышенных требований к аппарат му обеспечению. Сама процедура шифрования трафика занимает относитед] низкий процент процессорного времени (4-5%).
Объект 1Объект 2
Сервер VPNЗащитныйЗащитный Сервер V
192.168.3.252 экранэкран192.168.2^
192.168.3.254192.168.2.254• ’
Рис. 10.7. Пример построения сети VPN
Предположим, что каждый из клиентов в сети настроен на использова шлюза по умолчанию (Default gateway), который соответствует внутренн интерфейсу защитного экрана (то есть интерфейсу в локальную сеть). То же Cal относится и к серверам VPN — они, как правило, будут иметь некие статиче^ адреса протокола IP, но па них также должны быть настроены адреса шлюз умолчанию. На данном этапе будем считать, что туннель между двумя сер! ми VPN установлен и работает. Для демонстрации происходящего на сек уровне предположим, что некий хост на объекте 1 (адрес 192.168.3.39) выпол команду ping с адресом хоста на объекте 2 (команда ping 192.168.10.1, рис. 1 Учитывая то, что получатель дейтаграммы, содержащей запрос ICMP echo re< (протоколу ICMP посвящена глава 4), находится в сети, отличной от сети 01 вителя, дейтаграмма отправляется по адресу шлюза по умолчанию — 192.168.^ (внутренний интерфейс защитного экрана).
§943 1.503012 192.160.3.39 192.16B.iai ICMP Echo (рН1д)Г«ЧШ'41
0000
00 dO Ь7 а8 50 d2 00 dO
Ь7 ba bf
19 08 00 45 00
....РЕ.
I
пою
00 Зс Of 05 00 00 80 01
9d 43 с0
а8 03 27 сО а8
.<С...'..
0020
Оа 01 08 00 3b 5с 02 00
10 00 61
62 63 64 65 66
....;¥.. ..abcdef
I
0030
67 68 69 6а 6Ь 6с 6d бе
6f 70 71
72 73 74 75 76
ghijklmn opqrstuv
пплп
..77..Й1..Й?.^АЙ Й7
„ЙЯ ЙЦ
-*-***W*i«^^
-и»клг1е,Рог k j
X
Frame 943 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:d0:b7:ba:bf:19, Dst: 00:d0:b7:a8=50:d2
Internet Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.10.1 (192.168.10.1)
Internet Control Message Protocol
Рис. 10.8. Исходная дейтаграмма, содержащая запрос ICMP echo request
Защитный экран, получая дейтаграмму, принимает решение о том, как передавать ее дальше. Здесь основой для этого являются таблицы маршрутизации — ведь защитный экран в общем случае представляет собой маршрутизатор с расширенной поддержкой правил фильтрации и трансляции адресов. Так как в предлагаемой в качестве примера сетевой конфигурации существует отдельный сервер VPN, то защитный экран должен быть настроен на дальнейшую передачу поступившей дейтаграммы серверу VPN. Для этого можно воспользоваться статической маршрутизацией, или динамической (например с помощью протокола RIP). В рассматриваемом примере защитный экран должен иметь в своей таблице маршрутизации запись, говорящую о том, что «все дейтаграммы, напрдц^енцще в сеть 192.168.10^0/24, нужно перенаправлять по адресу 192.168.3.252 (адрес сервера VPN для объекта17». Обратите внимание, что защитный экран, получив от клиента первую дейтаграмму, перешлет ее и одновременно отправит клиенту ^общение ICMP re^regt (рис. 10.9), указывающее на то, что все последующие дейтаграммы для адреса 192.16ВТ(Г1 следует отправлять напрямую по адресу 192.168.3.252 (адрес сервера VPN), минуя защитный экран. Это позволит сократить задержки, которые вносятся лишним переходом (хоть он и находится в рамках одной локальной сети).
@944 1.508143 192.168.3.254 192.1603.39 ICWH<4lliMl
fFrame 944 (70 bytes on wire, 70 bytes captured)
If Ethernet II, Src: 00:d0:b7:a8:50:d2, Dst: OO:dO:b7:ba:bf:19
If Internet Protocol, Src Addr: 192.168.3.254 (192.168.3.254), Dst Addr: 192.168.3.39 (192. 168.3.39)
В Internet Control Message Protocol
-Type: 5 (Redirect)
-Code: 1 (Redirect for host)
-Checksum: OxeOfd (correct)
-Gateway address: 192.168.3.252
If Internet Protocol, Src Addr: 192.168.3.39 (192. 168.3.39), Dst Addr= 192. 168. 10.1 (192.168. 10. 1) E>Internet Control Message Protocol
Рис. 10.9. Сообщение о перенаправленииРис. 10.9. Сообщение о перенаправлении
Рис. 10.9. Сообщение о перенаправлении
Рис. 10.9. Сообщение о перенаправлении
Далее, на сервере VPN указано, что дейтаграммы с адресом получателя из сети 192.168.10.0/24 должны отправляться через созданный интерфейс DOD VPN '
(согласно правилу в таблице маршрутизации). Сервер получает дейтаграмму . анализирует адрес получателя, видит, что она направлена в известную ему сеть и начинает выполнять следующие действия (обобщенно). Дейтаграмма целиков ..шифруется и единым блоком помещается в новую дейтаграмму *с'нивЕПЙ"SSPo- ' ловком, в котором в качестве адреса получателя указывается внешний (зарегистрированный в сети Интернет) адрес сервера-партнера по сети VPN. После этого сервер проводит маршрутизацию полученной дейтаграмм*ьГзаново. Так как на сервере VPN указан шлюз по умолчанию, на который нужно отправлять
дейтаграммы для всех неизвестных адресов, то сервер отправляет ее шлюзу (защитному экрану), передающему ее дальше в сеть Интернет. Дейтаграмма «путе
шествует» по сети Интернет до тех пор, пока не поступит на внешний .и-нт^^Дц^д. защитного экрана на объекту 2, который по настроенным правилам ретранслирует
дейтаграмму серверу VPN, который, в свою очередь, распакует и расшифрует" исходную дейтаграмму. *"'
Л Теперь рассмотрим процесс в деталях. Дейтаграмма, направленная на объект 2
(и содержащая запрос ICMP echo request) поступает на физический сетевой интерфейс сервера VPN с адресом 192.168.3.252. На сервере к ней добавляется за-’
головок протокола РРР. Затем она целиком шифруется (вместе с добавленным заголовком протокола РРР) и инкапсулируется в пакет GRE. Далее к получившемуся пакету GRE добавляется новый заголовок протоколаД^ и вновь сформированная дейтаграмма отправляется через сеть Интернет по адресу удаленного, конца виртуального соединения. На обратном конце сервер выполняет обратную операцию — расшифровывает исходную дейтаграмму и отправляет ее к нужному получателю. Рисунок 10.10 показывает, как инкапсулированная дейтаграмма выглядит на сетевом уровне. На нем наглядно видны различные заголовки протоколов, которые добавляются к исходной дейтаграмме. 3
1^Ш1^ШSi 70Н I г HW 142 1ЬН 134 1Ч2.1ЫМ0 I >СЧ>«Ь|>(рШц) ггм№»
1^Ш
1^Ш
Frame 708 (107 bytes on wire, 107 bytes captured)
Ethernet II, Src: 00:d0:b7:a9:la:21, Dst: 00:d0:b7:aS:50:d2•
Internet Protocol, Src Addr: 182.168.3.252 (192. 168.3.252), Dst Addr: 193.125.203.24 (193.125.203.24)
Generic Routing Encapsulation (PPP)
Point-to-Point Protocol
Jatarset Protocol, Src Addr: 192.168.3.39 (192.168.3.39), Dst Addr: 192.168.10.1 (192.168.10.1)"
Internet Control Message Protocol
•Be i;№o" 10010 10020 1 0030 ■;|пплл•Be i;№o" 10010 10020 1 0030 ■;|пплл00 00 cb 0000 00 cb 00do м 18 00do м 18 00Ь74630ЗсЬ74630Зса8 0а0171а8 0а017150 0088 eb50 0088 ebd2 00 0b 00d2 00 0b 000080000000800000dO 2f 3d 7еdO 2f 3d 7еЬ7 аЗ 03 01Ь7 аЗ 03 01а9 2d е7 Зса9 2d е7 Зс1а сО 00 5d1а сО 00 5d21 а8 00 сО21 а8 00 сО08 03 05 aS08 03 05 aS00 fc 81 0300 fc 81 0345 cl 212745 cl 212700 7d 45 сО00 7d 45 сО=Я По П1 ns ПП 9л По П9 ПП If ПП RI R9 R4 ЙЛ ВЦ=Я По П1 ns ПП 9л По П9 ПП If ПП RI R9 R4 ЙЛ ВЦ•IF...., ..0....: ,.<q...'•IF...., ..0....: ,.<q...'..I..E.-}IE<]...’.oh^rl Q..I..E.-}IE<]...’.oh^rl Q
•Be i;№o" 10010 10020 1 0030 ■;|пплл
•Be i;№o" 10010 10020 1 0030 ■;|пплл
00 00 cb 00
00 00 cb 00
do м 18 00
do м 18 00
Ь7
46
30
Зс
Ь7
46
30
Зс
а8 0а
01
71
а8 0а
01
71
50 00
88 eb
50 00
88 eb
d2 00 0b 00
d2 00 0b 00
00
80
00
00
00
80
00
00
dO 2f 3d 7е
dO 2f 3d 7е
Ь7 аЗ 03 01
Ь7 аЗ 03 01
а9 2d е7 Зс
а9 2d е7 Зс
1а сО 00 5d
1а сО 00 5d
21 а8 00 сО
21 а8 00 сО
08 03 05 aS
08 03 05 aS
00 fc 81 03
00 fc 81 03
45 cl 21
27
45 cl 21
27
00 7d 45 сО
00 7d 45 сО
=Я По П1 ns ПП 9л По П9 ПП If ПП RI R9 R4 ЙЛ ВЦ
=Я По П1 ns ПП 9л По П9 ПП If ПП RI R9 R4 ЙЛ ВЦ
•IF...., ..0....: ,.<q...'
•IF...., ..0....: ,.<q...'
..I..E.
-}
IE
<]...’.
oh^rl Q
..I..E.
-}
IE
<]...’.
oh^rl Q
Рис. 10.10. Дейтаграмма в состоянии готовности к продвижению через Интернет
Учитывая то, что дейтаграмма была перехвачена в сети Ethernet, в ней пр® сутствует заголовок Ethernet II, далее следует стандартный заголовок дейтг граммы IP (сейчас МАС-адресами можно пренебречь). То есть до этого момегп на рисунке мы видим классическую дейтаграмму. Но вот далее, согласно теорг добавлены заголовки протоколов GRE и РРР, за которыми следует оригинф ная дейтаграмма (исходный запрос ICMP echo request), которую нужно бы
инкапсулировать и зашифровать (в этом примере туннель РРТР. был настроен, на работу без шифрации и сжатия данных — в противном случае результирующая дейтаграмма была бы не информативна).
Обратите внимание на адреса в новой дейтаграмме. Адрес отправителя 192.169. 3.252 (это сервер VPN на объекте 1), а адрес получателя — 193.125..203.24 — это * адрес внешнего интерфейса защитного экрана на объекте 2- Рассматриваемая" дейтаграмма была перехвачена на защитном экране объекта 1 — сервер VPN выполнил преобразование и вновь сформированную дейтаграмму отправил в сеть Интернет по адресу 193.125.203.24. А так как маршрут ему неизвестен, то дейтаграмма поступила по адресу шлюза по умолчанию или на внутренний интерфейс защитного экрана. Защитный экран отправляет дейтаграмму далее в дед^. Интернет, но предварительно выполняет .трансляцию адресов — заменяем .щщшрр дейтаграмме адрес отправителя с 192.168.3.252 на 193.125.203.1 (подставляет адрес своего внешнего интерфейса — работает функция трансляции адресов (NAT) — особенность защитного экрана Kerio WinRoute Pro) и пересчитывает цода^рц- трольной суммы. Кроме того, уменьшается на единицу поле "рте to live после прохождения через защитный экран (согласно теории, маршрутизаторы декрементируют это поле на 1 при передаче дейтаграммы — см. главу 2). В таком виде дейтаграмма и поступает в сеть Интернет. Предложенный пример скорее исключение из правил, так как для наглядности были принудительно отключены опции шифрования и сжатия данных. В результате анализатор протоколов смог расшифровать все инкапсулированные данные в новой дейтаграмме. В том случае, если бы содержимое сжималось или (и) шифровалось, эта же самая дейтаграмма была бы теоретически нечитаемой анализатором. В своем дальнейшем пути дейтаграмма, минуя промежуточные маршрутизаторы сети Интернет, поступит на внешний интерфейс защитного экрана на объекте 2, который перенаправит ее локальному серверу VPN. Сервер выполнит обратную процедуру — удалит заголовки протоколов IP, GRE и РРР, восстановит исходную дейтаграмму и отправит ее хосту с адресом 192.168.10.1 (это будет обычный запрос ping). Ответ пройдет аналогичную цепочку преобразований, пока не достигнет отправителя запроса.
Рассмотрим другой, более сложный пример сети, в которой три объекта связаны между собой через сеть Интернет с использованием протокола РРТР (рис. 10.11).
Здесь три объекта подключены к сети Интернет. Но если рассматривать картину с точки зрения пользователей, все три объекта связаны между собой и находятся ца расстоянии двух переходов друг от друга. Обратите внимание на то, что топология сети может отличаться от приведенной на рисунке, где туннели созданы в расчете на формирование логической схемы «звезда» с центром на объекте 1 (например, если он является центральным офисом компании). Здесь также можно было бы создать туннель между объектом 2 и объектом 3, а затем организовать туннель между последним и центральным офисом. В этом случае трафик между центральным офисом и объектом 3 имеет на своем пути один транзитный узел (то есть для конечных устройств количество переходов будет равно 3). Однако, учитывая, что, как правило, трафик чаще всего передается между Центральным офисом и удаленными площадками, выбранная топология туннелей оправдана. Но также обратите внимание, что чем больше туннелей создается, тем жестче цдд^з^^а.с^рвев_£. центральном офисе, который является одним из окончаний туннелеи(внашемсшЯк^объекте 1) и, естественно,
.<.<этот сервер будет критичным узлом в сети. Опыт показывает, что самый обыч1- •
.<
.<
ный сервер на платформе Intel Pentium II может без затруднений обслуживать схему, в которой один центральный офис и десять удаленных объектрд^аап, ны по вышеприведенной схеме.
Объект 1Объект 1Объект 2Объект 2Туннель РРТРТуннель РРТР193.125.203.33193.125.203.33192.168.10.254192.168.10.254Защитный экранЗащитный экранСервер VPN .192.168.10.253*Сервер VPN .192.168.10.253*Сервер VPN192.168.3.252Сервер VPN192.168.3.252193.125.203.1193.125.203.1Защитный экран 192.168.3.254Защитный экран 192.168.3.254ИнтернетИнтернет193.125.203.24193.125.203.24192.168.1.254192.168.1.254Объект 3Объект 3Рис. 10.11. Пример связи трех объектовРис. 10.11. Пример связи трех объектовЗащитный экранЗащитный экранСервер VPN192.168.1.253Сервер VPN192.168.1.253'Я'Я■ -Д'■ -Д'я;я;В предположении, что серверы помимо всего прочего выполняют роли маршрутизаторов, необходимо настроить и корректную маршрутизацию во всей сети Перед этим рекомендуется детально проработать адресную схему, благо что адм$^. нистратор волей задействовать целые сети (например, из диапазона 192.168.Х.Х/24), даже для небольших (по количеству компьютеров) удаленных точек вместо того^ чтобы заниматься выделением подсетей — помимо подсетей будет еще массЭр проблем, которые нужно будет решать, поэтому лучше облегчать себе жизнь ЙЗ^
Объект 1
Объект 1
Объект 2
Объект 2
Туннель РРТР
Туннель РРТР
193.125.203.33
193.125.203.33
192.168.10.254
192.168.10.254
Защитный экран
Защитный экран
Сервер VPN .
192.168.10.253*
Сервер VPN .
192.168.10.253*
Сервер VPN
192.168.3.252
Сервер VPN
192.168.3.252
193.125.203.1
193.125.203.1
Защитный экран 192.168.3.254
Защитный экран 192.168.3.254
Интернет
Интернет
193.125.203.24
193.125.203.24
192.168.1.254
192.168.1.254
Объект 3
Объект 3
Рис. 10.11. Пример связи трех объектов
Рис. 10.11. Пример связи трех объектов
Защитный экран
Защитный экран
Сервер VPN
192.168.1.253
Сервер VPN
192.168.1.253
'Я
'Я
■ -Д'
■ -Д'
я;
я;
самых первых шагах.
Напомним, что после создания интерфейса DOD VPN, он. мои^ жен) участвовать в деле маршрутизации. Рассмотрим еще раз схему маршрут^ зации (только более детально) и прохождения информаций из центрально^ офиса в объект 2 (один из внутренних клиентов вновь выполняет команду Р^ 192.168.10.1). До этого детализировался простой пример, когда туннель VPN.CB зывает только два объекта — теперь сделаем то же самое для более жизненнс
примера.
Предположим, что для всех клиентов на объекте 1 с помощью сервера DHCP выдается адрес шлюза по умолчанию 192.168.3.254 (разумеется, помимо другой адресной информации). После проверки адреса получателя (а он принадлежит сети 192.168.10.0 и маршрут клиенту не известен) дейтаграмма отправляется шлюзу по умолчанию — серверу, который выполняет роль защитного экрана сети центрального офиса. Дейтаграмма поступает на внутренний интерфейс и после этого принимается решение о том, куда ее послать далее. На защитном экране работают служба RRAS и протокол маршрутизации RIP (версия 2). Тут следует отметить, что вместо использования динамической маршрутизации вполне можно решить все задачи с помощью статических маршрутов, задаваемых «вручную». Рекомендации относительно выбора того или иного метода приводить сложно, так как каждый имеет свои плюсы и минусы. Отмечу только, что протокол RIP в состоянии помочь избежать проблем с маршрутами при изменении адресной схемы — он просто начнет рассылать информацию о новых сетях.
Защитный экран проверяет свою адресную таблицу (сейчас не будем акцентировать внимание на то, каким образом она была построена — статически или с помощью протокола динамической маршрутизации) и обнаруживает, что маршрут в сеть с адресом 192.168.10.0/24 знает сервер VPN и, соответственно,.«заворачивает» полученную дейтаграмму, направляя ее этому серверу. Последний получает ее и выполняет проверку таблицы маршрутизации. На этом сервере «заведен» статический маршрут, указывающий на то, что весь трафик, адресованный в искомую сеть, должен отправляться через интерфейс DOD VPN, связанный с сервером на объекте 2. На рис. 10.12 показан пример статического маршрута в сеть 192.168.10.0/24 — согласно этой записи все дейтаграммы, направляемые в данную сеть, должны отправляться через интерфейс pOD VPN с именем SH4 (интерфейс может именоваться по выбору администратора). ’
Д. Routing and Remote Access v Server Status.
Destination -/ .
j NetWork,mask.........
1 Gateway
i Interface. . .
$192.168.1.0
255.255.255.0
None
R31
й- И BOBCAT (local)
$192.168.2.0
255.255.255.0
None
ENG29
i-^ Routing InterFaces
$192.168.4.0
255.255.255.0
None
RCV37■
i- X Remote Access Clients (9)
$192.168.5.0
255.255,255.0
None
1138
r-j^ Portss
$192.168.6.0
255.255.255.0
None
GRD105<
Я X IP Routingp
i г $ Generalp
$192.168.7.0
255.255.255.0
None
изо?;
EI192.168.10.0
255.255.255.0
None
SH4II
$192.168.12.0
255.255.255,0
None
N175:
:г-Ж DHCP Relay Agent;=
:rip
: ■ SIG4PH
Ф-'^ Remote Access Policies i? S (^ Remote Access Logging i^
$192.168.13.0
255.255.255.0
None
LIG501
$192.168.15.0
255.255.255.0
None
MZ30;
<1
IfilBll
^.Routing and Remote Access№В
Tree |StahcRoutes
Рис. 10.12. Пример статической маршрутизации
Дейтаграмма проходит стадию шифрования и отправляется в сеть Интернет При этом адрес получателя устанавливается в адрес, присвоенный внешнему Я интерфейсу защитного экрана на объекте 2 (193.125.203.24 — адрес сервера-парт- J нера по туннелю указывается при его настройке). Роль защитного экрана в процес- 1 се маршрутизации минимальна — на нем настроены соответствующие правила д согласно которым трафик протокола РРТР (а точнее пакеты GRE и сегменты 1 TCP с портом назначения 1723) должен передаваться во внутреннюю сеть сер- j веру VPN. Этот сервер, получая дейтаграмму, расшифровывает ее и проверяет Л оригинальный заголовок для уточнения получателя. А получатель оригинальной- Л дейтаграммы имеет адрес 192.168.10.1 — сервер просто посылает ее по данному ч адресу. Ответ на запрос ping проходит всю описанную цепочку, но в обратном. 1
порядке. Можно посчитать, через сколько маршрутизаторов прошла одна дейта- ) грамма — через четыре. То есть правильнее сказать, что до сети 192.169.10.0 из: ' центрального офиса четыре перехода и первые два маршрутизатора, через кото- j рые прошла дейтаграмма, находятся в одной локальной сети (защитный экран и сервер VPN). К сожалению, помимо нагрузки на серверы VPN, нагрузка так ; же ложится и па защитные экраны — им нужно «заворачивать» дейтаграммы, * направленные в удаленные точки, связанные туннелями (отчасти помогает сообщение ICMP redirect — в результате количество переходов сокращается). ’
Не очень простая схема? Но если рассмотреть всю цепочку передачи одной' j дейтаграммы, то картина будет еще более запутанная. Ведь сейчас не было учтено, как именно передается зашифрованная дейтаграмма от сервера VPN на объ- г екте 1. Было сказано «отправляется по туннелю», но на практике добавляются 1 еще задачи — дейтаграмма шифруется и вновь отправляется защитному экрану, так как после шифрации исходной дейтаграммы к пей добавляется новый зато-. ловок, где в качестве адреса получателя устанавливается 193.125.203.24, а в ка-: ’^ честве адреса отправителя адрес сервера VPN — 192.168.3.252. Вновь сформиро-. ванная дейтаграмма отправляется шлюзу по умолчанию — а именно защитному G экрану, поскольку сервер VPN абсолютно не владеет информацией о маршруте ■ ; в сеть 192.168.10.0/24 — для него это где-то в сети Интернет. Можно, конечно, прописать на нем статический маршрут, да только смысла в этом не будет никакого — все равно дейтаграмма должна выйти за пределы внутренней сети через ; защитный экран. Защитный экран, получая дейтаграмму, проверяет свою таблицу маршрутизации, не находит маршрут в нужную сеть и передает ее далее ■ в Интернет. Однако перед тем как отправить ее, он должен выполнить трансля- ; цию адреса, так как адрес отправителя установлен в 192.168.3.252 (напомним, что это адрес из диапазона немаршрутизируемых в сети Интернет). Если транс- Д ляцию не выполнить и послать дейтаграмму без изменения адреса отправителя, то она должна дойти до адресата — ведь промежуточные маршрутизаторы про- Д веряют только адрес получателя — да только вот ответа можно уже не дождать- .■ ся — сеть 192.168.3.0/24 относится к разряду немаршрутизируемых.Ж
При трансляции адреса дейтаграмма претерпевает изменения — меняется ад- Ж рес отправителя и порт на его стороне (изменение порта выполняется, если защитный экран настроен на подстановку только одного адреса, и в таком случае номер порта позволяет идентифицировать сеансы от разных хостов). И только после этого дейтаграмма отправляется в путешествие через сеть Интернет Д05Я внешнего интерфейса защитного экрана на объекте 2, который транслирует без изменения локальному серверу VPN. Там дейтаграмма вновь претерпевается
изменения — удаляется новый заголовок, а расшифрованные данные формируют исходную дейтаграмму. Аналогично можно посчитать количество трансформаций — их тоже три. Учитывая то, что па все требуется процессорное время, начинаешь к рекомендациям производителей по поводу аппаратного обеспечения относиться с меньшим скепсисом (кстати, скептицизм этот сугубо российский, на Западе к рекомендациям относятся более внимательно). Можно задать вопрос — что будет, если все же защитный экран не выполнит трансляцию адреса и дейтаграмма уйдет в сеть Интернет с адресом отправителя 192.168.3.252 (если принять как версию, что до сервера VPN она дойдет)? Ведь новый заголовок (с этим адресом) будет там удален!
Методы шифрования информации
Для выполнения процедуры шифрования данных протокол РРТР использует процесс RAS с разделяемым закрытым ключом (RAS «shared-secret» encryption process). Такое'Название он получил из-за того, что оба участника туннеля используют один ключ шифрования. В реализации РРТР от компании Microsoft этот ключ получается с помощью пользовательской информации, вводимой на стадии настройки туннеля (то есть имени и пароля учетной записи, созданной для туннеля). Кроме того, протокол РРТР может дополнительно сжимать передаваемые по туннелю данные для уменьшения их размера.
Стандарт на протокол РРТР не уточняет, как именно должно выполняться шифрование данных, а вместо этого ссылается на технологию МРРЕ (Microsoft Point-to-Point Encryption, шифрование на каналах типа «точка-точка», см. документ RFC 3078). Как легко догадаться из названия, эта технология разработана компанией Microsoft для организации процедуры шифрования информации на каналах типа «точка-точка». Сама по себе технология МРРЕ является расширением технологии Microsoft Point-to-Point Compression (МРРС, RFC 2118), которая применяется для сжатия данных, передаваемых в пакетах протокола РРР, и была разработана для оптимизации разделения полосы пропускания между множеством одновременных соединений.
Технология МРРЕ использует алгоритм RC4 (лицензия компании RSA Data ■ Security Inc., www.rsa.com) с различными длинами ключей шифрования (например 40 бит или 128 бит), которые, в свою очередь, получаются из информации пользователя. Алгоритм RC4 относится к потоковому (stream chiper) и, следовательно, размеры зашифрованной и расшифрованной дейтаграммы одинаковы (это очень важно, так как алгоритм не вносит накладных расходов). Отметим, что реализация технологии МРРЕ от компании Cisco Systems полностью совместима с возможностями, предлагаемыми Microsoft. В их перечень входит возможность работы «без истории» (режим historyless), которая позволяет повысить пропускную способность на ненадежных каналах связи (в том числе и в туннелях виртуальных частных сетей, проходящих через сеть Интернет), так как ни одна из сторон не должна синхронизировать контекст шифрования при потере Дейтаграмм. Данные шифруются при использовании технологии МРРЕ только в том случае, когда была согласована аутентификация с помощью алгоритмов MS-CHAP, MS-CHAP v2 или EAP/TLS, которые позволяют генерировать свои
собственные начальные ключи для шифрования. При этом оба участника полу,, j чают один ключ.д ч
.I.IК СВЕДЕНИЮ
.I
.I
RC4 — это потоковый алгоритм для побайтового шифрования входных данных с использованием ключа, длину которого можно варьировать в зависимости от желаемой скорости обработки информации и стойкости шифра. Алгоритм работает очень быстро и поэтому часто применяется там, где требуется шифрование непрерывно передаваемых данных. По своей сути RC4 представляет собой генератор псевдослучайных чисел, которые затем комбинируются с шифруемыми данными при помощи дперации побитового сложения по модулю 2.- <
Технология MPPE настраивается на вкладке Encryption в диалоговом окне ' свойства политики удаленного соединения (remote access policy) на использование ключей разного размера (рис. 10.13). Так, при установке флажка Basic (баз^-М вое шифрование) используется 40-битовый ключ, флажок Strong (строгое) подразумевает ключ длиной 56 бит, а флажок Strongest (самое строгое) задает ключ длиной 128 бит. Первоначально 40- и 56-битовые ключи предназначались для ; использования за пределами США, а ключ длиной в 128 бит не подлежал при- ■ . менению за пределами США и был доступен только в соответствующей версии - ■ операционной системы Windows 2000. Однако с выходом второго пакета об- . новления (Service Pack 2) интернациональные пользователи также получили . возможность использования 128-битового ключа для создания зашифрованных ; туннелей. Такое стало возможным и по причине смягчения экспортных требо- " ваний, осуществленного правительством США в начале 2000 года.." i
Edit Dial-in »ч «fileEdit Dial-in »ч «fileDiet-i» СоптЬдНЕ»AuthenticationDiet-i» СоптЬдНЕ»AuthenticationiiteiiSiiteiiSД12£1Д12£1NOTE, these $n$pp6on things £₽pfe$n^tp th$ Vi^^ and Rerrote Access Service.NOTE, these $n$pp6on things £₽pfe$n^tp th$ Vi^^ and Rerrote Access Service.№5д®да№5д®даP p pP p p£wngSiteses£wngSitesesРис. 10.13. Настройка длины ключа для шифрованияРис. 10.13. Настройка длины ключа для шифрования■ -a>-V^t■ -a>-V^t
Edit Dial-in »ч «file
Edit Dial-in »ч «file
Diet-i» СоптЬдНЕ»
Authentication
Diet-i» СоптЬдНЕ»
Authentication
iiteiiS
iiteiiS
Д12£1
Д12£1
NOTE, these $n$pp6on things £₽pfe$n^tp th$ Vi^^ and Rerrote Access Service.
NOTE, these $n$pp6on things £₽pfe$n^tp th$ Vi^^ and Rerrote Access Service.
№5д®да
№5д®да
P p p
P p p
£wng
Siteses
£wng
Siteses
Рис. 10.13. Настройка длины ключа для шифрования
Рис. 10.13. Настройка длины ключа для шифрования
■ -a>-
V^t
■ -a>-
V^t
После того как вы установите второй пакет обновлений или иначе Service Pack 2, ваша операционная система будет обновлена, и любая система, поддерживающая максимально 56-битовый ключ, будет подготовлена до наивысшего уровня шифрования. Интересно, что после обновления вернуться обратно на предыдущий уровень шифрования будет невозможно, даже при деинсталляции пакета обновления. Кроме того, подобное обновление осуществляется автоматически и пользователь не имеет возможности его запретить.
Ключи для сеанса формируются на основе пользовательского пароля. В случае применения алгоритмов MS-CHAP (vl и v2) необходимо предпринять дополнительные меры по хранению пароля в тайпе и выбирать его следует таким образом, чтобы снизить вероятность подбора. Так, можно порекомендовать воспользоваться генераторами случайных паролей при настройке туннеля (точнее, при создании в домене пользователя, который затем будет указываться в свойствах интерфейса DOD VPN — если, конечно, администратор предпочел такую схему), а затем пароль можно «забыть». Ведь он будет нужен только один раз, и всегда есть возможность его поменять. Важно отметить, что ключ шифрования отправляемых дейтаграмм меняется для каждой из них и, следовательно, расшифровка каждой дейтаграммы не зависит от получения предыдущих. Для того, чтобы синхронизировать ключи, используется специальное поле с номером последовательности, и если дейтаграммы потерялись в пути или пришли не в порядке их отправления, то ключи адаптируются к изменению условий.
Для того чтобы показать, как именно работает протокол РРТР на сетевом уровне, и продемонстрировать, что он действительно обеспечивает должный уровень безопасности (точнее, выполняет шифрование данных, так как анализ уровня криптоустойчивости алгоритма RC4 выходит за рамки главы), выполним команду ping в отношении удаленного сервера, находящегося на другом конце виртуального соединения (адрес 192.168.10.254 — это адрес внутреннего интерфейса защитного экрана на объекте 2). Сама команда выполняется с защитного экрана, установленного на объекте 3 (рис. 10.11), имеющего адрес 192.168.1.253 (также адрес внутреннего интерфейса — напомним, что если хост имеет несколько сетевых интерфейсов, то при отправке дейтаграмм подставляется адрес того интерфейса, через который дейтаграмма поступает в сеть). Кстати, одна особенность команды ping в операционной системе Windows 2000 очень полезна — по умолчанию она заполняет повторяющимися символами алфавита поле данных. Ниже показан пример, где для наглядности размер поля данных был задан равным 512 байт и все эти 512 байт были упорядоченно заполнены английским алфавитом. Результирующий размер дейтаграммы составляет 540 байт (рис. 10.14).
Учитывая, что адрес получателя дейтаграммы находится в другой сети (192. 168.10/24) и маршрут до этой сети предполагает прохождение сквозь туннели РРТР (сначала через туннель до объекта 1, а затем через туннель от объекта 1 до объекта 2), дейтаграмма посылается серверу VPN на объекте 1, который знает маршрут в искомую сеть (то есть этот сервер является партнером сразу двух других серверов VPN — на объектах 2 и 3). Сервер VPN (его адрес 192.168.1.253) на объекте 3 согласно заложенной логике выполняет шифрование дейтаграммы и отправляет ее в сеть Интернет. После выполнения процедуры шифрования исходная дейтаграмма выглядит, как это показано на рис. 10.15.
2111 X2OUMS 192.16U1.ZS» 1ШЮШ 4 ICMP faho (pU»y) fiiMUriTit2111 X2OUMS 192.16U1.ZS» 1ШЮШ 4 ICMP faho (pU»y) fiiMUriTitFrame 2111 (554 byte» on wire, 554 byte* captured)
2111 X2OUMS 192.16U1.ZS» 1ШЮШ 4 ICMP faho (pU»y) fiiMUriTit
2111 X2OUMS 192.16U1.ZS» 1ШЮШ 4 ICMP faho (pU»y) fiiMUriTit
Ethernet II, Sre: 00:30:48:21:**:38, Det: 00:90:27:eO:04:1e
Internet Protocol, Sre Addr: 192.188.1.254 (192.188.1.254), Det Addr: 192.188.10.254 (192.188.10.264) internet Control Keuage Protocol
-Type: 8 (Echo (ping) request)
-Code: 0.
-Checkaum: Oxd019 (correct)
-identifier: 0x0200
-Sequence number: ее:91
шпшшпш0020 0030 0040 00500080 0070 nnRn0020 0030 0040 00500080 0070 nnRn0a fa87 8877 8170 7189 8a82 8379 770a fa87 8877 8170 7189 8a82 8379 7708 00 d8 19 02 89 8a 8b 8c 8d 82 83 64 85 88 72 73 74 75 78 6b 8c 8d Be 8f 84 85 88 87 88 74 7A 7R 77 RI08 00 d8 19 02 89 8a 8b 8c 8d 82 83 64 85 88 72 73 74 75 78 6b 8c 8d Be 8f 84 85 88 87 88 74 7A 7R 77 RI00 8e87777089R900 8e87777089R9ее 91 81 82 83 84 85 888f 70 71 72 73 74 75 78ее 91 81 82 83 84 85 888f 70 71 72 73 74 75 7888 69 8a 8b 8c 8d 81 82 83 84 85 88 71 72 73 74 75 78 8a 8b 8c 8d 8e 8f as R4 RR RR R7 RR88 69 8a 8b 8c 8d 81 82 83 84 85 88 71 72 73 74 75 78 8a 8b 8c 8d 8e 8f as R4 RR RR R7 RR8e 8f 87 88 77 81 70 71 RO Re8e 8f 87 88 77 81 70 71 RO Reabedif ghijklmn opqretuv wmbedaft hijklmno pqrstuvw abedefih ijklmnop qrstuvwa bedefehi jklmnopq r»+iiwnioh. /mrle^shi iabedif ghijklmn opqretuv wmbedaft hijklmno pqrstuvw abedefih ijklmnop qrstuvwa bedefehi jklmnopq r»+iiwnioh. /mrle^shi i*-Data (512 byte»)
шпш
шпш
0020 0030 0040 0050
0080 0070 nnRn
0020 0030 0040 0050
0080 0070 nnRn
0a fa
87 88
77 81
70 71
89 8a
82 83
79 77
0a fa
87 88
77 81
70 71
89 8a
82 83
79 77
08 00 d8 19 02 89 8a 8b 8c 8d 82 83 64 85 88 72 73 74 75 78 6b 8c 8d Be 8f 84 85 88 87 88 74 7A 7R 77 RI
08 00 d8 19 02 89 8a 8b 8c 8d 82 83 64 85 88 72 73 74 75 78 6b 8c 8d Be 8f 84 85 88 87 88 74 7A 7R 77 RI
00 8e
87
77
70
89
R9
00 8e
87
77
70
89
R9
ее 91 81 82 83 84 85 88
8f 70 71 72 73 74 75 78
ее 91 81 82 83 84 85 88
8f 70 71 72 73 74 75 78
88 69 8a 8b 8c 8d 81 82 83 84 85 88 71 72 73 74 75 78 8a 8b 8c 8d 8e 8f as R4 RR RR R7 RR
88 69 8a 8b 8c 8d 81 82 83 84 85 88 71 72 73 74 75 78 8a 8b 8c 8d 8e 8f as R4 RR RR R7 RR
8e 8f 87 88 77 81 70 71 RO Re
8e 8f 87 88 77 81 70 71 RO Re
abedif ghijklmn opqretuv wmbedaft hijklmno pqrstuvw abedefih ijklmnop qrstuvwa bedefehi jklmnopq r»+iiwnioh. /mrle^shi i
abedif ghijklmn opqretuv wmbedaft hijklmno pqrstuvw abedefih ijklmnop qrstuvwa bedefehi jklmnopq r»+iiwnioh. /mrle^shi i
’03.1)’03.1)Рис. 10.14. Исходная дейтаграмма, содержащая запрос ICMP echo request
’03.1)
’03.1)
^ 144 1.341896 192.168.1.253 193.125^03.1 PPPOmip WP t сиир nimiirrwil p*
trFrame 144 (120 bytes on wire, 120 bytes captured)
©Ethernet II, Sre: 00:90:27:eO:04: le, Det: 00:30:48=21 :aa=36
©Internet Protocol, Sre Addr: 192. 168. 1.253 (192.188. 1.253), Dst Addr: 193.125.203. 1 ( 193
-Version: 4
-Header length: 20 bytes
I Hype of service: 0x00 (None)
-Total Length: 108
-Identification: 0x7bc6
ttFlags: 0x00
-Fragment offset: 0
-Time to 1ive: 128
-Protocol: GRE (0x2f)
-Header checksum: 0x6f7a (correct)
-Source: 192.168.1.253 (192-168.1.253)
LDestination: 193.125.203.1 (193.125.203.1)
ttGeneric Routing Encapsulation (PPP)
©Point-to-Point Protocol
'-Protocol: compressed packet (OxOOfd)
LPPP Compressed Datagram
FEZ[oW001010020:|0030|nnjnFEZ[oW001010020:|0030|nnjn00 00 cb 4300 00 cb 4330 486a 7b01 3000 2130 486a 7b01 3000 2121 c6014521 c60145aa 00 88 00aa 00 88 0036 000b0236 000b02008000008000902f4a902f4a27 6f 83 be27 6f 83 beeO 7a df80eO 7a df8004 le 08 00 cO aS 01 fd 00 12 fc 4f 00 3f 80 c604 le 08 00 cO aS 01 fd 00 12 fc 4f 00 3f 80 c645 00 cl 7d fd ec62 f445 00 cl 7d fd ec62 f4ПО 41) ГЧ f= RI 9R % У П4 nn -n RA 4П Rn 9-51ПО 41) ГЧ f= RI 9R % У П4 nn -n RA 4П Rn 9-51-OH!.6.. ’.■j(..../ oz ..0....J .. C. !E-OH!.6.. ’.■j(..../ oz ..0....J .. C. !E..E...E....0.. •?..b. Р « Й...0.. •?..b. Р « ЙII
FEZ[oW001010020:|0030|nnjn
FEZ[oW001010020:|0030|nnjn
00 00 cb 43
00 00 cb 43
30 48
6a 7b
01 30
00 21
30 48
6a 7b
01 30
00 21
21 c6
01
45
21 c6
01
45
aa 00 88 00
aa 00 88 00
36 00
0b
02
36 00
0b
02
00
80
00
00
80
00
90
2f
4a
90
2f
4a
27 6f 83 be
27 6f 83 be
eO 7a df
80
eO 7a df
80
04 le 08 00 cO aS 01 fd 00 12 fc 4f 00 3f 80 c6
04 le 08 00 cO aS 01 fd 00 12 fc 4f 00 3f 80 c6
45 00 cl 7d fd ec
62 f4
45 00 cl 7d fd ec
62 f4
ПО 41) ГЧ f= RI 9R % У П4 nn -n RA 4П Rn 9-51
ПО 41) ГЧ f= RI 9R % У П4 nn -n RA 4П Rn 9-51
-OH!.6.. ’.
■j(..../ oz ..0....J .. C. !E
-OH!.6.. ’.
■j(..../ oz ..0....J .. C. !E
..E.
..E.
...0.. •?..b. Р « Й
...0.. •?..b. Р « Й
I
I
Рис. 10.15. Запрос ICMP echo request после процедуры шифрования
■i■iВидно, что формируется новая дейтаграмма. К ней добавляется заголовок протокола GRE с указанием того, что вложенные данные представляют собой пакет протокола РРР. В пакете протокола РРР доступно только одно поле заголовка, а именно Protocol (протокол), которое указывает на то, что содержимое пакета сжато (compressed packet). Хитрость заключается в том, что числовое значение OxOOfd свидетельствует, что пакет либо сжат (работает протокол МРРС), либо зашифрован (работает протокол МРРЕ), либо все вместе. Просто в данном . случае анализатор протокола посчитал, что пакет сжат. Посмотрите, размер исходу ной дейтаграммы больше 512 байт (512 байт данных ICMP плюс заголовки я итого 540 байт), но после того как она была отправлена в сеть Интернет (ИТ^
■i
■i
иными словами, после ее обработки сервером VPN), ее размер сократился до 106 байт.
Согласно логике работы алгоритма шифрования данных (RC4), используемого в протоколе РРТР (а точнее в технологии МРРЕ), данные не увеличиваются и не уменьшаются в размере после процедуры шифрования — их размер остается прежним. То есть можно сделать вывод, что данные был^ преуч^р^тц^- но сжаты с помощью протокола МРРС, и уже затем зашифрованы. Трудно утверждать, что это добавляет надежности передаваемым данным, но вот нагрузку на серверы-партнеры виртуальной частной сети это добавляет несомненно. С другой стороны, общий размер исходной дейтаграммы был 540 байт, а после процедур сжатия и шифрования получилась дейтаграмма длиной 106 байт. Пятикратное сжатие позволяет достичь более высоких скоростей (точнее говоря, за промежуток времени для передачи 540 байт можно будет передать пять дейтаграмм по 106 байт, выигрывая в скорости). Правда, следует отметить, что приведенный пример был не совсем корректен с точки зрения выигрыша в размере — заполнение поля данных сообщения ICMP имеет большую избыточность. Для сжатия данных используется популярный алгоритм LZ, далеко не во всех случаях обеспечивающий такой высокий уровень сжатия (см. Документ: Lempel, А. and Ziv, J., A Universal Algorithm for Sequential, Data Compression, IEEE Transactions On Information Theory, Vol. IT-23, No. 3, May 1977).
Несколько слов относительно уязвимости технологии PPTP. Есть интересная статья The Crumbling Tunnel (security tunnel) по адресу http://solaris.opennet.ru/base/ sec/p53-12.txt.html, где рассматривается возможность компрометации туннеля с помощью различных методов. Учитывая сказанное, рекомендуется при настройке правил на защитных экранах ограничивать права отправителя и получателя трафика туннеля. Например при настройке соединения между двумя серверами, как правило, внешние граничные адреса серверов известны и неизменны. То есть следует, например, указать, что сегменты TCP с портом 1723 .могут проходить через защитный экран только в том случае, если они направлены по адресу, удаленного сервера и никак иначе. Такие меры позволят снизить риск от несанкционированного доступа. Однако, вне всяких сомнений, они не помогут от возможного перехвата информации и последующей ее расшифровки.
Анализ криптоустойчивости туннеля РРТР выходит за рамки книги, однако следует заметить, что в операционной системе Windows 2000 реализован ряд решений, которые затрудняют расшифровку перехваченных данных. Одним из них, например, является семена ключа щцфрования для каждойдейтагуам- ^ы. В технической литературе такой режим иногда называют «безразличным» (stateless), и при его использовании (а он включен по умолчанию) расшифровка следующей дейтаграммы не зависит от предыдущей. Уникальный ключ для каждого пакета значительно повышает нагрузку на модуль шифрования на сервере, однако позволяет серверам не ожидать поступления предыдущего пакета, для того чтобы расшифровать текущий. В результате значительно повышается производительность на критичных каналах связи.
Самым очевидным методом взлома является перехват зашифрованных дейтаграмм с последующей попыткой их дешифрации. Здесь стоит полагаться на надежность и устойчивость криптографического алгоритма, применяемого для шифрования данных. В целом можно предположить, что такое действие будет
не под силу одному человеку или группе лиц, за которыми не стоит технически • оснащенная организация. Дейтаграммы следуют от маршрутизатора к маршрутизатору, которые, как правило, установлены у авторитетных и крупных поставщиков услуг Интернета. При этом получить доступ для проведения анализа I данных довольно затруднительно. Тем не менее, атакующий может попытаться 3 сам установить туннель РРТР со внутренним сервером и, как следствие, полу- ; чить доступ во внутреннюю сеть. Грубо говоря, все что нужно для «вз^^яь i? протокола РРТР и реализации туннелей на базе Microsoft Windows 20007это]
просто настроить интерфейс DOD VPN, указать IP-адрес сервера Ц W%jfcej- роль пользователя. Адрес сервера не так трудно выяснить с помощью сканиро- | вания портов — например, атакующий может провести сканирование и увидеть, j что порт 1723 протокола TCP открыт на таком-то хосте.
В схеме, показанной на рис. 10.11, этот порт может быть открыт на вне- ч шнем интерфейсе защитного экрана, прикрывающего сервер VPN. При этом за- J щитный экран выступает простым ретранслятором — получая сегменты TCP j с портом назначения 1723 (как и дейтаграммы, содержащие данные протокола | РРТР), он просто транслирует их внутреннему серверу. То есть задача атакующего сводится только к знанию имени и пароля пользователя, которому разре- ’ шено устанавливать туннель, или к попыткам эту информацию найти методом > подбора. Самым простым и, на взгляд автора, надежным методом защиты будет ’{ ограничение на защитном экране адресов, с которых.могут поступарьданные, принадлежащие туннелю РРТР. Напомним, что эти данные слагаются из сегментов TCP с целевым портом 1723, принадлежащих управляющему соединению 1 РРТР, и дейтаграммы IP, переносящей сами зашифрованные данные (пакету GRP). Практически любой современный защитный экран позволит ввести такир 1 ограничения, которые упрощаются тем, что IP-адреса серверов-партнеров всегда ;,i известны и статичны. Впрочем, в том случае, если есть мобильные клиенты, кото- * рые периодически подключаются через Интернет к корпоративной сети, ситуация у; усложняется, так как здесь адреса будут динамическими. На опыте эту пробле- ( му автор решал обнаружением целой сети провайдера, на телефоны модемного пула которого чаще всего звонят мобильные пользователи (например те, КТО подключается через переносной компьютер и модем GSM), и разрешал доступ ‘ для всей сети. До сих пор такое решение работает, хотя, несомненно, оно несёт ' в себе некий элемент риска — мало ли кто еще с адреса этой сети (обычно клйс- j са С для России) будет пытаться установить соединение. Дополнительно на sal- Я щитном экране можно порекомендовать ограничить исходящий в сеть Интер- тЯ нет трафик от внутреннего сервера, принадлежащий протоколу ¥*№?. Причём .Д ограничить по той же адресной группе, которая создавалась для фильтрации Я дящего трафика. Подобные настройки стоит выполнить на всех защитных экрана^, ■ «опекающих» серверы VPN, естественно, создавая каждый раз свои адресном группы в соответствии с выбранной топологией построения VPN. В результате атакующий просто не сумеет «прокопать» туннель РРТР к удаленной точке сетИ^е так как защитный экран пакеты от его адреса просто не пропустит во внутр^З^Я нюю сеть. Правда, тут открывается поле деятельности для выполнения ата^Й^Я основанной на замене адреса отправителя на разрешенные адреса.. ■
Например, предположим, что, как показано на рис. 10.11, два сервера установили соединение РРТР. Защитные экраны настроены на соответствующие правила прохождения и отсеивают неизвестные адреса. Но если нападающий знает пару адресов, не блокируемых экранами, то он может попытаться скомпрометировать соединение, посылая управляющие сегменты TCP или сами пакеты GRE с указанием правильных адресов отправителя. В этом случае защитные экраны пропустят означенные пакеты к внутренним серверам. Тем самым появляется вероятность организации атаки DoS, при которой установленное соединение может быть разорвано серверами по причине поступления большого количества пакетов. Отмечу, это только теоретические изыскания и на практике с подобным автор не сталкивался или просто не обращал внимания — ведь обычно в день туннели РРТР через Интернет разрываются по 2-3 раза (в большинстве случаев по причине резкого повышения задержки) и понять истинную причину перебоя довольно сложно.
Возвратимся к рассмотрению (рис. 10.15) прохождения получаемой дейтаграммы. Как видим, она отправляется по адресу 193.125.203.1 — на внешний интерфейс защитного экрана на объекте 1. Для того чтобы выполнить маршрутизацию, защитному экрану вовсе не обязательно анализировать содержимое дейтаграммы (да это после шифрования и невозможно), но он настроен таким образом, что дейтаграммы, поступающие на его внешний интерфейс и содержащие данные протокола РРТР (анализируется поле Protocol в дейтаграмме), должны транслироваться локальному серверу VPN. Необходимость подобного правила очевидна — подразумевается, что данные зашифрованы и особой ценности внутри сети без процедуры дешифрования не представляют, соответственно их нужно передать серверу, который сможет выполнить такую процедуру. Сервер VPN на объекте 1 получает эту дейтаграмму, расшифровывает ее и извлекает исходный запрос ICMP echo request. Затем он смотрит, по какому адресу полученную дейтаграмму нужно передать. Учитывая, что адрес получателя 192.168.10.253 и он принадлежит другой сети, транспортировка в которую подразумевает шифрование данных (отправка по туннелю DOD VPN), сервер выполняет обратную операцию — шифрует запрос ICMP echo, формирует новую дейтаграмму и отправляет ее далее по маршруту. Сервер VPN на объекте 3 получает дейтаграмму, расшифровывает ее и доставляет конечному получателю. Получатель (в данном случае — защитный экран объекта 3) принимает обычный запрос ping с адресом отправителя 192.168.1.254 и отвечает на него (кстати, ответ содержит тот же объем данных, что и запрос). Ответ проходит всю описанную цепочку преобразований вновь и поступает серверу VPN на объекте 3 (адрес на схеме 192.168.1.253).
То есть при построении сети, где все туннели сходятся на одном из объектов, выполнение одного запроса подразумевает под собой две процедуры шифрования и дешифрования данных. Как уже было отмечено, подобная схема построения будет оправдана, если в сети присутствует некий центр и если характер распределения трафика соответствует этой схеме. В противном случае при интенсивном обмене данными между объектами 2 и 3 рассмотренная модель будет нецелесообразной, так как сервер VPN на объекте 1 будет выполнять просто роль некого передаточного узла. Если характер трафика предполагает в большей сте-
пени обмен данными между объектами 2 и 3, то между ними можно настроить дополнительный туннель (потребуется только зарегистрировать маршруты на серверах VPN).
Чримеры настройки защитного экрана
Если в своей сети читатель решит внедрить схему, рассмотренную выше, то следует не забыть о том, что защитные экраны на обоих концах соединения также нужно настраивать, иначе серверы не смогут связаться друг с другом. Методы настройки различных защитных экранов на поддержку протокола РРТР отличаются друг от друга, но принципы общие и опираются они на параметры соединения. Так, при использовании защитного экрана Kerio WinRoute Pro настройка проводится следующим образом. (Напомню, что этот програмДный‘продукт для своей работы использует технологию NAT/PAT, меняющей адрес отправителя и номер порта на стороне отправителя. Последняя функциональность нужна для того, чтобы выделять различные сеансы от различных хостов в защищаемой сети.) В качестве зарегистрированного IP-адреса используется адрес, назначенный внешнему интерфейсу защитного экрана. Для того чтобы дейтаграммы, принадлежащие протоколу РРТР, попадали к внутреннему серверу VPN, нужно настроить так называемое отображение портов (port mapjping^, где указать, что дейтаграммы, поступающие на определенный порт, должны отображаться (транслироваться) по указанному адресу до внутреннего сервера.
[Port Mapping
, Mnpp»d£6its
UtienPott"ГойеФр Гргбйёб!i РейЫЛп IP, .R
; g =m[n/a"|<Unvecified>PPTP192.16810.253N/A
^§<«1723<Unspecified>TCP192.168.10.2531723
№.. | Edi.. I Bemov»
OK | &nc4 | Wr |
Рис. 10.16. Настройка параметров отображения портов
Из рис. 10.16 видно, что дейтаграммы, принадлежащие протоколу РРТР и направленные на адрес внешнего интерфейса защитного экрана на объекте 2, должны перенаправляться в защищаемую сеть по адресу 192.168.10.253 — это адрес внутреннего сервера VPN (сервера-партнера туннеля с объектом 1). Подобная настройка применяется для трансляции сегментов TCP, принадлежащих контрольному соединению протокола РРТР (номер порта назначения 1723). Подоб-
Packet Description - •: Эйоси|;[тср 2* Source -- - iЙ||Я^||192т^Packet Description - •: Эйоси|;[тср 2* Source -- - iЙ||Я^||192т^—' destination ■H>*ddM»e:|l 93 i25 203 24—' destination ■H>*ddM»e:|l 93 i25 203 24Pgrt: [AnyPgrt: [Any(^^ЁсиаЛс^^(^^ЁсиаЛс^^
Packet Description - •
: Эйоси|;[тср 2
* Source -- - i
Й||Я^||192т^
Packet Description - •
: Эйоси|;[тср 2
* Source -- - i
Й||Я^||192т^
—' destination ■
H>*ddM»e:|l 93 i25 203 24
—' destination ■
H>*ddM»e:|l 93 i25 203 24
Pgrt: [Any
Pgrt: [Any
(^^ЁсиаЛс^^
(^^ЁсиаЛс^^
ные настройки нужно сделать на защитных экранах на обоих концах соединения (конечно, учитывая то, что адреса протокола IP будут другими).
Если на защитном экране не определен протокол РРТР, то это определение легко создать. Для чего следует указать, что все дейтаграммы с установленным в значение 0x2f полем Protocol в своих заголовках принадлежат означенному протоколу. Анализатор будет идентифицировать такие дейтаграммы как принадлежащие протоколу GRE, что не должно вводить вас в заблуждение, поскольку вся информация, проходящая по туннелю, построенному на базе протокола РРТР, передается с помощью протокола GRE. То есть можно сказать, что РРТР это название не протокола, а технологии. В этой технологии используются два протокола — протокол TCP с портом назначения 1723 и, как уже отмечено, дейтаграммы IP с инкапсулированным заголовком GRE (десятичное значение поля Protocol в заголовке дейтаграммы — 47).
Далее, если на защитном экране настроена фильтрация исходящего трафика в сеть Интернет, то нужно не забыть о^щрытьдоступ для сервергшшартне^эов* виртуальной, частнойссти.^Так, следует открыть доступ по протоколу ф£^,р ^ том получателя 1723 к удаленному защитному экрану. Например, на защитном экране, установленном на объекте 1, для защиты локальной сети включена фильтрации исходящего трафика. Для того чтобы сервер VPN на этом объекте мог установить и поддерживать управляющее соединение с сервером VPN на объекте 2, нужно настроить разрешающее правило (рис. 10.17). Согласно этому правилу, защитный экран разрешит прохождение сегментов протокола TCP с заданными адресами получателя и отправителя и портом на стороне получателя, равным 1723 (порт на стороне отправителя может быть любой — ключевое слово any). Этот пример применим к продукту Kerio WinRoute Pro и, естественно, процедура настройки для иных реализаций защитных экранов будет другой, сохраняется только общий принцип.
*1*1Add itrii>
*1
*1
TCP^ag#—
Г* Oh^^st^lr^«d TCP
Г &ф «slashing TCP согум^
ActonActonr DlooГ Denyr DlooГ Deny-lag PacketГ Logrionrdow;-lag PacketГ Logrionrdow;ЙЖ1ЙЖ1Sy.^^X^ij (Always)Sy.^^X^ij (Always)
Acton
Acton
r Dloo
Г Deny
r Dloo
Г Deny
-lag Packet
Г Logrionrdow;
-lag Packet
Г Logrionrdow;
ЙЖ1
ЙЖ1
Sy.^^X^ij (Always)
Sy.^^X^ij (Always)
Рис. 10.17. Пример настройки правила фильтрации на защитном экране объекта 1
Учитывая то, что соединение РРТР двустороннее (это будет показано далее), J то есть каждый сервер устанавливает соединение с удаленным сервером, нужно также разрешить проход через защитный экран и обратному трафику от удаленно-я
го сервера. То есть если сервер VPN на объекте 2 отправляет сегменты TCP с пор-у
том получателя 1723, то в ответ сервер VPN на объекте 1 будет посылать сегмен- f ты со случайным (или трудно предсказуемым) портом получателя, но с портом отправителя 1723 — это требуется учесть при настройке правил (рис. 10.18).:
Add Item
- Packet Desctipfon—————;
£iato6ol фтср" " А;
-Satece - ■— ■--- - - -j)estfw!ion-- - ;
.. туре:|н^3 I
I JPMdte^t [i 92™i 68 "3252: IP Address ф 93123203 24
! Рй»: (Equal to (=1:Pepp^T3
liliiii»^^^
('TCPFbjp'” — - -———~i
( P Orif gstatiished TCP connections.. i
| Г On^ estpyishing TCP connections' ' -V
rteiw: i- Log PacketValid at— —-гv
й H a'J
I OK | Cancel |-
Рис. 10.18. Пример настройки правила фильтрации на защитном экране объекта 2
И наконец, следует разрешить прохождение через защитный экран дейтаграмм, содержащих заголовок GRE. В применении к защитному экрану Kerio WinRoute Pro, это не составляет труда, так как он изначально понимает, что означает протокол РРТР (у этого программного продукта есть встроенная поддержка протокола РРТР). Учитывая, что протокол РРТР работает на сетевом уровне (уровень IP), при его настройке не нужно указывать номера портов (рис. 10.19).
Безусловно, настраивать правила фильтрации нужно на каждом защитном экране, который может пропускать через себя трафик протокола РРТР. Приведенные настройки правил безопасности применимы также в том случае, если виртуальное соединение устанавливается не между серверами, а между сервером и клиентом. Например, вероятна следующая ситуация — компания имеет выход в сеть Интернет и для предоставления этой услуги своим сотрудникам из . дома установила сервер доступа. Пользователи звонят на сервер и после авторизации (скажем, средствами протокола RADIUS) получают доступ в Интернет. Однако можно также предоставить им доступ и во внутреннюю сеть с помощью технологии РРТР. И хотя сама технология РРТР в большей степени ориенти- » рована на использование между территориально удаленными точками, ничто НЙ®
мешает разрешить и описанный доступ. Если такая схема реализована, то компании не требуется создавать внутри сети еще один сервер доступа.
Packet Description-E-oiocol |рртр"VjPacket Description-E-oiocol |рртр"Vjdestination
Packet Description-
E-oiocol |рртр"Vj
Packet Description-
E-oiocol |рртр"Vj
- , Type Host
Рис. 10.19. Пример правила для протокола PPTPРис. 10.19. Пример правила для протокола PPTPIP Address :|i93125 203 24
Рис. 10.19. Пример правила для протокола PPTP
Рис. 10.19. Пример правила для протокола PPTP
Если «подняться» на уровень выше и посмотреть на связь трех рассматриваемых объектов с точки зрения структуры Active Directory (естественно при условии, что сеть построена на базе Microsoft Windows 2000), то можно предложить к рассмотрению схему, в которой на каждом объекте серверы VPN выполняют также роль контроллеров домена и участвуют в процедуре репликации информации домена. При этом схема репликации может либо настраиваться администратором собственноручно, либо создаваться автоматически самими серверами (процесс проверки целостности знаний, КСС — Knowledge Consistency Checker). В последнем случае, например, могут быть созданы репликационные связи между серверами на объектах 2 и 3. С точки зрения логики работы домена, это не создает никаких проблем — ведь в конечном итоге все контроллеры будут содержать одинаковую информацию. Но вот на сетевом уровне процесс репликации между этими серверами будет не оптимален с точки зрения трафика — поскольку пакеты будут проходить через сервер VPN на объекте 1 транзитом, создавая двойной трафик. Впрочем, подобные опасения становятся существенными только тогда, когда каждый из удаленных объектов содержал бы не десяток пользователей, а под тысячу. Здесь правильнее было бы настроить репликацию по схеме «звезда с центром в центральном офисе».
Вообще говоря, если для организации виртуальных сетей было выбрано программное решение от компании Microsoft, то администратор может выбирать схемы размещения серверов VPN из нескольких вариантов. Первый — когда сервер VPN располагается за защитным экраном, во внутренней сети. Такая
схема была выбрана для рассматриваемой сети (см. рис. 10.11). Преимущества Я данного решения в том, что сервер VPN скрыт защитным экраном и, в общемд
не доступен для прямого воздействия. Под прямым воздействием понимается воз-1
можность посылать непосредственно пакеты серверу, а затем ожидать (или не Я ожидать) получения ответа. В последнем случае можно организовать атаку по Л типу DoS на сервер VPN с фальшивых адресов в надежде па то, что он переста- Ь нет нормально работать. Например, зная, что сервер использует протокол TCP 5 с портом 1723 для управляющих соединений, можно попытаться «завалить» его i потоком сегментов TCP (или более того, просто посылать различные команды J по управляющему соединению в расчете на то, что серверы «упадут»). Если сер- а вер находится за защитным экраном, то на последнем можно просто указать ад- я реса, от которых разрешается прохождение во внутреннюю сеть сегментов TCP Я с портом 1723 и пакетов РРТР. Когда серверы VPN огорожены защитным пери- ) метром сети в виде экранов, их лучше включать в домен (например, домен ' Active Directory в силах охватить все объекты) и, как следствие, пользоваться ' единой политикой учетных записей. Так, при настройке туннеля РРТР на обоих ■ серверах-партнерах указываются учетные записи, которые будут использовать- ;
ся при проверке легитимности создания туннеля. Если серверы включены в до- । мен, то эти учетные записи (а лучше одна учетная запись на один туннель) мо- < гут быть также членами домена. Можно порекомендовать выбирать сложные • пароли и установить опции, указывающие на то, что пользователю не позволено -| менять пароль самостоятельно, а срок действия последнего не истечет никогда. (1
Другим вариантом может быть размещение сервера VPN за пределами внут- Я ренней сети, с внешней стороны защитного экрана. С точки зрения маршрутиза- ; ции такая схема абсолютно рабочая. Напомню, что при маршрутизации по- ; ступающей дейтаграммы службой RRAS операционной системы Windows 2000:
логический интерфейс DOD VPN рассматривается как обычный сетевой интер- 3 фейс, который, соответственно, способен передавать и получать дейтаграммы; : А тот факт, что они при этом будут зашифрованы, не играет роли. То есть в такой ” конфигурации сервер VPN формально не отличается от некоего маршрутизатора ^ с двумя и более портами, который знает маршруты в определенные сети. Недо- | статок такого размещения серверов очевиден — они становятся доступны из сети ., Интернет и нужно будет либо настраивать фильтры на граничном маршрутиза- j торе, либо настраивать фильтры в самой операционной системе Windows 2000 . ЭД (кстати, возможности фильтрации в ней впечатляют). Ну и управление серве^ Я ром усложняется — просто ли получить доступ для полного управления компь-1 Я ютером за пределами защитного экрана?' л ■
И последним решением может быть размещение сервера VPNnpHMO^gjytH^^ Д цом экране,,— такую конфигурацию, например, поддерживает продукт Wcrggoft ■ ISA Server. Схема очень удобная и устраняет необходимость в дополнительный серверах*— действительно, нужно будет приобрести только защитный экран, кой торый параллельно станет выполнять и роль сервера VPN. В такой схеме вовсе не обязательно задействовать протокол РРТР, так как многие современные щитные экраны включают в себя поддержку создания подобных конфигурацй^^Д на базе других протоколов — например протокола IPSec.
Остановимся отдельно на таком важном факторе, как надежность виртуального соединения. Естественно, она ниже, чем в случае использования выдр- ленных цифровых каналов связи, созданных либо самостоятельно, либо полученных от провайдера услуг. Мониторинг туннеля между реально работающими объектами показал, что его надежность составляет 98% или, если приводить абсолютные цифры, то из 449 часов его работы общее время простоя составило порядка 6 часов (на момент написания этих строк). В общем, при рабочем доступе в сеть Интернет на обоих концах требуется порядка 2-3 минут для восстановления соединения, если оно было потеряно по каким либо причинам. Наиболее распространенной причиной для разрыва связи между серверами по протоколу РРТР является резкое увеличение задержки при передаче информации на промежуточных узлах в сети Интернет. В этом случае серверы теряют связь и сразу же начинают процедуру повторного соединения. Ниже приведен отчет системы мониторинга соединения, которое выполняет обычную команду ping с интервалом в две минуты:
Mon, Nov 19. 2001. 18:54:30
State Change: Device Down / Verifying (удаленный сервер не отвечает на ping) Detail: Missing reply from Ping•
Mon, Nov 19. 2001. 18:56:31
State Change: Device Down / Verifying (удаленный сервер не отвечает на ping) Detail: Missing reply from Ping
Previously device was down / Verifying
Mon. Nov 19. 2001. 18:58:32
State Change: Device Up (удаленный сервер ответил)
Previously device was down / Verifying
Видно, что потребовалось немного времени для восстановления соединения (в данном конкретном случае 4 минуты). К сожалению, сбои в работе виртуального соединения зависят от множества факторов, которые, как правило, не поддаются контролю. В иной ситуации надежность соединения может быть очень высокой или, наоборот, очень низкой, если между точками в сети Интернет есть ненадежные или сильно загруженные маршрутизаторы. Качество связи между конечными точками можно проверить с помощью команды traceroute (оценить задержки на каждом переходе).
ИЗ ОПЫТА:
Практика показала, что иногда при попытке передать очень большие объемы данных через туннель РРТР (скажем к-2 Гбайт на высокой скорости — 2 Мбит/с), серверы VPN перестают отвечать на запросы и для возвращения их в рабочее состояние требуется перезагрузка. Кроме того, подобное поведение проявляется при продолжительной работе (2-3 месяца без перезагрузки). Не исключено, что проблема будет решена в очередном пакете исправлений от компании Microsoft, ну а пока самым простым решением является периодическая перезагрузка сервера, например в выходные дни ночью. Если сервер отвечает только за поддержание одного или нескольких туннелей, то перезагрузка будет абсолютно незаметна для пользователей, ведь туннели восстановятся автводвдщщм, Следует оговориться, что описанная проблема типична для сервера, на котором «сходятся» много туннелей (более 10), в то время как серверы на удаленных площадках, поддерживающие единственный туннель, работают без нареканий (рекордное время работы без перезагрузки и вообще административного вмешательства 10 месяцев^1 •ю*™'ю ■
Анализ трафика РРТР на сетевом уровне
Для перехвата трафика, относящегося к туннелю РРТР, можно воспользоваться, например, следующей командой, которая запускает программу WinDump (глава 4) с ключами, указывающими на то, что размер перехватываемых данных равен 1514 байт (-5 1514). При этом пакеты перехватываются целиком и записываются в файл PPTP.log (параметр -w c:\temp\PPTP.log). И последний параметр предписывает перехватывать пакеты, адрес отправителя или получателя которых совпадает с х.х.х.х (ключ host, за которым должен следовать адрес).
windump -S1514 -w c:\temp\PPTP.log host х.х.х.х
К сожалению, подобный способ перехвата не исключает попадание в журнал «лишних» пакетов, но гарантирует то, что ни один пакет, принадлежащий туннелю РРТР, не будет не замечен. Другим, более тонким вариантом будет указание того, что нужно перехватывать пакеты управляющего соединения (TCP, 1723) и пакеты GRE.. '
Разберем в деталях, как происходит инициализация туннеля между двумя серверами, его работа и завершение. Кстати, это относится и к случаю взаимодействия клиента с сервером. Для данных целей был проделан простой эксперимент — один из серверов-партнеров принудительно перезагружался. и..з^£м автоматически устанавливал туннель. Параллельно происходил перехват трафика, отражающего взаимодействие между серверами-партнерами. Адрес сервера VPN, который оставался активным в процессе эксперимента — 192.168.3.252 (объект 1 в рассматриваемых примерах), а адрес перезагружаемого сервера — 192.168.1.253 (объект 3).
Первоначально, серверы-партнеры должны установить между собой управляющее соединение по протоколу TCP. Для этого они обмениваются друг с дру- , гом пакетами TCP с установленными флагами SYN и АСК (рис. 10.20). Первый пакет с опцией SYN (запрос на установление соединения) поступает Зт сервера VPN на объекте 3, имеющего адрес 192.168.1.253. Обратите внимание, что пред- . лагается использовать технологию SACK (выборочное подтверждение — гла- ■ ву 5). Так как в рассматриваемой сети установлены защитные экраны, то пакет отправляется по адресу внешнего интерфейса защитного экрана (193.125.203.1) на объекте 1 и порт назначения 1723 (анализатор подставляет ключевос^слово, РРТР). Сервер-партнер по туннелю РРТР посылает в ответ пакет TCf^c установленными флагами SYN и АСК и соглашается на использование опции SACK . (выборочное подтверждение).■ ■
После того как соединение было установлено, сервер на объекте 3 отправляет по нему запрос START-CONTROL-REQUEST протокола РРТР (рис, 1°-2О- , А в ответ на него соответственно посылается START-CONTROL-REPLY. Эти запросы служат для начала согласования управляющего соединения TCP (не пу- J тать с логическим соединением, которое к этому времени уже было установлено).
Обмен этими сообщениями, согласно стандарту на протокол РРТР, призвай» согласовать версию протокола используемого управляющего соединения мей^Л серверами (в нашем случае версия 1 — поле Protocol version). Само поле содер-™
жит старший и младший номера версии протокола (версия 1, ревизия 0). Другие поля в этом сообщении практически не несут никакой особой смысловой нагрузки, за исключением, может быть, поля Cookie, которое всегда заполняется одним и тем же значение — 0xla2b3c4d и служит для гарантии правильной синхронизации потока данных протокола TCP. В ответ на рассматриваемое сообщение прсылается другое, которое содержит аналогичные поля и. сду^£дд^ подтверждения готовности начать установление туннеля (сообщение STAkT-
и in, :u»>.'i;i/tn:i inz.ibu.i.ZM mizb/oi.i HP n un - p|itp[srN]t>fl| I i tiuii'i a ki n <v,n in n। ur.Hi*i.
Frame 116 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:90:27:e0:04:le, Dst: 00:30:48:21:aa:36
Internet Protocol, Src Addr: 192.168.1.253 (192.168.1.253), Dst Addr: 193:125.203.1 (193.125.203.1) И
Transmission Control Protocol, Src Port: 11748 (11748), Dst Port: pptp (17231, Seq: 3314440471, Ack: (I
-Source port: 11748 (11748)-Destination port: pptp (1723)-Sequence number: 3314440471-Header length: 28 bytesOFlags: 0x0002 (SYH)-Window size: 16384-Checksum: 0xa0b5 (correct)eOptions: (8 bytes)-Maximum segment size: 1460 bytes-MOP-MOP-SACK permitted-Source port: 11748 (11748)-Destination port: pptp (1723)-Sequence number: 3314440471-Header length: 28 bytesOFlags: 0x0002 (SYH)-Window size: 16384-Checksum: 0xa0b5 (correct)eOptions: (8 bytes)-Maximum segment size: 1460 bytes-MOP-MOP-SACK permitted
-Source port: 11748 (11748)
-Destination port: pptp (1723)
-Sequence number: 3314440471
-Header length: 28 bytes
OFlags: 0x0002 (SYH)
-Window size: 16384
-Checksum: 0xa0b5 (correct)
eOptions: (8 bytes)
-Maximum segment size: 1460 bytes
-MOP
-MOP
-SACK permitted
-Source port: 11748 (11748)
-Destination port: pptp (1723)
-Sequence number: 3314440471
-Header length: 28 bytes
OFlags: 0x0002 (SYH)
-Window size: 16384
-Checksum: 0xa0b5 (correct)
eOptions: (8 bytes)
-Maximum segment size: 1460 bytes
-MOP
-MOP
-SACK permitted
88#00000304821aa36009027eO04le08004500Й00100030b26940008006f939cOaS01fdcl7d#020cb012de406bbc58e5917000000007002i 00304000aOb50000020405b401010402#00000304821aa36009027eO04le08004500Й00100030b26940008006f939cOaS01fdcl7d#020cb012de406bbc58e5917000000007002i 00304000aOb50000020405b401010402• OH!.6, .oa®..• OH!.6, .oa®..аа.9 Y..9 Y.Е.Е.рр
8
8
#00000304821aa36009027eO04le08004500
Й00100030b26940008006f939cOaS01fdcl7d
#020cb012de406bbc58e5917000000007002
i 00304000aOb50000020405b401010402
#00000304821aa36009027eO04le08004500
Й00100030b26940008006f939cOaS01fdcl7d
#020cb012de406bbc58e5917000000007002
i 00304000aOb50000020405b401010402
• OH!.6, .oa®..
• OH!.6, .oa®..
а
а
.9 Y.
.9 Y.
Е.
Е.
р
р
EXEX000000304821aa36009027eO04le08004500001000c4b26b40008006f8a3cOa801fdcl7d0020cb012de406bbc58e5918beb69ccO50180030447013c60000009c0001la2b3c4d0001000000304821aa36009027eO04le08004500001000c4b26b40008006f8a3cOa801fdcl7d0020cb012de406bbc58e5918beb69ccO50180030447013c60000009c0001la2b3c4d0001ппдп пп ппппдп пп ппП1 пп пп пп пп ппП1 пп пп пп пп ппПП ГН ПП ПП ЛП П1 пп ппПП ГН ПП ПП ЛП П1 пп пп-0H!.8 ...k®. dp?:::-0H!.8 ...k®. dp?:::Y.Y.Е.Е....P +<M....P +<M.
EX
EX
000000304821aa36009027eO04le08004500
001000c4b26b40008006f8a3cOa801fdcl7d
0020cb012de406bbc58e5918beb69ccO5018
0030447013c60000009c0001la2b3c4d0001
000000304821aa36009027eO04le08004500
001000c4b26b40008006f8a3cOa801fdcl7d
0020cb012de406bbc58e5918beb69ccO5018
0030447013c60000009c0001la2b3c4d0001
ппдп пп пп
ппдп пп пп
П1 пп пп пп пп пп
П1 пп пп пп пп пп
ПП ГН ПП ПП ЛП П1 пп пп
ПП ГН ПП ПП ЛП П1 пп пп
-0H!.8 ...k®. dp?:::
-0H!.8 ...k®. dp?:::
Y.
Y.
Е.
Е.
...P +<M.
...P +<M.
Рис. 10.20. Запрос на установление соединения TCP
Й 119 388.941080 14g.t68.U83493.l?M03.1WtPSt<Uir-e04#t».W<jt4 9r
, eFrame 119 (210 bytes on wire, 210 bytes captured)
i eEthernet II, Src: 00:90=27:eO:04:1 e, Dst: 00:30:48:21 :aa=38
: ФInternet Protocol, Src Addr: 192.168.1.253 (192.168.1.253), Dst Addr: 193.125.203.1 (193.125.203.1)
1 eTransmission Control Protocol, Src Port: 11748 (11748), Dst Port: pptp (1723), Seq: 3314440472, Ack:
I ePoint-to-Point Tunnelling Protocol
i[-Length: 156
i-Message type: CONTROL-MESSAGE(1)
■-Cookie: 0xla2b3c4d (correct)
<-Control type: START-CONTROL-REQUEST (1)
1-Reserved: 0 "ж
i-Protocol version: 1.0
i-Reserved: 0
> -Framing capabilities: ASYNCHRONOUS (1)
I-Bearer capabilities: ANALOG (1)
i-Maximum channels: 0
i-Firmware revision: 2160
-Hostname:
|^Vendor: Microsoft Windows MT
Рис. 10.21. Сообщение START-CONTROL-REQUEST
Следующее сообщение от удаленного сервера, после того как он убедился, что его партнер готов к продолжению, гораздо более информативно. Сервер VPN на объекте 3 отправляет сообщение OUTGOING-CALL-REQUEST, которое указывает на то, что удаленный сервер начинает процедуру установки самого туннеля РРТР (рис. 10.22).
Й 16$ 300.94 /331 192.1684.253 *®Э. 125.2034 #»МР 0U I ШМИДи ЯWlt'9-ГЙ 16$ 300.94 /331 192.1684.253 *®Э. 125.2034 #»МР 0U I ШМИДи ЯWlt'9-ГFrame 165 (222 bytes on wire, 222 bytes captured)Ethernet II. Src: 00:00:27:eO:04:le, Dst: 00:30:48:21:aa:36Internet Protocol, Src Mdr= 192.168.1.253 (192.168.1.253), Dst Addr: 193.125.203.1 (193.125.203.1) Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428408, Ack: Point-to-Point Tunnelling Protocol-Length: 168-Message type-' CONTROL -MESSAGE (1)-Cookie: 0xla2b3c4d (correct)-Control type: OUTGOING-CALL-REQUEST (7)-Reserved: 0-Call ID: 16384-Call Serial Number: 28097-Minimum BPS: 300-Maximum BPS: 100000000-Bearer capabilities: EITHER (3)-Framing capabilities'- EITHER (3)-Receive window size: 64-Processing delay: 0-Phone number length: 0-Reserved: 0-Phone number:-Subaddress:Frame 165 (222 bytes on wire, 222 bytes captured)Ethernet II. Src: 00:00:27:eO:04:le, Dst: 00:30:48:21:aa:36Internet Protocol, Src Mdr= 192.168.1.253 (192.168.1.253), Dst Addr: 193.125.203.1 (193.125.203.1) Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428408, Ack: Point-to-Point Tunnelling Protocol-Length: 168-Message type-' CONTROL -MESSAGE (1)-Cookie: 0xla2b3c4d (correct)-Control type: OUTGOING-CALL-REQUEST (7)-Reserved: 0-Call ID: 16384-Call Serial Number: 28097-Minimum BPS: 300-Maximum BPS: 100000000-Bearer capabilities: EITHER (3)-Framing capabilities'- EITHER (3)-Receive window size: 64-Processing delay: 0-Phone number length: 0-Reserved: 0-Phone number:-Subaddress:яя0000 00100020 0030 пплп0000 00100020 0030 пплп00 30 00 d0Л 01 43 d4 пп пп00 30 00 d0Л 01 43 d4 пп пп48 b4 2e 29 лп48 b4 2e 29 лп2143 0039 по2143 0039 поaa 4006 00 мaa 4006 00 м36 00 ьь0036 00 ьь0000 9080 06 сб 9100 а8 по по00 9080 06 сб 9100 а8 по по27 еО f6 bf 90 38 00 0127 еО f6 bf 90 38 00 0104 =0 be la nn04 =0 be la nn1е 08 00 а8 01 fd 4b bb cf 2b 3c 4d fc, „1 nn1е 08 00 а8 01 fd 4b bb cf 2b 3c 4d fc, „1 nn454550 00 nn50 00 nn00 7d 18 07 nn00 7d 18 07 nnOH! .6 ..ce.OH! .6 ..ce.C.)9.C.)9.Е.Е.■8.К..Р....+<М..■8.К..Р....+<М..
Й 16$ 300.94 /331 192.1684.253 *®Э. 125.2034 #»МР 0U I ШМИДи ЯWlt'9-Г
Й 16$ 300.94 /331 192.1684.253 *®Э. 125.2034 #»МР 0U I ШМИДи ЯWlt'9-Г
Frame 165 (222 bytes on wire, 222 bytes captured)
Ethernet II. Src: 00:00:27:eO:04:le, Dst: 00:30:48:21:aa:36
Internet Protocol, Src Mdr= 192.168.1.253 (192.168.1.253), Dst Addr: 193.125.203.1 (193.125.203.1) Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428408, Ack: Point-to-Point Tunnelling Protocol
-Length: 168
-Message type-' CONTROL -MESSAGE (1)
-Cookie: 0xla2b3c4d (correct)
-Control type: OUTGOING-CALL-REQUEST (7)
-Reserved: 0
-Call ID: 16384
-Call Serial Number: 28097
-Minimum BPS: 300
-Maximum BPS: 100000000
-Bearer capabilities: EITHER (3)
-Framing capabilities'- EITHER (3)
-Receive window size: 64
-Processing delay: 0
-Phone number length: 0
-Reserved: 0
-Phone number:
-Subaddress:
Frame 165 (222 bytes on wire, 222 bytes captured)
Ethernet II. Src: 00:00:27:eO:04:le, Dst: 00:30:48:21:aa:36
Internet Protocol, Src Mdr= 192.168.1.253 (192.168.1.253), Dst Addr: 193.125.203.1 (193.125.203.1) Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428408, Ack: Point-to-Point Tunnelling Protocol
-Length: 168
-Message type-' CONTROL -MESSAGE (1)
-Cookie: 0xla2b3c4d (correct)
-Control type: OUTGOING-CALL-REQUEST (7)
-Reserved: 0
-Call ID: 16384
-Call Serial Number: 28097
-Minimum BPS: 300
-Maximum BPS: 100000000
-Bearer capabilities: EITHER (3)
-Framing capabilities'- EITHER (3)
-Receive window size: 64
-Processing delay: 0
-Phone number length: 0
-Reserved: 0
-Phone number:
-Subaddress:
я
я
0000 0010
0020 0030 пплп
0000 0010
0020 0030 пплп
00 30 00 d0
Л 01 43 d4 пп пп
00 30 00 d0
Л 01 43 d4 пп пп
48 b4 2e 29 лп
48 b4 2e 29 лп
21
43 00
39 по
21
43 00
39 по
aa 40
06 00 м
aa 40
06 00 м
36 00 ьь
00
36 00 ьь
00
00 90
80 06 сб 91
00 а8 по по
00 90
80 06 сб 91
00 а8 по по
27 еО f6 bf 90 38 00 01
27 еО f6 bf 90 38 00 01
04 =0 be la nn
04 =0 be la nn
1е 08 00 а8 01 fd 4b bb cf 2b 3c 4d fc, „1 nn
1е 08 00 а8 01 fd 4b bb cf 2b 3c 4d fc, „1 nn
45
45
50 00 nn
50 00 nn
00 7d 18 07 nn
00 7d 18 07 nn
OH! .6 ..ce.
OH! .6 ..ce.
C.)9.
C.)9.
Е.
Е.
■8.К..Р.
...+<М..
■8.К..Р.
...+<М..
Рис. 10.22. Сообщение OUTGOING-CALL-REQUEST
В этом сообщении интересно такое поле, как Call ID (16384), содержащее уникальный идентификатор сеанса между серверами и ййюльзуклцееся для мультиплексирования и демультиплексирования данных, посылаемых по туннелю. Поле . Call Serial Number (28097) содержит другой идентификатор сеанса, применяемый для различения разных сеансов при обмене. В отличие от предыдущего поля, это поле будет одинаково для обоих серверов. Удаленный сервер также предлагает размер окна (поле Receive window size) на принимающей стороне. В ответ на сообщение OUTGOING-CALL-REQUEST посылается OUTGOING-CALL-REPLY, . которое обобщает результаты обработки предыдущего запроса (рис. 10.23).'
Ответ дополнительно включает в себя сведения, позволяющие регулировать передачу информации для устанавливаемого сеанса. Учитывая, что поле Call IP уникально, ему присваивается уникальное число (в примере 33761). А вот поле Peer's call ID наследует значение поля Call ID (16384) из запроса OUTGOING' ; CALL-REQUEST, посланного первым сервером. Поле Result, как можно поняТь J из названия, содержит результат попытки установить управляющего сеанса -- в данном случае попытка была успешной, и в ответ посылается значение 1 CONNECTED. В стандарте предусматривается 7 возможных сообщений (6 из HHx’^j^e сообщения об ошибках). Поле Connect speed содержит актуальное значение cKo^^J
рости соединения в битах в секунду (порядка 14,1 Мбит/с). Поле Receive window size (размер приемного окна) указывает число пакетов, которые будут помещаться в буфер для этого сеанса.
<4 16Ь .1111 ОМОЬI 193.175.20:1.1 14Z.lbM.Z53 ОСН'ОИГЬОМСЧЛП'ЙГПГ
El-Frame 186 (86 bytes on wire, 86 bytes captured)El-Ethernet II, Src: 00:30:48:21:aa:38, Dst: 00:00:27:eO:04: leEl-Internet Protocol, Src Addr: 193. 125.203.1 (193. 125.203.1), Dst Addr: 192.168. 1.253 (192.168. 1.253) ElTransinission Control Protocol, Src Port: pptp (1723), Dst Port: 11776 (11776), Seq: 3192634319, Ack: aPoint-to-Point Tunnelling Protocol-Length: 32-Message type'- CONTROL-MESSAGE (1)-Cookie: 0xla2b3c4d (correct)-Control type: OUTGOING-CALL-REPLY (8).-Reserved: 0-Call ID: 33761-Peer’s call ID: 16384-Result: CONNECTED (1)-Error: NONE (0)-Cause code: 0-Connect speed: 14808325-Receive window size: 16384-Processing delay: 0^-Physical channel ID: 0El-Frame 186 (86 bytes on wire, 86 bytes captured)El-Ethernet II, Src: 00:30:48:21:aa:38, Dst: 00:00:27:eO:04: leEl-Internet Protocol, Src Addr: 193. 125.203.1 (193. 125.203.1), Dst Addr: 192.168. 1.253 (192.168. 1.253) ElTransinission Control Protocol, Src Port: pptp (1723), Dst Port: 11776 (11776), Seq: 3192634319, Ack: aPoint-to-Point Tunnelling Protocol-Length: 32-Message type'- CONTROL-MESSAGE (1)-Cookie: 0xla2b3c4d (correct)-Control type: OUTGOING-CALL-REPLY (8).-Reserved: 0-Call ID: 33761-Peer’s call ID: 16384-Result: CONNECTED (1)-Error: NONE (0)-Cause code: 0-Connect speed: 14808325-Receive window size: 16384-Processing delay: 0^-Physical channel ID: 01LL- » 0610 0020 0030 1ПП4П1LL- » 0610 0020 0030 1ПП4ПITTITT7700 00 01 f9 пл00 00 01 f9 пл9048 fdac nn9048 fdac nn27 3e 06 Of8127 3e 06 Of81eO 32 bb 28eO 32 bb 2804 00 2e 00 an04 00 2e 00 an1е 00 3000 7с 0600 be 4b00 00 20 nn П1 nn1е 00 3000 7с 0600 be 4b00 00 20 nn П1 nn48 bl bb 00 пп48 bl bb 00 пп2159 cf01 nn2159 cf01 nnаааасб 1а ппсб 1а пп36 7d 912b36 7d 912b08 cb 903c ft,08 cb 903c ft,00 01 eO 4d П5.00 01 eO 4d П5.45 cO 50 00 4П.45 cO 50 00 4П.00 a8 18 08 ПП00 a8 18 08 ППН>2Н>2а.а.ооККН!• УН!• У6..Е6..Е...P KN....P KN.44
El-Frame 186 (86 bytes on wire, 86 bytes captured)
El-Ethernet II, Src: 00:30:48:21:aa:38, Dst: 00:00:27:eO:04: le
El-Internet Protocol, Src Addr: 193. 125.203.1 (193. 125.203.1), Dst Addr: 192.168. 1.253 (192.168. 1.253) ElTransinission Control Protocol, Src Port: pptp (1723), Dst Port: 11776 (11776), Seq: 3192634319, Ack: aPoint-to-Point Tunnelling Protocol
-Length: 32
-Message type'- CONTROL-MESSAGE (1)
-Cookie: 0xla2b3c4d (correct)
-Control type: OUTGOING-CALL-REPLY (8).
-Reserved: 0
-Call ID: 33761
-Peer’s call ID: 16384
-Result: CONNECTED (1)
-Error: NONE (0)
-Cause code: 0
-Connect speed: 14808325
-Receive window size: 16384
-Processing delay: 0
^-Physical channel ID: 0
El-Frame 186 (86 bytes on wire, 86 bytes captured)
El-Ethernet II, Src: 00:30:48:21:aa:38, Dst: 00:00:27:eO:04: le
El-Internet Protocol, Src Addr: 193. 125.203.1 (193. 125.203.1), Dst Addr: 192.168. 1.253 (192.168. 1.253) ElTransinission Control Protocol, Src Port: pptp (1723), Dst Port: 11776 (11776), Seq: 3192634319, Ack: aPoint-to-Point Tunnelling Protocol
-Length: 32
-Message type'- CONTROL-MESSAGE (1)
-Cookie: 0xla2b3c4d (correct)
-Control type: OUTGOING-CALL-REPLY (8).
-Reserved: 0
-Call ID: 33761
-Peer’s call ID: 16384
-Result: CONNECTED (1)
-Error: NONE (0)
-Cause code: 0
-Connect speed: 14808325
-Receive window size: 16384
-Processing delay: 0
^-Physical channel ID: 0
1LL- » 0610 0020 0030 1ПП4П
1LL- » 0610 0020 0030 1ПП4П
ITT
ITT
7
7
00 00 01 f9 пл
00 00 01 f9 пл
90
48 fd
ac nn
90
48 fd
ac nn
27 3e 06 Of
81
27 3e 06 Of
81
eO 32 bb 28
eO 32 bb 28
04 00 2e 00 an
04 00 2e 00 an
1е 00 30
00 7с 06
00 be 4b
00 00 20 nn П1 nn
1е 00 30
00 7с 06
00 be 4b
00 00 20 nn П1 nn
48 bl bb 00 пп
48 bl bb 00 пп
21
59 cf
01 nn
21
59 cf
01 nn
аа
аа
сб 1а пп
сб 1а пп
36 7d 91
2b
36 7d 91
2b
08 cb 90
3c ft,
08 cb 90
3c ft,
00 01 eO 4d П5.
00 01 eO 4d П5.
45 cO 50 00 4П.
45 cO 50 00 4П.
00 a8 18 08 ПП
00 a8 18 08 ПП
Н>2
Н>2
а.
а.
о
о
К
К
Н!
• У
Н!
• У
6..Е
6..Е
...P KN.
...P KN.
4
4
Рис. 10.23. Сообщение OUTGOING-CALL-REPLY
Следующим этапом создания соединения является проверка имени пользователя и пароля. Говоря о туннеле РРТР, следует помнить, что он состоит как бы из двух соединений, каждое из которых устанавливается сервером. Например, в рассматриваемом примере в создании туннеля участвуют два сервера, на каждом из них при настройке службы RRAS (а точнее при создании интерфейса DOD VPN) указываются имя и пароль пользователя. Впоследствии, когда сервер начинает процедуру формирования туннеля, он отправляет удаленному партнеру информацию об имени пользователя и его пароле. На сервере-партнере такой пользователь должен существовать, и он должен иметь право удаленного доступа. Эту процедуру выполняет каждый сервер-участник туннеля. В том случае, если оба сервера входят в домен, можно использовать одну доменную учетную запись.
Очередной шаг — проверка имени пользователя и пароля (только начинается). В нашем случае сервер VPN на объекте 3 первым начинает процедуру «постройки» своей части туннеля. Первенство ему отдано по той причине, что он перезагружался, а при запуске служба RRAS сразу пытается установить настроенные туннели, в то время как удаленный сервер на объекте 1 после того, как туннель оборвалс^, делает попытку восстановить его через небольшие периоды времени — 1-2 минуты (этот временной интервал может быть настроен).
При настройке туннеля администратору предлагается несколько схем аутентификации удаленного партнера. В сети Интернет есть публикация, которую я как автор настоятельно рекомендую прочитать (http://www.counterpane.com/ pptpv2-paper.html, автор Брюс Шнайер (Bruce Schneier)) — она рассматривает
слабые стороны протокола РРТР, а если говорить точнее, то «узкие места» протокола MS-CHAP vl (версии 1). Документ датирован 1998 годом, и в ответ на его появление компания Microsoft' представила новую версию этого протокола MS-CHAP v2. Впрочем, следует отметить, что до этого момента версии как таковой и не было — был просто протокол MS-CHAP, считавшийся расширенным вариантом известного протокола CHAP, предложенного Microsoft. Новая редакция протокола похожа на первую версию, но не совместима с ней — назначение некоторых полей изменилось или от их использования было решено отказаться вовсе. Кроме того, сам протокол стал гораздо более устойчивым к различным методам его дискредитации и, очевидно, должен использоваться там, где это возможно. Учитывая вышесказанное, не будем останавливаться на обсуждении протокола MS-CHAP как не совсем удачного выбора в качестве средства аутентификации партнеров по туннелю, а сразу перейдем к рассмотрению второй версии этого протокола, отмечая только радикальные отличия между этими
двумя версиями протоколов.
В процессе формирования туннеля, после того как было установлено управляющее соединение и серверы обменялись сообщениями OUTGOINT-CALL- REQUEST и OUTGOINT-CALL-REPLY, начинает работать процедура согласования параметров соединения протокола РРР. Для этих целей использует^ протокол PPP LCP (Link Control Protocol — протокол управления соединением). Основная задача данного протокола — согласовать различные параметры, которые будут затем использоваться в соединении РРР (напомню, что туннель РРТР в своей работе полностью опирается на протокол РРР, пакеты которого просто инкапсулированы в дейтаграммы IP). При согласовании параметров серверы обмениваются между собой несколькими пакетами РРР LCP, в одном из которых указывается и протокол аутентификации, который предполагается задействовать. Сервер VPN с адресом 192.168.1.253 посылает своему партнеру по туннелю запрос (РРР LCP Configuration Request) с предложением использовать, алгоритм MS-CHAP v2 для аутентификации (рис. 10.24)...
Поскольку спецификация РРТР опирается на возможности протокола РРР, разработчикам из Microsoft практически не пришлось «изобретать велосипед». Гораздо проще задействовать имеющиеся и апробированные механизмы, каковым является протокол РРР, и дополнительные возможности, такие как проверка имени и пароля (метод РАР или CHAP). Однако первоначально протокол РРР позиционировался для работы на канальном уровне модели OSI, в то время как для создания туннеля требуется взаимодействие на сетевом уровне и выше, или, иными словами, необходимо передавать пакеты РРР, инкапсулируя их в дейтаграммы IP. Для этих целей привлекается протокол GRE, который просто предоставляет каркас для любых видов инкапсуляции, в том числе и пакетов РРР» в дейтаграммы.■
Протокол аутентификации MS-CHAP v2 активируется указанием числового значения 0x81 в поле Algorithm (алгоритм) опций заголовка протокола РРР LCP. В остальном конфигурационные параметры для протокола MS-CHAP v2 идеи- , тичны тем, которые используются при согласовании стандартного протокола j CHAP (для него поле Algorithm будет иметь значение 0x05, то есть пароль буд^д проверяться по алгоритму MD5). В приведенном на рис. 10.24 перехваченной!
пакете один из серверов посылает запрос PPP LCP с предложением использовать протокол MS-CHAP v2 для аутентификации. Если другая сторона соглашается с предложением, то в ответ посылается подтверждение (сообщение PPP LCP Configuration Ack). В рассматриваемом случая оба сервера настроены на поддержку этого протокола и запрос был успешен.
а >30Э26Л6620? 192.168.1.253 1'13.125.203.1 WШ* И»ЮCwfmn» illun Рицам!
til-Frame 130 (107 bytes on wire, 107 bytes captured)
tl-Ethernet II, Src: 00:90:27:eO:04:1 e, Dst: 00:30:48:21:aa:38
II-Internet Protocol, Src Addr: 102. 168. 1.253 (192. 168. 1.253), Dst Addr: 193. 125.203. 1 (193. 125.203. 1)
(^Generic Routing Encapsulation (PPP)
tlPoint-to-Point Protocol aPPP Link Control Protocol
-Code: Configuration Request (0x01)
- Identifier: 0x00
-Length: 53
В Opt ions: (49 bytes)
(^■Authentication protocol: 5 bytes.
I-Authentication protocol: Cryptographic Handshake Auth. Protocol (0xc223)
LAlgorithm: HS-CHAP-2 (0x81)
-Magic number: 0x394d7b63
-Protocol field compression
-Address/control field compression
EtCallback: 3 bytes"
L0peration: Location is determined during CBCP negotiation (0x06)
-Multilink MRRU: 1614
BMultilink endpoint discriminator: 23 bytes
l-Class: Locally assigned address (1)
LAddress (20 bytes).
-Link discriminator for BAP: 0x0020
0600
00
30
48
21
аа
36
00
90
27
eO
04
1е
08
00
45
00
■ОН!.6.. ..
,.Е.
UU1U
00
5d
Ъ2
cl
00
00
80
2f
38
8с
с0
а8
01
fd
cl
7d
.]/8..
...)
0020
ch
01
30
81
88
0b
00
39
00
06
00
00
00
00
00
00
..0....9 ...
J
0030
00
01
ff
03
сО
21
01
00
00
35
03
05
с2
23
81
05
!.. .5.
ЛП4Л.
.ПК
OQ
44
7k
КО
П7
Л9
AR
n?.
П4
ПО
ПК
1.1.
П4
лк
4о..
Рис. 10.24. Запрос на согласование схемы аутентификации
Далее наступает очень важный момент в процедуре формирования туннеля — проверка правильности имени и пароля удаленного клиента. Сейчас рассматривается конфигурация, когда туннель устанавливается между двумя серверами, но при этом важно помнить, что туннель является двунаправленным — то есть каждый сервер по очереди выступает как клиент и как сервер в процессе инициализации туннеля. По этой причине все сказанное будет верно и для ситуации, когда удаленный пользователь пытается установить туннель с сервером в своей сети для работы с внутренними ресурсами.
После того как стороны согласовали протокол аутентификации (в нашем случае MS-CHAP v2), происходит обмен пакетами PPP CHAP, который помогает удостовериться, что пробующий установить туннель сервер (или в терминологии алгоритма MS-CHAP — клиент; в нашем случае туннель пытается организовать сервер VPN на объекте 3 — он и будет клиентом) имеет необходимые для этого полномочия. В случае туннеля РРТР сервер должен проверить имя и пароль удаленного клиента, убедиться, что таковой зарегистрирован в домене (Active Directory — если сеть построена на базе Windows 2000) и имеет полномочия устанавливать туннель. Так как пароль нельзя передавать по сети в открытом виде
(хотя при установления туннеля он задается именно так) используются так называемые «знаки внимания» или «вызовы» (challenges). На первом шаге клиент запрашивает «вызов» от сервера и сервер посылает его в виде 16-байтовой числовой последовательности (рис. 10.25).
| ^ 188 387.262267 193.125.203.1 192.168.1.253 IW СНА» WV СВАР Cl7.ll6-i.yf| ^ 188 387.262267 193.125.203.1 192.168.1.253 IW СНА» WV СВАР Cl7.ll6-i.yfЯЯЙ-Frame 188 (79 bytes on wire, 79 bytes captured)©Ethernet II, Src: 00:30:48:21:aa:36, Dst: 00:90:27: eO: 04:1 e£ Internet Protocol, Src Addr-' 193. 125.203. 1 (193. 125.203. 1), Dst Addr: 192.168.1.253 (192. 188. 1.253) :©Generic Routing Encapsulation (PPP),©Point-to-Point Protocol£PPP Challenge Handshake Authentication Protocol'-Code: Challenge (0x01)-Identifier: 0x00-Length: 27©Data (23 bytes);£Value Size: 16 bytesЙ-Frame 188 (79 bytes on wire, 79 bytes captured)©Ethernet II, Src: 00:30:48:21:aa:36, Dst: 00:90:27: eO: 04:1 e£ Internet Protocol, Src Addr-' 193. 125.203. 1 (193. 125.203. 1), Dst Addr: 192.168.1.253 (192. 188. 1.253) :©Generic Routing Encapsulation (PPP),©Point-to-Point Protocol£PPP Challenge Handshake Authentication Protocol'-Code: Challenge (0x01)-Identifier: 0x00-Length: 27©Data (23 bytes);£Value Size: 16 bytesI Value (16 bytes)I Value (16 bytes)*-Name (6 bytes)*-Name (6 bytes)и 0010 0020 0030 0040и 0010 0020 0030 004000000100000001000041 fd060041 fd06d2d2274530 c2274530 c28787eO3f8123eO3f81234949040088 01040088 013535le 000b 00le 000b 00■8■8007c00 00007c00 00494930 2f Id lb30 2f Id lb020248 aa401048 aa40106q6q21 2a 0021 2a 00ааааISIS42420000fafa36 7d 0036 7d 004f4fе?е?08 cb0008 cb0042422b2b0001050001054343fbfb45 =0 0045 =0 004141040400 a80000 a800Е.Е.5454едед.’....0 H!.6АЕ7..1/ .*.}.’....0 H!.6АЕ7..1/ .*.}
| ^ 188 387.262267 193.125.203.1 192.168.1.253 IW СНА» WV СВАР Cl7.ll6-i.yf
| ^ 188 387.262267 193.125.203.1 192.168.1.253 IW СНА» WV СВАР Cl7.ll6-i.yf
Я
Я
Й-Frame 188 (79 bytes on wire, 79 bytes captured)
©Ethernet II, Src: 00:30:48:21:aa:36, Dst: 00:90:27: eO: 04:1 e
£ Internet Protocol, Src Addr-' 193. 125.203. 1 (193. 125.203. 1), Dst Addr: 192.168.1.253 (192. 188. 1.253) :
©Generic Routing Encapsulation (PPP),
©Point-to-Point Protocol
£PPP Challenge Handshake Authentication Protocol'
-Code: Challenge (0x01)
-Identifier: 0x00
-Length: 27
©Data (23 bytes);
£Value Size: 16 bytes
Й-Frame 188 (79 bytes on wire, 79 bytes captured)
©Ethernet II, Src: 00:30:48:21:aa:36, Dst: 00:90:27: eO: 04:1 e
£ Internet Protocol, Src Addr-' 193. 125.203. 1 (193. 125.203. 1), Dst Addr: 192.168.1.253 (192. 188. 1.253) :
©Generic Routing Encapsulation (PPP),
©Point-to-Point Protocol
£PPP Challenge Handshake Authentication Protocol'
-Code: Challenge (0x01)
-Identifier: 0x00
-Length: 27
©Data (23 bytes);
£Value Size: 16 bytes
I Value (16 bytes)
I Value (16 bytes)
*-Name (6 bytes)
*-Name (6 bytes)
и 0010 0020 0030 0040
и 0010 0020 0030 0040
00
00
01
00
00
00
01
00
00
41 fd
06
00
41 fd
06
d2
d2
27
45
30 c2
27
45
30 c2
87
87
eO
3f
81
23
eO
3f
81
23
49
49
04
00
88 01
04
00
88 01
35
35
le 00
0b 00
le 00
0b 00
■8
■8
00
7c
00 00
00
7c
00 00
49
49
30 2f Id lb
30 2f Id lb
02
02
48 aa
40
10
48 aa
40
10
6q
6q
21 2a 00
21 2a 00
аа
аа
IS
IS
42
42
00
00
fa
fa
36 7d 00
36 7d 00
4f
4f
е?
е?
08 cb
00
08 cb
00
42
42
2b
2b
00
01
05
00
01
05
43
43
fb
fb
45 =0 00
45 =0 00
41
41
04
04
00 a8
00
00 a8
00
Е.
Е.
54
54
ед
ед
.’....0 H!.6
АЕ7..1/ .*.}
.’....0 H!.6
АЕ7..1/ .*.}
Рис. 10.25. Пример пакета, содержащего «вызов»
В перехваченном в сети пакете этот «вызов» представляет собой набор 0xe2fae72bfb048961d2874935c849026c. Эта последовательность должна быть случайной. Обратите внимание, что в пакете есть поле Name (8 байт) — оносодержит сервера VPN на объекте 1 (BOBCAT). Клиент получает «вызов» и, в свою очередь, формирует новую 16-байтовую последовательность, которая в стандарте, называется Peer Authenticator Challenge (будем далее ссылаться на нее как на РАР). Далее он формирует другую цепочку символов длиной 8 байт с помощью двух перечислецщ>1х.«вызов^р?>Ц1 имени польдоват^дя^ под которым выполняет- $Й$ЙяЙса установить туннель, у казанйые 8'байт формируются с помощью процедуры хэширования (hashing^. Конкретно происходит следующее — объединение двух 16-байтовых «вызовов» и имени пользователя (в шестнадцатеричном виде), после чего результат «проходит» через функцию SHA-1 и первые 8 байт результата становятся 8-байтовой последовательностью, которая затем применяется для шифрования.
НА ЗАМЕТКУ
В документе RFC 2759 от января 2000 года отмечено, что в настоящее (в то) время продукты компании Microsoft не заполняют поле Name — и это может измениться в будущем — «Microsoft authenticators do not currently provide information in the Name field. This may change in the future». Видимо, это будущее уже настало..
[СНТ[СНТ'К'К:те 3) выполняет процедуру:те 3) выполняет процедурупароля пользователя спомощьюэтой 8-байтовой последовательности (дпароля пользователя спомощьюэтой 8-байтовой последовательности (д
[СНТ
[СНТ
'К
'К
:те 3) выполняет процедуру
:те 3) выполняет процедуру
пароля пользователя спомощьюэтой 8-байтовой последовательности (д
пароля пользователя спомощьюэтой 8-байтовой последовательности (д
вызывается стандартная функция хэширования, принятая в Microsoft Windows NT). В результате получается 24 байт данных отклика (response), которые отправляются удаленному серверу (рис 10.26).Точнее, посылается такая строка: 16 байт случайной последовательности, сгенерированной клиентом (РАР); 8 байт, заполненных нулями (па будущее расширение); 24 байт — сформированный «ответ» и 1 байт — флаг (зарезервировано па будущее — пока равен нулю).
55^189 387^263/50 192.168 1J>53 147 125Л13 1 И* t HAI’Wt'HAI'
5
5
□•Frame 189 (119 bytes on wire, 119 bytes captured)
□ Ethernet II, Src: 00:90:27:eO:04: le, Dst: 00:30:48:21 :aa:36
□ Internet Protocol, Src Addr = 192- 188-1-253 ( 192.168. 1.253), Dst Addr: 193- 125.203. 1 (193. 125.203.1)
□■Generic Pouting Encapsulation (PPP)
EPoint-to-Point Protocol
□•PPP Challenge Handshake Authentication Protocol
-Code! Response (0x02)
-Identifier: 0x00.
-Length: 67
□■Data (63 bytes)
ФValue Size: 49 bytes
Маше (13 bytes)
FTTSi) 10040 005010060 10070FTTSi) 10040 005010060 1007000 0500 057c 6c00 dl54 la7c 6c00 dl54 laс2 23 02 00 00 43 31 51с2 23 02 00 00 43 31 515c 565c 569a b297 f c6a 09 c5 00 DO 00 00 00 00 00 50 dd 2f 28 8f ec 7c a2 eh 04 64 d4 59 f2 50 84 f9 f6 f? c8- cc ppg—19a b297 f c6a 09 c5 00 DO 00 00 00 00 00 50 dd 2f 28 8f ec 7c a2 eh 04 64 d4 59 f2 50 84 f9 f6 f? c8- cc ppg—150 4e 5f 52 3350 4e 5f 52 3354 4f 4d 54 49 5454 4f 4d 54 49 54¥VPN_R3¥VPN_R3fb 99 6c 55 79 5S]fb 99 6c 55 79 5S]
FTT
Si) 10040 0050
10060 10070
FTT
Si) 10040 0050
10060 10070
00 05
00 05
7c 6c
00 dl
54 la
7c 6c
00 dl
54 la
с2 23 02 00 00 43 31 51
с2 23 02 00 00 43 31 51
5c 56
5c 56
9a b297 f c6a 09 c5 00 DO 00 00 00 00 00 50 dd 2f 28 8f ec 7c a2 eh 04 64 d4 59 f2 50 84 f9 f6 f? c8- cc ppg—1
9a b297 f c6a 09 c5 00 DO 00 00 00 00 00 50 dd 2f 28 8f ec 7c a2 eh 04 64 d4 59 f2 50 84 f9 f6 f? c8- cc ppg—1
50 4e 5f 52 33
50 4e 5f 52 33
54 4f 4d 54 49 54
54 4f 4d 54 49 54
¥VPN_R3
¥VPN_R3
fb 99 6c 55 79 5S]
fb 99 6c 55 79 5S]
Рис. 10.26. Пример пакета, содержащего «ответ»
Наибольший интерес вызывает поле Name (имя), которое в соответствии со стандартом на протокол MS-CHAP v2 является строкой длиной до 255 символов, идентифицирующей пользователя (VPN_R3). Если учетная запись входит в домен Microsoft Windows, то его имя указывается как префикс (ТОМТ1Т\), а в противном случае имя домена может быть опущено. Видно, что на данном этапе уже известно имя удаленного сервера (BOBCAT), что нельзя признать очень полезным для атаки, но что более важно — известно имя пользователя и домена, где он зарегистрирован. Теперь осталось только узнать пароль и можно сказать, что туннель надежным являться не будет.
Сложно объяснить, почему во второй версии протокола MS-CHAP реализована столь сложная схема формирования «ответа». Видно, что здесь не востребован (по крайней мере явно) 16-байтовый «вызов» сервера, а вместо этого генерируется новая случайная последовательность (тоже 16 байт — в нашем случае 0xc0fb996c5579597c6c9ab297fc6a09c5), которая, тем не менее, также посылается по сети. Из перехваченного пакета нам уже известен 24-байтовый «ответ» — 0xdl50dd2f288fec7ca2eb0454d459f2541a5084f9f6f7c8cc. Как это значение получается? Процедура практически одинакова для двух версий протокола MS-CHAP — сервер берет хэшированное значение пароля пользователя (16 байт) и заканчивает эту последовательность нулями до получения 21 байт (добавляется пять нулевых байтов). Далее, новая 21-байтовая последовательность (обозначим ее как Z) разбивается на 3 блока по 7 байт, каждый из которых затем используется как ключ для шифрации 8 байт, полученных ранее с помощью алгоритма SHA-1.
Хэшированная версия пароля пользователя производится следующим образом — пароль перекодируется в Unicode с сохранением регистра, а затем к нему применяется функция MD4.
Подведем итог, что может быть известно злоумышленнику на данном этапе. Можно легко рассчитать 8-байтовую последовательность, которая затем участвует в шифровании — для этого подойдет любой калькулятор хэш-значений (например с сайта http://www.slavasoft.com). Вся необходимая информация уже есть (обозначим эту последовательность X) — в том числе имя пользователя. Далее, известно, что последовательность X используется для шифрования по алгоритму DES пароля пользователя (точнее, хэш-значения пароля) и нам известен результат — 24 байт (назовем это У). У формируется посредством применения функции DES к последовательности X, где ключом для шифрования служат 7-байтовые блоки из последовательности Z. В последнем блоке, как было отмечено, только ■ первые два байта неизвестны — остальные равны нулю. То есть, если говорить о взломе, то, предполагая, что пароль представляет собой некую угадываемую комбинацию (значит, возможна атака по словарю), нужно перебрать 216 возможных вариантов битов) комбинаций для получения последних двух байтов хэшированного значения пароля пользователя. Далее можно воспользоваться большим словарем, вычислить для каждого слова хэш-последовательность, а затем получить список тех, у которых последние два байта совпадают с вычисленными. Такой подход позволит значительно сократить размер словаря и повысить скорость взлома (и надеюсь, что осознание его легкости подтолкнет вас принять дополнитель- пые меры безопасности, по крайней мере, в отношении сложности пароля).
Вернемся к происходящему на сетевом уровне. После получения от клиента ответа (собственно, сервер интересует только последовательность У), он, опираясь на хранящееся у него хэш-значение пароля пользователя, выполняет процедуру дешифрации У. Если дешифрованные блоки совпадают с «вызовом», то считается, что клиент успешно прошел аутентификацию. Основное отличие двух вер- , ... сий алгоритмов MS-CHAP заключается в том, что версия 2 использует хэш-зна- . чения паролей Windows NT, в то время как первая — LAN Manager и Windows NT. Эти две разновидности отличаются друг от друга и первая гораздо менее < устойчива к взлому, чем вторая.j
В том случае, если клиент прошел процедуру аутентификации, сервер отправ- * ляет сообщение PPP CHAP Success^ которое содержит так называемый «ответ J аутентификатора» (Authenticator Response), размеров 42 -байт. Формат этого ; сообщения следующий — S=<auth_string> (см. выделенную часть рис. 10.27). Ответ представляет собой 20-байтовую последовательность (число, обозначим ? его как АД), кодированное в соответствии со стандартом ASCII как 40 шестна- Я дцатеричных цифр.я
Клиент получает последовательность AR, вычисляет ее самостоятельно и затем ■ Я производит сравнение для того, чтобы завершить процедуру аутентификации» Я При расчете клиент выполняет повторное хэширование хэш-значения пароля Я Чназовем это РНН — password hash-hash). Далее, клиент конкатенирует значе- Я ние РНН с последовательностью У (24 байт) и со строкой «Magic server to client constant» и затем подвергает результат обработке алгоритмом SHA-1. Полу^ДИ ченный результат (20 байт — на выходе этого алгоритма хэширования всегд^^М
последовательность такой длины) объединяется с последовательностью X (8 байт) и со строкой «Pad to make it do more than one iteration» и затем вновь поступает на вход алгоритму SHA-1, формируя последовательность для сравнения с AR. Трудно объяснить, зачем разработчики настолько усложнили алгоритм — дважды задействуется SHA-1.
^■Jaj2Sl^■Jaj2Sl@190 387.309155 193.125.2(13.1 192.1Ь8.1.2S3PPP СНАМW CHAP!
^■Jaj2Sl
^■Jaj2Sl
ФFrame 190 (98 bytes on wire, 98 bytes captured)
S-Ethernet II, Src: 00:30=48:21:aa:36, Dst: 00:90:27:eO:04:le
ФInternet Protocol, Src Addr: 193.125.203.1 (193.125.203.1), Dst Addr: 192-168.1.253
S-Generic Routing Encapsulation (PPP)
S-Point-to-Point Protocol
в PPP Challenge Handshake Authentication Protocol
-Code: Success (0x03)
-Identifier: 0x00
-Length: 46
в Data (42 bytes)
Message: 4? bytes
ПП00000090 27еО041е 00 3048 21 аа 36 08 00 45 0000100054 454е0000 7с 2fаа 08 cl 7d cb 01 сО а8002001fd 3081880b 00 3040 00 00 00 00 06 00 ОС00300007 с2230300 00 2е|53 3d 38 31 38 36 32 310040■3235 44343336 34 3831 30 38 45 36 45 32 39005014638 39323531 41 4545 36 38 42 34 31 37 440060ззё00000090 27еО041е 00 3048 21 аа 36 08 00 45 0000100054 454е0000 7с 2fаа 08 cl 7d cb 01 сО а8002001fd 3081880b 00 3040 00 00 00 00 06 00 ОС00300007 с2230300 00 2е|53 3d 38 31 38 36 32 310040■3235 44343336 34 3831 30 38 45 36 45 32 39005014638 39323531 41 4545 36 38 42 34 31 37 440060ззё25D43B48 F89251АЕ25D43B48 F89251АЕТЕН .0.ТЕН .0..0I/ .0.0I/ .0Н!Н!8.8.izr__izr__5581862118186211108Е6Е29E68B417D108Е6Е29E68B417D
П
П
0000
00
90 27
еО
04
1е 00 30
48 21 аа 36 08 00 45 00
0010
00
54 45
4е
00
00 7с 2f
аа 08 cl 7d cb 01 сО а8
0020
01
fd 30
81
88
0b 00 30
40 00 00 00 00 06 00 ОС
0030
00
07 с2
23
03
00 00 2е
|53 3d 38 31 38 36 32 31
0040
■32
35 44
34
33
36 34 38
31 30 38 45 36 45 32 39
0050
146
38 39
32
35
31 41 45
45 36 38 42 34 31 37 44
0060
ззё
0000
00
90 27
еО
04
1е 00 30
48 21 аа 36 08 00 45 00
0010
00
54 45
4е
00
00 7с 2f
аа 08 cl 7d cb 01 сО а8
0020
01
fd 30
81
88
0b 00 30
40 00 00 00 00 06 00 ОС
0030
00
07 с2
23
03
00 00 2е
|53 3d 38 31 38 36 32 31
0040
■32
35 44
34
33
36 34 38
31 30 38 45 36 45 32 39
0050
146
38 39
32
35
31 41 45
45 36 38 42 34 31 37 44
0060
ззё
25D43B48 F89251АЕ
25D43B48 F89251АЕ
ТЕН .0.
ТЕН .0.
.0
I/ .0
.0
I/ .0
Н!
Н!
8.
8.
izr
__
izr
__
5
5
8186211
8186211
108Е6Е29
E68B417D
108Е6Е29
E68B417D
Рис. 10.27. Пакет, подтверждающий успешность аутентификации
Ранее уже упоминалось, что в шифровании данных, передаваемых по туннелю, участвуют технология МРРЕ и алгоритм RC4. Особенностью является то, что ключи для пщфрорания ^™^,прлучаю^. е
согласованных алгоритмом MS-CHAP vz, и в каждом направлении работает свой, уникальный ключ, хотя и получаются они из одних и тех же данных (собственно хэшированное значение пароля пользователя). При использовании алгоритма MS-CHAP vl ключ формировался следующим образом — к хэшированному паролю применялась функция SHA-1, а затем результат обрезался в зависимости от длины ключа. При согласовании с помощью ключа длиной 40 бит результат функции укорачивался до 64 бит, а после первые 24 бит устанавливались в значение 0xdl269e, а для ключа длиной 128 бит результат функции усекался до 128 бит. Полученный ключ и использовался для шифрования трафика в обоих направлениях. Отметим, что ранние версии протокола МРРЕ для хэширования опирались на алгоритм MD4 (как и указано в стандарте RFC 3079), но потом было предложено задействовать алгоритм SHA-1.
В случае согласования алгоритма MS-CHAP v2 процедура получения ключей усложняется. Выполняется хэширование последовательности, состоящей из хэш- значения пароля (16 байт), последовательности У (24 байт) и константы (строки «This is the МРРЕ Master Key» — 27 байт) с помощью алгоритма SHA-1. Результат укорачивается до 16 байт. Это так называемый master-master-ключ
(мастер-ключ). Далее, если согласован ключ длиной 40 бит, то на вход алгоритма хэширования поступает следующая последовательность: мастер-ключ; 40 байт, заполненных нулями; некая «магическая» константа длиной 84 байт и 40 байт, заполненных значением 0xF2. Из результата (20 байт) берется 8 первых байтов (64 бит), начальные 24 бит которых устанавливаются в значение 0xdl269e — это и будет ключом длиной 40 бит. Значение «магической» константы зависит от того, используется ли ключ для шифрования трафика от клиента к серверу, или наоборот. Ключ длиной 128 бит получается аналогично, за исключением того, что берется не 8, а 16 байт результата функции хэширования. Видно, что хотя процедура формирования ключей усложнилась, по сравнению с алгоритмом MS-CHAP vl, но все равно в основе лежит хэшированное значение пароля пользователя.
На практике, скорее всего, при формировании туннелей РРТР будет применяться ключ длиной 128 бит и алгоритм MS-CHAP v2, как обеспечивающие наивысший уровень безопасности передаваемых данных. Использование разных ключей для двух направлений передачи данных также помогает значительно повысить устойчивость к перехвату данных и последующим попыткам взлома. В любом случае, надежность туннеля будет определяться тем, насколько сложным и трудно предсказуемым (случайным) был выбран пароль. ,
JO|2=IJO|2=IВернемся к рассмотрению процедуры установления туннеля, где мы остановились на согласовании параметров протокола IP. Так как туннель является двунаправленным, то каждый из серверов-партнеров выступает в роли сервера и клиента одновременно. Клиенту, как минимум, нужно предоставить адрес протокола IP, который выделяется ему из удаленной сети. Для этого используется протокол PPP IP Control Protocol (контрольный протокол — IPCP). Клиент (в нашем случае сервер на объекте 3) посылает запрос PPP IPCP Request с опциями в виде IP-адресов, которые изначально установлены в значение 0.0.0.0 (рис. 10.28).
JO|2=I
JO|2=I
195 387.331057 192.168.1.253 193.125^03.1 PPP JPG’ PPP Я
0 Frame 195 (82 on wire, 82 captured)■
0 Ethernet II
0 Internet Protocol, Src Addr= 192.168.1.253 (192-168.1.253), Dst Addr: 193-125.203-1
0 Generic Routing Encapsulation (PPP)
0 Point-to-Point Protocol
0 PPP IP Control Protocol
Code: Configuration Request (0x01)
Identifier: 0x06
Length: 34
0 Options: (30 bytes)
IP address: 0-0-0-0
Primary DNS server IP address: 0-0-0-0
Primary WINS server IP address: 0.0.0-0
Secondary DNS server IP address: 0.0.0.0
Secondary WINS server IP address: 0.0-0-0
000000 30 4821aa36009027eO 04le08004500-OH!-6001000 44 b4660000802f3700 cOa801fdcl7d.D.f..ПП9П.\ (1M(1(MMT.1(19,1QQ-I, ППППППП-9П,91n000000 30 4821aa36009027eO 04le08004500-OH!-6001000 44 b4660000802f3700 cOa801fdcl7d.D.f..ПП9П.\ (1M(1(MMT.1(19,1QQ-I, ППППППП-9П,91n" -1" -1Рис. 10.28. Запрос на получение параметров протокола IPРис. 10.28. Запрос на получение параметров протокола IP
000000 30 4821aa36009027eO 04le08004500-OH!-6
001000 44 b4660000802f3700 cOa801fdcl7d.D.f..
ПП9П.\ (1M(1(MMT.1(19,1QQ-I, ППППППП-9П,91n
000000 30 4821aa36009027eO 04le08004500-OH!-6
001000 44 b4660000802f3700 cOa801fdcl7d.D.f..
ПП9П.\ (1M(1(MMT.1(19,1QQ-I, ППППППП-9П,91n
" -1
" -1
Рис. 10.28. Запрос на получение параметров протокола IP
Рис. 10.28. Запрос на получение параметров протокола IP
Этим запросом клиент предлагает серверу установить соответствующие адреса, которые затем будут востребованы. Как видно из рисунка, клиента интересует собственно его адрес в удаленной сети (как правило, он выдается службой RRAS с помощью сервера DHCP), а также адреса серверов DNS и WINS. Для чего это нужно? Самым простым примером может быть ситуация, когда некий пользователь через сеть Интернет устанавливает туннель в корпоративную сеть. Хосту, за которым работает пользователь, присвоен некий адрес IP, выдаваемый обычно провайдером, который, естественно, не имеет ничего общего с адресной схемой, принятой внутри корпоративной сети (например, 192.168.3.0/24). Если хосту не будет назначен адрес внутри сети и другие параметры, то работать пользователь просто не сможет. Поэтому удаленный сервер VPN в ответ на такой запрос посылает аналогичный (IPCP Configuration Ack), но с уже заполненными полями (рис. 10.29).
Рис. 10.29. Ответ сервера VPN с предлагаемыми параметрами
Теперь процедуру формирования туннеля можно считать законченной. Отметим, что мы только рассмотрели установление одного направления туннеля: от сервера с адресом 192.168.1.253 к серверу с адресом 192.168.3.252 (в перехватах фигурирует адрес получателя 193.125.203.1 — адрес внешнего интерфейса защитного экрана на объекте 1, который просто транслирует дейтаграммы серверу VPN на этом объекте). Нгмгужттае се^^ ливать оба направления туннеля одновреКгеппсгЖ как правило, этот процесс за- от скорости каналов связи). Очень редко наблюдается'Сйтуацищкогда один из серверов VPN потерял «свою» часть туннеля, в то время как другая продолжает успешно наблюдать «свет на противоположном конце». Автор сталкивался с такой ситуацией, и для нее характерно
то, что связь с удаленным объектом прерывается (например, хосты перестают ; отвечать па запросы ping), но в то же время можно получить доступ к удаленной ■' сети непосредственно с локального сервера VPN (то есть с того, который еще . поддерживает свое направление туннеля). Самым простым способом исправить
ситуацию будет подключение с локального сервера VPN через терминальный
доступ к удаленному серверу и принудительная перезагрузка последнего. Такая ситуация в нормальной работе туннеля встречаться не должна и скорее всего характеризует некий внутренний сбой в программном обеспечении. ■
Пора подвести итог тому, что удалось узнать из перехваченных пакетов (для обоих направлений туннеля) — имена двух серверов-партнеров, имя домена, имя пользователя в домене и адреса серверов DNS и WINS внутри двух сетей. И хотя этой информации будет явно недостаточно для компрометации туннеля, но все же она не может относиться к тому типу информации, которую стоит свободно распространять в сети Интернет. Обратите внимание, что контрольные соединения туннеля не защищаются никоим образом и, как следствие, появляется возможность организовать атаку на контрольное соединение TCP. Также злоумышленник может сгенерировать ложные управляющие сообщения, направленные одному из серверов-партнеров с целью разрушить воздвигнутый туннель.
Уже после того как туннель был установлен, серверы обмениваются между собой специальными пакетами ECHO (некий вариант сообщенияJ<eegalive — рис. 10.30). Обмен «эхо» происходит по управляющему соединению и, как можно догадаться из названия, служит для проверки того, что связь работает и тоннель функционирует. Так, один из серверов посылает запрос ECHO-REQUEST в надежде, что удаленный сервер отзовется. Если ответа нет (в течение 60 секунд), то туннель считается разрушенным и серверы могут начинать процедуру его уста
новки с самого начала.
00111419 157В?* 1/ ’h4» PV 1MI ] *V 1ЧИЛ .Dll PPIPH НО Ш»ИДЧ1111419 157В?* 1/ ’h4» PV 1MI ] *V 1ЧИЛ .Dll PPIPH НО Ш»ИДЧ1IE Frame 11419 (70 on wire, 70 captured)E Ethernet II■И Internet Protocol, Src Addr: 192.168.1.263 (192.168.1.263), Det Addr: 193.126.203.1 (193-126.203.1)В Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428968, Ack: 319263495! El Point-to-Point Tunnelling Protocol Length: 16 Message type: CONTROL-MESSAGE (1) Cookie: 0xla2b3c4d (correct) Control type: ECHO-REQUEST (6) Reserved: 0 Identifier: 318767104IE Frame 11419 (70 on wire, 70 captured)E Ethernet II■И Internet Protocol, Src Addr: 192.168.1.263 (192.168.1.263), Det Addr: 193.126.203.1 (193-126.203.1)В Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428968, Ack: 319263495! El Point-to-Point Tunnelling Protocol Length: 16 Message type: CONTROL-MESSAGE (1) Cookie: 0xla2b3c4d (correct) Control type: ECHO-REQUEST (6) Reserved: 0 Identifier: 3187671040000 00 30 48Ё1 м 36 OOM Й ТбнГл 0010 00 38 06 32 40 00 80 06 аб 69 сО а8 01 fd cl 7d .8.2®. loogn-^hjTTTsJliLQfLhLkS^^0000 00 30 48Ё1 м 36 OOM Й ТбнГл 0010 00 38 06 32 40 00 80 06 аб 69 сО а8 01 fd cl 7d .8.2®. loogn-^hjTTTsJliLQfLhLkS^^Е.Е.Рис. 10.30. Пример пакета ECHOРис. 10.30. Пример пакета ECHO/Чин/ЧинВ запросе ECHO-REQUEST есть поле идентификатора (Identifier), пре^ значенное для того, чтобы дифференцировать поступающие ответы на разн|* запросы — значение данного поля в ответе должно совпадать со значением' в.В запросе ECHO-REQUEST есть поле идентификатора (Identifier), пре^ значенное для того, чтобы дифференцировать поступающие ответы на разн|* запросы — значение данного поля в ответе должно совпадать со значением' в.просе.просе.
0
0
111419 157В?* 1/ ’h4» PV 1MI ] *V 1ЧИЛ .Dll PPIPH НО Ш»ИДЧ1
111419 157В?* 1/ ’h4» PV 1MI ] *V 1ЧИЛ .Dll PPIPH НО Ш»ИДЧ1
IE Frame 11419 (70 on wire, 70 captured)
E Ethernet II■
И Internet Protocol, Src Addr: 192.168.1.263 (192.168.1.263), Det Addr: 193.126.203.1 (193-126.203.1)
В Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428968, Ack: 319263495! El Point-to-Point Tunnelling Protocol Length: 16 Message type: CONTROL-MESSAGE (1) Cookie: 0xla2b3c4d (correct) Control type: ECHO-REQUEST (6) Reserved: 0 Identifier: 318767104
IE Frame 11419 (70 on wire, 70 captured)
E Ethernet II■
И Internet Protocol, Src Addr: 192.168.1.263 (192.168.1.263), Det Addr: 193.126.203.1 (193-126.203.1)
В Transmission Control Protocol, Src Port: 11776 (11776), Dst Port: pptp (1723), Seq: 3331428968, Ack: 319263495! El Point-to-Point Tunnelling Protocol Length: 16 Message type: CONTROL-MESSAGE (1) Cookie: 0xla2b3c4d (correct) Control type: ECHO-REQUEST (6) Reserved: 0 Identifier: 318767104
0000 00 30 48Ё1 м 36 OOM Й ТбнГл 0010 00 38 06 32 40 00 80 06 аб 69 сО а8 01 fd cl 7d .8.2®. loogn-^hjTTTsJliLQfLhLkS^^
0000 00 30 48Ё1 м 36 OOM Й ТбнГл 0010 00 38 06 32 40 00 80 06 аб 69 сО а8 01 fd cl 7d .8.2®. loogn-^hjTTTsJliLQfLhLkS^^
Е.
Е.
Рис. 10.30. Пример пакета ECHO
Рис. 10.30. Пример пакета ECHO
/Чин
/Чин
В запросе ECHO-REQUEST есть поле идентификатора (Identifier), пре^ значенное для того, чтобы дифференцировать поступающие ответы на разн|* запросы — значение данного поля в ответе должно совпадать со значением' в.
В запросе ECHO-REQUEST есть поле идентификатора (Identifier), пре^ значенное для того, чтобы дифференцировать поступающие ответы на разн|* запросы — значение данного поля в ответе должно совпадать со значением' в.
просе.
просе.
Процедура настройки туннеля
До этого момента рассматривались детали работы туннеля РРТР, а сейчас остановимся на процедуре настройки туннеля между двумя серверами, участвующими в его поддержании. Для примера покажем как настроить туннель на сервере VPN объекта 1 (адрес 192.168.3.252 на рисунках в этой главе) к одному из удаленных объектов (а точнее к объекту 2 — серверу с адресом 192.168.10.253). Первым этапом является запуск консоли службы RRAS на сервере VPN на объекте 1. Если администратор запускает консоль первый раз, то ему будет предложено воспользоваться мастерами по настройке различных вариантов подключений, в том числе и подключения по виртуальной частной сети. Как показывает практика, лучше выбрать опцию «Ручная настройка» и выполнить все описанные далее шаги самостоятельно.
На первом этапе нужно, перейдя в дерево Routing Interfaces, нажать правую кнопку мыши и выбрать создание нового интерфейса DOD (New Demand-Dial Interface). На экране появится приветствие Мастера создания интерфейса и после нажатия кнопки Далее будет предложено ввести имя интерфейса (рис. 10.31).
Мастер интерфейса вызова ширебонанп**Мастер интерфейса вызова ширебонанп**Имя интерфейсаIdodvpnИмя интерфейсаIdodvpnИмя интерфейсаВыберите имя для этого нового интерфейса.Имя интерфейсаВыберите имя для этого нового интерфейса.Рис. 10.31. Ввод имени интерфейса DODРис. 10.31. Ввод имени интерфейса DOD■■I■■и■■I■■и
Мастер интерфейса вызова ширебонанп**
Мастер интерфейса вызова ширебонанп**
Имя интерфейса
Idodvpn
Имя интерфейса
Idodvpn
Имя интерфейса
Выберите имя для этого нового интерфейса.
Имя интерфейса
Выберите имя для этого нового интерфейса.
Рис. 10.31. Ввод имени интерфейса DOD
Рис. 10.31. Ввод имени интерфейса DOD
■■I
■■и
■■I
■■и
Вообще говоря, имя служит просто для удобства дальнейшего администрирования интерфейса и администратор волен выбрать его любым. Можно только посоветовать использовать такое имя, которое в дальнейшем позволит легко понять, на каком из объектов данный интерфейс будет поддерживать туннель. Далее предлагается выбрать протокол, который будет отвечать за туннелирование трафика. Сейчас мы остановимся на протоколе РРТР (рис. 10.32).
После этого будет предложено ввести адрес сервера (или .его имя),-с которым будет устанавливаться туннель. Как уже не раз отмечалось в главе, адреса
серверов-партнеров участников туннеля, как правило, являются фиксированными и определяются на этапе планирования сети (рис. 10.33)
Мастер интерфейса вызова по Tpebnuawto
Тип сети VPN
Выберите тип создаваемого интерфейса виртуальной частной сети.
Г1 Автоматический выбор;
Ху^с зци<->жтж''ж<»ж-'ж<к-н‘<-ж<-ж''>н<''ж<"тн1ч-ж'"'ж''>н«.м''.ж'-ж..'ж<г-у:: :•:■:•:•:•:•: циннельньй протокол точка-тскка f^TPl ;
Г Туннельный тиокол отроге уровня (L2TP)
< Цабж I Далее > I Отмена
Рис. 10.32. Выбор типа технологии для использования в туннеле
I Мас тер интерфейса вызова по требованию
Адрес назначения
Укажите имя или адрес удаленного маршрутизатора
: врвдиг^мя или iP'Wpep маршрутизатора к которому производится повкл1бчение
„Г; ^Цж^пыотерв или IFmumb (например, waosoft.com или 12145.6,791:
*193125 203 33
им
<Hasan . I Далее> I Отменаf ''
Рис. 10.33. Ввод адреса сервера-партнера по соединению Л ■
Далее предлагается выбрать опции маршрутизации (транспортных протру.-* лов). Для настройки туннеля можно принять настройки по умолчанию («Перед, направлять пакеты IP на зтот интерфейс») (рис. 10.34). ^Фз
|м«н irp инм-рфгиго ui.hopo по гррбипонит
Протоколы и бееопеснооть
Выберите транспортные протоколы и параметры безопасности для этого подключения,
Уазад | . Далее > | Отмена
Рис. 10.34. Выбор транспортных протоколов для туннеля
Следующее окно служит для указания параметров учетной записи, которая будет проверяться удаленным сервером при установке туннеля. Напомним, что туннель является двусторонним и каждый из серверов-партнеров выполняет свою процедуру его установки, и только после того как оба успешно выполнили ее, туннель считается установленным. Учетная запись используется при установке одного направления туннеля с текущего сервера (на котором сейчас выполняются настройки). Это может быть доменная учетная запись или локальная. В последнем случае она должна быть явно создана на удаленном сервере VPN и ей должны быть назначены соответствующие права. Если на обоих объектах, между которыми устанавливается туннель, установлены контроллеры домена (когда сеть построена на базе Microsoft Network), то на обоих серверах можно задать одну учетную запись, которая предварительно должна быть зарегистрирована в домене. Из опыта автор рекомендует именно такое решение, так как оно позволяет гибко и централизованно управлять учетными записями, особенно если сеть включает более одного туннеля. Излишне говорить, что пароль для учетной записи должен быть сложно предсказуемым и что администратору следует включить флажок, указывающий на то, что пароль никогда не «устареет».
На рис. 10.35 используется доменная учетная запись (из домена TOMTIT). Применительно к домену, построенному на базе службы каталогов Microsoft Active Directory, серверы-партнеры могут одновременно выполнять роли контроллеров этого домена, и на каждом при настройке туннеля допускается указывать одну и ту же учетную запись. Следует только не забыть о том, что создавая учетную запись на одном из контроллеров, потребуется некоторое время, прежде чем эта информация будет реплицирована на другой контроллер, особенно если они располагаются в разных сегментах (sites). На этом этапе процедура настройки туннеля завершается. Вновь созданный интерфейс DOD VPN появится в консоли службы RRAS в дереве Routing Interfaces (интерфейсы маршрутизации) (рис. 10.36).
Мастер интерфейса вызова по требованию
Учетные данные исходящего подключения
Имя пользователя и пароль, используемые при подключении к удаленному маршрутизатору.
Необходимо задать учеткне датечне исходящего подключения. которые будут использоваться интерфейсом для подключен*) к удаленному маршрутизатор; ЗтиучвтныеданныедолжнысоатветСгвоВагьучвтнымдамчымвноаящого , , подключения на этом уделанном маршрутизатора- ,
Дмяпользователя
Доме»
Пароль _
Пдатверждениз
<Назад | Далее» ~ | ^OtMp^\J
Рис. 10.35. Настройка учетной записи для туннеля
& Routing and Remote Ai c rs*.
j] Действие £ид <| ф» »р ®|® X й* Q 0^' Ег?‘*
ВИИИИИ
Структуре 1
Routing Interfaces
i ^ Routing and Remote Access5
i i S Server Status1
IAN end Pemand Dlel Interfaces
1 Type
.1 Sfceew.. .
1 Connection 5.. ■ 11
@ENG29
Demand-dial
Enabled
Connected;
i IS @ BOBCATt
@GRD105
Demand-dial
Enabled
Connectedi
:^ Routing Interfacess
^Internal
Internal
Enabled
Connected!
i i -Д Remote Access Clients (9) i
@1138
Demand-dial
Disabled
Unreachable<
:, " POrtS!
@LIG50
Demand-dial
Enabled
Connected■
; ft; -^ IP Routing$
^ Local Area Connection
Dedicated
Enabled
Connected^
:уч ..^ Remote Access Policies ?
^Loopback
Loopback
Enabled
Connectedi;
•&• ® Remote Access Logging ;
@M207
Demand-dial
Enabled
Connectedi
@MZ30
Demand-dial
Enabled
Connectedi
@N175
Demand-dial
Enabled
Connected;
@R3
Demand-dial
Enabled
Connected:
@RCV37
Demand-dial
Enabled
Connected;
@SH1
Demand-dial
Enabled
Connecting i
Demand-dial"
- Enabled
Disconnected J
11ill
1
Рис. 10.36. Состояние нового интерфейса
У нового интерфейса есть статус (Status) который может быть Enabled (разрешен) или Disabled (запрещен — администратор волен менять статус в любое вре-. мя). Как несложно догадаться, статус Disabled запрещает использование этого , интерфейса на сервере. Также каждый интерфейс имеет статус соединения j (Connection Status), который может быть Connected (интерфейс подключен, илй, J иными словами, сервер успешно установил свою часть туннеля), Connecting — Ц
происходит попытка установить туннель, Unreachable (через этот интерфейс дейтаграммы посылаться не будут, как это показано на рисунке 10.36 для интерфейса с названием L138) и Disconnected — отключен, Вновь созданный интерфейс типа DOD VPN поначалу имеет такой статус, до тех пор пока администратор не выберет опцию Connect, щелкнув правой кнопкой мышки на интерфейсе. Там же есть пункт выпадающего меню Свойства (Property), выбор которого приводит к появлению диалогового окна с несколькими вкладками, на которых можно настроить параметры вновь созданного интерфейса (рис. 10.37).
OKI Отмена I
Рис. 10.37. Свойства подключения интерфейса
На вкладке Параметры диалогового окна настройки параметров интерфейса администратор может указать, должен ли интерфейс DOD VPN устанавливаться по требованию или поддерживаться постоянно. Первый вариант подразумевает, что сервер начнет процедуру инициации туннеля, когда он получает дейтаграмму, направленную в сеть, маршрут до которой подразумевает прохождение по туннелю (или, иными словами, отправку через настроенный интерфейс DOD VPN). Другой альтернативой является опция Постоянное подключение, при выборе которой туннель будет устанавливаться, а затем работать постоянно (то есть не разрываться по истечении времени неактивности). По опыту эксплуатации сети более чем с десятью туннелями рекомендуется выбрать именно последний вариант. Служебный трафик туннеля хоть и вносит дополнительные накладные расходы (как с точки зрения пропускной способности, так и в отношении финансовых затрат), они крайне несущественны — в сети, построенной на базе туннелей РРТР и с достаточно интенсивным трафиком между объектами (общим количеством порядка 10), служебный трафик (к которому относятся сегменты
протокола TCP с портом получателя 1723) составляет порядка 1% от суммарного объема трафика, проходящего по всем туннелям. Можно предположить, что такими накладными расходами стоит пренебречь и выбрать вариант, когда туннели поддерживаются серверами постоянно, а не устанавливаются по первому требованию и закрываются по истечении периода неактивности. Дополнительно (рис. 10.37) администратор может настроить еще два параметра, которые способны повлиять на работу туннеля — это Число повторений набора номера и Среднее время между попытками. Применительно к туннелю эти параметры начинают работать в случае, когда туннель оборвался и сервер пытается его восстановить (к сожалению, более подробной информации по этому вопросу не удалось найти даже на сайте компании Microsoft). Параметры, приведенные на рисунке, были выработаны экспериментальным путем при управлении сетью с туннелями. Фактически они означают, что при обрыве туннеля (если, например, пропала связь через сеть Интернет) сервер будет пытаться восстановить его 5000 раз с интервалом между попытками в 5 минут. После этого в случае неудачи интерфейс перейдет в состояние Unreachable.
DOD VPNDOD VPNJj2il
DOD VPN
DOD VPN
Общие j Параметры безопасность 1 Сеть |‘
Параметры безопасности
^ ESsssIffi**®”^ параметры] ]
При проверке используется:
]||й|Безопасный пароль
| Отмене || Отмене |P Tрежется шифрование данных (иначе отключаться!С* Дополнительные (особые параметры]P Tрежется шифрование данных (иначе отключаться!С* Дополнительные (особые параметры]Рис. 10.38. Параметры безопасности туннеляРис. 10.38. Параметры безопасности туннеля
| Отмене |
| Отмене |
P Tрежется шифрование данных (иначе отключаться!
С* Дополнительные (особые параметры]
P Tрежется шифрование данных (иначе отключаться!
С* Дополнительные (особые параметры]
Рис. 10.38. Параметры безопасности туннеля
Рис. 10.38. Параметры безопасности туннеля
Другая вкладка (рис. 10.38) позволяет администратору настроить параметры безопасности применительно к туннелю. По умолчанию предлагается задействовать обычные параметры, которые являются рекомендованными для большинства ситуаций и обеспечивают высокую степень безопасности туннеля — используется безопасный метод проверки пароля (алгоритм MS-CHAP v2) и обязательным условием является шифрование передаваемых данных. Следует отметить, что
администратор имеет возможность достаточно гибко управлять параметрами туннеля, в том числе и настроить туннель таким образом, что будет выполняться, например, только сжатие данных без последующего шифрования; он волен отключить сжатие и оставить только шифрование; задействовать эти две возможности вместе или отключить их вообще (кстати, некоторые примеры перехваченных пакетов были получены в таких условиях). Если при настройке туннеля принимаются установки по умолчанию (рекомендованные), то это означает, что сервер будет пытаться при установке туннеля задействовать алгоритм MS-CHAP (начиная с усовершенствованной второй версии), данные будут сжиматься, а затем шифроваться. В том случае, если администратор хочет провести более гибкую настройку параметров туннеля, он может включить режим Дополнительные (особые параметры) и нажать кнопку Настройка. В результате появится диалоговое окно, показанное на рис. 10.39, где администратор волен выбрать один из четырех возможных вариантов шифрования данных, а также указать разрешенные к использованию алгоритмы аутентификации.
Дополнительные оаронетщ > besonai нот г и
|обяэетвль^^^
| не разрешено (отключиться если требуется шифрование)
у необязательное (подключиться даже без шифрования)hi
обязательное (отключиться если нет шифрования)
самое стойкое (отключиться если нет шифрования)№
8* Разрешить Следующие протоколы. ;
Г" Незашифрованный пароль (РАР).; i
Г Протокол проверки пароля Shiva (SPAP]'
Г* Протокол проверки пароля (CHAP)I ;
Р Протокол проверки пароля Мю<о«Й(М5-СНАР)) j
Г" Разрешить СТарый фагоколМ5-СНАР для Window» 35 I )
Р Протокол проверки пароля Microsoft (MS-CHAP v2) i :
ОК| Отмена |:
Рис. 10.39. Дополнительные параметры туннеля
Обратите внимание, что эти опции влияют на то, как именно будет работать созданный ранее интерфейс DOD VPN при установке одной части туннеля с удаленным сервером. Так, можно уточнить, что требуется обязательное шифрование, и если удаленный сервер настроен на то, чтобы передавать данные без этой процедуры, то интерфейс DOD VPN не сумеет перейти в состояние Connected (подключен). Как видим, есть несколько вариантов поведения при подключении в зависимости от требований к шифрованию данных. Обычно оставляют
настройки по умолчанию, подразумевая обязательное шифрование, и если удаленный сервер его не поддерживает, туннель установлен не будет (точнее, одна его часть — от настраиваемого сервера к удаленному). Далее, администратор может выбрать алгоритмы аутентификации — сервер будет проводить аутентификацию пользователя с удаленным сервером именно по выбранному алгоритму. Учитывая сказанное ранее в этой главе, настоятельно рекомендуется воспользоваться второй версией протокола MS-CHAP как наиболее безопасной. Если оба сервера работают на базе операционной системы Microsoft Windows 2000, то предпочтительно выбрать только указанный алгоритм (MS-CHAP v2), а остальные запретить к использованию.
ООО VPN
: Общие | Парем^ры|Бе$огчсность Сеть |. -;-
::й«| тчннельнь1й протокол точка-точка IPPTP1
А:’''."У': ч : : v 'Х .гЙ^лЖчк? tCskK’.
□Ж Протокол Интернета tf^
Свойств»
- Описание1;
i сетей, обеспеччеакшийсвязь между различными:;
■ взаимодействующими сетямир
OK I Отмена;
Рис. 10.40. Сетевые параметры туннеля
Следующая вкладка диалогового окна настройки параметров интерфейса DOD VPN включает в себя две группы параметров — тип вызываемого сервера VPN и параметры протокола TCP/IP для этого интерфейса при подключении (рис. 10.40). Первая группа позволяет администратору настроить параметры самого туннеля РРТР (а точнее протокола РРР, который является базовым для туннеля), как то задействование протокола LCP, контроль процедуры сжатия и согласование многоканальных подключений. По умолчанию все эти параметры активны, как показано на рис. 10.41. Из них наибольший интерес представляет флажок, включающий или выключающий предварительное сжатие информации перед выполнением процедуры шифрования (технология МРРС). В свою очередь, протокол управления каналом связи (LCP) обеспечивает метод организации, выбор конфигурации, поддержание и завершение работы протокола РРР.
Рис. 10.41. Параметры протокола РРР
Администратор может также настроить параметры протокола TCP/IP для созданного интерфейса DOD VPN. Напомню, что каждый из серверов-партнеров поочередно будет выполнять роль клиента и сервера при установлении туннеля. В роли клиента он отвечает за подключение к удаленному серверу, как это, например, происходит при звонках пользователей в корпоративную сеть по обычному модему. По ходу клиенты получают адресную информацию протокола TCP/IP (включая такие параметры, как шлюз по умолчанию, адреса серверов WINS и DNS и т. п.). Аналогичная ситуация имеет место и при подключении клиента к серверу VPN — он автоматически получает эту информацию от удаленного сервера (как правило, последний задействует протокол DHCP — он опрашивает серверы DHCP в подключенной сети, получает адресную информацию для клиентов, а затем при установлении соединения предоставляет ее). То есть при подключении интерфейс DOD VPN приобретает свой собственный адрес IP и уточняет другие параметры, которые могут быть настроены администратором на серверах DHCP на удаленном объекте, с которым устанавливается туннель. На удаленной сети может работать обычный сервер DHCP, который помимо обслуживания клиентов в этой сети также предоставляет информацию и локальному интерфейсу DOD VPN. Кстати, сервер, отвечающий за установления туннеля, способен выполнять и роль сервера DHCP. По умолчанию параметры протокола TCP/IP интерфейса DOD VPN настроены на автоматическое получение адресной информации и в большинстве случаев эти настройки можно оставить без изменений.
Перейдем к другому, не менее важному аспекту настройки сервера для поддержания туннеля — формированию политики удаленного доступа (Remote Access Polices). Если до этого мы рассматривали параметры интерфейса DOD VPN как бы со стороны клиента (то есть настраиваемый сервер, начиная инициализацию своей части туннеля, выступает клиентом), то теперь перейдем к настройке параметров, определяющих его поведение со стороны сервера, принимающего запросы от удаленных клиентов. Для определения этих параметров как раз и служит политика доступа. Применительно к туннелю РРТР она настраивает параметры, которые будут обязательны для удаленного клиента (или клиентов, если на сервере «сходятся» несколько туннелей) и без учета которых сервер не сможет принять запрос на установку второго направления туннеля (от удаленного сервера к локальному). Даже если локальный сервер VPN установил свою часть туннеля (ведь политика настраивается и на удаленном сервере-партнере, но на обоих серверах параметры политики могут отличаться друг от друга), сам туннель не будет работоспособным, так как требуется обязательная функциональность обоих направлений (применительно к ситуации связи двух локальных сетей
Specify the conditions to'natchSpecify the conditions to'natchNAS-PorbType matches "Virtual (VPNfNAS-PorbType matches "Virtual (VPNf«однобокий» туннель позволит передавать трафик только в одном направлении — здесь начинаются проблемы с маршрутизацией ответного трафика).
Specify the conditions to'natch
Specify the conditions to'natch
NAS-PorbType matches "Virtual (VPNf
NAS-PorbType matches "Virtual (VPNf
лк.,^,;;-....,--^.^^l;.,-j . ., .tlAdd | Somov» j £<Я. j
If a user matches the conditions''
<• 5rent remote access permission1
Г* Веду remote access permission|
Access wil be giantedwnh the prohleyou specify, unless access is overridden on а pet-user basis,
EdtEiofile |
Рис. 10.42. Настройка политики доступа
На рис. 10.42 показано диалоговое окно настройки параметров политики доступа (ее имя «Виртуальная частная сеть»), определяющей те критерии, которые удаленный сервер должен поддерживать при установлении туннеля с локальным сервером. В политике доступа выделяются условия (conditions) и действие, которое должно выполняться при соблюдении этих условий. В нашем примере оба сервера-участника туннеля входят в единый домен (один из ранее отмеченных вариантов организации сети) и они оба используют для туннеля одну и ту же учетную запись домена при проверке имени и пароля пользователя. В том случае, если в сети существуют несколько туннелей и для каждого из них было принято решение задействовать свою доменную учетную запись, то можно посоветовать создать группу в домене, включающую в себя эти специальные учетные записи. Если вернуться к рисунку 10.42, то, как видим, одним из условий является то, что учетная запись, используемая при установлении части туннеля на этот сервер, должна входить в группу Domain VPN remote Users домена TOMTIT. Следующее условие специфичное для туннеля — тип порта NAS (NAS-Port-Type; тип порта сервера удаленного доступа) должен соответствовать Virtual (VPN). В принципе, двух таких условий достаточно для проверки того, что удаленный сервер, устанавливающий туннель с локальным, работает с корректной учетной записью, и того, что устанавливается именно туннель (условие — NAS-Port-Type
matches Virtual (VPN)). Далее следует указать, что именно нужно сделать, если условия соблюдены — разрешить или запретить доступ. Понятно, что следует выбрать опцию, разрешающую доступ, иначе туннель установлен не будет. Помимо условий можно настроить профиль политики доступа (Edit Profile...). При нажатии на соответствующую кнопку откроется диалоговое окно, в котором настройке поддается довольно большое количество параметров, но применительно к туннелю наибольший интерес вызывают две вкладки — аутентификация (Authentication) и шифрование (Encryption).
[tdit Dial in Profile
D.al n Contlranli | IP | Mui hi* |
Authentication | Enciyption | Advanced |
N ЭДЙб|11||||8МВЙ1Й|Я8Я^
Check the authentication method! which ate allowed fot lias connection.
r&terotiiAu^-
Select the EAP -ype which is acceptable toi the policy
|-" й T *1,।
P MicicsdtEtxwtad Authenticate veision 2 ^^.
Г Miaotioil Ereiypted Authenticate (MS-CHAP)
Г Eftcryded Authentication (CHAP) Г ynencypted Authentication (PAP. SPAP]
Unauthenbcated Accent-*■
<™ Alow remote gPPclients toconnedveihoutnegotiaiing ’ 8 any authentication rnethod..'
I ОК | Отмена I
Рис. 10.43. Настройка параметров аутентификации в политики доступа
Рисунок 10.43 показывает содержимое диалогового окна на вкладке Authentication. Здесь администратор может выбрать протоколы аутентификации, которые будут поддерживаться для этой политики доступа (а политика доступа обслуживает как один, так и несколько туннелей). Видно, что предлагаются несколько протоколов на выбор, включая опцию «вообще не проводить аутентификацию удаленных клиентов». В данном случае установлен флажок MS-CHAP v2, и если удаленный сервер попытается задействовать другой алгоритм аутентификации, туннель не состоится. Следующая вкладка (рис. 10.44), которая может предоставлять интерес — Encryption, где администратору позволено задать уровни шифрования данных, поддерживаемые сервером. Сам уровень (за исключением параметра, вообще отключающего шифрование — No Encryption) зависит от длины ключа, который используется при шифровании. Зависимость простая — чем длиннее ключ, тем более устойчивее будут зашифрованные данные к попыткам взлома. В рассматриваемом примере сервер примет любой уровень шифрования
данных, даже в том случае, если эта процедура вообще не будет выполняться. Скорее, последний случай более подходит к тестовым целям, в то время как в рабочей сети рекомендуется выставить только последний флажок (Strongest), подразумевающий задействование ключа длиной 128 бит.
Edit Didi m Profile
г А:^Т^!^^Л^^ '■ ’ >1 ^AA®?'. : >' A ■: ■' L^ •■'.■^:; Mi^ltiiink :' ?: t: .ГА? .r-^iheniicS^^ Enow1*'' ■ > .■.;;. .|:? ;:; :А&^<?ЙРЙ A
^:^OtEl:lhesw^ete^in&^lp^
■;:§&$1^)Ь£$8гее1$$епё^^pfa&/; ■
C s®^: $■&&::«бн1м>МЦн<'&<Ьй&&4]Ь:!: :^:.;.:.:-А$>:.г::ф:;:3:ф:Ь:.<к::.$:.>;.$.х.:.х.;-:.Г.;,.:-:.>:.;-;.^^ ;.•.•:’>::<:. ;< •:;& ::-::.<::>;.?.:.-..;:.::<.:-:.: :.>::>:.>;SA:.':.:.;4:i ГЖ^.ЙадРМ У ^Щ^^ А? ii®AAiAA АЙ^ ^Ai^il^i^^ААЙАЙЖ^^^^^^ ■ ЙA A';,‘УйAriАiA^SA А йЙ^&к! Ah yyyyy :у:^'У йй^ййй^ri ?УМй
■$Й:Й:':^°Ь^Г; id Г; У. <■;: У ::'Й :А;ГГ:; У>; Й АЙ '3
ОК 1 Отмена ] iKi-M-'-'-Tir
Рис. 10.44. Настройка уровня шифрования данных в профиле политики доступа
На этом можно считать что локальный сервер готов к обслуживанию туннеля через интерфейс DOD VPN. Точнее, он готов выполнять функции клиента (интерфейс будет пытаться установить одну составляющую туннеля с удаленным сервером VPN) и сервера (будет готов принять запрос на установление второй части туннеля). Как уже было отмечено, если первая часть процедуры установки туннеля была успешно выполнена, то интерфейс перейдет в состояние Connected (подключен). А когда удаленный сервер VPN успешно установит соединение с локальным (настраиваемым) сервером, на последнем это можно наблюдать в списке удаленных клиентов (Remote Access Clients). Как показано на рис. 10.45, в итоге к локальному серверу было подключено 8 клиентов. Причем это могут быть клиенты туннеля РРТР (удаленные серверы или конечные пользователи, подключающиеся к корпоративной сети через Интернет) или, например, клиенты, входящие в сеть через аналоговые модемы (для службы RRAS оба типа являются, в принципе, равноправными, нужно только учесть это при настройке политик доступа, их может потребоваться создать больше чем одну — одну для клиентов туннеля РРТР, другую для тех, кто работает через модемы).
^ Routinu and Remote A^vs*»
Дейс1вп* §ид $ Ф*
Mglssls
I Remote Actress Clients (8)
U$® Name r :
®TOMTIT\VPN_RCV37
SjTOMTIT\VPN R3
11:55:23
12:32:58
0TOMTIT\VPN_N17S
31:37:57
BjTOMTIT\VPN_MZ30
12:33:47
fiaiOMTITWPN M207
04:07:23
&1TOMTIT\VPN_LIG50
31:37:43
B1TOMTIT\VPN GRD105
12:35:13
QtOMTIT\VPN_ENG29
26:16:42
: Д Routing and Remote Access f Server Status BOBCAT
;; ^ Routing Interfaces
::■ ^ RenhQteACGBi&Ci^
:r S Рогк
i35"^ IP Routing
i$ -^ Remote Access Policies
;Sr$j Remote Access Logging
ICwtaon J Ny^ Ports" |
Рис. 10.45. Список подключенных клиентов
Рисунок 10.45 — «снимок» с работающего сервера, который обслуживает порядка десяти туннелей (используется схема типа «звезда») и в настоящий момент к нему подключено 8 туннелей, каждый из которых представляет некий сервер, работающий на удаленном объекте. Для любого из клиентов можно вызвать диалоговое окно статуса (Status), если щелкнуть на имени пользователя два раза мышкой (рис. 10.46).
Stat us
; Connection.
Duration:12:40-53.
: - Statistics™———— —-
B#tes in:18477915 Bytes out7287738
Franes И80183 Frames о* -46883
Compression и 13%Compression out:25У
-Errors - -—— —- - - -
CRC:'0 Ft«*g-0
Time-out0 Hardware overruns; .0
Alignment0 Buffer overruns;0
- Network registration . .— . —.
IP address:192.1883.147
1FK address:
NetBEUI name:-
AppleTalk address:-
Hgfresh j fieset | disconnect j Oose |
Рис. 10.46. Статус подключенного клиента
Появляющееся диалоговое окно предоставит такую информацию, как количество переданных и полученных по туннелю байтов (включая процент сжатия
в каждом направлении, если, конечно, согласовано использование алгоритма МРРС), время, в течение которого клиент был подключен к серверу (в примере — 12 часов), и адрес IP, который был назначен этому клиенту. Если нужно, администратор может принудительно отключить клиента, нажав кнопку Disconnect, хотя это не закроет весь туннель, а только отключит удаленный сервер VPN от локального. В дальнейшем, если условия связи позволят, удалённый сервер попытается вновь выполнить свою часть подключения. В консоли службы RRAS также есть такое свойство как Ports (порты), которое имеет непосредственное отношение к туннелям РРТР. Применительно к туннелю, порт — это некая точка подключения на локальном сервере. Администратор может настроить определенное количество портов, что аналогично настройке максимального количества туннелей, которые могут «сходиться» на этом сервере.
Структуре |
Ports
Name-..-....1 Device " i Comment' 1 Status '> - I ¥ :
; Д Routing and Remote Access
^ Server Statusi
iЙ-Щ BOBCAT;
“S Routing Interfaces\
iRemote Access Clients (9) Я
Ф- $ IP Routings
IR: ^ Remote Access Policies;
:IS- S3 Remote Access Logging J
S WAN Miniport (PPTP) (VPNS-19)VPNActive
^WAN Miniport (PPTP) (VPN3-20)VPNActive-:
§WAN Miniport (PPTP) (VPN3-21)VPNActive
^WAN Miniport (PPTP) (VPN3-22)VPNActive
@ WAN Miniport (PPTP) (VPN3-23)VPNActive
у WAN Miniport (PPTP) (VPN3-24)VPNActivei
^ WAN Miniport (PPTP) (VPN3-2S)VPNActiveJ
WAN Miniport (PPTP) (VPN3-26)VPNActive1
WAN Miniport (PPTP) (VPN3-27)VPNActivei||!
S WAN Miniport (PPTP) (VPN3-28)VPNActive) Д
WAN Miniport (PPTP) (VPN3-29)VPNActive
^WAN Miniport (PPTP) (VPN3-13)VPNActive;H
§?WAN Miniport (PPTP) (VPN3-14)VPNActive
§v WAN Miniport (PPTP) (VPN3-1S)VPNActive
S WAN Miniport (PPTP) (VPNS-16)VPNActive; j
i^WAN Miniport (PPTP) (VPNS-17)VPNActive
у WAN Miniport (PPTP) (VPN3-18)VPNActiveЙ
Ф Routing and Remote Access
Рис. 10.47. Список активных портов на сервере
На рис. 10.47 показан перечень активных портов. Интересно отметить, что для каждого туннеля (а на момент получения рисунка сервер поддерживал одновременно 9 туннелей) задействуется два порта — по одному для каждого направления туннеля (сейчас на сервере активно 18 портов). Особой важности порты при создании туннелей для администратора не имеют, нужно только определить максимальное количество туннелей, которые сервер в состоянии поддерживать, и настроить соответствующее число портов. При этом различаются порты протоколов PPTP, L2TP и Direct Parallel (прямая связь через параллельный порт компьютера). Из рис. 10.48 видно, что для протокола РРТР настроено 30 портов и, учитывая, что каждый туннель задействует два порта, сервер в такой конфигурации сможет обслуживать до 15 туннелей одновременно. Администратор волен в любой момент изменить количество портов в большую или меньшую сторону.
ESSESSSSM^,^:..' .' и х1
(||^Дж|||в1|в|||^^
touting and Remote Access IRRAS] uses t^e devises feted hebw.
Device< Used ByI type i Numb,, i
;:;- WAN Minipoit (PPTP)RAS/RoutingPPTP30
WAN Miniport (L2TP)NoneL2TP5
Direct ParallelNoneParallel1
OK | Отмена |
Рис. 10.48. Настройка количества портов на сервере
Мы рассмотрели все основные параметры, относящиеся к туннелям на базе протокола РРТР. Как видно, процедура настройки крайне простая и занимает совсем немного времени администратора. За рамками главы остались такие вопросы, как маршрутизация и ведение журнала, но, по мнению автора, они будут понятны и без дополнительного «разжевывания». Ведь после создания интерфейса DOD VPN он может рассматриваться как простой физический интерфейс, и, следовательно, к нему применимы все операции, связанные с маршрутизаций трафика, как к обычному интерфейсу.
Протоколы
В этом приложении перечислены наиболее часто используемые протоколы, а также порты, которые они задействуют. Эта информация будет полезна, если администратору сети требуется настроить на маршрутизаторе защитный экран или списки доступа с целью блокировать или разрешить работу пользователей с тем или иным протоколом. Следует отметить, что некоторые протоколы фигурируют далее в нескольких таблицах.
Таблица 1, Перечень базовых протоколов, работающих в обход UDP/TCP
Протокол
Базовый протокол
Номера используемых портов
Полное название
EGP
IP
8
Exterior Gateway Protocol
GRE
IP
47
Generic Routing Encapsulation
ICMP
IP
1
Internet Control Message Protocol
EIGRP
IP
88
Enhanced Interior Gateway Routing Protocol
Таблица 2. Перечень базовых протоколов, использующих в своей работе UDP/TCP
Протоколы, опирающиеся на TCP/UDP
Базовый протокол
Краткое описание
FTP
TCP
File Transfer Protocol
Exchange
TCP
MS-RPC for Exchange
HTTP
TCP
Hypertext Transfer Protocol
Citrix
TCP
Citrix Published Application — native support 12.1(2)E
Netshow
TCP/UDP
Microsoft Netshow
RealAudio
TCP/UDP
RealAudio Streaming Protocol
r-commands
TCP
rsh, rlogin, rexec
SQL*NET
TCP/UDP
SQL*NET for Oracle
SunRPC
TCP/UDP
Sun Remote Procedure Call
TFTP
UDP
Trivial File Transfer Protocol
VDOLive
TCP/UDP
VDOLive Streaming Video
Протоколы
443
Таблица 3. Базовые протоколы с номерами используемых портов
Протокол
Базовый протокол
Номера портов
Полное название
BGP
TCP/UDP
179
Border Gateway Protocol
CU-SeeMe
TCP/UDP
7648, 7649
Desktop Videoconferencing
CU-SeeMe
UDP
24032
Desktop Videoconferencing
DHCP/Bootp
UDP
67, 68
Dynamic Host Configuration Protocol/ Bootstrap Protocol
DNS
TCP/UDP
53
Domain Name System
Finger
TCP
79
Finger User Information Protocol
Gopher
TCP/UDP
70
Internet Gopher Protocol
HTTP
TCP
80
Hypertext Transfer Protocol
HTTPS
TCP
443
Secure HTTP
IMAP
TCP/UDP
143, 220
Internet Message Access Protocol
IRC
TCP/UDP
194
Internet Relay Chat
Kerberos
TCP/UDP
88, 749
The Kerberos Network Authentication Service
L2TP
UDP
1701
L2F/L2TP Tunnel
LDAP
TCP/UDP
389
Lightweight Directory Access Protocol
MS-SQLServer
TCP
1433
Microsoft SQL Server
NetBIOS
TCP
137, 139
NetBIOS over IP (Microsoft Windows)
NetBIOS
UDP
137, 138
NetBIOS over IP (Microsoft Windows)
NFS
TCP/UDP
2049
Network File System
NNTP
TCP/UDP
119
Network News Transfer Protocol
Notes
TCP/UDP
1352
Lotus Notes
NTP
TCP/UDP
123
Network Time Protocol
PCAnywhere
TCP
5631, 65301
Symantec PCAnywhere
PCAnywhere
UDP
22, 5632
Symantec PCAnywhere
POP3
TCP/UDP
ПО
Post Office Protocol
PPTP
TCP
1723
Point-to-Point Tunneling Protocol
RIP
UDP
520
Routing Information Protocol
RSVP
UDP
1698,1699
Resource Reservation Protocol
SFTP
TCP
990
Secure FTP
SHTTP
TCP
443
Secure HTTP
SIMAP
TCP/UDP
585, 993
Secure IMAP
SIRC
TCP/UDP
994
Secure IRC
SLDAP
TCP/UDP
636
Secure LDAP
SNNTP
TCP/UDP
563
Secure NNTP
продолжение
Таблица 3 (продолжение)
Протокол
БазовыйНомераПолное название
протоколпортов
SMTP
TCP25Simple Mail Transfer Protocol
SNMP
TCP/UDP161,162Simple Network Management Protocol
SOCKS
TCP1080Firewall security protocol
SP0P3
TCP/UDP995Secure POP3
SSH
TCP22Secured Shell
STELNET
TCP992Secure TELNET
Syslog
TCP514System Logging Utility
Telnet
TCP23Telnet Protocol
X Windows
TCP6000-6003 XI1, X Windows
Следующая информация адресована администраторам сетей, построенных на базе сетей Microsoft Windows. Она способна помочь в ситуации, когда необходимо блокировать трафик, относящийся к сетям Microsoft Windows. Можно предположить, что наиболее востребованной она будет, когда администратору нужно разграничить части внутренней сети, оставляя, однако, связь между серверами и службами Microsoft. Важно отметить, что представленные в табл. 4 данные требуют периодического обновления, так как при появлении новых версий продуктов номера используемых портов могут меняться. Источник информации: www.microsoft.com.
Таблица 4. Протоколы, задействуемые службами в сетях Microsoft Network
Сервис
Протокол
Запрашиваемые порты для взаимодействия клиент-сервис
Входящий порт сервиса
Исходящий порт сервиса
Функция browsing
UDP (запрос)
137
137
137
(NetBIOS поверх TCP/IP)
UDP (ответ)
138
138
138
Служба DHCP lease
TCP (запрос)
67
TCP (ответ)
68
Служба DNS (запросы от клиента к серверу)
TCP/UDP (зависит от реализации)
1024-5000
53
53
Служба DNS (запросы между серверами)
TCP/UDP (зависит от реализации)
53
53
53
Служба DNS (передача зоны primary a secondary)
TCP
53
53
1024-5000
Служба DNS (передача primary а secondary soa record)
UDP
53
53
53
Сервис
ПротоколЗапрашиваемые Входящий Исходящий
порты дляпортпорт сервиса
взаимодействия сервиса клиент-сервис
Общие ресурсы в сети
иОР(разрешение137
имени)
TCP (сеанс)139
Протокол
FTP — данные
TCP20
Протокол FTP
TCP21
HTTP
TCP80
HTTP (SSL)
TCP443
IMAP4
TCP143
IRC
TCP531
LDAP
TCP389
LDAP (SSL)
TCP636
Membership MSN
Microsoft Chat
TCP'569
TCP (сервер-сервер)6665
TCP (клиент-сервер)6667
NetMeeting
TCP (обнаружение522
пользователя)
TCP (T.120)1503
TCP (звуковой1731
вызов)
UDP (протокол RTP)Динамический
NetShow
UDPTcp/1755Tcp/1755Udp/1755
TCP17551755
HTTP808080
Групповая доставка1-650001-650001-65000
224.0.0.1-
239.255.255.255
DCOM1351351024-5000
NNTP
TCP119
POP3
TCPno
PPTP
PPTP (protocol 47)1723
Общий принтер в сети
UPD (разрешение137
имени)
TCP (сеанс)139
RADIUS
UDP1645 или 1812
(аутентификация)
продолжение ^
Таблица 4 (продолжение)
Сервис
Протокол
Запрашиваемые
Входящий
Исходящий
порты для
порт
порт сервиса
взаимодействия
сервиса
клиент-сервис
UDP (учет)
1646 или 1813
RPC (например, User Manager Server Manager и т. д.)
TCP
135
TCP (сеанс)
Динамический
SMTP
TCP
25
SNMP
UDP
161
SNMP Trap
UDP
162
SQL Server (TCP)
UDP/TCP (разрешение имени)
53
TCP (сеанс)
1433
SQL Server (RPC client, supports encryption over NetBEUI, IPX/SPX, TCP/IP)
UDP (name lookup)
137
Telnet
TCP
23
Регистрация WINS
UDP (NetBIOS поверх TCP/IP)
137
Репликация серверов WINS
TCP
42
Аутентификация Windows Challenge/ Response
TCP (NetBIOS поверх TCP/IP)
139
X400
TCP
102
Алфавитный указатель
А
ААА, 365
АСК, 155, 190
ACL, 344
Active Directory, 387, 411
ADSL, 308
any, ключевое слово, 351
AR, 324■
ARP
запрос, 171
ARP spoofing, 123
ARP-таблица, 120
очистка, 121
Asymmetric Digital Subscriber Line, 308
ATM, 322
Automatic Broadcast Control, 377
AUX, 50
В
backlog, 194, 195
banners, 66
Be, 326, 335
Be, 326
BECN, 325
c
CAR, 334
CBQ, 267
CDP, 135
CHAP, 368,369
chap, ключевое слово, 369
Checkpoint FirewaII-1, 239, 358
CIDR, 109
CIR, 324, 326, 335
Cisco ConfigMaker. 22, 67, 117, 119
v2.4, 87
Cisco IOS
буфер истории, 34
встроенный отладчик, 137
интерфейс командной строки, 28
команды проверки аппаратных ресурсов, 52
образ, 39
подавление источника, 164
Cisco IOS (продолжение) приглашение, 29
в режиме подконфигурации, 32
режимы конфигурации, 29
списки доступа, 344
Cisco IOS Firewall Feature Set, 358
Cisco Systems, 17
CiscoWorks 2000, 58
CLI, 27
Communication Administratively Prohibited, config, ключевое слово. 32
CTY/CON, 50
CWND, 230
D
DE, 324
decoy-сканировапие, 171
default, ключевое слово. 370
description, 131
Destination Host Unknown, 165
Destination Network Unknown, 165
DF, 46, 235
DLCI, 322
DNS, 126
сервер, настройка адресов, 127
DoS, 194,241
DWFQ, 271
Dynamic Host Configuration Protocol, 178
DynamicBacklogGrowthDelta, 199
E
eEye Iris Network Traffic Analizer, 141
enable password, 30, 69
enable secret password, 30, 69, 70
EnableDynamicBacklog, 198
Ethereal, 143
и WinDump, 143
Exec, заголовок, 66
exec, ключевое слово, 372
F
Fast Retransmit, 226
FCS, 322
FECN, 325
FIFO, 246
FQ, 267
Fragmentation needed and DF flag Set, 165
Frame Relay, 320
FRTS, 334, 336, 337
FTP, 225
G
G.shdsl, 310
Gigabit Ethernet, 211
GTS, 334, 336
GuardianPro, 243
v5, 243
v5.02, 364
v5.0x. 201
H
Host Precedence Violation, 165
Host Unreachable, 164
Host Unreachable for Type of Service, 165
host, ключевое слово, 351
I
IAS, 368
ICMP, 139, 235
address mask reply, 179
address mask request, 178
destination unreachable, 164, 181
echo reply, 156
echo request, 151
host unreachable, 168
information request, 178
parameter problem, 180
port unreachable, 170
protocol unreachable, 168
redirect, 171
source quench, 160
маршрутизаторы Cisco Systems, 164
нестандартные сообщения, 163
sweep, 154
time exceeded, 171,181
timestamp request, 176, 177
авторизованный агент, 179
временная синхронизация, 176
данные
шаблон заполнения, 159
и UDP, 170
и UNIX, 153
и защитный экран, 162
и модель OSI, 140
идентификатор и номер
последовательности, 152
классификация сообщений, 150
опрос работающих хостов, 154
перенаправление. 172
сообщение
поле данных, 157 сообщения
обязательные поля, 150
запросов, 151
таймеры, 169
тип и код сообщения, 147
типы сообщений, 148
условия формирования сообщений, 149
фильтрация сообщений, 188
фрагментация, 158
широковещательный трафик, 155
IDS, 198,361,363
IETF, 219
IIS, 200
INTERNETWORK CONTROL, 163
InterNTC, 82
IP
дейтаграмма
смещение фрагмента, 186
идентификатор дейтаграммы, 184
флаг More Fragments (MF), 183
фрагментация, 183
IP identification number, 183
IP Precedence, 249, 251
IP Subnet Calculator, 87
ip unnumbered, 118
IP-адрес
зарезервированные, 79
классы, 77, 80
диапазон значений, 79
формат, 77
IP-заголовок
бит DF, 46, 235
поле TOS, 249, 250, 251
IP-сеть
качество обслуживания, 249
поле IP Precedence, 249, 251
поле TOS, 250
рекомендации RFC 1812, 251
контроль перегрузок, 228
протокол RSVP, 228
планирование, 86 предотвращение перегрузок алгоритмы, 229 медленный старт, 229 1Р-телефония, 378, 379 ISN, 190 ISS, 363
к
keepalive, сообщения, 43
Kerio WinRoute Pro, 385
L
Layer-2 Forwarding, 382
Layer-2 Tunneling Protocol, 382, 383
Layer-3 Tunneling, 384
Link Control Protocol, 418
LMI, 327
local, ключевое слово, 369
log, ключевое слово, 357
Login, заголовок, 66
loopback, 129
м
МАС-адрес
префикс производителя, 146
MaximumDynamicBacklog, 199
Microsoft Active Directory, 154
Microsoft Network Monitor, 141
Microsoft Point-to-Point Compression, 401
Microsoft Point-to-Point Encryption, 383, 401
Microsoft SMS Server, 141
Microsoft Windows 2000
и технология VPN, 386
Microsoft Windows 2000 Professional, 152
MINCIR, 339
MinimumDynamicBacklog, 198, 200
MOTD, заголовок, 66, 67
MPPE, 383
MS-CHAP, 368
MSS, 212,235
MTU, 45, 74, 183, 187. 235
Path MTU. 46
Path MTU Discovery, 234
правило выбора, 45
N
NAR, 245
NAT, 238
таймер пеактивности, 240
NBMA, 329
NETWORK CONTROL, 163
Network Unreachable, 164
Network Unreachable for Type of Service, 165
nmap, 154, 187
no, ключевое слово, 37
none, ключевое слово, 372
NVRAM, 60
О
one-way, алгоритм шифрования паролей, 70
overload, ключевое слово, 241
Р
РАР, 368. 369
password, ключевое слово, 371
PathMTU, 46
Path MTU Discovery, 234
параметр реестра
EnablePMTUBHDetect, 236
EnablePMTUDiscovery, 236
ping, 151, 157
ping sweep, 154
PMTU, 46
Point-to-Point Tunneling Protocol, 374
Port Unreachable, 164
PPP, 369
PPP IP Control Protocol, 424
PPTP
управляющее соединение, 391
Precedence cutoff in effect, 165
Protocol Unreachable, 164
proxy ARP, 245
proxy server, 387
PSH, 217
PVC, 130,321
R
RADIUS, 366
radius-server, ключевое слово, 373
RAM, 18
rep, сервер, 61
RCV.NXT, 204
receive timestamp, 177
RED, 252,255
RedHat Linux 6.2, 157
RFC 1009, 96
RFC 1027, 121
RFC 1035, 66
RFC 1058, 292, 293, 295
RFC 1122, 151, 157, 177, 229
RFC 1191, 46, 139
RFC 1256, 139
RFC 1323, 212, 214, 224
RFC 1349, 250
RFC 1388, 100
RFC 1517, 109
RFC 1518, 109
RFC 1519, 109
RFC 1520, 109
RFC 1701, 393
RFC 1702, 393
RFC 1812, 81, 160, 178, 181, 250, 251, 360
RFC 1918, 238
RFC 2118, 401
RFC 2205, 229
RFC 2759, 420
RFC 3078, 401
RFC 3079, 423
RFC 791, 72, 181
RFC 792, 149, 152
RFC 793, 189, 224
RFC 826, 119
RFC 896, 139
RFC 950, 82, 87, 139
RFC 972, 139
RFC 990, 76
RFC 997, 76
RIP, 276, 290, 291, 299
RIP-1. 96, 97, 295
ROM Monitoring (ROMMON), 32
round-robin fashion, алгоритм, 262
Round-Trip Time, 159
RRAS, 239
RST, 155, 362
RSVP, 228
RTO, 223, 225, 226
RTT, 225
running-config, ключевое слово. 65
RWIN, 235
s
SACK, 219
SDH, 211
Simple Service Discovery Protocol, 170
SND.NXT, 204
SND.UNA, 204
Snort Intrusion Detection System, 144
Source Host Isolated, 165
Source Route Failed, 165
SRTT, 223, 225
SSTHREST, 232
start-stop, ключевое слово, 372
startup-config, ключевое слово, 65
station address, 41
SuperScoute for ISA Server, 387
SurfControl, 387
SYN, 190
Sy n Attack Protect, 196
Syslog, 58
сообщения, 58
T
TACACS+, 366
tacacs+, ключевое слово, 371
tacacs-server, ключевое слово, 373
ТСВ. 204
переменные, 204
RCV.NXT, 204
SND.NXT, 204
SND.UNA, 204
TCP
сегмент, 147
TCP Intercept, 200
TCP Path MTU Discovery, 234
TCP Timestamps, 224
TCPdump, 142
TcpMaxConnectResponseRetransmissions, 197
TcpMaxHalfOpen, 196
TcpMaxHalfOpenRetried, 196, 197
ТСР-скаиирование, 155
Telnet, 376
Telnet, сеанс.
завершение, 135
подавление, 133
просмотр отладочной информации, 137
управление маршрутизатором, 133
Timestamp Echo Reply, 224
Timestamp Value, 224
TOS, 250
transmit timestamp, 177
TTY, 50
tunnel, 129
two-way, алгоритм шифрования паролей, 70
и
UDP. 170
V
Virtual Private Netowork, 374
VLSM, 96
VPN. 173, 374
и атаки DoS, 412
инкапсуляция данных, 392
интерфейс DOD, 429
топология туннелей, 397
управляющее соединение, 414
VPN, port mapping, 408
VTY, 50
w
WFQ, 267.
WIC-2T, 309
WIC-2T, 310
Windows 2000 Service Pack 2, 402
Windows Sockets, 195
WinDump, 142
параметры командной строки, 142
WRED, 255
X
xDSL. 157,286
A
автоматический контроль широковещательных пакетов, 377
авторизация удаленного доступа, 371
административно заданное расстояние, 300
по умолчанию, 301
административное расстояние, 300
адрес
внутренний, 238
глобальный, 241
частный, 241
интерфейса маршрутизатора
вторичный, 117
первичный, 116
открытый, 238
адрес (продолжение')
разрешение, 120
обратное, 120
сервера DNS, 127
трансляция, 238
динамическая, 242
приоритеты, 244
статическая, 242
таймер неактивности, 240
адресное пространство организации
рекурсивное разбиение, 99
акронимы команд, 36
алгоритм
DES, 422
MD4, 423
MS-CHAP, 433
RC4, 401
SHA-1, 423
round-robin fashion, 262
быстрой повторной передачи, 226
параметр реестра TcpMaxDupAcks, 228
временных отметок, 224
масштабирования окна, 212
медленного старта, 229
алгоритмы маршрутизации, 273
внутридомеиные, 275
динамические, 274
междоменные, 275
многоадресные, 275
одноадресные, 275
одномаршрутные, 274
статические, 274
стоимость доставки, 273
требования, 273
анализатор трафика
Ethereal, 143
аппаратный адрес, 146
асинхронный порт (TTY), 50
атака
address spoofing, 358
ARP spoofing, 123
Cisco ident, 362
fraggle, 360
RIP Entry Added, 306
RIP Entry Timeout, 306
Smurf, 156, 158
основанная на фрагментации
IP-дейтаграмм, 362
атаки типа DoS, 194,241
Land, 201
Ping Of Death, 363
smurf, 359
stream.c, 201
TCP SYN flooding, 194, 195, 364
' DynamicBacklogGrowthDelta, 199
EnableDynamicBacklog, 198
MaximumDynamicBacklog, 199
атаки типа DoS (продолжение)
MinimumDynainicBacklog, 198, 200
SynAttackProtect, 196, 197
TcpMaxConnectResponseRetransmissions, 197
TcpMaxHalfOpen, 196
TcpMaxHalfOpenRetried, 196, 197
TearDropFragmentation, 75
шторм запросов TCP SYN, 194, 195, 196, 364
аутентификация, 387
MS-CHAP v2, 418
no протоколу RADIUS, 368
Б
баннеры (заголовки), 66
безадресные интерфейсы, 317
безопасность
доступа к маршрутизатору, 68
сети, составляющие, 362
система обнаружения атак, 363
удаленного доступа
авторизация, 366
, аутентификация, 365
настройка технологии ААА, 369
технология ААА, 365
учет, 366
бесклассовая маршрутизация, 109
бит
DE, 324
DF, 46,235
синхронизации, SYN, 190
буфер истории Cisco 1OS, 34
буферы сетевых пакетов, 53, 54
проверка состояния, 53
счетчик попаданий, 55
быстрая повторная передача, 226
параметр реестра TcpMaxDupAcks, 228
В
вес пакета, 271
виртуальное соединение Frame Relay, 321
постоянное, 321
виртуальный порт (VTY), 50
внутренние адреса, 238
глобальные, 241
частные, 241
внутренние часы, 58
настройка, 58
синхронизация на всех маршрутизаторах, 59
внутридомеиные алгоритмы маршрутизации, 275
временная синхронизация, 176
временные отметки, 176
временных отметок, алгоритм, 224
RTO, 225
RTT, 225
параметр реестра
TcpMaxConnectRetransmissions, 225
TcpMaxDataRetransmissions, 225
временных отметок, алгоритм (.продолжение) поле
Timestamp Echo Reply, 224
Timestamp Value, 224
встроенный отладчик Cisco IOS, 137
выбор
маршрута, 275
стратегии очередей, 271
Г
глубина очереди
настраиваемой, 264
с приоритетами, 261
группы пользователей, 388
д
дейтаграмма, 147
IP, 72
формат заголовка, 73
динамическая трансляция адреса, 242
динамические алгоритмы маршрутизации, 274
доступ к маршрутизатору
технология ААА, 370
драйвер WinPcap, 142
Ж
журнал
на маршрутизаторе, 57
уровни сообщений, 57
отбрасывания трафика по правилам списков доступа, 357
3
завершение
сеанса, принудительное, 132
сеанса Telnet, 135
заголовки (баннеры), 66
Ехес, 66
Login, 66
MOTD, 66, 67
настройка, 67
заголовок IP
бит DF, 46, 235
поле IP Precedence, 249, 251
поле TOS, 250
задержка выпуска в очереди FIFO, 247
запись таблицы маршрутизации, 293, 300
защитные экраны
опыт эксплуатации, 386
защитный экран, 201
Checkpoint Firewall-1, 358
Cisco IOS Firewall Feature Set, 358
Cisco PIX Firewall, 246
GuardianPro, 243
v5, 243
v5.02, 364
v5.0x, 201
технология NAR, 245
защитный экран (продолжение)
Kerio WinRoute Pro, 385, 408, 410
Microsoft ISA Server, 386, 412
журнал работы, 387
защита от атаки TCP SYN flooding, 201
контроль действий пользователя, 387
доступа к сайтам Интернета, 387
кэширование запросов, 386
настройка, 388
для VPN, 409
правила фильтрации, 387
И
имя
маршрутизатора
ограничения длины, 66
по умолчанию, 66
рекомендации RFC 1035, 23
инкапсуляция, 74
ARPA, 121, 130
интерфейс
lOBaseT, 376
недостатки, 378
DOD (Dial-on-Demand), 390
RS-232, 377
Serial
подключение, 42
типы кабелей, 42
V.35, 16,311,375,378
длина кабеля, 15
командной строки Cisco IOS, 27
настройка описания, 131
пропускная способность, 45
просмотр информации о настроенном
протоколе, 56
статистика работы, 43
статус, 43, 44
канального уровня, 43
физического уровня, 43
интерфейсы, 18
аппаратные, 40
именование и нумерация, 18
логические, 129
loopback, 129
tunnel, 129
подинтерфейсы, 130
физические, 128
К
кадр, 147
кадр Frame Relay
бит
BECN, 325
FECN, 325
структура, 322
калькулятор хэш-значений, 422 каналы связи, избыточные, 285 качество канала связи, 312, 379
характеристики провода, 376 качество обслуживания в 1Р-сетях, 249
поле
IP Precedence, 249, 251
TOS, 250
рекомендации RFC 1812, 251 клавиша Tab, при вводе команд, 37 ключевое слово
any, 351
chap, 369
config, 32
default, 370 DF, 169 exec, 372 host, 351 local, 369 log, 357 no, 37
no ip unreachable, 168 none, 372 overload, 241 password, 371 radius-server, 373 running-config, 65 start-stop, 372 startup-config, 65 tacacs+, 371 tacacs-server, 373
команда
aaa accounting, 372
aaa authentication, 369
aaa authorization network, 372
aaa new-model, 369 access-list, 348, 355 arp timeout, 121,124 bandwidth, 45, 229 cdp holdtime, 136 cdp timer, 136 clear arp-cache. 121 clear host, 128 clear line, 132 clock, 36
configure memory, 62
configure network, 63
configure terminal, 31,37,62
configure overwrite-network, 66 custom-queue-list, 265 debug, 137 debug ip rip, 296 description, 131 disable, 30 enable, 30 encapsulation, 131
encapsulation frame-relay, 326, 337
команда (продолжение)
end, 63
erase, 66
exec timeout, 38
exec-timeout, 132
exit, 32
fair-queue, 268
frame-relay adaptive-shaping, 339
frame-relay class, 338
frame-relay custom-queue-list, 343
frame-relay interface-dlci, 331
frame-relay traffic-rate, 338
group-range, 370
hostname, 66
interface, 31
ip access-group, 351
ipaddress, 117
ip host, 127
ip ICMP rate-limit unreachable, 169
ip mask-reply, 180
ip nat outside, 242
ip redirects, 176
ip rsyp bandwidth, 229
ip tcp intercept list, 201
ip tcp path-mtu-discovery, 234
ip tcp selective-ack, 220
ip tcp timestamp, 221
ip tcp window-size, 214
ip unnumbered, 118,317
line, 132
login, 68
map-class frame-relay, 337
network, 299, 306
no cdp enable, 136
no cdp run, 136
no ip domain-lookup, 126
no ip proxy-arp, 122
password, 68
ping, 127, 236
ppp authentication, 370
priority-group, 259, 260
priority-list, 258
queue-list, 263
queue-list queue limit, 266
radius-server host, 373
random-detect, 255, 256
random-detect precedence, 255
redistribute static, 305
resume, 134
router igrp, 306
service password-encryption, 70, 371
service timestamps log datetime, 358
show, 37
show arp, 121
show buffers, 53
show cdp entry, 136
show cdp neighbors, 135
show cdp neighbors detail, 136
команда (продолжение)
show clock. 58
show controllers, 41
show flash. 39
show frame-relay pvc, 332
show hosts, 128
show interface serial 1, 311
show interfaces, 121
show ip interface. 49
show ip route, 56
show ip route summary, 56
show line, 51
show logging, 357
show memory, 53
show process memory, 52
show processes cpu, 52
show protocols, 56
show queue, 268
show queuing priority, 260
show running-config, 60, 70
show sessions, 134
show sntp, 59
show stacks, 55
show startup-config, 60
show traffic-shape, 342
show user, 51
show users, 133
show version, 38
terminal, 34
terminal length, 38
terminal monitor, 137
terminal no history, 35
traceroute, 127
tracert, 162,166.182,313
traffic-shape rate bit-rate, 336
username, 371
write erase, 66
write memory, 64, 65
write network, 64
команды
длина, 34
отмена введенной ранее, 37
получение подсказки, 35
получение справки, 35
принцип сокращения, 35
проверки аппаратных ресурсов, 52
коммуникационные шкафы, 380
коммутаторы Hewlett-Packard, 377 компания
RAD Data Communication, 307
RSA Data Security Inc., 401
SurfControl, 387
консольный порт (CTY/CON), 18, 50
защита доступа, 28
кабель, 19
контроллеры, 41
просмотр информации, 41
конфигурационный регистр, 39
конфигурация
загрузочная, 20, 59
просмотр, 60
удаление, 66
хранение, 60
рабочая, 20, 59
копирование в загрузочную, 59
обновление, 62, 63
полная замена, 61
просмотр, 60
резервирование. 64, 65
удаленных маршрутизаторов, 21
файлы. 20
корпоративная сеть, требования к технологии, 323
Л
логические интерфейсы, 129
loopback, 129
tunnel, 129
м
маршрут
критерии выбора, 275
метрика, 14
по умолчанию, 302
настройка, 303
статический. 399
маршрутизатор, 14
Cisco 1720, 310
безопасность доступа, 68
буферы сетевых пакетов, 53, 54
ведение журнала, 57
получатели сообщений, 58
уровни сообщений, 57
имя
ограничения длины, 66
по умолчанию, 66
рекомендации RFC 1035, 23
интерфейсы, 18
логические, 129
настройка описания, 131
физические, 128
классы. 14, 16
комплектация, 310
настройка
начальная, 22
пошаговая, 25
память, 17
NVRAM, 18,60
RAM, 18
ROM, 18
флэш-память, 18
подинтерфейсы, 130
схема именования, 130
проверка аппаратных ресурсов, 52
маршрутизатор (продолжение)
работа со встроенным отладчиком, 137
режимы работы, 33
таблицы маршрутизации, 55, 56
управление через сеанс Telnet, 133
маршрутизация
административно заданное расстояние, 300
значения по умолчанию, 301
алгоритмы, 273, 274
внутридоменные, 275
динамические, 274
междоменные, 275
многоадресные, 275
одноадресные, 275
одномаршрутные, 274
статические, 274
требования, 273
бесклассовая, 109
в виртуальных частных сетях, 396, 399
выбор маршрута, 275
динамическая, 310
избыточные каналы связи. 285
маршрут по умолчанию, 302
настройка, 303
перенаправление, 172
протоколы, 275
длины вектора, 275
политики маршрутизации, 276
состояния канала, 276
стоимость доставки пакета, 273
счет до бесконечности, 289
технология
мгновенного обновления, 291
расщепления горизонта, 290
маска подсети. 84, 178
для стандартных классов IP-адресов, 84
механизм формирования, 85
переменной длины, 96, 179
преимущества, 97
условия, 100
масштабирование скользящего окна, 212
в Windows 2000, 213
мгновенное обновление (triggered updates), 291
медленный старт, 229
междоменные алгоритмы маршрутизации, 275
метрика маршрута, 14, 300
механизм
ip unnumbered, 118
Path MTU, 46
Path MTU Discovery, 234
параметр реестра
EnablePMTUBHDetect, 236
параметр реестра
EnablePMTUDiscovery, 236
SACK, 219
TCP Intercept, 200
разрешения адресов ARP, 120
механизм (продолжение)
скользящих окон TCP, 205
узкие места в сети, 208
фрагментации, 183
многоадресные алгоритмы маршрутизации, 275
модель OSI, 140, 382
модем
ASMi-50, 307
FlexDSL, 376
PairGain, 376
Watson, 310, 376
Натеке FlexDSL, 310
модемы
интерфейсы, 376
регулировка скорости, 377
н
надежность виртуального соединения
(VPN), 413
настраиваемые очереди, 261
глубина, 264
настройка
Frame Relay, 326
управление трафиком, 336, 337, 338, 340
адресного пространства, 313
адресов серверов DNS, 127
внутренних часов, 58
заголовков (баннеров), 67
защитного экрана
рекомендации, 181, 188
маршрута по умолчанию, 303 маршрутизатора
рекомендации, 164, 168, 179
начальная, 22
пошаговая, 25 модемов
рекомендации, 312
Натеке, 310
очередей, 246
RED, 255
WRED, 255
взвешенной справедливой, WFQ, 267
па основе классов, 267
настраиваемых (custom queuing), 261
с приоритетами, 258, 261
подинтерфейса. 331 протокола IGRP, 306 IP, 116 RIP, 299
терминальных портов, 132
технологии ААА, 369
авторизация, 371
ведение учета, 372
список аутентификации, 369
туннеля РРТР, 390
^маршрутизируемые протоколы, 274 номер подсети, ограничения, 87
О
обновление
загрузочной конфигурации, 65
с сервера TFTP, 65
рабочей конфигурации
из флэш-памяти, 63
командой configure memory, 62
командой copy startup-config
running-config, 62
с сервера гср, 63
с сервера TFTP, 62, 63
обратное разрешение адресов, 120
одноадресные алгоритмы маршрутизации, 275
одномаршрутные алгоритмы
маршрутизации, 274
окно, скользящее, 205
узкие места в сети, 208
изменение размера на маршрутизаторе, 214
масштабирование, 212
описание интерфейса (description), 131
организация сети Fame Relay, 323
отключение
рассылки сообщений протокола RIP,
295, 296
открытые адреса, 238
отладчик Cisco IOS, встроенный, 137
отображение портов, 408
отчеты по группам пользователей, 388
очереди
FIFO. 246
задержка выпуска, 247
перегрузка канала связи, 247
RED, 252
настройка, 255
WRED
настройка, 255
взвешенная справедливая (WFQ), 267
вес пакета, 271
настройка, 267
режим DWFQ, 271
выбор стратегии, 271
на основе классов (CBQ), 267
настраиваемые, 261
глубина, 264
и очереди с приоритетами, 262
настройка, 246
проблема голодания
в настраиваемой очереди, 261
в очереди с приоритетами, 258
с приоритетами, 256
глубина очереди, 261
настройка, 258
список приоритетов, 258
п
пакет, 147
память.
NVRAM, 18, 60
RAM, 18
ROM, 18
проверка состояния, 52, 53
флэш-память, 18
параметр реестра
DynamicBacklogGrowthDelta, 199
EnableDynamicBacklog, 198 EnablePMTUBHDetect, 236 EnablePMTUDiscovery, 236
GlobalMaxTcpWindowSize, 214
MaximumDynamicBacklog, 199
MinimumDynamicBacklog, 198, 200
SackOpts, 220
Sy n Attack Protect, 196, 197
Tcpl3230pts, 213,214
TcpDelAckTicks, 221
TcpipblelCMPRedirects, 173
TcpMaxConnectResponseRetransmissions, 197
TcpMaxConnectRetransmissions, 225
TcpMaxDataRetransmissions, 225
TcpMaxDupAcks, 228
TcpMaxHalfOpen, 196
TcpMaxHalfOpenRetried, 196, 197
TcpWindowSize, 212, 213
пароль
enable password, 30, 69
enable secret password, 30, 69, 70
пользовательского режима, 68 шифрование
one-way, 70
two-way, 70
перегрузки в IP-сети
контроль, 228
предотвращение, 229.
протокол RSVP, 228
передача
повторная
алгоритм быстрой повторной передачи, 226
таймер, 221
широковещательная, 80
направленная, 80
ограниченная, 81
переменные ТСВ, 204
RCV.NXT, 204
SND.NXT, 204
SND.UNA, 204
перенаправление сообщений, 395 трафика, 318
перехват трафика
фильтр, 142
Петербургская телефонная сеть, 310
подавление источника, 160
подавление сеанса Telnet, 133
подинтерфейсы, 130
настройка, 331
схема именования, 130
подсеть
маска
для стандартных классов IP-адресов, 84
механизм формирования, 85
переменной длины, 96, 97, 100
формирование, 82
трехуровневая концепция, 82
поле
DLCI, 322
FCS, 322
IP Precedence, 249, 251
Timestamp Echo Reply, 224
Timestamp Value, 224
Time-to-Live, 181
TOS, 250
полносвязная топология в сети Frame Relay, 328, 329
порт
1900, 170
80, 387
8080, 387
порты
терминальные, 50, 68
AUX, 19,50
асинхронный (TTY), 50
виртуальный (VTY), 50
кабель консольного порта, 19
консольный (CTY/CON), 18, 28, 50
настройка, 132
пошаговая настройка маршрутизатора, 25
префикс, сетевой, 77
расширенный, 84
приглашение
Cisco IOS, 29
в глобальном режиме конфигурации, 31
в режиме подконфигурации, 32
проверка
аппаратных ресурсов, 52
память, 52, 53
процессор, 52
состояния буферов сетевых пакетов, 53
программа
Cisco CallManager, 378
Cisco ConfigMaker, 22, 67, 117, 119
Firewalk, 183
nmap, 154, 187
routed, 292
SuperScoute for ISA Server, 387
System Configuration Dialog, 25
tracert, 188
WinDump, 414
прокси-сервер, 387, 388
пропускная способность
TCP, максимальная, 210
методы определения, 210
канала связи на интерфейсе, 45
просмотр
информации об интерфейсе, 56
конфигурации
рабочей, 60
загрузочной, 60
поддерживаемых протоколов, 56
списков доступа, 350
таблицы
маршрутизации, 55
протокола CDP, 135
протокол
ARP, 119, 120
proxy ARP, 120, 121
reverse ARP, 120
атака ARP spoofing, 123
разрешение адресов, 120
. сообщения, 122
BGP-4, ИЗ
CDP, 135
просмотр информации о соседних
маршрутизаторах, 135
CHAP, 369
DHCP, 178
EIGRP, 96
GRE, 391
формат пакета, 392
HDLC, 311 "
ICMP, 139,235,242
I GRP, настройка, 306
IP, 72
атака TearDrop Fragmentation, 75
дейтаграмма, 72
настройка на маршрутизаторах Cisco, 116
списки доступа, 346
формат адреса, 77
IPCP, 424
IPSec, 382,383
IS-IS, 100
L2F, 382,383
L2TP, 383
L2TP, 382
LMI, 327
MS-CHAP, 418,421
OSPF, 96, 100,310,311,312,319
PAP, 369
PPP, 369,383,391
PPP LCP, 418
PPTP, 374,382,383,389
аутентификация удаленного партнера, 417
знаки внимания, 420
недостатки, 405
протокол (продолжение)
сжатие данных, 401 сообщение
OUTGOING-CALL-REPLY, 416 OUTGOING-CALL-REQUEST, 416 START-CONTROL-REPLY, 415 START-CONTROL- REQUEST, 414 уровень безопасности шифрования, 424 фильтрация трафика, 410 шифрование данных, 401
Probe, 120
RADIUS, 366
аутентификация, 368
взаимодействие клиент-сервер, 367
и протокол TACACS+, 368, 369
RIP, 88
атака
RIP Entry Added, 306
RIP Entry Timeout, 306
мгновенное обновление, 291 настройка, 299 отключение рассылки сообщений, 295, 296
расщепление горизонта, 290
RIP, 276
RIP-1, 96,97,295
RIP-2, 100
RSVP, 228
SNMP,. 378
SSDP, 170
TACACS+, 366,368
и протокол RADIUS, 368, 369
TCP, 189
Path MTU Discovery, 234
алгоритм временных отметок, 224 алгоритм масштабирования окна, 212 атака Land, 201 атака streain.c, 201
атака TCP SYN flooding, 194, 195, 196 блок управления передачей (ТСВ), 204 выборочное подтверждение (SACK), 219 задержанное подтверждение. 221 квазисвободное соединение, 199 механизм скользящего окна, 205 пропускная способность, 210 расширения для Windows 2000, 219, 221 стратегии повторной передачи, 218 таймер повторной передачи, 221 узкие места в сети. 208 управление потоком, 214 установление соединения, 191
флаг PSH, 217.
флаги заголовка, 190
UDP, 386
протоколы
немаршрутизируемые, 274
просмотр поддерживаемых протоколов, 56
протоколы (продолжение-)
маршрутизации, 275, 276
длины вектора, 275, 293
политики маршрутизации, 276
состояния канала, 276
процессор, проверка состояния, 52
прямой провод
простая проверка, 376
Р
размер сегмента, максимальный (MSS), 212
разрешение адресов, 120
ARP, 120
локальная таблица соответствия, 127
обратное, 120
разъем
DB-25, 42
V.35, 42
расстояние, административно заданное
значения по умолчанию, 301
расстояние, административное, 300
расстояние, заданное административно, 300
расширение TCP для Windows 2000
выборочное подтверждение (SACK), 219
параметр реестра SackOpts, 220
задержанное подтверждение, 221
параметр реестра TcpDelAckTicks, 221
расширенные списки доступа, 354
расширенный сетевой префикс, 84
расщепление горизонта (split horizon), 290
регистр конфигурации, 39
режимы
конфигурации
Cisco IOS, 29, 31
интерфейсов, 31
портов, 68
подконфигурации, 31'
работы маршрутизатора, 33
ROM Monitoring, 32
глобальный, 31
пользовательский, 29
привилегированный, 30
пароль, 30
разрешения, 30
резервирование каналов связи, 310, 318
резервирование рабочей конфигурации
в памяти NVRAM
командой copy running-config
startup-config. 64
командой write memory, 64
во флэш-намяти, 65
на сервере гср, 65
на сервере ТЕТР
командой copy running-config tftp, 64
командой write network, 64
репликация информации домена, 411
С
сеанс
Telnet
завершение, 135
подавление, 133
управление маршрутизатором, 133
принудительное завершение, 132
просмотр отладочной информации. 137
сегмент TCP, 147
сервер
DNS, настройка адресов, 127
RADIUS, 367
RARP, 120
гср, 61
Syslog, 58
TACACS+, 371
VPN, 389,411
размещение, 411
авторизации, внешний, 69
сервер имен, 170
сетевой префикс, 77
расширенный, 84
сеть
Frame Relay
организация, 323
подинтерфейсы, 130
IP, качество обслуживания, 249
поле IP Precedence, 249, 251
иоле TOS. 250
рекомендации RFC 1812, 251
IP, контроль перегрузок, 228
IP, предотвращение перегрузок
алгоритмы, 229
медленный старт, 229
корпоративная, требования к технологии, 323
синхронизация внутренних часов, 59
система SuperScoute, 388
система обнаружения атак, 363
Snort, 144
система обнаружения атак (IDS), 361
система обнаружения вторжений (IDS), 198 сканирование
определение доступных портов, 181
определение номеров открытых портов, 187
определение схемы маршрутизации, 179
определение типов операционных систем, 178 сканирование портов
подстановка адресов, 171
скользяшее окно., 205
в Windows 2000, 213
GlobalMaxTcpWindowSize, 214
Tcpl323Opts, 213,214
TcpWindowSize, 212, 213
изменение размера на маршрутизаторе, 214
масштабирование, 212
узкие места в сети, 208
служба
DNS, 126
RRAS, 386,389,390
согласования параметров соединения
протокола РРР, 418
соединение
Frame Relay, мультиплексирование, 321
PVC, 130
TCP
квазисвободное, 199
установление, 191
сообщение
IPCP Configuration Ack, 425
PPP CHAP Success, 422
PPP IPCP Request, 424
PPP LCP Configuration Request, 418
сообщения
keepalive, 43, 319, 391
Syslog, 58
инкапсуляция ICMP, 140
маршрутизатора
получатели, 58
уровни, 57
протокола RIP, отключение рассылки,
295, 296
сообщения ICMP redirect, 172
списки доступа, 344
ведение журнала, 357
входящие, 345
диапазоны номеров, 347
добавление правил, 350
задачи, 344
защита от атаки
address spoofing, 358
Cisco ident, 362
fraggle, 360
Ping Of Death, 363
smurf, 359
основанной на фрагментации
IP-дейтаграмм, 362
исходящие, 345
маска шаблона, 348
и маска подсети для протокола IP, 350
просмотр, 350
протокола IP, 346
разрешающее правило (permit), 351
расширенные, 354
создание правил, 348
счетчики пакетов, 358
список
аутентификации, 369
приоритетов, 258
статистика работы интерфейса, 43
статическая трансляция адреса, 242
статические алгоритмы маршрутизации, 274
статус интерфейса, 43
стоимость доставки пакета, 273
стратегии повторной передачи в TCP индивидуальная, 218
пакетная, 218
только первый, 218
счет до бесконечности, при обрыве в сети, 289
счетчики пакетов, для списков доступа, 358
т
таблица маршрутизации, 55, 56, 173, 319
добавление маршрута, 173
запись, 293, 300
петля, 287
просмотр, 55
содержимое, 273
эффект прыжка, 287
таблица протокола CDP, 135
таймер повторной передачи, 221
КТО, 223
оценка SRTT, 223
телефон Cisco АТА 186, 379
терминальные порты, 50
настройка, 132
технология
ААА, 365
ведение учета, 372
контроль доступа к маршрутизатору, 370
настройка, 369
настройка авторизации, 371
список аутентификации, 369
АВС, 377
ADSL, 308
практика применения, 384
Frame Relay, 320
в корпоративных сетях, 323
в сравнении с VPN, 377
виртуальное соединение, 321
гарантированный объем кадров Вс, 326
и ATM, 322
и Х.25, 321
и протокол LM1, 327
мультиплексирование, 321
настройка, 326
организация сети, 323
параметр Be, 326
параметры сервиса, 326
полносвязная топология сети, 328, 329
постоянное виртуальное соединение, 321
пропускная способность CIR, 324, 326
расщепление горизонта, 330
структура кадра, 322
управление трафиком, 333, 334
МРРС, 401
МРРЕ, 401
настройка ключей, 402
NAR, 245
NAT, 238,312
совместно с технологией РАТ, 315
таймер неактивности, 240
NAT/PAT, 408
технология (продолжение)
РАТ, 166
SACK, 414
ТС-РАМ, 310
VoIP, 378
VPN
и Microsoft Windows 2000, 386
xDSL, 286
преимущества, 375
бесклассовой маршрутизации (CIDR), 109
виртуальной частной сети (VPN), 374
мгновенного обновления (triggered
updates), 291
наибольшего совпадения, 108
расщепления горизонта (split horizon), 290
в сети Frame Relay, 330
топология, полносвязная, в сети Frame Relay, 328, 329
трансляция адреса, 238
динамическая, 242
приоритеты, 244
статическая, 242
таймер неактивности, 240
трассировка пакетами UDP, 183
туннель
РРТР, 391
восстановление при обрыве, 432
криптоустойчивость, 405
параметры безопасности, 432
параметры учетной записи, 429
политика удаленного доступа, 435
рабочий режим, 426
установка, 416
VPN, 389
шифрование, 401
У
удаленный доступ, 365
авторизация, 366
аутентификация, 365
учет, 366
управление потоком в TCP, 214
управление трафиком Frame Relay, 333, 334
базовая реализация GTS, 334
и FRTS, 334
настройка, 336
настройка, 338, 340
технология CAR, 334
технология FRTS, 336
настройка, 337
установка и профилактика оборудования, 380
установка туннеля РРТР, 416
учет по технологии ААА, 372
start-stop, 372
stop-only, 372
wait-start, 372
настройка, 372
Ф
файлы
Cisco IOS
схема именования, 40
конфигурации, 20, 59, 62
host, 62
network, 62
резервные копии, 63
образ Cisco IOS, 39
физические интерфейсы, 128
флаг АСК, 155
флаг DF, 165
флаг Don't fragment (DF), 187
флаг More Fragments (MF), 183
флаг RST, 155, 167
флаги заголовка TCP, 190
ACK, 190
PSH, 217
RST, 362
SYN, 190
флэш-память, 18
для обновления рабочей конфигурации, 63
проверка содержимого, 39
формирование подсетей, 82
трехуровневая концепция, 82
фрагментация дейтаграмм IP, 183
X
хэширование при шифровании, 420
ч
часы, внутренние, 58
настройка, 58
синхронизация на всех маршрутизаторах, 59
ш
широковещательная передача, 80
направленная, 80
ограниченная, 81
шифрование и дешифрование трафика, 388
шифрование
Microsoft для канала «точка-точка», 383
RAS, 401
RC4, 401
с разделяемым закрытым ключом, 401
шлюз по умолчанию, 173, 318, 394
щторм запросов TCP SYN, 194—196,364