Если pppd является основным сервером для windows клиентов

VPN (Virtual Private Network — Виртуальная Частная сеть) используется для организации доступа извне к компьютерам, находящимся внутри корпоративной сети за маршрутизатором. При подключении к VPN пользователю выдаётся IP-адрес из внутренней сети и пользователь получает доступ ко всем ресурсам внутренней сети, как будто он находится в офисе. Для защиты информации весь трафик между сервером VPN и клиентом, как правило, шифруется.

Наиболее простым с точки зрения настройки и сервера, и клиента является VPN типа PPTP (Point-to-Point Tunneling Protocol), разработанный в Microsoft для Windows 95 и впоследствии ставший стандартом (RFC 2637). PPTP использует туннель GRE для передачи пакетов PPP. Основным преимуществом PPTP является простота подключения клиентов — соответствующее программное обеспечение встроено во все системы Microsoft Windows начиная с Windows 95 OSR2, возможно и подключение Linux/UNIX клиентов. Основной недостаток — недостаточная защита (применяемое шифрование MPPE 128bit считается достаточно слабым), поэтому там, где необходима надежная защита данных.

Рассмотрим настройку сервер  PPTP на следующем примере.

Вводные данные:

1. Корпоративная сеть 192.168.0.0/255.255.255.0
2. Шлюз — Linux-сервер, адрес шлюза во внутренней сети — 192.168.0.1
3. Внешнее подключение — PPP (3G) либо PPPOE (ADSL)(настройка внешнего подключения не входит в эту статью).
4. Настройка pptpd вручную

Установка пакетов

Для установки сервера PPTP необходимо выполнить команду:

Для Fedora, StartCom, ASP Linux, CentOS.

yum install pptpd

Для Debian, Ubuntu Server, и др..

apt-get install pptpd

Пакет ppp, если он не установлен, будет автоматически установлен по зависимостям.

Настройка pptpd

После установки необходимо включить автозапуск службы pptpd:

 chkconfig pptpd on
Настройка pptpd осуществляется путём редактирования трёх файлов:  /etc/pptpd.conf (настройка демона), /etc/ppp/options.pptpd (параметры  pppd) и /etc/ppp/chap-secrets (имена пользователей и пароли). Ниже  приведены примеры файлов с необходимыми комментариями.
/etc/pptpd.conf
# Файл, содержащий параметры pppd
option /etc/ppp/options.pptpd
# Локальный IP-адрес сервера PPTP
localip 192.168.0.1
# Пул адресов, которые сервер выдаёт клиентам
# Эти адреса не должны использоваться в локальной сети
remoteip 192.168.0.10-20

/etc/ppp/options.pptpd



  


                       
  





# Имя локальной системы для аутентификации
# Должно соответствовать второму полю записей в файле /etc/ppp/chap-secrets
name pptpd
# Отклонять небезопасные протоколы проверки пароля
refuse-pap
refuse-chap
refuse-mschap
# Требовать защищенный протокол проверки пароля
require-mschap-v2
# Требовать шифрование MPPE 128bit
require-mppe-128
# Передавать клиенту внутренний DNS-сервер, если необходимо
ms-dns 192.168.0.2
# Сделать клиента доступным для других компьютеров в локальной сети
proxyarp
# Создавать файл блокировки псевдотерминала в стиле UUCP
lock
# Отключить BSD-компрессию:
nobsdcomp 
# Отключить компрессию Van Jacobson
novj
novjccomp
# Отключить вывод ошибок на stderror
nologfd


/etc/ppp/chap-secrets
# Secrets for authentication using PAP
# client	server	secret			IP addresses
# Это пароль для исходящего соединения с сервером 3G оператора:
"80921234567@people.net.ua"     "PeopleNet"     "3GPasswd"
#Этому клиенту всегда выдаётся фиксированный IP:
"user1"	"pptpd" "passord1" 192.168.0.30
#Этому клиенту выдаётся любой свободный IP из разрешенных параметром remoteip в /etc/pptpd.conf
"user2"	"pptpd" "passord2" *

Настройка VPN (pptp) клиента с использование автоматических скриптов
 Настройка при помощи pptp-command

Устанавливаем pptp
Устанавливаем pptp-command
Проверяем содержание файла /etc/ppp/options

Проверяем чтобы в /etc/ppp/options были такие строчки
lock
noauth
defaultroute
usepeerdns

Проверяем содержание файла /etc/ppp/options.pptp
lock
noauth
nobsdcomp
nodeflate


Запускаем pptp-command setup и настраиваем туннель:
$ pptp-command setup
ls: /etc/pptp.d: No such file or directory
1.) Manage CHAP secrets
2.) Manage PAP secrets
3.) List PPTP Tunnels
4.) Add a NEW PPTP Tunnel
5.) Delete a PPTP Tunnel
6.) Configure resolv.conf
7.) Select a default tunnel
8.) Quit
?: 1
1.) List CHAP secrets
2.) Add a New CHAP secret
3.) Delete a CHAP secret
4.) Quit
?: 2
Add a NEW CHAP secret.

NOTE: Any backslashes () must be doubled ().

Local Name:

This is the 'local' identifier for CHAP authentication.

NOTE: If the server is a Windows NT machine, the local name
should be your Windows NT username including domain.
For example:

domainusername

Local Name: <ваш логин> 

Remote Name:

This is the 'remote' identifier for CHAP authentication.
In most cases, this can be left as the default. It must be
set if you have multiple CHAP secrets with the same local name
and different passwords. Just press ENTER to keep the default.

Remote Name [PPTP]:<enter>

Password:

This is the password or CHAP secret for the account specified. The
password will not be echoed. 

Password:<ваш пароль>
Adding secret <ваш логин> PPTP *****

1.) List CHAP secrets
2.) Add a New CHAP secret
3.) Delete a CHAP secret
4.) Quit
?: 4
1.) Manage CHAP secrets
2.) Manage PAP secrets
3.) List PPTP Tunnels
4.) Add a NEW PPTP Tunnel
5.) Delete a PPTP Tunnel
6.) Configure resolv.conf
7.) Select a default tunnel
8.) Quit
?: 4

Add a NEW PPTP Tunnel.

1.) Other
Which configuration would you like to use?: 1
Tunnel Name: <имя туннеля> #Произвольное
Server IP: 10.10.10.1
What route(s) would you like to add when the tunnel comes up?
This is usually a route to your internal network behind the PPTP server.
You can use TUNNEL_DEV and DEF_GW as in /etc/pptp.d/ config file
TUNNEL_DEV is replaced by the device of the tunnel interface.
EF_GW is replaced by the existing default gateway.
The syntax to use is the same as the route( command.
Enter a blank line to stop.
route:del default
route:add -host 10.10.10.1 gw <Ваш шлюз>
route:add default dev ppp0
Local Name and Remote Name should match a configured CHAP or PAP secret.
Local Name is probably your NT domainusername.
NOTE: Any backslashes () must be doubled ().

Local Name: <ваш логин>
Remote Name [PPTP]:<enter>
 
Added tunnel <имя туннеля>
1.) Manage CHAP secrets
2.) Manage PAP secrets
3.) List PPTP Tunnels
4.) Add a NEW PPTP Tunnel
5.) Delete a PPTP Tunnel
6.) Configure resolv.conf
7.) Select a default tunnel
8.) Quit
?: 8
Запуск vpn туннеля:
pptp-command start <Выбираем тунель>
 Настройка через pptpsetup на примере UBUNTU (рекомендуется)
Установка нужных пакетов:
sudo aptitude install pptp-linux
Создаем туннель:



  


                       
  




pptpsetup  --create <Название Тунеля> --server <Сервер>  --username <логин> --password  <Пароль>--start
route del default
route add default dev ppp0
Теперь можете включать и выключать впн подключение с помощью следующих команд: Включение
sudo pon <Название Тунеля>
Выключение

sudo poff  <Название Тунеля>

Для автоматического поднятия маршрута, восстановления при обрыве и  выставления максимального количества ошибок нужно в конец файла /etc/ppp/peers/<Название Тунеля> добавить:

persist
maxfail 0
holdoff 5
#lcp-echo-interval 10
#lcp-echo-failure 10
defaultroute
replacedefaultroute 
persist - написать этот параметр для того чтобы pppd автоматически переподнимал VPN. 
 maxfail n - сколько раз pppd будет пытаться переподнять VPN. Чтобы pppd пытался до упора n должно быть равно 0 
 holdoff n - время в секундах между попытками переподнятия упавшего VPN.
 lcp-echo-interval n - как pppd может узнать что канал отвалился?  Для этого предназначен протокол LCP. Этой командой Вы указываете pppd  через какой интервал времени в секундах посылать запросы типа ping чтобы  проверить жив канал или нет. По умолчанию ping не посылается и pppd не  может определить что канал упал.(я не стал указывать) 
 lcp-echo-failure n - этот параметр говорит, что если n пингов не  прошло, то это означает канал отвалился и его надо переподнимать(я не  стал указывать).
 Для автоматического подключения VPN при загрузке системы редактируем файл /etc/network/interfaces и вставляем в его конец следующие строки:
post-up pon <Название Тунеля>
где <Название Тунеля> - название vpn-соединения которое мы создали выше.
  Настройка Windows-клиента
При настройке Windows-клиента необходимо выполнить следующие действия:

Открыть Панель Управления - Сеть
Выбрать "Создание нового соединения - Подключить к сети на рабочем месте - Подключение к виртуальной частной сети"
Ввести название организации (имя соединения), затем имя или IP-адрес сервера PPTP
При установке соединения использовать имя пользователя и пароль, введенный в файле /etc/ppp/chap-secrets на сервере.

 Ссылки
https://wiki.ubuntu.com/VPN
 http://www1.opennet.ru/base/net/ubuntu_route.txt.html
 http://leolik.blogspot.com/2008/05/vpn-ubuntu.html
 Часть материала взята от сюда
 Настройка VPN (pptp) подключения в Ubuntu Linux



  


                       
  





									Теги: 

									network, pptp, сеть								

В этой заметке я хочу показать пример быстрой реализации корпоративного VPN сервера с поддержкой PPTP, L2TP (как с IPsec так и без), IPSec vpn с единой базой, который сможет работать с пулами адресов, разными группами пользователей, авторизировать пользователей как из LDAP, так и из локальной базы, опциональная настройка шейпирования как для групп, так и для отдельных пользователей с поддержкой windows, linux, osx, ios, android клиентов и все это на открытых решениях.
P.S. В данной заметке аспекты сетевой безопасности затронуты не будут, иначе она разрастется в огромный документ, с кучей нюансов в реализации, возможно о защите периметра и сетевой безопасности отдельно расскажу в следующий раз.
Кому интересно, добро пожаловать под кат.

Оглавление:

Введение

Подготовительные работы на сервере
Accel-PPP (PPTP, L2TP)
Strongswan (IPsec)
Freeradius
Samba 4

В результате мы планируем получить примерно такую схему:

В сети есть мобильные клиенты, офисные клиенты и защищенная сеть с важными сервисами, которая должны быть доступна только через VPN при этом офисные клиенты и мобильные клиенты должны получать от ВПН разные подсети и иметь разные права на доступы к ресурсам, что-то общее, что-то только для одних или других, также в сети присутствуют администраторы, которые должны иметь полный доступ к внутренней инфраструктуре компании как работая из офиса, так и на выезде, данная схема не охватывает внутриофисную сеть с ее серверами, доступными офисным пользователям локально, а мобильным клиентам через VPN.
Начинаем настройку сервера.

0) Подготовительные работы.

Перед тем как приступить непосредственно к настройке VPN, проведем некоторые подготовительные работы.
И так у нас есть свежеустановленный сервер с Debian 7 (не принципиально, аналогично будет работать на любом другом linux) в минимальной конфигурации. Логинимся на него по ssh или в локальной консоли, затем:
Ставим правильный часовой пояс (в примере я ставлю MSK)

mv /etc/localtime /etc/localtime_org && ln -s /usr/share/zoneinfo/"Europe/Moscow" /etc/localtime && date

Отключаем IPv6, если не планируете использовать на данном сервере

echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf

В репы подключаем бэкпорты(чтоб не ставить древние samba и strongswan в которых есть ряд проблем), для этого добавляем в /etc/apt/sources.list следующие строки:

deb http://http.debian.net/debian wheezy-backports main contrib non-free
deb http://mirror.yandex.ru/debian/ wheezy-backports main contrib non-free

Устанавливаем минимально необходимые на данном этапе пакеты

apt-get update
apt-get install cmake make libssl-dev libpcre3-dev libnet-snmp-perl libtritonus-bin bzip2 checkinstall ntpdate

Синхронизируем время на сервере, лучше сразу с доменными часами, самый простой вариант через

ntpdate DC.DOMAIN.COM

Указываем DNS сервер домена в /etc/resolv.conf
Настройки фаирвола специфичны для компании и тут не публикую, но на основе его мы привязываем разные подсети клиентов VPN к разным запретам и разрешениям.

Тут и далее
ХХ.УУ.1.99 — внешний IP вашего сервера.

1) Accel-PPP — основной сервис для работы с L2TP и PPTP

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

Скачиваем и кидаем на сервер.

http://downloads.sourceforge.net/project/accel-ppp/accel-ppp-1.9.0.tar.bz2

разархивируем

tar -xjf accel-ppp-1.9.0.tar.bz2
mkdir accel-ppp-build
cd accel-ppp-build

собираем

cmake -DBUILD_PPTP_DRIVER=FALSE -DLOG_PGSQL=FALSE -DNETSNMP=FALSE -DRADIUS=TRUE -DSHAPER=TRUE /root/accel-ppp-1.9.0/
make
checkinstall -D

Создаем скрипт автозапуска из примера.

cd ../accel-ppp-1.9.0/contrib/debian
cp accel-ppp-init /etc/init.d/accel-ppp

Определяем дирректорию с демоном

which accel-pppd

Скорее всего для deb будет /usr/local/sbin/accel-pppd
В стартовом файле меняем пути на полученный выше.

nano /etc/init.d/accel-ppp

Добавляем в автозапуск

insserv -v accel-ppp

Создаем дирректорию для логов
mkdir /var/log/accel-ppp/

Создаем фаил с доступами для проверки коннектов,

в дальнейшем заменим его на radius авторизацию

touch /etc/ppp/chap-secrets

Формат:
login * password ip_для выдачи(если надо брать из пула, то просто *)

Создаем конфигурационный фаил /etc/accel-ppp.conf

[modules]
path=/usr/local/lib64/accel-ppp
#Данный модуль предназначен для записи журнала событий в файл.
log_file
#Данный модуль записывает события в syslog.
#log_syslog

#Рабочие протоколы
pptp
l2tp

#Методы аутентификации
auth_mschap_v2
auth_mschap_v1
auth_chap
auth_pap
#модуль поддержки файла CHAP-secrets конфликтует с radius
#chap-secrets
#модуль поддержки файла RADIUS конфликтует с chap-secrets
radius

#Назначение IPv4 адреса из статического пула.
ippool
sigchld
#Данный модуль запускает скрипты ip-up/ip-down при старте сессии и обработки RADIUS CoA запрос.
#pppd_compat
#Модуль управления пропускной способностью.
shaper
#Модуль управления частотой подключений.
#connlimit

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=0
min-mtu=1280
mtu=1480
mru=1480
#ccp=1
check-ip=1
#    Если эта опция управления отсутствует контроль количество сессий на пользователя выключен.
#    Если эта опция replace - accel-ррр прекращает первую сессию, когда вторая выполяет подключение.
#    Если эта опция deny accel-ррр будет сбрасывать попытки авторизации второй сессии
#single-session=replace
#Задаё политику шифрования MPPE (Microsoft Point-to-Point Encryption)
# prefer – Не разрывает соединение при отрицании шифрования клиентом
mppe=prefer
ipv4=prefer
#Если эта опция задана, и больше 0, то PPP модуль будет отправлять LCP пакеты эхо-запроса каждые n секунд.
lcp-echo-interval=300
#Определяет максимальное количество эхо-запросов без ответа, по достижению значения n сессия будет сброшена.
lcp-echo-failure=6

[dns]
dns1=8.8.8.8
dns2=8.8.4.4

[auth]
#any-login=0
#noauth=0

[pptp]
bind=ХХ.УУ.1.99
echo-interval=300
echo-failure=6
verbose=0

[l2tp]
bind=ХХ.УУ.1.99
#ppp-max-mtu=1300
dictionary=/usr/local/share/accel-ppp/l2tp/dictionary
hello-interval=300
#timeout=60
#rtimeout=5
retransmit=3
host-name=vpn.mydomain.ru
#dir300_quirk=1
#secret=
verbose=0

[radius]
dictionary=/usr/local/share/accel-ppp/radius/dictionary
nas-identifier=cisco
nas-ip-address=127.0.0.1
gw-ip-address=ХХ.УУ.1.99
auth-server=127.0.0.1:1812,Radius-Sicret
acct-server=127.0.0.1:1813,Radius-Sicret
server=127.0.0.1,Radius-Sicret,auth-port=1812,acct-port=1813,req-limit=0,fail-time=0
dae-server=127.0.0.1:3799,Radius-Sicret
timeout=5
max-try=3
acct-timeout=600
acct-delay-time=1
verbose=0

[shaper]
attr=Filter-Id
#down-burst-factor=1.0
#up-burst-factor=1.0
#latency=50
#mpu=0
#time-range=1,7:00-00:59
#time-range=2,1:00-3:59
#time-range=3,4:00-6:59
#leaf-qdisc=sfq perturb 10
up-limiter=htb
down-limiter=htb
cburst=1375000
ifb=ifb0
r2q=10
quantum=1500
verbose=0

# Указывает диапазон IP-адресов, с которых клиенты могут подключиться к серверу в виде: x.x.x.x/mask (for example 10.0.0.0/8)
[client-ip-range]
#192.168.0.0/18
disable

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
log-debug=/var/log/accel-ppp/debug.log
#syslog=accel-pppd,daemon
#log-tcp=127.0.0.1:3000
copy=1
color=1
#per-user-dir=per_user
#per-session-dir=per_session
#per-session=1
level=0

# Раскоментировать во время теста, пока не настроен радиус
#[chap-secrets]
#gw-ip-address=ХХ.УУ.1.99
#chap-secrets=/etc/ppp/chap-secrets

[ip-pool]
attr=Framed-Pool
gw-ip-address=ХХ.УУ.1.99
10.65.16.129-254,fullaccess
10.65.17.129-254,mobila
10.65.18.129-254,office

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001
#password=123

#[connlimit]
#limit=10/min
#burst=3
#timeout=60

Запускаем

service accel-ppp start

Если что-то не так, увеличиваем в конфиге уровень логирования и смотрим логи.

Для работы под нагрузкой необходим небольшой тюнинг, если у вас менее 500 одновременных клиентов на VPN, можно не делать, кроме пункта net.ipv4.ip_forward=1, он обязателен.

Применяем:

sysctl -p

Пробуем подключиться с PPTP и L2TP без IPsec с логином и паролем, указанным в /etc/ppp/chap-secrets

На самом сервере список подключенных клиентов можно посмотреть командой

accel-cmd show session

Очень рекомендую прочитать справку по accel-cmd, имеет много возможностей, включая изменение метода авторизации пользователей на лету без обрыва сессий

Если все ОК, переходим к следующему пункту

2) IPsec

Ознакомиться с тем, что это и для чего нужно можно кратко тут

устанавливаем

apt-get -t wheezy-backports install strongswan libcharon-extra-plugins

Конфиги приводим к виду:
nano /etc/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

config setup
  # Нужно ли требовать неистекший лист отзывов для проведения аутентификации клиента
        strictcrlpolicy=no
  include /var/lib/strongswan/ipsec.conf.inc

conn %default
        ikelifetime=1440m
        keylife=60m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=xauthpsk
  # включает механизм Dead Peer Detection (DPD) и указывает, что нужно забывать о клиенте, если он не отзывался дольше таймаута
  dpdaction=clear
  # задержка до включения DPD
  # dpddelay=35s
  # таймаут для DPD
  # dpdtimeout=300s
  #включение внутренней фрагментации пакетов. Позволяет использовать IPsec с провайдерами, у которых сломана IP-фрагментация пакетов
  fragmentation=yes
  # выключение инициации смены ключей со стороны сервера. Windows это не любит.
  rekey=no
  # перечень ciphersuites для использования с IKE
  ike=aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-aesxcbc-sha256-sha1-modp4096-modp2048-modp1024,aes256-aes128-sha256-sha1-modp4096-modp2048-modp1024!
  # перечень ciphersuites для шифрования трафика
  esp=aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp4096-modp2048-modp1024,aes128-aes256-sha1-sha256-modp4096-modp2048-modp1024,aes128-sha1-modp1024,aes128-sha1!

conn L2TP_Accel-PPP
        authby=psk
        rekey=no
        type=transport
        esp=aes128-sha1,null-sha1,md5
        ike=aes128-sha-modp1024,null-sha1,md5
        left=194.135.1.99
        leftprotoport=17/%any # при 1701 не пашет на iOS
        right=%any
        rightprotoport=17/%any
        rightsubnetwithin=0.0.0.0/0
        auto=add
        compress=no
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        forceencaps=yes

conn IPsec
  authby=secret
  rekeymargin=3m
  keyingtries=1
  keyexchange=ikev1
  leftfirewall=yes
  rekey=no
  left=XX.YY.1.99
  leftsubnet=0.0.0.0/0
  leftauth=psk
  rightsourceip=%radius
  rightdns=8.8.8.8
  right=%any
  rightauth=psk
  rightauth2=xauth-radius
  dpdaction=clear
  dpdtimeout = 5s
  auto=add

Далее указываем наш приватный ключ
nano /etc/ipsec.secrets
: PSK "Sicret-Test-Key"

Для дальнейшей интеграции с Freeradius также правим
nano /etc/strongswan.d/charon/eap-radius.conf

eap-radius {
    accounting = yes
    load = yes
    nas_identifier = StrongSwan
    #Наш секрет для Radius
    secret = Radius-Sicret
    server = 127.0.0.1
    dae {
        enable = yes
        listen = 127.0.0.1
        port = 3799
        secret = Radius-Sicret
    }
    forward {
    }
    servers {
    }
    xauth {
    }
}

Запускаем

service ipsec start

Статус можно посмотреть так:

ipsec statusall

3) FreeRadius

*для тех, кто не знает что это.
Устанавливаем стандартно

apt-get install freeradius freeradius-ldap

Правим фаил /etc/freeradius/clients.conf в нем содержатся настройки для пользователей FreeRadius, у нас такими выступают локальные демоны Accel-PPP и Strongswan, минимально достаточно следующего содержимого:

client localhost {
ipaddr = 127.0.0.1
secret = Radius-Sicret
nastype = cisco
shortname = MY_TEST_VPN
}

Теперь подготовим профиль для запуска, стандартный находится тут /etc/freeradius/sites-enabled/default
, нам необходимо привести его к виду:

authorize {
	preprocess
	chap
	mschap
	ldap
#	ntlm_auth
	digest
	suffix
	eap {
		ok = return
	}
	files
	expiration
	logintime
	pap
}
authenticate {
	Auth-Type PAP {
		pap
	}
	Auth-Type CHAP {
		chap
	}
	Auth-Type MS-CHAP {
		mschap
	}
	Auth-Type LDAP {
		ldap
        }

#    	Auth-Type ntlm_auth {
#        	ntlm_auth
#    	}
	digest
	unix
	eap
}
preacct {
	preprocess
	acct_unique
	suffix
	files
}
accounting {
	detail
	unix
	radutmp
	exec
	attr_filter.accounting_response
}
session {
	radutmp
}
post-auth {
	exec
	Post-Auth-Type REJECT {
		attr_filter.access_reject
	}
}
pre-proxy {
}
post-proxy {
	eap
}

Теперь создадим фаил локальных пользователей, а также описание настроек для различных групп из LDAP

#Указываем что пользователь берется из локального файла, его имя и пароль, 
# можно откртым текстом либо зашифровать через 
#perl -e 'print(crypt("testpassword","abrakadabra")."n");'
#Тогда указываем сразу зашифрованно
#testuser Crypt-Password := "abA5hjwYqm1.I"

testuser  Cleartext-Password := "testpassword" , MS-CHAP-Use-NTLM-Auth := 0
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
# Можно не указывать конкретный IP, тогда он возьмется автоматически из пула, переданного в Framed-Pool
        Framed-IP-Address = 10.65.18.12,
        Framed-IP-Netmask = 255.255.255.255,
# Пул из которого берем адреса для клиентов, описан в секции ip-pool конфига accel-ppp
        Framed-Pool = "office",
# Скорость шейпера в килобитах на пользователя.
        Filter-Id = "100000/100000",
# В ответе указываем что авторизация взята из локального файла, удобно для тестов
        Reply-Message = "Accepted from local file"
# Можно указать дополнительно любые другие параметры соединения
# такие как Idle-Timeout, Acct-Interim-Interval и т.п.

# Описываем привязку к различным группам LDAP, например привязываем доменную группу 
# remote-connection к группе office, описанной в секции ip-pool конфига accel-ppp
DEFAULT Ldap-Group == "remote-connection"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Pool = "office",
        Filter-Id = "100000/100000"

# Остальные группы по аналогии
DEFAULT Ldap-Group == "full-access"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Pool = "fullaccess"
# Админская группа уберем для нее шейпер
#        Filter-Id = "100000/100000"

DEFAULT Ldap-Group == "mobile-access"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Pool = "mobila",
        Filter-Id = "100000/100000"

Перезапустим радиус

service freeradius restart

*Для отладки можно запускать в режиме вывода лога на терминал freeradius -X
Если все ОК и ошибок в запуске нет, проверим тестового пользователя:

radtest testuser testpassword 127.0.0.1 0  Radius-Sicret

мы должны получить ответ вида:

Sending Access-Request of id 238 to 127.0.0.1 port 1812
	User-Name = "testuser"
	User-Password = "testpassword"
	NAS-IP-Address = XX.YY.1.99
	NAS-Port = 0
	Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=238, length=105
	Service-Type = Framed-User
	Framed-Protocol = PPP
	Framed-IP-Address = 10.65.18.12
	Framed-IP-Netmask = 255.255.255.255
	Framed-Pool = "office"
	Filter-Id = "100000/100000"
	Reply-Message = "Accepted from local file"

Если в ответе есть Access-Accept, то все хорошо и можно переходить к настройке интеграции Freeradius с LDAP, конфиги помещаю в этой секции заранее, нам надо подправить:
nano /etc/freeradius/modules/ntlm_auth
*вместо KR.LOC просто указываем свой домен

exec ntlm_auth {
	wait = yes
	program = "/usr/bin/ntlm_auth --request-nt-key --domain=KR.LOC --username=%{mschap:User-Name} --password=%{User-Password}"
}

Чуток подправим авторизацию через mschap, т.к. pap использовать не безопасно.
nano /etc/freeradius/modules/mschap

mschap {
        #Используем шифрование
	use_mppe = yes
        # Но разрешаем подключаться и без шифрования, для некоторых клиентов это важно, если таких нет - заменить на yes
	require_encryption = no
	require_strong = yes
	with_ntdomain_hack = no
	ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
}

ну и самое важное, непосредственно интеграция с LDAP
nano /etc/freeradius/modules/ldap

ldap {
        server = "10.13.205.7"   #свой контроллер
        identity = "sf-test@KR.LOC"   #своя учетка
        password = "987654321"   # свой пароль
        basedn = "dc=KR,dc=LOC"   # свой домен
        filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
         ldap_connections_number = 5
        max_uses = 0
        #port = 389
        timeout = 4
        timelimit = 3
        net_timeout = 1

        tls {
                start_tls = no
        }
        dictionary_mapping = ${confdir}/ldap.attrmap
        password_attribute = userPassword
        edir_account_policy_check = no

        groupname_attribute = cn
        groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))"
        groupmembership_attribute = memberOf

        access_attr_used_for_allow = yes

        chase_referrals = yes
        rebind = yes
        # set_auth_type = yes

        keepalive {
                idle = 60
                probes = 3
                interval = 3
        }
}

Еще один важный момент, для того чтоб получать radius атрибуты для конкретного пользователя прямо из ldap атрибутов домена необходимо настроить соответствие их между собой, это делается в файле /etc/freeradius/ldap.attrmap там многое уже заполнено и интуитивно понятно, но для примера покажу несколько своих:

replyItem	Framed-IP-Address		msRADIUSFramedIPAddress
replyItem	Framed-Pool			msRADIUSFramedRoute

Таким образом указав в домене у пользователя персональный атрибут msRADIUSFramedIPAddress мы передадим радиусу считать его атрибутом Framed-IP-Address и выдать пользователю конкретно его по VPN, для пулов по аналогии.
Со стороны домена это выглядит так:

IP необходимо преобразовать в HEX на любом IP калькуляторе, можно конечно создать и любые свои атрибуты для ldap, через редактор атрибутов, но для ускоренного описания будем использовать стандартные.

*данные опции станут доступны после настройки samba4, необходимо не забыть раскомментировать секцию ldap в /etc/freeradius/sites-enabled/default

4) SAMBA 4

*краткая справка

Для начала установим все необходимое:

apt-get install krb5-user libpam-krb5 samba winbind libnss-winbind libpam-winbind -t wheezy-backports

Настройки samba находятся в файле /etc/samba/smb.conf

[global]
     obey pam restrictions = Yes
     log file = /var/log/samba/log.%m
     log level = 1
     socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192

     encrypt passwords = yes

     idmap config * : range = 10000-20000
     idmap config * : backend = tdb

     auth methods = winbind
     name resolve order = hosts bcast lmhosts

     case sensitive = no
     dns proxy = no
     netbios name = SAMBA
     server string = %v samba
     password server = DC02.KR.LOC

     # обязательно указывать имя домена в верхнем регистре
     realm = KR.LOC
     client use spnego = yes
     client signing = yes
     local master = no
     domain master = no
     preferred master = no
     workgroup = KR
     debug level = 2

    # ads указывает что авторизация проходит на уровне домена
     security = ads
     unix charset = UTF-8
     dos charset = 866
     max log size = 50
     os level = 0
     follow symlinks = yes

     winbind uid = 10000-20000
     winbind gid = 10000-20000
     winbind enum groups = yes
     winbind enum users = yes

Теперь настроим winbind (позволяет Самбе узнавать пользователей AD и общаться с ними как с локальными).
Нам необходимо отредактировать фаил /etc/nsswitch.conf , добавляем в него:

passwd:         compat  winbind
group:          compat  winbind
shadow:         compat  winbind

Осталось настроить Kerberos (используется для интеграции Samba в Active Directory)
Приводим фаил /etc/krb5.conf к виду

    [logging]
    default = FILE:/var/log/krb5.log
    kdc = FILE:/var/log/krb5kdc.log

    [libdefaults]
    default_realm = KR.LOC

    clockskew = 500
    dns_lookup_realm = false
    dns_lookup_kdc = true
    ticket_lifetime = 324000

    [realms]
    KR.LOC = {
    kdc = DC02.KR.LOC
    admin_server = DC02.KR.LOC
    default_domain = KR.LOC
    }

    [domain_realm]
    .kr.loc = KR.LOC

    [login]
    krb4_convert = true
    krb4_get_tickets = false

Конфиги поправлены, можно перезапустить сервисы:

service samba restart
service winbind restart

Проверяем для своего доменного пользователя:

kinit sf-test@KR.LOC

Получаем запрос на ввод пароля, вводим.

Password for sf-test@KR.LOC:

Если все ОК, вывода на экран не будет, если все-же что-то выводит, внимательно читаем и правим ошибки в конфиге.
Считаем что у вас все хорошо и вводим сервер в домен

net join –U sf-test@KR.LOC

Проверим работу winbind:

wbinfo -u
wbinfo -g

В выводе должны видеть список доменных пользователей и групп.

Что бы проверить воспринимаются ли доменные пользователи как локальные, можно воспользоваться командой:

id domain_user

Проверяем работу модуля аутентификации (логин/пароль/домен — естественно свои)

ntlm_auth --request-nt-key --domain=KR.LOC --username=sf-test --password=123456789

Получили OK, значит можно раскомментировать в конфиге радиуса модуль ldap или ntlm_auth (если не нужны доменные группы), перезапускать freeradius и наслаждаться работой VPN сервера с учетками домена, но для успокоения совести проверим что радиус авторизирует доменных пользователей:

radtest -t mschap sf-test 123456789 127.0.0.1 0  Radius-Sicret

Теперь можно создавать VPN подключение у себя и проверять всю связку.

5) Бонус

Пролистывая заметку еще раз посмотрел на схему сети и вспомнил, что у нас есть соединения site-to-site для IPsec — это так-же удобно если пользователям ВПН необходимо давать доступ в другие сети, все это реализовано фаирволом, но пример настройки strongswan для такого соединения привожу ниже.

conn juniper
        forceencaps=yes
        dpddelay=30 # Dead peer detection - 30 секунд - интервал между keep-alive пакетами
        dpdtimeout=120 # dpd таймаут 120 секунд, после которого хост будет объявлен недоступным
        # IKE alg 3DES - HASH sha1 - DH group 2 (1024)
        ike=3des-sha1-modp1024
        # IKE lifetime 86400 seconds (24 hours)
        ikelifetime=86400s
        # IKE auth method Pre-Shared Key (PSK secret)
        authby=secret
        # IPSec type tunnel
        type=tunnel # режим - туннель
        #left side (myside)
        left=ХХ.УУ.1.99 # OpenSWAN side
        leftsubnet=10.65.0.0/16 #наши локальные сети, которые мы экспортируем удаленному маршрутизатору
        right=ХХ.УУ.116.5 #Удаленный маршрутизатор
        rightsubnet=192.168.105.0/24 #Сети с удаленного маршрутизатора, которые доступны пользователям нашего VPN
        auto=start
	esp=3des-sha1,3des-md5
	keyexchange=ikev1

Заключение.

Надеюсь все получилось с первого раза и сразу заработало, если это не так — задавайте вопросы в комментариях. Автор паталогически безграмотен, если увидели ошибку, опечатку, не однозначность или любой другой момент, мешающий восприятию заметки — просьба сообщать в личку. Всем спасибо за потраченное время.

В Mikrotik ROUTER OS, как и во всех маршрутизаторах mikrotik — будь-то Mikrotik RouteBoard RB493AH или Mikrotik RouterBoard 750G,  под PPP отвели целый раздел.

 Рис. 1. PPP интерфейсы.

PPP Server и PPP Client

PPP (англ. Point-to-Point Protocol) – протокол точка – точка.

С его помощью можно организовать связь между двумя узлами. Но протокол уже не новый и в ETHERNET сетях не применяется.

Ethernét — технология передачи данных, основанная на передаче пакетов между узлами. Её используют мобильные операторы для подключения пользователя к мобильному интернету..

PPTP Server и PPTP Client

Вот это по нашей части. PPTP (англ. Point-to-point tunneling protocol)  — тоже протокол точка – точка, но туннельный. С его помощью можно создать защищенное соединение с сервером посредством создания специального туннеля в стандартной, незащищённой сети. Очень часто используется в ETHERNET сетях для предоставления доступа в Интернет.

L2TP Server и L2TP Client

L2TP (англ. Layer 2 Tunneling Protocol) — это сетевой протокол сочетающий в себе два протокола: L2F (разработчик Cisco) и PPTP (разработчик Microsoft).

OVPN Server  и OVPN Client

OpenVPN – это свободная реализация VPN (в отличии от PPTP и L2TP). Не поддерживается OS Windows по умолчанию. Придётся скачивать дополнительное ПО.

PPPoE Server и PPPoE Client

PPPoE (англ. Point-to-point protocol over Ethernet) – ещё один сетевой протокол, протокол канального уровня.

Перейдём к настройкам. Так как самые распространенные протоколы — это PPTP и PPPoE, то для них и будем настраивать сервер и клиент.

Переходим к настройке PPPoE Server-а.

 Рис. 2. Включаем PPPoE сервер.

Для того чтобы включить PPPoE сервер в Mikrotik, необходимо перейти на вкладку PPPoE Server и, как обычно, нажать плюс. После чего появится окно настроек PPPoE Server-a.

Service Name  — здесь можно оставить без изменений, или ввести свое название.

Interface – выбираем интерфейс, на котором PPPoE Server будет ожидать подключения от PPPoE Client. Обычно, это сетевой адаптер, который смотрит в локальную сеть.

Max MTU – без изменений.

Max MRU — без изменений.

MRRU — без изменений.

Keepalive Timeout — без изменений.

Default Profile – по умолчанию в Mikrotik ROUTER OS можно выбрать два профиля. Выберем default.

One Session Per Host и Max Sessions – тоже оставим без изменений.

Переходим к Authentication.

Authentication – это протоколы проверки подлинности.

PAP (англ. Password Authentication Protocol) — протокол проверки подлинности, проверяет верны ли отправленные имя и пароль на сервер удалённого доступа.

CHAP (англ. Challenge Handshake Authentication Protocol) — широко распространённый протокол, в нём серверу передается не сам пароль пользователя, а косвенные сведения о нём.

MS-CHAP (англ. Microsoft Challenge Handshake Authentication Protocol) — протокол от разработчиков Microsoft для выполнения проверки подлинности удалённых компьютеров.

Если вы уверенны, что будете использовать только один протокол, то лишние можно убрать, если же нет — то оставляем без изменений.  Нажимаем ОК. PPPoE Server готов!

Рис. 3. Список PPPoE Серверов.

Вот мы и настроили наш PPPoE Server, это оказалось совсем не сложно. Как обычно, благодаря  Mikrotik Router OS у нас есть возможность быстро настроить на маршрутизаторе нужную нам функцию. Хоть Mikrotik Router OS и основана на ОС Linux, если бы мы настраивали PPPoE Server не на Mikrotik Router OS, а на любой другой ОС Linux — мы бы так легко не отделались.

PPTP Client

Рис. 4. Добавляем PPTP Client.

Чтобы добавить PPPTP Client, выполняем все те же простые действия. Нажимаем плюс и в появившемся списке интерфейсов выбираем PPTP Client.

Рис. 5. PPTP Client General.

В появившемся окне, если есть желание, можно изменить параметр NAME; остальное оставляем без изменений и переходим на вкладку Dial Out.

Рис. 6. PPTP Client Dial Out.

На вкладке Dial Out в поле Connect To нужно ввести IP адрес PPTP сервера. User и Password – это логин и пароль для подключения к серверу. Все остальное можно оставить так, как есть. Единственное, что еще стоит сделать, это поставить галочку напротив Add Default Route. Это избавит нас от необходимости прописывать маршрут вручную. Нажимаем Apply, смотрим: если в нижнем правом углу статус стал connected, значит мы всё сделали верно.

PPTP Server

PPTP Server – настраивается также просто, как и PPPOE Server.

Рис. 7. Новый PPTP Server.

Жмём кнопку PPTP Server.

Рис. 8. Окно настройки PPTP сервера.

В появившемся окне ставим галочку напротив Enabled, жмем ОК. Всё, сервер настроен.

Теперь нужно добавить пользователей для нашего сервера. Переходим в раздел Secrets.

Рис.9. Добавляем пользователя.

Тут всё просто: Name – имя пользователя, Password – пароль. Выбираем профиль или оставляем без изменения. Например, если мы выбрали подсеть 172.16.1.0/24, то Local Address для всех пользователей будет одинаковый 172.16.1.1, а Remote Address у каждого свой. Вот и всё.

Евгений Рудченко специально для asp24

PPP (протокол «точка-точка») является наиболее широко используемым методом транспортировки IP-пакетов по последовательной связи между пользователем и поставщиком интернет-услуг (ISP). Хотя PPP в первую очередь используется по коммутируемым линиям, такие варианты, как PPoE (PPP over Ethernet ) и PPoA (PPP over ATM), расширяют PPP до новых протоколов уровня канала передачи данных.

PPP был разработан для обеспечения возможности передачи разных протоколов по одной двухточечной линии связи путем использования инкапсуляции. Инкапсуляция — это процесс хранения пакетов из внешнего протокола внутри кадров PPP. PPP также установил стандарт для назначения и управления IP-адресом, синхронной (старт-стоп) и бит-ориентированной синхронной инкапсуляции, мультиплексирования сетевых протоколов, конфигурации ссылок, тестирования качества связи, обнаружения ошибок и согласования опций для таких возможностей, как сетевой уровень согласование адресов и согласование сжатия данных. PPP поддерживает эти функции, предоставляя расширяемую программу управления каналами (LCP) и семейство Network Control Program (NCP) для согласования дополнительных параметров конфигурации и средств. В дополнение к IP, PPP поддерживает другие протоколы, включая Novell Internetwork Packet Exchange (IPX) и DECnet.

Компоненты PPP

PPP предоставляет метод для передачи дейтаграммы по последовательному каналу «точка-точка». PPP содержит три основные функции:

• Метод инкапсуляции дейтаграммы через последовательные ссылки. PPP использует протокол управления каналом высокого уровня (HDLC) в качестве основы для инкапсуляции дейтаграммы по каналам «точка-точка».
• Протокол управления связью (LCP) для установления, настройки и тестирования соединения с каналом передачи данных.
• Набор протоколов сетевого управления (NCP) для установления и настройки различных протоколов сетевого уровня. PPP предназначен для одновременного использования многочисленных протоколов сетевого уровня.

Операция PPP

Чтобы установить связь по каналу «точка-точка», инициирующий PPP сначала отправляет кадры LCP для настройки и тестирования канала данных. После установления связи и согласования дополнительных объектов с использованием LCP исходный PPP отправит кадры NCP для выбора и настройки одного или нескольких протоколов сетевого уровня. После конфигурирования каждого уровня сетевого протокола могут быть переданы пакеты пакетов каждого сетевого уровня, и связь будет оставаться настроенной, и пакеты могут быть отправлены по этим ссылкам. Ссылка останется сконфигурированной для связи до тех пор, пока не будут закрыты обычные LCP или NCP-фреймы, а также некоторые внешние события, такие как таймер неактивности, истекает или пользователь вмешивается.

Требования к физическому уровню

PPP способен работать через любой интерфейс DTE / DCE. Примеры включают EIA / TIA 232 C (ранее RS 232 C), EIA / TIA 422 (ранее RS 422), EIA / TIA 423 (ранее RS 423 (ранее RS 423) и Сектор стандартизации электросвязи в телекоммуникационном секторе (ITU-T) ранее CCITT) V.35. ППК имеет абсолютное требование — обеспечивает дуплексную схему, выделенную или коммутируемую, которая может работать либо в асинхронном, либо в синхронном режиме, который является прозрачным для кадров канального уровня PPP. Однако PPP не налагает никаких ограничений в отношении скорости передачи кроме наложенных для конкретного используемого интерфейса DTE / DCE.

PPP Link Layer

ППС использует принципы, терминологию и структуру кадров процедур HDLC Международной организации стандартизации (ISO) (ISO 3309-1979), модифицированных ISO 3309-948 / PDADI «Добавление 1 Пуск / остановка передачи. В стандарте ISO 3309-1979 показана структура кадра HDLC для использования в синхронных средах. ISO 3309: 1984 / PDADI определяет предлагаемые модификации стандарта ISO 3309-1979, позволяющие использовать его в асинхронных средах. В процедурах управления PPP используются определения и кодировки полей управления, идентичные ISO 4335-1979 / Addendum 1-1979.

Формат кадра PPP отображается в шести полях. В следующих описаниях суммируются поля кадра PPP:

• Флаг: один байт, указывающий начало или конец кадра. Поле флага состоит из двоичной последовательности 011111110.
• Адрес: один байт содержит двоичную серию, такую ​​как 11111111, и стандартный широковещательный адрес. PPP не назначает адреса отдельных станций.
• Управление: один байт, который имеет двоичную последовательность 00000011, используемый для передачи пользовательских данных в рамку без последовательности. Предоставлена ​​услуга связи без установления соединения, аналогичная службе управления логической связью (LLC) типа 1.
• Протокол: два байта, которые распознают протокол, суммированный в поле порядка в кадре. В целом современные принципы поля протокола указаны в самом последнем запрошенном запросе для комментариев (RFC).
• Данные: нулевой или более байт, который содержит дейтаграмму для протокола, указанного в поле протокола, определяется путем определения последовательности закрытия флага и разрешения 2 байта для поля FCS. Максимальная длина по умолчанию для игрового поля информации составляет 1500 байтов. Превосходящее соответствие, приемлемые реализации PPP могут использовать другие значения для максимального объема информационного поля.
• Frame Check Sequence (FCS): обычно 16 бит (2 байта). Следуя предыдущему соглашению, принятие реализации PPP будет использовать 32-битную (4 байта) FCS для лучшего обнаружения ошибок.

Протокол PPP Link-Control

PPP LCP предоставляет способ установления, настройки, поддержки и завершения соединения между двумя точками. LCP проходит через четыре различные фазы:

• Во-первых, происходит арбитраж организации и конфигурации. Перед тем, как можно обменять дейтаграмму сетевого уровня (например, IP), сначала LCP должен открыть соединение и согласовать параметры конфигурации. Эта фаза завершается, когда кадр подтверждения подтверждения отправлен и принят.
• Затем следует определение качества ссылки. LCP позволяет измерять силу выборки по уровню связи в фазе разума после этапа соединения и схемы арбитража. В этом разделе используется ссылка, чтобы решить, достаточно ли значения ссылки для создания протоколов сетевого уровня. Эта фаза не обязательна. LCP может отменить передачу информации протокола сетевого уровня до завершения этого этапа.
• Конфигурация протокола сетевого уровня может возникнуть после того, как LCP завершит этап определения качества связи, а протоколы сетевого уровня могут быть настроены отдельно, используя хорошее использование NCP и могут быть в любое время вверх и вниз. В то время как ссылка выбора LCP будет сообщать протоколу сетевого уровня, необходимо предпринять необходимые действия.
• Наконец, происходит прекращение соединения, LCP может в любой момент завершить соединение. Это часто делается по просьбе пользователя, но может произойти из-за физического события, такого как потеря носителя или завершение таймера простоя.

Контрольные сообщения LCP

LCP выполняет эти задачи с помощью простых управляющих сообщений:

Связь Конфигурационные сообщения, используемые для установки и настройки ссылки:

• Настройка-Request
• Настройка-Ack
• Настройка-ОПП
• Настройка-Reject

Сообщения о завершении связи, используемые для прекращения связи:

• Terminate-Request
• Terminate-Ack

Сообщение об обслуживании связи, используемое для управления и отладки ссылки:

• Code-Reject
• Протокол-Reject
• Echo-Request
• Echo-Reply
• Выбросьте-Request

PPP NCP

Протокол PPP должен быть определен для каждого типа сетевого пакета, который должен быть инкапсулирован и передан по линии PPP.

Некоторые из определенных PPP NCP:

• Протокол управления протоколом Интернета
• Протокол управления сетевым уровнем OSI
• Протокол управления IDP Xerox NS
• Протокол управления DECnet Phase IV
• Протокол управления Appletalk
• Протокол управления Novell IPX
• Мост NCP
• Протокол управления потоковым протоколом
• Протокол контроля Banyan Vines
• Протокол управления несколькими каналами
• Протокол управления сетью NETBIOS
• Протокол Cisco Systems Control Protocol
• Ascom Timeplex
• Протокол управления LBLB Fujitsu
• DCA Remote Lan Network Control Protocol (RLNCP)
• Протокол управления последовательными данными (PPP-SDCP)
• Протокол SNA по протоколу 802.2
• Протокол контроля SNA
• Протокол управления сжатием заголовка IP6
• Протокол управления мостом Stampede
• Сжатие по одной ссылке в групповой группе
• Протокол управления сжатием

Стандарты PPP официально описаны в RFC 1661: The Point-to-Point-Protocol (PPP).