Организация нескольких хотспотов

Один из вопросов, который мне часто задают в переписке — как правильно организовать несколько хотспотов (зон). Собственно, авторами этого вопроса чаще всего являются люди, заинтересовавшиеся предлагаемой мною модифицированной версией программы Easyhotspot. Напомню, что в варианте, который устанавливается моим инсталятором, структура взаимодействия модулей выглядит так, как описано в заметке «Хотспот и с чем его едят». При этом, роль контроллера доступа (NAS — Network Access Server) выполняет программа Chillispot. И если она запущена непосредственно на самом сервере, то у сервера должны быть две сетевые платы, к одной из которых подключены клиенты, а к другой — интернет. В этом случае все выглядит так, как показано ниже в варианте №1.

Должен сразу оговориться — тут и далее будут рассматриваться только случаи, когда точек доступа используется несколько (либо несколько зон, либо одна большая зона).

Вариант № 1

Взглянем на рисунок:

На рисунке рассмотрен случай, когда Chillispot запущен непосредственно на сервере, и весь трафик клиентов идет непосредственно через сервер хотспота.

Еще одно небольшое отступление — как показано на рисунке (шриховыми линиями), сам сервер может подключаться к интернету как непосредственно (первый способ), так и через модем либо маршрутизатор и т.п. (второй способ). Данное подключение в свете рассматриваемого вопроса особого значения не имеет, и в этой заметке рассматриваться не будет. 

Нас же по прежнему интересует подключение нескольких точек. Есть правило, которое, увы, нам нельзя нарушить: контроллер доступа Chilllispot ДОЛЖЕН работать с клиентскими компьютерами только НАПРЯМУЮ. То есть, между выходом Chillispot, и компьютерами клиентов хотспота НЕ ДОЛЖНО быть никакого оборудования, использующего функции, либо манипулирующие сетевыми адресами, либо вставляющими куда не попадя свои собственные mac-адреса. То есть,

• Функция NAT — заказана!
• Подключения по wi-fi типа repeater (повторитель) или client (клиент) — заказаны!

Их использовать НЕЛЬЗЯ! И если вы хотите чтобы точек доступа было много, то в таком случае к выходу сервера вы должны просто подключить тупой свитч, а к его выходам — тупые точки доступа. И никак иначе! В противном случае могут возникать даже такие «странные» ситуации, когда компьютер клиента хотспота IP-адрес от Chillispot получать БУДЕТ, но авторизоваться клиент все-равно НЕ СМОЖЕТ. Если в таком случае попытаться просмотреть логи системы, то можно увидить, что в процессе авторизации будут участвовать mac-адреса «транзитного» оборудования, а вовсе не клиентского компьютера. И как результат — отсутствие (полное) страницы авторизации. А что же делать, если все-таки необходимо использовать например wi-fi канал для прохождения какого-то участка и т.п. При такой организации сети единственный приемлемый вариант — это использование WDS. То есть, на «транзитном куске» устанавливаются две точки wi-fi, настроенные в режиме WDS, и как следствие, представляющие собой «виртуальный кусок Ethernrt-кабеля в отсутствие самого кабеля». Но что делать, если такой вариант неприемлем?

Или, что делать, если хочется организовать несколько хотспотов?

Описанный в заметке сервер хотспота в своей работе использует взаимодействие различных служб (серверов), образующих некую модульную структуру. И как уже было сказано в другой заметке, эти службы не обязательно должны располагаться на одном компьютере. Более того, некоторых служб может быть, скажем так, «больше чем одна». О чем это я? Еще раз посмотрим на рис. 2 в статье про взаимодействие служб хотспота. Как видно на рисунке – между клиентами и интернетом находится лишь один сервер (служба) – контроллер доступа Chillispot. А теперь давайте все остальные службы, показанные на этом рисунке,  условно объединим «в одно целое» и назовем его «сервером биллинга». Что нам это дает? Лишь одно – ответ на вопрос «А как сделать несколько хотспотов с единым управлением?». То есть, чтобы реализовать такую схему, достаточно поставить лишь один единственный такой «сервер биллинга», а в местах предполагаемых хотспотов установить только лишь контроллеры доступа Chillispot, и настроить их на взаимодействие с RADIUS-ом «сервера биллинга». Причем, территориально «сервер биллинга» и эти т.н. «контроллеры» могут быть разнесены между собой хоть и по всему миру!

Итак, смотрим второй вариант…

Вариант №2

Вашему вниманию предлагается следующий рисунок:

Как видно из рисунка, отличия заключаются в том, что

• клиентов обслуживают уже не точки доступа, а маршрутизаторы;
• эти маршрутизаторы подключаются не к серверу хотспота (напрямую или через свитч), а к тому модему (или маршрутизатору), который организует доступ в интернет для всей сети организации.

Чтобы сохранить функцию хотспота, в таком случае контроллер доступа Chillispot  переносится непосредственно в сами маршрутизаторы. Для этого маршрутизаторы, организующие зоны хотспота, прошиваются альтернативными прошивками, в которых встроен Chillispot (примером могут служить прошивки от dd-wrt, в которых Chillispot уже встроен, либо прошивки от open-wrt, где по умолчанию Chillispot  отсутствует, но может быть добавлен при помощи механизма т.н. optware-пакетов). Пример перепрошивки маршрутизатора рассмотрен мной в заметке «Прошивка роутера D’link DIR-320 под хотспот» ранее.

Сам сервер хотспота при этом выполняет только лишь функции биллинга и сервера RADIUS. При таком построении, доступ в интернет клиентам предоставляют непосредственно сами (перепрошитые) маршрутизаторы. А чтобы знать кого в интернет пускать, а кого не пускать, chillispot из прошивок маршрутизаторов настраивается таким образом, что он взаимодействует с сервером RADIUS, запущеном на сервере хотспота (биллинга).

Дополнительной особенностью данной схемы является еще и тот факт, что трафик клиентов не проходит сквозь сам сервер хотспота, что снижает требования к его производительности (т.к. Chillispot  — это програмный контроллер доступа, и его пропускная способность зависит от быстродействия компьютера).

Ну и напоследок вариант №3

Вариант №з

При просмотре второго рисунка у вас не возникало вопроса — а что там делает устройство подписанное как «Модем или маршрутизатор»? Ведь обслуживающие клиентов устройства — тоже маршрутизаторы. То есть, они сами в состоянии выполнять авторизацию у провайдеров, и как следствие, сами могут подключаться к интернету. То есть, выкидываем дополнительный «модем или маршрутизатор» и получаем рисунок №3 — своеобразный «частный случай» рисунка №2, при котором маршрутизаторы подключены к интернету напрямую.

И сам сервер хотспота, на котором работает RADIUS и биллинг — тоже находится «где-то там» (в интернете). При этом chillispot  снова трудится на маршрутизаторах, и снова запрашивает данные по авторизации у RADIUS-а. Результат — тот же самый, что и в варианте №2, но на одну «железяку» стало меньше… Но даже не это главное достоинство! В этом случае «сервер биллинга» и роутеры хотспотов территориально могут быть разнесены между собой хоть и по всему миру! То есть, ставим сервер биллинга на какой-нибудь VDS-сервер, а потом просто расставляем в нужных местах роутеры и получаем хотспоты!!!…