Протоколы управления сетью

Протокол SNMP

SNMP (англ.Simple Network Management Protocol — простой протокол управления сетью) — это протокол управления сетями связи на основе архитектуры TCP/IP.

Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB — management information base, RFC-1213, -1212).

Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу «система» входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр. В группу «интерфейсы» входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т. д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр. Ниже приведена таблица команд (pdu — protocol data unit) SNMP (Таблица1) и схема запросов-отликов SNMP (Рис. 8):

Таблица1.

Рис. 8. Схема запросов/откликов SNMP

Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (Рис. 9):

Рис. 9. Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы.

Поле версия содержит значение, равное номеру версии SNMP минус один. Поле пароль (community — определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления.

Управляющая база данных MIB

Вся управляющая информация для контроля ЭВМ и маршрутизаторами Интернет концентрируется в базе данных MIB (Management Information Base, RFC-1213 или STD0017). Именно эти данные используются протоколом SNMP. Система SNMP состоит из трех частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент SNMP должен находиться резидентно в памяти объекта управления. SNMP-менеджер может быть частью системы управления сетью NMS (Network Management System), что реализуется, например, в маршрутизаторах компании CISCO (CiscoWorks).

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

Согласно нормативам MIB управляющая информация делится на восемь категорий: (см слайд № 36).

MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки.

Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT.

Протокол DNS

DNS (англ. Domain Name System — система доменных имён) — это система, позволяющая преобразовывать символьные имена доменов в IP-адреса (и наоборот) в сетях TCP/IP.

Домемн — определённая зона в системе доменных имён (DNS) Интернета, выделенная какой-либо стране, организации или для иных целей.

DNS важна для работы Интернета, ибо для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-сервера, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла DHOSTS. TXT, который составлялся централизованно и обновлялся на каждой из машин сети вручную. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня — org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.

Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Как работает DNS?

DNS работает в режиме вопрос/ответ. Допустим Вы ввели в строке своего браузера ipipe.ru. Рассмотрим работу DNS пошагово:

Шаг 1. Ваш браузер об IP адресе ipipe.ru ничего не знает и с запросом IP адреса ipipe.ru, через специальную программу resolver обращается к локальному серверу имен.

Локальный DNS сервер это сервер имен Вашей локальной сети или DNS сервер Вашего Интернет провайдера (если вы используете DialUp). Откуда браузеру известно о существовании этого локального DNS? Спросите Вы. Все очень просто: При настройках сетевого подключения Вы прописываете IP адреса DNS серверов (предпочитаемого и/или альтернативного) один из которых будет отвечать на запросы посылаемые Вашим браузером через resolver — это и есть локальный или местный сервер Вашей сети. Если Вы используете модемное подключение (через телефонную линию) то для Вас местным сервером имен — будет DNS сервер Вашего провайдера. IP адрес этого сервера также будет прописан в настройках сетевого подключения, не зависимо от того как осуществлялась настройка (вручную или автоматически). Вы всегда сможете посмотреть IP адрес Вашего локального DNS сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на Вашем компьютере.

Шаг 2. Запрос на IP адрес ipipe.ru доходит до местного сервера имен. Этот сервер об этом IP адресе ничего не знает, и посылает запрос одному из корневых серверов «.» (root).

Шаг 3. Корневой сервер отдает локальному серверу IP адрес сервера, который поддерживает зону .ru.

Шаг 4. Далее по полученному адресу локальный сервер имен обращается к DNS серверу, который поддерживает .ru.

Шаг 5. Этот DNS сервер по полученному запросу отдает IP адрес сервера, который поддерживает зону ipipe.ru.

Шаг 6. Местный DNS сервер с запросом IP адреса ipipe.ru обращается к DNS серверу зоны ipipe.ru.

Шаг 7. Локальный сервер имен получает IP адрес ipipe.ru. от DNS сервера зоны ipipe.ru.

Шаг 8. Получив адрес ipipe.ru локальный DNS сервер сообщает его Вашему браузеру.

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

Простейший алгоритм работы представлен на структурной схеме:

Имя хоста и IP-адрес не тождественны — хост с одним IP-адресом может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки.

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

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

Протокол DNS использует для работы TCPили UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.

Обратный DNS-запрос

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Записи DNS

Наиболее важные категории DNS записей:

• · Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес — 192.0.34.164
• · Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя
• · Запись MX (mail exchange) или почтовый обменник указывает сервер (а) обмена почтой для данного домена.
• · Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.
• · Запись NS (name server) указывает на DNS-серверы для данного домена.
• · Запись SOA (Start of Authority) указывает, на каком сервере хранится эталонная информация о данном домене.

Зарезервированные доменные имена

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.