Ни единого разрыва: как мы создавали беспроводную сеть для 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.11n и диапазон 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.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-пингом).

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

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

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

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

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

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

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

Автор: Mail.Ru Group

Источник