Жодного розриву: як ми створювали бездротову мережу для 3000 пристроїв


Wireless Society by JOSS7

Wi-Fi в офісах Mail.Ru Group за останні десять років пережив кілька змін устаткування, підходів до побудови мережі, схем авторизації, адміністраторів та відповідальних за його роботу. Починалася бездротова мережа, напевно, як і у всіх компаніях — з декількох домашніх роутерів, які віщали якийсь SSID зі статичним паролем. Довгий час цього було досить, але кількість користувачів, площі і кількість точок доступу стало рости, домашні D-Link'и поступово замінили на Zyxel NWA-3160. Це вже було відносно просунутим рішенням: одна з точок могла виступати в якості контролера для інших і давала єдиний інтерфейс для менеджменту всій мережі. Якийсь більш глибокої логіки і автоматизації софт NWA-3160 не давав, тільки можливість налаштування підключених до контролера точок, користувальницький трафік оброблявся кожним пристроєм незалежно. Наступною зміною обладнання став перехід на контролер Cisco AIR-WLC2006-K9 + кілька точок доступу Aironet 1030. Вже зовсім доросле рішення, з безмозкими точками доступу і обробкою всього трафіку контролером бездротової мережі. Після ще була міграція на пару AIR-WLC4402-K9, мережа вже зросла до сотні точок Cisco Aironet 1242AG, 1130AG, 1140AG.

1. Накопичені проблеми
Настав 2011 рік, через рік очікувався переїзд компанії в новий офіс, а Wi-Fi вже був хворий темою і найбільш частою причиною скарг співробітників в техпідтримку: низька швидкість з'єднання (а буферизація відео на youtube/vk/pornhub викликає неабиякий стрес, і очевидно заважає роботі), обриви з'єднання. Періодичні спроби використовувати Wi-Fi-телефони провалювалися через непрацюючого роумінгу. Ноутбуків з вбудованим Ethernet ставало все менше (спасибі появи MacBook Air і гонці виробників за товщиною корпуса), переважна більшість мобільних телефонів вже вимагали постійного підключення до інтернету.

Ефір був постійно зайнятий, старенькі точки доступу не витримували навантаження. Починалися дисконнекты користувачів при підключенні 25+ пристроїв до однієї точки доступу, не підтримувався стандарт 802.11 n і діапазон 5 Ггц. Крім цього, для потреб мобільної розробки в офісі перебував купу SOHO-роутерів, підключених до різних эмуляторам (засобами NetEm).

З точки зору логічної схеми з моменту переходу на централізовані рішення у 2007-2008 роках мало що змінилося: кілька SSID, включаючи гостьовий, кілька великих підмереж (/16), в які потрапляли авторизовані в тій чи іншій бездротової мережі користувачі.

З мережевою безпекою також було погано: основним механізмом авторизації користувачів довірені Wi-Fi-мережі був PSK, не змінювався кілька років. Близько тисячі пристроїв постійно перебували в одній підмережі без будь-якої ізоляції, що сприяло поширенню шкідників. Номінальна фільтрація трафіку здійснювалася з допомогою iptables на *NIX-шлюзі, служила NAT'ом для офісу. Природно, ні про яку гранулярности firewall'ів не могло бути й мови.

2. Нова висота
Переїзд компанії виявився чудовою можливістю обдумати і побудувати офісну мережу з нуля. Пофантазувавши на тему ідеальної мережі та проаналізувавши основні скарги, вдалося визначити, чого ж ми хочемо досягти:

  • максимальна доступна на ринку продуктивність точок доступу. Бажано з можливістю апгрейда до нових стандартів 802.11 без заміни всього обладнання;
  • відмовостійкість. Сервера авторизації, контролери Wi-Fi, світчі, до яких підключалися точки доступу, firewall'и і маршрутизатори — все зарезервувати;
  • можливість емуляції різних умов мережі (втрата пакетів, затримки, швидкість) засобами корпоративного Wi-Fi. Наявність в офісі безлічі Wi-Fi-мильниць без централізованого управління не дозволяло використовувати ефір оптимальним чином;
  • Wi-Fi телефонія. Мобільність робочих телефонів зручна для роботи деяких відділів — техпідтримка, адміністративний відділ, і т. д.;
  • ITSEC. Ідентифікація підключених користувачів. Гранулярність списків доступу: підключеному користувачеві повинні були бути доступні тільки необхідні йому для роботи ресурси, а не вся мережа. Ізоляція пристроїв один від одного;
  • робота заснованих на bonjour і mDNS сервісів. У нас безліч користувачів macOS і iOS, а всілякі яблучні сервіси на зразок airplay, airprint, time machine спочатку не призначені для роботи у великих сегментованих мережах;
  • повне покриття бездротової мережі всіх приміщень офісу, від туалетів і тренажерного залу до ліфтових холів;
  • централізована система локації користувачів і джерел перешкод в роботі Wi-Fi.
Є кілька підходів до організації бездротової мережі з точки зору управління та обробки користувальницького трафіку обладнанням:

  1. Розсип автономних точок доступу. Дешево і сердито — адміністратор і монтажник розставляють по приміщенню недорогі домашні Wi-Fi-роутери, по можливості налаштовують їх на різні канали. Можна навіть спробувати їх налаштувати на мовлення одного і того ж SSID і сподіватися на якийсь роумінг. Кожне пристрій незалежно, для внесення змін у конфігурацію потрібно покрутити кожну точку окремо.

  2. Частково централізовані рішення. Єдина точка управління всіма точками доступу — контроллер Wi-Fi-мережі. Він відповідає за внесення змін у конфігурацію кожної точки доступу, позбавляє адміністратора від необхідності вручну обходити і перенастроювати всі наявні пристрої. Він може відповідати за централізовану авторизацію користувачів при підключенні до мережі. В іншому точки доступу не залежать від роботи контролера, самостійно обробляють трафік користувачів і випускають його в дротову мережу.

  3. Централізовані рішення. Точки більше не є скільки-небудь незалежними пристроями, повністю передаючи як управління, так і обробку трафіку контролера мережі. Весь користувальницький трафік завжди передається для обробки контролеру, рішення про зміну каналу, потужності сигналу, що віщаються бездротових мережах та авторизації користувачів приймаються виключно контролером. Завдання точок доступу зводиться до обслуговування бездротових клієнтів і туннелированию фреймів у напрямку контролера бездротової мережі.
Ми встигли спробувати кожен з цих підходів, і централізоване рішення з єдиним контролером було найбільш придатним для наших нових завдань. Разом з контролером ми отримували єдину точку застосування списків доступу і відв'язувати клієнтів роумінг між точками доступу від адресного простору на дроті.

3. Вибір обладнання
На той момент (кінець 2012 року) було всього кілька вендорів, що викликають у нас довіру і при цьому мають задовольняє основним вимогам лінійку обладнання. До живого тестування крім очевидної Cisco дійшло рішення від Aruba. Тестувалися точки 93-ї 105-,125 і 135-ої серії з контролером. Все проходило в реальних умовах, з живими користувачами розгорнули мережу на цих точках на декількох поверхах старого офісу. По продуктивності точки повністю задовольняли потребам на той момент. Софт контролера був теж непоганий: багато фішки, для яких у випадку c Cisco було б встановлювати додаткові сервера (MSE/WCS/Prime) і купувати ліцензії, були реалізовані безпосередньо на контролері (геолокація, збір і відображення просунутої статистики по клієнтам, відтворення heatmap'ов і відображення користувачів на карті в реальному часі). Разом з цим виявилися і недоліки:

  • відключається (вірніше, відключається тільки разом з потрібним функціоналом) stateful firewall з досить скромним лімітом сесій. Фактично, Wi-Fi-мережу вдалося вбити з одного ноутбука, запустивши вдале мережеве сканування;
  • спектроанализатор в точках використовувався тільки для генерації алертів адміністратору. Cisco вже тоді номінально вміла реагувати на інтерференцію самостійно (Event Driven RRM);
  • MFP не був реалізований взагалі;
  • на відміну від Cisco, точки Aruba не можна було перепрошити і використовувати без контролера.
У підсумку довелося повернутися до рішень від Cisco: контролеру 5508, топовим AP 3602i для основних приміщень офісу та AP 1262 для підключення зовнішніх антен. Точки 36-ої серії на той момент були цікаві можливістю апгрейда до 802.11 ac Wave 1 шляхом підключення додаткового антенного модуля. На жаль, ці модулі так і не стали сумісні з виробленими для Росії точками з індексом -R-, тому для повноцінної підтримки 802.11 ac доводиться міняти точки доступу на AP 3702 (і 3802 в майбутньому).

Покрокових інструкцій з початкового налаштування «цискиного» Wi-Fi в мережі безліч, так само як і по плануванню (а починаючи з восьмої версії софта більшість «best practices» налаштування доступні безпосередньо з web-ui контролера).

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

4. Відмовостійкість
Контролер мережі Wi-Fi обробляє весь трафік і є єдиною точкою відмови. Немає контролера — мережа не працює взагалі. Його необхідно було зарезервувати в першу чергу. З деяких пір Cisco пропонує для цього два різних рішення:

  • «N+1». Ми маємо кілька контролерів з повністю незалежним control-plane, власної конфігурацією, IP-адресами і набором встановлених ліцензій. Точки доступу відомий список адрес контролерів і пріоритетність кожного з них (primary-secondary-tertiary ...), і в разі раптової відмови поточного контролера точка перезавантажується і намагається підключитися до наступного в списку. Користувач при цьому залишається без зв'язку на хвилину-дві.

  • «AP SSO». Ми об'єднуємо основний і резервний контролери між собою, вони синхронізують конфігурацію, стан підключених користувачів і використовують один і той же IP-адресу для створення тунелю до точок доступу. При відмові основного контролера, IP і MAC-адресу, до якого були почеплені точки доступу, швидко і автоматично переноситься на резервний (віддалено схоже на роботу FHRP-протоколів). Точки доступу також не повинні помітити розриву зв'язку. В ідеальному світі користувачі взагалі не відчують що щось зламалося.
Варіант «AP SSO» виглядає набагато цікавіше: миттєвий і непомітний для користувача failover, відсутність необхідності в додаткових ліцензії, не потрібно вручну підтримувати актуальність конфігурації другого контролера і т. д. В реальному житті, у свіжому на той момент софті 7.3 все виявилося не настільки райдужно:

  • обидва WLC (контролера Wi-Fi) фізично повинні знаходитися недалеко один від одного. Для синхронізації конфігурації і heartbeat'ов використовується виділений мідний порт. У нашому випадку контролери знаходилися в приміщеннях на різних поверхах, і довжини мідного кабелю вистачало на межі;

  • прозорий failover підключених користувачів («Client SSO») з'явився тільки у версії 7.6. До цього користувачів все-таки відключав від Wi-Fi, хай і ненадовго;

  • м'яко кажучи, дивний механізм визначення та поведінки кластера при аварії. Якщо коротко: обидва контролери пингают один одного разу в секунду по мідному дроту і перевіряють доступність шлюзу за замовчуванням (знову ж таки, ICMP-пінгом).
З останнім пунктом і виникла проблема. Суть проблеми — відповідно до таблицей у разі будь незрозумілої ситуації — standby контролер йде в reboot. Припустимо, що у нас наступна схема мережі:


Що відбувається при відключенні C6509-1? Активний контролер втрачає uplink і відразу перезавантажується. Бэкапный контролер втрачає зв'язок з основним і намагається пропінгувати шлюз, який протягом трьох секунд (при дефолтних таймерах VRRP) буде недоступний до «переїзду» адреси на C6509-2. Після двох невдалих пінгів шлюзу протягом двох секунд standby wlc теж піде на перезавантаження. Причому двічі. Вітаю, на найближчі 20-25 хвилин ми залишилися без Wi-Fi. Аналогічне поведінка спостерігалося при використанні будь-якого протоколу резервування першого переходу (FHRP), а також спонтанні reboot'и контролерів при занадто суворому ICMP rate limit. Вирішується проблема або тюнінгом таймінгів FHRP, щоб адреса встигав «переїхати» до перезавантаження standby wlс. Або перенесенням FHRP master на роутер, до якого підключений standby wlc, або повною зміною схеми підключення (наприклад, використанням MC-LAG/VPC/VSS-PC в бік контролерів).

В софті 8.0+ проблему вирішили, ускладнивши логіку перевірки доступності шлюзу і перейшовши з ICMP-пингалок на UDP-heartbeat'ы власного формату. У результаті ми зупинилися на зв'язці з HSRP і софта 8.2, домігшись таки непомітного для користувача фэйловера між контролерами.

Також для відмовостійкості використовуються кілька RADIUS-сервера (MS NPS), точки доступу в межах одного приміщення підключаються в різні свічі доступу, свічі доступу мають uplink'і до двох незалежних пристроїв ядра мережі і т. д.

5. Тюнінг
Знайти загальні рекомендації по тюнінгу продуктивності Wi-Fi не складно (наприклад, Wi-Fi: неочевидні нюанси (на прикладі домашньої мережі)), так що сильно загострювати на цьому увагу не буду. Хіба що коротко про специфіку.

5.1. Data rates
Уявімо, що після базового налаштування контролера і підключення до нього перших десяти точок доступу на тестовому поверсі ще незавершеного будівництва, ми підключаємося до спектроанализатору і бачимо, що більше 40% ефіру в 2.4 Ггц вже зайнято. Навколо жодної живої душі, ми в порожньому будинку, тут немає чужих мереж і домашніх Wi-Fi роутерів. Половину ефірного часу займає передача beacon'ов — вони завжди передаються на мінімально підтримуваної точками швидкості передачі, при великій щільності це особливо помітно. Додавання в ефір нових SSID посилює проблему. При мінімальному дата-рейте в 1 Mbps вже 5 SSID при 10 точках в зоні поразки призводять до стовідсоткової завантаженні ефіру виключно биконами. Відключення всіх data rates нижче 12 Mbps (802.11 b) кардинально змінює картину.

5.2. Radius VLAN assignment
Великі L2-домени — це весело. Особливо на бездротової мережі. Multicast забиває ефір, відкриті peer-to-peer коннекти всередині сегмента дозволяють одному зараженому хосту атакувати інші, і т. д. Очевидним рішенням став перехід на 802.1 X. Клієнти були поділені на кілька десятків груп. Для кожної був заведений окремий VLAN та окремі списки доступу.

Вольовим рішенням у довірених SSID був заборонений p2p. Для WLAN з авторизацією по радіусу WLC дозволяє об'єднати будь-яку кількість VLAN в логічну групу і видавати кожному користувачеві потрібний сегмент мережі. При цьому користувачеві не потрібно замислюватися про те, куди підключитися. У мріях кінцева схема виглядала як два SSID — PSK для гостьових користувачів і WPA2-Enterprise для корпоративних, але ця мрія швидко розбилася об сувору реальність.

5.3. 30+ SSID
Необхідність в нових WLAN'ах з'явилася відразу ж. Частина пристроїв не підтримувала .1x, але повинна була знаходитися в околодоверенных сегментах. Для іншої частини потрібний p2p, а у решти були особливо специфічні вимоги, як, наприклад, PBR трафіку через сервера, або ipv6-only.

При цьому точки 3602 дозволяють віщати не більше шістнадцяти SSID (а 802.11 ac модулі, на які була надія в майбутньому, не більше восьми).

Але оголошувати навіть 16 SSID означає забити биконами досить солідний відсоток ефіру.
На допомогу прийшли Ap Groups — можливість мовити певні мережі з певних точок доступу. В нашому випадку кожен поверх був розбитий на окрему групу з індивідуальним набором для кожної. При бажанні дроблення можна продовжувати і далі.

5.4. Multicast і mDNS
З попереднього пункту випливає наступна проблема: девайси, які потребують multicast і mDNS (Apple TV найбільш часто зустрічається примірник). Всі користувачі побиті за VLAN'ам і не бачать чужий трафік, а тримати в кожному VLAN'е за окремим mDNS-пристрою дещо проблематично. На додаток до цього спочатку failover svi на роутерах був реалізований за допомогою VRRP, який використовує multicast, і за замовчуванням відправляє ключ аутентифікації відкритим текстом.

Підключаємося до Wi-Fi, слухаємо трафік, крафтим hello-пакет, стаємо майстром. Додаємо md5 до VRRP. Тепер hello-пакети в якійсь мірі захищені. Захищені і відправляються в усіх клієнтів. Як і весь інший multicast трафік в межах сегмента. Іншими словами:

  • у нас повноцінно не працюють пристрої, що вимагають mDNS;
  • непотрібний клієнтам трафік (і це були аж ніяк не тільки hello від VRRP) все одно відправляється в них.
Рішення другої проблеми, здавалося, напрошувалося само собою — відключити multicast в бездротової мережі. З першою проблемою на той момент (до виходу 7.4) було все трохи складніше. Доводилося піднімати в потрібних VLAN'ах сервер, що слухає mDNS запити, і ретранслирующий їх між клієнтами і пристроями. Рішення очевидно ненадійне, нестабільний і не дає повноцінно вирішити проблему наявності multicast'а.

Починаючи з 7.4 Cisco викотили mDNS-proxy на рівні контролера. Тепер всі mDNS запити з певною «service string» всередині (наприклад, _airplay._tcp.local. для Apple TV) стало можливо надсилати лише інтерфейси з певним mDNS-профілем (причому це можна окремо настроїти на кожній точці доступу, що дозволяє транслювати запити навіть з тих VLAN'ів, до яких контролер не підключений фізично за рахунок підключення туди лише однієї точки). І цей функціонал працює незалежно від глобальних налаштувань multicast'а. Що дозволяє виключити останній і благополучно відкидати пакети. Що і було зроблено.

5.5. І знову multicast
Ми вимкнули multicast. Навантаження на мережу зменшилася. Здавалося б, щастя є. Але тут з'являється один-два клієнта, яким він все-таки конче потрібен. На жаль, без милиць тут обійтися не вдалося. І милицею цим виявився FlexConnect, який ніяк для цих цілей не призначений, і взагалі…

FlexConnect — це функціонал, що дозволяє прив'язувати до контролера точки, що знаходяться, наприклад, у віддаленому офісі, для централізованого управління. І головною особливістю для нас в даному випадку стане можливість реалізувати Local Switching на таких точках. Потрібно це для можливості точок вручну обробляти трафік (віщати SSID і т. д.) при падінні зв'язності з контролером або в тому випадку, якщо ми не хочемо форсувати весь трафік від точки через нього.

Заводимо окрему крапку в FlexConnect групу, створюємо окремий SSID в цій групі і обробляємо там весь трафік локально. З одного боку, це явне використання функціоналу не за призначенням, але з іншого — у нас з'являється можливість піднімати маленькі бездротові нефильтрующиеся L2-домени за необхідності, не зачіпаючи основну інфраструктуру.

5.6. Rogue AP
Рано чи пізно постає необхідність захиститися від evil twin, т. к. BYOD не дозволяє захистити клієнта від самого себе. Всі точки вбудовують в биконы фрейм, який відповідає за приналежність до контролера. При отриманні бикона з некоректним кадром — його BSSID записується.

Будь-яка Lightweight Access Point кожен заданий інтервал часу знімається зі свого каналу на 50 мс для збору інформації про інтерференції, шумі і невідомих клієнтів і точках доступу. При знаходженні rogue AP з SSID ідентичним одному з довірених генерується відповідний запис у таблиці «ворогів». Далі з'являється можливість або відловити пристрій людським ресурсом, або придушити його силами контролера. В останньому випадку контролер віддає декількох точках, які не беруть участь в передачі даних, снифать трафік від «близнюка» і відправляти deauth-пакети як йому від імені клієнтів, так і всім клієнтам від його імені.



Потенційно даний функціонал дуже цікавий і дуже небезпечний одночасно. Неправильна конфігурація і ми знищуємо весь невідомий контролеру Wi-Fi в радіусі покриття точок.

6. Висновок
Стаття не претендує на звання якогось гайду про те, як правильно будувати бездротову мережу. Скоріше це просто основні проблеми, з якими ми зіткнулися при заміні і розширенні офісної інфраструктури.

Зараз тільки в основному офісі у нас більше трьох тисяч бездротових клієнтів і більше трьох сотень точок доступу, так що якісь рішення можуть бути незастосовні або є надмірними в інших умовах.

P. S. Не знайшов на хабре жодної згадки WLCCA. Це аналізатор конфігурації контролера, який вказує на деякі проблеми, так і дає поради по налаштуванню. Інвайт можна запросити тут. Заливаємо в нього висновок show run-config (215 000 рядків в нашому випадку) і отримуємо на виході сторінку з розбором всього цікавого на WLC. Enjoy!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.