Глава 14. PPP
Пред. |  | След.

## Глава 14. PPP

14.1. Не могу заставить работать ppp. Что я делаю не так?
14.2. Ppp просто зависает, когда я его запускаю
14.3. Ppp не звонит в режиме -auto
14.4. Что означает сообщение No route to host?
14.5. Соединение разрывается через 3 минуты
14.6. Соединение разрывается при большой нагрузке
14.7. Соединение разрывается в случайные промежутки времени
14.8. Соединение часто рвётся в случайные промежутки времени
14.9. Удалённая система не отвечает
14.10. Ppp зависает
14.11. Ничего не происходит после сообщения Login OK!
14.12. В протоколе есть сообщения о том, что «magic being the same».
14.13. Согласование LCP продолжается, пока не закроется соединение
14.14. Когда я выполняю команду shell для тестирования соединения, ppp блокируется
14.15. Почему программа ppp, обслуживающая нуль-модем, никогда не закрывается?
14.16. В режиме -auto ppp неожиданно начинает звонить
14.17. Что означают ошибки CCP
14.18. Почему ppp не протоколирует скорость соединения?
14.19. Ppp игнорирует символ \ в chat-скрипте
14.20. ppp(8) получает ошибку защиты (Segmentation fault), но я не вижу файла ppp.core
14.21. Процесс, вызвавший прозвонку в режиме -auto, никогда не получает затребованного соединения
14.22. Почему большинство игр не работает с опцией -nat?
14.23. Кто-нибудь ведёт список полезных номеров портов?
14.24. Что такое ошибки FCS?
14.25. Почему при использовании на маршрутизаторе PPPoE замирают соединения в Mac OS® и Windows® 98?
14.26. Ничего не помогает — я уже отчаялся!

14.1. | Не могу заставить работать ppp. Что я делаю не так?
| Первым делом прочтите страницы справочника, посвящённые ppp(8), а также соответствующий раздел Руководства. Включите протоколирование следующей командой: set log Phase Chat Connect Carrier lcp ipcp ccp command Эта команда может быть набрана в командной строке ppp(8) или она может находиться в конфигурационном файле `/etc/ppp/ppp.conf` (начало секции `default` - лучшее для неё место. Удостоверьтесь, что файл `/etc/syslog.conf` (посмотрите справку по syslog.conf(5)) содержит указанные ниже строки и существует файл `/var/log/ppp.log`: !ppp *.* /var/log/ppp.log Теперь вы сможете найти полную информацию о происходящем в файле протокола. Не беспокойтесь, если не всё вам будет там понятно. Если вы будете пользоваться чьей-то помощью, протокол вам пригодится.
14.2. | Ppp просто зависает, когда я его запускаю
| Обычно это происходит, когда не может быть определено имя вашего хоста. Наилучший способ исправить это - удостовериться, что файл `/etc/hosts` используется вашим резолвером. Отредактируйте файл `/etc/host.conf`, поместив на первое место строчку `hosts`. Затем просто добавьте записи о вашей машине в файл `/etc/hosts`. Если у вас нет локальной сети, измените строку `localhost`: 127.0.0.1 foo.example.com foo localhost В противном случае просто добавьте ещё одну запись о вашем хосте. Обратитесь к соответствующим страницам справочника за подробным описанием. Если вы выполнили эти указания, вы сможете успешно выполнить команду `ping -c1 `hostname``.
14.3. | Ppp не звонит в режиме -auto
| Во-первых, проверьте, что у вас есть маршрут по умолчанию. Выполнив команду `netstat -rn` (посмотрите справку по netstat(1)), вы должны увидеть две строки такого вида: 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 Здесь предполагается, что вы использовали адреса, приведённые в Руководстве, Справочнике или файле `ppp.conf.sample`. Если у вас нет маршрута по умолчанию, это может быть из-за того, что вы забыли добавить строку `HISADDR` в файл ppp.conf. Другая причина отсутствия маршрута по умолчанию может крыться в том, что вы ошибочно установили маршрут по умолчанию в вашем файле `/etc/rc.conf` (посмотрите справку по rc.conf(5)), и пропустили указанную ниже строку в `ppp.conf`: delete ALL В таком случае обратитесь к соответствующему разделу Руководства.
14.4. | Что означает сообщение No route to host?
| Эта ошибка появляется из-за того, что в файле `/etc/ppp/ppp.linkup` отсутствует следующий раздел: MYADDR: delete ALL add 0 0 HISADDR Он необходим, если ваш IP адрес выделяется динамически или адрес маршрутизатора вам не известен. Если вы используете интерактивный режим, вы можете набрать следующие команды после входа в `пакетный режим` (пакетный режим идентифицируется заглавными буквами PPP в приглашении): delete ALL add 0 0 HISADDR Обратитесь к разделу PPP и динамические IP адреса Руководства за подробной информацией.
14.5. | Соединение разрывается через 3 минуты
| Таймаут для PPP по умолчанию равен 3 минутам. Это может быть изменено такой строкой: set timeout `NNN` где `NNN` - время неактивности в секундах, после которого соединение закрывается. Если `NNN` равно нулю, соединение никогда не разрывается по таймауту. Эту команду можно поместить в файл `ppp.conf` или набрать ее в интерактивном режиме. Изменение этого параметра также возможно при активном соединении, если подключиться к сокету ppp сервера с помощью программ telnet(1) или pppctl(8). Обратитесь к страницам Справочника, посвящённым ppp(8).
14.6. | Соединение разрывается при большой нагрузке
| Если у вас включен Link Quality Reporting (LQR), возможно, что слишком много пакетов LQR теряется в канале. Программа ppp(8) делает вывод, что канал плох, и разрывает соединение. В FreeBSD до версии 2.2.5 LQR было включено по умолчанию. Сейчас оно по умолчанию выключено. LQR можно выключить такой строкой: disable lqr
14.7. | Соединение разрывается в случайные промежутки времени
| Иногда, на шумной линии или даже на линии с включенным режимом ожидания звонка, ваш модем может вешать трубку, думая (совершенно напрасно), что потерял несущую. В большинстве модемов есть параметр, определяющий чувствительность к временной потере несущей. Например, в модеме U.S. Robotics® Sportster® это определяется значением регистра `S10` в десятых долях секунды. Чтобы сделать связь более устойчивой, добавьте следующую последовательность посылок-ожиданий в строку набора: set dial "...... ATS10=10 OK ......" Обратитесь к руководству по вашему модему.
14.8. | Соединение часто рвётся в случайные промежутки времени
| Многие сообщают об обрывах соединений без видимой причины. Первым делом нужно выяснить, с какой стороны соединения рвётся связь. Если вы используете внешний модем, можете просто попробовать использовать утилиту ping(8) и посмотреть, мигает ли индикатор TD при передаче данных. Если он мигает (а индикатор RD нет), проблема с той стороны. Если индикатор TD не загорается, проблема с вашей стороны. При использовании внутреннего модема вам необходимо воспользоваться командой `set server`, указав её в файле `ppp.conf`. Когда произойдёт обрыв связи, подключитесь к ppp(8) с помощью pppctl(8). Если ваше сетевое подключение неожиданно восстановится (PPP оживает при проявлении активности на диагностическом сокете) или или если вы не сможете соединиться (здесь мы полагаем, что команда `set socket` в начальный момент была выполнена успешно), то проблема имеет локальный характер. Если вы сможете подключиться, но связи всё равно нет, включите вывод отладочной информации командой `set log local async` и запустите `ping` из другого окна или терминала, чтобы проверить связь. В отладочном выводе будут показаны данные, передаваемые и получаемые из канала связи. Если данные посылаются, но не принимаются обратно, проблема с противоположной стороны. Выяснив, является эта проблема локальной или удалённой системы, вы имеете два варианта действий: Если проблема на удалённой машине, то прочтите Вопрос: 14.9. Если проблема с вашей стороны, прочтите Вопрос: 14.10.
14.9. | Удалённая система не отвечает
| Здесь вы мало что можете сделать. Большинство провайдеров отказываются оказать помощь, если вы используете ОС не от Microsoft®. Вы можете добавить команду `enable lqr` в ваш `ppp.conf`, что позволит ppp(8) отследить ошибки в удалённой системе и закрывать соединение, однако такое обнаружение достаточно медленно и поэтому не так уж полезно. Вы можете также просто не сообщать своему провайдеру, что запускаете user-PPP. Первым делом попробуйте отключить всю местную компрессию, указав в конфигурационном файле следующее: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Теперь попробуйте установить соединение ещё раз и удостовериться, что ситуация не изменилась. Если качество соединения улучшилось или проблема оказалась полностью решённой, выясните, настройка чего приводила к проблемам методом проб и ошибок. Это даст вам дополнительную защиту, когда вы будете разговаривать с вашим провайдером (хотя при этом может обнаружиться, что вы работаете не с продуктом Microsoft®). Перед тем, как звонить провайдеру, включите вывод отладочной информации, как вы это делали ранее и подождите, пока соединение снова не прервётся. Правда, для этого требуется некоторое дисковое пространство. Интерес могут представлять последние прочитанные из порта данные. Обычно это данные в формате ASCII и они могут даже содержать описание проблемы (Memory fault, Core dumped). Если ваш провайдер согласен помочь вам, нужно будет включить режим отладки с их стороны, а потом, когда связь прервётся в следующий раз, они могут сказать вам, почему возникли проблемы с их стороны. Будет хорошо, если вы пришлёте детальное описание на адрес Brian Somers `<brian@FreeBSD.org>`, или даже попросите провайдера связаться с ним напрямую.
14.10. | Ppp зависает
| Лучше всего в этом случае перекомпилировать ppp(8) с отладочной информацией, и затем использовать gdb(1) для получения стека вызовов для зависшего процесса ppp. Чтобы откомпилировать программу ppp с отладочной информацией, наберите такие команды: `#` `cd /usr/src/usr.sbin/ppp` `#` `env DEBUG_FLAGS='-g' make clean` `#` `env DEBUG_FLAGS='-g' make install` Затем следует перезапустить ppp и дождаться следующего зависания. Когда отладочная сборка ppp(8) зависнет, запустите gdb для зависшего процесса: `#` `gdb ppp `pgrep ppp`` В приглашении gdb вы можете использовать команду `bt` или `where` для получения стека вызовов. Сохраните вывод вашей сессии gdb и «отключитесь» от работающего процесса, выполнив команду `quit` в gdb. В завершение, отошлите результат сессии gdb на адрес Brian Somers `<brian@FreeBSD.org>`.
14.11. | Ничего не происходит после сообщения Login OK!
| До версии FreeBSD 2.2.5, как только связь устанавливалась, ppp(8) ожидал начала согласования Line Control Protocol (LCP) с противоположной стороны. Многие провайдеры Internet не начинают согласования и предполагают, что это сделает клиент. Чтобы заставить ppp(8) инициировать согласование параметров LCP, используйте следующую строку: set openmode active ### Примечание: Ничего страшного не произойдёт, если согласование начнут обе стороны, поэтому режим инициирования сейчас по умолчанию активный. Однако, в следующем разделе описывается ситуация, когда это приводит к некоторым неприятностям.
14.12. | В протоколе есть сообщения о том, что «magic being the same».
| Иногда, сразу же после установления соединения, вы можете увидеть в журнале сообщения Magic is the same. Иногда эти сообщения проходят безболезненно, а иногда одна из сторон прекращает работу. Большинство реализаций PPP не может справиться с такой ситуацией, и, даже когда связь выглядит установившейся, вы будете видеть только бесконечно повторяющиеся конфигурационные запросы и подтверждения в файле протокола до тех пор, пока ppp(8) окончательно не закроет соединение. Обычно это происходит на серверах с медленными дисками, на которых порт обслуживает программа getty(8), а ppp(8) выполняется из сценария регистрации или другой программы после регистрации пользователя. Были сообщения, что такое случается постоянно при использовании slirp. Причина заключается в том, что во время, проходящее между завершением работы getty(8) и запуском ppp(8), ppp(8) со стороны клиента начинает посылать пакеты Line Control Protocol (LCP). Так как режим эха остаётся всё ещё включенным, ppp(8) клиента получает «отражения» своих запросов. Частью процесса согласования параметров LCP является определение «магического» числа для каждой стороны соединения для обнаружения «отражений». Согласно спецификации, когда одна сторона пытается использовать совпадающее "магическое" число, должен быть послан ответ NAK и должно быть выбрано новое "магическое" число. В тот момент, когда на порту сервера включен режим эха, клиент ppp(8) посылает пакеты LCP, получает то же самое "магическое" число в отражённом пакете и отвечает на него NAK. Он также видит отражённый NAK (который также означает, что ppp(8) должен изменить своё "магическое" число). В потенциале это может вызвать появление огромного количества процессов смен "магических" чисел, и все они накапливаются в буфере терминала. Как только запустится сервер ppp(8), он будет перегружен запросами на смену "магических", немедленно решит, что этого много для согласования LCP и прервёт соединение. В то же самое время, клиент, который больше не видит отражений, останавливается для того, чтобы увидеть, что сервер закрыл соединение. Этого можно избежать, позволив начинать согласование противоположной стороне следующей строкой в файле `ppp.conf`: set openmode passive Это заставит ppp(8) ожидать начала согласования LCP. Некоторые серверы, однако, могут никогда не начать согласование. Если это тот самый случай, вы можете сделать следующее: set openmode active 3 Это заставит ppp(8) пассивно ждать 3 секунды, и только затем посылать запросы LCP. Если противоположная сторона начнёт посылать в этот момент запросы, ppp(8) немедленно ответит, не ожидая истечения трёхсекундного интервала.
14.13. | Согласование LCP продолжается, пока не закроется соединение
| В настоящий момент одной из неприятных особенностей реализации ppp(8) является то, что она не связывает сообщения LCP, CCP & IPCP с запросами. Как результат, если реализация PPP с одной стороны более чем на 6 секунд медленнее, чем с другой, противоположная сторона будет посылать два дополнительных запроса на согласование параметров LCP. Это фатально. Предположим, что у нас работают две реализации, на машинах `A` и `B`. `A` начинает посылать запросы LCP сразу же после соединения, а `B` требуется 7 секунд для запуска. Когда `B` запускается, `A` послало 3 LCP-запроса. Полагаем, что режим эха выключен, в противном случае мы столкнулись бы с проблемами "магического" числа, описанными в предыдущем разделе. `B` посылает REQ, затем ACK на первый REQ от `A`. Это приводит к тому, что `A` входит в состояние OPENED и посылает (первый) ACK обратно `B`. В то же самое время `B` посылает обратно ещё два ACK в ответ на два дополнительных REQ, посланные `A` до старта `B`. `B` затем получает первый ACK от `A` и возвращается в состояние REQ-SENT, послав ещё один (четвёртый) REQ согласно RFC. Затем он получает третий ACK и входит в состояние OPENED. В это же время `B` принимает четвёртый REQ от `A`, что возвращает его в состояние ACK-SENT и посылает ещё один (второй) REQ и (четвёртый) ACK согласно RFC. `A` получает REQ, переходит в состояние REQ-SENT и посылает ещё один REQ. Он немедленно принимает последующий ACK и входит в состояние OPENED. Это будет продолжаться до тех пор, пока одна из сторон не обнаружит, что это ни к чему не приводит и не закроет соединение. Лучшим способом избежать этой ситуации является конфигурация одной из сторон как `passive`, чтобы она ждала другую для начала согласования. Это можно сделать следующей командой: set openmode passive С этой командой нужно быть осторожным. Вы также должны будете использовать эту команду для ограничения периода ожидания, в течении которого ppp(8) ждёт начала согласования с противоположной стороны: set stopped `N` Как вариант, может быть использована следующая команда (где `N` - период ожидания в секундах перед тем, как начать согласование): set openmode active `N` За дополнительной информацией обращайтесь к странице Справочника.
14.14. | Когда я выполняю команду shell для тестирования соединения, ppp блокируется
| Когда вы выполняете команду `shell` или `!`, ppp(8) запускает оболочку (если были заданы параметры, ppp(8) их использует). Программа ppp будет ждать окончания выполнения команды, прежде чем продолжить. Если вы попытаетесь воспользоваться связью PPP после запуска команды, связь будет выглядеть заблокированной. Это происходит из-за того, что ppp(8) ждёт завершения выполнения запущенной команды. Если вам необходимо выполнять подобные команды, используйте команду `!bg`. В этом случае нужная команда будет выполняться в фоновом режиме, а ppp(8) сможет продолжить обслуживание канала связи.
14.15. | Почему программа ppp, обслуживающая нуль-модем, никогда не закрывается?
| ppp(8) не может определить, что соединение было закрыто. Это происходит из-за метода использования сигнальных линий нуль-модемного кабеля. При использовании такого типа соединения всегда включайте LQR: enable lqr По умолчанию LQR включается, если это было затребовано с противоположной стороны на этапе согласования параметров соединения.
14.16. | В режиме `-auto` ppp неожиданно начинает звонить
| Если ppp(8) начинает неожиданно звонить, вы должны определить причину и задать фильтры dfilters для предотвращения подобных звонков. Для выяснения причины такого поведения, используйте строку: set log +tcp/ip Это включит протоколирование всего трафика через соединение. В следующий раз, когда неожиданно будет установлено соединение, вы установите причину по временным отметкам в файле протокола. После этого вы можете запретить дозвонку при выясненных условиях. Как правило, такие проблемы возникают из-за обращений к DNS. Для предотвращения обращений к DNS и установления соединения (что не запретит ppp(8) пропускать пакеты через уже установленное соединение), используйте такую комбинацию: set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 Это может вам не подойти, так как закроет возможность дозвонки по запросу — большинству программ нужно обратиться к DNS до того, как начать работать. В случае DNS, вы должны попытаться определить, кто пытается определить имя хоста. В большинстве случаев виновным оказывается sendmail(8). Удостоверьтесь, что вы указали программе sendmail не осуществлять обращений к DNS в его конфигурационном файле. Обратитесь к разделу об использовании электронной почты при коммутируемом соединении в Руководстве за подробным описанием создания конфигурационного файла и что туда нужно поместить. Вам может понадобиться добавить в файл `.mc` строку: define(`confDELIVERY_MODE', `d')dnl Это заставит sendmail ставить все сообщения в очередь до тех пор, пока не будет запущена её обработка (как правило, sendmail запускается с параметрами `-bd -q30m`, указывающими, что обрабатывать очередь нужно каждые 30 минут) или до тех пор, пока не будет выполнена команда `sendmail `-q`` (может быть, из файла `ppp.linkup`).
14.17. | Что означают ошибки CCP
| В файле протокола появляются такие сообщения об ошибках: CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) Это происходит, если ppp(8) пытается установить компрессию типа Predictor1, а противоположная сторона не хочет устанавливать никакой компрессии. Эти сообщения безобидны, но если вы хотите от них избавиться, вы можете запретить компрессию Predictor1 и у себя тоже: disable pred1
14.18. | Почему ppp не протоколирует скорость соединения?
| Для вывода протокола взаимодействия с модемом вам нужно включить следующее: set log +connect Это заставит ppp(8) протоколировать всё, вплоть до последней прочтённой через «expect» строки. Если вы хотите видеть скорость соединения и используете PAP или CHAP (и поэтому вам не нужно определять никаких сценариев входа через `set login` после получения строки CONNECT сценарием дозвонки dial), вы должны указать ppp(8), что нужно ожидать полную строку CONNECT, вроде следующего: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Здесь мы получили строку CONNECT, ничего не посылаем, затем ожидаем символа перевода строки, заставляя ppp(8) принять полный ответ модема.
14.19. | Ppp игнорирует символ `\` в chat-скрипте
| Программа ppp обрабатывает каждую строку в ваших конфигурационных файлах, так что он может проинтерпретировать строку вида `set phone "123 456 789"` правильно и обнаружить, что номер является на самом деле единственным аргументом. Для того, чтобы указать символ `"`, вы должны экранировать его символом обратного слэша (`\`). Когда интерпретатор chat обрабатывает каждую строку, он ещё раз просматривает аргумент для того, чтобы найти какую-либо специальную последовательность типа `\P` или `\T` (обратитесь к Справочнику). В результате этой двойной интерпретации вы должны всегда использовать правильное число экранирующих символов. Если вам нужно передать символ `\`, например, вашему модему, вам необходимо указать что-то типа: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" Это приведёт к такой последовательности: ATZ OK AT\X OK Или: set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" Это даст такую последовательность: ATZ OK ATDT1234567
14.20. | ppp(8) получает ошибку защиты (Segmentation fault), но я не вижу файла `ppp.core`
| Программа ppp (или любая другая программа такого рода) никогда не создаёт файлов дампа памяти. Так так ppp(8) запускается с эффективным uid, равным `0`, то операционная система не будет записывать дамп памяти ppp(8) на диск перед его завершением. Однако если ppp(8) всё же прекратит работу из-за нарушения защиты, или по другому сигналу, который вызывает создание дампа памяти, и вы уверены, что используете самую последнюю версию (смотрите самое начало раздела), то вы должны установить исходный код системы и выполнить следующее: `#` ``cd` `/usr/src/usr.sbin/ppp`` `#` ``echo` `STRIP`= >> `/etc/make.conf`` `#` ``echo` `CFLAGS`+=`-g` >> `/etc/make.conf`` `#` ``make` `install` `clean`` Теперь у вас есть отладочная версия ppp(8). Вам нужно стать суперпользователем для запуска ppp(8), так как соответствующие биты прав были убраны. Когда запустите ppp(8), обратите особое внимание на то, какой каталог у вас был текущим на этот момент. Итак, если ppp(8) получит ошибку нарушения защиты, он сбросит дамп памяти с именем `ppp.core`. Затем вам нужно сделать следующее: `%` `su` `#` `gdb /usr/sbin/ppp ppp.core` `(gdb)` `bt` ..... `(gdb)` `f 0` .... `(gdb)` `i args` .... `(gdb)` `l` ..... Вся эта информация должна быть предоставлена вместе с вашим вопросом, чтобы проблему можно было продиагностировать. Если вы умеете обращаться с gdb(1), вы можете попробовать найти причины образования дампа либо адреса и значения относящихся к этому переменных.
14.21. | Процесс, вызвавший прозвонку в режиме `-auto`, никогда не получает затребованного соединения
| Эта проблема проявлялась, когда ppp(8) в режиме `-auto` был настроен на динамическое согласование локального IP-адреса с противоположной стороной. Это было давно исправлено — поищите на странице справочника слово `iface`. Причиной было то, что когда эта программа использует системный вызов connect(2), для сокета назначается IP-адрес интерфейса tun(4). Ядро создаёт первый исходящий пакет и записывает его в устройство tun(4). Затем ppp(8) читает пакет и устанавливает соединение. Если в результате согласования ppp(8) динамического IP-адреса адрес интерфейса изменится, сокет будет работать некорректно. Любые IP-пакеты, передаваемые через сокет, будут отброшены. Если даже этого не произойдёт, ответные данные не будут достигать отправителя, так как этот адрес больше ему не принадлежит. Теоретически есть несколько способов решить эту проблему. Лучше всего, если противоположная сторона назначит интерфейсу тот же самый IP-адрес. Текущая версия ppp(8) именно так и поступает, но большинство других реализаций этого не делают. Самым простым решением будет просто никогда не менять IP-адрес интерфейса tun(4), а вместо этого изменять на лету все исходящие пакеты так, чтобы IP-адрес источника менялся с IP-адреса интерфейса на соответствующий с противоположной стороны. Это, в сущности, то же самое, что делает опция `iface-alias` в самой последней версии ppp(8) (с помощью библиотеки libalias(3) и ключа `-nat` для ppp(8)) — она отслеживает все назначенные ранее интерфейсу адреса и замещает их на последний из назначенных. Другой возможный (и, наверное, самый надёжный) способ - это создать системный вызов, меняющий IP-адреса всем уже связанным сокетам. ppp(8) использовал бы этот вызов для модификации сокетов всех работающих программ после согласования нового IP-адреса. Этот же самый системный вызов могли бы использовать клиенты DHCP, когда они осуществляют повторную привязку к сокету, вызывая для этого функцию `bind()`. Ещё одной возможностью является разрешение интерфейсу становиться активным без IP-адреса. Исходящим пакетам будет даваться IP адрес `255.255.255.255` до первого вызова ioctl(2) `SIOCAIFADDR`, приводящего к полной привязке сокета. ppp(8) нужно будет изменять исходящий IP-адрес и контрольную сумму пакета, только если он установлен в `255.255.255.255`. Это, однако, является некоторым хаком, так как ядро будет посылать некорректные пакеты на не полностью сконфигурированный интерфейс, в предположении, что существует механизм исправления этих пакетов.
14.22. | Почему большинство игр не работает с опцией `-nat`?
| Причиной, по которой игры и подобные программы не работают с библиотекой libalias(3) заключается в том, что внешняя машина будет пытаться открыть соединение или посылать (незапрошенные) UDP пакеты на машину внутренней сети. Программное обеспечение, обеспечивающее опцию -nat, не знает о том, что она должна пересылать эти пакеты машине во внутренней сети. Чтобы это всё же заработало, удостоверьтесь, что единственной запущенной программой является программное обеспечение, с которым вы испытываете проблемы, затем запустите tcpdump(1) на интерфейсе tun(4) маршрутизатора либо включите протоколирование TCP/IP в ppp(8) (`set log +tcp/ip`) на маршрутизаторе. Когда вы запустите некорректно работающее программное обеспечение, вы должны увидеть пакеты, проходящие через маршрутизатор. Когда что-то начнёт приходить извне, оно будет отброшено (в этом-то и проблема). Заметьте номер порта получателя этих пакетов, затем завершите работу вашего программного обеспечения. Выполните эту процедуру несколько раз для того, чтобы убедиться, что номер порта постоянен. Если это так, то следующая строчка в соответствующем разделе `/etc/ppp/ppp.conf` заставит программное обеспечение функционировать нормально: nat port `proto` `internalmachine`:`port` `port` Здесь `proto` - это `tcp` либо `udp`, `internalmachine` — это машина, которой вы хотите перенаправлять пакеты, и `port` - это номер порта получателя пакетов. Несомненно, вы не сможете использовать программное обеспечение на других машинах, не изменяя указанную выше команду, а также запускать программное обеспечение на двух машинах внутри сети одновременно — в конце концов, внешний мир видит всю вашу сеть как единственную машину. Если номера портов непостоянны, есть ещё три варианта: Настройте поддержку этого в libalias(3). Примеры «особых случаев» можно найти в `/usr/src/sys/netinet/libalias/alias_*.c` (`alias_ftp.c` — хорошее начало). Обычно это подразумевает чтение определенных распознаваемых исходящих пакетов, выявление команд для установления внешней машиной обратной связи на внутреннюю машину на конкретный (случайный) порт и настройку значения «route» в таблице соответствий таким образом, чтобы последующие пакеты проходили нормально. Это самое трудоёмкое решение, но оно наилучшее и позволит программному обеспечению работать на нескольких машинах. Используйте прокси-сервер. Например, приложение может поддерживать `socks5` или (как в случае `cvsup`) может иметь режим «passive», обходящийся без запросов к противоположной стороне на открытие обратного соединения. Переназначьте всё на внутреннюю машину с помощью команды `nat addr`. Это решение в лоб.
14.23. | Кто-нибудь ведёт список полезных номеров портов?
| Пока нет, но ниже находится список, могущий таковым стать (если к этому будет проявлен какой-либо интерес). В каждом примере `internal` нужно заменить на IP-адрес машины, участвующей в игре. Asheron's Call `nat port udp `internal`:65000 65000` Находясь в игре, вручную смените номер порта на `65000`. Если у вас есть несколько машин, на которых вы хотите играть, назначьте каждой машине уникальный номер порта (то есть `65001`, `65002` и так далее), и добавьте по строчке `nat port` для каждой машины. Half Life `nat port udp `internal`:27005 27015` PCAnywhere 8.0 `nat port udp `internal`:5632 5632` `nat port tcp `internal`:5631 5631` Quake `nat port udp `internal`:6112 6112` Quake 2 `nat port udp `internal`:27901 27910` `nat port udp `internal`:60021 60021` `nat port udp `internal`:60040 60040` Red Alert `nat port udp `internal`:8675 8675` `nat port udp `internal`:5009 5009`
14.24. | Что такое ошибки FCS?
| FCS является сокращением от `F`rame `C`heck `S`equence (контроль последовательности кадров). Каждый кадр PPP имеет контрольную сумму для проверки того, что принятые данные совпадают с переданными. Если FCS принятого пакета некорректна, пакет отбрасывается и счётчик FCS для HDLC увеличивается. Значения ошибок уровня HDLC можно вывести командой `show hdlc`. Если у вас плохая линия (или драйвер коммуникационного адаптера отбрасывает пакеты), ошибки FCS неизбежны. Это обычно не является причиной для волнений, хотя это существенно замедляет протоколы компрессии. Если у вас внешний модем, проверьте качество экранирования соединительного кабеля — это может избавить от проблемы. Если ваша связь замирает, как только вы соединились, и наблюдается большое количество ошибок FCS, это может быть вызвано не полной прозрачностью канала для 8-битовых данных. Проверьте, чтобы модем не использовал программного управления потоком (XON/XOFF). Если же оборудование должно использовать программное управление потоком, то воспользуйтесь командой `set accmap 0x000a0000` для указания ppp(8) экранировать символы `^Q` и `^S`. Другой причиной слишком большого количества ошибок FCS может быть прекращение противоположной стороной сеанса PPP. В этом случае Вам может понадобиться включить протоколирование `async` для проверки того, не являются ли поступаемые из линии данные на самом деле приглашениями login или shell. Если вы получили приглашение shell с противоположной стороны, возможно завершение ppp(8) без обрыва связи командой `close lcp` (последующая команда `term` снова вернёт вас к приглашению shell на удалённой машине). Если ничего в файле протокола не говорит о том, что связь была прервана, вы должны спросить у администратора удалённой машины (вашего провайдера), почему сеанс был закрыт.
14.25. | Почему при использовании на маршрутизаторе PPPoE замирают соединения в Mac OS® и Windows® 98?
| Мы благодарим Майкла Возняка (Michael Wozniak) `<mwozniak@netcom.ca>`, который сообщил следующую информацию, и Дэна Флемминга (Dan Flemming) `<danflemming@mac.com>` за решение проблемы в случае Mac: Это происходит из-за эффекта, который можно назвать «чёрной дырой» на маршрутизаторе. Mac OS® и Windows® 98 (и, может быть, другие операционные системы от Microsoft®), посылают пакеты TCP с запрашиваемым размером сегмента, который слишком велик для того, чтобы быть помещённым в кадр PPPoE (для сети Ethernet размер MTU по умолчанию равен `1500`) и с установленным битом «do not fragment» (по умолчанию для TCP), а маршрутизаторы Telco не посылает пакет ICMP «must fragment» обратно на сайт WWW, который вы пытаетесь открыть. (Либо маршрутизатор посылает пакеты ICMP правильно, а межсетевой экран на стороне сервера WWW их сбрасывает.) Когда Web-сервер посылает вам кадры, которые не помещаются в поток PPPoE, то маршрутизаторы Telco их отбрасывают и странички не загружаются (часть страниц/графики всё же видно, потому что они меньше, чем MSS). Похоже, что такие настройки действуют по умолчанию на большинстве конфигураций PPPoE Telco. Одним из способов устранения проблемы является использование утилиты regedit на системах 95/98 для того, чтобы добавить в реестр следующий параметр: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU Это должна быть строка со значением `1436`, так как имеются сведения, что некоторые маршрутизаторы ADSL не могут работать с пакетами размером, превышающим эту величину. В Windows® 2000 этот параметр реестра переименован в `Tcpip\Parameters\Interfaces\`ID адаптера`\MTU` и имеет тип `DWORD`. Обратитесь к документам из Microsoft Knowledge Base Q158474 - Windows TCPIP Registry Entries и Q120642 - TCPIP & NBT Configuration Parameters for Windows NT® для получения более полной информации по изменению MTU в Windows® для работы с NAT-маршрутизатором. Другим вариантом с Windows® 2000 является установка в регистре `DWORD`-параметра `Tcpip\Parameters\Interfaces\`ID адаптера`\EnablePMTUBHDetect` в `1`, как это отмечено в документе Microsoft 120642, указанном выше. К несчастью, в Mac OS® нет возможности изменить настройки TCP/IP. Однако имеется множество коммерческого программного обеспечения, позволяющего пользователям настраивать параметры TCP/IP. Пользователям NAT в Mac OS® нужно поискать у себя настройки MTU и заменить там значение `1500` на `1450`. В ppp(8) имеется команда `enable tcpmssfixup`, которая автоматически выравнивает MSS до подходящего значения. Эта возможность включена по умолчанию. Если у вас возникли проблемы с более старой версией ppp(8), то вас может заинтересовать порт `net/tcpmssd`.
14.26. | Ничего не помогает — я уже отчаялся!
| Если всё уже перепробовано, и ничего не получается, пошлите нам максимальное количество информации, ваш конфигурационный файл, способ запуска ppp(8), соответствующие части файла протокола, и вывод команды `netstat -rn` (до и после соединения) в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD или в телеконференцию comp.unix.bsd.freebsd.misc, и может быть, кто-нибудь укажет вам верное направление.

Пред. |  | След.
Глава 13. Безопасность | Начало | Глава 15. Коммуникационные адаптеры

Этот, и другие документы, могут быть скачаны с http://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите в рассылку <doc@FreeBSD.org>.