Subnets.ru blog

В продолжении статьи PPPoE сервер на встроенном в FreeBSD демоне pppoed рассмотрим ситуацию с LCP и LQR.

Немного теории:

LCP — сокращение от Link Control Protocol — протокол управления соединением.

LCP является частью протокола Point-to-Point.
При установлении соединения PPP передающее и принимающее устройство обмениваются пакетами LCP для уточнения специфической информации, которая потребуется при передаче данных.
Согласование параметров соединения проводится в форме переговоров.
LCP протокол осуществляет:

• проверку идентификации соединяемых устройств и, вследствие этого разрешает или отклоняет установку соединения
• определение приемлемого размера кадров для передачи MTU и приёма — MRU
• ограничение по ширине канала
• шифрование аутентификации соединения
• сжатие данных
• обнаружение петель маршрутизации
• проверку синтаксиса и поиск ошибок в конфигурации
• разрыв соединения, если какое-либо значение превышает заданный параметр

Устройства не могут передавать данные друг другу по сети прежде чем LCP пакеты не определят доступность устанавливаемого соединения.

LQR — Link Quality Report так же является частью протокола Point-to-Point и нужен для оценки состояния и качества связи PPP.

Если вы используете демон pppoed под FreeBSD, то в логах /var/log/ppp.log вам могут встречаться такие строки:

Apr 5 12:16:41 vpn-01 ppp[3951]: tun1: Warning: lqr_RecvEcho: Got sig 0x22c61241, not 0x594e4f54 !

 .... 

Apr 5 12:17:01 vpn-01 ppp[3951]: tun1: Phase: deflink: ** Too many LCP ECHO packets lost **

Первая строка говорит о том что lqr.magic в полученном пакете не верен.

Вторая строка появится после того как вы 5-ть раз увидете по данному туннелю первую строчку и затем данный туннель будет отключен принудительно.

Затем юзер реконнектнется и все повторится с начала…. и так до бесконечности.

Причина такого поведения в том, что некоторые производители домашних роутеров срут на стандарты при реализации протокола и отсюда все проблемы.

 

Что же с этим делать ?

Вариантов несколько:

1. отключить LQR совсем
2. позвонить пользователю и сказать что его роутер не годен для работы в вашей сети
3. ковырять и править исходники ppp

Отключать LQR совсем не вариант, т.к. тогда зависший туннель точно никогда не отвалится, а это не есть гуд. Предлагать пользователю сменить роутер равнозначно предложить ему сменить провайдера.

Получается что остается один вариант —  ковырять исходники ppp и нужно сделать так, чтобы  не было реагирования на состав меджика.

Для FreeBSD 8.2 это будет происходить так:

Идем в сорцы /usr/src/usr.sbin/ppp/ и находим в этой папке файл lqr.c.
Правим его, diff можно увидеть тут. А именно просто комментарим тот IF, который проверяет меджик, выводит нам сообщение и не увеличивает каунтер полученных LCP пакетов.

Затем делаем make и после чего в /usr/obj/usr/src/usr.sbin/ppp появится вновь собранный файл ppp.
Теперь наша задача плавно перевести пользователей на вновь собранный демон, т.к. тупо заменить им текущий может и не получится в виду того, что на каждый PPPoE туннель создается отдельный процесс:

97011 ?? Ss 0:03,33 /usr/sbin/ppp -direct pppoe

и фря может отказать вам в замене файла.

То у нас три варианта:

• перезапустить сервер
• убить все процессы ppp
• вызывать новый ppp только при новых подключениях

Действуем по последнему варианту, т.к. это позволит плавно перевести пользователй, ведь рано или поздно все переподключатся и мы сможем заменить старый /usr/sbin/ppp.

Берем новый ppp и копируем в /usr/sbin/ppp.new.

Не забудьте выставить владельца и права на новый файл так же как это было у старого:

-r-sr-x---  1 root  network  412608 26 Apr 13:14 /usr/sbin/ppp

# chmod 4550 /usr/sbin/ppp.new
# chgrp network /usr/sbin/ppp.new

Затем убиваем все процессы pppoed и стартуем их снова, но чуть изменив строку запуска:

# /usr/libexec/pppoed -a vpn-01 -p "*" -e "/usr/sbin/ppp.new -direct pppoe" em1

Что при подключении пользователя запустит уже не /usr/sbin/ppp, а /usr/sbin/ppp.new.

После того как все готово можно посмотреть как подключаются пользователи и убедиться в том, что Warning: lqr_RecvEcho более не появляется, а пользователи, которые из-за этого отваливались, более не отваливаются.

Как только процессов ppp не останется, мы сможем заменить старый новым и вернуть строку запуска pppoed к прежней.

Ещё одно полезное дополнение для pppoed это дополнить информацию в его логах.

По дефотлу подключение клиента в /var/log/pppoed.log выглядит так:

Apr 5 09:34:19 vpn-01 pppoed[58768]: Listening as provider * 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Offering to .:exec-58904 as access concentrator vpn-01 

Apr 5 09:34:19 vpn-01 pppoed[58904]: adding to .:exec-58904 as offered service vpn-01 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SESSIONID (hook "^C") 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SUCCESS (hook "exec-58904") 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Executing: exec /usr/sbin/ppp -direct pppoe

Но можно получить больше информации в лог. Наложив вот этот патч можно добавить чтобы в логе отображался мак клиента и интерфейс откуда пришел запрос:

Apr 5 09:00:52 vpn-01 pppoed[73025]: Offering to .:exec-73025 as access concentrator vpn-01 at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: adding to .:exec-73025 as offered service vpn-01 at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SESSIONID (hook "ü ÿÿÿ^?") [40:4a:03:a8:e3:a0] at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SUCCESS (hook "exec-73025") [40:4a:03:a8:e3:a0] at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Executing: exec /usr/sbin/ppp -direct pppoe for .:exec-73025: [40:4a:03:a8:e3:a0] at [vlan65]

Так становится более понятнее о том к какому клиенту относятся строчки в логе и за каким интерфейсом сервера расположен клиент.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Авторы: Николаев Дмитрий (virus (at) subnets.ru) и Панфилов Алексей (lehis (at) subnets.ru)

Похожие статьи:

Не найдено