Данный материал эксклюзивно разрешен к размещению в архиве документации opennet.ru (без передачи прав на копирование) автором статьи. Правообладателем публикуемого материала является Алексей А. Абрамов (Foxy S. Aries).
Вопросы использования материалов решаются только правообладателем в одностороннем порядке. Размещение текста статьи где бы то ни было запрещено, без личного разрешения автора.
Скрипт инициализации портов /etc/rc.serial сам по себе довольно объемен. Он содержит все (или почти все) возможные параметры инициализации для большинства известных науке девайсов, подключаемых к последовательному порту. Нас же интересует наличие раздела инициализации последовательных портов для модемов:
modem() { # Modem that supports CTS and perhaps RTS handshaking. ci=$1; shift co=$1; shift for i in $* do # may depend on modem comcontrol /dev/tty${ci}${i} dtrwait 100 drainwait 180 # Lock crtscts on. # Speed reasonable for V42bis. stty < /dev/ttyi${ci}${i} crtscts 57600 stty < /dev/ttyl${ci}${i} crtscts stty < /dev/cuai${co}${i} crtscts 57600 stty < /dev/cual${co}${i} crtscts done }.Сим инициализируются порты, идентификаторы и номера которых передаются функции в качестве аргументов.
Собственно, настройка заключается в раскомментировании строки в конце файла. Для терминалов ttyd1 и ttyd2 (в терминах Microsoft это COM2 и COM3) строка должна выглядеть так:
# Initialize assorted 8250-16550 (sio) ports. modem d a 1 2Параметры проинициализированных портов получаются такими:
stty < /dev/ttyi${ci}${i} crtscts 115200 ... stty < /dev/cuai${co}${i} crtscts 115200
Теперь, если отдать:
dial-in-server# cd /etc dial-in-server# sh rc.serialто порты проинициализируются нужными скоростями. Для пущей уверенности правильность настроек проверяется соединением с модемом с помощью терминалки. Об этом в разделе, посвященном настройке модемов.
Напоследок, есть немаловажные и не совсем очевидные детали при установке скоростей нескольких модемов на одном сервере, которую автор не встречал ни в одном из руководств по dial-in:
Правится это в /etc/ppp/ppp.conf, в параметре set speed. Мне это стоило двух дней - понять, где «собака порылась». Файл /etc/ppp/ppp.conf:
set speed 57600
Вообще, передача данных на физическом уровне бывает синхронной и асинхронной. Терминалы исторически пользуются только асинхронными протоколами последовательных линий. Начало пакета данных определяется положительным или отрицательным фронтом импульса. Затем следует заранее оговоренное число импульсов данных с заранее оговоренной скоростью. Количество переданных полезных бит может быть больше количества импульсов - данные могут передаваться и по фронтам. Далее могут следовать служебные данные типа бита четности. Завершают пакет стоп-биты. Сервер и терминал должны поддерживать и быть сконфигурированы на один тот же протокол.
Настройки линий собраны в файле /etc/gettytab. Естественно, getty, каждый раз, при старте его перечитывает. То есть, после правки, при следующем коннекте будут действовать уже правленые настройки. Секция default определяет параметры, общие для всех секций. Началом секции считается начало строки, окончание и разделитель - двоеточие, продолжение секции на следующей строке - «\» перед концом строки:
default:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:\ :if=/etc/issue:Умолчания такие:
Интересующие нас секции std находятся под комментарием:
# Fixed speed entriesДля dial-in сгодится большинство из них, если не использовать модем на 2400. Как видим, в секциях определяется запрещение эмуляции контроля четности и использование восьмибитных символов (np), затем переопределяется скорость порта (sp#):
g|std.19200|19200-baud:\ :np:sp#19200: std.38400|38400-baud:\ :np:sp#38400: std.57600|57600-baud:\ :np:sp#57600: std.115200|115200-baud:\ :np:sp#115200: std.230400|230400-baud:\ :np:sp#230400:Редактировать (пока) ничего не нужно, важно лишь наличие секции с выбранной скоростью портов и определения в ней протокола 8-N-1:
Настройка сводится к конфигурированию и записи в NVRAM модемов профиля, который будет загружаться при включении и сбросе сигнала DTR. Делается это с помощью любой терминалки и не важно, будет это Windows HyperTerminal, cu или tip UNIX. Мне, однако, претит лишний раз возиться в пыли-грязи с разъемами, да и колотить по клавиатуре в csh получается все же быстрее, чем возить мышью.
Итак, запустим терминалку (модем, подключенный к sio1, проинициализирован на 57600):
dial-in-server# cu -l /dev/cuaa1 -s 57600она лаконично ответит:
Connected.
По команде ATI4 модем обязан послушно выдать листинг текущего профиля. В зависимости от значений этого самого профиля модем может и не дублировать ввод, и не отвечать «ОК». Аналоги ATI4 реализованы во всех модемных чипсетах, так что, скорее всего, листинг будет примерно таким:
U.S. Robotics 56K FAX EXT Settings... B0 E0 F1 L2 M1 Q1 V1 X4 Y0 BAUD=57600 PARITY=N WORDLEN=8 DIAL=PULSE ON HOOK CID=0 &A3 &B1 &C1 &D2 &G0 &H1 &I0 &K1 &M4 &N0 &P2 &R2 &S0 &T5 &U0 &Y1 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=014 S11=070 S12=050 S13=000 S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 S25=020 S27=000 S28=008 S29=020 S30=000 S31=128 S32=002 S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 S41=004 S42=010 LAST DIALED #:
Для нормального функционирования модем должен иметь следующие настройки профиля:
AT&F1E0F1Q1Y0&A3&B1&C1&D2&G0&H1&K1&M4&N0&P0&R2&S0&T5&U0S0=1&W0
Можно поступить по-другому: загрузить заводской шаблон с аппаратным управлением потоком, пролистать его, подправить настройки и записать в NVRAM:
AT&F1 ATI4 AT&F1E0F1Q1Y0 U0S0=1Измененный заводской шаблон сохраняется в профиль 0 NVRAM командой:
AT&W0Проверить настройки можно перезагрузив модем с профилем по умолчанию:
ATZ0 ATI4Выход из cu по:
~. dial-in-server#
В старых (и некоторых не очень старых) модемах есть DIP-переключатели, они имеют наибольший приоритет по сравнению с командами и регистрами, настройка локального эха, автоответа, результирующих кодов и прочих разностей осуществляется ими.
Определения терминалов находятся в файле /etc/ttys. В числе прочих его пользует init, который и запускает на терминале управляющую программу. В контексте настройки dial-in правке подлежат строки определений последовательных терминалов:
# Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyd0 "/usr/libexec/getty std.9600" dialup off secure ttyd1 "/usr/libexec/getty std.9600" dialup off secure ttyd2 "/usr/libexec/getty std.9600" dialup off secure ttyd3 "/usr/libexec/getty std.9600" dialup off secureВ исходном состоянии каждым из четырех dial-in терминалов ttyd заведует getty с параметрами секции std.9600 из файла /etc/gettytab. Параметр secure разрешает логин rootом, а off - говорит init, что терминал отключен. Чтобы реализовать dial-in подключение к ttyd1 и ttyd2, нужно включить терминал, указать ему секцию с настройками порта и одновременно запретить getty принимать логин rootа - немного паранойи никому не помешает:
ttyd0 "/usr/libexec/getty std.9600" dialup off secure ttyd1 "/usr/libexec/getty std.57600" dialup on insecure ttyd2 "/usr/libexec/getty std.57600" dialup on insecure ttyd3 "/usr/libexec/getty std.9600" dialup off secureТеперь отдадим:
dial-in-server# kill -HUP 1Этим мы заставляем init перезагрузиться и, соответственно, перечитать конфигурационные файлы, через момент внешний модем должен зажечь индикатор «TR» (или «DTR» у некоторых модемов, если он есть). Отдадим:
dial-in-server# ps ax | grep ttydи убедимся, что getty готов принимать звонки на нужных нам терминалах с нужными скоростями:
232 ?? I 0:00,07 /usr/libexec/getty std.57600 ttyd1 237 ?? I 0:00,07 /usr/libexec/getty std.57600 ttyd2Особое внимание в листинге процессов стоит уделить второму столбцу. Символы «??» свидетельствуют о нормальном открытии порта getty и ожидании им модемного соединения (активности сигнала DCD). Нечто отличное, вроде «d1» для ttyd1 означает, что модем, подключенный к sio1, принял звонок и установил связь с удаленным коллегой или о неправильной настройке сигнала CD модема.
На этом настройку dial-in сервера можно закончить, если его основное назначение - удаленное администрирование, ибо dial-in консоли для этих целей вполне достаточно. Настройка PAP и CHAP аутентификации «как у взрослых провайдеров» рассматривается в главе «Настройка сервера удаленного доступа», но перед этим автор настоятельно рекомендовал бы убедиться в полной работоспособности «голой» dial-in консоли. В любом случае траблшутинг придется начинать с отключения протоколов авторизации, так как основных исходных причин немного:
Если Вы знакомы с удаленной консолью, то этот раздел можно пропустить и пользоваться для dial-in тем же аккаунтом, что и для удаленной консоли.
В предыдущем разделе «Настройка терминалов» удаленные терминалы были объявлены как insecure. Администрировать же нужно от имени rootа. Создадим с помощью /stand/sysinstall или adduser нового пользователя так, чтобы он являлся членом группы wheel - только доверенным лицам позволено su. Можно просто отредактировать /etc/group, если аккаунт уже существует.
wheel:*:0:root,remoteuser
Теперь, после логина под таким аккаунтом в любое время можно стать rootом:
% su - Password: dial-in-server#Тире - параметр su, позволяющий пользовать окружение rootа, если его опустить, окружение будет взято пользовательское. Кроме dial-in такой аккаунт годится и для любой удаленной консоли.
Неплохим решением будет очистить или отредактировать /etc/motd (оставив две пустые строки в конце) - его содержимое выводится на все виды консолей при логине. Желающим «крутить» систему, подсказка - секция default в /etc/login.conf, мне же было достаточно:
FreeBSD 4.7-RELEASE (NETKERNEL) #8: Thu Feb 5 22:05:48 MSK 2004 Welcome to FreeBSD!
Подробно рассмотренная система удаленного доступа в Internet уже не один год (и уже на втором месте работы) служит мне верой и правдой. Информация по dial-in собиралась из Internet по крупицам - к сожалению, руководство Игоря Сысоева попалось на глаза поздновато, когда многое из этого уже работало.
Как всегда, автором приветствуются предложения, пожелания, конструктивная критика и указание на допущенные ошибки.
Закончен фундаментальный труд. Изначально «Организация dial-in» задумывалась как самая первая из моих публикаций - многие коллеги просили поделиться опытом. Как оказалось, о том, что можно сконфигурировать за несколько часов, пришлось писать несколько недель.
Зачем этот фундаментальный труд, если есть толковое и понятное руководство от Игоря Сысоева? Да потому, что материалов, посвященных dial-in на FreeBSD в Internet крайне мало, по сравнению с остальными темами. Всего лишь упомянутое выше руководство и FreeBSD Handbook. Handbook можно не принимать в расчет, так как в нем отсутствует описание организации сервера удаленного доступа, как такового. Есть, правда, статья Андрея Мозгового на аналогичную тему в журнале «Системный администратор» за февраль 2003 года, но ее мне прочитать не удалось.
Возникло резонное желание - чем-то заполнить информационный вакуум, к тому же мне знакомы люди, которые так и не смогли, не могу сказать по какой причине (не знаю просто, но факт), настроить dial-in сервер по руководству Игоря Сысоева. Нужно учесть и то, что в руководстве изложен один опыт, один взгляд на вещи, а в данной публикации - другой, накопленный и проверенный независимо.
Данная публикация подытоживает мой личный опыт реализации сервера удаленного доступа в Internet с пулом дискретных модемов на основе getty и pppd во FreeBSD 4.x. Во время работы над этой статьей мне пришлось повторить все шаги по конфигурированию модемов, сервера и клиентов от самого начала и до конца (и получить еще один работающий сервер), чтобы вести повествование о стопроцентно работающей системе, ничего (или почти ничего) важного не забыть, акцентировать внимание на ключевых моментах и рассмотреть подробно то, что обычно ускользает.
Используемый мной пул модемов состоит из внешних 3COM/U.S.Robotics Sportster 56k и U.S.Robotics Sportster 28800. Оба модема подключены к портам аналоговой офисной АТС. Максимальные скорости соединений - 31200 бит/с и 28800 бит/с, соответственно. Клиентские стороны оборудованы внешним U.S.Robotics Sportster 33.6 и внутренним win-модемом Zoltrix Phantom 56k.
Несколько слов об организации dial-in через офисные АТС. Безусловно, это дополнительный и довольно сильный источник помех и одна из причин завалов АЧХ канала связи. Вообще, для dial-in большой удачей можно считать скорость устойчивого соединения 31200 бит/с на городских POT линиях. Именно наличие на пути сигнала аппаратуры офисной АТС может сделать невозможным удаленный доступ как таковой, в большинстве случаев, несколько стабилизировать связь и улучшить качество и скорости позволяет «тонкая» настройка модема на стороне сервера и/или клиента - очень кропотливая, но и, одновременно, творческая работа. Стоит быть готовым к тому, что эта работа в итоге может не дать положительного результата.
Настройка клиентов для dial-in сервера ничем не отличается от «стандартной», подробно описанной во множестве руководств. Кроме того, каждый уважающий себя провайдер Internet в конверт с логином и паролем кладет развернутую инструкцию по настройке удаленного доступа.
Итак, с помощью мастера создадим учетную запись удаленного доступа, например, «Dial-in клиент Windows». Первый подводный камень: иногда Windows забывает об установке импульсного набора, указанного в «правилах набора номера», поэтому сразу предупредим ее «склероз» символом «p»:
Также вполне логичным будет отключение брандмауэра Windows на период тестирования dial-in:
Вообще, во встроенном брандмауэре, как, кстати, и в QoS совершенно нет нужды, ведь сам dial-in сервер неплохо защищен. Более того, после удаления QoS из системы реальные скорости передачи информации в обе стороны возрастают.
По завершении работы мастера проинспектируем свойства получившегося подключения. Первым делом проверим параметры модема, через который будет производиться подключение:
Во вкладке «Параметры» можно установить параметры дозвона.
Вкладка «Безопасность» - как раз место для эксперимента. Если dial-in серверу предоставлена свобода выбора протокола аутентификации, то, скорее всего, менять ничего не придется и всех - сервер и клиента - вполне устроят «Обычные (рекомендуемые параметры)»:
Подобные параметры без проблем позволяют использовать CHAP обеим сторонам. При траблшутинге отметка опции «Вывести окно терминала» позволит лишний раз не пользоваться терминалкой, правда аутентификацию в этом случае нормально пройти не удастся.
Если, несмотря на мои вялые протесты, все же решено использовать PAP, или есть огромное желание экспериментировать, добро пожаловать в «Дополнительные (выборочные параметры)». Устойчивой аутентификации при минимуме затраченных нервов при экспериментах проще всего добиться, имея под рукой консоль сервера и рабочий стол клиента. Положительный результат достижим:
Вкладка «Сеть» отвечает за протокол, который должен быть, естественно «PPP», причем, настоятельно рекомендую включить опцию «Использовать расширения LCP». «Программное сжатие данных» на деле таковым не является, оно, как и подобная опция в настройках модема, весьма неожиданным образом меняет строку инициализации модема:
Указание IP и/или DNS вручную абсолютно ничего не меняет, если pppd сконфигурирован предоставлять адреса клиентам, стоит убедиться лишь, что в окне «Дополнительные параметры TCP/IP», зарытом глубже в свойствах, отмечены опции «Использовать основной шлюз в удаленной сети» и «Использовать сжатие IP-заголовков»:
Соответственно, редактировать параметры во вкладках «DNS» и «WINS» дополнительных параметров особого смысла не имеет.
Для UNIX систем, и, в частности, для FreeBSD настройка удаленного доступа также нисколько не отличается от «общепринятой». Можно устанавливать соединение вручную, выглядеть это будет точно так же, как описано в разделе «Установка соединения с сервером из FreeBSD» главы «Dial-in клиент» с небольшими отличиями в виде ввода имени и пароля:
Using interface: tun0 ppp ON dial-in-client> set authname client1 ppp ON dial-in-client> set authkey guessable1
Затем, после установления соединения из терминального режима, ввода «~p» чтобы запустить PPP-аутентификацию:
ppp ON dial-in-client>term ... CONNECT ... ~p ppp ON dial-in-client> Ppp ON dial-in-client> PPp ON dial-in-client> PPP ON dial-in-client>Кстати, в процессе работы ppp выводит на консоль ttyv0 (которая появляется при загрузке системы) некоторые важные сообщения, например, об установке шлюза по умолчанию.
Автоматическое соединение настраивается редактированием файла /etc/ppp/ppp.conf, причем перед редактированием стоит убедиться в правах доступа к нему - режим 400 и владелец root:wheel. Создатели уже предусмотрели практически все, поэтому правок немного.
В секции default редактированием chat строки можно подкорректировать параметры инициализации клиентского модема, там же изменяется метод набора номера (по умолчанию - тоновый):
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK AT&F1X4L3 OK \\dATDP\\T TIMEOUT 180 CONNECT"При необходимости - скорость порта:
set speed 57600
Строку, каждый раз перезаписывающую /etc/resolv.conf лучше закомментировать, и просто необходимо, если данному dial-in клиенту не все равно, какими DNS пользоваться:
# enable dnsБесконечный повтор набора номера через случайные промежутки времени можно указать строкой:
set redial random 0
Ниже, в секции «papchap», проставим реквизиты удаленного доступа (имя, пароль и номер телефона):
set phone 1234567 set authname client1 set authkey guessable1
Некоторым нравится сеть 10.0.0.0 с различной разрядностью маски. Если таковая находится в пределах досягаемости, рекомендую сменить адреса на несуществующие в строке:
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
Собственно все. Отдаем:
dial-in-client# ppp -ddial papchapи наслаждаемся.
Итак, терминальное соединение уже настроено и проверено, теперь нужно заставить dial-in сервер понимать протокол PPP и передавать управление не /usr/bin/login, а демону PPP - pppd, или, как его по-другому называют kernel-level ppp.
В разделе «Протокол терминальных линий» главы «Dial-in сервер» уже обсуждался /etc/gettytab. В ту секцию std, где описывается выбранная для getty скорость, добавим строку pp=/root/pppd.sh:
std.57600|57600-baud:\ :np:sp#57600:\ :pp=/root/pppd.sh:Этим мы заставим getty использовать аутентификацию PPP с помощью скрипта /root/pppd.sh, причем его путь и имя могут быть произвольными, но pppd будет запускаться от имена rootа, а /root/ - и неглубоко от корня, и права доступа у ней вполне соответствующие для обеспечения защиты скрипта. На pppd.sh лучше дать минимальные права - поставить режим 500 и владельца root:wheel. Скрипт будет таким:
#!/bin/sh /usr/sbin/pppd 57600 authЦифра 57600 - хорошо знакомая скорость портов и терминалов, параметр auth предписывает демону аутентифицировать с помощью PAP или CHAP.
Если же решено использовать, например, только CHAP, так как Windows предпочитает именно его, то работу pppd можно облегчить, запретив в скрипте /root/pppd.sh PAP:
#!/bin/sh /usr/sbin/pppd 57600 auth refuse-pap require-chap
Логи - один из основных инструментов системного администратора, а их чтение - ежедневная рутина, как мытье рук перед едой :). Вести их для pppd будет syslogd, и складывать в /var/log/pppd.log. В файл syslog.conf добавим строки:
!pppd *.* /var/log/pppd.log
Ротацию pppd.log по достижению им размера 100 Кбайт организуем добавлением в newsyslog.conf строки:
/var/log/pppd.log root:network 640 3 100 * ZПрава доступа лучше оставить именно такие. В любом случае root должен иметь возможность писать в файл.
Теперь осталось только создать сам файл логов и перезагрузить syslogd, чтобы он перечитал конфигурационные файлы:
dial-in-server# touch /var/log/pppd.log dial-in-server# kill -HUP `cat /var/run/syslogd.pid`
Кроме командной строки, по умолчанию pppd воспринимает опции из определенных файлов, расположенных в /etc/ppp/. Файлом, общим для всех терминалов, является /etc/ppp/options, для определенного терминала pppd ищет /etc/ppp/options.ttydN (например, для sio0 это будет файл /etc/ppp/options.ttyd0). Опции в них перечисляются по одной в строке. Самый высокий приоритет у опций, перечисленных непосредственно в командной строке (у нас это вызов в /root/pppd.sh), ниже у /etc/ppp/options, и самый низкий приоритет имеют опции для каждого терминала из /etc/ppp/options.ttydN.
Растаскивать опции по терминалам или же сконцентрировать их в одном месте - личное дело каждого, но из соображений удобства, единства конфигураций и избежания путаницы практичнее, все же, последнее. Файл /etc/ppp/options:
57600 modem crtscts passive mtu 576 ms-dns 192.168.0.1 ms-dns 192.168.1.1 ms-wins 192.168.0.100 name dialin debugОпция 57600 лишний раз напоминает pppd о скорости терминалов. Строки modem и crtscts говорят, что общение с терминальным девайсом происходит посредством присущих модемам сигналов (DCD) с аппаратным управлением потоком.
После установки соединения модемом pppd отсылает LCP-кадры инициализации PPP-соединения. Чтобы pppd не сбрасывал соединение, а терпеливо ждал, не получив в ответ правильные LCP-кадры от удаленной стороны, служит опция passive. Размер пакета по умолчанию - mtu равен 576 байт. На медленных линиях документация pppd рекомендует mtu 296 (40 байт на заголовок TCP/IP и 256 байт данных), в Ethernet по умолчанию mtu равен 1500 байт.
Сервер dial-in заставляет клиента принять и пользоваться DNS и WINS серверами из ms-dns и ms-wins, на самом деле к Microsoft эти опции никакого отношения не имеют. Нужда в адресах WINS мыслима только при логине в домен Microsoft, а хотя бы один адрес DNS указать стоит. Причем самым разумным будет указание DNS-форвардера (он же кэширующий DNS) шлюза в Internet из сегмента сети клиента, а не DNS провайдера. Этим заметно сокращается время ответа на запрос разрешения имени, значит, субъективно, браузер будет загружать страницы быстрее.
Имя, необходимое при аутентификации CHAP, берется из опции name. В принципе, опция может отсутствовать, тогда pppd воспользуется полным именем хоста hostname из /etc/rc.conf. Для PAP параметр name не имеет абсолютно никакого значения.
С помощью опции debug можно заставить pppd вести очень подробные протоколы всех своих действий. Ценой этому будет лог, в который умещается меньше десятка соединений, но на первое время, особенно на период «знакомства» с dial-in и/или траблшутинга, содержимое /var/log/pppd.log окажет неоценимую помощь.
Если планируется выделять IP-адреса для dial-in клиентов из пула локальной сети, стоит воспользоваться опцией:
proxyarpВ этом случае в ARP-таблице сервера каждый раз будет создаваться соответствующая запись с фиктивным MAC-адресом. Со стороны такое соединение будет выглядеть как Ethernet-соединение. Раздача dial-in клиентам IP-адресов из пула локальной сети привлекательна еще и тем, что, скорее всего, не придется добавлять и/или править правила для брандмауэра.
Список можно дополнить опцией, определяющей IP-адрес dial-in сервера, общего для всех клиентов:
192.168.1.1:Тогда, в рассмотренных ниже файлах аутентификации, указать нужно только IP-адреса dial-in клиентов. Все зависит от личных предпочтений и от того, будут ли в клиенты разделяться по адресам сервера.
Еще одной опцией может быть
loginВ этом случае pppd будет проверять базу со списком пользователей системы /etc/master.passwd на предмет наличия запрашивающего соединение пользователя и его валидности. То есть соединение будет возможно только с реквизитами пользователя, реально имеющего возможность входа в систему. Соответственно логике вещей, pppd запротоколирует такое соединение аналогично обычной консольной сессии пользователя. На первый взгляд, опция login может показаться очень удобной для организации биллинга. Не буду настаивать, но, на мой взгляд, есть способы гораздо более гибкие. Если dial-in пользователь один, то поменять его реквизиты, например, пароль - проблем нет, а если их десяток - путаницы не избежать, ведь изменять пароль придется дважды.
По умолчанию файлы аутентификации располагаются в /etc/ppp/ и называться должны pap-secrets и chap-secrets соответственно. Настоятельно рекомендую установить им права 400 и владельца root:wheel, pppd сможет их прочесть, так как запускается от имени rootа, а неблагонадежные посторонние - нет. В целом, их структура одинакова. Одна строка соответствует одной записи. Вообще-то, запись представляет собой не что иное, как список параметров для передачи функциям в недрах pppd:
client1 dialin "guessable1" 192.168.1.1:192.168.1.2 client2 dialin "guessable2" 192.168.1.1:192.168.1.3Клиент client1 может соединяться с сервером с хоста dialin с паролем guessable1 по протоколу PPP. Кавычки здесь служат символами-ограничителями пароля. При соединении ему будет присвоен адрес 192.168.1.2, а интерфейсу pppN (ppp0 - если client1 единственный) сервера pppd присвоит 192.168.1.1, если в файле опций /etc/ppp/options не указан иной адрес.
Как показала практика, никакой проверки на принадлежность хостов к доменам pppd не делает (или делает, но упорно об этом умалчивает), поэтому с одинаковым успехом с сервером соединяются dial-in клиенты FreeBSD и Windows с произвольным именем хоста. Вместо dialin смело можно ставить «*», позволив тем самым соединяться клиентам с любого хоста:
client3 * "guessable3" 192.168.1.1:192.168.1.4 client4 * "guessable4" 192.168.1.1:192.168.1.5
Стоит заметить, что pap-secrets, в отличие от chap-secrets, позволяет хранить пароли не только в открытом виде. При аутентификации PAP pppd после первой неудачной попытки сравнения исходного и полученного паролей хэширует исходный пароль функцией crypt и сравнивает повторно:
client5 * "gul87U6yPydXI" 192.168.1.1:192.168.1.6 client6 * "gupH5.1VDmOSA" 192.168.1.1:192.168.1.7
Более того, можно пойти дальше и, указав в /etc/ppp/options опцию login, заставить pppd брать образцы паролей dial-in клиентов из /etc/master.passwd. Тогда pap-secrets может вообще не содержать паролей:
client7 * "" 192.168.1.1:192.168.1.8 client8 * "" 192.168.1.1:192.168.1.9
Неудобство состоит в том, что смешивать пароли не удастся - для всех клиентов они будут браться либо из файла secrets, либо из системной базы /etc/master.passwd по опции login. На мой взгляд, для сокрытия содержимого файлов аутентификации вполне достаточно установки прав и владельца, а опция login - от лукавого. К тому же, наверняка в качестве PPP-клиента будет использоваться Windows, мягко говоря, предпочитающая протокол CHAP.
Резюмируя, мои рекомендации в плане аутентификации таковы:
Неизвестно почему, но все руководства опускают весьма важные вопросы, связанные с правилами брандмауэра и списками доступа прокси-сервера. А ведь, правильно и, значит, агрессивно, настроенный брандмауэр корпоративного доступа просто не пустит dial-in клиента в Internet, ни к электронной почте, ни к DNS сервису, вне зависимости от того, работает pppd на выделенном сервере или же непосредственно на корпоративном сервере доступа. Жирный минус в кондуит товарищам - либо не подумали, либо не умеют толком настраивать.
Смею предположить, что прокси-сервер - squid, на сегодняшний день это неписанный стандарт de facto. Настоятельно советую пользоваться прокси, при плохой АЧХ телефонных линий и частых ретрейнах это поможет сберечь нервные клетки. Адреса dial-in можно прописать в списки доступа непосредственно в /usr/local/etc/squid/squid.conf:
acl dial_in_users src 192.168.1.2-192.168.1.4/255.255.255.0 http_access allow dial_in_users Safe_ports
Можно завести, как, впрочем, и для всех остальных классов пользователей прокси-сервиса отдельный файл, например, /usr/local/etc/squid/dialin.users.tab:
acl dial_in_users src "/usr/local/etc/squid/dialin.users.tab"
Сам dialin.users.tab будет содержать перечисление IP-адресов:
192.168.1.2/255.255.255.255 192.168.1.3/255.255.255.255 192.168.1.4/255.255.255.255
Конфигурационный файл у squid огромный, поэтому преимущества и удобства вынесения адресов в отдельный файл очевидны, кроме того, правило http_access менять не нужно:
http_access allow dial_in_users Safe_ports
Разочарование постигает, когда проделана огромная работа и наконец-то затихли приятные уху звуки модуляции модемов, а в браузере не открывается ни один сайт. Что ж, значит, брандмауэр (или брандмауэры) настроен правильно, осталось только положить несколько штрихов. Для моих коллег по диагнозу «паранойа» могу предложить опробованный мной простой путь - вручную добавить поближе к верху списка ipfw правило, протоколирующее весь трафик IP. В данном примере сервер имеет адрес 192.168.1.1, а dial-in клиенты получают адреса из сегмента 192.168.1.0/24:
dial-in-server# ipfw add 10 allow log logamount 10000 ip \ from 192.168.1.0/24 to 192.168.1.0/24 via ppp0
Затем соединиться с сервером, запустить короткие сессии ping каких-либо серверов, походить по Internet (лучше делать это сразу через прокси), запустить удаленную консоль, «снять» почту и так далее. Добавленное правило все же образует «дыру», поэтому увлекаться не советую. По завершению соединения правило удаляется:
dial-in-server# ipfw delete 10А в файле /var/log/security можно будет отыскать прототипы всех необходимых правил ipfw:
Есть несколько тонкостей:
Итак, если клиенты располагаются в сети 192.168.1.0/24, а серверному интерфейсу PPP присваивается адрес 192.168.1.1 и в локальную сеть смотрит 192.168.0.1, то для FTP, HTTP через прокси, удаленной консоли и traceroute правила могут быть примерно такими:
dial-in-server# ipfw add 60 allow tcp \ from 192.168.1.1 20,21,22,200,3128-45000 to 192.168.1.0/24 via ppp0 dial-in-server# ipfw add 61 allow tcp \ from 192.168.1.1 20,21,22,200,3128-45000 to 192.168.1.0/24 via ppp1 dial-in-server# ipfw add 70 allow tcp \ from 192.168.1.0/24 to 192.168.1.1 20,21,22,200,3128-45000 via ppp0 dial-in-server# ipfw add 71 allow tcp \ from 192.168.1.0/24 to 192.168.1.1 20,21,22,200,3128-45000 via ppp1 dial-in-server# ipfw add 72 deny tcp \ from 192.168.1.0/24 to any 80,8000-8888 via ppp0 dial-in-server# ipfw add 73 deny tcp \ from 192.168.1.0/24 to any 80,8000-8888 via ppp1Для ping в локальной сети, если нет правила icmp from any to any:
dial-in-server# ipfw add 80 allow icmp \ from 192.168.1.0/24 to 192.168.1.0/24 icmptype 0,3,4,8,11 via ppp0 dial-in-server# ipfw add 81 allow icmp \ from 192.168.1.0/24 to 192.168.1.0/24 icmptype 0,3,4,8,11 via ppp1Для запросов и ответов DNS:
dial-in-server# ipfw add 90 allow udp \ from 192.168.1.0/24 to 192.168.1.1 53 via ppp0 dial-in-server# ipfw add 91 allow udp \ from 192.168.1.0/24 to 192.168.0.1 53 via ppp0 dial-in-server# ipfw add 92 allow udp \ from 192.168.1.0/24 to 192.168.1.1 53 via ppp1 dial-in-server# ipfw add 93 allow udp \ from 192.168.1.0/24 to 192.168.0.1 53 via ppp1 dial-in-server# ipfw add 94 allow udp \ from 192.168.1.1 53 to 192.168.1.0/24 via ppp0 dial-in-server# ipfw add 95 allow udp \ from 192.168.0.1 53 to192.168.1.0/24 via ppp0 dial-in-server# ipfw add 96 allow udp \ from 192.168.1.1 53 to 192.168.1.0/24 via ppp1 dial-in-server# ipfw add 97 allow udp \ from 192.168.0.1 53 to192.168.1.0/24 via ppp1
В заключение, нелишним будет еще раз испытать правило 10, рассмотренное выше, оно же станет одним из основных инструментов при траблшутинге dial-in. Мне весьма трудно предлагать готовые решения, не видя правил конкретного брандмауэра - оптимальная настройка ipfw - целое искусство.
Для успешного логина к серверу, а не только лишь факта установления связи, клиентский модем должен иметь следующие настройки в точности такие же, что и серверный:
Все это собрано в окне свойств модема, попасть туда можно через иконку «Телефон и модем» панели управления. Скорость порта устанавливается во вкладке «Модем», остальные параметры, в том числе и скорость порта по умолчанию в окне «Предпочтения по умолчанию», открывающимся кнопкой «Изменить умолчания...» там же, во вкладке «Дополнительные параметры связи».
В отличие от Windows, стоит лишь убедиться в наличии /dev/tun0.
Девайс непременно будет, если только в ядре есть и не закомментирована строка
(в ядре GENERIC она присутствует):
pseudo-device tun
Если tun все таки отсутствует, а модем подключен, поможет перезагрузка - во время device probing система создаст его. Можно сделать то же самое ручками:
dial-in-client# cd /dev dial-in-client# sh MAKEDEV tun0
После установления связи серверный модем (так же как и его удаленный коллега) устанавливает сигнал CD, getty просыпается, интересуется именем пользователя и передает управление /usr/bin/login с полученным именем в качестве параметра. Тот, в свою очередь, аутентифицирует пользователя в системе и вызывает указанный в /etc/master.passwd шелл, если он существует. Вид баннера, отображаемого при логине можно изменить в файле /etc/gettytab (см. раздел «Протокол терминальных линий» главы «Dial-in сервер»):
FreeBSD/i386 (dial-in-server.dialin.ru) (ttyd1) login: remoteuser Password: Last login: Mon Mar 15 20:37:31 from dialup-0.1.168. Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-RELEASE (NETKERNEL) #8: Thu Feb 5 22:05:48 MSK 2004 Welcome to FreeBSD! %su - Password: dial-in-server# dial-in-server# ps ax PID TT STAT TIME COMMAND ... 25047 d1 Ss 0:00,02 login -p remoteuser ... dial-in-server# exit logout % exit logout
Если после коннекта на экране вместо приглашения появляется «мусор», то, скорее всего, скорости портов серверной и клиентской сторон разные. Еще одной из причин появления «мусора» бывает, правда, очень редко, зашумленность линии - модемы соединяются без протоколов коррекции ошибок.
Воспользуемся интерактивным режимом user-ppp, предназначенным как раз для dial-up:
dial-in-client# ppp Working in interactive mode Using interface: tun0 ppp ON dial-in-client>Введем порт, его скорость и переключимся в режим терминала:
ppp ON dial-in-client>set device /dev/cuaa0 ppp ON dial-in-client>set speed 57600 ppp ON dial-in-client>termЗатем попробуем дозвониться до сервера. Для 3COM/U.S. Robotics диалог со сбросом текущих настроек модема и загрузкой заводских умолчаний аппаратного контроля потоком будет примерно таким:
at OK at&f1 OK atdp1234567 CONNECT FreeBSD/i386 (dial-in-server.dialin.ru) (ttyd1) login: remoteuser Password: Last login: Mon Mar 15 20:39:43 from dialup-0.1.168. Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-RELEASE (NETKERNEL) #8: Thu Feb 5 22:05:48 MSK 2004 Welcome to FreeBSD! %su - Password: dial-in-server# dial-in-server# exit logout % exit logout