ager as central nameserver: nameserver 191.72.1.1 При определении имени vale, решающее устройство искало бы его и в случае неудачи, vale.vbrew.com, и vale.com. 7.1.4 Ошибкоустойчивость решающего устройства. Если Вы запускаете LAN внутри большей сети, Вы непременно должны использовать центральные сервера, если они доступны. Преимущество этого состоит в том, что они разработают богатые кэши, так как все запросы направлены к ним. Эта схема имеет недостаток: когда сгорел базовый кабель в нашем университете при пожаре, невозможно было дальше работать на LAN нашего отдела, потому что решающее устройство не могло достичь какого-либо из серверов. Не было login на X-terminals, не было печати на принтерах, и т.д. - 110 - Хотя это не гоже для университетского городка, опускаться до пожаров, каждый обязан соблюдать технику безопаности, чтобы избежать случаев подобных этим. One - устанавливает локальный сервер, который определяет hostnames из вашей локальной области, и делает вперед все запросы для других hostnames к главным серверам. Конечно, это применимо только тогда, когда Вы используете вашу собственную область. В качестве альтернативы, Вы можете сохранить таблицу сохраненных хостов Вашей области или LAN в /etc/hosts. В /etc/host.conf Вы можете включить "order bind hosts" для того, чтобы решающее устройство вернулась бы к хост файлу, если центральный сервер ослабел или вышел из строя. 7.2 Запуск named. Программа, которая обеспечивает обслуживание имени области на большинстве Unix машин обычно называется named. Эта программа первоначально разработанна для BSD обеспечения клиентуры, и ,возможно, для других серверов. Эта версия в настоящее время используется на большинстве Linux инсталяционных пакетов, как мне кажеться это BIND- 4.8.3. Новая версия, BIND-4.9.3, тестируется бетой в этот момент, и должна быть скоро доступна на Linux. Этот раздел требует некоторого понимания как работает Domain Name System. Если следующее изложение будет не совсем Вам понятно, то Вам следует перечитать главу 3., которая имеет более подробную информацию по основам DNS. Named обычно запускается при начальной загрузке сичтемы, и работает пока машина вновь не перезагрузится. Она черпает информацию из конфигурационного файла называемого /etc/named.boot, и из различных файлов, которые содержат набор данных имен областей адресов. Далее они будут называться zone files. Форматы и семантика этих файлов будут объяснены в следующем разделе. Для запуска named, просто введите в командной строке: # /usr/sbin/named - 111 - Появится named, читает named.boot файл и zone file, установленные там. Он записывает идентичность процесса id к /var/run/named.pid в ASCII, выгружая любые zone files из основных серверов, в случае необходимости запускает listening на порт 53 для запросов DNS. (1) 7.2.1 Файл named.boot. Файл named.boot в основном очень мал и содержит еще немного информации, но содержит указатели на главные файлы, содержащие zone информацию, и указатели к другим серверам. Комментарии в файле начальной загрузки начинаются с точки с запятой и простираются вплоть до следующей линии. Прежде, чем мы обсудим формат named.boot файла более подробно, мы рассмотрим типовой файл для vlager представленный на рисунке 7.2.1. (2) Кэш и основные команды, показанные в этом примере загружают информацию в named. Эта информация берется из главного файла, определенного во втором аргументе. Он содержат текстовые представления DNS источника записи, которые мы рассмотрим ниже. 1. Имеются различные named binaries касающиеся Linux FTP sites, каждые из которых не намного, но отличаются друг от друга. Некоторые имеют свой собственный pid файл, некоторые хранят его в /tmp или /var/tmp. 2. Заметьте, что имена областей в этом примере даны без конечной точки. Более ранние версии named принимают конечные точки в named.boot за ошибку, и их отбрасывают. BIND-4.9.3, как уже упоминалось, устраняет это. ; ; /etc/named.boot file for vlager.vbrew.com ; directory /var/named ; ; domain file ;--------------------------------------------------- - 112 - cache . named.ca primary vbrew.com named.hosts primary 0.0.127.in-addr.arpa named.local primary 72.191.in-addr.arpa named.rev Рисунок 9. Named.boot файл для vlager. В этом примере, мы сконфигурировали named как основной сервер для трех областей, как обозначено основными операторами в конце файла. Первая из этих строк, например, инструктирует named действовать как основной сервер для vbrew.com, принимая zone данные из файла named.hosts. Ключевое слово каталога сообщает ему, что все zone files размещаются в /var/named. Кеш запись очень особа и должна присутствовать фактически на всех машинах, запускающих сервер. Его функция - двукратная: она инструктирует named для отмены кэша, и загружает основной сервер hints из кэш файла (named.ca в нашем примере). Мы вернемся к серверам hints ниже. Также имеется список наиболее важных опций, которые Вы можете использовать named.boot: directory - определяет директорию, в которой zone files постоянно находятся. Имена файлов могут быть даны относительно этой директории.Несколько директорий могут быть определены неоднократно используя directory. Согласно стандарту Linux filesystem, эта директория должна быть /var/named. primary - берет имя области и имя файла как аргумент, объявленный локальным сервером авторитарно для named области. Как основной сервер, named загружает zone информацию из данного главного файла. В основном будет всегда, по крайней мере хотя бы одна основная запичь в каждом boot-файле, а именно для обратного отбора сети 127.0.0.0, которая является локальной замкнутой сетью. - 113 - secondary - берет имя области, список адресов, и имя файла как аргумент. Он объявляет локальный сервер вторичным главным сервером для установленной области.Вторичный сервер задерживает авторитарные данные поступающие на область, но он не собирает их из файла, и пробует загрузить их из основного сервера. IP адрес, по крайней мере одного основного сервера, должен быть дан named(у) в списке адресов. Локальный сервер войдет в контакт с каждым из них, пока он успешно не перенесет всю зональную базу данных, которая затем будет сохранена в файле с резервной копией, данной как третий аргумент. Если ни один из основных серверов не отвечает,то зональные данные восстановятся из файла с резервной копией взамен.named затем пытается обновить зональные данные в постоянные интервалы. Это объясняется ниже с SOA типом записи. cache -Эта опция берет область и имя файла как аргументы. Этот файл содержит подсказки сервера hints, который является списком записей, указывающих на серверы. Но только NS и А записи будут признаны. Аргумент области, в основном ,- источник имени области.Эта очень важно: если кэш оператор не пояляется в boot-файле, named не начинает разрабатывать локальный кэш вообще. Это строго ухудшит характеристику и увеличит сетевую загрузку, если следующий сервер делает запрос не на локальную сеть. Кроме того, named не будет способен достичь всех серверов, и таким образом это не решит проблему адресов за исключением тех, которые авторитарны. Исключение из этого правила - это когда используются серверы пересылки (опция механизмов продвижения дана ниже). forwarders -Этот оператор берет список адреса как аргумент. IP адреса в этом списке точно определяют список серверов, на которые named может сделать запрос, решается ли запрос из его локального кэша. Они тестируются по порядку, пока один из них не отвечает на запрос. slave - это оператор делает главный сервер подчиненным сервером. То есть он никогда не будет выполнять рекурсивные запросы самостоятельно, и будет только направлять их к серверам определенных с forwarders оператором. - 114 - Имеются две опции, которые мы не будем описывать здесь, это sortlist и domain. Дополнительно, имеются две директивы, которые могут использоваться внутри zone файлов базы данных. Это - $INCLUDE и $ORIGIN. Так как они редко когда понадобятся, то мы не будем описывать их здесь. 7.2.2 DNS файл базы данных. Основной файл включаемый named, подобно named.hosts, всегда имеет область соединенную с ним, которая называется origin. Это - область название которой определено с кэшем и с основными командами. Внутри основного файла Вам дозволено определить область и имена хостов относительно этой области. Имя, данное в файле конфигурации, считается абсолютным, если оно заканчивается в единственной точке, иначе она будет рассматривается относительно origin. Весь оrigin может быть упомянут, если Вы используете "@". Все данные, содержащиеся в основном файле определены в источнике записей, или Rrs(resource records) для краткости. Они составляют самую малую единицу информации доступную через DNS. Каждый способ записи имеет тип. Запись, например отображение имени хоста к IP адресу, и CNAME запись ассоциируется с псевдонимом для хоста с его официальным именем. Например, посмотрите на рисунок 7.2.3 на странице 116, которая показывает named.hosts основной файл для virtual brewery. Способ записи в основых файлах является общим форматом: [domain] [ttl] [class] type rdata Поля отделены пробелами или табуляцией. Запись может быть продолжена через несколько строк, если открываящая"фигурная скобка появляется перед первой строкой, и последнее поле оканчивается закрывающей фигурной скобкой. Что-либо между точкой с запятой и новой строкой игнорируется. domain Это имя области в которой появляется запись. Если имя области не дано, RR попытается обратиться к области из предыдущего RR. ttl Необходим для того чтобы заставить решающие устройства - 115 - отбрасывать информацию после определенного промежутка времени, каждый RR ассоциируется с "time to live'', или ttl для краткости. Поле ttl определяет время в секундах. information имеет силу после того, как она была найдено на сервере. Это - десятичное число с восемью разрядами. Если ttl значение не дано, то будет использоваться значение по умолчанию к значению минимального поля предшествующей SOA записи. class Это - класс адреса, подобно IN для IP адресов, или HS для объекта в Hesoid классе. Для TCP/IP сетей, Вам необходимо сделать это IN. Если никакой класс поля не дан,то будет принят класс предшествующего RR. type Это описывает тип RR. Наиболее общие типы: A, SOA, PTR, и NS. Следующие разделы описывают различные типы RR. rdata Это задерживает данные связанные с RR. Формат этого поля зависит от типа RR. Ниже, это будет описано для каждого RR поотдельности. following - незавершенный список RR, который нужно использовать в DNS основном файле. Имеется несколько пар из них, которые мы не будем объяснять. Они являются экспериментальными, и вообще, небольшого использования. SOA Это описывает зону власти (SOA означает " Start of Authority''). Он сообщает что запись следующая за SOA RR содержите авторитарную информацию для области. Каждый основной файл, включенный основным оператором должен содержать SOA запись для этой зоны. Источники данных содержат следующиз поля: origin Это - каноническое имя хоста основного сервера для этой области. Обычно дается как абсолютное имя. - 116 - contact Это - email адрес человека ответственного за поддержания области, со знаком "@" в качестве точки. Например, если ответственный в Virtual Brewery - janet, то тогда это поле содержало бы janet.vbrew.com. serial Это - номер версии зонального файла, выраженный как единственное десятичное число. Всякий раз, когда данные меняются в зональном файле, то это число должно быть увеличено. Серийный номер используется вторичными серверами, чтобы распознать, когда зональная информация была изменена. Чтобы оставаться на уровне современных требований, вторичные серверы запрашивают SOA запись примарного сервера в определенные промежутки времени, и сравнивают порядковый номер с кэшируемой SOA записью. Если номер изменился, то вторичные серверы переносут целую зону баз данных из основного сервера. refresh Определяет интервал, в секундах, который вторичные серверы должны использовать между проверками SOA записей основного сервера. Это - десятичный номер более чем с восемью разрядами. В основном, сетевая топология слишком часто не изменяется для того, чтобы этот номер точно определял интервал для сликшом бурных дней больших сетей, и даже для меньших сетей. retry Этот номер определяет интервалы за которые вторичный сервер должен повторить соединение с основным сервером, если запрос или зональная регенерация терпит неудачу. Он не должно быть слишком маленьким, потому что даже временный отказ сервера или сетевая проблема могут потратить впустую все сетевые ресурсы. Один час, или возможно полчаса, могли бы быть хорошим выбором. expire - определяет время в секундах после которого сервер должен наконец-то отбросить все зональные данные, если невозможно было войти в контакт с основным сервером. Этот промежуток времени в основном должен быть очень большим. Craig Hunt (GETS "hunt - tcpip"]) рекомендует 42 дня. - 117 - minimum - задает по умолчанию ttl значение для исходных записей, которые точно не определяют его. Требует другого сервера, чтобы отбросить RR при проверки после определенного кол-ва времени. Ничего нельзя сделать с временем после которого вторичный сервер попробует модифицировать зональную информацию. minimum должен быть большим значением, особенно для LANs, где сетевая топология почти никогда не меняется. Значение в неделю или в месяц. В случае, когда единственные Rrs могут часто изменяться, то Вы все еще можете приписывать им различные ttl. A Ассоциирует IP адрес с hostname. Источник полей данных содержит адрес в dotted quad notation. Для каждого хоста должна быть только одна запись. Hostname используемый в этой А записи рассматривается служебным или каноническим hostname. Все другие hostnames - псевдонимы и должны быть отображены на каноническом hostname используя CNAME запись. NS Указывает на главный сервер подчиненной зоны. Для объяснения, почему, каждый должен иметь NS запись, просмотрите раздел 3.6. Источник полей данных содержит hostname сервера. Можно разрешить дополнительный hostname к A записи, так называемый glue, которая дает IP адрес сервера. CNAME Ассоциирует псевдоним хоста с его каноническим hostname. Каноническиий hostname - главный файл, который обеспечивает А запись; псевдонимы просто связаны с этим именем CNAME записью, но не имеют собственные записи. - 118 - PTR Этот тип записи используется, для того, чтобы соединить имя в Addr.arpa области с hostnaoes. Это используется для обратного отображения IP адресов к hostnames. Данный hostname должен быть каноническим hostname. MX Эта RR объявляет преобразователь почты для области. Для чего надо иметь преобразователи почты, обсуждено в разделе 14.4.1 в главе 14.. Синтаксис MX записи следующий: [domain] [ttl] [class] MX preference host host объявляет преобразователь почты для области. Каждый преобразователь почты предпочитает целое число, связанное с этим хостом. Агент переноса почты, то кто желает доставить почту к области, будет перебирать все хосты, не имеющие MX записей в этой области, пока все не пойдет успешно. Сначала будет пробоваться тот хост, у которого самое низкое число, а дальше все хосты с числом по возрастанию (это число называется-preference value). HINFO Эта запись предоставляет информацию относительно аппаратных средств системы и программного обеспечения. Синтаксис этой записи: [domain] [ttl] [class] HINFO hardware software Аппаратная область идентифицирует аппаратные средства, используемые этим хостом. Имеются специальные соглашения, чтобы точно определить ее. Список подходящих имен дан в "Assigned Numbers'' (RFС 1340). Если область содержит пробелы, то это надо заключить в двойные кавычки. Имена областей программного обеспечения используються операционной системой. И снова, подходящее имя может быть выбрано из "Assigned Numbers'' RFC. 7.2.3 Запись главных файлов. - 119 - Рисунки 7.2.3, 7.2.3, 7.2.3, и 7.2.3 дают примерные файлы для названия сервера в brewery, размещенном на vlager. Вследствие характера обсуждаемой сети (единственная локальная вычислительная сеть), пример - довольно простой. Если ваши требования чересчур сложны, и Вы не можете запустить named, то вам поможет "DNS and BIND'' by Cricket Liu and Paul Albitz ([GETST "liu-dns"]). & " Кэш файл named.ca, который вы увидите на рисунке 7.2.3, показывает пример hint записи для root name сервера. Типичный кеш файл обычно описывает около дюжины серверов, или около того. Вы можете получить текущий список серверов для root области, используя nslookup, описанный ближе к концу этой главы.(3) ; ; /var/named/named.ca Cache file for the brewery. ; We're not on the Internet, so we don't need ; any root servers. To activate these ; records, remove the semicolons. ; ; . 99999999 IN NS NS.NIC.DDN.MIL ; NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103 ; . 99999999 IN NS NS.NASA.GOV ; NS.NASA.GOV 99999999 IN A 128.102.16.10 Рисунок 10. Файл named.ca. 7.2.4 Проверка установки сервера(Name Server Setup). 3. Заметьте, что Вы не сможете сделать запрос для Вашего сервера на root серверы, если Вы не имеете какие-нибудь root server hints: Захватите 22! Чтобы выйти из этой дилеммы, Вы можете также попробовать заставите nslookup использовать другой сервер, или Вы можете использовать примерный файл на рисунке 7.2.3, и затем получить полный список подходящих серверов. - 120 - ; ; /var/named/named.hosts Local hosts at the brewery ; Origin is vbrew.com ; @ IN SOA vlager.vbrew.com. ( janet.vbrew.com. 16 ; serial 86400 ; refresh: once per day 3600 ; retry: ong howr 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; ; local mail is distributed on vlager IN MX 10 vlager ; ; loopback address localhost. IN A 127.0.0.1 ; brewery Ethernet vlager IN A 191.72.1.1 vlager-if1 IN CNAME vlager ; vlager is also news server news IN CNAME vlager vstout IN A 191.72.1.2 vale IN A 191.72.1.3 ; winery Ethernet vlager-if2 IN A 191.72.2.1 vbardolino IN A 191.72.2.2 vchianti IN A 191.72.2.3 vbeaujolais IN A 191.72.2.4 Рисунок 11. Файл named.hosts. Существует прекрасное средство для проверки действия установки - 121 - Вашего сервера(server setup). Оно называется nslookup, и может быть использовано и в интерактивном режиме и из командной строки. В последнем случае, Вы просто вызываете ее как nslookup hostname и она сделает запрос на сервер, определенный в resolv.conf, для hostname. (Если эти имена файла больше чем один сервер, nslookup выберет какой-нибудь один) ; ; /var/named/named.local Reverse mapping of 127.0.0 ; Origin is 0.0.127.in- addr.arpa. ; @ IN SOA vlager.vbrew.com. ( joe.vbrew.com. 1 ; serial " " 360000 ; refresh: 100 hrs 3600 ; retry: one hour 3600000 ; expire: 42 days ; minimum: 100 hrs ) IN NS vlager.vbrew.com. 1 IN PTR localhost. Рисунок 12. Файл named.local. Интерактивный режим, является намного более захватывающим. Кроме того при просмотре индивидуальных хостов, Вы можете сделать запрос для любого типа DNS записи, и перенести зональную информацию для области. Когда он вызывается без аргумента, nslookup отобразит название используемого сервера, и вступить в интерактивный режим. В " > " приглашении(prompt), Вы можете ввести любое имя для которого должен быть сделан запрос. По умолчанию, он опросит класс A записи, содержащий IP - 122 - адреса в отношении названия области. Вы можете изменить этот тип, используя "set type=type", где type(тип) является одним из исходных названий записи, описанных выше в разделе 7.2, или ANY. Например, у Вас мог бы получиться следующий диалог: ; ; /var/named/named.rev Reverse mapping of our IP addresses ; Origin is 72.191.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. ( joe.vbrew.com. 16 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum; 1 week ) IN NS vlager.vbrew.com. ; brewery 1.1 IN PTR vlager.vbrew.com. 2.1 IN PTR vstout.vbrew.com. 3.1 IN PTR vale.vbrew.com. ; winery 1.2 IN PTR vlager-if1.vbrew.com. 2.2 IN PTR vbardolino.vbrew.com. 3.2 IN PTR vchianti.vbrew.com. 4.2 IN PTR vbeaujolais.vbrew.com. Рисунок 13. Файл named.rev. - 123 - $ nslookup Default Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 > sunsite.unc.edu Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 Non-authoritative answer: Name: sunsite.unc.edu Address: 152.2.22.81 Если Вы попробуете сделать запрос на имя, которое не имеет никакого связанного IP адреса, но другие записи были найдены в DNS базе данных, то nslookup сообщит об ошибке: "No type A records found''. Однако, Вы можете заставить сделать запрос для записей других типов (не А), введя "set type" команду. Например, чтобы получить SOA запись unc.edu, Вы бы ввели: > unc.edu *** No address (A) records available for unc.edu Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 > set type=SOA > unc.edu Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 Non-authoritative answer: unc.edu origin = ns.unc.edu & mcil addr = shava.ns.unc.edu serial = 930408 refresh = 28800 (8 hours) - 124 - retry = 3600 (1 hour) expire = 1209600 (14 days) minimum ttl = 86400 (1 day) Authoritative answers can be found from: UNC.EDU nameserver = SAMBA.ACS.UNC.EDU SAMBA.ACS.UNC.EDU internet address = 128.109.157.30 Таким образом Вы можете сделать запрос для MX записей, и т.д. Использование типа ANY вернет все исходные записи, связанные с данным именем. > set type=MX > unc.edu Non-authoritative answer: unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu lambada.oit.unc.edu internet address = 152.2.22.80 Authoritative answers can be found from: UNC.EDU nameserver = SAMBA.ACS.UNC.EDU SAMBA.ACS.UNC.EDU internet address = 128.109.157.30 Практическое применение nslookup, помимо отладки, - получить текущий список root серверов для файла named.ca. Вы можете сделать это, запрашивая все типы NS записей, связанные с root областью: > set typ=NS > . Name Server: fb0430.mathematik.th-darmstadt.de Address: 130.83.2.30 Non-authoritative answer: (root) nameserver = NS.INTERNIC.NET (root) nameserver = AOS.ARL.ARMY.MIL (root) nameserver = C.NYSER.NET - 125 - (root) nameserver = TERP.UMD.EDU (root) nameserver = NS.NASA.GOV (root) nameserver = NIC.NORDU.NET (root) nameserver = NS.NIC.DDN.MIL Authoritative answers can be found from: (root) nameserver = NS.INTERNIC.NET (root) nameserver = AOS.ARL.ARMY.MIL (root) nameserver = C.NYSER.NET (root) nameserver = TERP.UMD.EDU (root) nameserver = NS.NASA.GOV (root) nameserver = NIC.NORDU.NET (root) nameserver = NS.NIC.DDN.MIL NS.INTERNIC.NET internet address = 198.41.0.4 AOS.ARL.ARMY.MIL internet address = 128.63.4.82 AOS.ARL.ARMY.MIL internet address = 192.5.25.82 AOS.ARL.ARMY.MIL internet address = 26.3.0.29 C.NYSER.NET internet address = 192.33.4.12 TERP.UMD.EDU internet address = 128.8.10.90 NS.NASA.GOV internet address = 128.102.16.10 NS.NASA.GOV internet address = 192.52.195.10 NS.NASA.GOV internet address = 45.13.10.121 NIC.NORDU.NET internet address = 192.36.148.17 NS.NIC.DDN.MIL internet address = 192.112.36.4 Полная система команд, доступных с nslookup может быть получена при использовании команды help изнутри nslookup. 7.2.5 Другие полезные инструментальные средства Имеется несколько инструментальных средств, которые помогут Вам с Вашими задачами как BIND администратор. Я кратко опишу два из них. Пожалуйста обратитесь к документации, которая прилагается с этими инструментальными средствами для выяснения того, как их использовать. hostcvt - средство, которое помогает Вам с Вашей начальной - 126 - BIND конфигурации, преобразовывая ваш /etc/hosts файл в главный файл для named. Оно генерирует оба и прямое (A) и обратное отбражение (PTR), и заботится о псевдонимах и т.п. Конечно, оно не будет делать всю работу за Вас, поскольку Вы можете все еще захотеть настроить значения блокировки по втемепи в SOA записи сами, например, или прибавить MX запись и т.п. Но оно может помочь сохранить Вам несколько таблеток аспирина. Hostcvt - часть BIND источника, но может также быть использован как автономный пакет на несколько Linux FTP серверах. После установки вашего сервера, Вы можт быть захотите проверить Вашу конфигурацию. Идеальным (и, по моему мнению тоже) средством для этого является dnswalk, perl-based пакет который прогуливается по вашей DNS базе данных, выискивая общие ошибки и проверяет совместимость информации. Dnswalk был выпущен на comp.sources.misc недавно, и должен быть доступен на всех FTP, которые архивируют эту группу. 8. Последовательная линия IP Порядковые протоколы линии связи, SLIP и PPP, обеспечивают Internet connectivity для плохой связи. Кроме модема и последовательной оборудованной панели с FIFO буфером, никакие аппаратные средства не нужны. Использование его - не намного усложняется чем использование mailbox, и поэтому увеличивается число частных организаций, которые предлагают телефонный вызов по номеру IP за доступную стоимость каждому. Имеются оба драйвера доступные для Linux- SLIP и PPP. SLIP был там в течение долгого времени, и работает достаточно неплохо. А PPP драйвер был разработан совсем недавно MIchael Callahan и Al Longyear. Этот драйвер будет описан в следующей главе. 8.1 Общие требования. Для того, чтобы использовать SLIP или PPP, Вы должны сконфигурировать некоторую базисную работу с сетями, как описано в - 127 - предыдущих главах. Наконец Вы должны установить looback interface, и обеспечить для name resolution. При соединении с Internet, Вы несомненно пожелаете использовать DNS. Самая простая опция - поместит адрес сервера в Ваш resolv.conf файл; этот сервер сделает запрос как только SLIP связь будет активизированна. Однако, это решение не оптимально, потому что все поиски имен будут все еще проходить через вашу SLIP/PPP связь. Если Вы волнуетесь относительно ширины зоны, которую она требует, то Вы может также установить cache-only сервер. Он действительно не обслуживающий, он только действует как переключатель для всех DNS запросов, произведенных на Вашем хосте. Преимущество этой схемы - то, что она создает кэш, так, чтобы большинство запросов должны быть посланы через последовательные линии только один раз. Named.boot файл для cache-only серверов, выглядит так: ; named.boot file for caching-only server directory /var/named primary 0.0.127.in-addr.arpa db.127.0.0 ; loopback net cache . db.cache ; root servers В дополнение к этому файлу, Вы также должны установить db.cache файл с подходящим списком root серверов. Это описывается ближе к концу главы "Конфигурация решающего устройства". 8.2 SLIP Операция. Телефонный вызов IP серверов часто предлагает SLIP обслуживание через специальные пользовательские account(ы). После login в такой account, Вы не входите в общую оболочку; взамен программа или script оболочки - отключат SLIP драйвер серверов последовательной линии и сконфигурируют соответствующий сетевой interface. Затем Вы должны сделать тоже самое в конце связи. - 128 - На некоторых операционных системах, SLIP драйвер -- user-space программа; под Linux, это - часть ядра, которая делает его намного быстрее. Требуется, однако, чтобы порядковая линия явно была бы преобразована в SLIP режим. Это выполнено посредством tty line discipline, SLIPDISC. Пока tty находится в обычной line discipline (DISC0), изменятся данные только с процессвми пользователя, используя normal read (2) и write(2) вызовы, SLIP драйвер - отключен для записи или чтения из tty, пока все данные, поступающие на серейный порт, будут пропущены SLIP драйвером. SLIP драйвер непосредственно понимает число разновидностей на SLIP протоколе. Кроме обычного SLIP, он также понимает CSLIP, который выполняется так называемым Van Jacobson header compression на выходящих IP блоков.(1) Дополнительно, имеются шести-битовые версии для каждого из этих протоколов. Простой способ преобразовать последовательную линию в SLIP режим - использовать slattach. Допустим, что у Вас есть модем на /dev/cua3, и Вы удачно подсоеденились на SLIP сервер. Вы затем бы выполнили: #slattach /dev/cua3 & Это включит line discipline cua3 к SLIPDISC, и подсоединит ее к одному из interface SLIP сети. Если это ваша первая активная SLIP связь, то линия будет подсоединена к sl0; вторая была бы подсоединенп к sl1, и так далее. Текущие ядра поддерживают до восьми одновременных SLIP связей. 1. Van Jacobson header compression описан в RFC 1441. Заданное по умолчанию оформление пакета, выбранное slattach - CSLIP. Вы можете выбрать любой другой режим, используя -p переключатель. Для того, чтобы использовать normal SLIP (no compression), Вы должны использовать # slattach -p slip /dev/cua3 & - 129 - Другие режимы - cslip, slip6, cslip6 (для шести-битовой версии Slip(а)), и adaptive для адаптивного SLIP. Последние оставляют это для ядра, чтобы выяснить, который тип оформления пакета SLIP использует remote end. Заметьте, что Вы обязаны использовать такое же оформление, какое имеет Ваш peer. Например, если cowslip использует CSLIP,то Вы должны использовать его же. Симптомы рассогласования будут такие, что ping незначительному хосту не вернет блоки огратно. Если другой хост pings Вас, то Вы можете увидеть сообщение типа "Can't build ICMP header'' на вашем мониторе. Один способ избежать эту неприятность - надо использовать adaptive SLIP. Фактически, slattach не только не позволяет Вам отключить SLIP, но и не позволяет отключает другие протоколы, которые используют последовательную линию также, как и PPP или KISS (другой протокол, используемый людьми в ham radio). Для деталей, обратитесь пожалуйста к slattach инструкции стр. 8. После передачи линии SLIP драйверу, Вы должны сконфигурировать сетевой interface. И снова, мы используем стандарт ifconfig и route команды. Предположим, что из vlager мы соединилисьс сервером crowslip. Тогда Вы должны выполнить: # ifconfig sl0 vlager pointopoint cowslip # route add cowslip # route add default gw cowslip Первая команда конфигурирует interface как point-to-point связь к cowslip, в то время как вторая и третья команды прибавляет route к cowslip и задает по умолчанию маршрут, используемый cowslip как ворота. При демонтаже SLIP связи, Вы сначала должны удалить все маршруты cowslip, используя route c del опцией, уберите interface, и передаете slatch сигнал hangup(повесить трубку). Впоследствии Вы должны hangup модем, использующий Вашу терминал программу: - 130 - # route del default # route del cowslip # ifconfig sl0 down # kill -HUP 516 8.3 Использование dip Теперь это все просто. Однако, Вы могли бы захотеть автоматизировать вышеупомянутые шаги так, чтобы Вы только вызывли бы простую команду, которая выполняет все те шаги, показанные выше. Это - то, для чего нужен dip. (2) Текущее версия этого выпуска - версия 3.3.7. Онаисправлялась несколькими людьми, поэтому Вы уже больъе нз сможете говорить о dip как о программе. Эти различные элементы развития будут "обнадеживающе" слиты в будущей версии. Dip обеспечивает интерпретатор простым языком, который обрабатывает модем для Вас, преобразуя линию в SLIP режим, и конфигурируя interface. Это довольно примитивно и ограниченно, но вполне подходяще для большинства случаев. Новая версия dip(а) может описать большое количество многосторонних языков в один день. Чтобы было возможным сконфигурировать SLIP interface, dip требует root привелегию. Это теперь было бы соблазнительно для того, чтобы сделать dip setuid к root, таким образом Все пользователи могли бы соединиться с некоторым SLIP сервером без необходимости прдеоставления им root доступа. Это очень опасно, потому что при установке фиктивных interface(ов) и заданных по умолчанию маршрутов dip может разрушить направление на вашей сети. Даже еще хуже, это даст вашим пользователям приоритет на подсоединение к любым SLIP серверам, и начать опасную атаку на Вашу сеть. Так, если Вы хотите позволить Вашим пользователям запустить SLIP связь, напишите маленькие программки для каждого предполагаемого SLIP сервера, и вызовите dip со специфическим script(ом), который установит связь. Эти программы могут быть затем безопасно сделаны setuid root. (3) 8.3.1 Типовой Script(сценарий). - 131 - Типовой script аоказан на рисунке 8.3.1. Он может использоваться для связи с cowslip, вызывая dip со script именем как аргумент: 2. Dip подразумевается Dialup IP. Он был написан Fred van Kempen. 3. Diplogin может (или должен) быть запущен setuid(ом). См. раздел в конце этой главы. # Sample dip script for dialing up cowslip # Set local and remote name and address get $local vlager get $remote cowslip " port cua3 # choose a serial port speed 38400 # set speed to max modem HAYES # set modem type reset # reset modem and tty flush # flush out modem response # Prepare for dialing. send ATQ0V1E1X1\r wait OK 2 if $errlvl != 0 goto error dial 41988 if $errlvl != 0 goto error wait CONNECT 60 if $errlvl != 0 goto error # Okay, we're connected now sleep 3 send \r\n\r\n wait ogin: 10 if $errlvl != 0 goto error send Svlager\n wait ssword: 5 - 132 - if $errlvl != 0 goto error send hey-jude\n wait running 30 if $errlvl != 0 goto error # We have logged in, and the remote side is firing up SLIP. print Connected to $remote with address $rmtip default # Make this link our default route mode SLIP # We go to SLIP mode, too # fall through in case of error error: print SLIP to $remote failed. Рисунок 14. Типовой dip script. # dip cowslip.dip DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93) Written by Fred N. van Kempen, MicroWalt Corporation. connected to cowslip.moo.com with addr 193.174.7.129 # После соединения с cowslip и включением SLIP, dip отделится от терминала и отойдет к предоставлению возможности SLIP связи. Вы сможзте " затем начать использовать обычные сетевые услуги на SLIP связи. Чтобы завершить связь, просто вызовите dip c опцией -k. Это пошлет hangup сигнал dip процессу, используя id dip запись в /etc/dip.pid: (4) # kill -k На dip script языке, ключевые слова имеющие префикс с символом $ обозначают различные имена. Dip имеет предопределенное множество переменных, которые будут будут перечислены ниже. $remote и $local, - 133 - например, содержат hostnames локального и незначительного хоста, вовлеченных в SLIP связь. Первых два оператора в типовом script - получают команды, которые являются dip способом установки переменных. Здесь, локальный и незначительный hostname установленн к vlager и cowslip, соответственно. Следующие пять операторов устанавливают линию терминала и модема. Reset посылает reset строку к модему; для Hayes-совместимых модемов, это команда ATZ. Следующий оператор игнорирует реакцию модема, так что login chat в линиях работал правильно. Сhat - довольно прост: он просто набирает номер 41988, номер телефона cowslip, и подсоединятся в account Svlager через пароль hey-jude. Wait команда заставит dip ждать строку, данную как его первый аргумент; номер, данный как второй аргумент делает wait time, если никакая строка не была получена. If команды разбросаны в процедуре входа в систему, и проверяют то, что никакая ошибка не появилась при выполнении этой команды. Итоговые(final) команды, выполненные после logging, заданы по умолчанию, которые заставят SLIP связать заданный по умолчанию маршрут со всеми хостами, и режимом, который отключает SLIP на линии и конфигурирует interface и таблицу маршрутов(routing tables) для Вас. 4. См. newsgroup alt.tla для более палиндромической забавы с акронимами с тремя символами. 8.3.2 Dip ссылка. "Хотя широко используемый, dip не был еще очень хорошо описан. Поэтому, в этом разделе мы дадим ссылку для большинства dip команд. Вы можете получить краткий обзор всех команд, вызывая dip в test режиме, и вводя help команду. Для того, чтобы выяснять относительно синтаксиса команды, Вы можете набрать его без каких-либо аргументов; конечно это не работает с командами, которым не нужны никакие аргументы. $ dip -t - 134 - DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93) Written by Fred N. van Kempen, MicroWalt Corporation. DIP> help DIP knows about the following commands: databits default dial echo flush get goto help if init mode modem parity print port reset send sleep speed stopbits term wait DIP> echo Usage: echo on|off DIP> На всем протяжении, примеры, которые выделяют DIP> prompt показывают, как ввести команду в test режиме, и что output производится. Примеры, испытывающие недостаток в prompt должны приниматься как script отрывок. 8.3.2.1 Команды Модема. Имеется ряд rоманд, для которых dip обеспечивает конфигурацию вашей последовательной линии и модема. Некоторые из них - очевидны, такие как порт, который выбирает последовательный порт, и быстродействие, биты данных, стоповые биты, и четность, которые устанавливают общие параметры линии. Команда модема выбирает тип модема. В настоящее время, единственый поддерживаемый тип - HAYES. Вы должны обеспечить dip типом модема, или он откажется набирать номер и выполнять reset команды. Reset команда посылает reset строку на модем; используемая строка зависит от избраннпго вами типа модема. Для Hayes-совместимых модемов, это - ATZ. Flush code может использоваться для того, чтобы убрать все реакции, которые модем посылает so far. Иначе chat script мог бы быть спутанным, потому что он читает OK реакции из более ранних команд. - 135 - Команда init выбирает initialization строку, которую нужно набрать перед набором номера. Значение по умолчанию для Hayes модемов - "ATE0 Q0 V1 X1'', которая включает отображение на экране команд и long result code, и выбирает набор вслепую (нет проверки тона шкалы). Команда dial в конце посылает initialization строку на модем и набирает номер системы. Заданная по умолчанию dial команда для Hayes модемов - ATD. 8.3.2.2 echo и term. Команда ECHO служит как помощь в отладке, в которой использование ECHO ON делает dip ECHO на консоли и все посылает к порядковому устройству. Он может быть выключен снова, набирая ECHO OFF. Dip также позволяет Вам оставить script режим временно и вступить в terminal режим. В этом режиме, Вы можете использовать dip точно так же как и обычную terminal программу, пишущей в последовательную линию и читющей из нее. Чтобы оставить этот режим, введите " Ctrl-] ". 8.3.2.3 Get Команда. Get команда - dip способ установки переменной. Самая простая форма - установить переменную как константу, как это делалось в вышеупомянутом примере. Вы можете, также запросить пользователя для входа определяя ключевое слов вместо значения: DIP> get $local ask Enter the value for $local: Третий метод состоит в том, чтобы попробовать получить значение от отдаленного хоста. Причудливо, на первый взгляд, но это очень полезно в некоторых случаях: некоторые SLIP серверы не позволяют Вам использовать Ваш собственный IP адрес на SLIP связи, но будет приписывать Вам один из объединения адресов всякий раз, когда Вы - 136 - набираете номер, печатая сообщение, которое информирует Вас относительно адреса к которому Вы были назначены. Если просмотры сообщения - что - нибудь вроде этого ``Your address: 193.174.7.202'', то следующий фрагмент dip кода допустил бы Вас до подбора адреса: wait address: 10 get $locip remote 8.3.2.4 Print команда Это команда к ECHO тексту к dip консоли. Любая из dip переменных может использоваться в print командах, такие как: DIP> print Using port $port at speed $speed Using port cua3 at speed 38400 8.3.2.5 Переменные имена(Variable Names) Dip только понимает предопределенное множество переменных. Переменное имя всегда начинается с символа доллар и должен быть написан в нижнем регистре. $local и $locip переменные содержат название локального имени хоста и IP адреса. Установка hostname заставляет dip сохранить каноническиий hostname в $local, в то же самое время приписывая $locip соответствующий IP адрес. Аналогичная вещь случается при установке $locip. $remote и $rmtip переменные делают тоже самое для отдаленных хостов и адресов. $mtu содержит MTU значение для соединения. Эти пять переменных - единственые, которые могут быть назначены непосредственно используя get команду. Хост других переменных может быть только установлен через соответствующие команды, но может использовать и print опрераторы; это - $modem, $port, и $speed. $errlvl - переменная, через которую Вы можете обращаться к - 137 - результату последней выполненой команды. Уровень ошибки 0 указывает на успех, в то время как ненулевое значение обозначает ошибку. 8.3.2.6 If и Goto Команды If команда - более условная штука, чем то что обычно подрузамеваят  под if. Синтаксис: if var op number goto label где выражение должно быть простым сравнением между одной из переменных $errlvl, $locip, и $rmtip. Второй операнд должен быть целым числом; оператор op может быть один из ==,!=, <,>, < =, и > =. Команда goto делает выполнение из script continue строки, несущей эту метку. Метка должна появиться как первый токен в линии, и немедленно должна оканчиваться двоеточием. 8.3.2.7 send, wait и sleep Эти команды выполняют простые chat scripts в dip. Send выводит его аргументы на последовательную линию. Он не поддерживает переменные, но понимает все C-style backslash character sequences типа \n и \b. Знак тильды (~) используется как сокращение для каретки return/newline. wait берет слово как аргумент, и просматривает весь вход на последовательной линии, пока он не распознает это слово. Слово само по себе непосредственно не может содержать пробелы. Выборочно Вы можете дать wait timeout value как второй аргумент; если ожидаемое слово не получено внутри в течении заданного времени, команда возвратится со значением $errlvl равным 1. - 138 - Sleep оператор может быть использован для того, чтобы ждать некоторое количество времени, например, patiently ждет любую login последовательность для завершения. И снова, интервал определен в секундах. 8.3.2.8 mode и default Эти команды используются для того, чтобы переключить последовательную линию в SLIP режим и сконфигурировать interface. Mode команда - последняя команда, выполненная dip перед гонгом в daemon режиме. Пока ошибка не появляется, команда ничего не возвращает. Mode берет название протокола как аргумент. Dip постоянно распознает SLIP и CSLIP как подходящие имена. Текущая версия dip не понимает adcptive SLIP. После отключения SLIP режима на последовательной линии, dip выполняет ifconfig для того, чтобы сконфигурировать interface как двухточечную связь(point-to-point link), и вызвать маршрут к множеству маршрутов незначительного хоста. Если, кроме того, script выполняет заданную по умолчанию команду перед mode, то dip также задаcт по умолчанию точку маршрута на SLIP связь. 8.4 Запуск в server режиме Установка вашего SLIP клиента была трудной частью. Выполнение противоположного, а именно конфигурирование вашего хоста для того, чтобы действовать как SLIP сервер, - намного проще. Единственный способ сделать это - использовать dip в server режиме, который может быть достигнут, вызывая его как diplogin. Его главный файл конфигурации - /etc/diphosts, который присоединяет login имена к адресу этого хоста. В качестве альтернативы, Вы можете также использовать sliplogin, BSD-производное средство, которое описывает более - 139 - гибкую схему конфигурации, которая позволяет Вам выполнить shell scripts всякий раз, когда хост соединяется и разъединяется. В настоящее время это происходит на Бете. Обе программы требуют, чтобы Вы установили один login account на каждого SLIP клиента. Например, представте что Вы обеспечиваете SLIP обслуживание Arthur Dent в Dent.beta.com, Вы могли бы создать account названный dent, добавляя следующюю строку к вашему файлу пароля(passwd file): dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin Впоследствии, Вы должны были бы установит пароль Dent(а), утилиту passwd. Теперь, когда dent подключен, dip запустится как сервер. Чтобы определить, действительно ли ему разрешено использовать SLIP, нужно найти имя пользователя в /etc/diphosts. Этот файл подробно описывает& птава доступа и параметры соединения для каждого SLIP пользователя. Типовая запись для dent могла бы быть похожа на: dent::dent.beta.com:Arthur Dent:SLIP,296 Первая из отделяемых двоеточием областей - имя пользователя под которым он должен войти. Вторая область может содержать дополнительный пароль (см. ниже). Третья - hostname или IP адрес вызываемого хоста. Далее идет информационная область без специального значения (пока еще). Последняя область описывает параметры соединения. Это - список, отделенный запятыми, определяющий протокол (в настоящее время один из SLIP и CSLIP), следуя за MTU. Когда dent входит в систему, diplogin извлекает информацию относительно него из diphosts файла, и, если вторая область не пуста, подсказывает " Пароль внешней защиты ''. Строка, введенная пользователем - сравнивается с (нешифрованным) паролем из diphosts. Если они не соответствуют, то попытка входа в систему будет отклонена. - 140 - Это связь остается установленной, пока пользователь не отсоединяется, или модем не бросает линию. Diplogin затем возвратит линию к нормальной discipline line и выйдет. Diplogin требует привилегии супер-пользователя. Если Вы запустили dip setuid root, то Вы должны сделать diplogin отдельной копией dip(а) вместо простой связи. Diplogin может затем быть сделан setuid, без воздействия на состояние dip непосредственно. 9. Двухточечный Протокол(point-to-point protocol) 9.1 Распутывающий P's Точно так же как SLIP, PPP - протокол для того, чтобы посылать датаграммы через последовательную связь, но он адресует пару вышеупомянутых неточностей. Он позволяет сообщающиемся сторонам обсудить опции, такие как IP адрес и максимальный датаграмный размер во время запуска, и обеспечивает разрешение клкента. Для каждой из этих возможностей, PPP имеет отдельный протокол. Ниже, мы кратко рассмотрим эти базисные стандартные блоки PPP. Это обсуждение далеко не полно; и если Вы хотите выяснить что-либо относительно PPP, то я настоятельно рекомендую Вам прочитать спецификацию в RFC 1548, также как и dozen или companion RFCs. (1) В самой основе PPP лежит управление передачей данных высокого уровня, сокращенно HDLC(High-Level Data Link Control Protocol),(2), который определяет границы вокруг ндивидуальных структур PPP, и обеспечивает 16 разрядов контрольной суммы. В противоположность более примитивному оформлению SLIP пакета, PPP способен к захвату блоков из других протоколовтаких как IP типа IPX Novell's, или Appletalk. PPP достигает этого, добавляя область протокола к основному HDLC. LCP(Link Control Protocol), Протокол управления связи, используется на вершине HDLC для оговора опций, имеющих отношение к каналу связи, типа Maximum Receive Unit (MRU), которая заявляет - 141 - максимальный размер датаграммы одной стороны связи. Важный шаг в стадию конфигурации связи PPP клиентского разрешения. Хотя это не обязательно, это действительно должно было бы быть для dial- up линий. Обычно, вызываемый хост просит клиента зарегестрировать себя, доказывая, что он знает некоторый секретный ключ. Если клиент набрал неправильный ключ, то связь будет прервана. С PPP, разрешение работает обеими способами; то есть вызывающий может также просить, чтобы сервер опознал себя. Эти процедуры установления подлиности не зависят друг от друга. Имеются два протокола для различных типов разрешения, которые мы обсудим позже. Они именованы "Протоколом Установления Подлинности Пароля", или PAP(Password Authentication Protocol ), или CHAP(Challenge Handshake Authentication Protocol). Каждый сетевой протокол, который разбит поперек канала связи,  пожобно IP, AppleTalk, и т.д, сконфигурирован динамически, используя соответствующую Network Control Protocol (NCP). Например, чтобы послать IP датаграммы поперек 1. Релевантные RFCs перечислены в Annoted Bibiliography в конце этой книги. 2. Фактически, HDLC- намного более общий протокол, изобретенный Международной организацией по стандартизации связи, оба PPPs должны сначала обсудить, который из IP адресов каждый из них использует. Протокол управления, используемый для этого - IPCP, the Internet Protocol Control Protocol. Помимо посылки стандарта IP датаграммы поперек связи, PPP также поддерживает Van Jacobson header compression IP датаграмм. Это - метод для того, чтобы сократить заголовки TCP блоков к всего трем байтам. Это также используется в CSLIP, и - больше относится к VJ header compression. Использование сжатия может быть заключено в лимите времени запуска через IPCP. 9.2 PPP на Linux - 142 - На Linux, PPP функциональные возможности расщеплены на две части, low-level HDLC драйвер, который размещен в ядре, и пространство пользователя pppd daemon, которое обрабатывает различные протоколы управления. Текущее разъединение PPP для Linux - linux-ppp-1.0.0, которое содержит ядро PPP модуля, pppd, и программа, именованная chat используется для того, чтобы выполнить отдаленную связь. PPP kernel драйвер был написан Michael Callahan. Pppd был выведен из PPP реализации для Sun и 386BSD машин, который был написан Drew Perkins и другими, и поддерживается Paul Mackerras. Это было предоставлено к Linux Al Longyear. (3) chat был написан Karl Fox.(4) Точно так же как и SLIP, PPP выполнен посредством специальной line discipline. Для того, чтобы использовать последовательную линию как PPP связь, Вы сначала должпы уутановить связь над вашим модемом как обычно, и впоследствии преобразовать линию к PPP режиму. В этом методе, все входящие данные проходят через PPP драйвер, который проверяет входящие HDLC структуры для соответствия (каждая HDLC структура несет 16 битов контрольной суммы). В настоящее время, он способен к выбору, используя Van Jacobson header compression. Как только Linux поддерживает IPX, PPP драйвер будет расширен для того, чтобы обрабатывать IPX блоки. Kernel драйверу помогает pppd, PPP daemon, который выполняет целую инициализацию и опознавательный период, который является необходимым перед тем, как фактическое сетевое движение может быть послано поперек связи. Поведение Pppd может подстраиваться, используя ряд опций. PPP - комплексный, невозможно описать все из них в единственной главе. 3. Оба автора сказали, что они будут очень заняты некоторое время для того, чтобы вернуться. Если Вы имеете какие-либо вопросы относительно PPP в общем, то Вам лучше всего спросить бы людей относительно NET канала Linux activists mailing list.. 4. Karl@morningstar.com. - 143 - Эта книга, однако, не может покрывать все аспекты pppd, но даст Вам полное введение. Для более подробной информации, обратитесь к страницам инструкции и файлам README на pppd исходном распространении, которое должно помочь Вам отсортировать большинство вопросов, эта глава объясняет как это сделать. Если у Вас остаются проблемы даже после чтения всей документации, то Вы должны обратиться к newsgroup сomp.protocols.ppp для справки, которая является местом где Вы узнаете многое о pppd. 9.3 Запуск pppd Когда Вы хотите соединитьcя с Internet через PPP связь, Вы должны установить базисные возможности работы с сетями типа возврата цикла, и решающего устройства. Оба были описаны в предыдчщих" главах. Имеются некоторые вещи, которые нужно упоминать относительно использования DNS над последовательной связью; пожалуйста обратитесь к SLIP главе для описания. Как вводный пример того, как устанавливать PPP связь с pppd, представте, что Вы - во vlager снова. Вы уже соеденились с сервером по телефону, c3po, и зарегистрировались на ppp account. C3po уже запустила свой PPP драйвер. После выхода из коммуникационных программ, которые Вы используете для соединения по телефону, Вам необходимо выполнить следующую команду: # pppd /dev/cua3 38400 crtscts defaultroute Это переместит последовательную линию cua3 к PPP режиму и установит IP связь с c3po. Скорость передачи, используемая на последовательном порте будет 38400bps. Опция crtscts включает аппаратное рукопожатие на порт, который должен работать на скорости более чем 9600 бит\сек. Первую вещь, которую pppd делает после запуска - договориться о некоторых характеристиках связи, используя LCP. Обычно, заданное по умолчанию множество опций, о котором pppd попробует договориться, так что мы не будем подробно вдаваться в это. Мы возвратимся к LCP более - 144 - подробно несколько позже. В настоящее время, мы также принимаем, что c3po не требует какого-либо установление нашей подлинности, так что период конфигурации завершен успешно. Pppd будет договариваться о IP параметрах с peer используя IPCP, IP управляет протоколом. Так как мы не точно определяли IP адрес к pppd выше, то он попробует использовать адрес, полученный при наличии решающего устройство, при просмотре локального hostname. И затем объявят этот адрес друг другу. Обычно, ничего не случается с этими значениями по умолчанию. Даже если Ваша машина находится в Ethernet, Вы можете использовать тот же самый IP адрес для обоих. и для Ethernet, и для PPP interface. Но тем не менее, pppd позволяет Вам использовать различные адреса, или даже спрашивать Вашего peer для того, чтобы использовать некоторый специфический адрес. Эти опции обсуждены далее. После прохождения IPCP периода установки, pppd подготовит Ваш host's networking layer для того, чтобы использовать PPP связь. Сначала будет сконфигурированн PPP сетевой interface как point-to-point связь, используя ppp0 для первой PPP cвязи, которая является активной, ppp1 для второй, и так далее. Затем, он установит маршрутную таблицу, которая указывает на хост в другом конце связи. В примере, показанном выше, pppd сделает заданный по умолчанию сетевой маршрут к c3 опциии defaultroute. (5) Он азаставляет все датаграммы к хостам не на вашей локальной сети быть посланными к C3po. Имеется ряд различных маршрутов, которые pppd поддерживает, которые мы обсудим позже в этой главе. 9.4 Использование файлов опций Прежде чем pppd проанализирует аргументы командной строки, он просмотрит несколько файлов для опций, заданных по умолчанию. Эти - 145 - файлы могут содержать любые подходящие аргументы командной строки, распространяющиеся поперек произвольного числа линий. Комментарии представлены своими специальными знаками. Первый файл опций - /etc/ppp/options, который всегда просматривается тогда, когда запускается pppd. При использовании этого для установки некоторых глобальных значений по умолчанию - хорошая идея, потому что это позволит Вам сохранить пользователей от выполнения нескольких вещей, которые могут поставить под угрозу защиту. Например, чтобы pppd запросил некоторый вид установления подлинности (или PAP или CHAP) от peer, Вы бы добавили опцию auth к этому файлу. Эта опция необходима для того, чтобы стало невозможно установить PPP связь с любой системой, которая не в наших опозназательных базах данных. Другой файл опций, который читается после /etc/ppp/options - рpprc в исходном каталоге пользователя. Он позволяет каждому пользователю точно определить ее собственное множество опций по умолчанию. Типовой файл /etc/ppp/options мог бы выглядеть следующим образом: 5. Заданный по умолчанию сетевой маршрут может быть только установлен, если ни один из них не установлен. # Global options for pppd running on vlager.vbrew.com auth # require authentication usehostname # use local hostname for CHAP lock # use UUCP-style device locking domain vbrew.com # our domain name Первыя две из этих опций обращаются к установлению подлинности и будут объяснены ниже. Ключевое слово блокировки заставит pppd уступить стандарту UUCP метод блокировки устройства. С этим собранием, каждый процесс, который обращается к последовательному устройству, скажем /dev/cua3, создает файл блокировки, названный LCK.. cua3 в UUCP катологе, чтобы сообщить, что это устройство находится в использовании. Необходимо предотвратить любые другие программы типа minicom или uuci локального - 146 - устройства в то время как используется PPP. Причина в обеспечении этой опцией в глобальном конфигурационном файле - то, что опции типа тех, что были показанны выше не могут быть отменены, и они обеспечивают приемлемый уровень защиты. Заметьте однако, что некоторые опции могут быть отменены позже; один такой пример -соединить строку. 9.5 Набор номера с chat Одна из вещей, которая может испугать Вас как неудобная в вышеизложенным примере - то, что Вы должны установить связь вручную прежде, чем Вы могли бы запустить pppd. В отличие от dip, pppd не имеет собственный script язык для набора незначительной системы и регистрации, но полагается на некоторую внешнюю программу или shell script для того, чтобы сделать это. Команда, которая будет выполнена может быть дана pppd с connect командой line option. Pppd переназначит вход и выход к последовательной линии. Одна полезная программа для этого - expect, написанная Don Libes. Она имеет очень мощный язык основанный на Tcl, и была разработана точно для этого сорта приложения. Pppd пакет идет с подобной программой называемой called chat, которая позволяет Вам определить UUCP-style chat script. В основном, chat script состоит из чередующихся последовательности строк, которые мы ожидаем получить от отдаленной системы, и ответов, которые мы должны послать. Мы будем называть expect и send строки, соответственно. Это типичная выборка из chat script; ogin: b1ff ssword: s3kr3t Он сообщает chat чтобы ждать отает из отдаленной системы для того, чтобы послать login prompt, и вернуть login имя b1ff. Мы только ждем ogin: так чтобы было все равно стартует ли login prompt с верхнего регистра или с нижнего регистра I, или приходит искаженным. Следующяя строка - expect string снова, которая заставит chat ждать пароль, и посылать свой пароль в ответ. - 147 - Вот это в основном и все то, для чего предназначен chat scripts. Полный script для соединения с PPP сервером, несомненно должен включать соотствующие команды модема. Представте, что ваш модем понимает Hayes команды, и номер телефона сервера был 318714. Полный вызов chat для установки связи с c3po был бы: $ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN По определению, первая строка должна бы быть expect строкой, но так как модем не будет говорить что - нибудь прежде, чем мы пнули его, мы сделаем chat так, чтобы он сначала ожидал, опрзделкв пустую строку. Мы продолжаем и посылаем ATZ, reset команда для Hayes-совместимых модемов, и ждем реакцию (OK). Следующая строка посылает dial команду с номером телефона для chat, и ожидает сообщение CONNECT в ответ. За этим следует пустая строка снова, потому что мы не хотим посылать, но лучше подождать для быстрого входа в систему. Остаток от chat script работает точно так, как описано выше. Опция -v делает caht log all activities к syslog daemon's local2 facility. (6) Определение chat script на командной строке несет оправданный риск, потому что пользователи могут просматривать командную строку процессов с использованием ps команды. Вы можете избежать этого, помещая chat script в файл, скажем dial-c3po. Вы можете заставить chat прочесть script из файла вместо командной строки, давая ему опцию -f, сопровождаемой именем файла. Завершением колдовства над pppd теперь выглядело бы следующим образом: # pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \ crtscts modem defaultroute 6. Если Вы редактируете syslog.conf так, чтобы переназначить эти log сообщения к файлу, удостоверитесь, что этот файл не всемирно читаемый, так как chat также регестрирует введенный chat script по умолчанию - включая пароли и все. - 148 - Помимо соединяющейся опции, которая определяет dial-up script, мы добавили еще две опции к командной строке: - detach, которая сообщает рppd не отделяться от консоли и стать процессом предпосылки. Ключевое слово модема заставит его выполнить некоторые модем-определенные действия на последовательном устройстве, подобно "повесить трубку" прежде и после вызова. Если Вы не используете это ключевое слово, pppd не будет определять DCD линию, и будет не обнаруженна неожиданно. Примеры, показанные выше были довольно просты; chct позволяет учитывать намного более комплексные chat script. Одна очень полезная особенность - способность к точному определению строки на которой можно прервать chat с ошибкой. Типичные аварийные строки - BUSY, или NO CARRIER, которые ваш модем обычно генерирует, когда вызываемый номер занят, или не поднимают трубку. Для того, чтобы сделать chat распознающим их немедленно, скорее быстрее чем выйдет время, Вы можете определить начало script, используя ключевое слово ABORT. $ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ... В подобном режиме, Вы можете изменить значение блокировки по времени для частей chat scripts, вставляя TIME OUT опции. Для деталей, пожалуйста обратитесь к chat(8) справочника. Иногда, вы может быть захотели бы иметь некоторый вид условного извлечения частей chat script. Например, когда Вы не получаете отдаленный end'slogin prompt, возможно Вы можете захотеть послать BREAK, или возврат каретки. Вы можете достичь этого, присоединяя sub-script к expect строке. Она состоит из последовательности send- и expect- строк, точно таких же как и полный script непосредственно, который отделен дефисами. Sub-script выполняется всякий раз, когда expected строка когда не было ничего получено. В примере изложенном выше, мы модифицировали бы chat script следующим образом: ogin:-BREAK-ogin: ppp ssword: GaGariN Теперь, когда chat не видит, что отдаленная система посылает - 149 - быстрый вход в систему, sub-script выполняется сначала посылая BREAK, и затем ожидает для входа в систему снова. Если prompt теперь появится, то script будет продолжаться как обычно, иначе это прервется с ошибкой. 9.6 Отладка вашей PPP установки По умолчанию, pppd регестрирует любые предупреждения и сообщения об ошибках к syslog's daemon facility. Вы должны добавить записю " в syslog.conf, которая переназначит его к файлу, или даже к консоли, иначе syslog просто отбросит эти сообщения. Следующая запись посылает все сообщения к /var/log/ppp-log: daemon.* /var/log/ppp-log Если ваша PPP установка не работает, при просмотре этого log файла, то он должен дать Вам подсказку, что что-то идет неправильно. Если это не помогает, то Вы можете включить особо отлаживающийся вывод, используя опцию отладки. Это делает pppd log с содержанием из всех управляющих блоков, посланных или полученных к syslog. Все сообщения будут идти к daemon facility. В заключение, наиболее решительная особенность - отключение kernel-level отладки, вызывая pppd с опцией kdebug. Она сопровождается числовым аргументом, который является поразрядным ИЛИ следующих значений: 1 для общих сообщении отладки, 2 для печати содержания всей входящей HDLC структуры, и 4 для того, чтобы сделать драйвер принтера выходящим на HDLC структуру. Для того, чтобы захватить kernel отлаживающее сообщения, Вы должны также запустить syslogd daemon, кот или klogd daemon. Каждый из них направляет kernel отладку к syslog's kernel facility. 9.7 IP опции конфигурации IРCP используется для того, чтобы обговорить пару IP параметров в конфигурационной связи. Обычно, каждый peer может посылать IPCP запрос конфигурации, указывая, которая переменная хочет - 150 - измениться из значений заданных по умолчанию, и к какому значению. После получения, отдаленный end осматривает каждую опцию, и подтверждает или отклоняет ее. Pppd дает Вам множество управления, относительно IPCP опций, которые будут пытаться вести переговоры. Вы можете настроить ее через различные опции командных строк, которые мы обсудим ниже. 9.7.1 Выбор IP адресов В примере выше, у нау был pppd, связывающейся с c3po и устанавливающий IP связь. Никакие условия не принимались для того, чтобы выбрать частный адрес IP на любом конце связи. Взамен, мы выбрали адрес vlager's как локальный адрес IP, и позволяем c3po обеспечить себя собственным. Иногда это полезно иметь контроль над тем , какой адрес используется на одном или на другом конец связи. Pppd поддерживает отдельные разновидности этого. Чтобы просить о частных адресах, Вы вообще обеспечиваете pppd следующеми опциями: local addr:remote addr Где local addr и remote addr могут быть определены или в dotted quad notation, или как hostnames.(7) Это заставит pppd попытаться использовать первый адрес как собственный адрес IP, и второй как peer. Если peer отклоняет любой из них в течение IPCP переговоров, никакая связь IP не будет установленна. (8) Если Вы хотите установить локальный адрес, но принимаете любой адрес, который использует peer, Вы просто не учитываете remote addr part. Например, для того, чтобы vlager использовал IP адрес 130.83.4.27 вместо собственного, Вы бы дали ему 130.83.4.27: на командной строке. Подобно установки remote адресов только, Вы покинули бы локальную область адреса. - 151 - Используя значение по умолчанию, pppd затем использует адрес, связанный с вашим hostname. Некоторые PPP серверы, которые обрабатывают множество клиентов, приписывают адреса динамически: адреса назначены системам только когда существует обращение и требуются после того, как они прекратили регистрироваться снова. Когда происходит соединение с таким сервером, Вы должны удостовериться, что pppd не запрашивает какой- либо IP адрес из сервера, но когда адрес будет принят сервер попросит Вас, чтобы Вы его использовали. Это означает то, что Вы не должны определить того, Вы должны использовать опцию noipdefault, которая заставит pppd ждатю pegr, чтобы обеспечить адрес IP вместо использования адреса локального хоста. 7. Использование hostnames в этой опции имеет следствия на CHAP установления подлинности. Пожалуйста обратитесь к разделу на CHAP. 8. Вы можете позволить peer PPP отменить ваши идеи относительно IP адресов, давая pppd ipcp-accept-local и ipcp-accept-remote опции. Пожалуйста обратитесь к руководству для выяснения деталей. 9.7.2 Направление через связь PPP После установки сетевого interface, pppd будет устанавливать хост маршрут только к своему peer. Если remote хост находится на LAN, Вы обязательно захотите быть способным соединится с хостами множествами "позади" Вашего peer; то есть сетевой маршрут должен быть установлен. Мы уже видели, что pppd можно попросить уствновить заданный по умолчанию маршрут, используяю опцию defaultroute. Эта опция очень полезна если PPP сервер, с которым Вы связались будет действовать как ваши Internet ворота. Обратный случай, где ваша система действует как ворота для единственного хоста, является также относительно простым для того, чтобы быть выполненым. Например, возьмите некоторых служащих в Virtual Brewery, чья локальная машина называется loner. При соединении с vlager - 152 - через PPP, он использует адрес на подсети Brewery. В vlager, мы можем теперь дать pppd опцию proxyarp, которая установит полномочную ARP запись для loner. Это автоматически сделает loner доступным для всех и в Winery. Однако, вещи далеко не всегда просты как это иногда кажется, например когда Вы соединяете две LAN. Это обычно требует добавления специального сетевого маршрута, потому что эти сети могут иметь свой маршрут заданный по умолчанию. Кроме того, имея обоих peer использование связи PPP как маршрут заданный по умолчанию генерировало бы цикл, где блоки к некзвеутным адресатам будут пинаться между peer пока их time-to-live истечет. Как пример, предположите, что Virtual Brewery открывает ветвь в каком-нибудь другом городе. Подразделение запускает собственную Ethernet используя IP сетевой номер 191.72.3.0, который является подсетью 3 из Brewery класса B сети. Они хотят соединиться с Brewery's main Ethernet via PPP для тго, чтобы модифицировать базы данных заказчиков, и т.д. Снова, vlager действует как ворота; peer вызывается sub-etha и имеет адрес IP 191.72.3.1.. Когда sub-etha соединится с vlager, она примет заданный по умолчанию маршрут к vlager как обычный. На vlager, мы будем должны установить сетевой маршрут для подсети 3, который проходит к sub-etha. Для этого, мы используем особенность pppd, не обсужденного пока - ip-в готовности команды. Это shell script или программа, размещенная в /etc/ppp, которая выполнена после того, как PPP interface был сконфигурирован. Когда он существует, это вызывается со следующими пар ip-up iface device speed local addr remote addr Где iface называет сетевой interface используемым, device - тропа файла последовательного устройства используемого (/dev/tty, если stdin/stdout используется), и speed - быстродействие устройства. Local addr и remote addr дают IP адреса, используемые в обоих концах связи в dotted quad notation. В нашем случае, ip-up script, может содержать - 153 - следующий кодовый фрагмент: #!/bin/sh case $5 in 191.72.3.1) # this is sub-etha route add -net 191.72.3.0 gw 191.72.3.1;; esac exit 0 В подобном режиме, /etc/ppp/ip-down используется для того, чтобы отменить все действия ip-up после того, как связь PPP была демонтирована снова. Однако, схемж матшрутов еще не полна. Мы установили маршрут входов таблицы на оба PPP хоста, но пока, все другие хосты на обих сетях не знают ничего относительно связи PPP. Это не большая проблема, если все хосты в подразделении имеют свои, заданные по умолчанию маршруты в sub- etha, и все хосты в Brewery направляются к vlager по умолчанию. Если это не так, то ваша единственная опция будет использовать daemon маршрут подобно воротам. После создания сетевого маршрута передал бы по радио новый маршрут ко всем хостам на присоединенной подсети. 9.8 Опции управления связью Выше, мы уже столкнулись с LCP, Протоколом Управления Связи, который используется для того, чтобы заключить характеристики связи, и проверить связь. Две наиболее важных опции, которые могут быть заключены LCP - максимум получает единицу и Асинхронное Отображение Управляющего символа. Имеется ряд других LCP опций конфигурации, но они слишком специализированны для обсуждения их здесь. Пожалуйста обратитесь к RFC 1548 для описания этого. Асинхронное отображение управляющего символа, разговорно называемого async отображение, используется на асинхронных связях типа - 154 - телефонных линий для опознавания управляющих символов, которых нужно найти (заменить специфической последовательностью с двумя характерами). Например, Вы может быть захотите избежать XON и XOFF, используемые для рукопожатия программного обеспечения, потому что некоторый плохо сконфигурированный модем мог бы удушить получения стоп- сигнала. Ctrl-] (telnet символ ESC). PPP позволяет Вам выходить из любого из знака с ASCII кодировкой от 0 до 31, точно определяя их в аsync отображении. Async отображение - растр шириной 32 бита, с самым младшим битом, соответствующим ASCII NUL знаку, и старшим битом соответствующим 31 ASCII. Если бит установлен, то оп сообщает соответствующему знаку, который должен выйти перед посылкой через связь. Первоначально, async отображение - множество к 0xffffffff, то есть все управляющие символы будут esaped. Для того, чтобы сообщить вашему peer, что это он не должен escaped все управляющие символы, а только несколько из них, Вы можете точно определять новый asyncmap к pppd используя опцию asyncmap. Например, если только ^S и ^Q (ASCII 17 и 19, обычно используемый для старт-сигнала(XON) и стоп-сигнала(XOFF)) должно быть escaped, то Вам надо использовать следующую опцию: Asyncmap 0x000A0000 Максимум получает единицу, или MRU, сообщает peer максимальный размер HDLC рамки, которую мы хотим получить. Хотя это может напомнить Вам значение MTU (Максимальная Порция обмена), то эти два имеет немного общего. MTU - параметр kernel устройства работы с сетями, и описывает максимальную структуру inerface делая его способным к обработке. MRU более, чем совета к remote end для того, чтобы не генерировать любой фрейм больший чем MRU; interface должен однако быть способен 1500 байт. Выбор MRU не такой большой вопрос того что как связь способна к пересылке, но того, что даст Вам самый лучший throughput. Если Вы имеете в виду интерактивные приложения над связью, то установки MRU к значениям всего 296 - хорошая идея, так, чтобы случайный больший блок (говорят, из FTP сеанса) не сделал бы ваш курсор "jump''. Чтобы сообщить - 155 - pppd чтобы он запросил MRU 296, Вы бы дали ему опцию mru 296. Малый MRUs, однако, только имеет смысл, если Вы не имеете эту опцию (это отключается по умолчанию). Pppd понимает также пару LCP опций, которые конфигурируют полное поведение процесса переговоров, типа максимального номера из запросов конфигурации, которые могут быть обменены перед тем как связь будет прервана. & " В заключение, имеются две опции, которые обращаются к LCP ECHO сообщениям. PPP определяет эти два сообщения, запрос ECHO и ответ ECHO. Pppd использует эту особенность, чтобы проверить, действует ли связь все еще. Вы можете отключить это используя опцию lcp-echo-interval вместе со временем мгновенно. Если никакие структуры не получены от отдаленного хоста внутри этого интервала, то pppd сгенерирует запрос ECHO, и будет ожидает, какой ECHO ответ peer возвратит. Если peer не возвращает ответ, то связь будет прервана после некоторого числа посланных запросов. Этот номер может быть установлен используя опцию lcp-echo-failure. По умолчанию, эта особенность отключена в целом. 9.9 Общие рассмотрения защиты Плохо сконфигурированный PPP daemon может быть разрушителен для защиты. Это может быть так плохо, как разрешение подсоединиться любому человеку со своего компьютера в Вашу Ethernet (и это очень плохо). В этом разделе, мы обсудим несколько критериев, которые должны сделать вашу PPP конфигурацию безопасной. Одна проблема с pppd - то, что конфигурация сетевого устройства и таблицы маршрутов требуют привилегии root. Вы будете обычно разрешать эту сложность, выполняя setuid root. Однако, pppd позволяет пользователям установить различные защита-релевантные опции. Для защиты против любого нападения, пользователь может манипулировать этими опциями, Вам предложат установить пару значений по умолчанию в глобальном файле /etc/ppp/options, подобно тем показанным в типов 9.4. Некоторые из них, типа опознавательных опций, не могут быть - 156 - отменены пользователем, и так что они обеспечивают приемлемую защиту против манипулирований. Конечно, Вы должны защитить себя от систем, с которыми PPP также общается. Чтобы отразить хосты, Вы должны всегда иметь некоторый вид установления подлинности от вашего peer. Дополнительно, Вы не должпы позволять иностранным хостам использовать любой адрес IP какой они выберут, но ограничьте их по крайней мере несколькими. Следующий раздел будет связам с этими проблемами. 9.10 Установление подлинности с PPP .10.1 CHAP против PAP С PPP, каждая система может требовать, чтобы peer опознал себя используя однин из двух опознавательных протоколов. Они - (PAP), и (CHAP). Когда связь установлена, каждый может запросить другой, чтобы опознать себя, независимо от того, является ли это caller или callee. Ниже я буду говорить о "клиенте " и " сервере " когда я захочу сделать различие между системой опознания и authenticator. PPP daemon может спрашивать peer отно подлинности, посылая однако другой LCP запрос конфигурации, опознавающий желаемый протокол. PAP в основном работает в том же самом способ как нормальная процедура входа в систему. Клиент опознает себя, посылая имя пользователя и пароль ксерверу, который сравнивается с базой данных секретов. Этот метод легкоуязвим к eavesdroppers, который может попытаться получить пароль, слушая последовательную линию, и к повторению испытания и решения ошибки. CHAP не имеет этих недостатков. С CHAP, authenticator (то есть сервер) посылает беспорядочно сгенерированную " challenge'' строку к клиенту, наряду с hostname. Клиент использует hostname для того, чтобы искать соответствующий шифр, объединяя это с challenge, и шифруя строку, используя однонаправленную hashing function. Результат будет возвращен на сервер наряду с hostname клиента. Сервер теперь выполняет то же самое вычисление, и подтверждает клиента. - 157 - Другая особенность CHAP - то, что он не требуется опознания клиента для опознания самого себя при запуске, но посылает challenges в определенные промежутки времени, чтобы удостовериться не был клиент заменен "злоумяшлепником ", например, только переключая телефонные линии. Pppd хранит секретные ключи для CHAP и PAP в двух отдельных файлах, вназываемых /etc/ppp/chap-secrets и pap-secrets соответственно. Входом отдаленного хоста в один или другой файл, Вы имеете хороший контроль над CHAP или PAP предназначенный для этого, чтобы опознать нас с нашим peer, и наоборот. По умолчанию, pppd не требует установления подлинности от remote, но соглашается опознавать себя когда запрошено remote. Так как CHAP намного более сильна чем PAP, pppd пробует использовать вышеупомянутый всякий раз, когда это возможно. Если peer этого не поддерживает, или если pppd не может найти CHAP шифр для remote системы в файле шифров chap, он возвращается к PAP. Если он имеет PAP шифр для peer также, то он откажется опознавать в целом, и как следствие, связь закроется. Это поведение может быть изменено отдельными способами. Например, когда дается auth ключевое слово, pppd требует, чтобы peer опознал сам себя. Pppd согласится использовать или CHAP или PAP для этого, как только это будет имеет шифр для peer в CHAP или в базе данных PAP соответственно. Имеются другие опции, чтобы включить или выключить частный опознавательный протокол, но я не буду описывать их здесь. Пожалуйста обратитесь к pppd (8) для деталей. Если все системы, с которыми Вы говорите PPP, соглашаются опознавать самих себя с Вами, Вы должны поместить опцию auth в глобальный файл /etc/ppp/options и определить пароли для каждой системы в файле шифров chap. Если система не поддерживает CHAP, добавьте запись к файлу pap шифров. Таким образом, Вы можете удостовериться в том, что никакая неопознанная система не соединяется с Вашим хостом. - 158 - Следующие два раздела обсуждают два PPP файла шифров, pap- secrets и chap-secrets. Они размещзны "в /etc/ppp и содержат тройки клиентуры, серверов и паролей, необязательно сопровождаемых списком из адресов IP. Интерпретация клиента и областей сервера отлична для CHAP или PAP, и также зависит от того, опознаем ли мы себя самостоятельно с peer, или потребуем опознать сервер непосредственно с нами. 9.10.2 Файл шифров CHAP Когда это должно опознать себя с некоторым сервером, используя CHAP, рppd ищет файл шифров PAP для записи с клиентской областью равной локальному hostname, и области сервера равной к remote hostname посланный в CHAP Challenge. При требовании peer к опознаванию себя, роли просто поменялись: pppd будет затем искать запись с клиентской областью приравненной к отдаленному hostname (посланный в CHAP ответ клиенту) и область сервера приравненной локальному хосту. Следующее - типовой файл шифров chap для vlager: (9) # CHAP secrets for vlager.vbrew.com # # client server secret addrs #------------------------------------------------------------------- --- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas.com * vlager.vbrew.com "VeryStupidPassword" pub.vbrew.com При установлении PPP связи с c3po, c3po запрашивает vlager опознать себя, используя CHAP, посылая CHAP challenge. Pppd затем просматривает chap шифры для записи с клиентской областью, приравненой к vlager.vbrew.com и областью сервера приравненной к c3po.lucas.com, (10) и находит - 159 - первую линию, показанную выше. Затем производится CHAP ответ от challenge string и шифра (Используйте Источник Luke), и посылает от c3po. В то же самое время, pppd составляет CHAP challenge для c3po, содержащую уникальную challenge string, и пплноутью квалифицированный hostname vlager.vbrew.com. C3po создает CHAP ответ способом, который мы только что обсудили, и возвращает это к vlager. Pppd теперь извлекает клиентский hostname (c3po.vbrew.com) из ответа, и поисков файлов шифра chap для линии, соответствующей c3po как клиент, и vlager как сервер. Вторая линия делает так что pppd объединяет CHAP challe pasteve, шифрует их, и сравнивает результат с с3po CHAР ответа. Произвольная четвертая область перечисляет адреса IP, которые являются для клиентуры, именованной в первой области. Адреса могут быть даны в dotted quad notation или как hostnames, которые разысксканы с помощью решающего устройства. Например, если запрос c3po, на использование IP адреса во время IPCP переговора, который не в этом списке, запрос будет отклонен, и IPCP будет выключено. В типовойфайле, показанном выше, с3po следовательно будет ограничен использованием собств Если область адреса пуста, любые адреса будут позволяться, значение которых - предотвращает использование IP с клиентом. Третья линия в примере файле шифров chap позволяет любому хосту установить связь PPP с vlager потому что клиент или область сервера соответствует hostname. Единственое требование - то, что он знает пароль, и использует адрес pub.vbrew.com. Вход с групповым символом hostnames может появится где-нибудь в файле шифров, так как pppd будет всегда использовать наиболее специфическую запись, которая применяется к паре сервера / клиента. 9. Двойные кавычки - не часть пароля, они просто служат для того, чтобы защитить незаполненное пространство внутри пароля. 10. Этот hostname принимается из CHAP challenge. Имеются некоторые слова, которые нужно упоминуть относительно способа, которым pppd достигает hostnames: он ищет в файле шифров. - 160 - Как было объяснено прежде, отдаленный hostncme всегда обеспечивается peer в CHAP Challenge или в Response packet. Локальный hostname будет получен, если вызвать gethostname функцию (2) по умолчанию. Если Вы установили название системы Вашему неквалифицированному hostname, то Вы должны обеспечить его pppd областью. # pppd ...domain vbrew.com Это конкатенирует название Brewery области к vlager для всех установленых подлинностью действия. Другие опции, которые модифицируют progpppd's idea относительно локального hostname - usehostname и name. Когда Вы даете локальный IP адрес на командной строке, использующей "local:varremote", и local - название вместо dotted quad, pppd использует это как локальный hostname. Для деталей, пожалуйста обратитеськ pppd странице справочника (8). 9.10.3 Файл шифров PAP. Файл шифров PAP очень похожа на тот, который используется CHAP. Сначала две области всегда содержат название пользователя и название сервера; третья часть задерживает шифр PAP. Когда remote посылает опознающийся запрос, рppd использует запись, которая имеет область сервера равной локальному hostname, и область пользователя приравненной к имени пользователя, посланному в запросе. Когда опознание себя с peer произойдет, pppd выберет шифр, который будет послан из линии с область приравненной к локальному имени пользователя, и областью сервера приравненной к remote hostname. Типовой файл шифров PAP мог бы выглядить следующим образом: # /etc/ppp/pap-secrets # # user server secret addrs vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com Первая линия используется для того, чтобы опознать нас когда мы говорим с с3ро. - 161 - Вторая линия описывает, как пользователь именнованняй c3po, должен быть опознаным непосредственно с нами. Имя vlager-pap в столбце, который является именем пользователя, мы посылаем к c3po. По умолчанию, pppd выберет локальный hostname как имя пользователя, но Вы можете также определить различные названия, давая опцию пользователя, сопровождаемую эти именем. При выборе записи из файла шифров PAP регистрируются для установления подлинности с peer, pppd должен знать название remote хоста. Поскольку это не имеет способа нахождения того, что Вы должны точно определить на этой командной строке, используяе remotename ключевого слова, сопровождаемого hostname peer. Для образца, как использовать вышеупомянутую запись для установления подлинности с c3po, мы добавляем опцию следования к командной строке pppd's: \#{} pppd ... remotename c3po user vlager-pap В четвертой области (и все следующие области), Вы можете точно определить какие адреса IP разрешены для того частного множества, точно как и в файле шифров CHAP. Peer может затем только запроситьь адреса из этого списка. В типовом файле, мы требуем, чтобы c3po использовал реальный адрес IP. Заметьте, что PAP довольно слабый опознавательный метод, и это предполагает всякий раз, когда Вы используете CHAP, если это возможно. Мы не будем следовательно описывать PAP в деталях здесь; если Вы заинтересованы в использовании PAP, Вы найдете несколько больше в pppd странице справочника (8). 9.11 Конфигурирование PPP сервера При запуске pppd, поскольку сервер - только сущность добавления соответствующей опции к командной строке. Было бы идеальным, если Вы создали бы специальный account, скажем ppp, и - 162 - дадите этому script или программе как оболочке входа в систему, которая вызывает pppd с этими опциями. Например, Вы бы добавили следующую линия к /etc/passwd: " ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin Конечно, Вы можете захотеть использовать более универсальные uids и gids чем те, что показанны выше. Вы также были бы должны установить пароль для вышеупомянутого account, использующего команду passwd. Ppplogin script может быть выглядить следующим образом: #!/bin/sh # ppplogin - script to fire up pppd on login mesg n stty -echo exec pppd -detach silent modem crtscts Команда mesg блокирует других пользователей, чтобы записать к tty, используя, на пример, команду записи. Команда stty выключает знако-отображение на экране. Это необходимо, потому что иначе peer все посылал бы используя отображение на экране. Наиболее важная опция pppd, данная выше -detach, потому что это предотвращает pppd от отсоединения из управления tty. Если мы не точно определим эту опцию, это будет идти к предпосылке, создания shell script exit. Это было к зависанию. Silent опция заставляет pppd ждать, пока он не получит блок от системы вызова прежде, чем это начинает посылать. Это предотвращает от блокировки по времени, когда система вызова медлена в обслуживании PPP наблюдать DTR линию, чтобы видеть, понизил ли peer связь, и crtscts включает аппаратное рукопожатие. Помимо этих опций, Вы могли бы захотеть вынудить некоторый вид опознания, например, точно определяя auth на командной строке pppd's, или в глобальном файле опций. Руководство также обсуждает более специфические опции для вкл. или выкл. индивидуальных опознавательных протоколов. - 163 - 10. Различные сетевые приложения После успешной установки IP и решающего устройства, Вы должны обратиться к услугам обеспечивающим хорошую работу над сетью. Глава начинается с конфигурачия пескольких простых сетевых приложений, включая Inetd сервер, и программы из rlogin совокупности. Незначительная процедура обращения связывает, с помощью интерфейса, эти услуги подобно Сетевой Файловой системе (NFS). Сетевая Информационная Система (NIS) основана на том же самом, имела дело с briefly. Конфигурация NFS и NIS, однако берущяя большое количество памяти, будет описана в отдельных главах. Это применяется к электронной почте и netnews также. Конечно, мы не можем описать все сетевые приложения в этой книге. Если Вы хотите устанавить то, которое не обсуждается здесь, подобно переговорам, gopher, или xmosaic пожалуйста обратитесь к руководству для деталей. 10.1 Inetd супер-сервер Часто, услуги предоставляются так называемыми daemons. Daemon является программой, которая открывает некоторый порт, и связь. Если это происходит, это создает дочерний процесс, который принимает связь, в то время как основной продолжает ждать дальнейших запросов. Это понятие имеет недостаток что для каждого предлагаемого обслуживания, daemon должен запускать те, которые слушают порте для связи, для которых это вообще означает потери способов системы подобно пространст Таким образом, почти вся Un*x инсталляция запускает " супер- сервер ", который создает гнезда для ряда услуг, и слушает на них одновременно при использовании отобранного системного вызова (2). Когда отдаленный хост запрашивает одну из услуг, супер-сервер замечает этот и порождает другой сервер, точно установленный для этого порта. Супер-сервер, обычно используемый - inetd, Internet Daemon. Это начинается при начальной загрузке системы, и берет список услуг, к - 164 - которым он обращается из файла запуска, именованной /etc/inetd.conf. В дополнение к тем вызываемым серверам, там есть ряд тривиальных услуг, которые являются на сформировавшимся inetd, неппсрежственно вызываемым внутренние услуги. Они включают chargen который просто генерирует ряд знаков, и daytime который возвращают system's idea Запись в этой картотеке состоит из единственной линии, сделанной из следующей области: service type protocol wait user server cmdline Значение каждой области следующие: Service дает сервисное имя. Service name должно быть переведено к номеру порта, просматривая в файле services. Этот файл будет описан в разделе 10.3. type определяет тип гнезда, любой поток (для связь- ориентируемых протоколов) или dgram (для датаграмных протоколов). TCP основанна на услугах, которые должны всегда использовать поток, в то время как UDP-основанные услуги должны всегда использовать dgram. Protocol называется протоколом переноса, используемым обслуживанием. Это должно быть подходящим названием протокола, найденное в файле протоколов, также объяснено ниже. wait эта опция применяется только на dgram гнездах. Это может быть также wait или nowait. Если wait определен, то inetd только выполнит один сервер для точно установленного порта в любое время. Иначе, это немедленно продолжит слушать на порте после извлечения сервера. Это полезно для "единственно - связнных " серверов, которые читают все входящие датаграммы, и затем выходят. Большинство RPC серверов имеет этот тип и должны следовательно точно определить wait. Противоположный тип, "многопоточные " серверы, позв