Руководство администратора сети в ОС Linux

2.5.1. Безопасность системы

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

Здесь мы будет обсуждать несколько примеров и основных методов
обеспечения безопасности системы. Конечно, охваченные темы не могут
решить всех проблем безопасности, с которыми вы столкнетесь; они
просто служат иллюстрацией проблем, которые могут возникнуть. Поэтому,
необходимо прочитать хорошую книгу по безопасности, особенно
администратору сетевой системы. Simon Garfinkel "Практическая UNIX
Безопасность" ( см. [ GETST "безопасность"]) -- очень рекомендую.

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

При создании сервиса доступного по сети, постарайтесь дать ему
"наименьшие привилегии," удастовертесь что Вы не разрешаете ему делать
вещи, которые не требуются для его работы. Например, Вы должны делать
программы с привилегии root только, когда они действительно нуждаются
в этом. Например, если Вы хотите разрешить бездисковым хостам
загружаться от вашей машины, Вы должны обеспечить TFTP (тривиальный
сервис передачи файла) так, чтобы они загружали основные файлы
конфигурации из дириктории /boot. Однако, когда используется
неограниченный TFTP, это позволяет любому прочитать общедоступные
файлы с вашей машины. Если это не то, что Вы хотите, почему бы не
ограничить TFTP сервис дирикторией /boot?

По той же самой причине, Вы могли бы захотеть ограничить доступ к
определенным услугам пользователям с определенных хостов. В главе 10.,
мы представляем tcpd, который делает это для разнообразных сетевых
приложений.

Другой важный пункт -- избегайте "опасного" программного
обеспечения. Конечно, любое программное обеспечение, которое Вы
используете может быть опасно, потому что программное обеспечение
может иметь ошибки, так что умные люди могли бы использовать их чтобы
получить доступ к вашей системе. Подобные вещи случаются и нет никакой
полной защиты против этого. Эта проблема касается как бесплатного, так
и коммерческого программного обеспечения. Однако, программы, которые
требуют специальных привилегий несоизмеримо опаснее чем другие, потому
что любая лазейка может иметь непоправимые последствия. Если Вы
устанавливаете сетевую программу будте вдвойне осторожны и ничего не
пропускаете в документации, чтобы случайно не нарушить безопасность
системы. Вы не можете исключить того, что ваши предосторожности могут
потерпеть неудачу, независимо от того насколько осторожный Вы были.
Поэтому Вы должны удостовериться, что Вы обнаружите злоумышленников
сразу же после их появления. Хорошее начало -- проверка log файлов
системы, но злоумышленник вероятно умный человек, и будет удалять
любые очевидные следы перед уходом. Однако, имеются инструменты
подобно tripwire, которые позволяют Вам проверять жизненно важные
системные файлы и регистрировать были ли их содержание или разрешения
изменены. Tripwire вычисляет различные сильные контрольные суммы по
этим файлам и хранит их в базе данных. Потом контрольные суммы
повторно вычисляются и сравниваются с сохраненными для обнаружения
любых модификации.

2.6. Обзор следующих глав

Следующие несколько глав будут иметь дело с конфигурированием
Linux для TCP/IP сети, и с управлением некоторыми главными
приложениями. Прежде чем пачкать наши руки редактированием файлов и
подобными вещами мы немного исследуем IP в 3 главе. Если Вы уже знаете
относительно IP маршрутизации, и как выполняется address resolution,
Вы можете пропустить эту главу.

Глава 4. Обсуждение основных проблем конфигурации, типа установка
ядра и введения вашей Ethernet карты. Конфигурация ваших
последовательных портов охвачена в отдельной главе, потому что их
обсуждение не относится только к TCP/IP сети, но и к UUCP.

Глава 6. Помогает Вам отконфигурировать вашу машину для TCP/IP.
Она также описывает несколько полезных инструментов, которые Вы можете
использовать для проверки и отладки ваших установок Следующая глава
рассказывает как конфигурировать hostname resolution и объясняет как
установить сервер имен.

Это сопровождается двумя главами показывающими конфигурирование и
использование SLIP и PPP. Глава 8. Объясняет как установить SLIP связь
и дает детальные рекомендации по запуску программ, которые позволяют
автоматизировать большинство необходимых шагов. Глава 9. охватывает
PPP и pppd.

Глава 10. Дает короткое представление о некоторых из наиболее
важных сетевых приложений, типа rlogin, rcp, и т.д., Она также
охватывает услуги inetd и описывает как Вы можете ограничить
определенные услуги для набора каких-либо хостов.

Следующие две главы обсуждают NIS, Сетевую Информационную
Систему, и NFS, Сетевую Файловую Систему. NIS - полезный инструмент
для распространения административной информации типа паролей
пользователя в локальной сети. NFS позволяет Вам распределить файлы
между несколькими хостами в вашей сети.

Глава 13. Дает Вам представление об администрированию Taylor
UUCP, бесплатного UUCP пакета.

Остаток книги посвящен детальному путешествию по электронной
почте и Usenet Новостям. Глава 14. представляет Вам основные
концепциям электронной почты, типа того как выглядит адрес электронной
почты и как система обработки почты получает ваше сообщение

Главы 15. И 16. Охватывают установку smail и sendmail, два агента
транспортировки почты, которых Вы можете использовать в Linux. Эта
книга описывает оба из них, потому что smail более легкий для
установки (для начинающих), в то время как sendmail более гибок.

Главы 17. И 18. Объясняют пути управления новостями в Usenet и
как установить и использовать C news, популярный пакет программ для
управления Usenet новостями.

Глава 19. Кратко охватывает запуск NNTP daemon, чтобы обеспечить
доступ к новостям для вашей локальной сети.

Глава 20. Наконец показывает Вам как конфигурировать и
обслуживать различные newsreader.

3. Проблемы TCP/IP сети

Теперь обратимся к деталям того как вы будете присоединять вашу
Linux машину к сети TCP/IP, включая работу с IP адресами, именами
хостов, и чуть-чуть проблемы маршрутизации. Эта глава дает Вам основу,
которая поможет Вам понять, что требуется для установки системы, в то
время как следующие главы будут охватывать инструменты, с помощью
которых это достигается.

3.1. Сетевой интерфейс

Чтобы скрыть разнообразное оборудование, которое может
использоваться в сетевой среде, TCP/IP определяет абстрактный
интерфейс, через который можно обращаться к аппаратным средствам ЭВМ.
Этот интерфейс предлагает набор действий который является одинаковым
для всех типов аппаратных средств и в основном имеет дело с посылкой и
получением пакетов.

Для каждого переферийного устройства, которое Вы хотите
использовать, в ядре должен быть представлен соответствующий интерфейс
Например, Ethernet интерфейсы в Linux названы eth0 и eth1, а
интерфейсы SLIP -- sl0, sl1, и т.д.. Эти названия интерфейса
используются при конфигурировании, когда Вы хотите определить ядру
специфическое физическое устройство. Они не имеют никакого
назначения кроме этого.

Чтобы работать в TCP/IP сети, данному интерфейсу должен быть
назначен IP адрес, который служит как идентификатор при общении с
остальным миром. Этот адрес различен в зависимости от названия
интерфейса упоминаемого выше; если Вы сравниваете интерфейс с дверью,
тогда адрес подобен пластине с именем, прикрепленной на ней.

Конечно, имеются другие параметры устройства которые необходимо
отрегулировать; один из них - максимальный размер дэйтаграм который
может быть обработан данной частью аппаратуры, также называемый
Maximum Transfer Unit, или MTU. Другие параметры будут представлены
позже.

3.2. IP адреса

Kак упоминается в предыдущей главе, адреса понятные в
соответствии c IP -- это 32-битовые числа. Каждая машине в данной сети
должен быть назначена уникальный адрес.

В локальной сети, которая не использует TCP/IP для связи с
другими сетями, Вы может назначить эти номера согласно вашим
персональным предпочтениям. Однако, для участков Inetrnet, номера
назначаются NIC.

Для более легкого чтения, IP адреса разбивают на четыре 8 битовых
числа, названных octets. Например, quark.physics.groucho.edu имеет IP
адрес 0x954C0C04, который записывается как 149.76.12.4. Этот формат
часто называют dotted quad notation.

Другая причина для такой записи то, что IP адреса разбиваются на
номер сети, который написан в первых octets, и номер хоста, который
является остатком. При обращении к NIC за адресами, Вы не получаете
адрес для каждого отдельного хоста, которые Вы планируете поставить.
Вместо этого, Вам дают сетевой номер, и позволяющий назначать машинам
любые IP адреса из заданного таким образом диапазона.

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

Класс A включает сети от 1.0.0.0 до 127.0.0.0. Сетевой номер содержится в
первом octet, что предусматривает 24 разрядную хост часть, сеть
приблизительно из 1.6 миллион хостов.

Класс B содержит сети от 128.0.0.0 до 191.255.0.0; сетевой номер находится в
первых двух octets. Это предполагает 16320 сетей с 65024 хостами
каждый.

Класс C диапазон сетей от 192.0.0.0 до 223.255.255.0, с сетевой номер
содержится в первых трех octets. Это предполагает почти 2 миллиона
сетей по 254 хоста.

Классы D, E, и F Адреса попадающие в диапазон от 224.0.0.0 до 254.0.0.0
являются или экспериментальным, или сохранены для будущего
использования и не определяют какую-либо сеть.

Если мы вернемся к примеру в предыдущей главе, мы увидим что
149.76.12.4, адрес quark, относится к хосту 12.4 в сети 149.76.0.0
класса B.

Вы можете заметить, что в вышеупомянутом списке для каждого octet
в части хоста возможны не все значения. Это потому что номера хоста со
всеми octets равными 0 или 255 сохранены для специальных целей. Адрес
в котором все биты хост части -- ноль относится ко всей сети, а где
все биты хост части 1 назван broadcast (широковещательным) адресом. Он
относится ко всем хостам из указанной сети. Таким образом,
149.76.255.255 не существующий адрес хоста, он относится ко всем
хостам сети 149.76.0.0.

Имеются еще два зарезервированных адреса, 0.0.0.0 и 127.0.0.0.
Первый назван default route(путь по умолчанию), последний loopback
(кольцевым) адресом. default route используется при маршрутизации IP
дэйтаграм, с которыми мы будет иметь дело ниже.

Сеть 127.0.0.0 сохранена для IP работы внутри хоста. Обычно,
адрес 127.0.0.1 будет назначен специальному интерфейсу на вашем хосте,
так называемому интерфейсу loopback, который действует подобно
закрытому кругообороту. Любой IP пакет переданный ему от TCP или UDP
будет возвращен к ним как будто он только что прибыл из некоторой
сети. Это позволяет тестировать сетевое программное обеспечение без
использования "реальной" сети. Также он полезен, когда Вы хотите
использовать сетевое программное обеспечение на автономном хосте.
Например, большое количество UUCP участков не имеют IP связи вообще,
но все же хотят управлять INN системой новостей. Однако для правильной
работы под Linux, INN требует интерфейса loopback.

3.3. Address Resolution(поиск по адресу).

Теперь, когда вы видели как создаются IP адреса, Вы можете
спросить как же они используются в Ethernet при адресации различных
хостов? В конце концов Ethernet протокол опознает хосты по шести
байтовому адресу, который не имеет абсолютно ничто общего с IP
адресом.

Именно поэтому необходим механизм, переводящий IP адреса в адреса
Ethernet. Это так называемый Address Resolution Protocol (Протокол
Решения Адреса), или ARP. Фактически, ARP не ограничен Ethernet, он
используется и на сетях других типов. Идея, лежащая в основе ARP
аналогична способу применяемому большинством людей, когда они хотят
найти господина X. Они ходят по толпе и выкрикивают его имя. И если он
там, он откликнется.

Когда ARP хочет выяснять Ethernet адрес соответствующий данному
IP адрес, он использует особенность Ethernet известную как
"broadcast"(широковещательное), когда дэйтаграмы адресовываются
одновременно всем станциям в сети. Широковещательная дэйтаграма
посланная ARP содержит запрос с IP адресом. Каждый хост сравнивает его
с собственным адресом, и если они совпадают, возвращает ARP-ответ на
спрашивающий хост. Спрашивающий хост может теперь извлечь Ethernet
адрес отправителя из этого ответа.

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

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

Иногда, также необходимо выяснять IP адрес связанный с данным
Ethernet адресом. Это случается, когда бездисковая машина хочет
загрузится с сервера по сети, что является весьма общей ситуацией для
локальных сетей. Бездисковый клиент, однако, не имеет никакой
информацию относительно себя кроме Ethernet адреса! Он посылает
широковещательное сообщение содержащее просьбу к серверу сообщить ему
его IP адрес. Для этого существует другой протокол, называемый
Reverse Address Resolution Protocol (Реверсивный ARP), или RARP. А
также BOOTP протокол, который служит для определения процедуры
загрузки бездисковых клиентов по сети.

3.4. IP маршрутизация

3.4.1. IP Сети

<> Когда Вы пишете письмо, Вы обычно помещаете на конверте полный
адрес: страну, штат, почтовый индекс, и т.д.. После того, как Вы
опускаете его в почтовый ящик, почта доставит его по месту назначения:
оно будет послано обозначенной стране, чья национальное почта пошлет
его в требуемый штат, и т.д.. Преимущество этой иерархической схемы
довольно очевидно: Везде, где Вы отправляете по почте письмо, местный
начальник почтового отделения будет точно знать, куда передать это
письмо, и не должен заботиться, которым путем письмо будет
путешествовать.

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

3.4.2. Подсети

Эта структура отражена в разбиении IP адреса на хост и сетевую
части, как объяснено выше. ПО умолчанию, сеть мест назначения
получается из сетевой части IP адреса. Таким образом, хосты с
идентичными IP адресами сети должны располагаться в пределах одной
сети, и наоборот. (2)

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

Подсеть принимает ответственность за доставку дэйтаграм для
определенного диапазона IP адресов. Как с классами A, B, или C, она
идентифицируется сетевой частью IP адресов. Однако, сетевая часть
теперь расширена, чтобы включить некоторые биты от хост части. Число
битов которые интерпритируются как номер в подсети задается так
называемой subnet(подсетевой) маской, или netmask. Это - 32 разрядное
число, которое определяет разрядную маску для сетевой части IP
адреса.

Сеть Groucho Marx Университета - пример такой сети. Она имеет
класс B с сетевым номером 149.76.0.0, и netmask поэтому равен
255.255.0.0.

Внутри, сеть GMU состоит из нескольких меньших сетей, типа
локальных сетей различных отделов. Так что диапазон IP адресов разбит
на 254 подсети, от 149.76.1.0 до 149.76.254.0. Например, отдел
теоретической физики имеет номер 149.76.12.0. Университетский
оптиковолоконный кабель тоже сеть с собственным номером 149.76.1.0.
Эти подсети имеют одинаковый сетевой IP адрес, в то время как третья
octet используется, чтобы различать их между собой. Таким образом
они будут использовать подсетевую маску 255.255.255.0.

Картинка 3.4.2 показывает как 149.76.12.4, адрес quark,
интерпритируется по-разному когда адрес принят как обычный адрес сети
класса B, и когда используется с подсетью.

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

3.4.3. Gateways

Subnetting - не только организационная деление, но часто и
естественное следствие границ аппаратных средств. Знания хоста о
строении данной физической сети, типа Ethernet, являются очень
ограниченными: Единственные хосты, с которыми они способны говорить
непосредственно, те, что находятся в той же сети. Ко всем другим
хостам они могут обращаться только через так называемый gateways.
Gateway -- хост который связан с двумя или больше физическими сетями
одновременно и конфигурирован так, чтобы перекачивать пакеты между
ними.

IP достаточно легко распознать находится ли хост на местной
физической сети, различные физические сети должны принадлежать
различным IP сетям. Например сетевой номер 149.76.4.0 сохранен для
хостов в локальной сети математиков. При посылке дэйтаграм к quark,
сетевое программное обеспечение на erdos немедленно видит по IP
адресу, 149.76.12.4, что хост места назначения находится в другой
физической сети, и поэтому может быть достигнут только через gateway
(sophus по умолчанию).

Sophus непосредственно связан с двумя отличными подсетями:
отделом математики, и университетской магистралью. Они доступы через
различные интерфейсы (eth0 и fddi0 соответственно). Но какой IP адрес
мы ему назначаем? 149.76.1.0 или 149.76.4.0?

Ответ: оба. При разговоре с сервером в локальной сети
математиков, sophus использует IP адрес 149.76.4.1, а при разговоре с
хостом на магистраль, он должен использовать 149.76.1.4.

Таким образом, gateway получает по одному IP адресу на каждую
сеть, к которой он подключен. Эти адреса (вместе с netmask) привязаны
к интерфейсу через, который обращаются подсети. Таким образом,
интерфейсы и адреса sophus связаны так:

----------------------------------------
+-------+-------------+----------------+
| Интерфейс| адрес | Netmask |
+-------+-------------+----------------+
+-------+-------------+----------------+
| Eth0 | 149.76.4.1 | 255.255.255.0 |
| fddi0 | 149.76.1.4 | 255.255.255.0 |
| Lo | 127.0.0.1 | 255.0.0.0 |
+-------+-------------+----------------+
+-------+-------------+----------------+

Последняя запись описывает loopback интерфейс lo.

На картинке 3.4.3 изображена топология части сети Groucho Marx Университета
(GMU). Хосты, находящиеся в двух подсетях в то же самое время показываются с
обоими адресами.

Вообще, Вы можете не обращать внимание на различия между адресами
хоста и интерфейса. Относитесь к адресу хоста, который находятся
только в одной сети, как к адресу того и другого, хотя строго говоря
это Ethernet интерфейс имеет IP адрес. Однако, это различие ощутимо
только, когда Вы работаете с gateway.

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

Теперь сосредоточим наше внимание на том, как IP выбирает gateway
при доставке дэйтаграм к определенной сети.

Как мы видели раньше erdos, когда передавал дэйтаграмы для quark,
проверил место назначения и нашел, что его нет в местной сети. Поэтому
он посылает ее gateway, sophus, который теперь сталкивается с той же
самой задачей. Sophus определяет, что quark не находится в сетях, с
которыми он непосредственно связан, так что он передает эту дэйтаграм
другому gateway, чтобы он перенаправил ее дальше. Правильный выбор был
бы niels (gateway Отдела Физики). Но sophus нуждается в некоторой
информации чтобы определить подходящий gateway.

Для этого используется таблица IP маршрутизации, которая
определяет какие сети присоединены с помощью каких gateways.
Обязательно должен быть указан маршрут по умолчанию (the default
route), по которому будут направляться все пакеты с адресами в
неизвестных сетях. Этот gateway связан с сетью 0.0.0.0.. На sophus,
эта таблица могла бы напоминать эту:

-----------------------------------------
+------------+-------------+------------+
| Сеть | Gateway | Интерфейс |
+------------+-------------+------------+
+------------+-------------+------------+
| 149.76.1.0 | - | Fddi0 |
| 149.76.2.0 | 149.76.1.2 | fddi0 |
| 149.76.3.0 | 149.76.1.3 | fddi0 |
| 149.76.4.0 | - | Eth0 |
| 149.76.5.0 | 149.76.1.5 | fddi0 |
|... | ... | ... |
| 0.0.0.0 | 149.76.1.2 | fddi0 |
+------------+-------------+------------+
+------------+-------------+------------+

Маршруты к сетям, с которыми sophus связан непосредственно
обозначаются "-" в столбце gateway.

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

В зависимости от размера сети используются различные протоколы
маршрутизации. Для маршрутизации в автономной системе (типа
университетского городка), лучше подходит RIP, Routing Information
Protocol (протокол маршрутной информации), который предложен в BSD
демоне. Для маршрутизации между автономными системами используются
внешние протоколы маршрутизации типа EGP (Внешний Gateway Протокол),
или BGP ( Пограничный Gateway Протокол); они ( а также RIP) были
предложены в gated демоне( University of Cornell's).

3.4.5. Метрические значения

Динамическая маршрутизация основанная на RIP выбирает самый
лучший маршрут к некоторому хосту или сети, основываясь на наборе
"hops"(перелетов), то есть gateways дэйтаграм, рассылаемых перед
передачей основной информации. Чем более короткий маршрут, тем лучше
RIP его оценивает. Очень длинные маршруты с 16 или больше перелетов
рассматриваются как неподходящие и отвергаются.

Чтобы использовать RIP для управления информацией,
маршрутизируемой внутри вашей сети, Вы должны запустить gated на всех
хостах. Во время загрузки gated проверяет все активные сетевые
интерфейсы. Если имеется больше чем один активный интерфейс ( не
считая loopback ), это предполагает что хост передает пакеты между
несколькими сетями, и будет активно обмениваться маршрутной
информацией. Иначе, он будет только пассивно получать RIP пакеты и
модернизировать локальную таблицу маршрутизации.

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

3.5. The Internet Control Message Protocol
(Межсетевой протокол контрольных сообщений)

IP имеет протокол-компаньон, что ж мы до сих пор не поговорили о
нем. Это межсетевой протокол контрольных сообщений (ICMP) и
используется он сетевым кодом ядра, чтобы передавать сообщения об
ошибках и т. п. другим хостам. Например, предположите что Вы
находитесь на erdos и хотите использовать telnet через 12345 порт на
quark, но на этом порте отсутствует слушающий процесс. Когда приходит
первый TCP пакет на этот порт, ядро определит это и отошлет ICMP
сообщение.

Имеются множество ICMP сообщений, большинство из них сообщают о
каких-либо ошибках. Однако, имеется очень интересное сообщение
названное Перенаправляющим сообщением (Redirect message). Оно
генирируется модулем маршрутизации, когда он обнаруживает что другой
хост использует его как gateway, хотя имеется более короткий маршрут.
Например, после загрузки таблицы маршрутизации на sophus может быть
неполной: она содержит маршруты к сети математиков, к FDDI магистрали,
а по умолчанию указан gateway Groucho Вычислительного центра (gcc1).

Поэтому, любые пакеты для quark посылаются через gcc1, хотя
быстрее было бы через niels (gateway в отделе физики). При получении
таких дэйтаграм, gcc1 будет извещать что это -- плохой маршрут, и
будет отправлять пакет к niels, в то же самое время возвращая ICMP
сообщение к sophus, показывая ему лучший маршрут.

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

3.6. Система имен областей (Domain Name System)

3.6.1 Поиск по имени (Hostname Resolution)

< > Как описано выше, адресация в TCP/IP сети крутится вокруг 32
разрядных номеров. Однако, Вам будет трудно запомнить даже некоторые из
них. Поэтому, хосты чаще известны под "обычными", имена типа gauss или
strange. Поэтому требуются программы для получения IP адреса по имени
машины Этот процесс назван Hostname resolution.

Приложение, которое хочет найти IP адрес по данному имени хоста,
не должен пытаться сделать это собственными силами Вместо этого, оно
обращается к библиотечным функциям, которые для этого и написаны, они
называются gethostbyname (3) и gethostbyaddr (3). Традиционно, эти и
ряд других процедур были сгруппированы в отдельной библиотеке
названной resolver; в Linux, это часть стандартной libc.

На маленькой сети, подобной Ethernet, или даже на нескольких, не
очень трудно поддерживать таблицу, сопоставляющую имена хоста к IP
адресам. Эта информация обычно хранится в файле /etc/hosts. При
добавлении или перемещении хоста, или при переназначении адресов, все
что Вы должны сделать -- это изменить файл hosts на всех хостах.
Очевидно, что это будет достаточно трудно в сетях с большим
количеством машин.

Одно из решений этой проблемы -- NIS, Сетевая Информационная
Система разработанная Sun Microsystems, названное YP, или Желтыми
Страницами. NIS хранит hosts файл (и другую информацию) в базе данных
на главном хосте, от которого клиенты могут восстановить свои файлы
если это необходимо. Все еще, Этот способ подходит только для сетей
среднего размера, потому что он требует поддерживать полную базу
данных как на центральной машине, так и на всех остальных.

В Internet, первоначально информация об адресах хранилась в
единственном файле HOSTS.TXT. Этот файл поддерживался в NIC, и должен
был загружаться всеми участвующими участками. Когда сеть выросла,
возникло несколько проблем. Постоянное обновление и постоянная
перекачка файла HOSTS.TXT регулярно требовали все больше ресурсов,
нагрузка на сервер, который этим занимался стала слишком высока. Но
еще большей проблемой стало придумывание новых (не совпадающих с
преждними) имен.

Вот почему, в 1984 г, введена новая схема -- DNS, разработанная
Paul Mockapetris и решившая обе проблемы одновременно.

3.6.2. О DNS

DNS организовывает имена хостов по областям(domain). Область --
набор как-то связанных участков, это могут быть машины одной сети (на
пример все машины в университетском городке, или всех хосты в BITNET),
все они могут принадлежать определенной организации (типа
американского правительства), или они просто географически близки.
Например, университеты сгруппированы в edu области, с каждым
Университетом или Коледжом, использующим отдельную подобласть, в
которой и находятся все его хосты. Groucho Marx Университету можно
давать groucho.edu область, Отделу математики -- maths.groucho.edu.
Хост на данной сети к имени области добавляет свое имя и таким образом
получает свое полное имя в Internet erdos был бы известен как
erdos.maths.groucho.edu.

Картинка 3.6.2 изображает пространство имен. Запись в корне этого
дерева, которая обозначена единственной точкой, весьма точно названа
областью корня, и она связана со всеми другими областями. Чтобы
показать что в данном месте пишется полное имя хоста, а не имя
относительно локальной области, иногда после имени ставят точку. Это
значит, что последний компонент имени принадлежит области корня.

В зависимости от местоположения в иерархии имени, область может
быть названа top-level, second-level, или third-level
(верхнеуровневой, второго уровня, или третьего уровня). Больше
количество уровней встречается редко. Вот несколько верхних областей,
которые Вы можете часто увидеть:

edu ( Главным образом США ) образовательные учреждения подобно
университетам, и т.д..

com Коммерческие организации, компании.

org некоммерческие организации. Часто частные UUCP сети находятся в этой
области.

net Gateways и другие административные хосты в сети.

mil американские военные учреждения.

gov американские правительственные учреждения.

uucp Официально, все имена участков прежде используемые как UUCP имена
без областей, были перемещены в эту область.

Технически, первый четыре из них принадлежат американской части
Internet, но там встречаются и не американские участки. Это особенно
верно для net области. Однако, mil и gov используются исключительно в
США.

Вне США, каждая страна вообще использует собственную область,
названую по имени страны и состоящая из двух букв определенных в
ISO-3166. Финляндия, например, использует fi область, fr используется
Францией, de Германией, au Австралией и т.д.. Ниже этой
высокопоставленной области, NIC каждой страны может свободно раздавать
имена хостам. Австралия, например, имеет области второго уровня
подобные международным высшим областям, названным com.au, edu.au, и
так далее. Другие, подобно Германии, не используйте этот
дополнительный уровень, но используют слегка длинные имена, которые
непосредственно относятся к организациям управляющих специфической
областью. Например, на пример ftp.informatik.uni-erlangen.de.

чонечно, эти национальные области не подразумевают что хост
расположенный ниже фактически расположен в той же стране; это только
сигнализирует что хост регистрировался в NIC этой страны . Шведский
изготовитель мог бы иметь отделение в Австралии, и все же
регистрировать все хосты в se области.

Теперь, организация пространства имен в иерархии имен областей
приятно решает проблему уникальности имен; с DNS, имя хоста должно
быть уникально только в пределах одной области Кроме того, полностью
квалифицированные имена весьма легко запомнить. Но DNS делает не
только это: он позволяет Вам передать работу с подобластями местным
администраторам. Например, администратор в Groucho Вычислительном
Центре мог бы создать подобласть для каждого отдела; мы уже
столкнулись с подобластями физиков и математиков. Когда он решит, что
сеть в Отделе Физики слишком большая и хаотичная, чтобы справиться с
ней из вне , он может просто передать контроль над physics.groucho.edu
областью администраторам этой сети. Тогда они свободны использовать,
любые имена хостов и назначать их IP адреса в пределах подсети без
вмешательства сверху.

Так, пространство имени раздроблено на зоны, которая управляется
своей областью. Обратите Внимание На различие между зоной и областью:
область groucho.edu затрагивает все машины в Groucho Marx
Университете, в то время как зона groucho.edu включает только хостов
которые работают в компьютерном центре непосредственно, например в
отделе математики. Хост в отделе физики принадлежат другой зоне, а
именно physics.groucho.edu. На картинке 3.6.2, начало зоны отмечено
маленьким кружочком справа от имени области.

3.6.3 Поиск имени с помощью DNS

На первый взгляд, все эти суета с областями и зонами кажется
делает поиск адреса ужасно сложным делом. В конце концов, если нет
центрального органа контролируещего какие имена связаны с каким
адресом, тогда как - скромное приложение должно его узнавать?!

Теперь начинается действительно техническая часть описания DNS.
Если Вы хотите выяснять IP адрес erdos, тогда, DNS говорит, иди и
спроси людей, которые управляют им, и они ответят Вам.

Фактически, DNS - гигантская распределенная база данных. Это
осуществлено посредством так называемых серверов имен(name server),
которые снабжают всех информацией о данной области или нескольких
областях сразу. Для каждой зоны имеются по крайней мере два сервера
имен, которые содержат всю информацию относительно хостов в этой зоне.
Чтобы получить IP адрес erdos, все что Вы должны сделать -- обратится
к серверу имен зоны groucho.edu, который и передаст Вам требуемые
данные.

Легко сказать, а как это сделать, подумали вы. Так как найти
сервер имен в Groucho Marx Университет? В случае если ваш компьютер не
оборудован address-resolving oracle, DNS также обеспечивает это. Когда
ваше приложение хочет найти информацию относительно erdos, оно входит
в контакт с местным сервером имен, который проводит так называемый
итерационный опрос. Сначала он посылает запрос серверу имен об области
корня, спрашивая о адресе erdos.maths.groucho.edu. Сервер имен корня
сообщает, что это имя не принадлежит зоне его полномочий, но вместо
этого отсылает к edu области. Таким образом, он предлагает Вам войти в
контакт с сервером имен зоны edu для получения большего количества
информации, и прилагает список всех серверов имен edu вместе с их
адресами. Ваш местный сервер имен пошлет запрос одному из них,
например a.isi.edu. Также как серверу имен корня, a.isi.edu знает что
люди groucho.edu управляют свей зоной сами, и направит Вас на их
сервера. Местный сервер имен запросит одного из них, который наконец
распознает имя, как принадлежащее к его зоне, и вернет IP адрес.

Кажется, что для поиска одного IP адреса тратится слишком много
ресурсов. но это не сравнимо меньше, чем при преждней схеме с
HOSTS.TXT. Но все еще имеются места для усовершенствования этой
схемой.

Чтобы уменьшить время ответа для будущих запросов, сервер имени
хранит полученную раньше информацию в кэше. Так что в следующий раз,
когда любой другой из вашей локальной сети захочет найти адрес хоста в
groucho.edu области, ваш сервер имен не проведет все снова, а будет
сразу обращаться к серверу имен groucho.edu.

Конечно, сервер имен не будет хранить эту информацию всегда, а
отбросит ее через некоторое время. Этот интервал времени назван time
to live(временем жизни), или TTL. TTL задается администратором данной
зоны.

3.6.4 Областные сервера имен (Domain Name Servers)

Сервера имен, которые содержат всю информацию относительно хостов
в пределах данной зоны названы авторитарными для этой зоны и иногда
упоминаются как master name servers. Любой запрос относительно хоста в
пределах этой зоны будет в конце концов передан одному из этих
серверов.

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

Одна из причин иметь несколько серверов имен состoит в том, чтобы
распределять груз работы, другая -- надежность. Когда одна машина с
сервером имен ломается, все запросы будут посылаться другим серверам.
Конечно, эта схема не защищает Вас от сбоев сервера, при которых он
отсылает неправильные ответы на все запросы DNS, например от ошибок в
программе сервера.

Конечно, Вы можете также создать сервер имени, который не будет
авторитарным для любой области. Этот тип серверов используется чтобы
проверять запросы от местных приложений и кэшировать ответы. Поэтому
его называют caching-only сервером.

3.6.5 База данных DNS

Мы видели, что DNS имеет дело не только с IP адресами хостов, но
также обменивается информацией относительно серверов имен. В DNS базе
данных фактически имеется целая куча различных типов записей.

Единица информации в DNS базе данных названа resource record
(записью ресурса), или RR. Каждая запись имеет определенный тип,
описывающий тип данных, которые в ней записаны, и определяющий тип
сети, к которой она применяется. Последний используется при
определении схемы адресования, типа IP адресов (IN класс), или адресов
в Hesiod сетях (используемые в MIT), и др. Основной записью ресурсов
является запись, которая связывает полное имя области с IP адресом.

Конечно, хост может иметь больше чем одно имя. Однако, одно из
этих имен должно быть определенно как официальное, или каноническое
имя хоста, в то время как остальные просто псевдонимы. Различие между
ними в том, что каноническое имя хоста связано с А записью, в то время
как другие только с записью типа CNAME, которая указывает на
каноническое имя хоста.

Мы не будем приводить здесь все типы записей, а сделаем это
позже, в другой главе, здесь же ограничимся кратким примером. Картинка
3.6.5 показывает часть базы данных области которая загружена на
сервере имен для зоны physics.groucho.edu.

Кроме A и CNAME записи, Вы можете видеть специальную, занимающую
несколько строк, запись сверху файла. Это - SOA запись ресурса,
расшифровывается Start of Authority (Начало Власти), которая содержит
общую информацию относительно зоны, для которой этот сервер является
авторитарным. Она включает, например, время жизни для всех записей.

Обратите Внимание что все имена в файле с примером, которые не
заканчиваются точкой интерпретируются относительно groucho.edu
области. Специальное имя "@", используемое в SOA записи при обращении
к имени данной области.

Мы видели, что сервера имен для groucho.edu области так или иначе
должен знать хоть что-то относительно зоны физиков так, чтобы
направлять запросы серверам имен. Это обычно достигается парой
записей: NS запись дается FQDN, и А запись, ассоциирующая его имя с IP
адресом. Так как эти записи появляются вместе, они часто называются
склеенными записями. Это -- фактически единственный случаи записи, в
которой родительская зона держит информацию относительно хостов в
зоне подчиненного. Склеенные записи указывающие на сервера имен для
physics.groucho.edu показаны на рисунке 3.6.5.

;
; Authoritative Information on physics.groucho.edu
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
1034 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
;
; Name servers
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Theoretical Physics (subnet 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Collider Lab. (subnet 14)
boson IN A 149.76.14.1

muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...

Картинка 5. фрагмент файла amed.hosts для Отдела Физики.

3.6.6. Обратный поиск.

После обнаружения IP адреса, принадлежащего хосту, иногда
желательно выяснять каноническое имя хоста, соответствующее данному
адресу. Это называется reverse mapping(обратное отображение) и
используется несколькими сервесами, чтобы проверить идентичность
клиента. При использовании единственного hosts файла, обратный поиск
заключается просто в проверке этого файла. В DNS, конечно не
проводится просмотр всего адресного пространсва. Вместо этого, создана
специальная область, inaddr.arpa, она содержит IP адреса всех хостов.
в перевернутой dotted-quad записи Например, IP адрес 149.76.12.4
соответствует имени 4.12.76.149.in-addr.arpa. Тип записи ресурса,
связывающий это имя с именем, называется PTR.

;
; Zone data for the groucho.edu zone.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
....
;
; Glue records for the physics.groucho.edu zone
physics IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
...

Картинка 6. фрагмент файла named.hosts для GMU.

Создание зоны полномочий обычно означает что ее администраторам
дают полный контроль над тем как назначать адреса и имена хостов. Так
как они обычно управляют одной или более IP сетями или подсетями, одна
DNS зона может охватывать несколько IP сетей. Отдел Физики, например,
включает подсети 149.76.8.0, 149.76.12.0, и 149.76.14.0.

Как следствие, новые зоны должны быть записаны в in-addr.arpa
области: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, и
14.76.149.in-addr.arpa. Иначе, установка нового хоста в Collider
лаборатории требовала бы обращения к родительской области чтобы
отметится в ее in-addr.arpa файле. Зональная база данных для подсети
12 показана на картинке 3.6.6. Соответствующие склеенные записи в базе
данных зоны родителя показывается на картинке 3.6.6.

;
; the 12.76.149.in-addr.arpa domain.
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
233 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu.

Картинка 7. фрагмент файла named.rev для подсети 12.

;
; the 76.149.in-addr.arpa domain.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 360000 3600 3600000 3600
}
...
; subnet 4: Mathematics Dept.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; subnet 12: Physics Dept, separate zone
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
...

Картинка 8. фрагмент файла named.rev для сети

Одно важное следствие этого то, что зоны могут создаваться только
как наборы IP сетей, и, даже круче, количество нулевых битов в
netmasks должно выть кратно 8. Все подсети в Groucho Marx Университете
имеют netmask 255.255.255.0, так что in-addr.arpa зона может быть
создана для каждой подсети. Однако, если netmask 255.255.255.128,
создание зон для подсети 149.76.12.128 будет невозможно, потому что
нет никакой возможности сообщить DNS, что 12.76.149.in-addr.arpa
область была раздроблена на две зоны, с именами хостов
располагающимися от 1 до 127, и 128 до 255, соответственно.

                       Назад | Содержание | Вперед