Ни единого разрыва: как мы создавали беспроводную сеть для 3000 устройств

Wireless Society ^[1] 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 вызывает ^[2] нешуточный стресс, и очевидно мешает работе), обрывы соединения. Периодические попытки использовать Wi-Fi-телефоны проваливались из-за неработающего роуминга. Ноутбуков со встроенным Ethernet становилось все меньше (спасибо появлению MacBook Air и гонке производителей за толщиной корпуса), подавляющее большинство мобильных телефонов уже требовали постоянного подключения к интернету.

Эфир был постоянно занят, старенькие точки доступа не выдерживали нагрузки. Начинались дисконнекты пользователей при подключении 25+ устройств к одной точке доступа, не поддерживался стандарт 802.11n и диапазон 5 Ггц. Помимо этого, для нужд мобильной разработки в офисе находился ворох SOHO-роутеров, подключенных к различным эмуляторам (средствами NetEm ^[3]).

С точки зрения логической схемы с момента перехода на централизованные решения в 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.11ac Wave 1 путем подключения дополнительного антенного модуля. К сожалению, эти модули так и не стали совместимы с произведенными для России точками с индексом -R-, поэтому для полноценной поддержки 802.11ac приходится менять точки доступа на 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-пингом).

С последним пунктом и возникли сложности. Суть проблемы — в соответствии с таблицей ^[4] в случае любой непонятной ситуации — 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]), так что сильно заострять на этом внимание не буду. Разве что вкратце о специфике.

5.1. Data rates

Представим, что после базовой настройки контроллера и подключения к нему первых десяти точек доступа на тестовом этаже еще недостроенного здания, мы подключаемся к спектроанализатору и видим, что более 40% эфира в 2.4 Ггц уже занято. Вокруг ни единой живой души, мы в пустом здании, здесь нет чужих сетей и домашних Wi-Fi-роутеров. Половину эфирного времени занимает передача beaconʼов — они всегда передаются на минимально поддерживаемой точками скорости передачи, при большой плотности это особенно заметно. Добавление в эфир новых SSID усугубляет проблему. При минимальном дата-рейте в 1 Mbps уже 5 SSID при 10 точках в зоне «поражения» приводят к стопроцентной загрузке эфира исключительно биконами. Отключение всех data-rates ниже 12 Mbps (802.11b) кардинально меняет картину.

5.2. Radius VLAN assignment

Большие L2-домены — это весело. Особенно на беспроводной сети. Multicast забивает эфир, открытые peer-to-peer коннекты внутри сегмента позволяют одному зараженному хосту атаковать другие, и т.д. Очевидным решением стал переход на 802.1X. Клиенты были поделены на несколько десятков групп. Для каждой был заведен отдельный VLAN и отдельные списки доступа.

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

5.3. 30+ SSID

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

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

Но объявлять даже 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 ^[6], т.к. BYOD не позволяет защитить клиента от самого себя. Все точки встраивают в биконы фрэйм, отвечающий за принадлежность к контроллеру. При получении бикона с некорректным фреймом — его BSSID записывается.

Любая Lightweight Access Point ^[7] каждый заданный интервал времени снимается со своего канала на 50 мс для сбора информации об интерференции, шуме и неизвестных клиентах и точках доступа. При нахождении rogue AP с SSID идентичным одному из доверенных генерируется соответствующая запись в таблице «врагов». Дальше появляется возможность либо отловить устройство людским ресурсом, либо подавить его силами контроллера. В последнем случае контроллер отдает нескольким точкам, не участвующим в передаче данных, снифать трафик от «близнеца» и отправлять deauth-пакеты как ему от имени клиентов, так и всем клиентам от его имени.

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

6. Заключение

Статья не претендует на звание какого-то гайда о том, как правильно строить беспроводную сеть. Скорее это просто основные проблемы, с которыми мы столкнулись при замене и расширении офисной инфраструктуры.

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

P.S. Не нашел на хабре ни одного упоминания WLCCA. Это анализатор конфигурации контроллера, указывающий как на некоторые проблемы, так и дающий советы по настройке. Инвайт можно запросить тут ^[8]. Заливаем в него вывод show run-config (215 000 строк в нашем случае) и получаем на выходе страничку с разбором всего интересного на WLC. Enjoy!

Автор: Mail.Ru Group

Источник ^[9]