Розподілене captive portal в публічних місцях і складності з apple, savepearlharbor

Ми брали участь у створенні публічних мереж з розподіленими captive portal і наступали практично на всі граблі, тому хочу поділитися досвідом.

Для початку - трохи теорії про те, як це працює і чим розподілені портали відрізняються від централізованих. Ідеологічно то, що ми звикли називати Captive Portal, насправді складається з трьох компонентів:

firewall - розповідає доступом окремих користувачів в мережу. У разі відсутності доступу з ідейних міркувань - виконує перенаправлення користувача в web frontend. У разі відсутності доступу з технічних причин (НЕ пінгуєтся gateway) можна доручити firewall виконувати перенаправлення користувача на спеціальну сторінку «сервісу немає, але ми чинимо з усіх сил».

У разі централізованого captive portal все три компонента очевидним чином розташовуються на одній машині (пристрої), що сильно спрощує завдання. Firewall в даному випадку часто виконує ще й NAT, а captive portal можна реалізувати у вигляді купки скриптів, які підкручують локальний iptables. Виникає труднопреодолимое бажання натолкать в мережу дешевих точок доступу, які звалять нам всіх користувачів в ethernet або в найкращому разі - в окремий vlan. Які тут проблеми:

Проблеми з безпекою. Ми обмежуємо доступ до зовнішнього каналу, однак в локальній мережі все погано. Оскільки мережа відкрита, будь-який користувач може відповідати на arp від імені нашого default gateway, отримувати трафік користувачів і займатися фішингом. Не забороняється поставити свій сервер DHCP і в якійсь дельта-околиці стремається користувачів заявами типу «ваш браузер безнадійно застарів». Якщо ваш captive portal і користувача розділяє роутер, то у вас немає можливості контролювати на captive portal відповідність mac і ip з усіма наслідками, що випливають. Комунікація між бездротовими клієнтами стає можливою. Ви можете на дешевій точці заборонити комунікувати бездротовим клієнтам, але клієнти інших точок видно вже по ethernet.
Проблеми з трафіком. Маємо в локальній мережі багато зайвого трафіку. Бажано до відкриття captive portal клієнтів далі точки доступу не пускати.
Проблеми з масштабністю. При великому числі клієнтів проблемних може стати будь-який з трьох компонентів порталу.

Як ви вже здогадалися, розподілене captive portal покликаний вирішувати всі ці проблеми. Говорячи «розподілене», ми припускаємо, що компоненти можуть розміщуватися на різних пристроях. Це дозволить нам створити надійну систему, яка забезпечить необхідний рівень безпеки і сервісу, при цьому маючи більші можливості по масштабування. Проблему, яку нам належить вирішити - забезпечити взаємодію між компонентами captive portal. Де ж слід розташовуватися компонентів рішення?

Firewall повинен знаходитися максимально близько до клієнта, тобто однозначно в точці доступу. Оскільки точок доступу кілька і в кожній з них - свій firewall, то їх робота повинна бути синхронізована в рамках деякого простору або місцевості, в межах якої передбачається роумінг клієнтів. В іншому випадку клієнти при роумінгу будуть відчувати проблеми з комунікацією. У сучасних мережах задача синхронізації роботи чого-небудь всередині якоїсь області (RF-домену) виконується за допомогою призначаються арбітрів (менеджерів RF-домену) і була вирішена в стародавні часи безвідносно до задачі реалізації розподіленого captive portal. Для цієї системи синхронізація роботи firewall - просто ще один з процесів, який повинен виконуватися в домені узгоджено, поряд (наприклад) з комутацією трафіку, синхронізацією конфігурацій точок або збором статистики.

Місце розташування web frontend сильно залежить від складності завдань, які йому доведеться вирішувати. Якщо треба показувати сторінки, що не припускають server side processing або якихось складнощів типу розсилки СМС, то цілком можна обійтися сервером на точці доступу. Він, знову ж таки, розташовується в максимальному наближенні до клієнта і забезпечує найбільш ефективне з ним взаємодію. Синхронізацією контенту веб серверів на різних точках доступу займеться (сюрприз) менеджер RF-домену.

Місце розташування captive portal залежить від положення web frontend і доступності точок. Оскільки завданням captive portal є підкручування firewall, то він повинен мати своє представництво (агента) на кожній точці. Проте, web frontend може комунікувати з будь-якої з копій цих агентів, бо їх стан (ви вже здогадалися) також синхронізується в рамках домену.

Метод взаємодії з captive portal. Нам потрібен механізм, за допомогою якого ми можемо повідомити порталу результати взаємодії з користувачем. У нашому випадку в якості такого механізму був обраний HTTP GET. При необхідності відкрити портал ми посилаємо HTTP GET в будь-який з його представництв. Склад переданих в GET параметрів залежить від режиму, в якому працює портал. Тут кілька варіантів:

Портал відкривається завжди. Можливо занести запис про це в log.
Портал відкривається при наявності в GET змінної, що відображає згоду з умовами (agreement).
У GET передаються username і password, портал сам лізе в RADIUS з цими атрибутами і відкривається, отримавши звідти ACCEPT.
У GET передається один (універсальний) атрибут, портал вказує його і як username і як password при зверненні в RADIUS і відкривається, отримавши ACCEPT. Зрозуміло, що такий користувач повинен бути в RADIUS

В ідеалі, точка виконує бриджинг (форвардного 2-го рівня) між SSID і якимось vlan в проводах. Тобто firewall працює на другому (MAC) рівні. Оскільки firewall бачить прилетів з надр вашої мережі DHCP offer клієнту, він точно знає його IP, сам відповідає замість клієнта на ARP і жорстко фільтрує весь ARP і DHCP на бездротовому сегменті.

При чому тут Apple

І чому ми всюди, як і в метро, переконуємо айфончег, що порталу немає.

По тому, як айфончік поводяться в бездротових мережах, у мене склалося стійке переконання, що творці цього мегапродукта припускали тільки один сценарій, а саме - одна точка доступу. Тобто або вдома, або в кафе для хіпстера. У другому випадку є неіллюзорний шанс зустрітися з captive portal.

Що робить айфончік, зустрівши однаковий SSID відразу в 2.4 і в 5GHz? Ви думали, що зможете балансувати клієнтів між каналами, точками і діапазонами, максимально використовуючи можливості клієнтів і пропускання мережі? Тільки не з продуктами Apple! З боку мережі, чуючи від клієнта запити в обох діапазонах, ми вправі припускати, що зможемо змусити клієнта підключитися куди нам треба, пропускаючи запити до тих точках, куди ми не хочемо, щоб він підключався. Зазвичай клієнти розуміють натяк і підключаються, наприклад, в 5Ghz. Айфон буде ломитися в 2.4 до останнього. Для завзятих є окремий лічильник (20 запитів поспіль за замовчуванням). Теж займає час.

Два описаних процесу відбуваються не тільки при підключенні до мережі, але і при роумінгу, якщо відійти досить далеко. О, так тут нові точки. Ну-ка, перевіримо ...

Сподіваюся, вам тепер зрозуміло, чому в метро вимкнули виявлення порталу.

До речі, на нашому обладнанні виявлення вимикається однією командою: