Варианты построения сети хотспота

Как уже было сказано ранее, чтобы управлять доступом клиентов в интернет, между ними и интернетом на сервере хотспота устанавливается контроллер доступа Chillispot. Иными словами, сеть должна быть построена таким образом, чтобы трафик клиентов проходил через Chillispot. И, что немаловажно (чем именно - будет показано ниже), Chillispot - это ЕДИНСТВЕННОЕ, что находится между клиентами хотспота и интернетом!

В самом простейшем случае, подключение выполняется следующим образом:

• первой сетевой платой (WAN-интерфейсом) сервер хотспота подключается к интернету;
• Chillispot работает на самом сервере, управляя при этом второй сетевой платой
• ко второй сетевой плате сервера (LAN-интерфейсу) подключается беспроводная точка доступа на которую подключаются клиенты хотспота;

Но как быть, если одной точки доступа недостаточно для покрытия обслуживаемой зоны?

Вариант № 1

Собственно, данный вариант является "логическим продолжением" все того же "простейшего случая". Как видно с рисунка, контроллер доступа Chillispot все так же запущен непосредственно на самом сервере, и весь трафик клиентов по прежнему идет непосредственно через сам сервер хотспота. К выходу сервера подключается обычный неуправляемый свич, а к его выходам - любое необходимое вам число точек доступа.

ВАЖНОЕ ОБСТОЯТЕЛЬСТВО для данного "Варианта №1", равно как и для "простейшего случая" - ВЫ АБСОЛЮТНО СВОБОДНЫ В ВЫБОРЕ ТОЧЕК ДОСТУПА (РОУТЕРОВ), И ПРИ ЭТОМ НЕТ НЕОБХОДИМОСТИ ПЕРЕПРОШИВАТЬ ТОЧКИ ДОСТУПА (РОУТЕРЫ) АЛЬТЕРНАТИВНЫМИ ПРОШИВКАМИ (МОГУТ ИСПОЛЬЗОВАТЬСЯ ЗАВОДСКИЕ ПРОШИВКИ)!

Что важно учесть при таком построении сети? Два обстоятельства:

• Во первых, как уже было сказано, ВЕСЬ трафик ВСЕХ клиентов идет через сервер. А так как контроллер доступа Chillispot - это програмный NAS (Network Access Server - Сервер доступа к интернету), то его производительность напрямую зависит от производительности сервера, на котором он установлен. То есть, для того, чтобы сервер хотспота смог обслуживать большое число клиентов на высокой скорости, на нем должен быть установлен достаточно производительный процессор. 
• И второе правило, которое никак нельзя нарушить: контроллер доступа Chilllispot ДОЛЖЕН работать с клиентскими компьютерами только НАПРЯМУЮ. То есть, между выходом Chillispot, и компьютерами клиентов хотспота НЕ ДОЛЖНО быть никакого оборудования, использующего функции, либо манипулирующие сетевыми адресами, либо вставляющими куда не попадя свои собственные mac-адреса. Т.е. NAT, Firewall, Masquerade, WiFi-bridge и тп. - их использовать НЕЛЬЗЯ! И если вы хотите чтобы точек доступа было много, то в таком случае, как и показано на рисунке выше, к выходу сервера вы должны подключить простой неуправляемый свитч, а к его выходам – такие же простые неуправляемые точки доступа. И никак иначе! В противном случае будут ошибки, при которых компьютеры клиентов  IP-адреса от Chillispot получать БУДУТ, но авторизоваться НЕ СМОГУТ. И если в таком случае проанализировать логи системы, то можно будет увидеть, что в процессе авторизации будут участвовать mac-адреса «транзитного» оборудования, а вовсе не клиентских компьютеров. И как результат – полное отсутствие страницы авторизации.

А что же делать, если все-таки необходимо использовать например wi-fi канал для прохождения какого-то участка и т.п. При такой организации сети единственный приемлемый вариант – это использование WDS. То есть, на «транзитном куске» устанавливаются две точки wi-fi, настроенные в режиме WDS, и как следствие, представляющие собой «виртуальный кусок Ethernrt-кабеля в отсутствие самого кабеля». Но что делать, если такой вариант неприемлем? Или, что делать, если хочется организовать несколько хотспотов?.

"Лирическое отступление"

Как уже было сказано ранее, сервер хотспота:

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

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

• Нужно установить где-то один единственный такой «сервер биллинга»;
• плюс, в местах предполагаемых хотспотов между клиентами и интенрнетом каким-то образом разместить контроллеры доступа Chillispot!

После этого настраиваем взаимодействие Chillispot-ов с службой RADIUS «сервера биллинга», И ВСЁ! Причем, территориально «сервер биллинга» и эти «контроллеры» могут быть разнесены между собой хоть и по всему миру!

Лирическое отступление №2" - зачем "шить" роутеры?

Как уже было сказано выше, для построения "распределенной" сети нам нужно сделать так, чтобы в месте размещения каждого хотспота между интернетом и клиентами хотспота был установлен контроллер доступа Chillispot. Если мы посмотрим на блок-схему начинки "обычного" SOHO-роутера, то она выглядит следующим образом:

"Самое грустное", что мы видим - это то обстоятельство, что в заводских прошивках роутеров НИКАКИХ ТАКИХ Chillispot-ов НЕТ! И как быть в таком случае?

Ответ на этот вопрос существует. Его предоставляют такие фирмы как DD-WRT и OpenWRT. Они выпускают альтернативные прошивки для очень широкого модельного ряда роутеров самых различных изготовителей. Самым важным для нашей ситуации обстоятельством является тот факт, что в этих прошивках встроен (в DD-WRT) или может быть доустановлен (в OpenWRT) контроллер доступа Chillispot! В итоге, блок-схема роутера, перешитого такой альтернативной прошивкой, приобретает несколько иной вид:

И в данном случае, наше условие выполнено - Chillispot находится как раз на пути клиентов к интернету!

• ВАЖНОЕ УТОЧНЕНИЕ!!! Не требуется перепрошивка роутерам фирмы Mikrotik - в используемой в них Router OS уже присутствует собственная реализация хотспота (Hotspot). Для работы в составе описанных ниже распределенных систем с использованием биллинга Easyhotspot нужно во первых, включить в этих роутерах хотспот, и во вторых, настроить их на работу с внешним сервером RADIUS.

Ну вот мы и разобрались со всеми "лирическими отступлениями". И теперь готовы к тому, чтобы наконец-то рассмотреть …

Вариант №2

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

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

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

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

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

СПЕЦИАЛЬНО АКЦЕНТИРУЮ ВАШЕ ВНИМАНИЕ - для "Варианта №2", ВАМ БУДЕТ НЕОБХОДИМО ПЕРЕПРОШИВАТЬ РОУТЕРЫ АЛЬТЕРНАТИВНЫМИ ПРОШИВКАМИ!! Исключение составляют роутеры ф. Mikrotik (в них хотспот может быть настроен на заводской прошивке)!

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

Вариант №з

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

Сам "сервер биллинга", на котором работает RADIUS и биллинг – тоже находится «где-то там в интернете». При этом Chillispot снова "трудится" непосредственно на маршрутизаторах, и снова запрашивает данные по авторизации у RADIUS-а. Результат – вроде тот же самый, что и в варианте №2, но… Но главное достоинство даже не в том, что на одну «железяку» стало меньше! "Главное" в том, что «сервер биллинга» и роутеры хотспотов территориально могут быть разнесены между собой хоть и по всему миру! То есть, ставим сервер биллинга на какой-нибудь VDS-сервер, а потом просто расставляем в нужных местах роутеры и получаем хотспоты "по всей планете" (ТАКОЙ СЕБЕ "ОБЛАЧНЫЙ СЕРВИС")!!!…

СПЕЦИАЛЬНО АКЦЕНТИРУЮ ВАШЕ ВНИМАНИЕ - для "Варианта №3", ВАМ БУДЕТ НЕОБХОДИМО ПЕРЕПРОШИВАТЬ РОУТЕРЫ АЛЬТЕРНАТИВНЫМИ ПРОШИВКАМИ!! Исключение составляют роутеры ф. Mikrotik (в них хотспот может быть настроен на заводской прошивке)!

Предлагаемый сервер с модифицированной версией программы Easyhotspot позволит вам построить сеть по любой из приведенных выше схем.

Hotspot Network Topology Variants

As mentioned earlier, to control the access of clients to the Internet between them and the Internet, an access controller Coova-Chilli is installed on the server of the access points. In other words, the network must be built such way that client traffic flows through Coova-Chilli. You must to clear understand (and it will be shown below), Coova-Chilli is the ONLY THING that placed between the hotspot clients and the Internet!

In a simplest case network connection of hotspot server could be made as follows:

• First network card (WAN interface) connected to the Internet;
• Coova-Chilli runs on the server itself, while managing the second network card;
• Wireless AP is connected to the server’s second network card (LAN interface) and serves hotspot clients;

But what if one access point is not enough to cover the entire service area?

Variant No. 1

In fact, this option is a "logical evolution" of the "simplest case" shown above. As you can see from the figure, program NAS Coova-Chilli is still running on the server itself, and hotspot clients traffic is still passing through the server. A regular unmanaged switch must be connected to the server’s LAN output, and any required number of access points can be connected to this switch.

IMPORTANT NOTE for this "Variant No. 1", as well as for the "simplest case" – YOU ARE ABSOLUTELY FREE IN THE CHOICE OF ACCESS POINTS (ROUTERS), AND THERE IS NO NECESSITY TO FLASH THEM WITH ALTERNATIVE FIRMWARE (FACTORY FIRMWARE MAY BE USED)!

What is important to consider when building this network? Two circumstances:

• Firstly, as already mentioned, all traffic of ALL clients passes through the server. And since Coova-Chilli is a software NAS (Network Access Server), its performance directly depends on the performance of the server on which it is installed. In other words, for a hotspot server to be able to serve a large number of clients at high speed, a sufficiently powerful processor must be installed on it.
• And the second rule, which cannot be violated in any way: the Chilllispot access controller MUST INTERACT with client devices only DIRECTLY. This means that FORBIDEN TO PLACE ANY equipment, that uses functions that either manipulate network addresses or insert their own mac addresses, between the Coova-Chilli's output and the hotspot clients devices. In other words, the equipment installed after the server should not use NAT, Firewall, Masquerade, WiFi-bridge, etc.! And if you need a lot of access points, in this case, you must connect a simple unmanaged switch to the server output, and the same "dumb" (unmanaged) access points to its outputs, as it shown in the figure above. And no other way! Otherwise, hotspot clients will receive errors when their devices will get IP addresses from Coova-Chilli, but will NOT BE ABLE to log in! And if you look at the system logs in this case, you will see that the mac addresses of the "transit" equipment, but not the client devices, will participate in the authorization process. As result – the complete absence of the authorization page.

But what to do if you still need to pass through some area from server to hotspot location using wireless connection, for example. The only acceptable option is to use WDS for this kind of networking. It mean, that two wi-fi AP must be set and configured in WDS mode on both sides of such a "transit sector". As a result, you will get "a virtual Ethernrt cable in the absence of the cable itself" (without NAT, Firewall, MAC addresses manipulations, etc.). But what if this option is unacceptable? Or what to do if you want to organize several hotspots at different locations?

"Digression No.1"

As mentioned before, the hotspot server:

• ...uses the cooperation of some various services (programs) in its work, each of which functions as a separate module of the one global system;
• these services (modules) don't have to be placed on the same computer;
• system could have "more than one instance" of some services (modules);
• there is only one module (service) must be placed "between" the clients and the Internet – the program NAS Coova-Chilli;

So, what it gave to us? Look again at the figure about interaction of hotspot services. As you see again - between clients and the Internet there is only one server (service) - the program NAS Coova-Chilli. Now, let's merge virtually all other services, shown in this picture, "into one whole" and call it "billing server". As a result, we came very close to the answer to the question "How to make several hotspots with common management?" And this answer is simple - to implement such a scheme you need

• firstly, install one such "billing server" somewhere on the Internet;
• on the other hand, install the required number of devices (routers) that are equipped with Coova-Chilli "between" clients and the Internet at the locations of the alleged hotspots;

After that, you just have to configure the interaction between of the routers equipped with Coova-Chilli and the RADIUS daemon of the "billing server", AND THAT'S ALL! Moreover, geographically "billing server" and the "Coova-Chilli routers" could be placed arbitrarily far apart, though, and all over the world!

"Digression No. 2" – for what "to flash" routers?

As mentioned above, to build a "distributed" network, we need to make sure that the Coova-Chilli NAS is installed between the Internet and the clients in each hotspot router. Let's look at the block diagram of a "regular" SOHO router. It looks like this:

"The most sad thing" is the fact that there is NO ANY Coova-Chilli in the factory firmwares of the regular SOHO routers! And so what to do now?

The answer for this question exists. It is provided by companies DD-WRT and OpenWRT. They provide alternative firmwares for a very wide range of routers of various manufacturers. The most important circumstance of those firmwares for our situation is that the Coova-Chilli NAS already built-in (in DD-WRT firmware) or can be additionaly installed (in OpenWRT firmware)! As a result, the block diagram of the router with such an alternative firmware looks a slightly different:

And in case of using DD-WRT and OpenWRT firmware, our condition will be fulfilled – Coova-Chilli will be "right on the way" from clients to the Internet!

• IMPORTANT NOTE !!! Mikrotik routers do not need to be flashed – the Router OS used in them already has its own implementation of a hotspot. To work as part of the described below distributed system working under Easyhotspot control, you just need to enable hotspots in these routers, and then, configure them to work with an external RADIUS server.

So, we are finished with all the lyrical digressions now. And now we are ready to finally consider …

Variant No. 2

As you can see from the figure above, the differences are:

• clients are no longer served by "dumb" access points, but by routers;
• these routers don't connect to the LAN interface of the hotspot server (directly or through a switch), but to the some kind "main" router, that serve as Internet source for the whole organization network;

In this case the Coova-Chilli NAS must be "moved" from "Easyhotspot server" to the routers themselves, to have posibility of organize the hotspot function. To do this, the routers which organize hotspot zones must be flashed with alternative firmware with Coova-Chilli NAS is built-in (for example, DD-WRT firmware, which Coova-Chilli is already built-in, or OpenWRT firmware, where Coova-Chilli is absent by default, but can be added by optware packages). In this case, the Coova-Chilli of the router must be configured to work with an external RADIUS server as which you will use Easyhotspot. An example of router flashing and following configuration of the built-in Coova-Chilli was described at my blog post "Flashing D’link DIR-320 by DD-WRT firmware for hotspot".

The Easyhotspot server itself will perform only the functions of billing and the RADIUS server. With this network topology, Internet access to clients is provided by flashed routers directly. And information about who allowed Internet access and with kind of limits, router's Coova-Chilli will get from RADIUS daemon running on the Easyhotspot server.

An additional advantage of this network topology is the fact that client's traffic does not pass through the Easyhotspot server itself, which reduces its performance requirements (since Coova-Chilli is a software NAS and its throughput depends on the speed of the computer).

I EM SPECIALLY PAY YOUR ATTENTION for "Variant No. 2" – YOU WILL NEED TO FLASH YOUR ROUTERS WITH ALTERNATIVE FIRMWARES (DD-WRT for example)! An exception is Mikrotik routers (their Router OS already has its own implementation of a hotspot, which could be configured to work with an external RADIUS server)!

And finally …

Variant No. 3

Did you have a question – "What does doing the device named as a «Modem or Router» there?", when you looking at the second picture (above)? After all, devices serving to a clients are routers also! Thereby, they themselves can to perform authorization with providers, and themselves can connect to the Internet as a result. So, we just throw out an additional «modem or router» and get Variant No. 3 – a kind of "special case" of Variant No. 2, where the routers with Coova-Chilli are connected to the Internet directly:

The "Easyhotspot server" itself, which runs RADIUS and billing, is also located "somewhere on the Internet" again. At the same time, Coova-Chilli "works" directly on the routers again and "asking" authorization data from RADIUS daemon again. And result, as you can see, is almost the same as in Variant No. 2, but… But the main advantage is not even that there is one device less! "The most point" is that the "billing server" and hotspot routers interact over Internet and can be geographically distributed among themselves, although around the world! Other words, we can to install the billing server on some VDS server, and then just place the routers in the any random places and get hotspots "all over the planet" (a kind of “CLOUD SERVICE”)!

IMPORTANT NOTE for "Variant No. 3" – YOU WILL NEED TO FLASH YOUR ROUTERS WITH ALTERNATIVE FIRMWARES (DD-WRT for example)! An exception is Mikrotik routers (their Router OS already has its own implementation of a hotspot, which could be configured to work with an external RADIUS server)!

The proposed server with a modified version of Easyhotspot will allow you to build a hotspot network using any of the above topologies.