1205 lines
50 KiB
Text
1205 lines
50 KiB
Text
<!-- $Id: network.sgml,v 1.1 1998-12-28 19:20:04 ache Exp $ -->
|
||
<!-- The FreeBSD Russian Documentation Project -->
|
||
|
||
<sect>
|
||
<heading>Работа в сети<label id="networking"></heading>
|
||
|
||
<sect1>
|
||
<heading>Где можно найти информацию о ``бездисковой загрузке''?</heading>
|
||
|
||
<p>``Бездисковая загрузка'' означает, что машина с FreeBSD загружается
|
||
по сети и читает необходимые файлы с сервера, а не со своего диска.
|
||
Подробное описание есть в
|
||
<url url="../handbook/diskless.html" name="соответствующей главе">
|
||
Руководства.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Может ли машина с FreeBSD использоваться как маршрутизатор?
|
||
</heading>
|
||
|
||
<p>Стандарты Internet и опыт практической работы не позволяют нам
|
||
в FreeBSD держать маршрутизацию пакетов включенной по умолчанию. Вы,
|
||
можете сделать это, изменив значение следующей переменной в файле
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
|
||
name="rc.conf"> на <tt/YES/:
|
||
|
||
<verb>
|
||
gateway_enable=YES # Set to YES if this host will be a gateway
|
||
</verb>
|
||
|
||
<p>Этот параметр изменит значение
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sysctl"
|
||
name="системной переменной">
|
||
<tt/net.inet.ip.forwarding/ на <tt/1/.
|
||
|
||
<p>Кроме того, в большинстве случаев вам будет необходимо запустить
|
||
программу маршрутизации, для того, чтобы объявить о появлении нового
|
||
маршрутизатора другим системам в вашей сети; FreeBSD поставляется со
|
||
стандартной для BSD-систем программой маршрутизации
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed"
|
||
name="routed">, в более сложных ситуациях вы можете попробовать
|
||
<em/GaTeD/ (доступный по FTP с <tt/ftp.gated.Merit.EDU/), который
|
||
поддерживает FreeBSD начиная с версии 3_5Alpha7.
|
||
|
||
<p>Мы обязаны предупредить вас, что даже когда FreeBSD настроена
|
||
таким образом, она не полностью соответствует стандартам Internet
|
||
для маршрутизаторов, однако для обычной работы этого хватает.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Можно ли подключить машину с Win95 к Internet с помощью FreeBSD?
|
||
</heading>
|
||
|
||
<p>Как правило, те, кто задает такие вопросы, имеют дома два компьютера,
|
||
один с FreeBSD, а другой с Win95; идея состоит в использовании
|
||
FreeBSD для подключения к Internet, а затем осуществлять выход в
|
||
Internet из Windows95 через FreeBSD. На самом деле это просто
|
||
особый случай предыдущего вопроса.
|
||
|
||
<p>Существует полезный <url
|
||
url="http://www.ssimicro.com/~jeremyc/ppp.html" name="документ">,
|
||
описывающий, как настроить FreeBSD в качестве маршрутизатора с выходом
|
||
по протоколу PPP.
|
||
|
||
<p><bf/ЗАМЕЧАНИЕ:/ При этом требуется иметь по крайней мере два
|
||
фиксированных IP адреса, а может быть, три или больше, в зависимости
|
||
от того, сколько машин с Windows вы хотите подключить. Как вариант,
|
||
если у вас нет фиксированных IP адресов, вы можете использовать
|
||
одну из частных IP подсетей и установить <bf/прокси/ типа
|
||
<url url="http://squid.nlanr.net/Squid/" name="SQUID"> или
|
||
<url url="http://www.tis.com/" name="TIS"> на машине с FreeBSD.
|
||
|
||
<p>Посмотрите также раздел о <ref id="natd">.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Почему не проходит компиляция последней версии BIND от ISC?
|
||
</heading>
|
||
|
||
<p>Это - результат конфликта между файлом ``<tt/cdefs.h/'' в
|
||
дистрибутиве и тем, что поставляется с FreeBSD. Достаточно
|
||
удалить файл <tt>compat/include/sys/cdefs.h</tt>.
|
||
|
||
<sect1>
|
||
<heading>Поддерживает ли FreeBSD протоколы SLIP и PPP?</heading>
|
||
|
||
<p>Да. Посмотрите страницы справочника по командам
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
|
||
name="slattach">, <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?sliplogin" name="sliplogin">,
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppd" name="pppd"> и
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">.
|
||
<tt/Pppd/ и <tt/ppp/ могут обслуживать как входящие, так и исходящие
|
||
соединения. <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
|
||
name="Sliplogin"> имеет дело исключительно со входящими соединениям,
|
||
а <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
|
||
name="slattach"> - только с исходящими.
|
||
|
||
<p>Эти программы описаны в следующих разделах
|
||
<url url="../handbook/handbook.html" name="руководства">:
|
||
|
||
<itemize>
|
||
<item><url url="../handbook/slips.html"
|
||
name="Протокол SLIP (сервер)">
|
||
|
||
<item><url url="../handbook/slipc.html"
|
||
name="Протокол SLIP (клиент)">
|
||
|
||
<item><url url="../handbook/ppp.html"
|
||
name="Протокол PPP (ядро)">
|
||
|
||
<item><url url="../handbook/userppp.html"
|
||
name="Протокол PPP (пользователь)">
|
||
</itemize>
|
||
|
||
<p>Если вы имеете доступ в Internet через командную строку
|
||
оболочки, вам может подойти <htmlurl
|
||
url="http://www.freebsd.org/cgi/ports.cgi?^slirp" name="slirp">.
|
||
С его помощью можно получить (ограниченный) доступ к таким
|
||
службам, как ftp и http прямо с вашей машины.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Поддерживает ли FreeBSD NAT или Masquerading?<label id="natd">
|
||
</heading>
|
||
|
||
<p>Если у вас есть локальная сеть (одна или больше машин), но
|
||
только один IP адрес, предоставленный провайдером, вас может привлечь
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd" name="natd">.
|
||
<tt/Natd/ позволяет подключить всю сеть к Internet, используя
|
||
единственный IP адрес.
|
||
|
||
<p>Программа <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
|
||
name="ppp"> имеет похожую встроенную возможность через параметр
|
||
<tt/-alias/. В обоих случаях используется библиотека
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
|
||
name="libalias">.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Не могу заставить работать ppp. Что я делаю не так?<label id="userppp">
|
||
</heading>
|
||
|
||
<p>Первым делом прочтите <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?ppp"
|
||
name="страницы справочника">, посвящённые ppp, а также соответствующий
|
||
<url url="../handbook/userppp.html" name="раздел"> руководства.
|
||
Включите протоколирование командой
|
||
|
||
<verb>
|
||
set log Phase Chat Connect Carrier lcp ipcp ccp command
|
||
</verb>
|
||
|
||
<p>Эта команда может быть набрана в командной строке <bf/ppp/ или
|
||
она может находиться в конфигурационном файле
|
||
<tt>/etc/ppp/ppp.conf</tt> (начало секции <bf>default</bf> - лучшее
|
||
для неё место. Удостоверьтесь, что файл
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
|
||
name="/etc/syslog.conf"> содержит строки
|
||
|
||
<verb>
|
||
!ppp
|
||
*.* /var/log/ppp.log
|
||
</verb>
|
||
|
||
<p>и файл <tt>/var/log/ppp.log</tt> существует. Теперь вы сможете
|
||
найти полную информацию о происходящем в файле протокола. Не
|
||
беспокойтесь, если не всё вам будет там понятно. Если вы будете
|
||
пользоваться чьей-то помощью, протокол вам пригодится.
|
||
|
||
<p>Если ваша версия ppp не понимает команду "set log", вы должны
|
||
скачать <url url="http://www.freebsd.org/~brian"
|
||
name="последнюю версию">. Она рассчитана на FreeBSD версий 2.1.5
|
||
и выше.
|
||
|
||
<sect2>
|
||
<heading>Ppp просто зависает, когда я его запускаю</heading>
|
||
|
||
<p>Обычно это происходит, когда не может быть определено имя
|
||
вашего хоста. Наилучший способ исправить это -
|
||
удостовериться, что файл <tt>/etc/hosts</tt> используется вашим
|
||
ресолвером. Отредактируйте файл <tt>/etc/host.conf</tt>, поместив
|
||
на первое место строчку <tt>hosts</tt>. Затем просто добавьте
|
||
записи о вашей машине в файл <tt>/etc/hosts</tt>. Если у вас нет
|
||
локальной сети, измените строку <tt>localhost</tt>:
|
||
|
||
<verb>
|
||
127.0.0.1 foo.bar.com foo localhost
|
||
</verb>
|
||
|
||
В противном случае просто добавьте ещё одну запись о вашем хосте.
|
||
Обратитесь к соответствующим страницам справочника за подробным
|
||
описанием.
|
||
|
||
<p>Если вы выполнили эти указания, вы сможете успешно выполнить
|
||
команду <tt>ping -c1 `hostname`</tt>.
|
||
|
||
<sect2>
|
||
<heading>Ppp не звонит в режиме -auto</heading>
|
||
|
||
<p>Во-первых, проверьте, что у вас есть маршрут по умолчанию.
|
||
Запустив <htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
|
||
name="netstat -rn">, вы должны увидеть две строки вида:
|
||
|
||
<verb>
|
||
Destination Gateway Flags Refs Use Netif Expire
|
||
default 10.0.0.2 UGSc 0 0 tun0
|
||
10.0.0.2 10.0.0.1 UH 0 0 tun0
|
||
</verb>
|
||
|
||
<p>Здесь предполагается, что вы использовали адреса,
|
||
приведённые в Руководстве, Справочнике или файле
|
||
ppp.conf.sample. Если у вас нет маршрута по умолчанию, это
|
||
может быть из-за использования старой версии
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
|
||
name="ppp">, которая не понимает слова <tt/HISADDR/ в файле
|
||
ppp.conf. Если ваша версия <bf/ppp/ из FreeBSD версий ранее
|
||
чем 2.2.5, замените строку
|
||
|
||
<verb>
|
||
add 0 0 HISADDR
|
||
</verb>
|
||
|
||
<p>на
|
||
|
||
<verb>
|
||
add 0 0 10.0.0.2
|
||
</verb>
|
||
|
||
<p>Другой причиной отсутствия маршрута по умолчанию может быть
|
||
то, что вы ошибочно установили маршрут по умолчанию в вашем файле
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
|
||
name="/etc/rc.conf"> (этот файл назывался <tt>/etc/sysconfig</tt>
|
||
до 2.2.2-RELEASE), и вы пропустили строку
|
||
|
||
<verb>
|
||
delete ALL
|
||
</verb>
|
||
|
||
<p>в <tt>ppp.conf</tt>. В таком случае обратитесь к
|
||
соответствующему <url url="../handbook/userppp:final.html"
|
||
name="разделу"> Руководства.
|
||
|
||
<sect2>
|
||
<heading>Что означает сообщение "No route to host"?</heading>
|
||
|
||
<p>Эта ошибка появляется из-за отсутствующего раздела
|
||
|
||
<verb>
|
||
MYADDR:
|
||
delete ALL
|
||
add 0 0 HISADDR
|
||
</verb>
|
||
|
||
<p>в файле <tt>/etc/ppp/ppp.linkup</tt>. Он необходим, если ваш
|
||
IP адрес выделяется динамически или адрес маршрутизатора вам не
|
||
известен. Если вы используете интерактивный
|
||
режим, вы можете набрать следующие команды после входа в
|
||
<tt/пакетный режим/ (пакетный режим идентифицируется заглавными
|
||
буквами <bf/PPP/ в приглашении):
|
||
|
||
<verb>
|
||
delete ALL
|
||
add 0 0 HISADDR
|
||
</verb>
|
||
|
||
<p>Обратитесь к разделу <url url="../handbook/userppp:dynamicIP.html"
|
||
name="PPP и динамические IP адреса"> Руководства за подробной
|
||
информацией.
|
||
|
||
<sect2>
|
||
<heading>Соединение разрывается через 3 минуты</heading>
|
||
|
||
<p>Таймаут для ppp по умолчанию равен 3 минутам. Это может быть
|
||
изменено строкой
|
||
|
||
<verb>
|
||
set timeout NNN
|
||
</verb>
|
||
|
||
<p>где <bf/NNN/ - время неактивности в секундах, после которого
|
||
соединение закывается. Если <bf/NNN/ равно нулю, соединение никогда
|
||
не разрывается по таймауту. Эту команду можно поместить в файл
|
||
<tt>ppp.conf</tt> или набрать ее в интерактивном режиме. Изменение
|
||
этого параметра также возможно при активном соединении, если
|
||
подключиться к сокету <bf/ppp/ сервера с помощью программ
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet">
|
||
или <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
|
||
name="pppctl">. Обратитесь к страницам Справочника, посвящённым
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">.
|
||
|
||
<sect2>
|
||
<heading>Соединение разрывается при большой нагрузке</heading>
|
||
|
||
<p>Если у вас включен Link Quality Reporting (LQR), возможно,
|
||
что слишком много пакетов LQR теряется в канале. Ppp делает вывод,
|
||
что канал плох, и разрывает соединение. В FreeBSD до версии 2.2.5
|
||
LQR было включено по умолчанию. Сейчас оно по умолчанию выключено.
|
||
LQR можно выключить строкой
|
||
|
||
<verb>
|
||
disable lqr
|
||
</verb>
|
||
|
||
<sect2>
|
||
<heading>
|
||
Соединение разрывается в случайные промежутки времени
|
||
</heading>
|
||
|
||
<p>Иногда, на шумной линии или даже на линии с включенным режимом
|
||
ожидания звонка, ваш модем может вешать трубку, думая (совершенно
|
||
напрасно), что потерял несущую.
|
||
|
||
<p>В большинстве содемов есть параметр, определяющий чувствительность
|
||
к временной потере несущей. Например, в модеме USR Sportster,
|
||
это определяется значением регистра S10 в десятых долях секунды.
|
||
Чтобы сделать связь более устойчивой, добавьте следующую
|
||
последовательность посылок-ожиданий в строку набора:
|
||
|
||
<verb>
|
||
set dial "...... ATS10=10 OK ......"
|
||
</verb>
|
||
|
||
<p>Обратитесь к руководству по вашему модему.
|
||
|
||
<sect2>
|
||
<heading>
|
||
Ничего не происходит после сообщения Login OK!
|
||
</heading>
|
||
|
||
<p>До версии FreeBSD 2.2.5, как только связь устанавливалась,
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
|
||
name="ppp"> ожидал начала согласования Line Control Protocol
|
||
(LCP) с противоположной стороны. Многие провайдеры Internet не
|
||
начинают согласования и предполагают, что это сделает клиент.
|
||
Чтобы заставить <bf/ppp/ инициировать согласование параметров
|
||
LCP, используйте следующую строку:
|
||
|
||
<verb>
|
||
set openmode active
|
||
</verb>
|
||
|
||
<p><bf/Замечание/: Ничего страшного не произойдёт, если согласование
|
||
начнут обе стороны, поэтому режим инициирования сейчас
|
||
по умолчанию активный. Однако, в следующем разделе описывается
|
||
ситуация, когда это <bf/приводит/ к некоторым неприятностям.
|
||
|
||
<sect2>
|
||
<heading>
|
||
В протоколе есть сообщения о том, что 'magic being the same'.
|
||
</heading>
|
||
|
||
<p>Иногда, сразу же после установления соединения, вы можете увидеть
|
||
сообщения в протоколе, говорящие что "magic is the same". Иногда
|
||
эти сообщения проходят безболезненно, а иногда одна из сторон
|
||
прекращают работу. Большинство реализаций ppp не может справиться с
|
||
такой ситуацией, и, даже когда связь выглядит установившейся, вы
|
||
будете видеть только бесконечно повторяющиеся конфигурационные
|
||
запросы и подтверждения в файле протокола до тех пор, пока ppp
|
||
окончательно не закроет соединение.
|
||
|
||
<p>Обычно это происходит на серверах с медленными дисками, на
|
||
которых порт обслуживает программа getty, а ppp выполняется из
|
||
сценария регистрации или другой программы после регистрации
|
||
пользователя. Были сообшения, что такое случается постоянно при
|
||
использовании slirp. Причина заключается в том, что во время,
|
||
проходящее между завершением работы getty и запуском ppp, ppp
|
||
со стороны клиента начинает посылать пакеты Line Control Protocol
|
||
(LCP). Так как режим эха остаётся всё ещё включенным, ppp клиента
|
||
получает "отражения" своих запросов.
|
||
|
||
<p>Частью процесса согласования параметров LCP является определение
|
||
"магического" числа для каждой стороны соединения для обнаружения
|
||
"отражений". Согласно спецификации, когда одна сторона пытается
|
||
использовать совпадающее "магическое" число, должен быть послан ответ
|
||
NAK и должно быть выбрано новое "магическое" число. В тот момент,
|
||
когда на порту сервера включен режим эха, клиент ppp посылает пакеты
|
||
LCP, получает то же самое "магическое" число в отражённом пакете и
|
||
отвечает на него NAK. Он также видит отражённый NAK (который также
|
||
означает, что ppp должен изменить своё "магическое" число). В
|
||
потенциале это может вызвать появление огромного количества процессов
|
||
смен "магических" чисел, и все они накапливаются в буфере терминала.
|
||
Как только запустится сервер ppp, он будет перегружен запросами на
|
||
смену "магических", немедленно решит, что этого много для согласования
|
||
LCP и прервёт соединение. В то же самое время, клиент, который больше
|
||
не видит отражений, останавливается для того, чтобы увидеть, что
|
||
сервер закрыл соединеие.
|
||
|
||
<p>Этого можно избежать, позволив начинать согласование
|
||
противоположной стороне следующей строкой в файле ppp.conf:
|
||
|
||
<verb>
|
||
set openmode passive
|
||
</verb>
|
||
|
||
<p>Это заставит ppp ожидать начала согласования LCP. Некоторые
|
||
серверы, однако, могут никогда не начать согласование. Если это тот
|
||
самый случай, вы можете сделать следующее:
|
||
|
||
<verb>
|
||
set openmode active 3
|
||
</verb>
|
||
|
||
<p>Это заставит ppp пассивно ждать 3 секунды, и только затем посылать
|
||
запросы LCP. Если противоположная сторона начнёт посылать в этот
|
||
момент запросы, ppp немедленно ответит, не ожидая истечения
|
||
трёхсекундного интервала.
|
||
|
||
<sect2>
|
||
<heading>
|
||
Согласование LCP продолжается, пока не закроется соединение
|
||
</heading>
|
||
|
||
<p>В настоящий момент одной из неприятных особенностей
|
||
реализации <bf/ppp/ является то, что она не связывает сообщения
|
||
LCP, CCP & IPCP с запросами. Как результат, если реализация
|
||
<bf/ppp/ с одной стороны более чем на 6 секунд медленнее, чем с
|
||
другой, противоположная сторона будет посылать два дополнительных
|
||
запроса на согласование параметров LCP. Это фатально.
|
||
|
||
Предположим, что у нас работают две реализации, <bf/A/ и <bf/B/.
|
||
<bf/A/ начинает посылать запросы LCP сразу же после соединения, а
|
||
<bf/B/ требуется 7 секунд для запуска. Когда <bf/B/ запускается,
|
||
<bf/A/ послало 3 LCP-запроса. Полагаем, что режим эха выключен,
|
||
в противном случае мы столкнулись бы с проблемами "магического"
|
||
числа, описанные в предыдущем разделе. <bf/B/ посылает REQ, затем
|
||
ACK на первый REQ от <bf/A/. Это приводит к тому, что <bf/A/ входит
|
||
в состояние <bf/OPENED/ и посылает (первый) ACK обратно <bf/B/. В
|
||
то же самое время <bf/B/ посылает обратно ещё два ACK в ответ на
|
||
два дополнительных REQ, посланные <bf/A/ до старта <bf/B/. <bf/B/
|
||
затем получает первый ACK от <bf/A/ и возвращается в состояние
|
||
<bf/REQ-SENT/, послав ещё один (четвёртый) REQ согласно RFC. Затем
|
||
он получает третий ACK и входит в состояние <bf/OPENED/. В то же
|
||
время <bf/B/ принимает четвёртый REQ от <bf/A/, что возвращает
|
||
его в состояние <bf/ACK-SENT/ и посылает ещё один (второй) REQ
|
||
и (четвёртый) ACK согласно RFC. <bf/A/ получает REQ, переходит
|
||
в состояние <bf/REQ-SENT/ и посылает ещё один REQ. Он немедленно
|
||
принимает последующий ACK и входит в состояние <bf/OPENED/.
|
||
|
||
<p>Это будет продолжаться до тех пор, пока одна из сторон не
|
||
обнаружит, что это ни к чему не приводит и не закроет соединение.
|
||
|
||
<p>Лучшим способом избежать этой ситуации является конфигурация
|
||
одной из сторон как <bf/passive/, чтобы она ждала другую для
|
||
начала согласования. Это можно сделать командой
|
||
|
||
<verb>
|
||
set openmode passive
|
||
</verb>
|
||
|
||
С этой командой нужно быть осторожным. Вы также должны будете
|
||
использовать команду
|
||
|
||
<verb>
|
||
set stopped N
|
||
</verb>
|
||
|
||
для ограничения периода ожидания, в течении которого <bf/ppp/ ждёт
|
||
начала согласования с противоположной стороны. Как вариант, может
|
||
быть использована строка
|
||
|
||
<verb>
|
||
set openmode active N
|
||
</verb>
|
||
|
||
(где <bf/N/ - период ожидания в секундах перед тем, как начать
|
||
согласование).
|
||
|
||
<sect2>
|
||
<heading>Вскоре после соединения ppp блокируется</heading>
|
||
|
||
<p>В версиях FreeBSD ранее 2.2.5, была возможна ситуация,
|
||
когда связь выключалась очень скоро после соединения из-за
|
||
некорректной обработки запроса на согласования сжатия данных
|
||
<bf/ppp/. Это случалось, когда обе стороны пытались установить
|
||
разные типы CCP (Compression Control Protocol). Эта проблема
|
||
сейчас решена, но если вы всё ещё используете старую версию
|
||
<bf/ppp/, проблема может быть обойдена с помощью строки
|
||
|
||
<verb>
|
||
disable pred1
|
||
</verb>
|
||
|
||
<sect2>
|
||
<heading>
|
||
Когда я выполняю команду shell для тестирования соединения,
|
||
ppp блокируется
|
||
</heading>
|
||
|
||
<p>Когда вы выполняете команду <tt/shell/ или <tt/!/, <bf/ppp/
|
||
запускает оболочку (если были заданы параметры, <bf/ppp/ их
|
||
использует). Ppp будет ждать окончания выполнения команды, прежде
|
||
чем продолжить. Если вы попытаетесь воспользоваться связью ppp
|
||
после запуска команды, связь будет выглядеть заблокированной. Это
|
||
происходит из-за того, что <bf/ppp/ ждёт завершения выполнения
|
||
запущенной команды.
|
||
|
||
<p>Если вам необходимо выполнять подобные команды, используйте
|
||
команду <tt/!bg/. В этом случае нужная команда будет выполняться
|
||
в фоновом режиме, а ppp сможет продолжить обслуживание канала связи.
|
||
|
||
<sect2>
|
||
<heading>
|
||
Ppp, обслуживающее нуль-модем, никогда не закрывается
|
||
</heading>
|
||
|
||
<p><bf/Ppp/ не может определить, что соединение было закрыто.
|
||
Это происходит из-за метода использования сигнальных линий
|
||
нуль-модемного кабеля. При использовании такого типа соединения
|
||
всегда включайте LQR.
|
||
|
||
<verb>
|
||
enable lqr
|
||
</verb>
|
||
|
||
<p>По умолчанию LQR включается, если это было затребовано с
|
||
противоположной стороны на этапе согласования параметров соединения.
|
||
|
||
<sect2>
|
||
<heading>В режиме -auto ppp неожиданно начинает звонить</heading>
|
||
|
||
<p>Если <bf/ppp/ начинает неожиданно звонить, вы должны определить
|
||
причину и задать фильтры dfilters для предотвращения подобных
|
||
звонков.
|
||
|
||
<p>Для выяснения причины такого поведения, используйте строку:
|
||
|
||
<verb>
|
||
set log +tcp/ip
|
||
</verb>
|
||
|
||
<p>Это включит протоколирование всего трафика через соединение. В
|
||
следующий раз, когда неожиданно будет установлено соединение,
|
||
вы установите причину по временным отметкам в файле протокола.
|
||
|
||
<p>После этого вы можете запретить дозвонку при выясненных
|
||
условиях. Как правило, такие проблемы возникают из-за обращений
|
||
к DNS. Для предотвращения обращений к DNS и установления соединения
|
||
(что <bf/не/ запретит <bf/ppp/ пропускать пакеты через уже
|
||
установленное соединение), используйте такую комбинацию:
|
||
|
||
<verb>
|
||
set dfilter 1 deny udp src eq 53
|
||
set dfilter 2 deny udp dst eq 53
|
||
set dfilter 3 permit 0/0 0/0
|
||
</verb>
|
||
|
||
<p>Это может вам не подойти, так как закроет возможность дозвонки
|
||
по запросу - большинству программ нужно обратиться к DNS до того,
|
||
как начать работать.
|
||
|
||
<p>В случае DNS, вы должны попытаться определить, кто пытается
|
||
определить имя хоста. В большистве случаев виновным оказывается
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
|
||
name="sendmail">. Удостоверьтесь, что вы указали программе sendmail
|
||
не осуществлять обращений к DNS в его конфигурационном файле.
|
||
Обратитесь к разделу о <ref id="ispmail" name="настройке почты">
|
||
за подробным описанием создания конфигурационного файла и что туда
|
||
нужно поместить. Вам может понадобиться добавить в файл <bf/.mc/
|
||
строку:
|
||
|
||
<verb>
|
||
define(`confDELIVERY_MODE', `d')dnl
|
||
</verb>
|
||
|
||
<p>Это заставит sendmail ставить все сообщения в очередь до
|
||
тех пор, пока не будет запущена её обработка (как правило,
|
||
sendmail запускается с параметрами ``-bd -q30m'', указывающие, что
|
||
обрабатывать очередь нужно каждые 30 минут) или до тех пор, пока
|
||
не будет выполнена команда ``sendmail -q'' (может быть, из файла
|
||
ppp.linkup).
|
||
|
||
<sect2>
|
||
<heading>Что означают ошибки CCP</heading>
|
||
|
||
<p>В файле протокола появляются такие сообщения об ошибках:
|
||
|
||
<verb>
|
||
CCP: CcpSendConfigReq
|
||
CCP: Received Terminate Ack (1) state = Req-Sent (6)
|
||
</verb>
|
||
|
||
<p>Это происходит, если ppp пытается установить компрессию
|
||
типа Predictor1, а противоположная сторона не хочет устанавливать
|
||
никакой компрессии. Эти сообщения безобидны, но если вы хотите
|
||
от них избавиться, вы можете запретить компрессию Predictor1 и
|
||
у себя тоже:
|
||
|
||
<verb>
|
||
disable pred1
|
||
</verb>
|
||
|
||
<sect2>
|
||
<heading>
|
||
Ppp блокируется во время передачи файла с ошибками ввода-вывода
|
||
</heading>
|
||
|
||
<p>В FreeBSD 2.2.2 и ранее существовала ошибка в драйвере устройства
|
||
tun, которая не позволяла проходить пакетам размером, превышающим
|
||
значене MTU интерфейса. Приём пакета, большего, чем размер MTU,
|
||
приводит к ошибке ввода-вывода, который протоколируется через syslogd.
|
||
|
||
<p>Спецификация протокола ppp утверждает, что MRU, равное 1500,
|
||
должно <bf>всегда</bf> подходить как минимальное, несмотря на
|
||
согласование LCP, таким образом, если сделать MTU меньше
|
||
1500, ваш провайдер может начать передавать пакеты размером 1500,
|
||
несмотря ни на что, и вы это почувствуете - ваше соединение
|
||
заблокируется.
|
||
|
||
<p>Проблема может быть обойдена, если никогда не ставить MTU,
|
||
меньшее, чем 1500, для FreeBSD 2.2.2 и ранее.
|
||
|
||
<sect2>
|
||
<heading>
|
||
Почему ppp не протоколирует скорость соединения?
|
||
</heading>
|
||
|
||
<p>Для вывода протокола взаимодействия с модемом вам нужно
|
||
включить следующее:
|
||
|
||
<verb>
|
||
set log +connect
|
||
</verb>
|
||
|
||
<p>Это заставит <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">
|
||
протоколировать всё вплоть до последней прочтённой через "expect"
|
||
строки.
|
||
|
||
<p>Если вы хотите видеть скорость соединения и используете
|
||
PAP или CHAP (и поэтому вам не нужно определять никаких сценариев
|
||
входа через "set login" после получения строки CONNECT сценарием
|
||
дозвонки dial), вы должны указать ppp, что нужно ожидать полную
|
||
строку CONNECT, вроде следующего:
|
||
|
||
<verb>
|
||
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
|
||
</verb>
|
||
|
||
<p>Здесь мы получили строку CONNECT, ничего не посылаем, затем
|
||
ожидаем символа перевода строки, заставляя <bf/ppp/ принять
|
||
полный ответ модема.
|
||
|
||
<sect2>
|
||
<heading>Ppp игнорирует символ `\' в chat-скрипте</heading>
|
||
|
||
<p>Ppp выполняет каждую строку в ваших конфигурационных файлах, так
|
||
что она может проинтерпретировать строку вида
|
||
<tt/set phone "123 456 789"/ правильно (и обнаружить. что номер
|
||
является на самом деле <bf/единственным/ аргументом. Для того, чтобы
|
||
указать символ ``"'', вы должны экранировать его символом обратного
|
||
слэша (``\'').
|
||
|
||
<p>Когда интерпретатор chat обрабатывает каждую строку, он
|
||
ещё раз просматривает аргумент для того, чтобы найти какую-либо
|
||
специальную последовательность типа ``\P'' or ``\T'' (обратитесь с
|
||
справочнику). В результате из-за этой двойной интерпретации вы
|
||
должны всегда использовать правильное число символов экранирования.
|
||
|
||
<p>Если вам нужно передать символ ``\'', например, вашему модему,
|
||
вам необходимо указать что-то типа:
|
||
|
||
<verb>
|
||
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
|
||
</verb>
|
||
|
||
<p>что приведёт к такой последовательности:
|
||
|
||
<verb>
|
||
ATZ
|
||
OK
|
||
AT\X
|
||
OK
|
||
</verb>
|
||
|
||
<p>или
|
||
|
||
<verb>
|
||
set phone 1234567
|
||
set dial "\"\" ATZ OK ATDT\\T"
|
||
</verb>
|
||
|
||
<p>что даст такую последовательность:
|
||
|
||
<verb>
|
||
ATZ
|
||
OK
|
||
ATDT1234567
|
||
</verb>
|
||
|
||
<sect2>
|
||
<heading>
|
||
Ppp получает ошибку защиты, но я не вижу файла <tt/ppp.core/
|
||
</heading>
|
||
|
||
<p>Ppp (или любая другая программа такого рода) никогда не
|
||
создаёт файлов дампа памяти. Так так ppp запускается с
|
||
эффективным uid, равным 0, то операционная система не будет
|
||
записывать дамп памяти ppp на диск перед его завершением. Если,
|
||
однако ppp <bf/всё же/ прекратит работу из-за нарушения защиты,
|
||
или по другому сигналу, который вызывает создание дампа памяти,
|
||
<bf/и/ вы уверены, что используете самую последнюю версию (смотрите
|
||
самое начало раздела), то вы должны сделать следующее:
|
||
|
||
<verb>
|
||
$ tar xfz ppp-*.src.tar.gz
|
||
$ cd ppp*/ppp
|
||
$ echo STRIP= >>Makefile
|
||
$ echo CFLAGS+=-g >>Makefile
|
||
$ make clean all
|
||
$ su
|
||
# make install
|
||
# chmod 555 /usr/sbin/ppp
|
||
</verb>
|
||
|
||
<p>Теперь у вас есть отладочная версия ppp. Вам нужно
|
||
стать суперпользователем для запуска ppp, так как соответствующие
|
||
биты прав были убраны. Когда запустите ppp, обратите особое внимание
|
||
на то, какой каталог у вас был текущим на этот момент.
|
||
|
||
<p>Итак, если ppp получит ошибку нарушения защиты, он сбросит дамп
|
||
памяти с именем ppp.core. Затем вам нужно сделать следующее:
|
||
|
||
<verb>
|
||
$ su
|
||
# gdb /usr/sbin/ppp ppp.core
|
||
(gdb) bt
|
||
.....
|
||
(gdb) f 0
|
||
.....
|
||
(gdb) i args
|
||
.....
|
||
(gdb) l
|
||
.....
|
||
</verb>
|
||
|
||
<p>Вся эта информация должна быть предоставлена вместе с вашим
|
||
вопросом, чтобы проблему можно было продиагностировать.
|
||
|
||
<p>Если вы умеете обращаться с gdb, вы можете попробовать найти
|
||
причины образования дампа, а также адреса и значения относящихся
|
||
к этому переменных.
|
||
|
||
<sect2>
|
||
<heading>
|
||
Процесс, вызвавший прозвонку в режиме auto, никогда не получает
|
||
затребованного соединения
|
||
</heading>
|
||
|
||
<p>Эта проблема проявлялась, когда <bf/ppp/ в режиме auto был
|
||
настроен на динамическое согласование локального IP-адреса с
|
||
противоположной стороной. Это исправлено в последней версии -
|
||
поищите на странице справочника слово <bf/iface/.
|
||
|
||
<p>Причиной было то, что когда эта программа использует системный
|
||
вызов <htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
|
||
name="connect(2)">, для сокета назначается IP-адрес tun-интерфейса.
|
||
Ядро создаёт первый исходящий пакет и записывает его в устройство
|
||
tun. Затем <bf/ppp/ читает пакет и устанавливает соединение. Если
|
||
в результате согласования <bf/ppp/ динамического IP-адреса,
|
||
адрес интерфейса менется, сокет будет работать некорректно. Любые
|
||
IP-пакеты, передаваемые через сокет, будут отброшены. Если даже
|
||
этого не произойдёт, ответные данные не будут достигать отправителя,
|
||
так как этот адрес больше ему не принадлежит.
|
||
|
||
<p>Теоретически есть несколько способов решить эту проблему.
|
||
Лучше всего, если противоположная сторона назначит интерфейсу тот же
|
||
самый IP-адрес <tt/:-)/ Текущая версия <bf/ppp/ именно так и
|
||
поступает, более ранние реализации этого не делали.
|
||
|
||
<p>Самым простым решением будет просто никогда не менять IP-адрес
|
||
tun-интерфейса, а вместо этого изменять на лету все исходящие
|
||
пакеты так, чтобы IP-адрес источника менялся с IP-адреса интерфейса
|
||
на согласованный с противоположной стороной. Это, в сущности, то же
|
||
самое, что делает опция <tt/iface-alias/ в последней версии <bf/ppp/
|
||
(с помощью библиотеки <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?libalias" name="libalias(3)">
|
||
и ключа <bf/-alias/ для ppp) - она отслеживает все назначенные
|
||
ранее интерфейсу адреса и замещает их на последний из назначенных.
|
||
|
||
<p>Другой возможный (и наверное, самый надёжный) способ - это
|
||
создать системный вызов, меняющий IP-адреса всем уже связанным
|
||
сокетам. <bf/Ppp/ использовал бы этот вызов для модификации сокетов
|
||
всех работающих программ после согласования нового IP-адреса. Этот
|
||
же самый системный вызов могли бы использовать клиенты DHCP, когда
|
||
они осуществляют повторную привязку к сокету.
|
||
|
||
<p>Ещё одной возможностью является резрешение интерфейсу становиться
|
||
активным без IP-адреса. Исходящим пакетам будет даваться IP адрес
|
||
255.255.255.255 до тех пор, пока не будет дан ioctl-запрос SIOCAIFADDR.
|
||
приводящий к полной привязке сокета. <bf/Ppp/ нужно будет изменять
|
||
IP-адрес источника и контрольную сумму пакета, только если он
|
||
установлен в 255.255.255.255. Это, однако, является некоторым
|
||
хаком, так как ядро будет посылать некорректные пакеты на не полностью
|
||
сконфигурированный интрерфейс, в предположении, что существует
|
||
механизм исправления этих пакетов.
|
||
|
||
<sect2>
|
||
<heading>
|
||
Почему большинство игр не работает с опцией -alias?
|
||
</heading>
|
||
|
||
<p>Причиной, по которой игры и подобные программы не работают
|
||
с библиотекой libalias заключается в том, что внешняя машина будет
|
||
пытаться открыть соединение или посылать (нежданные) UDP пакеты на
|
||
машину внутренней сети. Программное обеспечение, обеспечивающее
|
||
опцию -alias, не знает о том, что должна посылать эти пакеты машине
|
||
внутренней сети.
|
||
|
||
<p>Чтобы это всё же заработало, удостоверьтесь, что единственной
|
||
запущенной программой является программное обеспечение, с которым
|
||
вы испытываете проблемы, затем напустите tcpdump на
|
||
tun-интерфейс маршрутизатора либо включите протоколирование tcp/ip
|
||
в ppp (``set log +tcp/ip'') на маршрутизаторе.
|
||
|
||
<p>Когда вы запустите некорректно работающее программное обеспечение,
|
||
вы должны увидеть пакеты, проходящие через маршрутизатор. Когда
|
||
что-то начнёт приходить извне, оно будет отброшено (в этом-то и
|
||
проблема). Заметьте номер порта получателя этих пакетов, затем
|
||
завершите работу вашего программного обеспечения. Выполните эту
|
||
процедуру несколько раз для того, чтобы убедиться, что номер порта
|
||
постоянен. Если это так, то следующая строчка в соответствующем
|
||
разделе /etc/ppp/ppp.conf заставит программное обеспечение
|
||
функционировать нормально:
|
||
|
||
<verb>
|
||
alias port proto internalmachine:port port
|
||
</verb>
|
||
|
||
<p>Здесь ``proto'' - это ``tcp'' либо ``udp'', ``internalmachine'' -
|
||
это машина, которой вы хотите перенаправлять пакеты, и ``port'' - это
|
||
номер порта получателя пакетов.
|
||
|
||
<p>Несомненно, вы не сможете использовать программное обеспечение на
|
||
других машинах, не изменяя указанную выше команду, а также запускать
|
||
программное обеспечение на двух машинах внутри сети одновременно -
|
||
в конце концов, внешний мир видит всю вашу сеть как единственную
|
||
машину.
|
||
|
||
<p>Есои номера портов непостоянны, есть ещё три варианта:
|
||
|
||
<p><bf>1)</bf> Настройте поддержку этого в libalias. Примеры
|
||
``особых случаев'' можно найти в /usr/src/lib/libalias/alias_*.c
|
||
(alias_ftp.c - хорошее начало). Это означает, что вам нужно будет
|
||
использовать чтение некоторых распознаваемых исходящих пакетов,
|
||
обнаруживать команды для установления внешней машиной обратной связи
|
||
на внутреннюю машину на конкретный (случайный) порт и настраивать
|
||
``маршрут'' в таблице соответствий так, чтобы последующие пакеты
|
||
проходили нормально.
|
||
|
||
<p>Это самое трудоёмкое решение, но оно наилучшее и позволит
|
||
программному обеспечению работать на нескольких машинах.
|
||
|
||
<p><bf>2)</bf> Используйте прокси. Приложение может поддерживать,
|
||
например, socks5 или (как в случае ``cvsup'') может иметь
|
||
режим ``passive'', обходящийся без запросов к противоположной
|
||
стороне на открытие обратного соединения.
|
||
|
||
<p><bf>3)</bf> Переназначьте всё на внутреннюю машину с помощью
|
||
команды ``alias addr''. Это решение в лоб.
|
||
|
||
<sect2>
|
||
<heading>Что такое ошибки FCS?</heading>
|
||
|
||
<p>FCS является сокращением от <bf/F/rame <bf/C/heck <bf/S/equence
|
||
(контроль последовательности кадров). Каждый кадр ppp имеет
|
||
контрольную сумму для проверки того, что принятые данные совпадают
|
||
с переданными. Если FCS принятого пакета некорректна, пакет
|
||
отбрасывается и счётчик FCS для HDLC увеличиваетя. Значения ошибок
|
||
уровня HDLC можно вывести командой <tt>show hdlc</tt>.
|
||
|
||
<p>Если у вас плохая линия (или драйвер коммуникационного адаптера
|
||
отбрасывает пакеты), ошибки FCS неизбежны. Это обычно не является
|
||
причиной для волнений, хотя это существенно замедляет протоколы
|
||
компрессии. Если у вас внешний модем, проверьте качество
|
||
экранирования соединительного кабеля - это может избавить от
|
||
проблемы.
|
||
|
||
<p>Если ваша связь замирает, как только вы соединились и
|
||
наблюдается большое количество ошибок FCS, это может быть вызвано
|
||
не полной прозрачностью канала для 8-битовых данных. Проверьте, что
|
||
модем не использует программного управоения потоком, используйте
|
||
команду <tt>set accmap 0x000a0000</tt> для указания <bf>ppp</bf>
|
||
экранировать символы ^Q и ^S.
|
||
|
||
<p>Другой причиной слишком большого количества ошибок FCS может
|
||
быть прекращение противоположной стороной сеанса <bf/PPP/.
|
||
В этом случае Вам может понадобиться включить протоколирование
|
||
<tt/async/ для проверки того, не являются ли поступаемые из линии
|
||
данные на самом деле приглашениями login или shell. Если вы
|
||
получили приглашение shell с противоположной стороны, возможно
|
||
завершение ppp без обрыва связи командой <tt>close lcp</tt>
|
||
(последующая команда <tt>term</tt> снова вернёт вас к приглашению
|
||
shell на удалённой машине).
|
||
|
||
<p>Если ничего в файле протокола не говорит о том, что связь
|
||
была прервана, вы должны спросить у администратора удалённой
|
||
машины (вашего провайдера), почему сеанс был закрыт.
|
||
|
||
<sect2>
|
||
<heading>Ничего не помогает - я уже отчаялся!</heading>
|
||
|
||
<p>Если всё уже перепробовано, и ничего не получается, пошлите нам
|
||
максимальное количество информации, ваш конфигурационный файл,
|
||
способ запуска <bf/ppp/, соответствующие части файла протокола, и
|
||
вывод команды <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?netstat" name="netstat -rn">
|
||
(до и после соединения) в адрес списка рассылки
|
||
<url url="mailto:freebsd-questions@FreeBSD.org"
|
||
name="freebsd-questions@FreeBSD.org"> или в телеконференцию
|
||
<url url="news:comp.unix.bsd.freebsd.misc"
|
||
name="comp.unix.bsd.freebsd.misc">, и может быть, кто-нибудь
|
||
укажет вам верное направление.
|
||
|
||
<sect1>
|
||
<heading>Не могу создать устройство <tt>/dev/ed0</tt>!</heading>
|
||
|
||
<p>В стандарте сетевого взаимодействия Беркли сетевые интерфейсы
|
||
напрямую доступны только ядру. За дополнительной информацией
|
||
обратитесь к файлу <tt>/etc/rc.network</tt> и страницам справочника,
|
||
описывающим различные сетевые программы, упоминаемые здесь. Если всё
|
||
это оставит вас в недоумении, почитайте книгу, описывающую
|
||
администрирование сети в другой BSD-подобной операционной системе;
|
||
с некоторыми незначитальными исключениями, администрирование сети
|
||
во FreeBSD в основном совпадает с SunOS 4.0 и Ultrix.
|
||
|
||
<sect1>
|
||
<heading>Как настроить алиас на Ethernet?</heading>
|
||
|
||
<p>Добавьте ``<tt/netmask 0xffffffff/'' в командной строке <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?ifconfig" name="ifconfig">
|
||
так, как это сделано здесь:
|
||
|
||
<verb>
|
||
ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
|
||
</verb>
|
||
|
||
<sect1>
|
||
<heading>
|
||
Как заставить адаптер 3C503 использовать другой тип сетевого разъёма?
|
||
</heading>
|
||
|
||
<p>Если вы хотите задействовать другой разъём, то должны указать
|
||
дополнительный параметр в командной строке
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig"
|
||
name="ifconfig">. Разъёмом по умолчанию является ``<tt/link0/''.
|
||
Чтобы задействовать разъём AUI, а не BNC, используйте ``<tt/link2/''.
|
||
Эти флаги должны быть указаны с помощью переменных ifconfig_*
|
||
в <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">.
|
||
|
||
<sect1>
|
||
<heading>У меня проблемы при работе NFS во FreeBSD.</heading>
|
||
|
||
<p>Некоторые сетевые адаптеры работают (мягко говоря) хуже, чем другие
|
||
что может иногда вызывать проблемы при работе приложений типа NFS,
|
||
интенсивно использующих сеть.
|
||
|
||
<p>Подробности описаны в <url url="../handbook/nfs.html"
|
||
name="соответствующей главе"> Руководства, посвящённой NFS.
|
||
|
||
<sect1>
|
||
<heading>Почему я не могу смонтировать диск Linux по NFS?</heading>
|
||
|
||
<p>Некоторые версии NFS для Linux поддерживают запросы на монтирование
|
||
только с привилегированного порта; попробуйте
|
||
|
||
<verb>
|
||
mount -o -P linuxbox:/blah /mnt
|
||
</verb>
|
||
|
||
<sect1>
|
||
<heading>Почему я не могу смонтировать диск Sun по NFS?</heading>
|
||
|
||
<p>Рабочие станции Sun под управлением SunOS 4.X поддерживают запросы
|
||
на монтирование только с привилегированного порта; попробуйте
|
||
|
||
<verb>
|
||
mount -o -P sunbox:/blah /mnt
|
||
</verb>
|
||
|
||
<sect1>
|
||
<heading>Проблемы при связи по PPP с машинами NeXTStep.</heading>
|
||
|
||
<p>Попробуйте отменить все расширения TCP в <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">,
|
||
изменив значение следующей переменной в NO:
|
||
|
||
<verb>
|
||
tcp_extensions=NO
|
||
</verb>
|
||
|
||
<p>Маршрутизаторы Annex фирмы Xylogic не работают по этой же причине,
|
||
поэтому при подключении к ним вам нужно проделать то же самое.
|
||
|
||
<sect1>
|
||
<heading>Как включить поддержку multicast IP?</heading>
|
||
|
||
<p>Работа с многоадресной рассылкой по умолчанию полностью
|
||
поддерживается версиями FreeBSD 2.0 и выше. Если вы хотите использовать
|
||
ваш компьютер как маршрутизатор многоадресного трафика, вам нужно
|
||
перекомпилировать ядро с включенной опцией <tt>MROUTING</tt> и
|
||
запустить <tt/mrouted/. Версии FreeBSD 2.2 и выше будут запускать
|
||
<tt/mrouted/ во время загрузки, если переменная <tt/mrouted_enable/
|
||
в файле <tt>/etc/rc.conf</tt> установлена в значение "YES".
|
||
|
||
<p>Приложения MBONE находятся в своей категории портов, mbone. Если
|
||
вы ищете приложения для организации конференций <tt/vic/ и <tt/vat/,
|
||
посмотрите там!
|
||
|
||
<p>Более подробная информация располагается на сервере
|
||
<url url="http://www.mbone.com/" name="Mbone Information Web">.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Какие сетевые адаптеры сделаны на наборе микросхем DEC PCI?
|
||
</heading>
|
||
|
||
<p>Вот список, составленный <url url="mailto:gfoster@driver.nsta.org"
|
||
name="Гленом Фостером"> (Glen Foster), с некоторыми незначительными
|
||
добавлениями:
|
||
|
||
<verb>
|
||
Производитель Модель
|
||
----------------------------------------------
|
||
ASUS PCI-L101-TB
|
||
Accton ENI1203
|
||
Cogent EM960PCI
|
||
Compex ENET32-PCI
|
||
D-Link DE-530
|
||
Dayna DP1203, DP2100
|
||
DEC DE435
|
||
Danpex EN-9400P3
|
||
JCIS Condor JC1260
|
||
Linksys EtherPCI
|
||
Mylex LNP101
|
||
SMC EtherPower 10/100 (Model 9332)
|
||
SMC EtherPower (Model 8432)
|
||
TopWare TE-3500P
|
||
Zynx ZX342
|
||
</verb>
|
||
|
||
<sect1>
|
||
<heading>
|
||
Почему я должен использовать FQDN для хостов не в моей сети?
|
||
</heading>
|
||
|
||
<p>Вы, наверное, обнаружили, что хост, к которому вы обратились,
|
||
оказался на самом деле в другом домене; например, если вы находитесь
|
||
в домене foo.bar.edu и хотите обраттиться к хосту ``mumble'' в домене
|
||
bar.edu, то должны указать его полное доменное имя, ``mumble.bar.edu'',
|
||
а не просто ``mumble''.
|
||
|
||
<p>Традиционно, это позволял делать ресолвер BSD BIND. Однако текущая
|
||
версия <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?named" name="bind">,
|
||
поставляемая с FreeBSD, больше не добавляет имена доменов,
|
||
отличающихся от того, в котором вы находитесь, для не полностью
|
||
указанных имён хостов. Так что неполно указанный хост <tt>mumble</tt>
|
||
будет найден либо как <tt>mumble.foo.bar.edu</tt>, либо будет искаться
|
||
в корневом домене.
|
||
|
||
<p>Это отличается от предыдущего поведения, при котором поиск
|
||
продолжался в <tt>mumble.bar.edu</tt>, и <tt>mumble.edu</tt>.
|
||
Посмотрите RFC 1535 о причинах объявления такого поведения плохой
|
||
практикой и даже ошибкой в безопасности.
|
||
|
||
<p>Как хорошее решение, вы можете поместить строку
|
||
|
||
<verb>
|
||
search foo.bar.edu bar.edu
|
||
</verb>
|
||
|
||
<p>вместо ранее используемой
|
||
|
||
<verb>
|
||
domain foo.bar.edu
|
||
</verb>
|
||
|
||
<p>в файл <htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"
|
||
name="/etc/resolv.conf">. Однако удостоверьтесь, что порядок поиска не
|
||
нарушает ``границ полномочий между местным и внешним
|
||
администрированием'', как это названо в RFC 1535.
|
||
|
||
<sect1>
|
||
<heading>``Permission denied'' для любых действий в сети.</heading>
|
||
|
||
<p>Если вы компилировали ядро с опцией <tt/IPFIREWALL/, имейте в
|
||
виду, что политика по умолчанию настроена как в 2.1.7R (она
|
||
на самом деле изменилась во время разработки 2.1-STABLE), то есть
|
||
указан запрет на прохождение всех пакетов, которые явно не разрешены.
|
||
|
||
<p>Если вы случайно неверно отконфигурировали брандмауэр, то для
|
||
восстановления работоспособность сети дайте такую команду, войдя
|
||
суперпользователем:
|
||
|
||
<verb>
|
||
ipfw add 65534 allow all from any to any
|
||
</verb>
|
||
|
||
<p>Также вы можете установить "firewall_type='open'" в файле
|
||
<tt>/etc/rc.conf</tt>.
|
||
|
||
<p>Более подробная информация о конфигурировании брандмауэра в
|
||
FreeBSD находится в <url url="../handbook/firewalls.html"
|
||
name="соответствующем разделе"> Руководства.
|
||
|
||
<sect1>
|
||
<heading>Какую нагрузку вызывает использование IPFW?</heading>
|
||
|
||
<p>Ответ на этот вопрос зависит главным образом от набора правил
|
||
и производительности процессора. Для большинства приложений, имеющих
|
||
дело с ethernet и простым набором правил, ответ: незначительно. Для
|
||
тех, кому нужны реальные цифры для удовлетвореия любопытства,
|
||
читайте дальше.
|
||
|
||
<p>Следующие измерения были сделаны с использованием 2.2.5-STABLE на
|
||
машине 486-66. IPFW был модифицирован для измерения времени,
|
||
затрачиваемого внутри процедуры <tt/ip_fw_chk/ и вывода результатов
|
||
на консоль каждую тысячу пакетов.
|
||
|
||
<p>Тестировались два набора по 1000 правил в каждом. Первый набор
|
||
был предназначен для демонстрации наихудшего случая, повторяя условие
|
||
|
||
<verb>
|
||
ipfw add deny tcp from any to any 55555
|
||
</verb>
|
||
|
||
<p>Это наихудший случай, так как все условия IPFW будут проверены
|
||
перед тем, как будет принято окончательное решение о том, что пакет
|
||
не соответствует условию (мы меняли номер порта). После 999
|
||
повторений этого условия находилось правило
|
||
<tt>allow ip from any to any</tt>.
|
||
|
||
<p>Второй набор был предназначен для быстрого прерывания
|
||
процесса проверки условий:
|
||
|
||
<verb>
|
||
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
|
||
</verb>
|
||
|
||
<p>Неподходяший IP-адрес источника для указанного условия
|
||
быстро вызывает пропуск этого правила. Как и ранее, последним правилом
|
||
было <tt>allow ip from any to any</tt>.
|
||
|
||
<p>Затраты на обработку пакета в первом случае было примерно 2.703
|
||
мс/пакет, или примерно 2.7 микросекунд на правило. Таким образом,
|
||
теоретический предел скорости обработки пакетов с этими правилами
|
||
равен примерно 370 пакетам в секунду. Предполагая использование
|
||
ethernet 10Мб/с с размером пакета примерно 1500, мы можем достигнуть
|
||
только 55.5% использования пропускной способности.
|
||
|
||
<p>В последнем случае на обработку каждого пакета было затрачено
|
||
примерно 1.172мс, или около 1.2 микросекунд на правило. Теоретический
|
||
предел обработки будет равен около 853 пакетам в секунду, что почти
|
||
соответствует скорости 10Мб/с ethernet.
|
||
|
||
<p>Большое количество протестированных правил и природа этих правил
|
||
не даёт представление о реальной жизни - они были использованы
|
||
только для генерации информации о времени обработки. Вот
|
||
несколько наблюдений, которые нужно иметь в виду для построении
|
||
эффективного набора правил:
|
||
|
||
<itemize>
|
||
|
||
<item>Поместите правило `established' в самое начало списка для
|
||
обработки основного трафика TCP. Не помещайте перед ним никаких
|
||
правил <tt>allow tcp</tt>.
|
||
|
||
<item>Старайтесь помещать часто вызываемые правила как можно раньше,
|
||
а редко используемые - позже (<bf>без изменения политики</bf>,
|
||
конечно). Вы можете выяснить частоту использования правил с помощью
|
||
вывода статистики командой <tt>ipfw -a l</tt>.
|
||
|
||
</itemize>
|
||
|
||
<sect1>
|
||
<heading>
|
||
Как можно перенаправить запросы с одной машины на другую?
|
||
</heading>
|
||
|
||
<p>Вы можете перенаправить запрос на FTP (или другой сервис) с помощью
|
||
пакаджа 'socket', доступного в дереве портов в категории 'sysutils'.
|
||
Просто замените командную строку запуска сервиса на вызов socket,
|
||
типа:
|
||
|
||
<verb>
|
||
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
|
||
</verb>
|
||
|
||
<p>где 'ftp.foo.com' и 'ftp' являются соответственно хостом и портом
|
||
для перенаправления.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Где можно найти средства управления сетевым трафиком?
|
||
</heading>
|
||
|
||
<p>Для FreeBSD существуют два средства управления трафиком: свободно
|
||
распространяемый <url
|
||
url="http://www.csl.sony.co.jp/person/kjc/programs.html" name="ALTQ">
|
||
и коммерческий продукт Bandwidth Manager от <url
|
||
url="http://www.etinc.com" name="Emerging Technologies">.
|
||
|
||
</sect>
|