Размещено на http://www.allbest.ru/

Содержание

• Введение
• 1. Аналитическая часть
• 1.1 Сведения о предприятии
• 1.2 Положение об отделе
• 1.3 Структура предприятия
• 2. Проектная часть
• 2.1 Существующая структура локальной сети университета
• 2.1.1 Модель сети
• 2.1.2 Организация доступа в Интернет для пользователей
• 2.1.3 Используемое программное обеспечение
• 2.1.4 Антивирусная защита сети
• 2.1.5 Проблемы данной структуры сети
• 2.2 Итоговая структура локальной сети
• 2.2.1 Модель сети
• 2.2.2 Организация доступа в Интернет
• 2.2.3 Используемое программное обеспечение
• 2.2.4 Антивирусная защита сети
• 2.2.5 Проблемы данной структуры сети
• 2.2.6 Перспективы и планы развития сети
• 2.3 Регламент работы системного администратора сети
• 2.3.1 Мониторинг работы локальной сети
• 2.3.2 Мониторинг работы Интернет
• 2.3.3 Резервное копирование
• 2.3.4 Корпоративная почта
• 2.3.5 Антивирусная защита
• 3. Техника безопасности и охрана труда
• 3.1 Безопасность и экологичность проекта
• 3.2 Эргономичность проекта
• 3.3 Описание зрительной работы администратора
• 3.4 Расчеты по технике безопасности в помещении технического центра университета
• Заключение
• Список используемых источников
• Приложения

Введение

Любое современное предприятие обладает собственной информационной структурой, обеспечивающей решение производственных задач.

Данной структурой в настоящее время является локальная вычислительная сеть (далее - локальная сеть), соединяющая все или выделенные компьютеры учреждения в единое целое, упрощая обмен информацией и совместную работу сотрудников. Современное предприятие уже практически нельзя представить без наличия работающей локальной сети и программных продуктов, работающих в подобной среде.

Одной из основных задач в этом случае является передача документов между сотрудниками и отделами с целью сокращения как денежных затрат на распечатку, так и затрат времени на передачу документов.

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

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

В первой главе описана структура самого университета и технического центра, а также выполняемых последним задач.

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

В третьей главе описывается техника безопасности при работе с оборудованием в техническом центре.

1. Аналитическая часть

1.1 Сведения о предприятии

Начальник ТЦ - занимается организацией работы подразделения, эффективного взаимодействия с другими подразделениями вуза, планированием работы подразделения в соответствии с планом работы вуза, распределяет работу в соответствии с должностными инструкциями сотрудников.

Инженер-электронщик - занимается вопросами технического обслуживания и ремонта средств вычислительной и копировально-множительной техники. Количество - 1 человек.

Администратор сети - занимается поддержкой сервера и сайта Университета, администрированием работы локальной сети Университета, контролем использования сети Интернет. Количество - 1 человек.

Инженер-программист - занимается обслуживанием и сопровождением сайта Университета. Количество - 1 человек.

Инженер - занимается подготовкой, размножением и тиражированием бланочной документации и методических материалов, подготовкой и выпуском периодических изданий. Количество - 2 человека.

В процессе прохождения преддипломной практики я формально исполнял обязанности инженера-программиста, работы по анализу и преобразованию локальной сети проводились совместно с администратором сети.

Основные задачи

1. формирования политики вуза в области использования средств вычислительной техники;

2. внедрение современных программно-аппаратных средств в систему управления вузом и учебный процесс;

3. содержание в рабочем состоянии и администрирование каналов доступа в сеть Интернет;

4. обеспечение вуза бланковой документацией и выпуск периодических изданий.

Функции

Основные функции ТЦ:

1. сопровождение программного обеспечения задач АСУ ВУЗ и учебного процесса;

2. анализ, планирование и контроль состояния средств вычислительной техники;

3. техническое обслуживание и ремонт средств вычислительной и копировально-множительной техники университета;

4. программно-аппаратная поддержка учебного процесса;

5. тиражирование методических и других материалов по заявкам кафедр.

6. развитие, наполнение, администрирование WEB-сайта и его форумов.

7. развитие и администрирование ЛВС;

8. контроль эффективности использования ВТ во время работы в Интернет;

9. администрирование каналов доступа в сеть Интернет;

1.3 Структура предприятия

На момент начала работ, описанных в данном дипломном проекте, в единую локальную сеть были объединены главный корпус, и корпуса технического и педагогического факультетов.

В данный момент, все перечисленные выше корпуса находятся в единой локальной сети и имеют доступ ко всем локальным ресурсам.

2. Проектная часть

2.1 Существующая структура локальной сети университета

Изначально проекта локальной сети университета не существовало как такового. В связи с его развитием, появлением новых корпусов, появлением необходимости работы в сети Интернет, каждая из этих задач по сути решалась отдельно.

При этом, если связь между главным корпусом и корпусом технического факультета отвечала минимальным требованиям по надёжности и пропускной способности, то связь с педагогическим факультетом не была пригодной для более-менее серьёзного обмена данными. Что касается общежития №2, то локальная сеть данного корпуса вообще не имела связи с локальной сетью университета, т.к. получала доступ в Интернет с помощью провайдера ООО "Казахтелеком" [1].

Но даже существующие мощности локальной сети практически не были задействованы в организации совместного хранения и использования данных. Использование поднятой на сервере службы внутренней электронной почты затруднялось неудобным web-интерфейсом и отсутствием руководства по её использованию.

Далее, подробно рассмотрим существующую ранее структуру локальной сети университета, её цели, задачи, принцип работы и недостатки.

2.1.1 Модель сети

В момент начала преддипломной практики в техническом центре Костанайского социально-технического университета, локальная сеть университета выглядела следующим образом:

Рисунок 1. Структура локальной сети университета

Данная схема создана с помощью утилиты мониторинга состояния локальной сети The Dude [2].

Поясним каждый элемент в данной схеме:

1. InfoCenter. Это маршрутизатор ООО "Инфоцентр" [3], предоставляющего в тот момент университету доступ к сети Интернет и обеспечивающего связь между главным корпусом по ул. Герцена, 27 и корпусом педагогического факультета по ул. Баймагамбетова, 160. Доступ к нему производился посредством подключения типа PPPoE [4].

2. 10.190.1.1 Это главный маршрутизатор локальной сети университета, организованный на основе MikroTik Router OS [5]. В его задачи входили организация раздачи интернет-трафика и локального трафика между подчинёнными маршрутизаторами университета, подсчёт расхода трафика средствами mangle, ограничение максимальной загруженности всех каналов связи с применением протокола шейпинга трафика HTB. К сожалению, на схеме нельзя показать все виртуальные интерфейсы маршрутизатора, созданные по протоколу VLAN [3].

3. 10.190.3.2 Это маршрутизатор локальной сети педагогического факультета. Он имел свой собственный аккаунт для выхода в интернет посредством Инфоцентра, связь с центральным маршрутизатором была реализована с помощью технологии 802.11Q VLAN, наложенной на физическую линию связи VDSL.

4. 10.190.2.2 Это маршрутизатор локальной сети главного корпуса. Весь обмен трафиком со всеми остальными точками производится через главный маршрутизатор 10.190.1.1, через виртуальный интерфейс по технологии 802.11Q VLAN, наложенном на физическую линию связи VDSL.

5. 10.190.1.5 Это маршрутизатор локальной сети технического факультета. Он физически связан с главным маршрутизатором по линии VDSL.

6. server. Это наш LAPM [5] сервер, обеспечивающий работу службы DNS, сайта университета и локальной почты (практически неиспользуемой на тот момент).

7. 10.190.1.4 Это прокси-сервер, получающий HTTP запросы от роутеров, и пересылающий ответы, приходящие со спутниковой тарелки.

8. sat. Спутниковая тарелка, обеспечивающая университет входящим интернетом.

Связи между элементами схемы:

1. Связь между InfoCenter и 10.190.1.1 Физически представлял собой два VDSL модема, работающих в режиме моста, использующих полевой кабель в качестве среды передачи данных. С другой стороны канал связи подключался к оборудованию ООО "Инфоцентр".

2. Ширина предоставляемого канала доступа в Интернет составляла 1,5 Мбит/с для входящего и 512 Кб/с для исходящего трафика соответственно.

3. Связь между 10.190.1.1 и 10.190.3.2 Это "виртуальный" канал связи VLAN [6] между главным маршрутизатором и маршрутизатором педагогического факультета. Реализованный с помощью технологии VLAN [6], физически он представлял собой канал, совмещённый с основным каналом связи Инфоцентра. Пропускная способность зависела от загруженности основного канала связи.

4. Связь между 10.190.1.1 и 10.190.2.2 Это также виртуальный канал связи [6], основанный на VDSL [7] канале связи между главным и техническим корпусами. Его максимальная пропускная способность зависела от загрузки данного канала, и составляла не более 14-15 Мбит/с, при условии полностью свободного канала между корпусами. На практике, для нормальной работы сети Интернет в обоих корпусах, необходимо было ограничивать максимальную ширину данной связи до 10 Мбит/с.

5. Связь между 10.190.1.1 и 10.190.1.5 Физический канал связи Ethernet, на основе кабеля UTP cat.5E. Ширина канала 10 Мбит.

6. Связи между подчинёнными маршрутизаторами и локальными сетями корпусов одинаковы, их максимальная пропускная способность составляла 100 Мбит/с.

7. Связь между 10.190.1.5 и подсетью 10.190.1.0/24. Физически эта связь представляла собой канал связи шириной в 100 Мбит/с до свитча.

8. В свитч были подключены основной и единственный сервер, обеспечивающий работу сайта, DNS службы, и внутренней электронной почты, а также прокси-сервер.

Вкратце опишем принцип работы данной структуры сети.

Сетью охвачены только три корпуса: педагогический факультет, технический факультет, и главный корпус.

При такой структуре сети, любой запрос ресурса из интернет проходит следующую логическую цепочку:

1. Запрос из подсети корпуса к подчинённому маршрутизатору

2. Запрос от подчинённого маршрутизатора к главному маршрутизатору

3. Если это HTTP-запрос, то он переадресовывается к прокси-серверу 10.190.1.4

4. Если результатов данного запроса нет в кэше прокси-сервера, то отправляем запрос прокси-сервером снова к главному маршрутизатору

5. Пересылаем запрос на наш основной шлюз Инфоцентра.

6. Приходит ответ на HTTP-запрос на спутниковую тарелку

7. Ответ пересылается на прокси сервер

8. Прокси сервер пересылает ответ на главный маршрутизатор

9. Главный маршрутизатор пересылает ответ на подчинённый маршрутизатор

10. Подчинённый маршрутизатор пересылает запрос на узел, запросивший данный ресурс.

Необходимо понимать, что логически вполне разные связи между 10.190.1.1 и 10.190.1.5,10.190.1.4, server на самом деле являются одной и то же физической линией связи между главным и техническом корпусами. Физически при этом она наиболее загружена, т.к. она реализована на технологии VDSL и имеет достаточно небольшую пропускную ширину канала - до 20 мбит/с. При этом, как показано выше, в связи с подобной реализацией маршрутизации пакетов между узлами внутренней сети, запрос и ответ для могли проходить по данному каналу связь до 4-х раз в разных направлениях, что естественно негативно отражалось на загруженности канала связи.

Именно по этой причине приходилось достаточно жёстко лимитировать загруженность этого канала обычным локальным трафиком между корпусами, т.к. его предельная загрузка в течении сколько бы то ни было длительного времени вылилась бы в невозможность нормальной работы в сети Интернет для сотрудников обоих корпусов.

Более того, при необходимости обеспечивать доступ из разных корпусов более чем к двум разным системным узлам (server и 10.190.1.4) возникает необходимость динамически делить ширину канала между ними и ограничивать максимальную его загрузку. Более того, на практике на канале шириной в 20 Мбит/с реальная достигаемая скорость составляет около 14-15 Мбит/с, что связано с особенностями реализации стандарта Ethernet.

В результате, нормальная работа сети была затруднена.

2.1.2 Организация доступа в Интернет для пользователей

По историческим причинам, доступ в сеть Интернет для пользователей университета организован с помощью системы "быстрого подключения" HotSpot, включённой в состав MikroTik Router OS [5].

Данная система представляет собой т. н. "прозрачную" прокси [8], пропускающую через себя весь трафик, исходящий от клиента. При HTTP-запросе от неавторизованного клиента его браузер перенаправляет на страничку логина/пароля. После авторизации пользователь сразу получает доступ к сети Интернет, ограниченный лишь настройками маршрутизатора.

Положительные моменты такой организации работы:

1. Не требуется приобретение и установка дополнительного ПО как на стороне сервера, так и на стороне клиента.

2. Не требуется никакой настройки оборудования клиента. Необходимо лишь иметь учётную запись, и быть подключённым к локальной сети.

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

4. Наличие встроенной системы биллинга на маршрутизаторе. Она позволяет ограничивать скорость доступа к сети Интернет у каждого из клиентов, учитывать как входящий, так и исходящий трафик, и ограничивать его потребление каждым из пользователей.

5. Наличие системы WalledGarden, позволяющей разрешать доступ к заданным ресурсам сети без авторизации в системе.

6. Возможность сменить типовое оформление на своё собственное, в формате HTML.

Проблемы при использовании HotSpot:

1. HotSpot ограничивает доступ не к Интернету, а к любой подсети, отличающейся от той, в которой находится пользователь. С помощью модуля Walled Garden можно разрешить использовать сервер локальной почты без регистрации в HotSpot. Но при этом, если пользователь войдёт в интернет, то на доступ ко всем локальным ресурсам (внутренний сайт, локальная электронная почта) будут накладываться те же ограничения, что и на доступ к сети Интернет. То есть, будет ограничиваться скорость работы с сетью, а также будет учитываться трафик. При этом в дальнейшем не будет возможности отделить действительно внешний трафик и локальный, засчитанный как внешний.

2. В силу реализации, учётные записи работают только на тех маршрутизаторах, на которых они созданы. При использовании же внешней RADIUS-авторизации [15] не будет работать встроенный подсчёт израсходованного трафика.

На данный момент, эта проблема остаётся нерешённой.

2.1.3 Используемое программное обеспечение

До работ по преобразованию сети, использовались следующие службы:

Для всех пользователей локальной сети:

1. Локальная POP3/SMTP электронная почта. Практически не использовалась

2. Корпоративный антивирус Dr. Web Enterprice Suite [10].

3. Прокси-сервер UserGate.

Дополнительно, для сотрудников технического центра:

1. FTP и SMB файлообменник на базе сервера

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

2.1.4 Антивирусная защита сети

Для защиты локальной сети от вирусных угроз с ноября 2008 года использовался корпоративный пакет антивирусной защиты Dr. Web Enterprise Suite [10]. До этого периода использовался антивирус NOD32.

Продукт Dr. Web Enterprise Suite предназначен для централизованного управления защитой рабочих станций корпоративной сети под управлением Microsoft Windows 9x-Vista. При необходимости обеспечения централизованного управления файловыми серверами Windows и/или почтовыми серверами Unix приобретаются соответствующие лицензии.

Комплект включает в себя:

- антивирусный сервер;

- консоль администратора;

- сканер с графическим интерфейсом для Windows;

- антивирусный монитор SpIDer Guard®;

- антивирусный почтовый монитор SpIDer Mail® (со встроенным модулем антиспам-фильтра в случае лицензии антивирус+антиспам).

Однако, как показала практика полугодового использования данного антивируса, он имеет критические уязвимости:

1. Не проверяет и не удаляет вирусы со съёмных носителей ("флэшек").

2. Не препятствует автоматическому запуску большинства вирусов со съёмных носителей.

3. Во многих случаях не умеет удалять вирусы, уже находящиеся в памяти компьютера, без непосредственного вмешательства сотрудника технического центра.

4. Достаточно неудобная консоль администрирования, с которой затруднительно оперативно отслеживать состояние антивирусной сети предприятия.

5. За полугодовой период использования было обнаружено более 10 вирусов, не определяемых Dr. Web. Их лечение стало возможным только после передачи образцов в службу технической поддержки Dr. Web.

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

2.1.5 Проблемы данной структуры сети

Данная структура сети имеет следующие очевидные проблемы:

1. Сложность добавления новых узлов в структуру сети.

2. Создание локальной подсети вида 10.190. х.0/24 для каждого нового корпуса/маршрутизатора.

3. Одинаковые адреса локальных подсетей корпусов делают невозможным работу непосредственно с клиентскими компьютерами - два компьютера в разных корпусах вполне могут иметь один и тот же IP адрес. Это же влечёт с собой невозможность напрямую обмениваться информацией с помощью, скажем, стандартного протокола SMB. Более того, ограниченная пропускная способность линии связи между корпусами вынудили запретить непосредственный обмен данными между рядовыми компьютерами между корпусами.

4. Добавление новых узлов тут же влечёт за собой увеличение нагрузки на узкое место системы - VDSL [7] связь между двумя корпусами. Это связано и с тем, что все HTTP-запросы проходят через этот канал связи до прокси-сервера, и с тем, что все локальные сервисы (сайт, почта) расположены в корпусе технического факультета. При этом максимальная пропускная способность каждой из подчинённых связей будет вычисляться по принципу 20 Мбит/N, где N - количество подчинённых маршрутизаторов. Реальная же ширина канала будет меньше ещё на 15-20% из-за изначальной структуры Ethernet сети.

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

6. Необходимость жёстко ограничивать локальный трафик между корпусами, т.к. при падении этой линии фактически перестанет работать как локальная сеть, так и доступ к сети Интернет.

7. Необходимость всем пакетам проходить через 2 NAT'a [17] делает невозможным применение утилит удалённого администрирования, и сильно осложняет работу многих сетевых программ.

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

Провайдер AlakhanSAT [11] в данный момент практически завершил работы по подключению наших корпусов по технологии Wi-Fi к единой сети, с выделением блока "белых" IP адресов 217.151.226.160/28.

2.2 Итоговая структура локальной сети

На данный момент работы по подключению всех корпусов университета в единую локальную сеть посредством Wi-Fi линков практически завершены. На данный момент ведётся тестирование устойчивости и работоспособности каналов связи между корпусами.

Для расширения и модернизации локальной сети университета было принято решение о закупке оборудования RouterBoard с предустановленной на них MikroTik Router OS [5].

Эта ОС и ранее использовалась в университете для построения его инфраструктуры, однако при этом использовались обычные персональные компьютеры, с установленными на них x86 версией данной операционной системы. Подобное решение, очевидно, имеет ряд недостатков, от которых избавлены устройства RouterBoard.

Сравнительная таблица производительности [12] различных моделей RouterBoard представлена ниже, на рис. 2:

Рисунок 2. Сравнительная диаграмма производительности различных моделей RouterBoard.

В нашем случае, было принято решение о закупке RouterBoard 433AH.

Данная модель построена на базе RISC процессора Atheros с тактовой частотой 680 Mhz, имеет 3 Fast Ethernet LAN порта, и способна обрабатывать суммарный поток данных по всем интерфейсам до 197 Мбит/с, что более чем достаточно для наших задач.

Это фактически старшая модель в линейке устройств, предназначенных для работы со сетью стандарта Fast Ethernet, т.к. более мощные устройства ориентированы на гигабитную сеть и имеют заметно большую цену.

Таким образом, для модернизации локальной сети университета было закуплено 7 маршрутизаторов RB 433AH, из расчёта по одному маршрутизатору на каждый подключаемый к локальной сети корпус.

2.2.1 Модель сети

Сейчас структуру локальной сети университета можно представить следующим образом:

Рисунок 3. Структура локальной сети университета

Как заметно невооружённым взглядом, схема сети заметно усложнилась, по сравнению первоначальной схемой, показанной на рис. 1.

Большая часть элементов схемы осталась неизменной, разве что приобрела содержательные имена. Тем не менее, следует точности ради вкратце привести их данные здесь:

1. Alakhan.

Это маршрутизатор ООО "AlakhanSAT" [11], предоставляющего нам на данный момент доступ к сети Интернет и обеспечивающего связь между главным корпусом по ул. Герцена, 27 и корпусами педагогического факультета по ул. Баймагамбетова, 160, а также КСТК и общежитием №2.

Университету по договору был выделен блок внешних IP адресов 217.151.226.160/28, т.е. адреса 217.151.226.162 - 217.151.226.174. Адрес 217.151.226.161 зарезервирован для шлюза, а адреса 217.151.226.160 и 217.151.226.175 для адреса сети и адреса широковещательной рассылки.

2. main. kosstu. kz.

Это главный маршрутизатор локальной сети университета, организованный на основе MikroTik Router OS [5]. В его задачи, как и ранее, входит организация раздачи интернет-трафика и локального трафика между подчинёнными маршрутизаторами университета, подсчёт расхода трафика в первом приближении средствами mangle, ограничение максимальной загруженности всех каналов связи с применением протокола шейпинга трафика HTB. Также он отвечает за локальную сеть главного корпуса университета, имеющую адреса 192.168.30.0/24.

В связи с техническими ограничениями, выставленными нам провайдером, нет возможности использовать для связи с корпусами технологию VLAN.

Как отмечалось выше, каждый корпус в данный момент имеет свой "белый" внешний IP, что не очень удобно для организации локальной сети. В связи с этим используются стандартные PPPoE туннели с достаточно стойким 128-битным шифрованием, посредством которых весь трафик, идёт не на шлюз по умолчанию 217.151.226.161, а на наш главный маршрутизатор.

При этом, каждый корпус получает постоянный адрес из локального пула адресов 10.190.2.0 с маской 255.255.255.0.

Подобное решение имеет массу преимуществ:

1. Легко учитывать локальный и интернет трафик между узлами.

2. Легко разрешать локальный трафик на каждом из подчинённых маршрутизаторов.

3. Хорошая масштабируемость.

Нужно заметить, что недостатком подобного решения является то, что корпус становится недоступным извне по своему внешнему IP адресу.

Однако существует достаточно простое решение, основанное на механизме mangle в MikroTik Router OS [5].

Алгоритм работы следующий: при получении запроса на TCP соединение с внешнего IP по интерфейсу, соответствующему внешнему, соединение помечается специальным маркером, позволяющим отслеживать все пакеты этого соединения в дальнейшей обработке. Механизм mangle не вносит никаких изменений в пакеты, данные маркеры существуют только внутри маршрутизатора и могут использоваться как условие в правилах файрволла и при создании очередей пакетов при формировании графика загрузки канала.

Далее, второе правило помечает пакеты, относящиеся к помеченным соединениям, специальным маркером типа routing-mark. И, наконец, создаём маршрут с таблице маршрутизации, который отправляет пакеты, помеченные данным маркером, на внешний интерфейс в обход PPPoE туннеля [4].

Это решает проблему доступа к маршрутизатору с его внешнего IP адреса.

3. pedfak. kosstu. kz

Это маршрутизатор локальной сети педагогического факультета.

Подсеть педагогического факультета имеет адреса 192.168.40.0/24

Он соединяется с main. kosstu. kz с помощью PPPoE туннеля, как описано выше, получая адрес 10.190.2.2.

4. tech. kosstu. kz

Это маршрутизатор локальной сети технического факультета, обслуживающий сеть корпуса с адресами 192.168.10.0/24. В связи с тем, что старый канал связи между корпусами не удовлетворял предъявляемым требованиям, были проведены работы по монтажу новой линии связи.

Она представляет собой протянутый между корпусами кабель UTP cat.6, обеспечивающий достаточную для работы скорость обмена данными 100 Мбит/c.

5. muzfak. kosstu. kz.

Это маршрутизатор локальной сети ДК "Студент", с адресами 192.168.20.0/24.

6. college. kosstu. kz

Это маршрутизатор локальной сети Костанайского социально-технического колледжа. Локальная сеть КСТК разделена на две независимые подсети: сеть собственно колледжа 192.168.50.0/24 и сеть центра тестирования 192.168.32.0/24. Обмен данными между этими двумя подсетями запрещён.

7. hostel1. kosstu. kz

Это маршрутизатор локальной сети общежития №1 (ул. Пушкина, 140), с адресами 192.168.60.0/24

8. hostel2. kosstu. kz

Это маршрутизатор локальной сети общежития №2 (ул. Герцена, 56), с адресами 192.168.90.0/24

9. hostel3. kosstu. kz

Это маршрутизатор локальной сети общежития №3 (ул. Текстильщиков, 61), с адресами 192.168.70.0/24

10. president. kosstu. kz

Это маршрутизатор, обеспечивающий работу локальной сети в коттедже Президента, с адресами 192.168.80.0/24.

11. Platonus

Это виртуальная машина, на которой работает сервер web-приложения Tomcat [18], обеспечивающий работу отдела дистанционного образования [9]. Она имеет адрес из пула локальных адресов 10.190.1.8

12. Saturn

Резервный на данный момент сервер, в будущем предполагается использование в качество контроллера домена, его адрес 10.190.1.2

13. Mercury

Основной сервер, с адресом 10.190.1.7 Обеспечивает работу web-сервера Apache+PHP +MySQL, сервера корпоративной электронной почты Kerio Mail Server, файлового сервера. Также на нём работает виртуальная машина, на которой запущено приложение Platonus [13].

14. Proxy

Рабочая машина системного администратора, с адресом 10.190.1.4 На ней запущен сервер утилиты мониторинга работы локальной сети The Dude [2].

Связи между элементами схемы:

Необходимое отступление: в данный момент, во всех корпусах доступ как к локальной сети, так и к сети Интернет осуществляется путём подключения нашего оборудования MikroTik к Wi-Fi точкам, смонтированным сторонней организацией по договору. Т.к. эти точки работают в режиме моста, то отображать их на схеме не представляется возможным.

1. Связь между main. kosstu. kz и Alakhan. Физически представляет собой Wi-Fi канал связи, с шириной предоставляемого канала доступа в Интернет составляла 512 Кбит/с для входящего и 256 Кб/с для исходящего трафика соответственно. Ширина канала между адресами, входящими в наш пул адресов, составляет по последним замерам около 8 Мбит/c.

2. Связи между main. kosstu. kz и всеми корпусами, кроме techfak. kosstu. kz. Это PPPoE [4] туннели между главным маршрутизатором и соответствующим маршрутизатором удалённого корпуса. Пропускная способность зависит как от загруженности основного канала связи, так и от конкретного корпуса, варьируясь от 1 Мбит/с до 15-16 Мбит/c.

3. Связь между main. kosstu. kz и подсетью 10.190.1.0/24. Это физический канал связи Fast Ethernet, на основе кабеля UTP cat.6. Ширина канала составляет 100 Мбит.

4. Связи между подсетью 10.190.1.0/24 и серверами. Скорость обмена данными организована по стандарту Gigabit Ethernet и составляет 1 Гбит/с.

5. Связи между подчинёнными маршрутизаторами и локальными сетями корпусов одинаковы, их максимальная пропускная способность составляла 100 Мбит/с.

Теперь подробно рассмотрим работу реорганизованной локальной сети университета.

По-прежнему главным маршрутизатором остаётся main. kosstu. kz, задачей которого является координирование работы всех подчинённых маршрутизаторов всех остальных корпусов.

Здесь основным изменением является то, что мы ушли от необходимости выделенного маршрутизатора для главного корпуса университета. Сейчас локальная сеть главного корпуса обслуживается тем же main. kosstu. kz. В порядке модернизации локальной сети, был протянут кабель витой пары 6-й категории между главным корпусом и корпусом технического факультета. В результате этого, теперь мы имеем полноценный канал пропускной способностью в 100 мегабит/с между корпусами. Учитывая, что все сервера по прежнему находятся в корпусе технического факультета, это более чем кстати. Более того, при необходимости, мы сможем увеличить эту пропускную способность ещё на 20%, до 120 мегабит/c, задействовав старый VDSL канал связи между корпусами.

В подсети серверов также произошли определённые изменения: она по сути преобразована в т. н. "демилитаризованную зону" (англ. DMZ), которая располагается между Интернет и локальной сетью предприятия, осуществляя фильтрацию и проверку трафика в обе стороны от себя.

Появился новый выделенный сервер Mercury, который занимается следующими задачами:

- обслуживание сайта университета и других web-сервисов;

- на нём поднята служба VMWare Server 2 [19], обеспечивающая работу виртуального сервера приложения центра дистанционного образования Platonus;

- серверная часть корпоративного антивируса Kaspersky Workspace Security [20];

- DNS сервер, обеспечивающий разрешение имён для зоны kosstu. kz;

- WINS-сервер, обеспечивающий разрешение NetBIOS-имён для всей локальной сети университета;

- файловый сервер;

- корпоративный почтовый сервер Kerio Mail Server [21];

- система мониторинга состояния сети и учёта потребляемого трафика PRTG Traffic Grapher [22];

Старый сервер server1 прекратил своё существование, т.к. все его функции сейчас переданы на mercury. На этом оборудовании в данный момент производятся работы по поднятию контроллера домена, и в перспективе будет создан регламент по переходу всех компьютеров организации в корпоративный домен.

Proxy в данный момент является рабочей машиной администратора, а также обеспечивает работу дублирующей системы мониторинга сети The Dude [2].

Второе заметное изменение: подсети всех корпусов теперь имеют разный номер подсети. Например, подсеть корпуса технического факультета имеет подсеть 192.168.10.0/24, главного корпуса: 192.168.30.0/24, и так далее.

Это как минимум позволяет однозначно идентифицировать компьютер по его адресу в пределах всей корпоративной локальной сети университета. Помимо этого, пока не используется домен с его динамическим обновлением службы DNS, становится возможным использовать службу WINS для идентификации компьютеров по их NetBIOS имени.

На данный момент к локальной сети университета подключены все корпуса университета: главный корпус, технический факультет, педагогический факультет, ДК "Студент", общежития №1, №2, №3, КСТК.

Каждый корпус обслуживается своим маршрутизатором второго уровня, и имеет свой собственный "белый" IP адрес из диапазона 217.151.226.160/240.

Каждый маршрутизатор второго уровня соединяется с главным маршрутизатором main. kosstu. kz по протоколу PPPoE с 128-ми битным шифрованием, получая локальный адрес из пула 10.190.2.0/24. Все запросы маршрутизатора, как к ресурсам Интернет, так и к ресурсам локальной сети осуществляются через этот PPPoE интерфейс. Таким образом реализуется эффективное разделение единого канала доступа в Интернет между корпусами университета.

На данный момент, ширина общего канала доступа в Интернет для всех корпусов университета составляет 512 Кбит/с на входящий трафик, и 256 Кбит/с на исходящий. Пропускная ширина линий связи между корпусами, по проекту, должна была составлять как минимум 11 Мбит/c, но на практике с корпусами, находящимися в центре города (педагогический факультет, КСТК, общежитие №2) она не превышает 1 Мбита.

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

2.2.2 Организация доступа в Интернет

Как мы говорили ранее в разделе 2.1.2, доступ к сети Интернет для студентов и сотрудников университета реализован на основе функционала системы Hotspot.

Перечислим ещё раз достоинства и недостатки подобного решения:

Положительные моменты такой организации работы:

1. Не требуется приобретение и установка дополнительного ПО как на стороне сервера, так и на стороне клиента.

2. Не требуется никакой настройки оборудования клиента. Необходимо лишь иметь учётную запись, и быть подключённым к локальной сети.

3. Простота использования - достаточно всего лишь ввести свои учётные данные в форму, которая сама покажется при любой попытке получить доступ к сети Интернет.

4. Наличие встроенной системы биллинга на маршрутизаторе. Она позволяет ограничивать скорость доступа к сети Интернет у каждого из клиентов, учитывать как входящий, так и исходящий трафик, и ограничивать его потребление каждым из пользователей.

5. Наличие системы Walled Garden, позволяющей разрешать доступ к ресурсам сети без авторизации в системе.

6. Возможность сменить типовое оформление на своё собственное, в формате HTML.

Проблемы при использовании HotSpot:

1. HotSpot ограничивает доступ не к Интернету, а к любой подсети, отличающейся от той, в которой находится пользователь. С помощью модуля Walled Garden можно разрешить использовать сервер локальной почты без регистрации в HotSpot. Но при этом, если пользователь войдёт в интернет, то на доступ ко всем локальным ресурсам (внутренний сайт, локальная электронная почта) будут накладываться те же ограничения, что и на доступ к сети Интернет. То есть, будет ограничиваться скорость работы с сетью, а также будет учитываться трафик. При этом в дальнейшем не будет возможности отделить действительно внешний трафик и локальный, засчитанный как внешний.

2. В силу реализации, учётные записи работают только на тех маршрутизаторах, на которых они созданы. При использовании же внешней RADIUS-авторизации не будет работать встроенный подсчёт израсходованного трафика.

В процессе работы над данной проблемой обрисовались два возможных пути решения, каждый их которых имеет как достоинства, так и недостатки.

1. Использование PPPoE соединения с подчинённым маршрутизатором.

В MikroTik Router OS существует возможность создавать PPPoE сервер на любом доступном интерфейсе, ограничивая пропускную способность данного подключения, а в состав наиболее используемой в университете версии Windows XP входит клиент PPPoE.

Таким образом, на каждом клиентском компьютере необходимо создать PPPoE соединение, с заданным именем и паролем. После соединения с маршрутизатором, на клиентском компьютере появится второй сетевой интерфейс. Предположим, что при этом клиент получит адрес из пула 10.190.2.0/24, а адрес сервера при этом 10.190.2.1.

Тогда в таблице маршрутизации у клиента добавится новый маршрут по умолчанию, имеющий вид:

ip 0.0.0.0 mask 0.0.0.0 gateway 10.190.2.1 metric 1

Однако, в этом случае мы получим ту же самую проблему: через созданный туннель будет идти вообще весь трафик, т.к. вновь созданный маршрут имеет приоритет перед обычным сетевым подключением. Нам же нужно, чтобы локальный трафик перенаправлялся на шлюз локальной сети, а весь Интернет трафик шёл через новое соединение.

Однако мы знаем, какие адреса являются локальными согласно стандарту [14] и в нашем случае есть ещё пул адресов, принадлежащий нашему провайдеру:

1. 10.0.0.0 - 10.255.255.255

2. 172.16.0.0 - 172.31.255.255

3. 192.168.0.0 - 192.168.255.255

4. 217.151.226.0 - 217.151.226.255

Для этого достаточно создать четыре постоянных маршрута на клиентском компьютере, выполнив в командной строке следующие команды с правами администратора:

route add 10.0.0.0 mask 255.0.0.0 192.168.10.1 metric 1 - p

route add 172.16.0.0 mask 255.240.0.0 192.168.10.1 metric 1 - p

route add 192.168.0.0 mask 255.255.0.0 192.168.10.1 metric 1 - p

route add 217.151.226.0 mask 255.255.255.0 192.168.10.1 metric 1 - p

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

Также MikroTik позволяет авторизовать клиентов как с помощью внутренней базы учётных записей, так и с помощью внешнего сервера авторизации, работающего по протоколу RADIUS [15].

Подобным образом, в порядке эксперимента, на данный момент реализован бесплатный доступ студентов и сотрудников в сеть Интернет на компьютерах библиотеки главного корпуса и в библиотеке педагогического факультета. Доступ в Интернет предоставляется с 15: 00 до 19: 00.

На рисунке 4 показаны активные PPP соединения на главном маршрутизаторе:

Рисунок 4. Список активных РРР соединений на main. kosstu. kz

В нашем случае, соединения с именами student2, student3, student5 это как раз активные сессии с компьютеров, находящихся в библиотеке главного корпуса. При этом данным компьютерам выдаются адреса из пула 10.190.3.0/24, в отличие от PPPoЕ туннелей с другими корпусами, имеющими адреса в диапазоне 10.190.2.2 - 10.190.2.254.

Плюсы подобной реализации:

1. Удобство работы в сети Интернет, отсутствие "смешивания" локального и внешнего трафика, и ограничений, связанных с этим.

2. Возможность внешнего централизованного хранения базы данных пользователей.

3. Возможность более гибко управлять шириной канала различных пользователей (в зависимости от времени суток, запрашиваемого ресурса и т.п.)

Недостатки:

1. Отсутствие встроенного биллинга требует применение сторонней утилиты по учёту израсходованного трафика.

2. Требуется настройка соединения на каждом клиентском компьютере.

3. Необходимость обучения пользователей.

2. Использования PPTP VPN соединения с главным маршрутизатором.

При этом варианте всё вышесказанное в первом варианте остаётся в силе, различие в том, что соединение устанавливается по протоколу PPTP [12] с главным маршрутизатором. Это добавляет к вышеприведённым достоинствам и недостаткам следующее:

1. Достоинство - при использовании RADIUS-авторизации у пользователей будет возможность использовать свою учётную запись из любого корпуса университета.

2. Достоинство - централизованное управление доступом в интернет производится на одном маршрутизаторе вместо многих, и упрощение мониторинга загруженности интернет-канала.

3. Минус - протокол PPTP является достаточно требовательным к вычислительным ресурсам, и в этом случае на главный маршрутизатор будет ложиться дополнительная вычислительная нагрузка.

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

Тем не менее, плюсы подобного решения явно перевешивают минусы. Так, централизованная авторизация по протоколу RADIUS средствами, например, стандартного Windows IAS, позволит в будущем как привязать к этой же учётной записи электронную почту, так и в будущем безболезненно произвести ввод рабочей станции в домен.

На рис.4 можно видеть активную PPTP сессию "kamrad”, которая используется в техническом центре в порядке тестирования.

2.2.3 Используемое программное обеспечение

1. The Dude

Рисунок 5. Пример рабочей карты сети в Dude.

Эта бесплатная утилита поставляется разработчиками используемых нами маршрутизаторов MikroTik, и изначально предназначена для мониторинга состояния оборудования и сети. Однако, возможности предоставляемые данным средством, позволяют применять его и для мониторинга сети смешанного состава, включающей и Windows/Unix сервера. Для этого необходима лишь поддержка протокола диагностики состояния сети SNMP, которая обеспечивается практически всем современным аппаратным оборудованием. В случае серверов, необходимая поддержка протокола SNMP включается программно.

Зелёными прямоугольниками на карте отмечены работающие устройства, красными - устройства, на которых неисправна одна или несколько служб. Жёлтыми "облачками" показываются IP подсети. Связи между узлами сети отражают тип линии связи и её пропускную способность.

Данная утилита позволяет в любой момент времени посмотреть статистику загруженности каналов связи, подключиться к маршрутизатору по SSH, Telnet, или с использованием утилиты конфигурирования WinBox, проверить доступность того или иного узла сети. Для линий связи также доступна проверка на пропускную ширину канала (только для маршрутизаторов MikroTik), и просмотр соединений в реальном времени с подробной статистикой по скоростям передачи/приёма, используемым портам, адресам приёма/передачи, типу трафика и т.п.

В результате, администратор имеет возможность отслеживать загруженности сети в реальном режиме времени, и всегда имеет под рукой "живую" схему сети. Пример подобной схемы показан выше на рис.5.

Ключевым понятием в данной утилите являются понятия службы и зонда.

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

Зонд - это предопределённый тип подобной задачи. Зондировать можно очень много параметров работы устройства, вплоть до загруженности CPU и размера свободного пространства на жёстком диске.

Самым распространенным, простым и полезным зондом при этом является обычный ICMP пинг, позволяющий определить работоспособность устройства. Основные параметры зонда это:

1. Интервал зондирования. Как часто производится зондирование (в нашем случае это пинг узла от сервера Dude).

2. Таймаут зондирования. Как скоро при неудаче зондирования службе будет передано состояние "Нестабильно".

3. Количество зондов в состоянии "Не работает". Сколько неудачных зондирований будет выполнено, прежде чем службе будет выставлено состояние "Не работает".

На рис. 6 показано окно свойств службы ping для одного из устройств:

Рисунок 6. Свойства службы ping

Как видно из рис. 6, в правой колонке отображается текущее состояние службы (не работает), описание проблемы (таймаут), текущее количество зондирований в состоянии "не работает". Ещё больший интерес представляет суммарная статистика этой службы.

Так, по рис. 6 видно, что время последней неработоспособности службы составило 2 дня 17: 45: 13, при этом суммарное время работы службы 33 дня 07: 27: 01. Из них в состоянии "Не работает" служба пребывала 12 дней 22: 12: 03.

На рис. 7 показано окно свойств выбранного устройства, открытое на вкладке "Службы". Как видно из рисунка, служба ping выдаёт таймаут. Это означает, что заданное количество зондирований прошло с ошибкой.

Рисунок 7. Окно свойств устройства, вкладка "Службы".

При этом ведётся история изменений в состоянии всех устройств. В свойства конкретного узла сети показываются только последние 16 изменений его состояния.

Пример истории показан ниже на рис. 8:

Рисунок 8. Выходы из строя устройства

Каждая из записей отображает время выхода из строя устройства, продолжительность сбоя (в том числе, текущую продолжительность, в случае если на данный момент устройство недоступно), а также предоставляет возможность делать заметки к каждой из записей.

С целью максимально быстрого уведомления администратора о сбое в работе узла сети существует возможность гибкой настройки уведомлений о любом изменении в статусе узла сети.

Заданы следующие типы уведомлений:

1. Всплывающая подсказка у клиента Dude

2. Команда, выполняемая локально у клиента или на сервере

3. Запись в системный журнал событий

4. Проиграть заданный wav файл

5. Отправить уведомление на заданный e-mail

6. Уведомить посредством встроенного системного динамика

Пример настройки уведомления показан на рис. 9.

Рисунок 9. Настройки уведомлений.

Используя услугу от Beeline существует возможность настроить отсылку уведомлений на мобильный телефон с помощью SMS.

Ещё одной часто используемой встроенной в Dude утилитой является проверка ширины канала между двумя узлами сети. Эта возможность реализована только для узлов, являющимися маршрутизаторами MikroTik.

Окно с тестом пропускной способности линии связи показано ниже на рис.10:

Рисунок 10. Проверка пропускной способности канала связи

Тест позволяет варьировать размер пакета, ограничивать максимальную скорость обмена данными, выбирать протокол передачи данных (TCP или UDP). Эти возможности чаще используются при тестировании проблемных каналов связи, выдающих нестабильные результаты скорости передачи данных.

В целом, утилита The Dude представляет очень удобную среду для работы системного администратора локальной сети предприятия, обеспечивая:

- наглядную визуализацию структуры локальной сети, состояния каждого её узла, загруженности каналов связи;

- отличный механизм отчётов о выходах из строя, с ведением суммарной статистики и возможностью добавления заметок.

- быстрый доступ к основным часто используемым утилитам: ping, tracert, winbox, тест ширины канала связи.

- построение графиков для данных зондов и графиков загруженности линий связи.

2. PRTG Traffic Grapher

Как дополнительное средство мониторинга сети с помощью протокола SNMP, используется PRTG Traffic Grapher.

Пакет PRTG Traffic Grapher представляет собой удобное в использовании Windows-приложение для мониторинга пропускной способности сети и других параметров, таких, как объем свободной памяти и использование ресурсов процессора на серверах сети.