Настройка VPN сервера LINUX PPPD + POPTOP

Материал из BiTel WiKi

(Различия между версиями)
Перейти к: навигация, поиск
м (Полезное)
 
(8 промежуточных версий не показаны.)
Строка 1: Строка 1:
 +
== Установка и настройка ==
Это работа '''Vladisson''' a, текст приведен полностью с сохранением авторской стилистики.  
Это работа '''Vladisson''' a, текст приведен полностью с сохранением авторской стилистики.  
Только исправлены некоторые частности про настройку SNMP, изменившиеся к 3.0.
Только исправлены некоторые частности про настройку SNMP, изменившиеся к 3.0.
Строка 122: Строка 123:
Расположение и настройки в конфигах были сделаны применительно к моей системе возможно кому то потребуется дополнительная правка.  
Расположение и настройки в конфигах были сделаны применительно к моей системе возможно кому то потребуется дополнительная правка.  
-
И не забудьте создать '''/local/utils/passtest.sh'''  
+
И не забудьте создать '''/local/utils/passtest.sh''', вы можете взять его здесь: [[Медиа:pppd_passtest.zip]]
 +
 
 +
В скрипте отредактируйте название файла вашего pppd.
 +
Для сброса клиента с линии и проверки по SNMP используется код приходящий в старт пакет радиуса Acct-Session-Id=00005AB3, здесь 00005AB3 - шестнадцатиричный код pppd процесса на Unix'e.
 +
 
Усе!!!! Если возникнут какие нит вопросы обращайтесь к разработчикам и ко мне мой мыл "vladisson@rbcmail.ru icq 96029701" и смотрите топик "Проблема с SNMP" и другие и не стесняйтесь задавать вопросы
Усе!!!! Если возникнут какие нит вопросы обращайтесь к разработчикам и ко мне мой мыл "vladisson@rbcmail.ru icq 96029701" и смотрите топик "Проблема с SNMP" и другие и не стесняйтесь задавать вопросы
 +
 +
== Тестирование "сброса с линии" ==
 +
Если у Вас получилась установка с первого раза и всё заработало как надо — можете не читать эту часть статьи. Если же "абонент не сбрасывается с линии", как часто форумчане задают этот вопрос, читаем сей небольшой мануал.
 +
 +
=== Этап 1. passtest.sh ===
 +
Для начала тестируем как сам скрипт будет убивать "процесс", а для этого будем его запускать как бы "от лица" snmpd.<br />
 +
На машине, где установлен passtest.sh, открываем второй терминал и запускаем на ней "подопытный" процесс, пускай это будет ''top'':
 +
$ top
 +
Выясняем его пид:
 +
$ ps -e |grep top
 +
    15190 pts/1    00:00:00 top
 +
Вот он: '''15190''' . Теперь запускаем сам скрипт с параметрами:
 +
 +
# passtest.sh -s 11111 integer 15190
 +
, где:
 +
* '''-s''' &mdash; это ''как бы'' "set", он же первый параметр ($1), передаваемый скрипту;
 +
* '''11111''' &mdash; это ''как бы'' MIB ($2);
 +
* '''integer''' &mdash; это как бы тип переменной ($3), которая передаётся скрипту,
 +
* '''15190''' &mdash; это пид процесса ($4), так если собственно значение.<br />
 +
Вообще, для проверки скрипта нужно указать только первый и четвёртый параметры, но остальные должны присутствовать, цифрового или текстового вида.<br />
 +
Переходим на второй терминал, команда ''top'' в нём должна завершиться. Если работа ''top'' не завершилась &mdash; смотрим лог скрипта и анализируем как он работает.
 +
 +
Когда отладка закончена и любой процесс посредством passtest.sh завершается, переходим на уровень выше &mdash; '''snmp'''.
 +
 +
=== Этап 2. snmpd - testpass.sh ===
 +
Для теста на этом этапе нужно чтобы:
 +
* демон snmpd был сконфигурирован и работал от имени root`а (иначе не закроет процесс top, запущенный от имени root`а) ,
 +
* bgradius_dialup должен быть отключён, дабы не мешался.
 +
Открываем второй терминал, запускаем всё тот же ''top'', выясняем его пид:
 +
$ ps -e |grep top
 +
  18011 pts/1    00:00:00 top
 +
В первом терминале запускаем запрос "как бы" от имени bgradius_dialup:
 +
# snmpset -v2c -c secret 127.0.0.1 .1.3.6.1.4.1.2021.255.1 i 18011
 +
  UCD-SNMP-MIB::ucdavis.255.1 = INTEGER: 15379
 +
здесь:
 +
* '''-v2c''' &mdash; версия по которой взаимодействуем по snmp;
 +
* '''secret''' &mdash; "секрет", используемый для доступа к ресурсу snmp (в конфиге выше это &mdash; "secret" он присутствует в первой строке snmpd.conf);
 +
* '''127.0.0.1''' &mdash; адрес, где работает snmpd;
 +
* '''.1.3.6.1.4.1.2021.255.1''' &mdash; MIB;
 +
* '''i''' &mdash; даёт понять демону, что параметр типа ''integer'' (целый, число),
 +
* '''18011''' &mdash; собственно параметр и он же &mdash; пид процесса который надо завершить.
 +
 +
Вторая строка &mdash; ответ snmpd. Если всё сконфигурировано правильно, процессс top во втором терминале должен завершиться.
 +
 +
Возможен вариант, что в процессе выполнения, в логе snmpd и в стандартном выводе будет много строк типа:
 +
...
 +
Cannot find module (SNMPv2-TC): At line 15 in /usr/share/mibs/netsnmp/UCD-DISKIO-MIB
 +
Cannot find module (SNMPv2-SMI): At line 34 in /usr/share/mibs/netsnmp/UCD-SNMP-MI
 +
Undefined identifier:...
 +
это означает, что в пакете net-snmp нет нужных MIB`ов. Для решения данной проблемы, читаем статью "[[Проблема с прохождением update пакетов и сброса сессий в Debian и Ubuntu дистрибутивах]]".
 +
 +
При выполнении команды возможен ответ:
 +
# snmpset -v2c -c secret 127.0.0.1 .1.3.6.1.4.1.2021.255.1 i 18011
 +
  <font color="red">Timeout: No Response from 127.0.0.1</font>
 +
&mdash; это может означать не только потерю связи или останов snmpd, но также и неправильно указанный в команде "секрет".
 +
 +
Когда взаимодействие по snmp отлажено, можно запустить сервис bgradius_dialup, затем проверить локальную (или общую) конфигурацию NAS`а на предмет правильности установки параметров для соединения с snmpd:
 +
 +
#SNMP порт и пароль (не нужны для PoD инспектора)
 +
nas.inspector.snmp.port=161
 +
nas.inspector.snmp.community=<font color="red">secret</font>
 +
#входящий буфер в мегабайтах
 +
nas.inspector.snmp.buffer.in=4
 +
#исходящий буфер в мегабайтах
 +
nas.inspector.snmp.buffer.out=4
 +
#
 +
# Конфигурация непосредственно для PPPD DialUp Linux
 +
snmp.version=2
 +
#возможные значения 2.4.2 и 2.4.3, для 2.4.4 указывается версия 2.4.3
 +
pppd.version=2.4.2
 +
nas.inspector.class=ru.bitel.bgbilling.kernel.network.radius.inspectors.SNMPNasConnectionInspectorPPPD
 +
nas.inspector.snmp.kill.oid=1.3.6.1.4.1.2021.255.1
 +
nas.inspector.snmp.check.oid=1.3.6.1.4.1.2021.255
 +
 +
, и перейти к проверке работы связки ''bgradius_dialup'' --> ''snmpd'' --> ''testpass.sh''
 +
 +
=== Этап 3. bgradius_dialup - snmpd - testpass.sh ===
 +
Если параметры для соединения с NAS`ом (вендор\адрес\секрет) правильны и в мониторе отображается активность пользователя, пробуем это соединение "сбросить" через диалог в мониторе NAS`а, одновременно контролируя закрытие процесса pppd.
 +
[[Изображение:NAS-monitor-menu-sbrosa.jpg|thumb|left|250px|Диалог управления сессией]]
 +
Если соединение не сбрасывается, смотрим и анализируем логи bgradius_dialup, затем логи snmpd и лог passtest.sh
 +
<br clear="both"/>
 +
=== Полезное ===
 +
* Не забывайте, что для завершения процесса ''pppd'', нужны права root`а, а так как запускать ''passtest.sh'' будет ''snmpd'', то и последний должен быть запущен от имени root`а. Теоретически можно настроить и sudo.
 +
 +
* Для отладки может помочь запуск snmpd в debug-режиме (пути к файлам поставьте свои):
 +
# /usr/local/sbin/snmpd -V -a -f -q -d -c /usr/local/etc/snmp/snmpd.conf
 +
 +
* Также для отладки иногда полезно "прослушать" интерфейс на предмет пакетов с\на 161-й порт:
 +
для случая, если взаимодействие bgradius_dialup <--> snmpd происходит через локальный интерфейс:
 +
# tcpdump -i lo -n port 161
 +
 +
для варианта когда bgradius_dialup и snmpd функционируют на разных машинах (имя_интерфейса &mdash; интерфейс(ы) через которые идёт обмен по snmp между машинами):
 +
# tcpdump -i имя_интерфейса -n port 161
 +
 +
Процесс "сброса" (при прослушивании интерфейса) выглядит примерно так:
 +
<pre>
 +
# tcpdump -i lo -n port 161
 +
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 +
  listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
 +
  07:49:18.564320 IP 127.0.0.1.59346 > 127.0.0.1.161:  C=secret SetRequest(29)  .1.3.6.1.4.1.2021.255.1=18113
 +
  07:49:18.576595 IP 127.0.0.1.161 > 127.0.0.1.59346:  C=secret GetResponse(29)  .1.3.6.1.4.1.2021.255.1=18113
 +
</pre>
 +
здесь '''18113''' &mdash; пид процесса сессии.

Текущая версия на 16:54, 24 июня 2011

Содержание

Установка и настройка

Это работа Vladisson a, текст приведен полностью с сохранением авторской стилистики. Только исправлены некоторые частности про настройку SNMP, изменившиеся к 3.0.

Качаем откуда нить ppp-2.4.2 или более старшую. Я использую ppp-2.4.2b3 далее

./configure

после

/make

Если возникли ошибки при компиляции связанные с радиусклиентом то находим в Makefile в каталоге pppd-2.4.2/pppd/plugins/radius/radiusclient код

cd $(top_srcdir) && $(AUTOHEADER)

И делаем просто

cd $(top_srcdir)

После ./make для пакета.

Должно скомпилиться дальше

./make install

Далее находим "poptop-1.1.4" (он поднимает VPN тунель) собираем

./configure

Компилим

./make

Инсталим

./make install

Потом качаем net-snmp-5.1.2 (найти легко), собираем компилим инсталим как и предыдущие

Привожу мои конфиги для pppd они у меня лежат в /etc/ppp

Файл options lock

Файл options.pptpd

ipparam PoPToP 
   lock 
   mtu 1490 
   mru 1490 
   ms-dns 195.151.116.2 # ТУТ должен быть указан ваш DNS сервер
   lcp-echo-interval 30
   lcp-echo-failure 5
   proxyarp 
   auth 
   -pap 
   +chap 
   ipcp-accept-local 
   ipcp-accept-remote 
   deflate 0 
   plugin radius.so  

теперь конфиги для радиусклиента т.к он кенектится к радиус серверу билинга конфиги лежат у меня в /etc/radiusclient файл servers

#Server Name or Client/Server pair Key
   #---------------- --------------- 
   #portmaster.elemental.net hardlyasecret 
   #portmaster2.elemental.net donttellanyone 

127.0.0.1 123456 # это пароль для подключения к радиус серверу, он был описан выше 

файл radiusclient.conf

auth_order radius
   login_tries 4
   login_timeout 60
   nologin /etc/nologin
   authserver 127.0.0.1
   acctserver 127.0.0.1
   servers /etc/radiusclient/servers
   dictionary /etc/radiusclient/dictionary
   seqfile /var/run/radius.seq
   mapfile /etc/radiusclient/port-id-map
   default_realm
   radius_timeout 10
   radius_retries 3

теперь конфигурация pptpd у меня лежит в /etc файл pptpd.conf

speed 115200
   option /etc/ppp/options.pptpd
   pidfile /var/run/pptpd.pid
   debug
   localip 192.168.3.500
   remoteip 192.168.3.501-250

ипы поменяете на свои и на последок конфиги snmp у меня лежат в /etc/snmp

com2sec billing X.X.X.X secret
com2sec local localhost public

group groupbill v2c billing
group groupbill v2c local

view all included .1.3.6.1.4.1.2021.255 ff.f0

# context sec.model sec.level prefix read   write notify
access groupbill ""      v2c       noauth    prefix      all    all   none

pass .1.3.6.1.4.1.2021.255 /bin/sh /local/utils/passtest.sh

Расположение и настройки в конфигах были сделаны применительно к моей системе возможно кому то потребуется дополнительная правка. И не забудьте создать /local/utils/passtest.sh, вы можете взять его здесь: Медиа:pppd_passtest.zip

В скрипте отредактируйте название файла вашего pppd. Для сброса клиента с линии и проверки по SNMP используется код приходящий в старт пакет радиуса Acct-Session-Id=00005AB3, здесь 00005AB3 - шестнадцатиричный код pppd процесса на Unix'e.

Усе!!!! Если возникнут какие нит вопросы обращайтесь к разработчикам и ко мне мой мыл "vladisson@rbcmail.ru icq 96029701" и смотрите топик "Проблема с SNMP" и другие и не стесняйтесь задавать вопросы

Тестирование "сброса с линии"

Если у Вас получилась установка с первого раза и всё заработало как надо — можете не читать эту часть статьи. Если же "абонент не сбрасывается с линии", как часто форумчане задают этот вопрос, читаем сей небольшой мануал.

Этап 1. passtest.sh

Для начала тестируем как сам скрипт будет убивать "процесс", а для этого будем его запускать как бы "от лица" snmpd.
На машине, где установлен passtest.sh, открываем второй терминал и запускаем на ней "подопытный" процесс, пускай это будет top:

$ top

Выясняем его пид:

$ ps -e |grep top
   15190 pts/1    00:00:00 top

Вот он: 15190 . Теперь запускаем сам скрипт с параметрами:

# passtest.sh -s 11111 integer 15190

, где:

  • -s — это как бы "set", он же первый параметр ($1), передаваемый скрипту;
  • 11111 — это как бы MIB ($2);
  • integer — это как бы тип переменной ($3), которая передаётся скрипту,
  • 15190 — это пид процесса ($4), так если собственно значение.

Вообще, для проверки скрипта нужно указать только первый и четвёртый параметры, но остальные должны присутствовать, цифрового или текстового вида.
Переходим на второй терминал, команда top в нём должна завершиться. Если работа top не завершилась — смотрим лог скрипта и анализируем как он работает.

Когда отладка закончена и любой процесс посредством passtest.sh завершается, переходим на уровень выше — snmp.

Этап 2. snmpd - testpass.sh

Для теста на этом этапе нужно чтобы:

  • демон snmpd был сконфигурирован и работал от имени root`а (иначе не закроет процесс top, запущенный от имени root`а) ,
  • bgradius_dialup должен быть отключён, дабы не мешался.

Открываем второй терминал, запускаем всё тот же top, выясняем его пид:

$ ps -e |grep top
  18011 pts/1    00:00:00 top

В первом терминале запускаем запрос "как бы" от имени bgradius_dialup:

# snmpset -v2c -c secret 127.0.0.1 .1.3.6.1.4.1.2021.255.1 i 18011
  UCD-SNMP-MIB::ucdavis.255.1 = INTEGER: 15379

здесь:

  • -v2c — версия по которой взаимодействуем по snmp;
  • secret — "секрет", используемый для доступа к ресурсу snmp (в конфиге выше это — "secret" он присутствует в первой строке snmpd.conf);
  • 127.0.0.1 — адрес, где работает snmpd;
  • .1.3.6.1.4.1.2021.255.1 — MIB;
  • i — даёт понять демону, что параметр типа integer (целый, число),
  • 18011 — собственно параметр и он же — пид процесса который надо завершить.

Вторая строка — ответ snmpd. Если всё сконфигурировано правильно, процессс top во втором терминале должен завершиться.

Возможен вариант, что в процессе выполнения, в логе snmpd и в стандартном выводе будет много строк типа:

...
Cannot find module (SNMPv2-TC): At line 15 in /usr/share/mibs/netsnmp/UCD-DISKIO-MIB
Cannot find module (SNMPv2-SMI): At line 34 in /usr/share/mibs/netsnmp/UCD-SNMP-MI
Undefined identifier:...

это означает, что в пакете net-snmp нет нужных MIB`ов. Для решения данной проблемы, читаем статью "Проблема с прохождением update пакетов и сброса сессий в Debian и Ubuntu дистрибутивах".

При выполнении команды возможен ответ:

# snmpset -v2c -c secret 127.0.0.1 .1.3.6.1.4.1.2021.255.1 i 18011
 Timeout: No Response from 127.0.0.1

— это может означать не только потерю связи или останов snmpd, но также и неправильно указанный в команде "секрет".

Когда взаимодействие по snmp отлажено, можно запустить сервис bgradius_dialup, затем проверить локальную (или общую) конфигурацию NAS`а на предмет правильности установки параметров для соединения с snmpd:

#SNMP порт и пароль (не нужны для PoD инспектора)
nas.inspector.snmp.port=161
nas.inspector.snmp.community=secret
#входящий буфер в мегабайтах
nas.inspector.snmp.buffer.in=4
#исходящий буфер в мегабайтах
nas.inspector.snmp.buffer.out=4
#
# Конфигурация непосредственно для PPPD DialUp Linux
snmp.version=2
#возможные значения 2.4.2 и 2.4.3, для 2.4.4 указывается версия 2.4.3
pppd.version=2.4.2
nas.inspector.class=ru.bitel.bgbilling.kernel.network.radius.inspectors.SNMPNasConnectionInspectorPPPD
nas.inspector.snmp.kill.oid=1.3.6.1.4.1.2021.255.1
nas.inspector.snmp.check.oid=1.3.6.1.4.1.2021.255

, и перейти к проверке работы связки bgradius_dialup --> snmpd --> testpass.sh

Этап 3. bgradius_dialup - snmpd - testpass.sh

Если параметры для соединения с NAS`ом (вендор\адрес\секрет) правильны и в мониторе отображается активность пользователя, пробуем это соединение "сбросить" через диалог в мониторе NAS`а, одновременно контролируя закрытие процесса pppd.

Диалог управления сессией

Если соединение не сбрасывается, смотрим и анализируем логи bgradius_dialup, затем логи snmpd и лог passtest.sh

Полезное

  • Не забывайте, что для завершения процесса pppd, нужны права root`а, а так как запускать passtest.sh будет snmpd, то и последний должен быть запущен от имени root`а. Теоретически можно настроить и sudo.
  • Для отладки может помочь запуск snmpd в debug-режиме (пути к файлам поставьте свои):
# /usr/local/sbin/snmpd -V -a -f -q -d -c /usr/local/etc/snmp/snmpd.conf
  • Также для отладки иногда полезно "прослушать" интерфейс на предмет пакетов с\на 161-й порт:

для случая, если взаимодействие bgradius_dialup <--> snmpd происходит через локальный интерфейс:

# tcpdump -i lo -n port 161 

для варианта когда bgradius_dialup и snmpd функционируют на разных машинах (имя_интерфейса — интерфейс(ы) через которые идёт обмен по snmp между машинами):

# tcpdump -i имя_интерфейса -n port 161

Процесс "сброса" (при прослушивании интерфейса) выглядит примерно так:

# tcpdump -i lo -n port 161
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
  07:49:18.564320 IP 127.0.0.1.59346 > 127.0.0.1.161:  C=secret SetRequest(29)  .1.3.6.1.4.1.2021.255.1=18113
  07:49:18.576595 IP 127.0.0.1.161 > 127.0.0.1.59346:  C=secret GetResponse(29)  .1.3.6.1.4.1.2021.255.1=18113

здесь 18113 — пид процесса сессии.

Личные инструменты