<!-- $FreeBSD$ -->
<!-- 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/index.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/ppp-and-slip.html#USERPPP"
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/ppp-and-slip.html#USERPPP" 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/ppp-and-slip.html#USERPPP-FINAL"
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/ppp-and-slip.html#USERPPP-DYNAMICIP"
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>
Соединение часто рвётся в случайные промежутки времени
</heading>
<p>Многие сообщают об обрывах соединений без видимой причины. Первым
делом нужно выяснить, с какой стороны соединения рвётся связь.
<p>Если вы используете внешний модем, можете просто попробовать
использовать утилиту <tt/ping/ и посмотреть, мигает ли индикатор
<tt/TD/ при передаче данных. Если он мигает (а индикатор <tt/TD/ нет),
проблема с той стороны. Если индикатор <tt/TD/ не загорается, проблема
с вашей стороны. При использовании внутреннего модема вам необходимо
воспользоваться командой <tt/set server/, указав её в файле
<tt/ppp.conf/. Когда произойдёт обрыв связи, подключитесь к ppp с
помощью pppctl. Если ваше сетевое подключение неожиданно восстановится
(ppp оживает при проявлении активности на диагностическом сокете) или
или если вы не сможете соединиться (здесь мы полагаем, что команда
<tt/set socket/ в начальный момент была выполнена успешно), то проблема
имеет локальный характер. Если вы сможете подключиться, но связи всё
равно нет, включите вывод отладочной информации командой <tt/set log
local async/ и запустите <tt/ping/ из другого окна или терминала, чтобы
проверить связь. В отладочном выводе будут показаны данные,
передаваемые и получаемые из канала связи. Если данные посылаются,
но не принимаются обратно, проблема с противоположной стороны.
<p>Выяснив, является эта проблема локальной или удалённой системы,
вы имеете следующие возможности:
<sect3>
<heading>Удалённая система не отвечает</heading>
<p>Здесь вы мало что можете сделать. Большинство провайдеров
отказываются оказать помощь, если вы используете ОС не от Microsoft.
Вы можете добавить команду <tt/enable lqr/ в ваш <tt/ppp.conf/, что
позволит ppp отследить ошибки в удалённой системе и закрывать
соединение, однако такое обнаружение достаточно медленное и поэтому
не так уж полезно. Вы можете также просто не сообщать своему
провайдеру, что запускаете user-ppp....
<p>Первым делом попробуйте отключить всю местную компрессию,
указав в конфигурационном файле следующее:
<verb>
disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
</verb>
<p>Теперь попробуйте установить соединение ещё раз и удостовериться,
что ситуация не изменилась. Если качество соединения улучшилось
или проблема окащалась полностью решённой, выясните, настройка
чего приводила к проблемам методом проб и ошибок. Это даст вам
дополнительную защиту, когда вы будете разговаривать с вашим
провайдером (хотя при этом может обнаружиться, что вы работаете
не с продуктом Microsoft).
<p>Перед тем, как звонить провайдеру, включите вывод отладочной
информации, как вы это делали ранее и подождите, пока соединение
снова не прервётся. Правда, для этого требуется некоторое
дисковое пространство. Интерес могут представлять последние
прочитанные из порта данные. Обычно это данные в формате ascii
и они могут даже содержать описание проблемы (``Memory fault,
core dumped'' ?).
<p>Если ваш провайдер согласен помочь вам, нужно будет включить
режим отладки с их стороны, а потом, когда связь прервётся в
следующий раз, они могут сказать вам, почему возникли проблемы
с их стороны. Будет хорошо, если вы пришлёте детальное описание
на адрес <url url="mailto:brian@Awfulhak.org"
name="brian@Awfulhak.org">, или даже попросите провайдера связаться
со мной напрямую.
<sect3>
<heading>Ppp зависает</heading>
<p>Лучше всего в этом случае перекомпилировать ppp, добавив параметры
<tt/CFLAGS+=-g/ и <tt/STRIP=/ в конец Makefile, а затем выполнить
<tt/make clean && make && make install/. Когда ppp
зависнет, найдите идентификатор процесса ppp с помощью команды
<tt/ps ajxww | fgrep ppp/ и выполните команду <tt/gdb ppp PID/.
Затем в приглашении gdb вы можете использовать команду <tt/bt/ для
получения стека вызовов.
<p>Пошлите результат на адрес <url url="mailto:brian@Awfulhak.org"
name="brian@Awfulhak.org">.
<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''. Это решение в лоб.
<sect3>
<heading>
Кто-нибудь составляет список полезных номеров портов?
</heading>
<p>Пока нет, но ниже находится список, могущий таковым стать (если
к этому будет проявлен какой-либо интерес). В каждом примере
<tt>internal</tt> должно быть заменено IP адресом машины, участвующей
в игре.
<itemize>
<item><bf>Quake</bf>
<tt>alias port udp internal:6112 6112</tt>
<p>Альтернативное решение, обеспечивающее поддержку прокси
для Quake, можно найти на сервере <htmlurl
url="http://www.battle.net/support/proxy/" name="www.battle.net">.
</itemize>
<itemize>
<item><bf>Quake 2</bf>
<p><tt>alias port udp internal:27901 27910</tt>
</itemize>
<itemize>
<item><bf>Red Alert</bf>
<p><tt>alias port udp internal:8675 8675</tt>
<p><tt>alias port udp internal:5009 5009</tt>
</itemize>
<itemize>
<item><bf>Half Life</bf>
<p><tt>alias port udp internal:27005 27015</tt>
</itemize>
<itemize>
<item><bf>PCAnywhere 8.0</bf>
<p><tt>alias port udp internal:5632 5632</tt>
<p><tt>alias port tcp internal:5631 5631</tt>
</itemize>
<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, DE450
Danpex EN-9400P3
JCIS Condor JC1260
Linksys EtherPCI
Mylex LNP101
SMC EtherPower 10/100 (Model 9332)
SMC EtherPower (Model 8432)
TopWare TE-3500P
Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
(3.x) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442,
ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)
</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">.
<sect1>
<heading>
Почему появляются сообщения ``/dev/bpf0: device not configured"?
</heading>
<p>Для работы программ, использующих Berkeley Packet Filter <htmlurl
url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)"> необходимо
включение в ядро соответствующего драйвера. Перекомпилируйте ядро,
добавив в его конфигурационный файл следующую строку:
<verb>
pseudo-device bpfilter # Berkeley Packet Filter
</verb>
<p>Затем, после перезапуска системы, вам нужно создать соответствующий
файл устройства. Это можно сделать, сменив текущий каталог на
<tt>/dev</tt> и выполнив команду
<tscreen><verb>
# sh MAKEDEV bpf0
</verb></tscreen>
<p>Обратитесь к разделу руководства, посвящённому <htmlurl
url="../../handbook/kernelconfig-nodes.html"
name="созданию файлов устройств"> за подробной информацией по этому
вопросу.
</sect>
