diff options
Diffstat (limited to 'ru/FAQ/network.sgml')
| -rw-r--r-- | ru/FAQ/network.sgml | 1205 |
1 files changed, 0 insertions, 1205 deletions
diff --git a/ru/FAQ/network.sgml b/ru/FAQ/network.sgml deleted file mode 100644 index 32f9d4f547..0000000000 --- a/ru/FAQ/network.sgml +++ /dev/null @@ -1,1205 +0,0 @@ -<!-- $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> |