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

Сценарий дозвона, который будет инициализировать модем и ставить его в режим автоответа. Поскольку доступ по коммутируемым телефонным линиям в настоящее время утратил актуальность, этот пункт можно упомянуть здесь только для академической полноты изложения. Однако все последующие вопросы в равной степени относятся и к серверам доступа по производным от PPP протоколам — PPPoE и PPTP (вместе называемым иногда VPDN — Virtual Private Dial-up Networks).

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

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

Режим установления и разрыва соединения.

Соединение устанавливается, как правило, по требованию клиента. Для параметра connection применительно к серверу имеют смысл значения permanent и passive. Рекомендуется использовать режим passive — в этом случае устройство NSG не посылает запросов LCP, а только ждёт, пока они поступят от клиента. Исключением является соединение с клиентом, работающим под управлением продуктов корпорации Microsoft, по нуль-модемному кабелю или выделенной линии. Ввиду особенностей архитектуры драйверов в этих продуктах, их PPP-клиент в такой ситуации не может начать работу первым и должен сначала получить что-либо от сервера, поэтому на сервере необходимо установить режим permanent. (Кроме того, необходимо установить специальный драйвер NSG для асинхронной нуль-модемной линии, или аналогичный драйвер от другого производителя; встроенный нуль-модемный драйвер Microsoft предназначен только для эмуляции локальной сети и непригоден для PPP-соединений.)

Критериями для разрыва соединения, как и в случае клиента, может быть отсутствие полезного трафика в течение некоторого времени, достижение максимальной продолжительности сеанса (idle-time, session-time) или отсутствие связи де-факто (параметры lcp-echo-*).

Аутентификация удалённых клиентов на устройстве NSG производится только встроенными средствами протокола PPP. Необходимо выбрать протокол аутентификации и источник аутентификации: локальная таблица пользователей PPP или системный механизм аутентификации, позволяющий задействовать централизованные серверы RADIUS или TACACS+.

Локальная таблица пользователей для сервера PPP (и производных от него протоколов) всегда хранится в узле .system.ppp-secrets.pap или .system.ppp-secrets.chap, в зависимости от выбранного протокола аутентификации. Каждая запись таблицы содержит 3 параметра: имя клиента, имя сервера и пароль. В качестве имени сервера может быть указана просто звёздочка (*), означающая любое имя; по существу же это должно быть имя устройства NSG, заданное параметром system.hostname (или специальное имя, которое можно задать дополнительными опциями pppd).

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

Дополнительно в таблице может быть указан список IP-адресов, с которых разрешено работать данному клиенту. Если клиент при установлении PPP-соединения не имеет собственного адреса и просит назначить ему адрес, то сервер NSG посылает ему первый адрес из этого же списка.

Если используется централизованная аутентификация, то она настраивается в узле .system.aaa.ppp. Подробнее см. справку по узлу .system.aaa.

IP-адреса. Как правило, сервер PPP-доступа знает собственный IP-адрес и назначает IP-адреса клиентам. При этом PPP-интерфейсы сервера часто делаются ненумерованными и все используют один и тот же адрес, "позаимствованный у" (borrowed from) какого-либо другого интерфейса, чаще всего, Ethernet или lo. Этот адрес указывается в параметре ppp.main.ip-address. Пул адресов клиентов для серверов PPPoE и PPTP формируется специфическим образом, см. справку по этим типам туннелей. Если адрес для клиента указан индивидуально при аутентификации (записан в локальной таблице пользователей или прислан сервером аутентификации RADIUS/TACACS+), то этот адрес имеет приоритет.

ПРИМЕЧАНИЕ. В данной версии NSG Linux обработка IP-адресов, назначаемых клиентам централизованно сервером RADIUS/TACACS+, не поддерживается.

В любом случае, адреса сторон в PPP-соединении никак не связаны друг с другом. Ясности ради, можно выбрать адреса традиционным образом — из одной сети с маской /30, но настоятельной необходимости в этом нет. Адреса могут быть произвольными, понятия сети и маски для PPP-соединений не имеют смысла.

Помимо адресов, в большинстве задач клиентам требуется передать один или несколько адресов DNS, которые указываются в узле ppp.main.ipcp.

Сжатие и защита трафика. К сжатию трафика "на лету" и его защите в PPP-соединениях относится всё сказанное выше для клиента PPP.

Маршрутизация и фильтрация. Очевидно, что PPP-интерфейс к какому-либо клиенту не является для сервера маршрутом по умолчанию, поэтому следует установить ppp.main.default-route=false.

При установлении соединения создаётся маршрут к удалённому клиенту через данный сетевой интерфейс. Про сети, расположенные за клиентом, сервер ничего не знает. В большинстве случаев ему незачем это знать, поскольку все эти сети скрыты за NAT (IP-masquerading) на клиенте; с точки зрения сервера, все они вместе с клиентом составляют единый, непосредственно подключённый, хост.

Если NAT не используется и необходимо указать маршруты в сети, расположенные за PPP-клиентом, то проблема, как правило, состоит в том, что заранее неизвестно, какой IP-адрес получит данный клиент в очередной раз. Для этой задачи возможны два решения:

• Каждому клиенту назначается специфический IP-адрес при аутентификации по локальной таблице пользователей или от централизованного сервера RADIUS/TACACS+, и маршруты в удалённые сети задаются статически через этот адрес как gateway.
• Используется динамическая маршрутизация (RIP, OSPF).

Дополнительно на сервере PPP-доступа рекомендуется создать (в узле .ip.filter.FORWARD) фильтр, который будет запрещать отправку пакетов, адресованных PPP-клиентам, через интерфейс, служащий маршрутом по умолчанию. Дело в том, что если клиент разорвал соединение, а для него продолжают поступать пакеты, то, поскольку маршрута к клиенту уже нет, эти пакеты будут отправляться по умолчанию на вышестоящий хост, оттуда снова возвращаться на PPP-сервер и так далее до тех пор, пока у них не истечёт TTL. В принципе, эта ситуация не грозит никакими катастрофическими последствиями, но создаёт бесполезную нагрузку на сеть; в некоторых случаях она может быть существенной (например, когда к клиенту продолжает идти недосмотренный видеопоток или большой недозакачанный файл).

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