PPP (Point-to-Point Protocol) — сложный и гибкий протокол, имеющий большое число параметров и применений. Это основной протокол 2 уровня для передачи пакетов IP через асинхронные среды передачи WAN "точка-точка", к которым относятся коммутируемые модемные линии, коммутируемые соединения GSM в канальном режиме (CSD, или GSM data), все пакетные технологии сотовых сетей 2 и 3 поколений (GPRS/EDGE/WCDMA/HxDPA/HSPA+, CDMA), а также нуль-модемные соединения и мультипротокольные инкапсуляции PPP-over-Ethernet (PPPoE), PPP-over-ATM (PPPoA), Point-to-Point Tunneling Protocol (PPTP), PPP-over-X.25. Базовым вариантом, наиболее простым, является асинхронная линия; все остальные варианты применения по существу используют ту же самую процедуру.

Процедура работы PPP разделяется на несколько этапов, каждый из которых обрабатывается отдельным протоколом. Их понимание необходимо для корректной настройки PPP и поиска возможных нестыковок.

1 этап — соединение на физическом уровне. Обработчик протокола PPP (pppd), как правило, должен отработать некоторый скрипт на подключённом модеме: послать строку инициализации, команду дозвона с номером телефона, и, в конечном счёте, получить от модема ответ CONNECT и поднятие сигнала DCD на физическом интерфейсе (или его аналога в соединениях PPPoE, PPTP).

Если после установления физического соединения вызываемая сторона (сервер) требует ввода имени и пароля пользователя в терминальном режиме, то это также должно делаться посредством модемного скрипта. Но в современных системах это редкость, поскольку все распространённые реализации PPP давно поддерживают PAP и CHAP.

2 этап — по поднятию DCD запускается протокол LCP (Link Control Protocol), базовый компонент стека PPP. C его помощью согласовываются последующие процедуры, например, будет ли выполняться аутентификация и какой из встроенных протоколов (PAP, CHAP и т.п.) будет использоваться для этой цели.

3 этап — после поднятия LCP запускаются три процедуры, которые могут исполняться последовательно или одновременно:

3.1 — аутентификация. Каждая из сторон может потребовать от другой стороны аутентифицировать себя с помощью имени и пароля. Используются протоколы PAP, CHAP, MS-CHAP или MS-CHAPv2. Протокол PAP является небезопасным, поскольку при этом передаётся сам пароль в зашифрованном виде; он может быть перехвачен и расшифрован, поскольку способ шифрования общеизвестен. Протокол CHAP и его модификации передают только хэш от совокупности пароля клиента и имени сервера, поэтому в части сохранности пароля они являются безопасными.

Очевидно, что если аутентификация не завершается успехом, то сторона, запросившая её, разрывает соединение.

Дополнительно в аутентификации может участвовать третья сторона — сервер аутентификации, авторизации и учёта (Authentication, Authorization and Accounting — AAA), на котором централизованно хранятся имена и пароли. Сторона, запрашивающая аутентификацию (сервер доступа) пересылает ему по протоколу RADIUS или TACACS+ то, что получила от клиента, а в ответ сервер присылает свой вердикт: разрешить подключение этого клиента или нет. Кроме того, сервер может прислать дополнительные настройки для работы клиента: IP-адрес, который следует ему назначить, фильтры и т.п. Далее, в процессе работы, сервер доступа может периодически отсылать серверу ААА статистику работы клиента. Если централизованный сервер ААА не используется, то имена и пароли клиентов хранятся в локальной таблице на сервере доступа.

3.2 — согласование параметров IP. Каждая из сторон может иметь заранее установленные (статические) IP-адреса для себя и для партнёра, или одна сторона может запрашивать их у другой. Каждая сторона может соглашаться с адресами, предлагаемыми другой стороной, или не соглашаться. Используется протокол IPCP. Взаимное знание IP-адресов в PPP-соединении является, по существу, формальным требованием, но оно должно быть выполнено для работы протокола. Эти адреса нужны только для пакетов, передаваемых или принимаемых непосредственно одним из устройств. Допустима даже такая ситуация, когда одна сторон использует одну пару адресов для себя и для партнёра, а другая — другие адреса (один или оба). При этом транзитный трафик, тем не менее, будет передаваться. В частности, в некоторых современных сетях 3G сервер назначает IP-адрес клиенту, но не сообщает свой собственный; в этом случае NSG Linux автоматически выбирает для сервера некоторый случайный адрес вида 10.x.x.x, хотя никакого практического смысла он не имеет.

В любом случае, обе стороны должны иметь для работы PPP какие-либо IP-адреса для себя и для партнёра, хотя бы формальные. Если согласовать их не удаётся, например, сторона А пытается назначить адрес стороне Б, а на стороне Б согласование адресов запрещено, то процедура аварийно завершается и соединение разрывается.

Помимо адресов, на этапе IPCP могут передаваться другие параметры, существенные для работы стека IP. В первую очередь, это адреса серверов DNS.

3.3 — согласование параметров сжатия. Используется протокол CCP. При передаче трафик может сжиматься "на лету", а также защищаться с помощью алгоритма MPPE (Microsoft Point-to-Point Encryption). По умолчанию, все алгоритмы сжатия являются опциональными, поэтому процедура может считаться успешно завершенной и в том случае, если стороны договорились работать без сжатия. Однако если на разных сторонах принудительно установлены несовпадающие алгоритмы или параметры (особенно для MPPE) и запрещёна прозрачная передача, то процедура завершится аварийно и соединение будет разорвано.

4 — IP-маршрутизация. После успешного завершения 3 вышеуказанных процедур соединение готово к передаче пакетов IP поверх PPP. Но чтобы пакеты пошли в это соединение, должна быть настроена маршрутизация. Специфический приём маршрутизации именно для сеансовых PPP-соединений состоит в том, что данное соединение, если оно успешно установлено, объявляется маршрутом по умолчанию (и удаляется из маршрутной таблицы после разъединения). Можно также сделать это заранее (статическими маршрутами), можно — динамически (если партнёр поддерживает протоколы динамической маршрутизации).

ВНИМАНИЕ! Если для задания маршрутов используются одновременно несколько способов, то между ними может возникнуть конфликт, и в результате будет действовать только один из маршрутов. Например, если в устройстве определён некоторый маршрут по умолчанию и, кроме того, устанавливается второй маршрут по умолчанию через PPP-соединение, то необходимо установить приоритет между ними с помощью метрик.

Кроме того, в большинстве случаев на интерфейсе IP-over-PPP требуется использовать NAT, а именно, процедуру IP-маскарадинга (или Source NAT, если адрес выделен данному клиенту статически.) Это необходимо, если устройство работает в качестве клиента и получает от оператора единственный IP-адрес для самого себя, а за ним стоит локальная сеть из одного или нескольких хостов. NAT не требуется в следующих случаях:

• Данное устройство является единственным пользователем PPP-соединения (например, одиночный ПК).
• Удалённая сторона знает, что маршруты в сеть, расположенную за данным устройством, проходят через это PPP-соединение.
• Весь трафик из/в локальную сеть передаётся внутри какого-либо туннеля (PPTP, IPsec, STunnel, etc.). В этом случае все пакеты туннеля посылаются и принимаются только данным устройством. С точки зрения публичной сети, оно является единственным пользователем PPP-соединения.

5 — во всё время существования соединения в рамках PPP продолжает работать протокол LCP. В частности, любая из сторон может затребовать повторную аутентификацию, пересогласование адресов или параметров сжатия. Если одна из сторон решает штатно завершить соединение по какой-либо причине (например, по достижении максимального времени неактивности или максимальной продолжительности сеанса), она присылает пакет LCP Reset и следом разрывает физическое соединение.

Очевидно, что существование PPP-соединения на 2 и вышележащих уровнях имеет смысл только при условии, что под ним имеется физическое соединение. По этой причине pppd следит за состоянием сигнала DCD на порту. Если модемы разъединяются по какой-либо причине, то немедленно удаляются соответствующие соединения, установленные процедурами PPP.

Возможны, однако, ситуации, когда физическое соединение становится де-факто неработоспособным, но это не приводит к падению DCD — из-за неисправности модема, его аппаратных особенностей, настройки (AT&C0) и т.п.. Например, в сотовых сетях нередка ситуация, когда соединение номинально существует, но его пропускная способность падает до нуля из-за высокой загруженности сети. Чтобы своевременно обнаруживать такие ситуации, в LCP предусмотрен механизм Echo: стороны PPP-соединения при отсутствии полезного трафика обмениваются пакетами LCP Echo Request/Echo Reply. Если ответы не возвращаются, то соединение считается умершим и принудительно уничтожается. Каждая из сторон может посылать или не посылать свои пакеты Echo Request, но обязана отвечать на запросы партнёра. (Хотя встречаются и операторы, работающие с нарушением стандарта.)

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