Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

182 Глава 6. Настройка интерфейса

• Символ SLIP ESC, отдельный байт с десятичным значением 219. Исполь-

зуется для «маскировки» управляющих символов SLIP. Если источник

SLIP-передачи встречает в передаваемой дейтаграмме байт со значением,

эквивалентным символу SLIP END или SLIP ESC, такой байт преобразу-

ется в последовательность двух символов. Двухсимвольные последова-

тельности: ESC 220 для символа END и ESC 221 для самого символа ESC.

Адресат SLIP-передачи, встретив такую двухбайтовую последователь-

ность, преобразует ее в однобайтовое значение. Описанный механизм

предотвращает интерпретацию байта данных в качестве маркера конца

дейтаграммы SLIP-адресатом.

Протокол SLIP описан в документе RFC 1055, A Nonstandard for Transmissi-

on of IP Datagrams Over Serial Lines: SLIP (Нестандартная передача дейта-

грамм IP через последовательные линии: SLIP). Как видно из названия RFC,

SLIP не является стандартом Интернета. RFC не предлагает стандартизацию,

лишь документирует существующий протокол. В документе RFC 1055 описа-

ны недостатки протокола SLIP, разделенные на две категории:

• Протокол SLIP не содержит средств динамического управления характе-

ристиками соединения. Следовательно, системы SLIP неявно предпола-

гают наличие определенных характеристик канала. Вследствие этого ог-

раничения SLIP может применяться только для передачи дейтаграмм IP

и только в случае, когда каждой из сторон известен не только свой адрес,

но и адрес второй стороны.

• SLIP не позволяет компенсировать зашумленность или низкую скорость

телефонных линий. В протоколе отсутствуют возможности коррекции

ошибок и сжатия данных.

Протокол РРР (Point-to-Point Protocol), разработанный в качестве стандар-

та Интернета, призван восполнить недостатки протокола SLIP. Протокол

РРР регламентируется рядом документов RFC.

Два ключевых документа:

RFC 1661, The Point-to-Point Protocol (РРР) и RFC 1172, The Point-to-Point

Protocol (PPP) Initial Configuration Options.

РРР восполняет недостатки SLIP при помощи трехуровневого протокола:

Протокол канального уровня (Data Link Layer Protocol)

Протокол канального уровня, применяемый в РРР, является немного мо-

дифицированной версией протокола HDLC (Highlevel Data Link Control).

РРР добавляет в HDLC поле Protocol, позволяющее РРР адресовать тра-

фик различным протоколам сетевого уровня. HDLC - это международ-

ный стандартизированный протокол, позволяющий надежно передавать

данные по синхронным, последовательным линиям. Кроме того, в РРР

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

HDLC-передачи по асинхронным линиям, так что РРР гарантирует на-

дежность доставки по последовательной линии любого типа.

В данном случае ESC обозначает управляющий символ SLIP, а не ASCII.

Чтобы наверняка иметь дело с наиболее актуальной версией стандарта, обрати-

тесь к перечню документов RFC, описанных в приложении G.

Установка РРР

183

Протокол управления каналом (Link Control Protocol)

Протокол управления каналом LCP (Link Control Protocol) обеспечивает

обмен управляющей информацией для последовательных каналов. LCP

используется для организации соединения, согласования параметров на-

стройки, проверки качества связи и завершения соединения. LCP разра-

батывался специально для РРР.

Протоколы управления сетью (Network Control protocols )

Протоколы управления сетью - это отдельные протоколы, передающие

данные настройки и управляющую информацию протоколам сетевого

уровня. Вспомните, что РРР спроектирован таким образом, чтобы пере-

давать данные широкому спектру сетевых протоколов. NCP позволяет ре-

гулировать работу РРР в этой области. Каждому из сетевых протоколов

(DECNET, IP, OSI и т. д.) соответствует протокол сетевого управления.

Документами RFC 1661 и RFC 1332 определен протокол управления про-

токолом Internet (IPCP, Internet Protocol Control Protocol), позволяющий

работать с протоколом Internet.

Протокол РРР - лучший протокол TCP/IP для последовательных соедине-

ний. Дело в том, что протокол РРР является стандартом Интернета, что га-

рантирует корректный обмен данными для самых разнообразных систем.

РРР имеет больше возможностей, чем SLIP, и является более устойчивым.

Эти преимущества делают РРР оптимальным выбором открытого протокола

для связи маршрутизаторов по последовательным линиям и подключения

удаленных компьютеров по коммутируемым каналам.

Отдельные системы Linux включают как РРР, так и SLIP. Однако в боль-

шинстве систем Unix, таких как Solaris, присутствует РРР, а не SLIP. Ниче-

го плохого в этом нет, поскольку следует избегать применения SLIP в пользу

РРР.

Установка РРР

Процедура установки и настройки РРР зависит от конкретной реализации.

В этом разделе мы используем реализацию демона РРР (pppd), поставляемую

в составе систем Linux, и рассмотрим сопутствующие команды настройки.

РРР является стандартом Интернета, и в стандартных ядрах большинства

систем Unix по умолчанию присутствует поддержка этого протокола. Обыч-

но для его установки не требуется дополнительных действий. Настройка

РРР в ядре Linux описана в главе 5. В системе Linux программные модули

физического и канального уровня (HDLC) РРР интегрированы в ядро.

Установка РРР в ядре - лишь начало. В этом разделе мы рассмотрим приме-

нение демона pppd для развертывания РРР-служб в системе Linux.

Сверьтесь с документацией на вашу систему, чтобы точно знать, как следует на-

страивать РРР.

184

Глава б. Настройка интерфейса

Демон РРР

Протокол РРР реализован в системе Linux в виде демона РРР

(pppd),

создан-

ного на основе бесплатной реализации РРР для систем BSD. pppd может рабо-

тать во всех режимах: в качестве клиента, в качестве сервера, по коммутиру-

емым и выделенным каналам. (Понятия клиента и сервера должны быть

знакомы читателям из главы 3.) Выделенный канал - это прямое кабельное

подключение (или выделенная линия), не требующее наличия телефона для

создания соединения. Коммутируемое соединение - это модемный канал,

создаваемый набором телефонного номера.

Простейший вариант настройки pppd связан с выделенными линиями. Выде-

ленная линия или прямое подключение не требует создания сценария дозво-

на. Нет смысла динамически назначать адреса, поскольку выделенная ли-

ния всегда соединяет две конкретные системы. Проверка подлинности не

особо востребована, поскольку выделенная линия физически соединяет две

точки. Злоумышленник не может получить доступа к каналу, не считая ва-

риантов «взлома и проникновения» или электронного прослушивания.

В системе Linux настройка выделенного РРР-канала выполняется единст-

венной командой в загрузочном сценарии:

pppd /dev/сиаЗ 56000 crtscts default route

Аргумент /dev/сиаЗ указывает устройство, с которым работает РРР. Разуме-

ется, это именно тот порт, который подключен к выделенной линии. Ско-

рость линии определяется в битах за секунду (56000). Оставшаяся часть

строки команды содержит последовательность ключевых слов параметров.

Параметр crtscts включает аппаратный контроль передачи. Последний па-

раметр, default route, создает маршрут по умолчанию через удаленный сер-

вер, используя его в качестве шлюза.

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

ния. Если в командной строке pppd адрес не указан, демон передает второй

стороне адрес локального узла, извлеченный из таблицы узлов или получен-

ный посредством службы DNS. Аналогичным образом удаленная система

передает свой адрес локальному узлу. Эти адреса используются в качестве

исходного и конечного адресов канала. Адреса могут быть указаны в ко-

мандной строке в формате «локальный:удаленный». Пример:

pppd /dev/сиаЗ 56000 crtscts defaultroute 172.16.24.1:

Здесь указан локальный адрес 172.16.24.1 и пустой адрес второй стороны.

В этом случае pppd передает адрес, указанный в командной строке, и ожида-

ет, что удаленный сервер пришлет свой адрес. Локальный адрес указывает-

ся в командной строке, если он отличается от адреса, связанного с именем

локального узла в таблице узлов либо на сервере DNS. Например, система

может использовать интерфейс Ethernet, которому уже назначен адрес. Что-

Если маршрут по умолчанию уже существует в таблице маршрутизации, пара-

метр defaultroute игнорируется.

Установка РРР

185

бы воспользоваться другим адресом для соединения РРР, мы должны ука-

зать его в командной строке pppd; в противном случае каналу РРР будет наз-

начен существующий адрес интерфейса Ethernet.

Команда pppd предоставляет гораздо больше параметров, чем мы увидим в

примерах этой главы (полный перечень параметров содержится в приложе-

нии А). В действительности параметров командной строки pppd существует

столько, что иногда проще сохранить их в файле, чем набирать в командной

строке, pppd читает параметры прежде всего из файла /etc/ррр/options, затем

из файла -/.ррргс, затем из файла /etc/ррр/options.device (где device - имя

устройства, скажем, сиаЗ) и, наконец, из командной строки. Порядок обра-

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

строки имеют более высокий приоритет, чем параметры файла -/.ррргс. Па-

раметры файла -/.ррргс, в свою очередь, имеют приоритет более высокий,

чем параметры файла /etc/ррр/options. Такая система позволяет системному

администратору задать общесистемные умолчания параметров в файле /etc/

ppp/options, но оставить пользователям возможность дополнительно настра-

ивать РРР. Файл /etc/ррр/options является удобным и гибким способом пе-

редачи параметров демону pppd.

Единственная команда pppd позволяет настроить РРР для работы по выде-

ленному каналу. Коммутируемые соединения требуют больших усилий.

Коммутируемые соединения РРР

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

ретение третьей системы ставит нас перед вопросом - как подключить ее к се-

ти? Именно по этой причине чаще всего применяются расширяемые техноло-

гии, в частности Ethernet, для объединения систем в локальную сеть. Кроме

того, выделенные линии дороги. Они используются в основном крупными ор-

ганизациями для объединения сетей. Таким образом, РРР чаще применяется

для создания коммутируемых соединений, нежели выделенных каналов.

Поддержка коммутируемых соединений РРР осуществляется рядом вспомо-

гательных программ. Dial-up IP (dip) - распространенный пакет, упрощаю-

щий процесс дозвона до удаленного сервера, регистрацию на нем и передачу

соединения под контроль РРР. В этом разделе мы опишем dip, поскольку па-

кет является популярным и бесплатно доступен для широкого спектра сис-

тем Unix, ну и, кроме того, поставляется в составе системы Red Hat Linux,

которую мы используем для создания примеров применения РРР.

Одной из наиболее важных возможностей dip является автоматизация про-

цесса создания действующего РРР-канала при помощи языка сценариев.

В приложении А рассмотрены все команды языка сценариев, существую-

щие в dip версии 3.3.7o-uri, поставляемой в составе Red Hat. Чтобы полу-

чить перечень существующих команд, запустите dip в режиме тестирования

(ключ

-t)

и наберите команду help:

186

Глава 6. Настройка интерфейса

Команда get в начале сценария позволяет РРР автоматически определить

локальный и удаленный адреса. Slocal - это переменная сценария. Сущест-

вует несколько стандартных переменных для сценариев, все они описаны в

приложении А. $1оса1 обычно хранит локальный адрес, который может ста-

Перечисленные команды позволяют настраивать интерфейс, контролиро-

вать выполнение сценария и обрабатывать ошибки. Простейшие сценарии

требуют использования достаточно ограниченного подмножества команд:

Установка РРР 187

тически определяться в сценарии. Однако сервер РРР обладает способнос-

тью динамически назначить адрес локальной системе. Этим обстоятельст-

вом мы и пользуемся, указав локальный адрес, состоящий из одних нулей.

Данная команда предписывает dip разрешить pppd самостоятельно опреде-

лить адреса. Клиент pppd может получить адреса тремя путями:

• Системы РРР могут обмениваться локальными адресами, извлеченными

при помощи DNS. Такой вариант мы уже обсуждали в разговоре о на-

стройке выделенных линий.

• Адреса могут указываться в командной строке pppd - и этот вариант мы

также изучили.

• Клиент может разрешить серверу назначить оба адреса. Эта возможность

часто используется при работе с коммутируемыми линиями. Она весьма

востребована серверами, работающими с многочисленными непродолжи-

тельными соединениями. Хорошим примером является сервер поставщи-

ка услуг Интернета, предоставляющий коммутируемый доступ.

Следующие две строки сценария указывают физическое устройство, с кото-

рым связан модем, и устанавливают скорость его работы. Команда port под-

разумевает путь /dev, поэтому в качестве аргумента указано только само

имя устройства. В большинстве систем PC Unix аргумент команды port при-

нимает одно из значений: cuaO, cual, сиа2 и сиаЗ. Эти значения соответству-

ют портам системы MS-DOS - от СОМ1 до COM4. Команда speed определяет

максимальную скорость передачи данных модему через указанный порт.

Скорость по умолчанию - 38400. Измените аргумент, если модем принимает

данные с иной скоростью.

Команда reset выполняет аппаратную инициализацию, передавая модему

Науев-команду прерывания (+++) и Науев-команду сброса (ATZ). Данный ва-

риант dip использует АТ-команды системы Hayes и работает только с Hayes-

совместимыми модемами.

По счастью, это определение охватывает боль-

шинство существующих модемов. После инициализации модем генерирует

ответ, отмечая свою готовность принимать данные. Команда flush удаляет это

сообщение и все другие сообщения, которые могли быть отображены моде-

мом, из очереди ввода. Используйте flush, чтобы избавиться от потенциаль-

ных проблем, связанных с наличием непредусмотренных данных в очереди.

Следующая команда осуществляет подключение к удаленному номеру. Ко-

манда dial передает модему стандартную Науеэ-команду набора номера -

ATD. Вместе с командой передается вся строка аргумента. Команда dial из

примера передает модему строку ATD*70,301-555-1234. Модем набирает

*70 (код отключения ожидания звонка

), а затем междугородный код 301,

Если модем понимает лишь часть Науев-команд, избегайте применения таких ко-

манд dip, как reset и dial, поскольку они генерируют Науев-команды. Воспользуй-

тесь командой send, которая позволяет передавать модему любую желаемую строку.

Отключайте ожидание звонка, прежде чем приступать к созданию соединения

РРР. Различные местные телефонные операторы предлагают различные коды,

позволяющие отключать ожидание звонка.

188 Глава б. Настройка интерфейса

номер АТС 555 и номер 1234. Успешно установив соединение с удаленным

модемом, локальный модем отображает сообщение CONNECT. Команда wait

предписывает ожидать такого сообщения от модема.

Команда sleep 2 вставляет в сценарий двухсекундную задержку. Зачастую

бывает полезно сделать паузу перед регистрацией, чтобы позволить удален-

ному серверу инициализировать сеанс. Помните, что сообщение CONNECT

исходит от модема, а не от удаленного сервера. Удаленному серверу может

понадобиться выполнить ряд действий, прежде чем он будет готов прини-

мать данные. Небольшая задержка позволяет избежать появления необъяс-

нимых, невоспроизводимых ошибок.

Команда send передает второй стороне символ возврата каретки

(\г).

Когда

установлено модемное соединение, все данные, передаваемые локальной сис-

темой, попадают напрямую в удаленную систему. Команда send позволяет пе-

редать любую строку. В нашем примере удаленный сервер должен получить

символ возврата каретки, прежде чем отобразит первое приглашение. Сим-

вол возврата каретки записывается как \г, а символ новой строки - как \п.

Удаленный сервер отображает приглашение Login>, предлагая указать имя

пользователя. Команда wait ogin> позволяет обнаружить это приглашение, а

команда send kristin передает в ответ имя пользователя, kristin. Сервер за-

прашивает пароль, отображая приглашение Passwords Команда password пред-

лагает локальному пользователю набрать пароль вручную. Пароль может

храниться в команде send сценария, но такой способ потенциально опасен -

если неуполномоченное лицо получит доступ к сценарию, оно получит доступ

и к паролю. Команда password призвана повысить уровень безопасности.

Если пароль принят, удаленный сервер из нашего примера предлагает на-

чать работу, отображая символ «больше» (>). Многие серверы требуют вы-

полнения определенных команд, указывающих корректный режим работы.

Сервер из нашего примера поддерживает несколько протоколов, так что мы

должны предписать ему использование РРР, передав соответствующую ко-

манду при помощи send.

Завершается сценарий рядом команд, выполняющих настройку среды ло-

кального узла. Команда mode предписывает локальному узлу использовать

протокол РРР для работы с этим каналом. Выбранный протокол должен со-

ответствовать протоколу удаленного сервера. Существуют следующие значе-

ния протоколов для команды dip mode: SLIP, CSLIP, РРР и TERM. SLIP и

CSLIP - это варианты протокола SLIP, о котором мы уже говорили. TERM -

режим эмуляции терминала. РРР - протокол Point-to-Point (точка-точка).

Наконец, команда exit завершает работу сценария, тогда как dip продолжа-

ет работу в фоновом режиме и обслуживает канал.

Этот простой сценарий действительно работает и дает полное представление

о структуре ожидание/передача сценария dip. Однако ваши сценарии, веро-

ятно, будут не столь простыми. Описанный сценарий неустойчив, поскольку

не реализует проверку ошибок. Не получив ожидаемого ответа, сценарий

просто повисает. Для решения проблемы можно воспользоваться интерва-

Установка РРР 189

лом ожидания для каждой команды wait. К примеру, команда wait OK 10

предписывает системы ожидать ответа ОК в течение 10 секунд. Когда ответ

ОК получен, переменная сценария $errlvl получает нулевое значение и вы-

полнение сценария продолжается со следующей команды. Если ответ ОК не

получен до завершения десятисекундного интервала ожидания, $errlvl по-

лучает ненулевое значение, и сценарий переходит к следующей команде. Со-

четание переменной $errlvi с командами if и goto позволяет реализовать об-

работку ошибок в сценариях dip. Более подробная информация по этой теме

содержится в приложении А.

Готовый сценарий исполняется по команде dip. Предположим, приведен-

ный выше сценарий хранится в файле start-ppp.dip. Следующая команда вы-

полняет сценарий и создает канал РРР, соединяющий локальную систему и

удаленный сервер:

> dip start-ppp

Завершается соединение РРР по команде dip -к. Команда закрывает соедине-

ние и принудительно завершает фоновый процесс dip.

Параметры pppd не хранятся в сценариях

dip.

dip всего лишь создает соедине-

ние РРР, но не занимается настройкой

pppd.

Параметры pppd хранятся в фай-

ле /etc/ррр/options.

Имея в виду приведенный выше сценарий dip, мы можем воспользоваться

следующими параметрами pppd:

noipdefault

ipcp-accept-local

ipcp-accept-remote defaultroute

Параметр noipdefault запрещает клиенту определять свой адрес при помощи

локальных служб, ipcp-accept-local предписывает клиенту получить свой

адрес от второй стороны. Параметр ipcp-accept-remote предписывает системе

получить удаленный адрес от удаленной системы. Наконец, pppd предписы-

вает использовать канал РРР в качестве маршрута по умолчанию. Именно

этот параметр defaultroute мы уже встречали ранее в командной строке pppd.

Любой параметр командной строки pppd может храниться в файле /etc/ррр/

options. В этом случае он принимается во внимание всякий раз, когда запус-

кается демон

pppd,

в том числе и по вызову сценария dip.

Я использую dip на своем домашнем компьютере, чтобы настраивать комму-

тируемое РРР-подключение.

Лично я нахожу dip простым и легким в приме-

нении, отчасти потому, что знаком с языком сценариев dip. Кому-то больше

понравится вспомогательная программа

chat,

входящая в состав пакета pppd.

Для меня коммутируемое РРР-соединение - просто резервный вариант. Как мно-

гие другие люди, я работаю через высокоскоростное подключение. Однако DSL и

кабельные модемы не требуют особой настройки, поскольку интерфейсом для

большинства каналов DSL и кабельных модемов является Ethernet.

190

Глава 6. Настройка интерфейса

Каждая строка сценария начинается ожидаемой строкой, а заканчивается

строкой, которая передается в качестве ответа. Модем не посылает строку,

пока не получит соответствующую команду. Первая строка сценария имеет

смысл «не ожидать ничего, передать модему команду инициализации». Па-

ра одинарных кавычек (' ) в начале строки указывает программе chat, что

не следует ожидать получения какой-либо строки. Выполнив команду ини-

циализации, сценарий ожидает получения от модема приглашения ОК, а за-

тем набирает номер удаленного сервера. Когда модем отображает сообщение

CONNECT, сценарий выжидает две секунды (\d\d), а затем передает символ

возврата каретки (\г). Каждый специальный символ \d предписывает паузу

длительностью в одну секунду. Специальный символ \г обозначает возврат

каретки. В chat существует довольно много специальных символов, которые

могут использоваться в строках ожидания и передачи.

Сценарий заверша-

ется передачей имени пользователя, пароля, а также команды настройки

удаленного сервера - в ответ на соответствующие приглашения.

Наберите сценарий в своем любимом текстовом редакторе и сохраните в

файле, назвав его, например dial-server. Проверьте сценарий при помощи

ключа -V команды chat, который предписывает комментировать выполнение

сценария в стандартном потоке ошибок:

Более подробная информация содержится в приложении А.

Выполнения сценария chat не достаточно для настройки канала РРР. Чтобы

выполнить поставленную задачу, команду следует использовать в сочетании

с pppd. Параметр командной строки connect позволяет запустить pppd и вы-

полнить сценарий подключения в одной команде:

chat

Сценарий chat состоит из пар ожидание/передача, определяющих строки,

ожидаемые системой, и строки, передаваемые в ответ. В действительности

chat не имеет языка сценариев, но предоставляет ряд специальных симво-

лов, позволяющих создавать более сложные сценарии. Ниже приведен сце-

нарий chat, выполняющий те же самые функции, что и сценарий dip, кото-

рый мы изучали в предшествующем разделе:

Установка РРР

191

Первый параметр,

lock,

предписывает pppd использовать файлы блокировки в

стиле UUCP. Это предотвращает вмешательство в РРР-соединения со сторо-

ны других приложений, таких как UUCP или эмулятор терминала. Параметр

auth требует авторизации второй стороны для создания канала РРР. Следуя

этому указанию, локальная система запрашивает данные аутентификации у

второй стороны. Вторая сторона при этом может и не запрашивать аналогич-

ные данные у локальной системы. Если администратор удаленной системы

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

слово auth в настройках своей системы. Параметр usehostname предписывает

использовать имя узла в процессе аутентификации и запрещает пользовате-

лю устанавливать произвольное имя локальной системы при помощи пара-

метра

name.

(Очень скоро мы еще вернемся к вопросу проверки подлинности.)

Последний параметр дополняет используемое в процессе проверки подлин-

ности локальное имя до абсолютного - указанием доменного имени.

Вспомните, что параметры файла -/.ррргс и параметры командной строки

pppd имеют приоритет более высокий, чем те, что содержатся в файле /etc/

ррр/options. Такая ситуация может отрицательно повлиять на безопасность.

По этой причине некоторые параметры - включая только что перечислен-

ные, будучи определенными в файле /etc/ррр/options, уже не могут быть из-

менены.

Команда

chat,

указанная в качестве аргумента параметра

connect,

использу-

ется для коммутируемого подключения и регистрации. Здесь может приме-

няться любой пакет, способный выполнить подобные действия; не обяза-

тельно chat.

Команда pppd имеет и другие параметры, используемые для клиентов ком-

мутируемых РРР-подключений. Параметр modem предписывает pppd отсле-

живать наличие несущей частоты (DCD) модема. Указатель DCD сообщает

pppd, что соединение установлено или разорвано, pppd следит за DCD, чтобы

определить, когда удаленный сервер повесит трубку. Параметр nodetach за-

прещает pppd отсоединение от терминала и работу в фоновом режиме. Это не-

обходимо только в случае, когда команда chat выполняется с ключом

-V.

За-

вершив отладку сценария chat, удалите ключ V из подкоманды chat и пара-

метр nodetach из команды

pppd.

Альтернативой является применение ключа

-v команды

chat.

-V не требует изменения режима работы

pppd,

поскольку ди-

агностика chat передается демону syslogd, а не в поток ошибок. Все прочие

параметры этой командной строки мы уже встречали ранее.

Безопасность демона РРР

Серьезным преимуществом РРР перед SLIP являются более надежные меха-

низмы обеспечения безопасности. Чтобы повысить безопасность, добавьте

следующие параметры pppd в файл /etc/ррр/options: