Библиотека Интернет Индустрии I2R.ru

NAT прекрасно работает... до тех пор, пока вы не начинаете использовать систему сетевого управления на основе протокола SNMP. И тут для решения возникших проблем придется воспользоваться продуктом NNM или CNAT.

Подобно многим другим технологиям, трансляция сетевых адресов (Network Address Translation - NAT) имеет свои преимущества и недостатки. Она позволяет обеспечить маршрутизацию в Интернет и корпоративных сетях трафика сетей с частными адресами, но при этом создает препятствия для управляющего трафика. Это может привести к неприятностям при работе с SNMP-совместимыми средствами системного управления.

NAT модифицирует лишь заголовки пакетов, но не сами содержащиеся в пакетах данные. Именно это и является источником проблем при использовании SNMP - наиболее часто применяемого средства сетевого управления. Помимо прочего, SNMP обеспечивает сбор данных о сетевых адресах устройств. Типичным примером собираемой информации являются данные, хранящиеся в таблице AT Table базы MIB II. Эти записи MIB не транслируются системой NAT.

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

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

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

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

Альтернативный подход заключается в том, чтобы либо управлять сетью изнутри, либо установить внутри сети устройство, которое могло бы передавать нужные данные за ее пределы. Сервис на базе подобных устройств предоставляет компания SilverBack Technologies. Такой же подход реализован в продукте InfraTools фирмы Peregrine Systems. Данный метод требует наличия соответствующего устройства на каждом узле, т. е. вы теряете в масштабируемости. Да, этот метод позволяет избежать переадресации, но в ситуации, когда в одной сети используются дублирующиеся адреса, приводит к чрезмерному дроблению доменов сетевого управления.

Более практичными представляются два других решения. Ни одно из них нельзя назвать совершенным, хотя оба работают. Первое - это бесплатно предлагаемый фирмой Hewlett-Packard вариант конфигурации ее продукта Network Node Manager (NNM), а другой - продукт Comprehensive Network Address Translation (CNAT) от IBM.

Статическая трансляция адресов работает лучше всего

Существуют три разновидности технологии NAT: статическая, динамическая и трансляция с использованием номеров портов, или, в терминологии Cisco Systems, перегруженная. Чтобы обеспечить работу системы сетевого управления вместе с NAT, все адреса должны однозначно отображаться друг на друга, а для этого необходимо обратиться к статической системе NAT.

Поясним, что мы понимаем под NAT. Маршрутизатор NAT устанавливает соответствие адресных пространств и интерфейсов. Интерфейсы могут называться внутренними и внешними, либо истинными и нормализованными, либо закрытыми и общедоступными (открытыми). Чаще всего закрытой стороне соответствуют адреса, назначенные согласно RFC 1918, а открытой - маршрутизируемые адреса Интернет, но для наших целей лучше называть их нерегистрируемыми (частными) и регистрируемыми (уникальными) адресами.

Обычно NAT применяется для отображения на один уникальный адрес множества частных адресов. Этот процесс известен под названиями PAT (Port Address Translation) и NAPT (Network Address Port Translation) и часто используется в сетях SOHO (Small Office/Home Office). Другая разновидность NAT - это динамическая трансляция адресов, при которой используются адресные пулы для временного отображения адресов в сеансах связи между узлами, расположенными по ту и другую сторону от устройства NAT.

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

Ни динамическая трансляция адресов, ни PAT не могут гарантировать уникальности адреса. В случае с PAT для всех устройств используется один и тот же адрес, а это делает статистические данные SNMP ненадежными. Можно вести статистику по типам трафика, но если требуются статистические данные SNMP для какой-то определенной машины, то для ее индексации в базе данных SNMP необходим конкретный адрес. При динамической трансляции устройство, представленное определенным адресом, может быть заменено другим буквально в интервале между двумя командами get протокола SNMP, в результате исказятся статистические данные. Поэтому статическое отображение адресов является обязательным при сборе данных SNMP в сети, где используется NAT.

Как обойти NAT с помощью NNM

Документ "Управление доменами с дублирующимися IP-адресами с помощью NNM" (http://neutron. hp.com/Managing%20Duplicate%20IP%20address% 20domains%20with%20NNM.htm) (автор - Пит Цветкоф из Hewlett-Packard) описывает способ настройки ПО OpenView NNM фирмы HP, модифицирующий действующий по умолчанию метод наполнения БД и дающий возможность NNM работать с информацией об устройствах с дублирующимися адресами.

В данном методе используется файл noDiscovery программы NETMON с записями, содержащими дублированные адреса, что препятствует обнаружению этих адресов станцией сетевого управления, когда она "просматривает" базы данных MIB. Для проверки работы менеджера NNM мы создали записи с адресами 176.230.0.0/16, так как оба наших частных адреса принадлежали к указанному адресному домену. Это удерживало систему NNM от автоматического обнаружения устройств, расположенных на закрытой стороне маршрутизатора NAT.

Добавление устройств, которыми мы хотели управлять на закрытой стороне маршрутизатора NAT, в файл hosts позволило распознавать их имена. Мы имели в своем распоряжении как службу DNS, так и службу NIS и использовали записи, указывающие на открытые адреса. Вспомните, что на открытой стороне все адреса являются уникальными, поскольку это необходимо для маршрутизации и управления.

Наконец, мы добавили устройства в БД при помощи команды loadhosts, применив открытые уникальные адреса. Эти устройства не обнаруживаются автоматически, поскольку записи в базе MIB II указывают управляющей станции на дублирование частных адресов.

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

Как обойти NAT с помощью CNAT

Разработанная группой NetView компании Tivoli Systems (в составе IBM) технология CNAT, транслирует адреса в SNMP-данных, содержащихся в полезной нагрузке IP-пакетов. Здесь используется прямолинейный подход - трансляция частных адресов в открытые и наоборот. Красота этого решения - в его простоте: такую трансляцию может использовать любая система сетевого управления. Но при тестировании CNAT мы обнаружили одну неприятную вещь.

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

Правила трансляции являются двунаправленными. Это означает, что они действуют независимо от направления трафика. Это просто и красиво и не приводит к большой нагрузке на ОС и аппаратные средства. В качестве устройства CNAT мы использовали компьютер IBM RS/6000 43p-140 с 200-МГц процессором PowerPC 604e и объемом ОЗУ 128 Мбайт. Мы не тестировали его на производительность и не создавали большой трафик, и платформа никогда не была загружена более чем на 1%. Фирма IBM утверждает, что ее тесты показывали коэффициент утилизации менее 2% при трансляции 1000 событий в минуту.

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

Например, NAT транслирует частный адрес 10.0.0.1 в публичный адрес 192.155.0.1. Когда пакеты проходят через устройство CNAT, адреса в их заголовках проверяются на совпадение с публичным адресом 192.155.0.1. При обнаружении такового все вхождения адреса 10.0.0.1 в полезной нагрузке SNMP заменяются на 192.155.0.1.

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

CNAT использует наборы правил. Хотя, с точки зрения сервис-провайдеров, многие сети их заказчиков могут иметь повторяющиеся частные адреса, подобные 10.0.0.1; эти наборы правил обеспечивают уникальность информации о производительности и об отказах данных сетей. Это достигается путем использования различных правил трансляции в наборах правил для разных заказчиков.

Например, в приведенной схеме "Как CNAT позволяет обойти NAT" оба заказчика используют частные подсети 176.230.92.0. Одному и тому же адресу 176.230.92.92 соответствуют различные серверы Microsoft Windows NT: сервер 1, связанный с маршрутизатором B, и сервер 2, связанный с маршрутизатором C.

Когда пакет от сервера 1 проходит через устройство NAT, частный адрес этого сервера 176.230.92.92 транслируется в открытый адрес 20.20.92.92. Если пакет от сервера 2 проходит через устройство NAT, частный адрес его источника 176.230.92.92 аналогично транслируется в открытый адрес 30.30.92.92. Когда пакеты от обоих серверов поступают на устройство CNAT, то, несмотря на то что адреса в их заголовках уже оттранслированы, данные SNMP их полезной нагрузки все еще содержат частные адреса из диапазона 176.230. 92.*. Однако IP-адрес 20.20.92.92, содержащийся в заголовке пакета от сервера 1, инициирует выполнение набора правил CNAT, транслирующих все вхождения 176.230.92.* в 20.20.92.*. IP-адрес 30.30.92.92 в заголовке пакета от сервера 2 запускает другой набор правил, транслирующих все адреса 172.230.92.* в 30.30.92.*. Наборы обычно содержат несколько правил трансляции и поддерживают их агрегирование с помощью масок подсетей.

Эта система работала у нас отлично, позволяя управлять серверами 1 и 2, как если бы они имели уникальные адреса. Однако мы обнаружили "утечку" адресов 176.230.*.* на маршрутизаторах NAT - на маршрутизаторе B и маршрутизаторе C. Для станций сетевого управления это выглядело так, как будто адреса 176.230.*.* переходили взад-вперед от маршрутизатора B к маршрутизатору С.

Данный эффект возникает из-за появления открытых адресов в БД MIB главным образом в таблицах IP и AT. С открытыми адресами, конечно, было все в порядке, но при обработке их устройством CNAT они в соответствии с правилами трансляции заголовков сменялись частными адресами. Это просто сводило нас с ума, пока сотрудники IBM не подсказали нам, что правила трансляции работают в обе стороны. Так, если определено, что адреса 176.230. 92.* должны транслироваться в адреса 20.20.92.*, то верно также и обратное. Хотя это упрощает правила и уменьшает объем работы для устройства CNAT, поскольку ему не надо учитывать направление, но также означает, что адреса 20.20.92.* оказываются оттранслированными в адреса 172.230.92.*. А так как другой набор правил переводит адреса 30.30.92.* также в адреса 172.230.92.*, наши станции управления оказались в очень затруднительном положении.

Чтобы выйти из подобной ситуации, необходимо добавить в файл инициализации запись, запрещающую автообнаружение для адресных пространств с дублирующимися адресами 176.230.*.*, точно так, как мы сделали, работая с продуктом NNM. В результате мы могли распознавать сети 20.20.92.* и 30.30.92.* и заполнять базу данных.

Мы узнали, что устройства CNAT разрабатывались с целью замены маршрутизаторов NAT для обеспечения как работы с SNMP, так и трансляции заголовков. Однако IBM скоро обнаружила, что большинство организаций не хотят заменять свои устройства NAT компьютерами общего назначения. Как бы там ни было, если разместить устройство CNAT на границе частной сети, правила трансляции могут быть определены таким образом, чтобы избежать "утечки" адресов.