Модернизация сети одной из компаний

Многие компании, зависящие от беспроводных сетей стандарта 802.11b, объединяют их со своими проводными сетями. При этом беспроводные сети зачастую требуют индивидуального подхода к решению проблем и повышенного внимания к себе. Небольшие неполадки могут налагаться друг на друга и приводить к полной остановке беспроводной сети. Эксперименты в конструировании и управлении, проводимые на действующей сети, весьма опасны. Специалисты компании UtahWISP, поставщика услуг доступа в Internet на базе технологий беспроводных сетей (wireless ISP, WISP), создавали свою инфраструктуру, преодолевая множество трудностей.

Когда UtahWISP начала свою деятельность в Северной Юте, она была одной из первых компаний, обеспечивавших широкополосный доступ в Internet в местах, не охваченных сетями других компаний, продвигавших широковещательные решения. Сотрудники компании создали пару беспроводных точек доступа (AP) на расположенных неподалеку друг от друга башнях и установили приемники на высоких зданиях у своих клиентов. Таким образом, те, кто находился в прямой видимости башни, имел широкополосный доступ в Internet.

Поскольку компания обеспечивала сервис, который никто другой в этой местности не предоставлял, сеть UtahWISP стало лихорадить из-за быстрого роста количества пользователей. Когда число клиентов превысило 200, а количество точек доступа достигло 12, некоторые клиенты, обслуживаемые беспроводной сетью, начали испытывать затруднения при просмотре сети, появлялись потерянные пакеты, замедление ответов от ping. Поскольку нагрузка на сеть UtahWISP заметно возросла, клиенты стали периодически терять соединение.

Перегрузка беспроводной сети усугубила общие проблемы, хотя, на мой взгляд, UtahWISP имеет далеко не худшие показатели производительности сети. Собрав некоторую дополнительную информацию по общим показателям производительности, я посетил UtahWISP, чтобы посмотреть, как можно повысить скорость работы сети. В этой статье я расскажу о проведенных мероприятиях по модернизации сети с целью увеличения ее производительности. Здесь будет последовательно описан весь процесс модернизации, от поверхностного взгляда на проблему до идентификации потенциальных неполадок и реализации решений, которые привели, в конце концов, к решению поставленной задачи.

Общее представление

Я знал, что сеть была медленной, но после тщательной проверки мне так и не удалось обнаружить причины замедления работы. Я видел, что имеется значительная неиспользуемая полоса пропускания, а причины снижения производительности не удается подвести под общепринятые шаблоны. Более того, общая производительность не зависела от количества пользователей и от времени их работы. Некоторые пользователи регулярно сообщали о затруднениях в работе, хотя в то же время другие имели хорошую скорость соединения и малое время отклика на команду ping. Дейл Мередит, ИT-менеджер UtahWISP, сказал, что ему не удается установить причин происходящего.

В прошлом я имел дело с медленными беспроводными сетями, но этот случай был одним из самых трудных. В обслуживаемой UtahWISP беспроводной среде многие проблемы накладывались одна на другую и влияли на производительность сети. Но чем же эта сеть в действительности отличалась от других? Конечно же, сигнал экранировался и блокировался зданиями и деревьями. Это совсем не то, что имеет место в офисах, где препятствием для сигнала становятся стены и мебель. Настоящее различие было в масштабах сети.

Прежде чем погружаться в подробности, еще раз вернемся к общей картине сети. Я знал, что UtahWISP имеет 12 точек доступа на двух башнях. Каждая из башен обслуживала клиентов на территории радиусом десять миль и имела быстрый беспроводной канал связи с главным офисом. В этом офисе находилась точка подключения к главному маршрутизатору UtahWISP.

Чтобы получить карту сети, я использовал AdRem Net-Crunch 3.1 Premium. NetCrunch не только позволил мне начать процесс построения наглядной карты сети, но и предоставил компании UtahWISP полноценную систему мониторинга и создания отчетов. Получив возможность производить автоматическое обнаружение, я построил пространственную карту сети. Хотя результаты автоматического поиска потребовали кое-что сделать вручную, они помогли мне сэкономить немало времени. После некоторой обработки я получил точное представление о сети Utah-WISP, показанное на экране 1.

Экран 1. Карта сети UtahWISP, созданная программой NetCrunch

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

NetCrunch обеспечивает более широкие возможности мониторинга, в том числе возможность мониторинга счетчиков SNMP, данных системных журналов и счетчиков производительности Windows, в частности время отклика на ping. Программа имеет десятки параметров для настройки мониторинга отдельных сетей. NetCrunch предоставляет развитые средства построения диаграмм и графиков для отслеживания выбранных параметров в реальном времени.

Я решил использовать этот продукт прежде всего для отслеживания проблем с производительностью сети. Карта сети Net-Crunch сразу показала наличие проблемы. На ней были видны медленные ответы и большие задержки для некоторых хостов, а в определенные периоды времени сеть казалась особенно медленной. Я замечал, что хосты часто отключались и на карте появлялись красные значки отключившихся устройств. Возможно, это было результатом потери пакетов, поскольку значки на карте становились красными произвольно.

Сбор статистики

Стало ясно, что проблемы в UtahWISP были серьезнее, чем я мог предположить. Обычно можно выделить основную проблему, но эта сеть была иной. Я не нашел главной проблемы, но увидел множество мелких неполадок, результатом которых было значительное снижение производительности сети.

Мне необходимо было получить как можно больше информации о сети, поэтому я решил установить устройство Network Intelligence enVision HA Series для сбора информации из журналов. Это устройство позволило собрать статистику от различных устройств по сети и объединить все данные в одном месте для анализа.

Система Network Intelligence HA была настроена при помощи программного обеспечения enVision, которое оказалось очень удобным для сбора, объединения и создания отчетов по данным журналов с различных платформ. Система имеет встроенный набор шаблонов для интерпретации сообщений о событиях, приходящих с десятков маршрутизаторов, брандмауэров и других сетевых устройств.

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

Я настроил маршрутизатор Cisco на отправку данных Syslog в систему Network Intelligence. Кроме того, я настроил enVision для сбора журналов, событий Windows с важных серверов компании, таких как почтовые серверы, Web и DNS. Это позволило мне сопоставить системные события, происходящие на многих устройствах, находящихся в различных местах сети, и получить необходимые данные для того, чтобы вернуться назад и отследить любую проблему.

После нескольких минут работы по сбору данных журналов я увидел картину монитора сообщений enVision, которая показана на экране 2, и определил по крайней мере одну из возможных причин возникновения проблем с производительностью: сеть была поражена вирусами и шпионским программным обеспечением и загружена трафиком от одноранговых сетей (P2P).

Экран 2. Монитор сообщений EnVision

Объединение беспроводных сетей

Когда была создана «энциклопедия» журналов событий, я поставил себе задачу узнать больше о трафике беспроводной сети. Я определил, что беспроводной трафик был полудуплексным, из чего можно было заключить, что присутствует значительное количество коллизий. В полудуплексных сетях множество станций разделяют между собой единую среду, такую, например, как сетевой кабель, а в нашем случае это был беспроводной канал. Поскольку осуществлять передачу в данный момент времени в подобной среде может только один хост, необходимо иметь алгоритм управления трафиком для предотвращения коллизий пакетов. Этот процесс должен гарантировать, что другие передающие станции будут обнаруживать коллизии. Если пакеты передаются одновременно, происходит коллизия, и их необходимо передавать заново. Если в одной и той же среде работает много хостов, появляется большое количество коллизий и, соответственно, увеличивается число повторных передач пакетов. По этим причинам эффективность полудуплексной сети сильно зависит от количества хостов и генерируемого ими сетевого трафика.

В полудуплексной кабельной сети использовался общий концентратор. В полнодуплексной кабельной сети у вас имеется коммутируемая среда. Utah-WISP имела эквивалент гигантского концентратора с включенными в него более чем двумя сотнями пользователей.

Проблема оказалась еще сложнее. Каналы беспроводной сети проходили через перегруженные, ненадежные и иногда пересекающиеся спектры частот. Фреймы, передаваемые через радиосеть, терялись и требовали повторной ретрансляции. Частые повторные передачи вызывали заметные задержки в передаче TCP/IP-пакетов и перегрузку в сети. Стандарт TCP/IP рассчитан на потери пакетов при перегрузке сети, но не на потерю пакетов от разрыва соединений. Когда пакет теряется, для протокола это означает, что сеть перегружена и занята. Соответственно, он реагирует дроблением окна передачи перед повторной передачей пакетов. Запускается таймер ретрансляции, замедляющий передачу, компенсируя тем самым с точки зрения протокола нагрузку на сеть. В результате снижается загрузка сети и производительность.

Более того, когда радиосигнал слабый, производительность страдает еще сильнее. «Некоторые поставщики продавали нам оборудование, находившееся в опытной эксплуатации, — пояснил Дейл. — Наложение спектров в нашей сети значительно больше, чем в других региональных городских радиосетях». Эти перекрывающиеся спектры в сочетании с унаследованными и устаревшими технологиями были основной проблемой, затмевающей все остальные. Некоторые из этих проблем можно было гарантированно решить, но для этого требовалось устранить любой нежелательный трафик.

Реализация проекта в три этапа

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

Снижение широковещательного трафика. Возможно, проще всего было снизить широковещательный трафик. Компьютеры используют широковещательные сообщения для обнаружения других систем в сети и оповещают о своем присутствии в этой сети. Широковещательный пакет проходит через всю сеть. Допустим, в сети Utah-WISP одна из клиентских систем посылает подобный пакет на башню, которая передает его всем остальным клиентам в зоне обслуживания. Затем пакет посылается обратно в главный офис, который вновь пересылает его на другую башню, а та передает этот пакет всем клиентам своей зоны обслуживания. Так каждый широковещательный пакет попадает на каждую из систем сети.

Чтобы решить эту проблему, мы быстро перестроили структуру подсетей и настроили маршрутизаторы для снижения уровня широковещательного графика. По сути, мы разорвали сеть и разместили системы в небольших сегментах так, чтобы широковещательный трафик не ходил по всей сети. Чтобы в будущем снизить широковещательный трафик через сеть, мы активизировали на коммутаторах функции кэширования протокола ARP Address Resolution Protocol и управление ARP-протоколами. Это действие не принесло особенной пользы, но повышение производительности было заметно на операциях загрузки файлов по беспроводной сети, скорость которой немного возросла.

Обеспечение безопасности сети. Работая с провайдером WISP, я не имел возможности управлять клиентскими системами и не мог установить обновления и персональные брандмауэры. Также нельзя было наложить слишком много ограничений на различные типы трафика с целью его блокировки. Хотя пользователям разослали по почте сообщения с рекомендациями по улучшению защиты систем, я знал, что кто-то проигнорирует эти советы, а кто-то не имеет достаточного опыта и знаний для того, чтобы ими воспользоваться.

К счастью, провайдер имел четко определенную политику использования сети, описанную в контрактах на подключение. Политика запрещала запуск в сети серверов и работу в одноранговых сетях P2P с использованием разделяемых локальных ресурсов. Поэтому UtahWISP начала блокировать соответствующий трафик, такой как входящий Web и почтовый трафик. Таким образом компания значительно снизила уязвимость сети от некоторых клиентов, которые по незнанию открывали лазейки спамерам и взломщикам.

В процессе обновления сети система обнаружения вторжений, Intrusion Detection System (IDS), сообщила, что некоторые из клиентских систем часто сканировали другие системы сети. Но ведь клиентским системам не было никакого смысла подключаться к другим системам. Я принял эту активность за наиболее общий признак заражения систем червями. Одним из привычных средств распространения подобных вредоносных программ является электронная почта. Таким образом, если бы UtahWISP удалось предотвратить проникновение вирусов и червей в сеть через почту, шансы пользователей подцепить подобные вредоносные программы вместе с почтовыми сообщениями устремились бы к нулю.

Черви оказывали влияние на две системы электронной почты: Microsoft Exchange Server 2003 и NetIQ MailMarshal SMTP. Переход на Exchange 2003 является более надежным и хорошо защищенным решением. Для продуктов, используемых в UtahWISP, очень важна полная интеграция с Windows Server, позволяющая создавать для каждого клиента одну учетную запись, которая будет использоваться им при работе с Web, дисковыми хранилищами и электронной почтой. Другими важными характеристиками являются надежность, производительность и масштабируемость. Одним из наиболее важных требований к продуктам в UtahWISP была возможность обеспечения доступа к почте через Web с помощью Outlook Web Access (OWA).

После того как мы разобрались с Exchange, я приступил к настройке и установке продукта компании NetIQ MailMarshal. Это продукт, обеспечивающий безопасность и интегрируемый напрямую с Exchange. Его можно использовать в качестве самостоятельного SMTP-шлюза. Я выбрал вариант SMTP-версии, поскольку хотел, чтобы шлюз работал отдельно от сервера Exchange, а UtahWISP не имела особой нужды в их интеграции, хотя MailMarshal наиболее уместен в корпоративной среде, где политики управления более закрытые и сильные. Я настроил продукт более консервативно по сравнению с другими провайдерами WISP и заблокировал только те сообщения, которые явно содержали вирусы. Практически сразу после установки я зафиксировал почти 30-процентное снижение объема почты, обрабатываемой сервером Exchange. Каждое сообщение, содержащее спам, не проходило через шлюз и каждый заблокированный вирус снижал общий уровень загрузки сети.

Таким образом, я успешно ограничил появление множества ненужных пакетов в сети. Но хотя разница была заметная, этого оказалось недостаточно. Посмотрев на карту, созданную NetCrunch, я все еще наблюдал в сети задержки запросов ping.

Управление сетевыми ресурсами. Следующим шагом было управление реальным трафиком, проходящим через сеть. Вместо установки брандмауэра и полной блокировки некоторых типов трафика я выбрал управление этим трафиком. Для этой цели я воспользовался продуктом компании Packeteer PacketShaper 6500. Монитор сетевого трафика позволил мне сформулировать правила, которые устанавливали высокие приоритеты для одного типа трафика и ограничивали скорость передачи пакетов других типов. Например, высший приоритет был предоставлен браузеру Web, а трафик одноранговых сетей P2P был ограничен скоростью, сопоставимой со скоростью модемного соединения. Более того, клиенты получили от UtahWISP тарифные планы, зависящие от необходимой им полосы пропускания. Ранее компания реализовывала эти ограничения на основе соответствующих настроек точек доступа, теперь же с помощью PacketShaper UtahWISP получила возможность более гибкого управления полосой пропускания каждого пользователя. Появилась возможность создания отчетов об актуальном использовании полосы пропускания.

Я позволил устройству PacketShaper собрать статистику за несколько часов и затем просмотрел некоторые графики. Я знал, что трафик одноранговых сетей P2P у UtahWISP велик, но у меня не было возможности оценить его объем до тех пор, пока я не посмотрел на эти графики. В действительности полоса пропускания, используемая P2P-трафиком, была так велика, что на диаграмме она перекрывала все остальные типы трафика. Более того, я был удивлен, увидев, что основную часть этой полосы занимают всего несколько пользователей. Некоторые пользователи имели пять и более одновременно запущенных P2P-приложений. Наличие общей оценки сети оказалось очень полезным для определения того, в каком направлении двигаться дальше. Я установил ограничения на весь P2P-трафик и предоставил таким протоколам, как HTTP и DNS, высокий приоритет в сети. Наконец, я распределил всех клиентов по отдельным классам обслуживания на основе тарифных планов, которые они приобрели.

После установки всех правил я включил монитор пакетов и сразу же увидел значительное снижение сетевого трафика, как показано на экране 3. Теперь, когда P2P-трафик был ограничен, я смог идентифицировать другие сетевые проблемы, покрывавшиеся ранее трафиком одноранговых сетей. Например, я заметил, что один из клиентов генерировал необычайно большое количество исходящих сообщений электронной почты. Значит, либо он является спамером, либо, что более вероятно, его станция поражена вирусом. Представители службы технической поддержки UtahWISP связались с клиентом и помогли решить проблему.

Экран 3. Снижение сетевого трафика, показанное PacketShaper

DMZ и серверное оборудование

Хотя исходная проблема была ликвидирована, я решил пойти на шаг дальше и проверить демилитаризованную зону DMZ UtahWISP. DMZ — это специальный сетевой сегмент, изолированный как от Internet, так и от внутренней сети. Оказалось, что в компании DMZ отсутствовала вообще. Вместо этого все критически важные серверы и офисные компьютеры находились в одной сети с клиентскими компьютерами. Если бы серверы Utah-WISP удалось взломать, они превратились бы в площадку для запуска других атак внутри сети. Для построения DMZ я воспользовался системой компании Network Engines NS6300 ISA Server.

Cистема Network Engines представляет собой сервер с установленной операционной системой Windows Server 2003 и ISA Server 2004, предварительно соответствующим образом настроенный и готовый к проведению базовой настройки. Вскоре я получил полнофункциональную DMZ, изолированную от остальной сети. Для начала я создал отдельную сеть для офисных компьютеров. Поскольку устройство имеет на передней панели шесть сетевых портов, один из них я выделил для внешнего соединения, другой для управления устройством и еще четыре — для создания изолированных сегментов сети. Сейчас серверы UtahWISP размещены в DMZ и защищены брандмауэром. Затем я проверил сами серверы. Их аппаратная часть соответствовала задачам компании, но я знал, что производительность Web-сервера значительно улучшится, если расширить имеющуюся оперативную память с 256 Мбайт до 4 Гбайт. Поэтому я установил восемь модулей памяти по 512 Мбайт, изготовленных компанией Micron Technologies для модернизации самого важного сервера. Хотя я и не выполнил официальных тестов производительности до и после модернизации, после увеличения оперативной памяти скорость явно возросла.

Серверная стойка

Моей главной целью была полная модернизация сети, поэтому я осмотрел стойки с серверами UtahWISP. Возле каждой стойки я обнаружил множество мониторов, клавиатур и мышей, предназначавшихся для управления различными серверами. Проходя различные этапы модернизации, я часто хватал не ту мышь или набирал что-то не на той клавиатуре. Кроме того, управлять несколькими серверами во время настройки было неудобно.

Решить проблему помог 16-портовый переключатель клавиатуры и мониторов с пятиметровыми кабелями OmniView компании Belkin. В этом переключателе кабели мыши, клавиатуры и видео, идущие от двух серверов, комбинируются в единый кабель. Такая конструкция позволила мне без труда объединить все серверы компании в один переключатель клавиатуры и управлять ими с одного стола, расположенного неподалеку от серверов.

В компании Belkin был закуплен стоечный источник бесперебойного питания mni-Guard 3200VA, позволивший заменить четыре старых источника бесперебойного питания, использовавшихся до модернизации. Этот источник обеспечивал ту же мощность, что и старые системы, но места при этом занимал вчетверо меньше. Сетевые кабели различных цветов помогли мне без труда различать сегменты сети.

Финальный аккорд

После недели работы сети в UtahWISP было проведено совещание для подведения итогов и обзора сделанных изменений. Администратор сети сообщил, что скорость работы сети увеличилась как минимум на 50 процентов, а клиенты, имевшие наибольшее количество проблем, отметили значительный рост производительности. Кроме того, когда добавились новые компоненты, администратор сети получил дополнительные возможности для отслеживания специфичных проблем. Таким образом, реконструкция сети была закончена и клиенты остались довольны.

Марк Барнетт - Независимый консультант по безопасности и автор, специализирующийся на безопасности в Windows. Имеет звание IIS MVP. Автор книги Perfect Passwords and Hacking the Code (Syngress). mburnett@xato.net