Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

52 Глава 2. Доставка данных

сократить рабочую нагрузку маршрутизаторов, несмотря на то, что при этом

резко сократилось число доступных для применения адресов. Назначение

крупной сети одного класса В вместо шести классов С сокращало нагрузку

на маршрутизатор, который мог хранить лишь один маршрут для целой ор-

ганизации. При этом в организации, получившей в свое распоряжение сеть

класса В, вероятнее всего, не было шестидесяти четырех тысяч компьюте-

ров, а потому большинство полученных адресов не использовались.

Классовая конструкция адреса подверглась критическим нагрузкам при

быстром росте сети Интернет. В какой-то момент адреса класса В находи-

лись под угрозой полного исчезновения. Быстрое истощение запаса адресов

класса В показало, что трех базовых адресных классов недостаточно: класс А

слишком велик, а класс С имеет слишком маленькую емкость. Для боль-

шинства сетей излишеством был даже класс В, но его приходилось использо-

вать за неимением лучшего.

Разрешить кризис с адресами класса В можно было очевидным путем - при-

нудить организации использовать наборы адресов класса С. Свободные адре-

са этого класса исчислялись миллионами, и такому запасу не грозило скорое

истощение. Однако, как часто случается, очевидное решение оказалось не

таким простым, как на первый взгляд. Каждому адресу класса С должна со-

ответствовать запись в таблице маршрутизации. Распространение миллио-

нов адресов класса С привело бы к быстрому росту таблиц маршрутизации и

перегрузке маршрутизаторов. Решение задачи требовало нового взгляда на

функциональность адресных масок и нового метода распределения адресов.

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

дования, по мере поступления запросов. Метод замечательно работал для не-

большой сети с централизованным управлением. Тем не менее он не учиты-

вал топологию сети, а потому шансы того, что для передачи сообщений в се-

ти 195.4.12.0 и 195.4.13.0 будет использоваться один набор промежуточных

маршрутизаторов, определялись лишь случаем. В результате особую слож-

ность приобретала задача минимизации размера таблицы маршрутизации.

Набор адресов может рассматриваться в совокупности лишь в том случае, ес-

ли адреса представлены последовательными номерами и доступны по одно-

му маршруту. Например, для непрерывного блока адресов поставщика сете-

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

ключений к сети Интернет для этой организации будет ограничено. Но если

один сетевой адрес находится во Франции, а следующий за ним по порядку -

в Австралии, создание общего маршрута для таких адресов становится не-

возможным.

В настоящее время длинные блоки последовательных адресов назначаются

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

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

ных блоков под нужды организаций, выступающих в роли клиентов. Рас-

пределение адресов, отражающее топологию сети, позволяет применять

объединение маршрутов. Известно, что при такой системе сети 195.4.12.0 и

195.4.13.0 достижимы через один и тот же набор промежуточных маршру-

Адрес IP

тизаторов. Более того, можно сказать, что оба адреса принадлежат диапазо-

ну, выделенному Европе: от 194.0.0.0 до 195.255.255.255.

Распределение адресов, отражающее топологию сети, позволяет применять

объединение маршрутов. Чтобы схема заработала, необходима еще и реали-

зация. Пока адреса 195.4.12.0 и 195.4.13.0 интерпретируются в качестве ад-

ресов различных сетей класса С, каждый из них требует отдельной записи в

таблице маршрутизации. Развитие адресных масок не только расширило

емкость адресного пространства, но и улучшило маршрутизацию.

Применение адресных масок вместо устаревших адресных классов для опре-

деления сети адресата носит название бесклассовой междоменной маршру-

тизации (Classless Inter-Domain Routing, CIDR

). CIDR требует модифика-

ции маршрутизаторов и протоколов маршрутизации. Наряду с конечными

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

терпретировать адреса. Маршрутизаторам и узлам необходима информация

о том, как интерпретировать адреса в качестве «бесклассовых» и как приме-

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

поддерживается всеми современными операционными системами и прото-

колами маршрутизации.

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

решение оказалось намного более долговечным, чем предполагали архитекто-

ры. Система CIDR уже много лет является решением проблемы с адресацией

и маршрутизацией и еще много лет останется разумным решением. Что каса-

ется долгосрочного решения проблемы истощения запасов адресов, оно за-

ключается в обновлении системы адресации. В семействе протоколов TCP/IP

за адресацию отвечает протокол IP. Комитет IETF - в целях создания новой

адресной структуры - разработал новую версию IP, названную IPv6.

IPv6

IPv6 - это доработка протокола IP, основанная на двадцатилетнем опыте

практического применения. Исходной причиной создания нового протокола

была угроза истощения адресных емкостей. В IPv6 адрес имеет очень боль-

шой размер - 128 бит, что полностью исключает подобную опасность. Кроме

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

структуру для сокращения нагрузки на маршрутизаторы и оставляют более

чем достаточный для дальнейшего расширения сети объем адресов. Среди

прочих достоинств IPv6:

• Более совершенные механизмы обеспечения безопасности, встроенные в

протокол

• Упрощенные заголовки фиксированной длины с выравниванием слов со-

кращают время на обработку заголовков и общие издержки на передачу

данных

• Улучшенные методы обработки параметров заголовка

Произносится «сайдр».

54 Глава 2. Доставка данных

Несмотря на ряд полезных возможностей IPv6, протокол пока не получил

широкого распространения. Отчасти это происходит потому, что развитие

IPv4, повышение эффективности и производительности аппаратного обеспе-

чения, а также изменения в способах настройки сетей сократили потреб-

ность в новых возможностях IPv6.

Критический дефицит адресов не проявился по трем причинам:

• CIDR придает распределению адресов дополнительную гибкость, что при-

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

грузку на маршрутизаторы посредством объединения маршрутов.

• Скрытые адреса и преобразование сетевых адресов (NAT, Network Ad-

dress Translation) значительным образом сократили потребность в офи-

циальных адресах. Многие организации предпочитают использовать соб-

ственную адресацию для всех систем в своих сетях, поскольку это сокра-

щает затраты на администрирование и повышает уровень безопасности.

• Назначение фиксированных, постоянных адресов используется не столь

часто, как динамическое назначение адресов. Большинство систем ис-

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

токола настройки DHCP.

Появление стандарта IPsec для протокола IPv4 уменьшило потребность в бо-

лее совершенных механизмах безопасности, реализованных в IPv6. Более

того, многие из инструментов обеспечения безопасности, доступные для сис-

тем IPv4, не используются в полном масштабе, и потребность в средствах за-

щиты соединений может быть попросту преувеличена.

В IPv6 устранено разбиение на транзитные участки, более эффективно спро-

ектированы заголовки и осуществляется более совершенная обработка пара-

метров. Эти обстоятельства делают пакеты IPv6 более эффективными в обра-

ботке, чем пакеты IPv4. Однако для большинства систем вопрос о повыше-

нии производительности не стоит, поскольку обработка дейтаграмм IP явля-

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

на периферии сети и обрабатывает сравнительно небольшое число пакетов с

данными. Процессорные мощности и объемы памяти растут с огромной ско-

ростью - при том, что снижается уровень цен на компьютерные устройства.

Мало кто из руководителей рискнет переходить на новый протокол IPv6 в

целях экономии нескольких процессорных циклов, когда можно просто до-

купить аппаратное обеспечение, работающее с проверенным практикой про-

токолом IPv4. От повышения эффективности ощутимо выиграют лишь сис-

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

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

Все эти обстоятельства способствовали снижению востребованности прото-

кола IPv6. Недостаток спроса ограничил число организаций, принявших

IPv6 в качестве основного протокола обмена данными, а необходимым усло-

вием успешного распространения протокола является все-таки большое чис-

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

с другими людьми. Если протоколом пользуется недостаточное число лю-

Архитектура маршрутизации в Интернете

дей, мы просто не ощущаем потребности в этом протоколе. IPv6 по-прежне-

му находится в стадии ранней адаптации. Большинство организаций не ис-

пользуют IPv6 вовсе, а многие из тех, что используют, делают это исключи-

тельно в экспериментальных целях.

1Ру6-взаимодействие между организа-

циями выполняется путем инкапсуляции данных в дейтаграммах IPv4.

Прежде чем протокол станет основным для существующих сетей, должно

пройти какое-то время.

Руководителям действующих сетей не стоит проявлять чрезмерное беспо-

койство по поводу IPv6. Текущее поколение TCP/IP (IPv4), дополненное ме-

ханизмами CIDR и других расширений, вполне соответствует нуждам су-

ществующих сетей. В таких сетях, включая Интернет, еще долго будут ис-

пользоваться 32-битные IP-адреса протокола IPv4.

Архитектура маршрутизации в Интернете

В первой главе рассказывалось о развитии архитектуры сети Интернет. Из-

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

информации маршрутизации по сети.

В исходной структуре Интернета существовала иерархия шлюзов, которая

отражала факт происхождения от сети ARPAnet. При создании Интернета

сеть ARPAnet стала магистралью сети, важным средством переноса трафика

на большие расстояния. Магистраль получила название стержня (core), а

объединяющие систему шлюзы с централизованным управлением - стерж-

невых шлюзов (core gateways).

В описанной иерархии информация о маршрутизации для всех без исключе-

ния сетей, составлявших Интернет, передавалась стержневым шлюзам.

Стержневые шлюзы обрабатывали информацию и обменивались информа-

цией между собой - при помощи протокола взаимодействия шлюзов {Gate-

way to Gateway Protocol, CGP). Обработанная информация маршрутизации

возвращалась внешним шлюзам. Стержневые шлюзы хранили самые точ-

ные данные по маршрутизации для всей сети Интернет.

Применение иерархической модели маршрутизации на базе стержневых

маршрутизаторов имеет серьезные недостатки: любой маршрут должен

быть обработан стержневой системой. Стержень подвергается невероятным

нагрузкам, что и можно было наблюдать по мере роста сети. На сетевом жар-

гоне в таких случаях говорят, что данная модель маршрутизации «плохо

масштабируется». Следствием этого стало создание новой модели.

Даже во времена единого стержня сети вне его существовали группы незави-

симых сетей, именуемые автономными системами. В маршрутизации TCP/IP

термин автономная система (autonomous system, AS) имеет особое значе-

ние. Автономная система - это не просто независимая сеть, но ряд сетей и

Системы Solaris и Linux имеют поддержку IPv6, позволяя экспериментировать с

применением протокола.

Глава 2. Доставка данных

шлюзов с общим механизмом сбора информации маршрутизации и переда-

чи ее другим независимым системам. Информация маршрутизации, кото-

рая передается другим сетевым системам, называется информацией дости-

жимости. Информация достижимости сообщает, какие сети доступны через

данную автономную систему. Во времена единого стержня автономные сис-

темы передавали информацию достижимости системам стержня - для обра-

ботки. Для обмена информацией достижимости со стержнем и другими ав-

тономными системами применялся протокол внешних шлюзов (Exterior Ga-

teway Protocol, EGP).

Новая модель маршрутизации базируется на равенстве наборов автономных

систем, называемых доменами маршрутизации. Домены маршрутизации

обмениваются информацией маршрутизации с другими доменами при помо-

щи протокола граничных шлюзов (Border Gateway Protocol, BGP). Каждый

домен маршрутизации обрабатывает информацию, полученную от других

доменов. В противоположность иерархической модели здесь нет зависимос-

ти от единственной стержневой системы при выборе «оптимальных» марш-

рутов. Каждый домен маршрутизации выполняет такую обработку самосто-

ятельно, и, как следствие, модель лучше поддается масштабированию. На

рис. 2.3 эта модель представлена тремя пересекающимися окружностями.

Каждая окружность обозначает домен маршрутизации. Общие зоны окруж-

ностей являются пограничными, они служат для обмена информацией. До-

мены обмениваются данными, но источником полной информации маршру-

тизации уже не служит одна-единственная система.

В описанной модели существует следующая проблема: как выявлять «опти-

мальные» маршруты в глобальной сети в отсутствие центральной управляю-

щей системы - такой, как стержень, - которой были бы доверены полномо-

чия определения таких маршрутов? Во времена NSFNET для определения

Рис. 2.3. Домены маршрутизации

Таблица маршрутизации

корректности информации достижимости, предоставленной автономной сис-

темой, применялась база данных правил маршрутизации (policy routing da-

tabase, PRDB). Но сегодня NSFNET уже не имеет прежних полномочий.

Чтобы заполнить пробел, NSF, наряду с точками доступа к сети (NAPs,

Network Access Points), объединяющими разнообразных поставщиков сете-

вых услуг, создал серверы арбитров маршрутизации (Routing Arbiter, RA).

Арбитр маршрутизации существует в каждой точке доступа к сети. Этот сер-

вер обеспечивает доступ к базе данных RADB (Routing Arbiter Database),

пришедшей на смену PRDB. Поставщики услуг Интернета могут обращать-

ся к серверам RA для проверки корректности информации достижимости,

предоставленной автономной системой.

База данных RADB является одной из частей реестра маршрутизации сети

Интернет (Internet Routing Registry, IRR). Как и приличествует распреде-

ленной архитектуре маршрутизации, существует целый ряд организаций,

отвечающих за проверку и регистрацию информации маршрутизации. На-

чалась эта работа на европейском континенте. Европейские IP-сети обслу-

живаются организацией Reseaux IP Europeens (RIPE) Network Control Cen-

ter (NCC). Крупные операторы сетевой связи предоставляют реестры своим

клиентам. Все реестры работают с общим форматом данных, основанным на

стандарте RIPE-181.

Многие поставщики услуг Интернета не используют серверы маршрутиза-

ции. Вместо этого они заключают формальные и неформальные двусторон-

ние соглашения, определяющие, какого рода информация достижимости

передается от одного поставщика услуг к другому. По сути дела, речь идет о

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

ставляющие услуги Интернета, критиковали правила маршрутизации по-

ставщиков услуг первого звена, заявляя, что эти правила ограничивают

конкурентную борьбу. В результате многие поставщики услуг первого звена

пообещали опубликовать правила, прояснив, таким образом, основы су-

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

Создание эффективной архитектуры маршрутизации по-прежнему остается

одной из серьезных задач, стоящих перед сетью Интернет, и эта архитекту-

ра с течением времени будет, вне всякого сомнения, эволюционировать. Но

независимо от происхождения, информация маршрутизации в конечном

итоге оказывается на локальном шлюзе, где и употребляется протоколом In-

ternet для принятия решений по маршрутизации.

Таблица маршрутизации

Маршрутизацией данных между сетями занимаются шлюзы, но решения по

маршрутизации приходится принимать всем участникам сети - не только

шлюзам, но и обычным узлам. Для большинства узлов принятие таких ре-

шений подчиняется простому алгоритму:

• Если узел-адресат принадлежит локальной сети, данные доставляются

напрямую адресату.

Глава 2. Доставка данных

• Если узел-адресат принадлежит внешней сети, данные передаются на ло-

кальный шлюз.

Принятие решений по IP-маршрутизации ограничивается простым поиском

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

таблицы маршрутизации (известной также как таблица ретрансляции).

Таблица маршрутизации связывает пункты назначения с маршрутизатора-

ми и сетевыми интерфейсами, которые протокол Internet должен использо-

вать для доставки данных. Взглянем на таблицу маршрутизации Linux-сис-

темы.

В случае Linux-системы воспользуйтесь командой route с ключом -п для

отображения таблицы маршрутизации.

Ключ -п предотвращает преобразо-

вание адресов IP в имена узлов, облегчая чтение результата. Таблица марш-

рутизации для некоторой системы Red Hat:

В системе Linux команда route -n отображает таблицу маршрутизации, со-

стоящую из следующих полей:

Destination

Значение, с которым сопоставляется IP-адрес пункта назначения.

Gateway

Маршрутизатор, через который пролегает путь к указанному пункту на-

значения.

Genmask

Адресная маска, используемая при сопоставлении адреса IP со значением

из поля Destination.

Flags

Определенные характеристики данного маршрута. В Linux существуют

следующие значения флагов:

U Указывает, что маршрут создан и является проходимым.

Н Указывает на маршрут к определенном узлу (большинство маршрутов

прокладывается в направлении сетей).

Для изучения таблицы маршрутизации в системе Solaris 8 применяется команда

netstat.

Пример для системы Solaris приводится далее по тексту.

Флаги R, М, С, I и ! существуют только в Linux. Прочие флаги применяются в боль-

шинстве систем Unix.

Таблица маршрутизации

G Указывает, что маршрут пролегает через внешний шлюз. Сетевой ин-

терфейс системы предоставляет маршруты в сети с прямым подключе-

нием. Все прочие маршруты проходят через внешние шлюзы. Флагом G

отмечаются все маршруты, кроме маршрутов в сети с прямым подклю-

чением.

R Указывает, что маршрут, скорее всего, был создан динамическим про-

токолом маршрутизации, работающим на локальной системе, посред-

ством параметра reinstate.

D Указывает, что маршрут был добавлен в результате получения сооб-

щения перенаправления ICMP (ICMP Redirect Message). Когда систе-

ма узнает о маршруте из сообщения ICMP Redirect, маршрут включа-

ется в таблицу маршрутизации, чтобы исключить перенаправление

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

маршруты отмечены флагом D.

М Указывает, что маршрут подвергся изменению - вероятно, в результа-

те работы динамического протокола маршрутизации на локальной

системе и применения параметра mod.

А Указывает на буферизованный маршрут, которому соответствует за-

пись в таблице ARP.

С Указывает, что источником маршрута является буфер маршрутиза-

ции ядра. В большинстве систем существует две таблицы маршрутиза-

ции: база данных ретрансляции (Forwarding Information Base, FIB),

представляющая для нас интерес, поскольку используется для приня-

тия решений по маршрутизации, и буфер маршрутизации ядра, в те-

чение некоторого времени хранящий данные по источникам и адреса-

там последних использовавшихся маршрутов. Флаг С упоминается в

документации, но мне не приходилось встречать его в отображении

таблицы маршрутизации, даже при включении в вывод буферизован-

ных данных по маршрутизации.

L Указывает, что пунктом назначения маршрута является один из адре-

сов данного компьютера. Такие «локальные маршруты» существуют

только в буфере маршрутизации.

В Указывает, что конечным пунктом маршрута является широковеща-

тельный адрес. Такие «широковещательные маршруты» существуют

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

чается как широковещательным, так и сетевым адресам; так, адресам

172.16.255.255 и 172.16.0.0 системой Solaris, принадлежащей сети

172.16.0.0/16, назначается флаг В.

I Указывает, что маршрут связан с кольцевым (loopback) интерфейсом с

целью иной, нежели обращение к кольцевой сети. Такие «внутренние

маршруты» существуют только в буфере маршрутизации.

! Указывает, что дейтаграммы, направляемые по этому адресу, будут

отвергаться системой. Linux позволяет пользователю самостоятельно

создавать подобные «отрицательные» маршруты. Такие маршруты яв-

Глава 2. Доставка данных

ным образом блокируют прохождение данных в определенном направ-

лении. Данное значение флага существует только в Linux и редко при-

меняется, хотя оно вполне допустимо.

Metric

Определяет «стоимость» маршрута. Метрика используется для сортиров-

ки дублирующих маршрутов, если таковые присутствуют в таблице. Кро-

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

динамической маршрутизации.

Ref

Зафиксированное число обращений к маршруту с целью создания соеди-

нения. Данное значение не используется в Linux-системах.

Use

Число обнаружений маршрута, выполненных протоколом IP.

If асе

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

, через который пролегает данный маршрут.

Каждая запись таблицы маршрутизации начинается с направления. На-

правление - это ключ, с которым сопоставляется IP-адрес пункта назначения

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

направления обычно называют «целевой сетью», хотя диапазон значений

для направления не ограничен адресами сетей. Значение направления может

быть представлено адресом узла, групповым адресом, адресным блоком,

представляющим объединение многих сетей, либо специальным значением -

для маршрута по умолчанию или кольцевого адреса. В любом случае поле

Destination содержит значение, с которым сопоставляется адрес получателя

из заголовка пакета IP при выборе маршрута доставки для дейтаграммы.

Поле Genmask содержит битовую маску, применяемую протоколом IP к ад-

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

адрес значению направления из таблицы. Если бит маски включен, соответ-

ствующий бит адреса получателя является значимым в процессе сопоставле-

ния. Таким образом, адрес 172.16.50.183 соответствует второй записи из

приведенной выше таблицы, поскольку выполнение операции логического

«И» для данного адреса и маски 255.55.255.0 дает в результате 172.16.50.0.

Когда найдено соответствие адреса записи таблицы, поле Gateway позволяет

протоколу IP определить, как достичь указанного направления. Если поле

Gateway содержит IP-адрес маршрутизатора, используется этот маршрутиза-

тор. Если поле Gateway содержит только нули (0.0.0.0, при выполнении ко-

манды route с ключом -п) или символ звездочки (*, при выполнении route без

ключа -п), целевая сеть является подключенной напрямую сетью, а «шлю-

зом» оказывается сетевой интерфейс данной машины. Последнее из полей,

Сетевой интерфейс - это устройство доступа к сети плюс программное обеспече-

ние, используемое протоколом IP для взаимодействия с физической сетью. Более

подробная информация приводится в главе 6.

Таблица маршрутизации

заполняемых во всех записях таблицы, содержит имя сетевого интерфейса,

через который пролегает маршрут. В нашем примере это первый интерфейс

Ethernet (ethO) либо кольцевой интерфейс (lo). Направление, шлюз, маска и

интерфейс полностью определяют маршрут.

Остальные поля (Ref, Use, Flags и Metric) содержат дополнительную инфор-

мацию по маршруту. Значимость этой информации минимальна. Некоторые

системы старательно отслеживают значение счетчика в поле Ref, а прочие,

например Linux, вовсе не интересуются этим полем. Linux подсчитывает в

поле Use, сколько раз потребовалось искать маршрут по запросу протокола

IP из-за того, что он отсутствовал в буфере маршрутизации. Некоторые из

прочих систем отображают в поле Use количество переданных по маршруту

пакетов. Поле Flags содержит информацию, зачастую очевидную и без фла-

гов: флаг U присутствует в определении каждого маршрута, поскольку - по

определению - все маршруты таблицы являются работоспособными, а поле

Gateway позволяет определить факт использования внешнего маршрутиза-

тора без помощи флага G. Значение Metric задействовано только при работе

с одним из вариантов протокола маршрутной информации (Routing Infor-

mation Protocol, RIP). Эта информация не должна отвлекать внимание:

главное в таблице маршрутизации - маршрут, который состоит из адресата,

маски, шлюза и интерфейса.

Протокол IP использует информацию из таблицы маршрутизации (ретранс-

ляции), чтобы строить маршруты для активных соединений. Маршруты,

связанные с активными соединениями, хранятся в буфере маршрутизации.

В Linux посмотреть на буфер маршрутизации можно при помощи команды

route с ключом

-С:

Буфер маршрутизации отличается от таблицы маршрутизации - он отража-

ет установленные маршруты. Таблица маршрутизации используется для

принятия решений по маршрутизации, буфер маршрутизации используется

после принятия решения. Буфер маршрутизации содержит адреса источни-

ка и получателя для сетевого соединения, а также значения для шлюза и ин-

терфейса, через которые было установлено соединение.

Содержимое таблицы маршрутизации удобно изучать на примере Linux, по-

скольку в данной ОС команда route очень четко выводит эту таблицу. Коман-