Настройка VPN сервера LINUX PPPD + POPTOP
Материал из BiTel WiKi
Admin (Обсуждение | вклад) |
Haku-nk (Обсуждение | вклад) м (→Полезное) |
||
(7 промежуточных версий не показаны.) | |||
Строка 1: | Строка 1: | ||
+ | == Установка и настройка == | ||
Это работа '''Vladisson''' a, текст приведен полностью с сохранением авторской стилистики. | Это работа '''Vladisson''' a, текст приведен полностью с сохранением авторской стилистики. | ||
Только исправлены некоторые частности про настройку SNMP, изменившиеся к 3.0. | Только исправлены некоторые частности про настройку SNMP, изменившиеся к 3.0. | ||
Строка 128: | Строка 129: | ||
Усе!!!! Если возникнут какие нит вопросы обращайтесь к разработчикам и ко мне мой мыл "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''' — это ''как бы'' "set", он же первый параметр ($1), передаваемый скрипту; | ||
+ | * '''11111''' — это ''как бы'' MIB ($2); | ||
+ | * '''integer''' — это как бы тип переменной ($3), которая передаётся скрипту, | ||
+ | * '''15190''' — это пид процесса ($4), так если собственно значение.<br /> | ||
+ | Вообще, для проверки скрипта нужно указать только первый и четвёртый параметры, но остальные должны присутствовать, цифрового или текстового вида.<br /> | ||
+ | Переходим на второй терминал, команда ''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 | ||
+ | <font color="red">Timeout: No Response from 127.0.0.1</font> | ||
+ | — это может означать не только потерю связи или останов 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 функционируют на разных машинах (имя_интерфейса — интерфейс(ы) через которые идёт обмен по 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''' — пид процесса сессии. |
Текущая версия на 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 — пид процесса сессии.