 |  | |
| IT сфера | ||
 |  |
| | |
ОБ АВТОРЕ
- Наши орбиты. Корень - Новости - Введение - Резюме IT - Контакты |
||
| |
| | |
МАТЕРИАЛЫ
- Разработка - Статьи - Ссылки |
||
| |
| ||||||||||||
| ||||||||||||
|
Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом Сетевые сервисы призваны обслуживать всю сетевую инфраструктуру или же отдельные сервера и клиенты, из наиболее востребованных можно DNS, DHCP, NTP, NF (netfilter), враппер xinetd и другие обзор и заметки по DNS (bind) DNS сервия является важной частью построения сетевой инфраструктуры, как локальной, так и Интернет. Все Интернет домены одного владельца, как локальные, так и доступные из Интернет, обслуживаются одним или несколькими DNS серверами Среди основных задач иерархии DNS серверов (а как частный случай - локальных и недоступных из Интернет) числятся отображение привычных пользователю символьных имён в IP адреса, используемые протоколом TCP/IP, и обратное отображение, а также предоставление информации по типовым сервисам, например почтовым серверам, обслуживающим Интернет домен и их приоритетам, прокси, Kerberos и другим сервисам Фактическим стандартом реализации является DNS сервер bind, удерживающий первое место по количестку установок и используемый на корневых DNS серверах, отвечающих за домены первого уровня (например .com,.org,.ru,.su) и фактически образующих основу инфраструктуры имён Интернет Сервер bind распространяется бесплатно по открытой лицензии и входит в дистрибутивы распространённых операционных систем семейства UNIX - Linux и FreeBSD. Использовать его для управления вашими доменами - вполне закономерное решение, причём существуют довольно удобные, но мало распространённые возможности настройки сервера, в частности использование т.н. представлений, когда, в зависимости от адреса клиента, ему отдаются те или иные (отличные) данные на тот же запрос Ниже приведён типичный пример настройки DNS сервиса bind с использованием технологии представлений, при которой в зависимости от IP адреса клиента емы могут возвращаться разные данные. Основной конфигурационный файл DNS сервера named расположен в /etc/named.conf, он описывает как общие параметры сервера, таки и обслуживаемые сервером DNS зоны, данные которых могут храниться в файлах, СУБД или других источниках (например LDAP каталоге):
### начало /etc/named.conf ##############################################################
options { directory "/var/named"; query-source address * port 53; };
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; };
acl InternalNet { 127.0.0.1; 192.168.39.0/24; };
view InternalView {
match-clients { InternalNet; } ;
zone "."{ type hint; file "named.ca"; };
zone "localhost"{ type master; file "localhost.zone"; allow-update { none; }; };
zone "0.0.127.in-addr.arpa."{ type master; file "named.local"; allow-update { none; }; };
zone "cosiculs.test.ru."{ type master; file "data/int.directZone.dns";
allow-update { none; }; };
zone "39.168.192.in-addr.arpa."{ type master; file "data/int.reversZone.dns";
allow-update { none; }; };
};
view ExternalView {
match-clients { any; } ;
zone "cosiculs.test.ru." { type master; file "data/ext.directZone.dns"; allow-update { none; };
allow-query { any; }; };
};
include "/etc/rndc.key";
### конец /etc/named.conf ##############################################################
Файлы зон частично представлены в поставке сервера, но специфичные зоны необходимо описать самому
### начало /var/named/chroot/var/named/data/ext.directZone.dns внешняя прямая зона #################
$TTL 86400
@ 1D IN SOA ns.cosiculs.test.ru. root.cosiculs.test.ru. (
2005072001 ; serial (рекомендуется указать дату и номер версии)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS ns.cosiculs.test.ru.
IN MX 10 mx.cosiculs.test.ru.
ns IN A 192.168.37.129
www IN CNAME ns
stat IN CNAME ns
mx IN CNAME ns
### конец /var/named/chroot/var/named/data/ext.directZone.dns внешняя прямая зона #################
### начало /var/named/chroot/var/named/data/int.directZone.dns внутренняя прямая зона #################
$TTL 86400
@ 1D IN SOA ns.cosiculs.test.ru. root.cosiculs.test.ru. (
2005072001 ; serial (рекомендуется указать дату и номер версии)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS ns.cosiculs.test.ru.
IN MX 10 mx.cosiculs.test.ru.
ns IN A 192.168.39.129
www IN CNAME ns
stat IN CNAME ns
mx IN CNAME ns
### начало /var/named/chroot/var/named/data/int.directZone.dns внутренняя прямая зона #################
### начало /var/named/chroot/var/named/data/int.reversZone.dns внутренняя реверсная зона #################
$TTL 86400
@ IN SOA 39.168.192.in-addr.arpa. root.39.168.192.in-addr.arpa. (
2004122801 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS ns.cosiculs.test.ru.
129.39.168.192.in-addr.arpa. IN PTR ns.cosiculs.test.ru.
### начало /var/named/chroot/var/named/data/ int.reversZone.dns внутренняя реверсная зона #################
обзор и заметки по DHCP Каждый клиент и сервер (узел) в компьютерной сети обладает рядом обязательных сетевых настроек, и такие настройки администратор должен сделать до того, как такой клиент или сервер сможет полноценно функционировать в сети. Это трудоёмкая работа может быть автоматизирована типовой технологией DHCP - автоматической роздачи сетевых настроек узлам сети Наиболее важными являются значения IP адреса, маски подсети, шлюза по умолчанию, адреса DNS сервера и имя локального DNS домена. Кроме того существует масса дополнительных настроек, а также специфические режимы работы, используемые, например, при развёртывании инфраструктуры сетевой установки или бездисковой загрузки. Нюансы конфигурирования таких специальных режимов для ряда решений описаны в статьях автора, посвящённых таким решениям. А для небольшой организации простейшее конфигурирование сервера DHCP в составе дистрибутива CentOS может быть проведено так:
обзор и заметки по NTP Сервер времени обеспечивает единую точку синхронизации времени на узлах сети. Для расчёта точного времени используются определённые математические алгоритмы, учитывающие данные несколько эталонных источников. Развёртывание сервера может быть проведено по следующему алгоритму
В качестве клиентов можно использовать утилиту ntpdate IP_адрес_сервера, добавив периодический запуск черех cron. Однако в силу оптимизации пакета ntpd на поддержку времени, а не установку, возникают определённые "непонятки" при настройке, которые приводят к недружественному поведению пакета. И если для установки начального времени вполне можно использовать такие довольно извествне утилиты, как date, ntpdate и hwclock, то вторичная синхронизация серверов в отдельных случаях может быть проблематичной, и требовать отдадки сервиса. Однако пакет ntpd не является уникальным, альтернативой ему является, например, пакет openntp, изначально используемый в BSD Unix и реализующий функции опорного сервера времени в локальной сети обзор и заметки по SSH SSH (secure shell) обеспечивает удалёный доступ к узлам сети через шифрованный канал, придя на смену стэку утилит RSH (rsh, rlogin, rcp). Конечно и RSH утилиты не всегда проигрывают SSH, обеспечиваю существенно более высокую скорость копирования, например. Однако фактическим стандартом для целей администрирования стал именно SSH. Фактически он настолько распространён, что в настоящем беглом обзоре будут отмечены только отдельные нюансы Существует возможность проброски графических приложений, называемая "X forwardig". Для проброса на сервере должно быть разрешено пробрасывать X - сессии. На клиенте при вызове необходимо указывать опцию -X и/или -Y, от ситуации. Важно, что существуют реализации SSH, отличные от OpenSSH, используемого в Linux, и на стыке не всегда всё корректно работает Существует возможность авторизации по ключам, когда для заранее сгенерированных ключей на стороне клиента (команда ssh-keygen) публичный ключ добавляется а файл ~/.ssh/authorized-keys в домашнем каталоге соответсвующего пользователя на сервере. Если при создании ключей пароль не указывался, можно довольно просто запускать удалёные команды через шифрованный канал, используя планировщик В отдельных случаях ключи без пароля неприемлимы, но приходится запускать много сессий ssh, и здесь может помочь утилита ssh-agent, которая позволит единыжды за родительскую терминальную сессию ввести пароль Важно также в принудительном порядке запрещать устаревшую 1-ю версию протокола SSH в конфигурации сервера, а также по возможности запрещать подключение пользователем root, используя непривелегированного пользователя и смену пользователя командами su или sudo обзор и заметки по NF Сетевой фильтр (файервол) - механизм, позволяющий запретить или разрешить прохождение определенных видов траффика через железку, на которой он установлен. Это типовое техническое решения является одним из ключевых механизмов защиты от несанкционированного вторжения в локальную сеть. В случае Linux встроенный в ядро сетевой фильтр называется Netfilter. Он управляется утилитой под названием iptables и имеет очень широкую функциональность. Кроме непосредственно фильтрации траффика по заданным разнообразным условиям от обеспечивает сетевую трансляцию в разных вариантах, маркировку траффики, переписывание адресов, механизмы сбора статистики о проходящем траффике, механизмы отбора пакетов по заданным условиям и многое другое Основой работы с сетевым фильтром являются понятия о протоколах стэка TCP/IP, ip и MAC адресах, портах, сетевой адресации и маршрутизации, и т.п. Знакомство с этими понятиями является следствием понимания стэка TCP/IP, и предполагается, что читатель знаком с этими понятиями. Если это не так, читать обзорный раздел по сетевому фильтру Netfilter бессмысленно, и читателю предлагается для начала познакомиться с TCP/IP, обратившись к поиску в Интренет. Ресурсы по этой теме, в том числе русскоязычные, есть Трафик, проходящий через сетевой фильтр, обрабатывается по правилам, конфигурируемым утилитой iptables и хранящимся в таблицах правил до выключения компьютера. Таблицы правил сгруппированы в иерархии mangle, nat и filter и правила выбираются из таблиц в последовательности расположения иерархий. Существуют предустановленные таблицы, например для INPUT, OUTPUT и FORWARD для иерархии filter, которые отвечают за фильтрацию соответственно входящего в хост траффика, исходящего и транзитного (маршрутизируемого). Для иерархии nat предустановленными таблицами правил являются PREROUTING, POSTROUTING и OUTPUT, отвечающие за переписывание адресов входящего маршрутизируемого траффика, исходящего маршрутизируемого ртраффика и локально генерируемого исходящего траффика соответственно. Кроме того, администратор может создать свои таблицы, для более наглядной группировки правил, и предусмотреть правило в одной из предустановленных таблиц для перенаправления определенного вида траффика во вновь созданную таблицу. Типичным примером может являться выделение интересующей администратора группы адресов для обработки траффика с учетом портов по единым правилам для исключения дублирования правил и упрощения конфигурации. Таким образом существование иерархически расположенных групп таблиц, связанных с определенными видами траффика, и содержащих последовательно обрабатываемые конфигурационные правила сетевого фильтра, а также доступные виды правил - это ключевые понятия темы устройства сетевого фильтра Правила в таблицах могут содержать модификаторы, определяюще подмножество обрабатываемого каждым конкретным правилом траффика, а также содержат целевое действие для траффика, разрешенного к обработке данным правилом, например - разрешить прохождение пакетов (-j ACCEPT), запретить (-j DROP), переписать адрес определенным образом (-j DNAT, -j SNAM, -j MASQUERADE), отразить статистику по пакету (-j LOG, -j ULOG), передать для дальнейшей обработки в выбранную именованную таблицу правил (-j имя_таблицы) и т.д. Если иерархия filter предназначена для фильтрации траффика, то иерархия nat предназначена для реализации механизмов распространенного механизма сетевой трансляции - переписывания адресов отправителя или получателя. Этит механизм позволяет спрятать за одним реальным IP адресом, выданным вашей организации, целую локальную сеть, разрешив обращение с компьютеров локальной сети в Интернет или же, наоборот, пробросить приходящий на ваш сервер запрос, например из Интернета, на какой нибудь сервер внутри локальной сети (например, выделенный почтовый или WEB сервер). Таблицы оставшейся иерархии mangle крайне редко используются в типовых задачах практического сетевого администрирования и рассматриваться здесь не будут Создатели сетевого фильтра netfilter предлагают документацию, детально расписывающую логику работы и предоставляющую примеры конфигурирования. Существует также русскоязычный перевод, который однозначно рекомендуется к прочтению для понимания сути работы, расположен он по адресу http://www.opennet.ru/docs/RUS/iptables/. Также в Интернет доступно множество материалов, в том числе русскоязычных, по решению отдельных задач на netfilter Еще можно добавить, что в netfilter встроено несколько методов сбора отчетности о проходящем траффике, в том числе поставляемый разработчиками Netfilter модуль ulogd, доступный по адресу http://www.netfilter.org и позволяющего собирать требуемую статистическую информацию и сохранять ее в различных хранилищах, например в файлах файловой системы, в таблицах нескольких распространенных OpenSource СУБД и т.п. По мнению автора метод сбора статистики от разработчика с использованием СУБД является предпочтительным, а практический опыт подтверждает высокую гибкость конфигурирования и удобство обработки собираемой статистики Белонин С.С. (С), сентябрь 2004 года (даты последующих модификаций не фиксируются)
|
(C) Белонин С.С., 2000-2024. Дата последней модификации страницы:2019-12-04 00:43:28