Установка, настройка и запуск
В текущий момент WiFi-агент и WiFi-портал реализованы одним приложением, которое и называется WiFi-агент. Для его установки его нужно скачать с сайта и распаковать в какую-нибудь папку .Например в папку /user/local. Далее для простоты будем считать, что мы установили в эту папку.
При установке рекомендуется идти от простого к сложному . Т.е. вначале заставить работать более простую конфигурацию, а потом уже пытаться добавлять дополнительные возможности.
Далее идут шаги, необходимые, для установки.
1) Для работы WiFi-агента нужна Java-машина;
2) Все настройки агента хранятся в файле inet_wifi_agent.properties. Вот пример этого файла :
#wifi agent class
wifi.agent.
class
=ru.bitel.bgbilling.modules.inet.wifi.InetWiFiAgent
#mq options
mq.url=failover:(nio://
127
.
0
.
0
.
1
:
61616
?socketBufferSize=
1000000
)
mq.user=bill
mq.pswd=bgbilling
#radius options
radius.auth.host=
127
.
0
.
0
.
1
radius.auth.port=
1812
radius.account.host=
127
.
0
.
0
.
1
radius.account.port=
1813
radius.nasId=den_nas
radius.secret=hello
#Слать Update-пакеты на Accounting-сервер (1 по умолчанию)
radius.update.send=
1
#billing server options
billing.server.login=admin
billing.server.passwd=admin
billing.server.http.url=http://localhost:
8080
/bgbilling
#billing.server.https.url=https://localhost:8443/bgbilling
billing.server.moduleId=
XXX
billing.server.show.statistics=
0
billing.server.password.remind=
0
#portal options
portal.http.port=
9090
#portal.https.port=9091
#portal.https.keystore.password=bgbilling
#portal.card.link=http://127.0.0.1:8080/bgbilling/pubexecuter?action=CreateContract&module=card&mid=5&activateType=1
#tariff options
#portal.use.realm=1
#portal.tarif.1.realm=wifi_128_128
#portal.tarif.1.title=128 kb/s
#portal.tarif.2.realm=wifi_256_128
#portal.tarif.2.title=256 kb/s
portal.http.url=http://localhost:
9090
#portal.https.url=https://localhost:9091
#wifi agent options
wifi.agent.port=
5555
wifi.agent.port.admin=
5556
wifi.agent.radius.live.time=
60000
wifi.agent.client.live.time=
24000000
wifi.agent.arp.command=/sbin/arp
#wifi.agent.server.https=1
#radius attributes
#wifi.agent.radius.atrubute.1.vendor.code=1111
#wifi.agent.radius.atrubute.1.attr.code=1
#wifi.agent.radius.atrubute.1.type=integer
#wifi.agent.radius.atrubute.2.vendor.code=1111
#wifi.agent.radius.atrubute.2.attr.code=2
#wifi.agent.radius.atrubute.2.type=integer
#dhcp options
#dhcp=1
#dhcp.server.host=192.168.184.254
#dhcp.server.port=67
#dhcp.agent.host=192.168.184.39
#dhcp.minThreadCount=10
#dhcp.maxThreadCount=10
#возможность использования символьных ссылок на файлы портала
#portal.allow.linking=1
#обработка ssi (обрабатываются shtml файлы )
#portal.use.ssi=1
Установите переменную billing.server.moduleId=<числовой код экземпляра модуля Inet>. При необходимости скорректируйте параметры доступа к базе данных и к MQ-серверу.
А теперь остановимся более подробно на каждой настройке .
radius.auth.host, radius.auth.port - хост и порт, на котором поднят RADIUS-слушатель на Access-сервере;
radius.auth.port, radius.account.port - хост и порт, на котором поднят RADIUS-слушатель на Accounting-сервере;
radius.nasId - идентификатор NAS'а (устройства, которое предствляет WiFi-агент в модуле inet);
radius.secret - секретный ключ для NAS'а (как настроить NAS для WiFi-агента будет описано ниже);
radius.update.send - Слать Update-пакеты на Accounting-сервер. По умолчанию включено;
billing.server.login, billing.server.passwd - логин и пароль доступа к серверу (те же самые, что используются в клиенте биллинга). Нужны для получения баланса пользователя. Данный пользователь должен быть заведён в системе и обладать правами на действия : "Основной модуль->Договор->Просмотр договора" и "Основной модуль->Договор->Баланс-Просмотр Баланса". О том как администрировать пользователей читайте здесь;
billing.server.http.url, billing.server.https.url - URL сервера биллинга (тот же самый, по которому обращается клиент биллинга). Соответственно для http и https. Если https-соединение не нужно, то не указывайте billing.server.https.url.
billing.server.moduleId - код модуля Inet на BGBilling-сервере, c которым будет работать этот агент;
billing.server.show.statistics - показывать ли ссылку на статистику сервера (1- показывать; 0 - не показывать, стоит по умолчанию ). При этом если в текущий момент клиент работает c порталом по http, то для него это будет ссылка на http-версию статистики, а если он работает по https с порталом, то это будет ссылка на https-версию статистики;
portal.http.port, portal.https.port - порты портала для обычного и безопасного соединения. Если https-соединение не нужно, то не указывайте portal.https.port;
portal.https.keystore.password - пароль для https-соединения. Для работы https-соединения нужен файл .keystore (основанный на этом пароле), который необходимо положить в папку агента. Как получить этот файл описано здесь. Если https-соединение не нужно, то не указывайте этот параметр;
portal.http.url, portal.https.url - URL портала для http и https соединений. Это URL, по которому будут обращаться клиенты WiFi-сети, чтобы попасть на сервисную страницу. Если https-соединение не используется, то параметр portal.https.url не указывается;
wifi.agent.port - это порт, на котором будет подниматься WiFi-агент и Access-сервер будет обращаться к этому порту для сбрасывания клиента.
wifi.agent.port.admin - порт для управления WiFi-агентом;
wifi.agent.client.live.time - время жизни (в миллисекундах) клиента . Т.е. это время неактивности клиента, через которое WiFi-агент считает, что клиента больше нет, сбрасывает сессию клиента (отсылает Stop-пакет Accounting-серверу, очищает iptables, вызывает внешние скрипты). По умолчанию стоит 40 минут. Активность клиента проверяется по изменению счётчиков iptables в цепочке WIFI (о том как настроить iptables читайте ниже);
wifi.agent.arp.command - путь к команде arp в ОС Linux. Она нужна для получения mac-адреса клиента и манипулирования arp-таблицами (в случае настойки защиты от ARP-спуффинга). По умолчанию обычно /sbin/arp;
wifi.agent.server.https - использовать или нет при взаимодействии между WiFi-агентом и сервером протокол https (1 - https; 0-http, стоит по умолчанию).
3) Для работы внешних скриптов нужно настроить файл conf.sh (часть этих настоек дублируется в inet_wifi_agent.properties). Пусть у нас имеется Linux-маршрутизатор c двумя сетевыми интерфейсами: eth0 - локальный (сеть 172.16.1.0/24, через него выходя клиенты WiFi), eth1 - внешний интерфейс для выхода в интернет (имеет внешний ip - 81.30.199.220).
#путь к Java-машине, установленной в системе
JAVA_HOME
=/opt/java/jre
#порты портала для обычного и безопасного соединения
PORTAL_HTTP_PORT
=
9090
PORTAL_HTTPS_PORT
=
9091
#это порт на котором будет подниматься WiFi-агент и Access-сервер будет обращаться к этому порту.
WIFI_AGENT_PORT
=
5555
#имя цепочки iptables, в которой будут хранится разрешающие правила для клиентов.
WIFI_CHAIN_NAME
=
WIFI
#интерфейс, на котором происходит подсчёт клиентов WiFi-сети
WIFI_INTERFACE
=eth0
#внешний интерфейс
EXTERNAL_INTERFACE
=eth1
#внешний IP
EXTERNAL_IP
=
81
.
30
.
199
.
220
#сеть клиентов WIFI
WIFI_NET
=
172
.
16
.
1
.
0
/
24
4) Необходимо сделать запускаемыми все скрипты в папке агента . Для этого надо перейти в эту папку и выполнить команду :
chmod
755
*.sh *.pl
5) Настроить скрипты входа/выхода абонента.
login.sh - сюда добавляются команды открытия доступа для авторизовавшегося клиента . В это скрипт в качестве параметра передаётся ip пользователя и RADIUS-атрибуты, полученные в Accept-пакете (настройка атрибутов описана ниже).
Скрипт имеет такой вид в стандартной поставке
#!/bin/sh
cd ${
0
%${
0
##*/}}.
. ./conf.sh
IP
=
$1
DOWNSTREAM_SPEED
=
$2
UPSTREAM_SPEED
=
$3
date >> ./log/manad.out
echo `/sbin/iptables -
I
$WIFI_CHAIN_NAME
1
-t nat -j
ACCEPT
-s
$IP
` >> ./log/manad.out
2
>&
1
echo `/sbin/iptables -
I
$WIFI_CHAIN_NAME
1
-t nat -j
ACCEPT
-d
$IP
` >> ./log/manad.out
2
>&
1
if
[
$USE_MANAD
-eq
1
];
then
./tell_manad.pl
"add $IP $DOWNSTREAM_SPEED $UPSTREAM_SPEED"
$MANAD_PORT
fi
#use it for shaping
#./shape.sh $IP $PARAM1 $PARAM2
logout.sh - сюда добавляются команды закрытия доступа для клиента . В этот скрипт в качестве параметра передаётся ip пользователя. Скрипт имеет такой вид в стандартной поставке:
!/bin/sh
cd ${
0
%${
0
##*/}}.
. ./conf.sh
IP=$
1
date >> ./log/manad.out
echo `/sbin/iptables -D $WIFI_CHAIN_NAME -t nat -j ACCEPT -s $IP` >> ./log/manad.out
2
>&
1
echo `/sbin/iptables -D $WIFI_CHAIN_NAME -t nat -j ACCEPT -d $IP` >> ./log/manad.out
2
>&
1
if
[ $USE_MANAD -eq
1
]; then
./tell_manad.pl
"remove $IP"
$MANAD_PORT
fi
6) Настроить скрипт проверки активности клиента - ip_counts.pl. Скрипт поставялется в стандартной поставке и расчитан на парсинг цепочки с разрешающми правилами . На выходе скрипт выдает данные вот в таком формате
192
.
168
.
185
.
10
13423
6878
192
.
168
.
185
.
20
133423
6878
Тут для каждого ip, найденного в цепочке, выводится информация о входящих (первый солбец) и исходящих байтах (второй столбец) на этот адрес . Столбцы разделены символом табуляции. Стандартный скрипт раcчитан на работу со стандартным файлом login.sh, считывает счетчики iptables из цепочки WIFI. Скрипт можно менять, главное, чтобы выходной формат оставался такой же, как описан выше.
7) Необходимо настроить iptables. По умолчанию WiFi-агент при старте системы инициализирует правила в системе с помощью скрипта iptables.sh. Рекомендуется все ваши настойки iptables тоже помещать в это скрипт. Этот скрипт также может использовать администратор для очистки правил и сбрасывания всех текущих клиентов. Вот пример этого скрипта:
#!/bin/sh
cd ${
0
%${
0
##*/}}.
. ./conf.sh
/sbin/iptables -
F
-t nat
/sbin/iptables -
F
-t filter
/sbin/iptables -
P
PREROUTING
DROP
-t nat
#external interface #####################################################################################
#ssh
/sbin/iptables -
A
PREROUTING
-s !
$WIFI_NET
-t nat -p tcp --dport
22
-d
$EXTERNAL_IP
-j
ACCEPT
#drop others from external interface
/sbin/iptables -
A
PREROUTING
-s !
$WIFI_NET
-t nat -j
DROP
#end of external interface #################################################################
#internal interface ###################################################################################################
#before wifi chain we must add redirects for authorized users
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
80
-d
$EXTERNAL_IP
-j
REDIRECT
--to-ports
$PORTAL_HTTP_PORT
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
443
-d
$EXTERNAL_IP
-j
REDIRECT
--to-ports
$PORTAL_HTTPS_PORT
#chain for WiFi (accept rules for authorized users)
/sbin/iptables --delete-chain
$WIFI_CHAIN_NAME
-t nat
/sbin/iptables -
N
$WIFI_CHAIN_NAME
-t nat
/sbin/iptables -
A
PREROUTING
-j
$WIFI_CHAIN_NAME
-t nat
#below is rules for internal not authorized users :
#dns
/sbin/iptables -
A
PREROUTING
-t nat -p udp --dport
53
-j
ACCEPT
#http
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
80
-j
REDIRECT
--to-ports
$PORTAL_HTTP_PORT
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
$PORTAL_HTTP_PORT
-j
ACCEPT
#https
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
443
-j
REDIRECT
--to-ports
$PORTAL_HTTPS_PORT
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
$PORTAL_HTTPS_PORT
-j
ACCEPT
#statistics
/sbin/iptables -
A
PREROUTING
-t nat -p tcp --dport
8080
-d
$EXTERNAL_IP
-j
ACCEPT
# NAT
iptables -
A
POSTROUTING
-o
$EXTERNAL_INTERFACE
-s
$WIFI_NET
-j
SNAT
-t nat --to-source
$EXTERNAL_IP
#RST packets for dropping estblished connections
/sbin/iptables -
A
FORWARD
-p tcp -j
REJECT
--reject-with tcp-reset
Этот скрипт нужно поправить под ваш случай. В процессе работы правила будут иметь вид :
# iptables -L -t nat -n
Chain
PREROUTING
(policy
DROP
)
target prot opt source destination
ACCEPT
tcp -- !
172
.
16
.
1
.
0
/
24
81
.
30
.
199
.
220
tcp dpt:
22
DROP
all -- !
172
.
16
.
1
.
0
/
24
0
.
0
.
0
.
0
/
0
REDIRECT
tcp --
0
.
0
.
0
.
0
/
0
81
.
30
.
199
.
220
tcp dpt:
80
redir ports
9090
REDIRECT
tcp --
0
.
0
.
0
.
0
/
0
81
.
30
.
199
.
220
tcp dpt:
443
redir ports
9091
WIFI
all --
0
.
0
.
0
.
0
/
0
0
.
0
.
0
.
0
/
0
ACCEPT
udp --
0
.
0
.
0
.
0
/
0
0
.
0
.
0
.
0
/
0
udp dpt:
53
ACCEPT
tcp --
0
.
0
.
0
.
0
/
0
0
.
0
.
0
.
0
/
0
tcp dpt:
9090
ACCEPT
tcp --
0
.
0
.
0
.
0
/
0
0
.
0
.
0
.
0
/
0
tcp dpt:
9091
ACCEPT
tcp --
0
.
0
.
0
.
0
/
0
81
.
30
.
199
.
220
tcp dpt:
8080
Chain
POSTROUTING
(policy
ACCEPT
)
target prot opt source destination
SNAT
all --
172
.
16
.
1
.
0
/
24
0
.
0
.
0
.
0
/
0
to:
81
.
30
.
199
.
220
Chain
OUTPUT
(policy
ACCEPT
)
target prot opt source destination
Chain
WIFI
(
1
references)
target prot opt source destination
ACCEPT
all --
172
.
16
.
1
.
105
0
.
0
.
0
.
0
/
0
ACCEPT
all --
172
.
16
.
1
.
57
0
.
0
.
0
.
0
/
0
ACCEPT
all --
172
.
16
.
1
.
94
0
.
0
.
0
.
0
/
0
# iptables -L -t filter -n
Chain
INPUT
(policy
ACCEPT
)
target prot opt source destination
Chain
FORWARD
(policy
ACCEPT
)
target prot opt source destination
REJECT
tcp --
0
.
0
.
0
.
0
/
0
0
.
0
.
0
.
0
/
0
reject-with tcp-reset
Chain
OUTPUT
(policy
ACCEPT
)
target prot opt source destination
Chain
RH
-Firewall-
1
-
INPUT
(
0
references)
target prot opt source destination
Очень не рекомендуется заносить правила в цепочку WIFI, т.к. она редактируется автоматически и могут возникнуть проблемы. Свои дополнительные правила вы можете заносить в любые другие цепочки и таблицы (учитывая логику работы iptables и WiFi-агента).
Например, если Access-сервер нахаодится на другой машине, то ему надо разрешить 5555-ый (в данном случае) порт для обращения к WiFi-агенту. Аналогично можно разрешить порты для ssh и т. п., если это необходимо. На шлюзовой машине, где ставиться агент, скорое всего, будет, как минимум, один внешний интерфейс и один внутренний интерфейс, через который будут работать клиенты WiFi. В этом случае, например, если по ssh будут обращаться только через внешний интерфейс, то можно повесить разрешающие правила на внешний интерфейс. Вариантов много, но главное, чтобы выход во внешнюю сеть был закрыт для клиентов локальной сети по умолчанию. Одним из вариантов организации сети может быть набор виртуальных (vlan) интерфейсов, которые будут заведены на данной шлюзовой машине (на интерфейсе eth0) и агент будет добавлять правила для всех клиентов этих виртуальных сетей. В этом случае агент может управлять сразу многими локальными сетями, которые могут быть физически разнесены далеко друг от друга.
Отметим, что для правильной работы сети кроме правила NAT, добавленного выше, в случае ОС Linux необходимо ещё включить ipforwarding. Для дистрибутива Fedora необходимо поставить net.ipv4.ip_forward = 1 в /etc/sysctl.conf и выполнить команду echo 1 >> /proc/sys/net/ipv4/ip_forward (чтобы изменения немедленно применились). Рекомендуется вначале проверить работу точки доступа и выход в интернет через неё, прежде чем применять запрещающие правила iptables, описанные выше.
8) Установить скрипт service/bgwifiagent_inet как службу. Для этого нужно скопировать файл bgwifiagent_inet в /etc/rc.d/init.d и потом вызвать следующие команды
chmod
755
/etc/rc.d/init.d/bgwifiagent_inet
chkconfig --add bgwifiagent_inet
chkconfig --level {lev} bgwifiagent_inet on
Где {lev}- это уровень запуска в вашей системе. Узнать его можно так:
[root
@king
~]
# runlevel
N
5
Т.к. агент изменяет правила iptables, то в системе он должен запускаться с правами root'а.
9) В файле setenv.sh нужно прописать JAVA_HOME.
10) Перед запуском агента нужно запустить скрипт
./update.sh
в папке агента. Это обновит все библиотеки на нем (скачает с сервера).
11) Для запуска агента можно выполнить команду:
service bgwifiagent_inet start
Агент не запуститься если не будет связи с сервером BGBilling, или там не будет установлены лицензии на модуль Inet или сам портал .
12)Подсоединиться клиентом к серверу биллинга, настроить устройство NAS для работы с нашим агентом. В конфигурацию NAS нужно добавить:
Идентификатор (такой какой мы указали в radius.nasId), секретное слово ( такое же как и в radius.secret), Хост/порт в формате (host:port). host - хост, на котором работает wifi-агент, port - то же самый что и в wifi.agent.port (5555 ). На этот хост и порт Access сервер будет и слать сигнал о завершении работы в случае ухода баланса клиента в минис, ручном сбросе сессии и т.п. В типе сервиса нужно установить обработчик активации сервисов ru.bitel.bgbilling.modules.inet.dyn.device.wifi.WiFiServiceActivator(входит в стандартную поставку).
13) Установить Access и Accounting сервера для модуля Inet. Настройки серверов должны совпадать с параметрами radius.auth.host, radius.auth.port, radius.account.host, radius.account.port в файле inet_wifi_agent.properties.