00-tech-book

Мониторинг сетевой подсистемы в реальном времени

В этом нам отлично поможет пакет ntop.

Убедитесь что репозиторий EPEL подключен. Далее набираем команду:

# yum -y install ntop

Инициализируем ntop, нужно будет задать пароль для админа.

# ntop -A u ntop -P /etc/ntop/

В файл /etc/ntop.conf добавляем наш IP-адрес в опциях --http-server и --https-server Запускаем ntop как службу

# service ntop start

Теперь через браузер можно получить доступ к статистики ntop. По умолчанию ntop работает на порту 3000.

Пример

http://192.168.146.132:3000/

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

#yum -y install iftop

#iftop

Мониторинг работы DNS-сервера в реальном времени

Ставим пакет dnstop на том же сервере где и dns-сервер.

#wget http://dag.wieers.com/rpm/packages/dnstop/dnstop-0.0.20070510-1. el5.rf.i386.rpm

#rpm -Uvh dnstop-0.0.20070510-1.el5.rf.i386.rpm

Далее запускаем dnstop и смотрим за статистикой.

# dnstop eth0

В момент когда dnstop запущен можно нажимать на специальные клавиши и смотреть статистику различного рода.

Основные кнопки:

s — показать таблицу с адресами источников запросов;

d — показать таблицу с пунктами назначения запросов, куда они передаются;

t — показывать статистику по типам запросов;

Другие опции в документации dnstop

# man dnstop

Мониторинг соединений proftpd в реальном времени

# ftptop

Статистика по виртуальной памяти

# vmstat

Статистика по процессору и устройствам ввода-вывода

Ставим пакет sysstat (содержит в себе программы sa, mpstat, iostat, sar)

# yum -y install sysstat

Информация по вводу-выводу

# iostat

Информация по процессору

# mpstat

Резюме

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

Домашнее задание

Настройте систему мониторинга Nagios и поставьте на мониторинг пару

серверов.

BIND

BIND – это пакет содержащий программное обеспечение для построения DNS-сервера.

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

Работа в компьютерных сетях происходит с IP-адресами (уникальный идентификатор) но запомнить все нужные IP-адреса не представляется возможным и здесь на помощь приходит DNS-сервер, который позволяет обращаться к хосту по имени.

Установка

Пакет bind-chroot содержит необходимую структуру каталогов для chrootокружения, пакет caching-nameserver содержит все необходимые файлы. Все остальное, что понадобится в работе будет установлено как зависимости.

Ставим нужные пакеты

# yum -y install bind-chroot caching-nameserver

Добавляем автозагрузку при старте сервера

# chkconfig named on

Инструменты

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

Базовые понятия

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

Домен – это название зоны в системе доменных имен. Название домена читается слева направо, от младших доменов к старшим.

Поддомен – это имя подчиненной зоны. Например mail.example545.com является поддоменом example545.com. example545.com – это домен второго уровня, mail.example545.com – домен третьего уровня.

Относительное имя домена – к имени этой записи будет добавлен основной домен в которой она находится.

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

resolver – программа-клиент. Она вступает в работу когда пользователь пытается получить информацию от DNS-сервера. Файл конфигурации резолвера - /etc/resolv.conf

DNS-запрос (query) – запрос от клиента к серверу. Существует два типа запросов.

1.Рекурсивный – при получение рекурсивного запроса сервер должен

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

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

Правила построения DNS-системы

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

1.Для каждой зоны должны быть не менее двух DNS-серверов, один master-

сервер и один slave-сервер;

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

Режимы работы ДНС-серверов

Существует несколько режимов в которых может работать DNS-сервер. Конечно самая распространенная связка – это Master/Slave.

Master DNS-сервер – главный DNS-сервер для зоны, только он имеет право вносить в нее изменения, другие могут получать и хранить у себя, отдавая на запросы клиентов. Здесь ключевое отличие в возможности редактировать файл зоны, изменять список NS-серверов для нее и прочие записи.

Slave DNS-сервер – вторичный DNS-сервер для зоны, их может быть несколько. Основное предназначение вторичного сервера – подстраховывать первичный (Master server) сервер (в случае, если он станет временно недоступен) и снижать нагрузку обрабатывая часть запросов. Он обслуживает запросы наравне с первичным сервером, также являясь авторитативным для зоны и пользователю должно быть все равно с какого DNS-сервера получать информацию. Slave-сервер не может вносить изменения в конфигурацию зоны.

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

# nslookup www.ru

Server: 192.168.146.2

Address: 192.168.146.2#53

Non-authoritative answer:

Name: www.ru

Address: 194.87.0.50

Строка “Non-authoritative answer” говорит о том, что ответ мы получили из кэша неавторитативного сервера.

Корневые DNS-сервера - сервера, которые обслуживают корневую зону (Root servers). Их место в получении отклика на запрос к системе доменных имен ключевое. Именно к одному из корневых серверов обращается локальный

сервер доменных имен, если не находит в зоне своей ответственности или в

своем кэше соответствия между доменным именем и IP-адресом.

Посмотреть корневые сервера можно вот так:

#dig . ns @198.41.0.4

;<<>> DiG 9.3.4-P1 <<>> . ns @198.41.0.4

;(1 server found)

;;global options: printcmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51497

;;flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

;;QUESTION SECTION:

;;Query time: 233 msec

;;SERVER: 198.41.0.4#53(198.41.0.4)

;;WHEN: Wed Apr 8 10:51:26 2009

;;MSG SIZE rcvd: 500

Stealth DNS-сервер (невидимый DNS-сервер) – такой DNS-сервер не упоминается в описание зоны. Информацию о нем нельзя получить прямыми запросами или копированием описания зоны. Данный тип сервера может быть полезен для внесения изменений в зону находясь за файрволом. В этом случае primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с “невидимого” primary master.

Типы ответов DNS-серверов

Авторитативный ответ (authoritative response ) - такой ответ возвращают сервера которые являются ответственными за зону.

Неавторитативный ответ (non authoritative response) - возвращают серверы, которые не отвечают за зону. Необходимую информацию они получают из своего кэша или после нерекурсивного запроса к авторитативному DNSсерверу.

Виды запросов к DNS-серверу

Прямой запрос (forward) – это запрос на преобразование имени хоста в IPадрес. Думаю это самый распространенный запрос.

Обратный запрос (reverse) – это запрос на преобразование IP-адреса хоста в доменное имя. Почтовые сервера любят проверять наличие этой записи, что в свою очередь помогает бороться со спамом.

Способы копирования зоны с master-сервера

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

оперировать с актуальной копией. Так вот существует два механизма получения обновлений с master-сервера.

AXFR - полное копирование зоны.

IXFR – инкрементальное копирование зоны, когда копируются только измененные данные а не весь файл целиком.

Перед продолжение хочу обратить внимание на некоторые моменты. Как уже говорилось slave-сервер копирует зону с master-сервера, То есть с сервера который является авторитативным для зоны. Но slave-сервер и сам может являться авторитативным и в этом случае он будет выступать masterсервером для того кто с него копирует зону. Для того чтобы точно описать сервер, который является авторитативным для зоны и который больше не получает обновлений для нее, был введен термин primary master. Primary master находится в корне всех процедур копирования и именно на нем происходит ручное изменение зоны. Такой сервер может быть только один для зоны.

За своевременное информирование slave-серверов о необходимости обновить свои данные отвечает механизм DNS NOTIFY. Принцип его работы не сложный.

1. Мы вносим изменения в зону на primary master увеличив значение поля serial на единицу;

2.После перезагрузки конфигурации primary master-сервера, он оповещает все свои slave-сервера об изменениях;

3. Slave-сервер запрашивает описание зоны с primary master-сервера и смотрит версию описания зоны, если версия отличается от его (больше) то он инициирует процесс обновления зоны;

4.После завершения обновления, slave-сервер посылает оповещение на все ему известные авторитативные сервера для этой зоны.

Виды записей

Non-authoritative answer:

ya.ru

origin = ns1.yandex.ru

mail addr = sysadmin.yandex.ru

serial = 2009040300

refresh = 10800

retry = 900

expire = 2592000

minimum = 900

Authoritative answers can be found from:

ya.ru nameserver = ns1.yandex.ru.

ya.ru nameserver = ns5.yandex.ru.

origin – первичный сервер зоны, ее primary master;

mail addr – e-mail администратора зоны, обращаю внимание что вместо @ нужно указывать точку;

serial – номер версии зоны, с каждым внесением изменений в зону не забывайте увеличивать это число на еденицу! Тогда slave-сервер сразу обновить ее у себя. Чтобы проще было ориентироваться используйте номер в таком формате <год><месяц><день><какое по счету изменение за день>, таким образом номер всегда будет только возрастать;

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

retry – интервал в секундах, через который вторичный сервер будет повторять обращения в случае неудачи;

expire – интервал в секундах, через который вторичный сервер будет считать информацию о зоне устаревшей и перестанет ее использовать;

minimum – значение времени жизни записи на кэширующих серверах.