Если некоторое сетевое устройство работает в качестве клиента PPP, то на нём необходимо выполнить, в большинстве случаев, следующие основные настройки:

Сценарий дозвона, состоящий из команд для инициализации модема и установления физического соединения с удалённой стороной, и ожидаемых ответов на них. Записывается в виде парных последовательностей "жду" — "посылаю".

Сценарий не требуется, если устройство NSG соединяется с PPP-сервером напрямую нуль-модемным кабелем или по выделенной модемной линии.

Если используемый порт не имеет сигнала DCD и/или не поддерживает управление потоком (RTS/CTS), то следует установить дополнительные опции для pppd: local и/или nocrtscts, соответственно. В частности, это относится к портам a1, a2 устройств NSG–18xx.

Подробнее о настройке сценариев дозвона и дополнительных опций PPP в устройствах NSG см. справку по узлам chat и options.

Режим установления и разрыва соединения. Соединение может устанавливаться по требованию или поддерживаться, по возможности, постоянно; в NSG Linux это определяется параметром connection. Критериями для его разрыва может быть отсутствие полезного трафика в течение некоторого времени, или достижение максимальной продолжительности сеанса (idle-time, session-time) или отсутствие связи де-факто (параметры lcp-echo-*). Очевидно, что первые два критерия имеют смысл только в режиме соединения on-demand.

Имя и пароль для аутентификации данного устройства по протоколам PAP/CHAP на удалённом сервере. Строго говоря, аутентификация выполняется по совокупности 3 параметров: имя клиента, имя сервера и пароль. В NSG Linux они могут быть указаны двумя способами:

• В общесистемной таблице паролей (PAP или CHAP, в зависимости от того, какой из протоколов аутентификации запрашивается сервером). Обязательными являются только имя клиента и пароль. Имя сервера используется редко, поэтому обычно вместо него ставится просто звёздочка (*), означающая любое имя. В меню порта указывается только имя клиента (sent-username), которое служит ключом для поиска в таблице паролей.
• Индивидуально для данного порта в параметре sent-password. Если данный параметр присутствует, то он имеет приоритет; в противном случае производится поиск по значению sent-username в общесистемной таблице. Имя сервера и IP-адрес в данном случае не указываются, если они необходимы — следует пользоваться системной таблицей паролей. Для 2-симчатых сотовых модулей допускается ситуация, когда для одного оператора пароль указывается в порту, а для другого — ищется в системной таблице. Данный способ задания пароля применим только для клиентов PPP (и производных от него протоколов).

Для клиентской стороны соединения рекомендуется использовать второй способ.

Пароль может содержать, в т.ч., спецсимволы, имеющие особое значение в файлах pap-secrets/chap-secrets: @, #, *, пробел. Для хранения внутри устройства эти символы преобразуются в соответствующие esc-последовательности автоматически. Особыми являются символы " и \ — их необходимо вручную вводить в виде esc-последовательностей \" и \\, соответственно.

ВНИМАНИЕ! Если устройство NSG служит одновременно и в качестве клиента, и в качестве сервера по PPP или производным от него протоколам, настоятельно рекомендуется задавать имена и пароли раздельно: для клиентов — непосредственно в меню соответствующих портов, для серверов — в узле system.ppp-secrets.
Возможно также использовать секрет, состоящий не из 2, а из 3 компонент: имени клиента, имени сервера и пароля. Имя сервера в данном случае позволяет использовать каждый пароль только для той или иной задачи.
В частности, данные меры предосторожности абсолютно необходимы, если устройство подключается в качестве клиента к сотовым сетям GPRS или 3G с общеизвестными именем и паролем, и одновременно служит сервером для доступа по PPP или PPTP.

IP-адреса. Как правило, в современных сетевых решениях сервер назначает клиентам IP-адреса, а также адреса DNS. Поэтому достаточно использовать настройки по умолчанию — принимать параметры IPCP, присланные сервером.

Если адреса не назначаются автоматически, то нужно задать их вручную.

Сжатие и защита трафика. NSG Linux поддерживает алгоритмы сжатия deflate, BSD Compression (BSDC) и защиту трафика с помощью MPPE. Каждый из этих алгоритмов имеет свой набор параметров. Поскольку в корпоративных сетевых решениях программные возможности сторон, как правило, заранее известны, то рекомендуется сразу установить требуемые значения параметров вручную, одинаковым образом на обеих сторонах, чтобы исключить возможные нестыковки. При несогласованных значениях параметров (например, одна сторона требует обязательного использования MPPE, а другая задаёт аутентификацию PAP) PPP-соединение установлено не будет.

При настройке MPPE следует учитывать следующие особенности данного механизма:

1. Возможности использования MPPE связаны с выбранным протоколом аутентификации:
   • MPPE–128 может быть осуществлено при MS–CHAP или MS–CHAP v2
   • MPPE–40 может быть осуществлено только при MS–CHAP v2.
   Инициатором аутентификации при этом может быть любая сторона.
2. Если противоположной стороной соединения является компьютер под управлением продуктов компании Microsoft, то необходимо установить режим stateful. В этих продуктах он является единственно возможным для PPP и PPPoE и предпочтительным для PPTP.

Маршрутизация и NAT. Для клиента данное PPP-соединение, как правило, является единственным выходом в вышестоящую сеть (корпоративную или публичный Интернет), и поэтому оно назначается в качестве маршрута по умолчанию. Если в системе существует другой маршрут по умолчанию, например, заданный статически, то необходимо задать им различные метрики.

Что касается маршрутизации в обратную сторону, то в большинстве случаев удалённый сервер назначает клиенту единственный IP-адрес и ничего не знает о сетях, расположенных за этим клиентом. Поэтому на PPP-интерфейсе клиента необходимо включить NAT в режиме IP-masquerading. Правила NAT являются составной частью обработки IP-пакетов в рамках всего устройства, поэтому они устанавливаются, как это принято в *NIX-системах, централизованно, а не по отдельным интерфейсам. В NSG Linux это делается в узле ip.nat.POSTROUTING. Однако для удобства пользователя в узле ppp предусмотрена команда add-nat/del-nat, которая автоматически генерирует (и, соответственно, удаляет) соответствующее правило NAT.

ВНИМАНИЕ! Команда add-nat/del-nat только создаёт правила NAT, но не применяет их. После включения/выключения NAT необходимо отдельно применить изменения в узле ip.nat.POSTROUTING

ПРИМЕЧАНИЕ. Если PPP-интерфейс используется в режиме клиента dial-up со следующими настройками:
— соединение устанавливается по требованию (connection = "on-demand")
— адреса назначаются удаленной стороной (ipcp.accept-address = "yes")
то для него в таблице маршрутизации создается запись с некоторыми фиктивными IP-адресами. Это необходимо для того, чтобы направить пакеты на интерфейс в то время, когда соединение отсутствует. После установления PPP-соединения она заменяется записью с фактическими адресами.
Фиктивные адреса в данном случае выбираются случайным образом из приватных диапазонов. Гипотетически может возникнуть ситуация, когда они конфликтуют с существующей схемой распределения адресов в сети. В этом случае следует назначить их явным образом при помощи параметров ip-address, peer-ip-address и разрешить удалённой стороне переопределять оба адреса при установлении соединения:
    ipcp.accept-address = "true"
    ipcp.accept-peer-address = "true"

Обратно в узел ppp...