Диплом Левадний

ТИТУЛЬНЫЙ ЛИСТ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФИЛИАЛ ГОСУДАРСТВЕННОГО ОБРАЗОВАТЕЛЬНОГО
УЧРЕЖДЕНИЯ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ»
Кафедра «Автоматизированные системы управления»

Специальность 230102 «Автоматизированные системы обработки
информации и управления»
ДОПУЩЕН
К ЗАЩИТЕ В ГАК
Заведующий кафедрой АСУ
Кандидат технических наук, доцент
_____________________ Бережной В.В.

(подпись)
«_____» июня 2011 года
ДИПЛОМНЫЙ ПРОЕКТ
На тему: Организация абонентского доступа к сети Интернет на
предприятии ООО «Ставропольские коммуникационные сети»
__________________________________________________________________
Выполнил:
Студент группы АСОУ-061 ______________ Левадний А. Д.
(подпись)
Научный руководитель
к.т.н., доцент ______________ Бережной В. В.
(подпись)
Рецензент
уч. степень, уч. звание ______________ Фамилия, инициалы
(подпись)
г. Ставрополь 2011
ЗАДАНИЕ ПО ДИПЛОМНОМУ ПРОЕКТУ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФИЛИАЛ ГОСУДАРСТВЕННОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ» в г. Ставрополе
ФАКУЛЬТЕТ Управления
КАФЕДРА «Автоматизированные системы управления»
СПЕЦИАЛЬНОСТЬ 230102 «Автоматизированные системы обработки информации
и управления»
ГРУППА АСОУ-061
ЗАДАНИЕ
ПО ДИПЛОМНОМУ ПРОЕКТУ
СТУДЕНТ __Левадний Александр Дмитриевич _____________

1. Тема проекта Организация абонентского доступа к сети Интернет на предприятии
ООО «Ставропольские коммуникационные сети» __________________________________
2. Срок сдачи студентом законченного проекта:
___6 июня 2011 года ___________________________________________________________
3. Исходные данные по проекту
__PPTP, LT2P, PPPoE, VLAN, BGP-4, Mikrotik Router OS, RADIUS, NAT______________
_____________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________
4. Содержание разделов дипломного проекта (наименование разделов)
___Введение__________________________________________________________________
___Диагностический анализ АСОИУ предприятия__________________________________
___Проектирование структуры части ядра сети на предприятии______________________
___Внедрение спроектированной структуры_______________________________________
___Технико-экономическое обоснование__________________________________________
___Обеспечение безопасности жизнедеятельности персонала_________________________
___Заключение________________________________________________________________
5. Перечень графического материала
___Рисунок 1.6 – Существующий метод доступа___________________________________
___Рисунок 1.7 – Схема взаимодействия АСР с сервисами __________________________
___Рисунок 1.8 – Предлагаемая схема взаимодействия______________________________
___Рисунок 2.1 – Физическая структура сети ______________________________________
___Рисунок 2.2 – Логическая схема взаимодействия________________________________
___Рисунок 2.3 – Схема взаимодействия сервисов__________________________________
Дата выдачи задания _________________________________
Руководитель дипломного проекта _______________(____Бережной В. В. ___)

(подпись, фамилия и инициалы)
Студент _______________(___ Левадний А. Д. _)
(подпись, фамилия и инициалы)
СОДЕРЖАНИЕ
ВВЕДЕНИЕ......................................................................................................................6
1ДИАГНОСТИЧЕСКИЙ АНАЛИЗ АСОИУ ПРЕДПРИЯТИЯ .................................9
1.1Анализ организационно-штатной структуры предприятия ООО «СКС»...9

1.1.1Организационная структура управления компании ...........................9
1.1.2Должностные обязанности сотрудников..............................................9
1.2Анализ задач, решаемых ООО «СКС»..........................................................12
1.2.1Анализ решаемых задач предприятия................................................12
1.2.2Анализ текущего состояния информационных технологий в
компании.......................................................................................................13
1.3Методы организации абонентского доступа................................................14
1.3.1PPTP.......................................................................................................14
1.3.2L2TP.......................................................................................................16
1.3.3PPPoE.....................................................................................................19
1.3.4PriviteVLAN..........................................................................................23
1.4Постановка задачи на модернизацию используемого в компании метода
................................................................................................................................30
1.4.1Существующий метод..........................................................................30
1.4.2Рассмотрение взаимодействия биллинга с сервисами......................32
1.4.3Постановка задачи................................................................................33
1.5Выводы по разделу.........................................................................................36
2ПРОЕКТИРОВАНИЕ СТРУКТУРЫ ЧАСТИ ЯДРА СЕТИ НА ПРЕДПРИЯТИИ

.........................................................................................................................................38
2.1Разработка схемы разделения задач на два выделенных сервера..............38

2.1.1Графическое представление модели...................................................38
2.1.2Детальное рассмотрение протокола RADIUS-сервера.....................39
Подпис
МГУПИ 230102.12ПЗ
Изм. Лист № докум. Дата Лит.
ь Организация абонентского
Разраб. Левадний Лист Листов
Провер. Бережной доступа к сети Интернет на
Филиал МГУПИ
предприятии ООО «СКС». г.Ставрополь
Н. Контр. Пояснительная записка. АСОИУ-061
Утверд.
АСОИУ-062
2.1.3Детальное рассмотрение механизма авторизации пользователя.....43
2.2Разработка метода устранения NAT и перехода на внешнюю адресацию
Интернета..............................................................................................................47
2.2.1Детальное рассмотрение системы NAT.............................................47
2.2.2Детальное рассмотрение протокола маршрутизации BGP...............54
2.2.3Разработка плана по внедрению..........................................................64
2.3Выбор программного и технического обеспечения....................................65
2.3.1Выбор программного обеспечения для маршрутизатора.................65
2.3.2Выбор программного обеспечения для сервера АСР.......................66
2.3.3Выбор аппаратного обеспечения для маршрутизатора....................67
3ВНЕДРЕНИЕ СПРОЕКТИРОВАННОЙ СТРУКТУРЫ..........................................71
3.1Подготовительные работы.............................................................................71
3.1.1Закупка программного обеспечения...................................................71
3.1.2Закупка аппаратного обеспечения......................................................72
3.1.3регистрация автономной системы и блока адресов в RIPE..............73
3.2Разработка конфигурационных файлов маршрутизатора...........................74
3.2.1Разработка конфигурации для взаимодействия по протоколу
RADIUS-сервера...........................................................................................74
3.2.2Разработка конфигурации для протокола BGP.................................75
3.3Разработка конфигурационных файлов сервера с АСР..............................77
3.4Настройка клиентов........................................................................................79
4ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ...............................................85
4.1Постановка задачи..........................................................................................85
4.2Оценка стоимости внедрения проекта..........................................................86
Подпис
Утверд.
АСОИУ-062
4.3Окупаемость проекта......................................................................................90
4.4Вывод по разделу............................................................................................90
5ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ЖИЗНЕДЕЯТЕЛЬНОСТИ ПЕРСОНАЛА..92
ЗАКЛЮЧЕНИЕ..............................................................................................................97
СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ..................................................99
Подпис
Утверд.
АСОИУ-062
2.2 Разработка метода устранения NAT и перехода на внешнюю адресацию
Интернета.............................................................Error: Reference source not found
2.2.1 Детальное рассмотрение системы NAT......Error: Reference source not
found
2.2.2 Детальное рассмотрение протокола маршрутизации BGP..........Error:
Reference source not found
2.2.3 Разработка плана по внедрению........Error: Reference source not found
2.3 Выбор программного и технического обеспечения...Error: Reference source
not found
2.3.1 Выбор программного обеспечения для маршрутизатора.............Error:
2.3.2 Выбор программного обеспечения для сервера АСР..Error: Reference
source not found
2.3.3 Выбор аппаратного обеспечения для маршрутизатора................Error:
2.4 Выводы по разделу........................................Error: Reference source not found
3 ВНЕДРЕНИЕ СПРОЕКТИРОВАННОЙ СТРУКТУРЫ.........ERROR: REFERENCE

SOURCE NOT FOUND
3.1 Подготовительные работы............................Error: Reference source not found

3.1.1 Закупка программного обеспечения. Error: Reference source not found
3.1.2 Закупка аппаратного обеспечения.....Error: Reference source not found
3.1.3 регистрация автономной системы и блока адресов в RIPE..........Error:
3.2 Разработка конфигурационных файлов маршрутизатора.....Error: Reference
source not found
3.2.1 Разработка конфигурации для взаимодействия по протоколу
RADIUS-сервера...........................................Error: Reference source not found
3.2.2 Разработка конфигурации для протокола BGP.Error: Reference source
not found
Лист
Подпис
МГУПИ 230102.12ПЗ 99
Изм. Лист № докум. Дата
ь
3.3 Разработка конфигурационных файлов сервера с АСР.........Error: Reference
source not found
3.4 Настройка клиентов......................................Error: Reference source not found
3.5 Выводы по разделу........................................Error: Reference source not found
4 ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ..............ERROR: REFERENCE

SOURCE NOT FOUND
4.1 Постановка задачи.........................................Error: Reference source not found

4.2 Оценка стоимости внедрения проекта.........Error: Reference source not found
4.3 Окупаемость проекта....................................Error: Reference source not found
4.4 Вывод по разделу...........................................Error: Reference source not found
5 ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ЖИЗНЕДЕЯТЕЛЬНОСТИ ПЕРСОНАЛА

................................................................ERROR: REFERENCE SOURCE NOT FOUND
ЗАКЛЮЧЕНИЕ.....................................ERROR: REFERENCE SOURCE NOT FOUND
СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ. ERROR: REFERENCE SOURCE

NOT FOUND
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
ВВЕДЕНИЕ
Рынок телекоммуникационных услуг, предоставляемых на базе технологии
широкополосного доступа, на текущий момент находится в стадии активного
роста. Проникновение в России выросло на 2,3 п.п. за квартал до 29,6%. Согласно
данным ACM-Consulting в IV квартале 2010 г. количество пользователей
проводного широкополосного доступа в России выросло на 9% относительно
предыдущего квартала до 15,3 млн. В результате проникновение проводного ШПД,
исходя из количества домохозяйств, увеличилось, по нашим оценкам, на 2,3 п.п. за
квартал и на 7,8 п.п. относительно уровня годичной давности - до 29,6%. Рост в
основном произошел за счет регионов (+12% за квартал до 11,0 млн.), тогда как на
более насыщенных рынках Москвы и Санкт-Петербурга квартальный рост составил
лишь 1,4% - до 3,1 млн. и 1,2 млн. соответственно.
Бывшие дочерние компании «Связьинвеста», являющиеся традиционными
региональными операторами, сохраняют лидерство в своих регионах: по состоянию
на конец IV квартала 2010 г. на их долю в общей сложности приходилось 42%
рынка (6,5 млн. пользователей). Доля МТС составила 11% российского рынка
проводного ШПД (1,7 млн. абонентов), увеличившись на 24% за квартал благодаря
покупкам региональных активов. Доля VimpelCom Ltd составила 9% рынка (1,4
млн. абонентов). Из независимых провайдеров наибольшую долю рынка занимает
ER-Telecom - 9%, или 1,4 млн. абонентов.
Хорошая статистика по числу пользователей ШПД за IV квартал 2010 г.
подтверждает позитивную оценку перспектив развития российского рынка ШПД.
Ожидается, что к 2015 г. проникновение проводного ШПД достигнет 69%
домохозяйств, то есть уровня, на который уже вышли Москва и Санкт-Петербург.
Данный рост положительно отразится на всех ключевых участниках российского
рынка связи, включая «Ростелеком», МТС и VimpelCom Ltd. При этом мы более
высоко оцениваются перспективы «большой тройки», чем «Ростелекома», позиции
которого на российском рынке мобильной связи достаточно ограниченны. Акции
МТС торгуются с 66-процентным потенциалом роста до прогнозной цены, равной
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
34 долл./АДР, а по прогнозу EV/EBITDA оценены на уровне 4.2. МТС является
фаворитом в секторе.
Для любой компании необходим рост не только за счет роста рынка, но и за
счет увеличения доли участия на рынке. Важной составляющей, необходимой для
роста, является качество предоставляемых услуг. Целью дипломного проекта
является увеличение качества услуг, предоставляемых предприятием ООО «СКС».
Известно, что текущая конфигурация центрального узла связи компании
работает на уровне близком к пику своих возможностей, поэтому необходимость
модернизации является актуальным вопросом. В дипломном проекте описаны шаги
к решению данного вопроса. Одним из таких шагов, и первой задачей, является
разделение функций одного физического сервера на сервер АСР и маршрутизатор
NAS. Это увеличит качество услуг для текущей емкости абонентской базы, а также
даст возможность для увеличения этой емкости, что в свою очередь даст
возможность роста компании в целом.
Одним из составляющих качества услуг связи является способ абонентского
доступа. Наиболее популярными способами доступа среди как ведущих, так и
малых операторов ШПД являются PPTP, L2TP, PPPoE и PrivateVLAN. У
протоколов PPTP и L2TP существует один важный недостаток – это необходимость
корректной конфигурации IP-адресации у абонентов, практика компании показала,
что настройки часто сбиваются по тем или иным причинам, что увеличивает
нагрузку на службу поддержки и приводит к появлению недовольства
пользователей. Способ доступа, именуемый как PrivateVLAN технически сложен
для реализации, для его внедрения необходима поддержка со стороны
оборудования «последней мили». Самым оптимальным вариантом оказался PPPoE,
он не имеет недостатков PPTP и L2TP, для его внедрения не нужно
дополнительных затрат на дорогостоящее оборудование как в случае с
PrivateVLAN. Второй задачей дипломного проекта является внедрение PPPoE.
И последней, третей задачей дипломного проекта является устранение
системы трансляции адресов NAT с заменой на внешние адреса и полноценную
маршрутизацию Интернета BGP-4.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
В первом разделе дипломного проекта рассматривается организационная
структура предприятия, основные программные и аппаратные средства, а также
схемы их взаимодействия. Во втором разделе – осуществляется планирование
решений и детально изучается теоретический материал, необходимый для
повышения уровня компетенции в поставленных задачах. Третий раздел посвящен
непосредственно внедрению проекта, а именно закупке необходимых компонентов,
разработке конфигураций и настройке клиентов. В четвертом разделе
рассчитывается экономический эффект от внедрения проекта. Пятый раздел
посвящен обеспечению безопасности жизнедеятельности персонала, а именно
эргономическим требованиям к рабочему месту. И в заключении подведены итоги
проделанной работы.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
1 ДИАГНОСТИЧЕСКИЙ АНАЛИЗ АСОИУ ПРЕДПРИЯТИЯ
1.1 Анализ организационно-штатной структуры предприятия ООО

«СКС»
1.1.1 Организационная структура управления компании
Предприятие имеет небольшой штат сотрудников – 11 человек. Для большей

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

разработчик администратор поддержки
Старший монтажник Старший монтажник
Монтажник Монтажник Монтажник Монтажник
Рисунок 1.1 – Организационная схема управления
1.1.2 Должностные обязанности сотрудников
Во главе компании находится Генеральный директор и выполняет следующие

функции:
− организует всю работу предприятия;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− несет полную ответственность за его состояние и состояние трудового
коллектива;
− представляет предприятие во всех учреждениях и организациях;
− распоряжается имуществом предприятия;
− заключает договора;
− поиск поставщиков материала;
− сбыт продукции (т.е. поиск клиентов);
− издает приказы по предприятию в соответствии с трудовым
законодательством, принимает и увольняет работников;
− применяет меры поощрения и налагает взыскания на работников
предприятия;
− открывает в банках счета предприятия.
Главный бухгалтер:
− руководит работой по планированию и экономическому стимулированию на
предприятии, повышению производительности труда, выявлению и использованию
производственных резервов улучшению организации производства, труда и
заработной платы;
− разрабатывает нормативы для образования фондов экономического
стимулирования;
− проводит всесторонний анализ результатов деятельности предприятия;
− разрабатывает мероприятия по снижению себестоимости и повышению
рентабельности предприятия, улучшению использования производственных фондов,
выявлению и использованию резервов на предприятии;
− осуществляет учет средств предприятия и хозяйственных операций с
материальными и денежными ресурсами ;
− устанавливает результаты финансово-хозяйственной деятельности
− производит финансовые расчеты с заказчиками и поставщиками, связанные с
реализацией готовой продукции, приобретением необходимого сырья, в его задачи
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
также получение кредитов в банке, своевременный возврат ссуд, взаимоотношение с
государственным бюджетом.
Основными обязанностями системного администратора являются:
− обновление и настройка биллинговой системы;
− настройка и сопровождение коммутаторов и маршрутизаторов сети
оператора;
− обслуживание ядра сети;
− подготовка и сохранение резервных копий данных, их периодическая
проверка и уничтожение;
− установка и конфигурирование необходимых обновлений для операционной
системы и используемых программ;
− установка и конфигурирование нового аппаратного и программного
обеспечения;
− создание и поддержание в актуальном состоянии пользовательских учётных
записей;
− ответственность за информационную безопасность в компании;
− устранение неполадок в системе;
− планирование и проведение работ по расширению сетевой структуры
− решение сложных технических проблем пользователей.
Обязанности веб-разработчика:
− администрирование сайта компании;
− разработка веб-сервисов для личного кабинета абонента;
− веб-дизайн.
Обязанности оператора технической поддержки:
− прием звонков абонентов;
− прием заказов на подключение;
− помощь в решении проблем пользователей;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− назначение монтажника для выезда к пользователю на дом;
− ведение табеля подключений.
Обязанности старшего монтажника:
− подключение новых пользователей;
− монтаж кабельных систем;
− монтаж узлов и оборудования;
− управление своей группой монтажников.
Обязанности монтажника:
− подключение новых пользователей;
− монтаж кабельных систем;
− монтаж узлов и оборудования;
− выезд на дом к пользователю для устранения неполадок.
1.2 Анализ задач, решаемых ООО «СКС»
1.2.1 Анализ решаемых задач предприятия
ООО «Ставропольские коммерческие сети» в рамках торговой марки SWNet

предоставляет услуги широкополосного доступа в Интернет на основе технологии
ETTH ( Ethernet To The Home).
Компания основа в 2008 году и на данный момент предоставляет услуги
более 400-ам абонентам.
В качестве дополнительного бесплатного сервиса компания предоставляет
доступ к городской файлообменной сети основанной на технологи Direct
Connection, а также доступ к игровым серверам.
Для оплаты услуг компания сотрудничает с большинством из известных
платежных систем, такими как:
− RosExpress;
− Comepay;
− QIWI;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Rapida;
− Сбербанк РФ.
Основными задачами компании являются:
− Построение сети передачи данных;
− Подключение клиента к сети;
− Техническая поддержка и сопровождение клиента во время пользования
услугой;
− Постоянная работа над увеличением качества связи.
1.2.2 Анализ текущего состояния информационных технологий в
компании
На данный момент в компании используется множество программного

обеспечения как проприетарного, так и свободно распространяемого (Open Source).
Сервер оснащен операционной системой Debian GNU/Linux. Для обеспечения
необходимого функционала используется программное обеспечение:
− Сервер баз данных MySQL;
− Веб-сервер Apache;
− Сервер авторизации FreeRADIUS;
− Сервер доступа Poptop;
− Программный комплекс iptables/iproute/tc;
− Приложение реализующее выполнение скриптового языка Perl;
− Биллинговая система (или АСР – Автоматизированная Система Расчетов)
собственной разработки.
Компьютер главного бухгалтера оснащен:
− операционная система Windows XP Professional;
− программный комплекс OpenOffice.org;
− система 1С Бухгалтерия.
Компьютеры генерального директора и оператора службы поддержки
оснащены:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− операционная система Ubuntu 11.04;
− офисный пакет OpenOffice.org.
Компьютеры системного администратора и веб-разработчика оснащены:
− операционная система Debian GNU/Linux версии 6.0 (Squeeze);
− офисный пакет OpenOffice.org;
− Среда разработки Eclipse.
Для обеспечения сетевого взаимодействия внутри компании используется
коммутатор D-Link DES-1016, также для беспроводного доступа используется WiFi
роутер D-Link DIR-300.
Для коммутации абонентов используются коммутаторы D-Link DES-3526,
установленные непосредственно в подъездах многоквартирных домов.
1.3 Методы организации абонентского доступа
1.3.1 PPTP
PPTP (англ. Point-to-Point Tunneling Protocol) — туннельный протокол типа

точка-точка, позволяющий компьютеру устанавливать защищённое соединение с
сервером за счёт создания специального туннеля в стандартной, незащищённой
сети. PPTP помещает (инкапсулирует) кадры PPP в IP-пакеты для передачи по
глобальной IP-сети, например Интернет[1]. PPTP может также использоваться для
организации туннеля между двумя локальными сетями. РРТР использует
дополнительное TCP-соединение для обслуживания туннеля.
Спецификация
Спецификация протокола была опубликована как «информационная» RFC
2637[2] в 1999 году. Она не была ратифицирована IETF. Протокол считается менее
безопасным, чем IPSec. PPTP работает, устанавливая обычную PPP сессию с
противоположной стороной с помощью протокола Generic Routing Encapsulation.
Второе соединение на TCP-порту 1723 используется для инициации и управления
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
GRE-соединением. PPTP сложно перенаправлять за сетевой экран, так как он
требует одновременного установления двух сетевых сессий.
PPTP-трафик может быть зашифрован с помощью MPPE. Для
аутентификации клиентов могут использоваться различные механизмы, наиболее
безопасные из них — MS-CHAPv2 и EAP-TLS.
Реализация PPTP
Cisco первой реализовала PPTP и позже лицензировала эту технологию
корпорации Microsoft.
PPTP удалось добиться популярности благодаря тому, что это первый
протокол туннелирования, был поддержан корпорацией Microsoft. Все версии
Microsoft Windows, начиная с Windows 95 OSR2, включают в свой состав PPTP-
клиент, однако существует ограничение на два одновременных исходящих
соединения. А сервис удалённого доступа для Microsoft Windows включает в себя
PPTP сервер.
До недавнего времени в Linux-дистрибутивах отсутствовала полная
поддержка PPTP из-за опасения патентных претензий по поводу протокола MPPE.
Впервые полная поддержка MPPE появилась в Linux 2.6.13. Официально
поддержка PPTP была начата с версии ядра Linux 2.6.14. Тем не менее, сам факт
применения MPPE в PPTP фактически не обеспечивает безопасность протокола
PPTP.
Операционная система FreeBSD поддерживает PPTP протокол, используя в
качестве сервера PPTP порт mpd (/usr/ports/net/mpd), используя подсистему
netgraph. В качестве клиента PPTP в системе FreeBSD может выступать либо порт
pptpclient (/usr/ports/net/pptpclient), либо порт mpd, работающий в режиме клиента.
Mac OS X поставляется со встроенным PPTP клиентом. Cisco и Efficient
Networks продают реализации PPTP клиента для более старых версий Mac OS. КПК
Palm, имеющие поддержку Wi-Fi, поставляются с PPTP клиентом Mergic.
Microsoft Windows Mobile 2003 и более новые также поддерживают PPTP.
Безопасность протокола PPTP
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
PPTP был объектом множества анализов безопасности, в нём были
обнаружены различные серьёзные уязвимости. Известные относятся к
используемым протоколам аутентификации PPP, устройству протокола MPPE, и
интеграции между аутентификациями MPPE и PPP для установки сессионного
ключа. Краткий обзор данных уязвимостей:
− MSCHAP-v1 совершенно ненадежен. Существуют утилиты для легкого
извлечения хешей паролей из перехваченного обмена MSCHAP-v1;
− MSCHAP-v2 уязвим к словарной атаке на перехваченные challenge response
пакеты. Существуют программы, выполняющие данный процесс;
− При использовании MSCHAP-v1, MPPE использует одинаковый RC4
сессионный ключ для шифрования информационного потока в обоих направлениях.
Поэтому стандартным методом XOR’а потоков из разных направлений вместе,
криптоаналитик может узнать ключ;
− MPPE использует RC4 поток для шифрования. Не существует метода для
аутентификации цифробуквенного потока, и поэтому данный поток уязвим к атаке,
исполняющей подмен битов. Злоумышленник легко может изменить поток при
передаче и изменить некоторые биты, чтобы изменить исходящий поток без
опасности своего обнаружения. Данный подмен бит может быть обнаружен с
помощью протоколов, считающих контрольные суммы.
1.3.2 L2TP
L2TP (англ. Layer 2 Tunneling Protocol — протокол туннелирования второго

уровня) — в компьютерных сетях тунельный протокол, использующийся для
поддержки виртуальных частных сетей[1]. L2TP не обеспечивает шифрование и
конфиденциальность сам по себе, он опирается на инкапсулируемый протокол для
обеспечения конфиденциальности.
Несмотря на то, что L2TP действует наподобие протокола Канального уровня
модели OSI, на самом деле он является протоколом Сеансового уровня и
использует зарегистрированный UDP-порт 1701
История и будущее
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Опубликованный в 1999 году как предлагаемый стандарт RFC 2661[3], L2TP
базировался главным образом на двух более ранних туннельных протоколах для
PPP: протоколе эстафетной передачи на втором уровне (L2F) от Cisco и туннельном
протоколе точка-точка (PPTP) от Microsoft. По общему мнению, протокол L2TP
вобрал в себя лучшие черты PPTP и L2F. Новая версия этого протокола, L2TPv3,
была опубликована как предлагаемый стандарт RFC 3931 в 2005 году.
Главное достоинство L2TP в том, что этот протокол позволяет создавать
туннель не только в сетях IP, но и в таких, как ATM, X.25 и frame relay.
Описание
L2TP применяет в качестве транспорта протокол UDP и использует
одинаковый формат сообщений как для управления туннелем, так и для пересылки
данных. L2TP в реализации Microsoft использует в качестве контрольных
сообщений пакеты UDP, содержащие шифрованные пакеты PPP.
Для обеспечения безопасности L2TP-пакетов обычно используется протокол
IPsec, который предоставляет конфиденциальность, аутентификацию и
целостность. Комбинация этих двух протоколов известна как L2TP/IPsec.
Конечные узлы L2TP туннеля называются LAC (L2TP Access Concentrator) и
LNS (L2TP Network Server). LAC является инициатором туннеля, тогда LNS —
сервер, который ожидает новых туннелей. Когда туннель установлен, сетевой
трафик между узлами является двунаправленным. Затем, протоколы более высоких
уровней запускаются внутри L2TP туннеля. Для этого, L2TP сессия
устанавливается внутри туннеля для каждого протокола более высокого уровня
(например, для PPP). Как LAC, так и LNS могут инициировать сессии. Трафик для
каждой сессии изолируется с помощью L2TP, поэтому возможно настроить
несколько виртуальных сетей через один туннель.
Инкапсуляция
Инкапсуляция пакетов L2TP/IPSec выполняется в два этапа.
− Инкапсуляция L2TP. Кадр PPP (IP-датаграмма или IPX-датаграмма)
заключается в оболочку с заголовком L2TP и заголовком UDP;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Инкапсуляция IPSec. Затем полученное L2TP-сообщение заключается в
оболочку с заголовком и трейлером IPSec ESP (Encapsulating Security Payload),
трейлером проверки подлинности IPSec, обеспечивающим целостность сообщения и
проверку подлинности, и заголовком IP. В заголовке IP-адреса источника и
приемника соответствуют VPN-клиенту и VPN-серверу.
В завершение L2TP выполняет вторую PPP-инкапсуляцию для подготовки
данных к передаче.
L2TP пакет состоит из:
Таблица 1.1 – Структура L2TP пакета
Биты 0-15 Биты 16-31
Flags and Version Info Length (опционально)
Tunnel ID Session ID
Ns (опционально) Nr (опционально)
Offset Size (опционально) Offset Pad (опционально)
Payload data
Значения полей:
Flags and version – Флаги, указывающие тип пакета (управляющий или
данные) и наличие полей с длиной, номером последовательности и сдвигом.
Length (опционально) – Полная длина сообщения в байтах, есть только когда
установлен флаг длины..
Tunnel ID – Отображает идентификатор управляющего соединения.
Session ID – Отображает идентификатор сессии внутри туннеля.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Ns (опционально) – Последовательный номер для данных или управляющего
сообщения, начиная с 0 и увеличиваясь на единицу (по модулю 216) для каждого
отправленного сообщения. Существует, когда установлен соответствующий флаг.
Nr (опционально) – Последовательный номер сообщения, ожидаемого для
принятия. Nr устанавливается как Ns последнего полученного сообщения плюс
один (по модулю 216). В сообщениях с данными, Nr зарезервирован, и, если
существует, ОБЯЗАН быть проигнорирован.
Offset Size (опционально) – Определяет, где находятся данные после L2TP
заголовка. Если это поле существует, L2TP заголовок заканчивается после
последнего байта offset padding. Существует, когда установлен соответствующий
флаг.
Offset Pad (опционально) – Переменной длины, указывается offset size.
Содержимое поля неопределенно.
Payload data – Сами передаваемые данные. Переменной длины
(Максимальный размер = Максимальному размеру UDP пакета — размер заголовка
L2TP)
1.3.3 PPPoE
PPPoE (англ. Point-to-point protocol over Ethernet) — сетевой протокол

канального уровня передачи кадров PPP через Ethernet[1]. В основном используется
xDSL-сервисами. Предоставляет дополнительные возможности (аутентификация,
сжатие данных, шифрование).
MTU протокола ниже, чем на стандартном Ethernet, что иногда вызывает
проблемы с плохо настроенными межсетевыми экранами.
PPPoE — это туннелирующий протокол, который позволяет настраивать (или
инкапсулировать) IP, или другие протоколы, которые наслаиваются на PPP, через
соединения Ethernet, но с программными возможностями PPP соединений, и
поэтому используется для виртуальных «звонков» на соседнюю Ethernet-машину и
устанавливает соединение точка-точка, которое используется для транспортировки
IP-пакетов, работающее с возможностями PPP.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Это позволяет применять традиционное PPP-ориентированное ПО для
настройки соединения, которое использует не последовательный канал, а пакетно-
ориентированную сеть (как Ethernet), чтобы организовать классическое соединение
с логином, паролем для Интернет-соединений. Также, IP-адрес по другую сторону
соединения назначается только когда PPPoE соединение открыто, позволяя
динамическое переиспользование IP адресов.
PPPoE разработан UUNET, Redback Networks и RouterWare. Протокол описан
в RFC 2516[4].
Стоит отметить, что некоторые поставщики оборудования (Cisco и Juniper,
например) используют термин PPPoEoE (PPPoE over Ethernet), означающий PPPoE,
работающий напрямую через Ethernet или другие IEEE 802.3 сети, а также PPPoE,
работающий через связанные в Ethernet (Ethernet bridged over) ATM, для того чтобы
отличать от PPPoEoA (PPPoE over ATM), который работает на ATM virtual circuit
по спецификации RFC 2684 и SNAP и инкапсулирует PPPoE. PPPoEoA — это не то
же самое, что Point-to-Point Protocol over ATM (PPPoA), поскольку он не использует
SNAP.
Работа PPPoE осуществляется следующим образом. Существует Ethernet-
среда, то есть несколько соединённых сетевых карт, которые адресуются MAC-
адресами. Заголовки Ethernet-кадров содержат адрес отправителя кадра, адрес
получателя кадра и тип кадра. Одну из карт слушает PPPoE сервер. Клиент
посылает широковещательный Ethernet кадр, на который должен ответить PPPoE
сервер (адрес отправителя кадра — свой MAC-адрес, адрес получателя кадра —
FF:FF:FF:FF:FF:FF и тип кадра — PPPoE Active Discovery Initiation). PPPoE сервер
посылает клиенту ответ (адрес отправителя кадра — свой MAC-адрес, адрес
получателя кадра — МАС-адрес клиента и тип кадра — PPPoE Active Discovery
Offer). Если в сети несколько PPPoE серверов, то все они посылают ответ. Клиент
выбирает подходящий сервер и посылает ему запрос на соединение. Сервер
посылает клиенту подтверждение с уникальным идентификатором сессии, все
последующие кадры в сессии будут иметь этот идентификатор. Таким образом,
между сервером и клиентом создается виртуальный канал, который
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
идентифицируется идентификатором сессии и MAC-адресами клиента и сервера.
Затем в этом канале поднимается PPP соединение, а уже в PPP пакеты
упаковывается IP-трафик.
PPPoE Discovery (PPPoED)
PADI — PPPoE Active Discovery Initiation.
Если пользователь хочет подключиться к интернету по DSL, сначала его
машина должна обнаружить концентратор доступа (DSL access concentrator или
DSL-AC) на стороне провайдера (point of presence (POP)). Взаимодействие через
Ethernet возможно только через MAC-адреса. Если компьютер не знает MAC-
адреса DSL-AC, он посылает PADI пакет через Ethernet broadcast (MAC:
ff:ff:ff:ff:ff:ff) Этот PADI-пакет содержит МАС-адрес пославшей его машины.
Пример PADI-пакета:
Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
Version: 1
Type 1
Code Active Discovery Initiation (PADI)
Session ID: 0000
Payload Length: 24
PPPoE Tags
Tag: Service-Name
Tag: Host-Uniq
Binary Data: (16 bytes)
Src. (=source) представляет MAC-адрес машины, пославшей PADI.
Dst. (=destination) является широковещательным Ethernet-адресом. PADI-пакет
может быть получен более чем одним DSL-AC.
PADO — PPPoE Active Discovery Offer.
Как только пользовательская машина отослала PADI-пакет, DSL-AC отвечает
посылая PADO-пакет, используя MAC-адреса, пришедшие с PADI. PADO-пакет
содержит MAC-адреса DSL-AC, их имена (например LEIX11-erx для концентратора
T-Com DSL-AC в Лейпциге) и имя сервиса. Если же более одной точки DSL-AC
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
ответило PADO-пакетом, пользовательская машина выбирает DSL-AC конкретный
POP, используя пришедшие имена или имена сервисов.
Пример PADO-пакета:
Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
Version: 1
Type 1
Code Active Discovery Offer (PADO)
Session ID: 0000 Payload Length: 36
PPPoE Tags
Tag: Service-Name
Tag: AC-Name
String Data: IpzbrOOl
Tag: Host-Uniq
Binary Data: (16 bytes)
AC-Name — String Data представляет строковое AC имя, в данном случае
«Ipzbr001» (Arcor DSL-AC в Лейпциге). Src. представляет MAC-адрес DSL-AC.
MAC-адрес DSL-AC также идентифицирует производителя DSL-AC (в данном
случае, Nortel Networks).
PADR расшифровывается как PPPoE Active Discovery Request.
Как сказано выше, пользовательская машина должна выбрать POP (точку
доступа) — это делается с помощью PADR-пакета, который посылается на MAC-
адрес выбранного DSL-AC.
PADS — PPPoE Active Discovery Session-confirmation.
PADR-пакет подтверждается концентратором пересылкой PADS-пакета, в
нем же приходит Session ID. Соединение с DSL-AC для этой точки доступа теперь
полностью установлено.
PADT — PPPoE Active Discovery Termination.
Этот пакет обрывает соединение с POP. Он может быть послан либо со
стороны пользователя, либо со стороны DSL-AC.
Преимущества схемы:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− IP-заголовки в Ethernet среде игнорируются. То есть пользователь может
назначить IP-адрес своей сетевой карте, но это не приведет к «обвалу» сети
(теоретически, при работе с сетевым концентратором не должно произойти «обвала»
и при смене пользователем MAC-адреса даже на адрес сервера, а при работе с
сетевым коммутатором все зависит от конструкции коммутатора);
− Каждое соединение отделено от других (работает в своем канале);
− Настройки (IP-адрес, адрес шлюза, адреса DNS серверов) могут передаваться
сервером;
− PPP соединение легко аутентифицируется и обсчитывается (например, при
помощи RADIUS);
− PPP соединение можно шифровать. Например, при работе с сетевым
концентратором (когда на каждой сетевой карте может быть виден весь Ethernet-
трафик) прочитать чужой IP-трафик весьма затруднительно.
1.3.4 PriviteVLAN
На протяжении уже довольно долгого времени одной из наиболее

обсуждаемых тем при построении городских Ethernet-сетей является возможность
использования в них архитектуры «VLAN на пользователя» или выделение
каждого абонента в отдельный широковещательный сегмент[5].
Для того, чтобы понять для чего нужна архитектура «VLAN на
пользователя», вначале рассмотрим традиционную и наиболее простую
архитектуру с общим VLAN, когда все устройства сети находятся в одном
широковещательном домене (рисунок 1.2).
Рисунок 1.2 – Архитектура с общим VLAN
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Такая архитектура достаточно легко реализуется и создает небольшую
нагрузку на центральное оборудование сети, обеспечивающее доступ в Интернет,
за счет того, что обмен локальным трафиком происходит напрямую между
абонентами по кратчайшему пути через ближайшие коммутаторы.
Основные недостатки архитектуры с общим VLAN:
− Изоляция абонентов на втором уровне отсутствует (Layer2), что создает
опасность сетевых атак: подмена абонентом своего IP- или MAC-адреса, установка
несанкционированного DHCP-сервера, ARP Spoofing, переполнение таблицы MAC-
адресов коммутатора;
− Точками контроля локального трафика становятся коммутаторы доступа,
которых в сети достаточно много. Это приводит к проблеме управления большим
количеством устройств различных моделей, которые в силу своей невысокой
стоимости еще и ограничены по функциональности.
Для решения первой проблемы используются управляемые коммутаторы
доступа с поддержкой функций безопасности (DHCP Snooping, IP Source Guard,
Port Security, Dynamic ARP Inspection). Решение второй проблемы с точкой
контроля локального трафика требует принципиальной перестройки архитектуры
сети. И одним из получивших применение способов стал переход на архитектуру
«VLAN на пользователя».
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Таблица 2 – Сравнение архитектур «Общий VLAN» и «VLAN на
пользователя»
VLAN на
Общий VLAN
пользователя
Контроль локального трафика* Ограниченный Полный
Количество точек контроля

Большое Малое
трафика
Путь локального трафика** Оптимальный Неоптимальный
«Паразитный»
Есть Нет
широковещательный трафик***
Обеспечивается
Обеспечивается
Защита от типовых атак функциями на
архитектурой
коммутаторе доступа
Сложность реализации Ниже Выше
* Контроль трафика требуется для гибкого управления межабонентским

трафиком, например, для блокировки доступа к локальным ресурсам сети при
отрицательном балансе
** Необходимость прохождения локального трафика через точку контроля
ведет к удлинению пути трафика между абонентами, что может увеличить нагрузку
на каналы
*** При масштабировании сети широковещательный трафик создает
ощутимую нагрузку на каналы связи и абонентские устройства
Архитектура «VLAN на пользователя», как следует из названия,
подразумевает выделение для каждого абонента своего собственного VLAN.
Рассмотрим вариант реализации такой архитектуры, предлагаемый ведущими
производителями - централизованную модель. В ней точкой консолидации всего
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
абонентского трафика является устройство BRAS – Broadband Remote Access Server
(рисунок 1.3).
Рисунок 1.3 – Централизованная модель VLAN на пользователя

Однако при рассмотрении такой модели возникает вопрос, как терминировать
на одном устройстве всех абонентов в сети, если согласно стандарту IEEE 802.1q[6]
под номер VLAN выделено всего 12 бит (максимум 4096 значений). В этом случае
при большом количестве абонентов решением является использование технологии
двойного тегирования пакетов (Q-in-Q) и их терминация на BRAS.
К преимуществам централизованной модели так же можно отнести и единую
точку контроля как Интернет, так и локального трафика. Это позволяет гибко
управлять качеством обслуживания и полосой пропускания для каждого абонента.
Также данная архитектура обеспечивает изоляцию абонентов на втором уровне, что
решает большинство проблем безопасности, рассмотренных выше. Главным
недостатком становится необходимость в производительном и как следствие
достаточно дорогом BRAS.
Следующим вариантом является компромиссная децентрализованная модель,
которая обеспечивает обработку Интернет-трафика на BRAS, а обмен локальным
трафиком производится на Layer3-коммутаторах. Тем самым удается снизить
нагрузку и требования по производительности к BRAS (рисунок 1.4).
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Рисунок 1.4 – Децентрализованная модель VLAN на пользователь
В чем же основные достоинства децентрализованной модели? Во-первых, как
и в централизованной сохраняется изоляция абонентов на втором уровне, тем
самым решаются проблемы безопасности. Во-вторых, точками контроля
локального трафика теперь являются коммутаторы агрегации, количество которых
по сравнению с коммутаторами доступа в сети значительно меньше и они более
унифицированы с точки зрения моделей оборудования. В-третьих, локальный
трафик теперь не обрабатывается BRAS.
Недостатки децентрализованной модели:
− Ограничение в 4096 VLAN на каждый коммутатор агрегации;
− Неэффективное использование адресного пространства (может быть решено
использованием проприетарной функции IP Unnumbered on SVI на коммутаторах
Cisco);
− Необходимость ручной конфигурации большого количества VLAN-
интерфейсов на коммутаторах агрегации;
− Индивидуальная конфигурация на каждом коммутаторе доступа.
Несмотря на недостатки, именно эта модель получила широкое
распространение среди Ethernet-операторов, в основном за счет улучшенной
управляемости сети по сравнению с архитектурой с общим VLAN, а также
снижением нагрузки на BRAS за счет обмена нетарифицируемым локальным
трафиком через коммутаторы агрегации.
Итак, изучив существующие подходы к построению архитектуры
операторских Ethernet-сетей, в ходе реализации одного из недавних проектов по
построению сети MetroEthernet, мы задались вопросом: Возможно ли найти
альтернативный подход и получить архитектуру по функциональности схожую с
децентрализованной моделью, но лишенную ее недостатков? Таким образом, была
поставлена задача - обеспечить безопасность и сохранить возможность контроля
локального трафика на Layer3-коммутаторах агрегации, но при этом избежать
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
создания большого числа VLAN-интерфейсов, и так же максимально
унифицировать конфигурацию коммутаторов доступа.
Снизить количество VLAN интерфейсов на коммутаторах агрегации и
одновременно унифицировать конфигурацию коммутаторов доступа возможно при
использовании одного VLAN для всех абонентов, что по сути означает
использование модели с общим VLAN. Однако, как тогда обеспечить прохождение
трафика между любыми двумя абонентами через коммутатор агрегации, который
бы являлся точкой контроля локального трафика? Решение задачи было найдено и
разбито на два этапа.
Во-первых, необходимо изолировать абонентские порты на коммутаторах
доступа в рамках одного VLAN и разрешить прохождение трафика из абонентских
портов только в uplink-порт, подключенный к вышестоящему коммутатору. Данная
функция реализована во многих моделях коммутаторов доступа и имеет различные
названия в зависимости от производителя: Private VLAN, Protected port, Traffic
Segmentation.
Во-вторых, чтобы трафик между любыми двумя абонентами в рамках одного
VLAN всегда проходил через коммутатор агрегации, необходимо, чтобы он отвечал
на все ARP запросы внутри этого VLAN от своего имени. Такая функция носит
название Local Proxy ARP.
Таким образом, мы получили сегментирование общего VLAN в коммутаторах
доступа на отдельные широковещательные домены с помощью функции Private
VLAN, а маршрутизацию трафика между этими доменами реализовали на
коммутаторах агрегации с помощью Local Proxy ARP. Наглядно схема решения
изображена на рисунке 1.5.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Рисунок 1.5 – Архитектура с использованием Private VLAN и Local ProxyARP
Контроль локального трафика в данном случае осуществляется на
коммутаторе агрегации с помощью списков доступа VLAN ACL.
Задача обеспечения безопасности решается аналогично схеме с общим VLAN
– включением на коммутаторах доступа функций DHCP Snooping, Port Security, IP
Source Guard и Dynamic ARP Inspection.
Проблема с «паразитным» широковещательным трафиком отсутствует, так
как каждый абонент находится в собственном изолированном широковещательном
домене. Широковещательные пакеты доходят только до коммутатора агрегации и
не передаются остальным абонентам внутри общего VLAN.
В результате получилась архитектура по функциональным возможностям
аналогичная децентрализованной схеме с VLAN на пользователя, но избавленная
от её недостатков. Так как все пользователи находятся в одном VLAN, то
конфигурация коммутаторов доступа упрощается и становится унифицированной.
Конфигурация коммутаторов агрегации также упрощается за счет необходимости
только в одном VLAN-интерфейсе.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Таблица 1.3 – Сравнение архитектур «PrivateVLAN + Local Proxy ARP» и
«VLAN на пользователя»
PrivateVLAN + VLAN на
пользователя
Local Proxy ARP
Контроль локального Полный Полный

трафика
Количество точек контроля Малое Малое

трафика
«Паразитный» Нет Нет

широковещательный
трафик
Защита от типовых атак Обеспечивается Обеспечивается

функциями на архитектурой
коммутаторе доступа
Сложность реализации Ниже Выше
Конфигурация Унифицированная Индивидуальная

коммутаторов доступа
Использование адресного Эффективное Неэффективное

пространства
1.4 Постановка задачи на модернизацию используемого в компании

метода
1.4.1 Существующий метод
В настоящее время в организации используется следующая схема доступа в

Интернет (рисунок 1.6):
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
ИНТЕРНЕТ
Физический
Сетевая карта 2
сервер
(7 – eth2
)
Iptables SNAT
MySQL
(6
) (4
(11 )
)
Шейпер tc Billing
(3 (9
(5 ) )
) (2 FreeRADI
) US
NAS pptpd (10
)
Сетевая карта 1 –
eth1
(1 (8 (1
) ) )
(8 (1 (8
Абонен ) ) )
т1 Абонен
Абонен т3
Операторская
т2
сеть
Рисунок 1.6 – Существующий метод доступа

− Абонент посылает запрос (1) на подключение к серверу pptpd (реализуется
протокол PPTP) и передает свои «логин» и «пароль»;
− Сервер pptpd посылает запрос (2) RADIUS-серверу на возможность
авторизации пользователя;
− RADIUS-сервер запрашивает (3) данные из биллинговой системы, которая в
свою очередь проверяет (4) данные в базе MySQL;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− При положительном ответе (9) RADIUS-сервер получает разрешение на
авторизацию и IP-адрес клиента;
− При положительном ответе (10) pptpd-сервер устанавливает тоннель (8) и
назначает клиенту IP-адрес, выданный RADIUS-сервером, и разрешает прохождение
трафика;
− Трафик передается (5) шейперу tc для создания правил ограничения скорости
по выбранному тарифу, запрашивая (11) эти данные в Billing;
− И наконец, трафик передается (6) системе Iptables SNAT, выполняется
трансляция адресов и передается (7) в Интернет.
1.4.2 Рассмотрение взаимодействия биллинга с сервисами
Для большего понимания системы взаимодействия и возможностей биллинга

привожу схему его работы (рисунок 1.7):
Рисунок 1.7 – Схема взаимодействия АСР с сервисами

1) Ядро биллинга. Совокупность программ для управления системой;
2) Сервер баз данных. Используется для хранения пользовательских данных;
3) Веб сервер. Используется для визуализации и управления системой;
4) RADIUS сервер. Используется для авторизации пользователей на серверах
доступа (NAS) поддерживающих RADIUS (RFC 2866, RFC 2865,) авторизацию или
аккаунтинг;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
5) Сервера доступа. Устройства служащие для предоставления услуги
пользователям. Могут быть как базированные на PC устройствах так и аппаратные
(Cisco, Juniper, Zyxel, D-Link);
6) Администраторы системы. Администраторы и менеджеры работы с
клиентами управляющие бизнес процессом;
7) Пользователи которым предоставляются услуги.
1.4.3 Постановка задачи
Как видим, на данный момент все необходимые сервисы установлены на

одном физическом сервере, средняя загруженность процессора в пиковые часы
составляет 80-90%, что показывает, что сервер работает на максимуме и
соответственно качество связи ухудшается с увеличением количества абонентов.
Увеличение мощности сервера может временно решить проблему с
загруженностью, но масштабируемость становится не возможной.
В ходе прохождения преддипломной практики и изучения специфики работы
биллинговой системы, организации было предложено решение проблемы с
загруженностью. Также для улучшения качества связи было предложено изменить
протокол доступа PPTP на PPPoE, т.к. последний обладает рядом преимуществ
такими как:
− IP-заголовки в Ethernet среде игнорируются. То есть пользователь может
назначить IP-адрес своей сетевой карте, но это не приведет к «обвалу» сети
(теоретически, при работе с сетевым концентратором не должно произойти «обвала»
и при смене пользователем MAC-адреса даже на адрес сервера, а при работе с
сетевым коммутатором все зависит от конструкции коммутатора).
− Каждое соединение отделено от других (работает в своем канале).
− Настройки (IP-адрес, адрес шлюза, адреса DNS серверов) могут передаваться
сервером.
− PPP соединение легко аутентифицируется и обсчитывается (например, при
помощи RADIUS).
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− PPP соединение можно шифровать. Например, при работе с сетевым
концентратором (когда на каждой сетевой карте может быть виден весь Ethernet-
трафик) прочитать чужой IP-трафик весьма затруднительно.
Также было предложено отказаться от трансляции адресов (NAT) в пользу
чистой маршрутизации «белых» адресов, потому что NAT имеет ряд недостатков:
− Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии
работать, если на пути между взаимодействующими хостами есть трансляция
адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов,
могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не
только в заголовках IP, но и на более высоких уровнях (например, в командах
протокола FTP). См. Application-level gateway.
− Из-за трансляции адресов «много в один» появляются дополнительные
сложности с идентификацией пользователей и необходимость хранить полные логи
трансляций.
− DoS со стороны узла, осуществляющего NAT — если NAT используется для
подключения многих пользователей к одному и тому же сервису, это может вызвать
иллюзию DoS-атаки на сервис (множество успешных и неуспешных попыток).
Например, избыточное количество пользователей ICQ за NAT приводит к проблеме
с подключением к серверу некоторых пользователей из-за превышения допустимой
скорости подключений. Частичным решением проблемы является использование
пула адресов (группы адресов), для которых осуществляется трансляция.
− В некоторых случаях, необходимость в дополнительной настройке (см.
Трансляция порт-адрес) при работе с пиринговыми сетями и некоторыми другими
программами, в которых необходимо не только инициировать исходящие
соединения, но также принимать входящие. Однако, если NAT устройство и ПО,
требующее дополнительной настройки, поддерживают технологию Universal Plug &
Play, то в этом случае настройка произойдет полностью автоматически и прозрачно
для пользователя которые приводят к ухудшению качества сервиса.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
В окончательном виде предполагается реализовать следующую схему
(рисунок 1.8):
ИНТЕРНЕТ
Сетевая карта 1 – Физический

eth2 сервер
Маршрутизат
ор
WEB
Политики MySQL
сервер
шейпинга и
маршрутиза
ции
Billing
RADIUS-сервер
PPPoE
Сетевая карта 1 – Сетевая карта 1 –

eth1 eth1
Абонен
Абонент
т3
1 Абонен
Операторская
т2
сеть
Рисунок 1.8 – Предлагаемая схема взаимодействия

Как видно на схеме, сервисы непосредственной передачи трафика и сервисы
биллинговой системы разнесены на маршрутизатор и выделенный сервер
соответственно. Для проведения данной модернизации на выделенном сервере
достаточно отключить сервис доступа pptpd и деактивировать функции
маршрутизации и передачи трафика. В качестве маршрутизатора предпологается
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
использовать мощный x86 сервер с установленной на него специализированной
операционной системой Mikrotik (http://www.mikrotik.com/)
1.5 Выводы по разделу
ООО «Ставропольские коммерческие сети» в рамках торговой марки SWNet

предоставляет услуги широкополосного доступа в Интернет на основе технологии
ETTH ( Ethernet To The Home).
Компания основа в 2008 году и на данный момент предоставляет услуги
более 400-ам абонентам.
PPPoE (англ. Point-to-point protocol over Ethernet) — сетевой протокол
канального уровня передачи кадров PPP через Ethernet. В основном используется
xDSL-сервисами. Предоставляет дополнительные возможности (аутентификация,
сжатие данных, шифрование).
PPPoE — это туннелирующий протокол, который позволяет настраивать (или
инкапсулировать) IP, или другие протоколы, которые наслаиваются на PPP, через
соединения Ethernet, но с программными возможностями PPP соединений, и
поэтому используется для виртуальных «звонков» на соседнюю Ethernet-машину и
устанавливает соединение точка-точка, которое используется для транспортировки
IP-пакетов, работающее с возможностями PPP.
Это позволяет применять традиционное PPP-ориентированное ПО для
настройки соединения, которое использует не последовательный канал, а пакетно-
ориентированную сеть (как Ethernet), чтобы организовать классическое соединение
с логином, паролем для Интернет-соединений. Также, IP-адрес по другую сторону
соединения назначается только когда PPPoE соединение открыто, позволяя
динамическое переиспользование IP адресов.
На данный момент все необходимые сервисы установлены на одном
физическом сервере, средняя загруженность процессора в пиковые часы составляет
80-90%, что показывает, что сервер работает на максимуме и соответственно
качество связи ухудшается с увеличением количества абонентов. Увеличение
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
мощности сервера может временно решить проблему с загруженностью, но
масштабируемость становится не возможной.
В ходе прохождения изучения специфики работы биллинговой системы,
организации было предложено решение проблемы с загруженностью. Также для
улучшения качества связи было предложено изменить протокол доступа PPTP на
PPPoE.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
2 ПРОЕКТИРОВАНИЕ СТРУКТУРЫ ЧАСТИ ЯДРА СЕТИ НА
ПРЕДПРИЯТИИ
2.1 Разработка схемы разделения задач на два выделенных сервера
2.1.1 Графическое представление модели
Изобразим графически структуру связей на различных уровнях

представления. Рассмотрим схему физической структуры на рисунке 2.1:
Рисунок 2.1 – Физическая структура сети
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Логическая схема связей взаимодействия изображена на рисунке 2.2.
ИНТЕРНЕТ
Маршрутиза Cервер
тор АСР
Клиент Клиент Клиент
Рисунок 2.2 – Логическая схема взаимодействия

И наконец, рассмотрим логическую схему взаимодействия, объектами в
которой являются службы и сервисы (рисунок 2.3).
ИНТЕРНЕ
Т
Служба Сервер
маршрутизац Баз
ии BGP Данных
NAS Сервер
PPPoE RADIUS
Клиент Клиент Клиент
Рисунок 2.3 – Схема взаимодействия сервисов

2.1.2 Детальное рассмотрение протокола RADIUS-сервера
RADIUS (англ. Remote Authentication in Dial-In User Service) — протокол

AAA (Authentication, Authorization и Accounting), разработанный для передачи
сведений между центральной платформой AAA и оборудованием Dial-Up/VPN
доступа (NAS, Network Access Server) и системой биллинга (то есть, системой
тарификации использованных ресурсов конкретным абонентом/пользователем)[1].
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
RADIUS был разработан Livingston Enterprises (конкретно Карлом
Ригней/Carl Rigney) для их серверов доступа (Network Access Server) серии
PortMaster к сети internet, и позже, в 1997, был опубликован как RFC 2058[9] и RFC
2059[10] (текущие версии RFC 2865[11] и RFC 2866[12]). На данный момент
существует несколько коммерческих и свободно распространяемых (open-source)
RADIUS-серверов. Они несколько отличаются друг от друга по своим
возможностям, но большинство поддерживает списки пользователей в текстовых
файлах, LDAP, различных базах данных. Учетные записи пользователей могут
храниться в текстовых файлах, различных базах данных, или на внешних серверах.
Часто для удаленного мониторинга используется SNMP. Существуют прокси-
серверы (proxy/forwarding) для RADIUS, упрощающие централизованное
администрирование и/или позволяющие реализовать концепцию интернет-
роуминга (internet roaming). Они могут изменять содержимое RADIUS-пакета на
лету (в целях безопасности или для выполнения преобразования между
диалектами). Популярность RADIUS-протокола, во многом объясняется:
открытостью к наполнению новой функциональностью при сохранении
работоспособности с устаревающим оборудованием, чрезвычайно высокой
реактивностью при обработке запросов ввиду использования UDP в качестве
транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки
запросов; способностью функционировать в кластерных (Cluster) архитектурах
(например OpenVMS) и мультипроцессорных (SMP) платформах (DEC Alpha, HP
Integrity) — как с целью повышения производительности, так и для реализации
отказоустойчивости.
Oсновные составные части службы идентификации удаленных пользователей
(Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от
IETF: RFC 2865[11] под названием Remote Authentication Dial-In User Service
(RADIUS) в форме проекта стандарта и RFC 2866[12] под названием RADIUS
Accounting в виде «информационного RFC».
Изначально концепция RADIUS состояла в обеспечении удаленного доступа
через коммутируемое телефонное соединение. Со временем выкристаллизовались и
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
другие области применения этой технологии. К ним относятся серверы
виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве
своем поддерживают Rаdius, — а также точки доступа беспроводных локальных
сетей (Wireless LAN, WLAN), и это далеко не все.
Концепция службы идентификации удаленных пользователей подразумевает,
что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа
беспроводной локальной сети — отсылает серверу RADIUS параметры доступа
пользователя (в англоязычной документации они часто называются Credentials, т. е.
мандат, куда, к примеру, входят его настройки безопасности и права доступа), а
также параметры соответствующего соединения. Для этого клиент использует
специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В
ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует
запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-
response. После этого клиент передает на сервер RADIUS учетную информацию.
Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем
информация об аутентификации направляется на порт UDP с номером 1812.
Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об
аутентификации) или, соответственно, 1646 (для учета) — выбор должен
определять своим решением администратор. В поле данных пакета UDP (так
называемая полезная нагрузка) всегда помещается только одно сообщение
RADIUS. В соответствии с RFC 2865[11] и RFC 2866[12] определены следующие
типы сообщений:
− Access-Request – "запрос доступа". Запрос клиента RADIUS, с которого
начинается собственно аутентификация и авторизация попытки доступа в сеть;
− Access-Accept – "доступ разрешен". С помощью этого ответа на запрос
доступа клиенту RADIUS сообщается, что попытка соединения была успешно
аутентифицирована и авторизована;
− Access-Reject – "доступ не разрешен". Этот ответ сервера RADIUS означает,
что попытка доступа к сети не удалась. Такое возможно в том случае, если
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
пользовательских данных недостаточно для успешной аутентификации или доступ
для пользователя не авторизован;
− Access-Challenge – "вызов запроса". Сервер RADIUS передает его в ответ на
запрос доступа;
− Accounting-Request – "запрос учета", который клиент RADIUS отсылает для
ввода учетной информации после получения разрешения на доступ.
Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из
которых содержит ту или иную информацию о попытке доступа: например, имя и
пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким
образом, главной задачей атрибутов RADIUS является транспортировка
информации между клиентами и серверами RADIUS. Атрибуты RADIUS
определены в нескольких RFC, а именно: RFC 2865[11], RFC 2866[12], RFC
2867[13], RFC 2868[14], RFC 2869[15] и RFC 3162[16].
RADIUS может совместно работать с различными протоколами
аутентификации. Наиболее часто используются протокол аутентификации пароля
(Password Authentication Protocol, РАР), протокол аутентификации с
предварительным согласованием (Challenge Handshake Authentication Protocol,
CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 —
во второй).
Протокол CHAP (Challenge Handshake Authentication Protocol)— это протокол
проверки подлинности типа «запрос-ответ», использующий стандартную схему
хеширования Message Digest 5 (MD5) для шифрования ответа. Протокол CHAP
используется множеством поставщиков серверов и клиентов доступа к сети.
Сервер, использующий маршрутизацию и удаленный доступ, поддерживает CHAP
таким образом, что выполняется проверка подлинности клиента удаленного
доступа, требующего данный протокол. Так как CHAP требует использования
обратимо зашифрованного пароля, рекомендуется использовать другой протокол
проверки подлинности, например MS-CHAP версии 2.
Операционные системы семейства Windows Server 2003 поддерживают
протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности,
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
создание более надежных начальных ключей шифрования данных для MPPE
(Microsoft Point-to-Point Encryption) и разные ключи шифрования для отправки и
приема данных. Чтобы свести к минимуму риск раскрытия пароля во время обмена
паролями, из протокола исключена поддержка старых методов обмена паролями
MS-CHAP.
Поскольку версия MS-CHAP v2 обеспечивает более надежную защиту, чем
MS-CHAP, при подключении сначала предлагается использовать именно ее (если
она доступна), а затем уже MS-CHAP.
Протокол MS-CHAP v2 поддерживается на компьютерах, работающих под
управлением Windows XP, Windows 2000, Windows 98, Windows Millennium Edition
и Windows NT 4.0. Компьютеры, работающие под управлением Windows 95,
поддерживают MS-CHAP v2 только для подключений VPN, но не для подключений
удаленного доступа.
Кроме того, возможно применение RADIUS вместе с PPP, протоколом
передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса
аутентификации между сервером доступа и действующим клиентом передаются на
сервер RADIUS, который их потом удостоверяет.
Для защиты сообщений клиент и сервер RADIUS обладают «общим
секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке
символов, имеющейся как на серверах, так и на клиенте RADIUS.
2.1.3 Детальное рассмотрение механизма авторизации пользователя
Вызов-ответ (англ. Challenge-response authentication) — способ

аутентификации, при котором секрет (в данном случае пароль) не передаётся по
каналу связи[1].
Простейший способ такой аутентификации (при хранении паролей в
открытом виде):
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Клиент, желающий пройти аутентификацию, дает запрос на начало сеанса
связи, в ответ на это вызываемая сторона (сервер) посылает произвольную, но
всякий раз разную информацию (например, текущие дату и время) клиенту;
− Клиент дописывает к полученному запросу пароль и от этой строки
вычисляет какой-либо хэш (например, MD5) и отправляет его серверу;
− Сервер проделывает с посланным значением аналогичные действия и
сравнивает результат. Если значения хэшей совпадают, то авторизация считается
успешной.
Рассмотрим основные протоколы проверки подлинности:
PAP (англ. Password Authentication Protocol) — протокол простой проверки
подлинности, предусматривающий отправку имени пользователя и пароля на
сервер удалённого доступа открытым текстом (без шифрования)[1]. Протокол PAP
крайне ненадежён, поскольку пересылаемые пароли можно легко читать в пакетах
PPP (англ. Point-to-Point Protocol), которыми обмениваются стороны в ходе
проверки подлинности. Обычно PAP используется только при подключении к
старым серверам удалённого доступа на базе UNIX, которые не поддерживают
никакие другие протоколы проверки подлинности.
CHAP (англ. Challenge Handshake Authentication Protocol) — широко
распространённый алгоритм проверки подлинности, предусматривающий передачу
не самого пароля пользователя, а косвенных сведений о нём[1]. При использовании
CHAP сервер удалённого доступа отправляет клиенту строку запроса. На основе
этой строки и пароля пользователя клиент вычисляет хеш-код MD5 (англ. Message
Digest-5) и передаёт его серверу. Хеш-функция является алгоритмом
одностороннего (необратимого) шифрования (преобразования), поскольку значение
хеш-функции для блока данных вычислить легко, а определить исходный блок по
хеш-коду с математической точки зрения невозможно за приемлемое время.
Сервер, которому доступен пароль пользователя, выполняет те же самые
вычисления и сравнивает результат с хеш-кодом, полученным от клиента. В случае
совпадения учётные данные клиента удалённого доступа считаются подлинными.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
MS-CHAP (англ. Microsoft Challenge Handshake Authentication Protocol) —
протокол, разработанный корпорацией Microsoft для выполнения процедур
проверки подлинности удалённых рабочих станций Windows[1]. Протокол
поддерживает функциональные возможности, привычные пользователям
локальных сетей, и интегрирует алгоритмы шифрования и хеширования,
действующие в сетях Windows. Для проведения проверки подлинности без
передачи пароля протокол MS-CHAP, как и CHAP, использует механизм «вызов-
ответ».
Протокол MS-CHAP генерирует запрос и ответ с помощью алгоритма
хеширования MD4 (англ. Message Digest 4) и алгоритма шифрования DES (англ.
Data Encryption Standard); предусмотрены также механизмы возврата сообщений об
ошибках подключения и возможности изменения пароля пользователя. Ответный
пакет использует специальный формат, предназначенный для использования
сетевыми средствами систем Windows 95, Windows 98, Windows Millennium Edition,
Windows NT, Windows 2000 и Windows XP.
CHAP аутентификация происходит следующим образом - при установлении
PPP-соединения удалённая сторона предлагает нам аутентификацию CHAP. Мы
соглашаемся, и удалённая сторона высылает нам ключ (challenge), состоящий из
случайной последовательности символов, и своё имя. Мы берем наш пароль и
присланный ключ и прогоняем их через алгоритм MD5. Получившийся результат
высылаем вместе со своим именем. Удалённая сторона, зная наш пароль и
высланный её ключ, в свою очередь, проделывает то же самое у себя, и если её
результат совпадает с присланным нами, то аутентификация считается успешной.
Таким образом, пароль не передается в открытом виде, но удалённая сторона
должна хранить наш пароль в открытом виде.
Рассмотрим как отреагирует NAS при поступлении запроса пользователя на
аутентификацию:
− Пользователь пытается пройти аутентификацию на NAS;
− NAS смотрит в первый попавшийся RADIUS сервер и посылает пакет для
установки связи(запрос на доступ);
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Если ответ не получен в течение определённого тайм-аута, то NAS либо
опрашивает RADIUS сервер ещё раз, либо ищет альтернативный сервер;
− RADIUS сервер смотрит ip адрес NAS и проверяет ключ симметричного
шифрования, если ip адрес и ключ соответствуют тому, что написано в
конфигурационном файле, то связь продолжается, иначе клиенту посылается пакет
Invalid Key. Проверка осуществляется генерацией и шифрацией случайной строки.
Далее передаваемые между клиентом и сервером RADIUS данные шифруются
данным ключом;
− Сервер RADIUS проверяет пароль пользователя (по сети передается md5 хеш
пароля), помимо пароля сервер может также проверить ip адрес и порт NAS, если эти
данные неверны, то сервер посылает NAS пакет "Доступ запрещён", содержащий код
ошибки, который также может содержать текстовое описание ошибки, отображаемое
для пользователя;
− Если же данные пользователя верны, то сервер посылает NAS пакет "Доступ
разрешён", содержащий данные о сервисе (PPP, SLIP, login) и некоторые
специфические параметры сервиса, например, ip адрес, номер подсети, MTU для PPP
сервиса в виде пар параметр=значение(AV пар).
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
2.2 Разработка метода устранения NAT и перехода на внешнюю
адресацию Интернета
2.2.1 Детальное рассмотрение системы NAT
Базовая трансляция сетевых адресов или Basic NAT представляет собой метод
отображения адресов IP из одной группы в другую, прозрачного для конечных
пользователей. Трансляция сетевых адресов и номеров портов или NAPT - метод, с
помощью которого множество сетевых адресов и соответствующих портов
TCP/UDP (Transmission Control Protocol/User Datagram Protocol) преобразуется в
один сетевой адрес и номер порта TCP/UDP. Оба метода вместе называют
традиционной трансляцией адресов (traditional NAT). NAT обеспечивает механизм
подключения областей с приватными адресами к внешним областям, в которых
используются уникальные в глобальном масштабе зарегистрированные адреса.
Необходимость преобразования (трансляции) адресов IP возникает в тех
случаях, когда используемые внутри сети адреса IP невозможно использовать за
пределами сети из соображений сохранения тайны или по той причине, что эти
адреса корректны только внутри сети[17].
Сетевая топология за пределами локального домена может изменяться по
разным причинам. Абоненты могут менять провайдеров, опорные сети компаний
могут реорганизоваться, а провайдеры могут делиться или объединяться. Всякий
раз при изменении внешней топологии выделение адресов внутри локального
домена также требуется соответствующим образом изменять. Эти изменения могут
оставаться незаметными для пользователей внутри домена при централизованном
изменении на одном маршрутизаторе, обеспечивающем трансляцию адресов.
Базовая трансляция во многих случаях может обеспечивать доступ
пользователей из частной сети во внешние сети, а также доступ извне к некоторым
локальным хостам. Организациям, в которых сеть используется для решения
внутренних задач, а доступ во внешние сети требуется нерегулярно, такая схема
будет весьма удобна.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Многие пользователи SOHO и удаленные сотрудники используют в своих
офисах множество узлов с приложениями TCP/UDP, но имеют лишь один адрес IP,
выделенный их маршрутизатору провайдером для доступа во внешнюю сеть. Эта
постоянно растущая группа удаленных пользователей может применить метод
трансляции NAPT, который позволяет множеству узлов из локальной сети
одновременно получить доступ во внешние сети с использованием единственного
адреса IP, выделенного для их маршрутизатора.
Существуют ограничения на использование метода трансляции. Обязательно,
чтобы все запросы и отклики, относящиеся к одной сессии, маршрутизировались
одним NAT-маршрутизатором. Одним из вариантов решения задачи является
организация NAT на граничном маршрутизаторе, который является единственным
для краевого домена и все пакеты IP, адресованные в домен или исходящие из него,
проходят через этот маршрутизатор. Существуют также варианты решения задачи
при использовании множества устройств NAT. Например, частная сеть может
иметь две разных точки выхода в сети различных провайдеров и поток пакетов той
или иной сессии внутреннего хоста может проходить через любое устройств NAT,
которое будет обеспечивать лучшую метрику для внешнего хоста. При отказе
одного из маршрутизаторов NAT оставшийся маршрутизатор сможет обслуживать
трафик для всех соединений. Однако в этой модели при смене маршрутизации во
время организованной сессии и переключении на другой маршрутизатор NAT
соединение данной сессии будет разорвано. В качестве варианта решения этой
проблемы можно использовать одинаковую конфигурацию NAT на обоих
маршрутизаторах обмен информацией соединений для обеспечения безопасного
переключения трафика между маршрутизаторами.
Трансляция адресов не зависит от приложений и часто сопровождается
специализированными шлюзами (ALG для мониторинга и изменения передаваемой
информации. FTP является наиболее популярным представителем ALG на
устройствах NAT. Приложениям, которым требуется наличие ALG, недопустимо
передавать свои данные в шифрованном виде, поскольку это будет нарушать
работу ALG, если последний не имеет ключа для расшифровки информации.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Недостатком этого решения является сквозная значимость адресов IP и рост
числа хранимых состояний. В результате сквозная защита IP на сетевом уровне,
обеспечиваемая IPSec, не может использоваться конечными станциями при
наличии в пути устройств NAT. Преимуществами этого варианта является то, что
его можно реализовать без внесения изменений в настройки хостов и
маршрутизаторов.
Обзор традиционной трансляции NAT
Описанная работа системы трансляции адресов относится к Traditional
NAT[17]. Существуют и другие варианты NAT. Traditional NAT обеспечивает в
большинстве случаев внутренним хостам частных сетей прозрачный доступ во
внешнюю сеть. При традиционной трансляции сессии являются односторонними и
направлены наружу из частной сети. Организация сессий в противоположном
направлении может быть разрешена в качестве исключения с использованием
статического отображения адресов для избранных хостов. Традиционная
трансляция имеет два варианта - Basic NAT и NAPT. Basic NAT обеспечивает
преобразование только для адресов, а NAPT позволяет транслировать адреса IP и
идентификаторы транспортного уровня (такие, как номера портов TCP/UDP или
ICMP query ID). Рассмотрим традиционную конфигурацию NAT на рисунке 2.4.
ИНТЕРНЕТ
Внешний ip адрес
маршрутизат
ор
Внутренний ip
адрес
Внутренний ip Внутренний ip
адрес адрес
Компьют Компьют
ер ер
Рисунок 2.4 - Традиционная конфигурация NAT

Фазы трансляции для сеанса:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Привязка адреса. При использовании Basic NAT приватный адрес
связывается с внешним адресом при организации первой исходящей сессии со
стороны хоста локальной сети. Все последующие сессии, организованные этим
хостом, будут использовать тот же адрес для трансляции пакетов. В случае NAPT
множество приватных адресов отображается на один публичный адрес и привязка
будет осуществляться между парами (приватный адрес, приватный порт TU) и
парами (публичный адрес, выделенный порт TU). Как и для Basic NAT эта привязка
определяется при организации первой исходящей сессии для пары (приватный адрес,
приватный порт TU) со стороны хоста локальной сети. Хотя это и не является
общепринятым, возможна организация приложением на хосте локальной сети
множества одновременных сессий для одной пары (приватный адрес, приватный
порт TU). В таких случаях для этой пары (приватный адрес, приватный порт TU)
может использоваться одна привязка для всех пакетов, относящихся к сессиям для
данной пары с этого хоста.
− Просмотр и трансляция адреса. После привязки адреса или пары (адрес,
порт TU)в случае использования NAPT может на программном уровне
поддерживаться информация о состоянии каждого соединения, использующего
данную привязку. Пакеты, относящиеся к одной сессии транслируются с учетом
данной сессии. Точное поведение трансляции рассматривается ниже.
− Удаление привязки адреса. Когда последняя сессия для адреса или пары
(адрес, порт TU) завершается, привязка может быть ликвидирована.
Преобразование пакетов
− Манипуляции с заголовками IP, TCP, UDP и ICMP. В модели Basic NAT
требуется изменять заголовок IP в каждом пакете. Модификация включает адрес IP
(адрес отправителя для исходящих пакетов и адрес получателя для входящих) и
контрольную сумму IP. Для сессий TCP ([TCP]) и UDP ([UDP]) также требуется
изменять контрольную сумму в заголовках TCP/UDP. Это связано с тем, что
контрольная сумма TCP/UDP учитывает также псевдозаголовок, содержащий IP-
адреса отправителя и получателя. Исключением являются случаи когда контрольная
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
сумма заголовка UDP имеет значение 0 – в этом случае поле контрольной суммы не
меняется. Для пакетов ICMP Query ([ICMP]) не требуется вносить изменений в
заголовок ICMP, поскольку контрольная сумма в заголовке ICMP не учитывает
адресов IP. В модели NAPT изменение заголовка IP похоже на случай Basic NAT.
Для сессий TCP/UDP изменяется также номер порта TU (порт отправителя для
исходящих пакетов и порт получателя для входящих) в заголовке TCP/UDP.
Заголовок ICMP в пакетах ICMP также требуется изменять для корректировки
значения идентификатора запроса и контрольной суммы заголовка ICMP.
Идентификатор запроса хоста внутренней сети в исходящих пакетах должен
заменяться на присвоенный при трансляции идентификатор, а для входящих
откликов должно выполняться обратное преобразование. Контрольная сумма
заголовка ICMP должна корректироваться с учетом трансляции Query ID.
− Корректировка контрольной суммы. Преобразования NAT выполняются для
каждого пакета и могут приводить к значительным расходам вычислительных
ресурсов при необходимости корректировки одной или нескольких контрольных
сумм в дополнение к простой замене полей. К счастью существует приведенный
ниже алгоритм, делающий корректировку контрольных сумм заголовков IP, TCP,
UDP и ICMP очень простой и эффективной. Поскольку все эти заголовки
используют арифметику дополнения до 1, достаточно рассчитать разность между
адресами до и после трансляции и добавить полученное значение к контрольной
сумме. Приведенный ниже алгоритм применим только для случаев четного
смещения (т. е., поле optr должно начинаться с четного октета от начала заголовка) и
четной длины (т. е., поля olen и nlen должны иметь четные значения).
− Изменение сообщений ICMP об ошибках. Изменения для сообщений ICMP об
ошибках ([ICMP]) будут включать модификацию заголовков IP и ICMP, а также
модификацию заголовков пакета, вложенного в поле данных сообщения ICMP.
Чтобы трансляция NAT была прозрачной для конечных хостов, адрес IP в заголовке
IP, вложенном в поле данных сообщения ICMP, а также контрольная сумма
вложенного заголовка IP должны быть изменены. Требуется также изменить
значение контрольной суммы заголовка ICMP с учетом изменений, внесенных в
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
данные. Для случая NAPT, если пакет IP, вложенный в сообщение ICMP, является
пакетом TCP, UDP или ICMP Query, потребуется также изменить номер порта TU в
заголовке TCP/UDP или поле Query Identifier в заголовке ICMP Query. В заключение
нужно изменить заголовок IP пакета, содержащего сообщение ICMP.
− Поддержка FTP. Одно из наиболее популярных приложений FTP ([FTP])
будет требовать наличия ALG для мониторинга управляющей сессии, чтобы
определить параметры соответствующего сеанса передачи данных. FTP ALG
является встроенной компонентой большинства реализаций NAT. FTP ALG требует
специальной таблицы для корректировки порядковых номеров и номеров
подтверждений с учетом номера порта FTP для отправителя или получателя. В
записи таблицы следует включать адреса и номера портов для отправителя и
получателя, приращения (delta) для порядковых номеров, а также временные метки.
Новые записи включаются в таблицу только в результате наблюдения команд FTP
PORT и откликов PASV. Приращение порядкового номера может увеличиваться или
уменьшаться для каждой команды FTP PORT и отклика PASV. Порядковые номера
инкрементируются для исходящих пакетов, а номера подтверждений
декрементируются для входящих пакетов на величину приращения (delta). Для
случая Basic NAT преобразование данных FTP ограничивается трансляцией между
приватными и публичными адресами (кодируются пооктетно в ASCII). Для случая
NAPT требуется также трансляция октетов, задающих номер порта TCP (в коде
ASCII) и следующих за октетами адреса.
− Поддержка DNS. Исходя из того, что при традиционной трансляции NAT
сессии преимущественно инициируются из внутренней сети, можно избежать
применения DNS ALG в связке с традиционной трансляцией NAT. Внутренние
серверы DNS приватного домена обеспечивают преобразование имен в адреса IP для
внутренних хостов и возможно для некоторых внешних хостов. Внешние серверы
DNS поддерживают преобразование имен для внешних хостов, но не поддерживают
для внутренних. Если в частной сети нет внутренних серверов DNS, все запросы
DNS могут направляться к внешним серверам DNS для поиска отображения имен
внешних хостов.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Обработка опций IP. Дейтаграммы IP с любыми из опций Record Route, Strict
Source Route и Loose Source Route будут включать запись использования адресов IP
промежуточных маршрутизаторов. Промежуточный маршрутизатор NAT может
отказаться от поддержки таких опций или оставлять нетранслированные адреса при
обработке опций. Результатом сохранения нетранслированных адресов в опциях
будет раскрытие внутренних адресов сети в пакетах с опциями заданной
отправителем маршрутизации. Это не создает, по сути, дополнительного риска,
поскольку предполагается, что каждый маршрутизатор просматривается только
маршрутизатором следующего интервала (next hop router).
Деление адресов на приватные и публичные
Для описанной работы NAT необходимо разделить пространство адресов IP
на две части – приватные адреса, используемые внутри оконечного домена, и
публичные адреса с глобальной доступностью. Любой конкретный адрес должен
относится к числу приватных или публичных. Области приватных и публичных
адресов не перекрываются.
Проблема перекрытия приватных и публичных адресов заключается в
следующем - предположим, что хост оконечного домена A хочет передать пакет
хосту оконечного домена B, но публичные адреса домена B перекрываются с
приватными адресами домена A. В таком случае маршрутизаторы домена A не
смогут отличить публичный адрес хоста из домена B от приватного адреса в своем
домене.
Рекомендации по выбору приватных адресов
RFC 1918 содержит рекомендации по выделению адресного пространства для
частных сетей. Агентство IANA выделило для этих целей 3 блока адресов IP -
10.0.0.0/8, 172.16.0.0/12, и 192.168.0.0/16. В нотации без использования CIDR
первый блок представляет собой одну сеть класса A, второй – 16 последовательных
сетей класса B, а третий – 256 последовательных сетей класса C.
Организации, которые решили использовать адреса из указанных блоков,
могут делать это без какого-либо согласования с IANA или реестром Internet.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Адресное пространство может, таким образом, использоваться одновременно во
множестве организаций с трансляцией NAT на граничных маршрутизаторах.
Маршрутизация через NAT
Маршрутизаторам, обеспечивающим NAT, не следует анонсировать наружу
префиксы частных сетей. За пределами оконечного домена могут быть известны
только публичные адреса. Однако глобальная информация, получаемая NAT от
оконечного маршрутизатора может обычным путем анонсироваться во
внутреннюю сеть.
Обычно оконечный маршрутизатор NAT имеет статический маршрут для
пересылки всего направленного наружу трафика маршрутизатору сервис-
провайдера через канал WAN, а маршрутизатор провайдера имеет статический
маршрут для пересылки пакетов NAT (т. е., пакетов, в которых IP-адрес получателя
относится к используемому NAT блоку публичных адресов) маршрутизатору NAT
через канал WAN.
Современные реализации
Доступно множество коммерческих реализаций трансляции адресов, которые
соответствуют описанию NAT. Открытая ОС Linux содержит реализацию NAT,
называемую "IP masquerade". Открытая ОС FreeBSD содержит реализацию NAPT,
работающую как демон. Отметим, что исходный код Linux распространяется по
лицензии GNU, а программы FreeBSD – по лицензии UC Berkeley.
Программы для Linux и FreeBSD являются бесплатными и вы можете купить
компакт-диск с любой из этих программ за весьма разумную цену. Можно также
просто загрузить последний вариант программы со множества серверов FTP.
2.2.2 Детальное рассмотрение протокола маршрутизации BGP
BGP (англ. Border Gateway Protocol, протокол граничного шлюза) —

основной протокол динамической маршрутизации в Интернете[1].
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
BGP, в отличие от других протоколов динамической маршрутизации,
предназначен для обмена информацией о маршрутах не между отдельными
маршрутизаторами, а между целыми автономными системами, и поэтому, помимо
информации о маршрутах в сети, переносит также информацию о маршрутах на
автономные системы. BGP не использует технические метрики, а осуществляет
выбор наилучшего маршрута исходя из правил, принятых в сети[18].
BGP поддерживает бесклассовую адресацию и использует суммирование
маршрутов для уменьшения таблиц маршрутизации. С 1994 года действует
четвёртая версия протокола RFC 4271[19], все предыдущие версии являются
устаревшими.
BGP является протоколом прикладного уровня и функционирует поверх
протокола транспортного уровня TCP (порт 179).
BGP, наряду с DNS, является одним из главных механизмов,
обеспечивающих функционирование Internet.
Протокол BGP (RFC-1267 BGP-3; RFC-1665; RFC-1467 BGP-4; -1771, -1863,
-1997, -2439, -2545, -2796, -2858, -2918, -3065, -3107, -3392) разработан компаниями
IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик
либо начинается, либо завершается в автономной системе (AS); в противном случае
- это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP
(им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ,
использующая протокол BGP, является маршрутизатором, даже если она
обменивается маршрутной информацией с пограничным маршрутизатором
соседней автономной системы. AS передает информацию только о маршрутах,
которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями
об изменении маршрутов (UPDATE-сообщения, рисунок 2.6). Максимальная длина
таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое
сообщение имеет заголовок фиксированного размера. Объем информационных
полей зависит от типа сообщения.
Здесь уместно заметить, что Интернет - это клуб джентльменов. Очень
многие узлы пропускают через себя значительный транзитный трафик, который
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
ограничивает возможности непосредственных клиентов узла. Как правило, этот
трафик никак не оплачивается. Администраторы могут в рамках протокола BGP
существенно ограничить или даже исключить такой транзитный трафик, но они
обычно этого не делают, понимая, что их клиенты создают такой же транзитный
трафик для других узлов. Эгоистичное поведение администраторов развалило бы
сеть Интернет на ряд враждующих феодальных крепостей.
Рисунок 2.6 – Формат BGP-сообщений об изменениях маршрутов

Поле маркер содержит 16 октетов и его содержимое может легко
интерпретироваться получателем. Если тип сообщения "OPEN", или если код
идентификации в сообщении open равен нулю, то поле маркер должно быть
заполнено единицами. Маркер может использоваться для обнаружения потери
синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет
общую длину сообщения в октетах, включая заголовок. Значение этого поля
должно лежать в пределах 19-4096. Поле тип представляет собой код
разновидности сообщения и может принимать следующие значения:
1 OPEN (открыть)
2 UPDATE (изменить)
3 NOTIFICATION (внимание)
4 KEEPALIVE (еще жив)
BGP отличается от RIP и OSPF тем, что использует TCP в качестве
транспортного протокола. Две системы, использующие BGP, связываются друг с
другом и пересылают посредством TCP полные таблицы маршрутизации.
После того как связь на транспортном протокольном уровне установлена,
первое сообщение, которое должно быть послано - это OPEN. При успешном
прохождении этого сообщения партнер должен откликнуться сообщением
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме
заголовка сообщение open содержит следующие поля (Рисунок 2.7):
Рисунок 2.7 – Формат сообщения open

Поле версия описывает код версии используемого протокола, на сегодня для
BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS
отправителя. Поле время сохранения характеризует время в секундах, которое
отправитель предлагает занести в таймер сохранения. После получения сообщения
OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно
выбирается меньшее из полученного в сообщении open и значения, определенного
при конфигурации системы (0-3сек). Время сохранения определяет максимальное
время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя
UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный
идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех
интерфейсов локальной сети). Если два узла установили два канала связи друг с
другом, то согласно правилам должен будет сохранен канал, начинающийся в узле,
BGP-идентификатор которого больше. Предусмотрен механизм разрешения
проблемы при равных идентификаторах.
Одно-октетный код идентификации позволяет организовать систему доступа,
если он равен нулю, маркер всех сообщений заполняется единицами, а поле
идентификационных данных должно иметь нулевую длину. При неравном нулю
коде идентификации должна быть определена процедура доступа и алгоритм
вычисления кодов поля маркера. Длина поля идентификационных данных
определяется по формуле:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Длина сообщения = 29 + длина поля идентификационных данных.
Минимальная длина сообщения open составляет 29 октетов, включая заголовок.
Сообщения типа UPDATE (изменения) используются для передачи
маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет
сообщить об одном новом маршруте или объявить о закрытии группы маршрутов,
причем объявление об открытии нового и закрытии старых маршрутов возможно в
пределах одного сообщения. Сообщение UPDATE всегда содержит стандартный
заголовок и может содержать другие поля в соответствии со схемой(Рисунок 2.8):
Рисунок 2.8 – Формат update-сообщения

Если длина списка отмененных маршрутов равна нулю, ни один маршрут не
отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные
маршруты имеет переменную длину и содержит список IP-адресных префиксов
маршрутов, которые стали недоступны. Каждая такая запись имеет
формат(Рисунок 2.9):
Рисунок 2.9 – Формат записи отмененных маршрутов

Длина префикса (в битах), равная нулю означает, что префикс соответствует
всем IP-адресам, а сам имеет нулевой размер. Поле префикс содержит IP-адресные
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
префиксы, за которыми следуют разряды, дополняющие их до полного числа
октетов. Значения этих двоичных разрядов смысла не имеют.
Нулевое значение полной длины списка атрибутов пути говорит о том, что
информация о доступности сетевого уровня в UPDATE-сообщении отсутствует.
Список атрибутов пути присутствует в любом UPDATE-сообщении. Этот список
имеет переменную длину, а каждый атрибут содержит три составные части: тип
атрибута, длину атрибута и значение атрибута. Тип атрибута представляет собой
двух-октетное поле со структурой(Рисунок 2.10):
Рисунок 2.10 – Тип атрибута

Старший бит (бит0) поля флаги атрибута определяет, является ли атрибут
опционным (бит0=1) или стандартным (well-known, бит0=0). Бит 1 этого поля
определяет, является ли атрибут переходным (бит1=1) или непереходным (бит1=0).
Для обычных атрибутов этот бит должен быть равен 1. Третий бит (бит 2) поля
Флагов атрибута определяет, является ли информация в опционном переходном
атрибуте полной (бит2=0) или частичной (бит2=1). Для обычных и для опционных
непереходных атрибутов этот бит должен быть равен нулю. Бит 3 поля флагов
атрибута информирует о том, имеет ли длина атрибута один (бит3=0) октет или два
октета (бит3=1). Бит3 может быть равен 1 только в случае, когда длина атрибута
более 255 октетов. Младшие 4 бита октета флагов атрибута не используются (и
должны обнуляться). Если бит3=0, то третий октет атрибута пути содержит длину
поля данных атрибута в октетах. Если же бит3=1, то третий и четвертый октеты
атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут
пути характеризуют значение атрибута и интерпретируются согласно флагам
атрибута.
Атрибуты пути бывают "стандартные обязательные" (well-known mandatory),
"стандартные на усмотрение оператора", "опционные переходные" и "опционные
непереходные". Стандартные атрибуты должны распознаваться любыми BGP-
приложениями. Опционные атрибуты могут не распознаваться некоторыми
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
приложениями. Обработка нераспознанных атрибутов задается битом 1 поля
флагов. Пути с нераспознанными переходными опционными атрибутами должны
восприниматься, как рабочие. Один и тот же атрибут может появляться в списке
атрибутов пути только один раз.
Маршрутная база данных RIB
Вся маршрутная информация хранится в специальной базе данных RIB
(routing information base). Маршрутная база данных BGP состоит из трех частей:
− ADJ-RIBS-IN: Запоминает маршрутную информацию, которая получена из
update-сообщений. Это список маршрутов, из которого можно выбирать. (policy
information base - PIB);
− LOC-RIB: Содержит локальную маршрутную информацию, которую BGP-
маршрутизатор отобрал, руководствуясь маршрутной политикой, из ADJ-RIBS-IN;
− ADJ-RIBS-OUT: Содержит информацию, которую локальный BGP-
маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений.
Так как разные BGP-партнеры могут иметь разную политику маршрутизации,
возможны осцилляции маршрутов. Для исключения этого необходимо выполнять
следующее правило: если используемый маршрут объявлен не рабочим (в процессе
корректировки получено сообщение с соответствующим атрибутом), до
переключения на новый маршрут необходимо ретранслировать сообщение о
недоступности старого всем соседним узлам.
Протокол BGP позволяет реализовать маршрутную политику, определяемую
администратором AS. Политика отражается в конфигурационных файлах BGP.
Маршрутная политика это не часть протокола, она определяет решения, когда
место назначения достижимо несколькими путями, политика отражает
соображения безопасности, экономические интересы и пр. Количество сетей в
пределах одной AS не лимитировано. Один маршрутизатор на много сетей
позволяет минимизировать таблицу маршрутов.
BGP использует три таймера:
− Connectretry (сбрасывается при инициализации и коррекции; 120 сек);
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Holdtime (запускается при получении команд Update или Keepalive; 90сек);
− Keepalive (запускается при посылке сообщения Keepalive; 30сек).
BGP отличается от RIP и OSPF тем, что использует TCP в качестве
транспортного протокола. Две системы, использующие BGP, связываются друг с
другом и пересылают посредством TCP полные таблицы маршрутизации. В
дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая
BGP, не обязательно является маршрутизатором. Сообщения обрабатываются
только после того, как они полностью получены.
Алгоритм вектора расстояния
BGP является протоколом, ориентирующимся на вектор расстояния. Вектор
описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает
соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что
"Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются
установить связь друг с другом одновременно, такие две связи могут быть
установлены. Такая ситуация называется столкновением, одна из связей должна
быть ликвидирована. При установлении связи маршрутизаторов сначала делается
попытка реализовать высший из протоколов (например, BGP-4), если один из них
не поддерживает эту версию, номер версии понижается.
Протокол BGP-4 является усовершенствованной версией (по сравнению с
BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках
одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой
версии. Для того чтобы приспособиться к этому, изменена семантика и
кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень
предпочтительности маршрута для собственной AS), который упрощает процедуру
выбора маршрута. Атрибут INTER_AS_METRICS переименован в
MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей).
Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые
позволяют группировать маршруты. Структура данных отражается и на схеме
принятия решения, которая имеет три фазы:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− Вычисление степени предпочтения для каждого маршрута, полученного от
соседней AS, и передача информации другим узлам местной AS;
− Выбор лучшего маршрута из наличного числа для каждой точки назначения
и укладка результата в LOC-RIB;
− Рассылка информации из loc_rib всем соседним AS согласно политике,
заложенной в RIB. Группировка маршрутов и редактирование маршрутной
информации.
Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain
routing, RFC-1520, -1519) - способ избежать того, чтобы каждая С-сеть требовала
свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в
группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число
входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466).
Протокол совместим с RIP-2, OSPF и BGP-4.
Основу протокола CIDR составляет идея бесклассовых адресов, где нет
деления между полем сети и полем ЭВМ.
Дополнительная информация, например 32-разрядная маска, выделяющая
поле адреса сети, передается в рамках протокола маршрутизации. При этом
выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание
> сегмент локальной сети. Групповой (агрегатный) адрес воспринимается
маршрутизатором как один адрес. Группу может образовывать только непрерывная
последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто
называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов
192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 -
192.1.255.255, таким образом, число, следующее после косой черты, задает
количество двоичных разрядов префикса. Это представление используется при
описании политики маршрутизации и самих маршрутов. Для приведенных
примеров это в терминах масок выглядит следующим образом:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Рисунок 2.10 – 24 и 17 длины префикса сети
Следует помнить, что маски с разрывами здесь недопустимы. Ниже
приведена таблица метрик маршрутизации для различных протоколов(Таб. 2.5).
Таблица 2.1 – Метрики маршрутизации для различных протоколов.
Код "маршрут
Протокол Метрика Диапазон
недостижим"
RIP Число скачков 0-15 16
hello Задержка в ms 0-29999 30000
BGP Не определена 0-65534 65535
Колонка "маршрут недостижим" содержит коды метрики, которые говорят о

недоступности маршрута. Обычно предполагается, что если послан пакет из точки
<А> в точку <B>, то маршруты их в одном и другом направлении совпадают. Но
это не всегда так. Пример, когда маршруты пакетов "туда" и "обратно" не
совпадают, представлен на рисунке 2.11. В предложенной схеме имеется две ЭВМ
"Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора "GW-2" и
"GW-1".
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Рисунок 2.11 – Пример разных маршрутов для пути "туда" и "обратно"
2.2.3 Разработка плана по внедрению
В первую очередь необходимо получить блок PI адресов. Провайдеро-

независимые IP адреса ("Provider Independent", или "PI") - это адреса, которые
могут маршрутизироваться небольшим количеством независимо от вышестоящего
провайдера.
В регионе RIPE NCC это адреса из блоков: 193/8, 194/7, 91/8.
В документе "Address Space Managed by the RIPE NCC" (5. "Longest Prefix
Tables") эти блоки помечены как Longest Prefix /29. Для маршрутизации
независимых адресов необходимо иметь как минимум /24 (256 адресов) и номер
AS.
Независмые IP адреса можно получить двумя способами:
− Запросить через LIR;
− Получить непосредственно в RIPE NCC.
Запросить независимые ресурсы (IP адреса, номер AS) можно, обратившись в
LIR. LIR - Local Internet Registry - организация, заключившая договор с RIPE NCC.
Членство в ассоциациии RIPE NCC дает право на получение блока IP адресов не
менее /21 и номера Автономной системы (ASN). LIR'ами, как правило, являются
крупные интернет-провайдеры, а также организации, имеющие обширную сеть IP
адресов: телекоммуникационные компании, промышленные предприятия,
административные учреждения, академические институты. LIR имеет полномочия
получать независимые ресурсы в RIPE NCC в интересах пользователя. Для
получения независимых ресурсов необходимо заключить контракт между
пользователем (End User) и LIR. Общие условия контракта изложены в документе
ripe-452 (см. также: перевод ripe-452 на русский язык). Одним из условий является
регулярная оплата за полученные ресурсы. Размер оплаты устанавливает LIR.
Запрос в RIPE NCC
Независимые ресурсы можно получить в RIPE NCC, заключив договор с этой
организацией. В этом случае Вы получаете статус "Direct Assignment User".
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Получать независимые ресурсы в качестве "Direct Assignment User" не
рекомендуется тем организациям, которым необходимо большое количество
независимых адресов. "Direct Assignment User" обязан использовать полученные
ресурсы для собственной инфраструктуры и не имеет права выделять адреса
третьим лицам.
Оплата за независимые ресурсы производится в соответствии с документом
RIPE NCC Billing Procedure and Fee structure for Direct Assignment Users. Новый
"Direct Assignment User" автоматически попадает в платежную категорию Extra
Small. Оплата для этой категории составляет: 1300 евро в год ("Annual Fee") + 2000
евро единоразовый вступительный взнос ("Administration Fee"). В последующие
годы оплата будет зависеть от количества полученных ресурсов.
2.3 Выбор программного и технического обеспечения
2.3.1 Выбор программного обеспечения для маршрутизатора
В качестве программного обеспечение для маршрутизатора была выбрана

Mikrotik Router OS. MikroTik RouterOS – сетевая операционная система на базе
Linux. Данная операционная система предназначена для установки на аппаратные
маршрутизаторы Mikrotik RouterBoard. Так же данная система может быть
установлена на ПК, превращая его в маршрутизатор, предоставляющий такие
функции, как правила брандмауэра, VPN сервер и клиент, формирование
качественной пропускной способности, беспроводную точку доступа и другие
часто используемые функции маршрутизации и подключения сетей. Операционная
система лицензирована в эскалации уровней, в каждом релизе тем больше функций
RouterOS, чем больше номер уровня. Лицензирование платные и эскалируются в
соответствии с функциями релиза. Существует программное обеспечение под
названием Winbox, которое предоставляет сложный графический интерфейс для
операционной системы RouterOS. Программное обеспечение также позволяет
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
соединеняться через FTP, Telnet, и SSH. Существует также API, который позволяет
создавать специализированные приложения для управления и мониторинга.
Особенности
RouterOS поддерживает множество приложений, которые могут быть
использованы средним или крупным провайдером, например, OSPF, BGP, VPLS /
MPLS. Все в одном, RouterOS это универсальная система, и очень хорошо
поддерживается Mikrotik, как в рамках форума и предоставление различных Wiki-
материалов, так и тематических примеров конфигураций.
Программное обеспечение обеспечивает поддержку практически всех
сетевых интерфейсов на ядре Linux 2.6.16. Mikrotik также работает над
модернизацией программного обеспечения, которая обеспечит полную
совместимость между сервисами Mikrotik и новыми сетевыми разработками,
такими как IPv6.
2.3.2 Выбор программного обеспечения для сервера АСР
В качестве сервера RADIUS, необходимый для связи NAS – Billing, был

выбран FreeRADIUS версии 2.1.10.
FreeRADIUS - RADIUS сервер с открытым исходным кодом.
Это альтернатива других коммерческих RADIUS серверов, поскольку он
наиболее модульный и функциональный на сегодняшний день. Кроме того, он
входит в пятёрку RADIUS серверов мира с точки зрения развёртывания и
количества пользователей, которых этот сервер авторизует ежедневно.
Может работать на встраиваемых системах с небольшим количеством памяти,
обслуживая несколько миллионов пользователей. FreeRADIUS быстрый, гибкий,
настраиваемый, а также поддерживает больше протоколов аутентификации, чем
многие коммерческие серверы. В настоящее время FreeRADIUS используется как
основа для разработки коммерческих RADIUS серверов.
FreeRADIUS был основан в августе 1999 года Аланом ДеКоком и Микуэлом
ван Смуренбергом. Микуэл ранее написал Cistron RADIUS сервер, который
получил широкое распространение. С того момента сервер Livingston больше не
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
поддерживается. Командой FreeRADIUS было начато создание нового RADIUS-
сервера, использующего модульную конструкцию, которая будет способствовать
более активному участию сообщества.
Модули ядра сервера поддерживают LDAP, MySQL, PostgreSQL, Oracle и
многие другие базы данных. Он поддерживает все популярные типы
аутентификации EAP, включая PEAP и EAP-TTLS. Для обеспечения
совместимости с широким спектром устройств NAS в него включены более 100
словарей поставщиков.
В версии 2.0.0 была добавлена поддержка Виртуального хостинга, IPv6,
VMPS, и новой языковой политики, что упрощает многие сложные конфигурации.
Исследование, проведенное в 2006 году, показало, что количество его
пользователей составляет 100 миллионов человек.
2.3.3 Выбор аппаратного обеспечения для маршрутизатора
В качестве маршрутизатора был выбран сервер HP Proliant DL360 G4p 3.4

Bundle(Рисунок 2.12)
Рисунок 2.12 – HP Proliant DL360 G4p 3.4 Bundle

В комплект входит:
− Шасси с двумя блоками питания (G4p);
− 2 процессора Intel Xeon 3.4;
− 4GB PC2-3200 ECC DRAM;
− 2x73GB HDD SCSI U320;
− В комплект не входит Rail Kit.
Технические характеристики HP DL360 G4:
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
− До 2-х процессоров серии Intel Xeon с тактовой частотой 3.0 - 3.6ГГц;
− Системная шина FSB 800 МГц;
− Набор микросхем Intel® E7520;
− Память до 16 Гб PC3200 DDR SDRAM;
− 2 слота PCI Express;
− Контроллер жестких дисков Smart Array 6i Controller;
− Два встроенных многофункциональных гигабитных сетевых адаптера
NC7782;
− Видеоконтроллер встроенный (ATI RAGE XL Video Controller with 8-MB);
− 2 отсеков для дисков малого форм-фактора (SFF) с возможностью горячей
замены для поддержки накопителей SCSI;
− Порты ввода/вывода. Последовательный – 1; мышь – 1; графический – 1;
клавиатура – 1; VGA – 1; Сетевой разъём RJ-45 – 2; порт дистанционного управления
iLO – 1; порты USB – 3 (1 спереди, 1 сзади, 1 внутри);
− Корпус для установки в стойку 1U;
− Функции питания. Дополнительно приобретаемый блок питания 460 Вт
(избыточность 1 к 1).
RADIUS (англ. Remote Authentication in Dial-In User Service) — протокол

AAA (Authentication, Authorization и Accounting), разработанный для передачи
сведений между центральной платформой AAA и оборудованием Dial-Up/VPN
доступа (NAS, Network Access Server) и системой биллинга (то есть, системой
тарификации использованных ресурсов конкретным абонентом/пользователем).
Вызов-ответ (англ. Challenge-response authentication) — способ
аутентификации, при котором секрет (в данном случае пароль) не передаётся по
каналу связи.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Простейший способ такой аутентификации (при хранении паролей в
открытом виде):
− Клиент, желающий пройти аутентификацию, дает запрос на начало сеанса
связи, в ответ на это вызываемая сторона (сервер) посылает произвольную, но
всякий раз разную информацию (например, текущие дату и время) клиенту;
− Клиент дописывает к полученному запросу пароль и от этой строки
вычисляет какой-либо хэш (например, MD5) и отправляет его серверу;
Сервер проделывает с посланным значением аналогичные действия и
сравнивает результат. Если значения хэшей совпадают, то авторизация считается
успешной.
Базовая трансляция сетевых адресов или Basic NAT представляет собой метод
отображения адресов IP из одной группы в другую, прозрачного для конечных
пользователей. Трансляция сетевых адресов и номеров портов или NAPT - метод, с
помощью которого множество сетевых адресов и соответствующих портов
TCP/UDP (Transmission Control Protocol/User Datagram Protocol) преобразуется в
один сетевой адрес и номер порта TCP/UDP. Оба метода вместе называют
традиционной трансляцией адресов (traditional NAT). NAT обеспечивает механизм
подключения областей с приватными адресами к внешним областям, в которых
используются уникальные в глобальном масштабе зарегистрированные адреса.
Необходимость преобразования (трансляции) адресов IP возникает в тех
случаях, когда используемые внутри сети адреса IP невозможно использовать за
пределами сети из соображений сохранения тайны или по той причине, что эти
адреса корректны только внутри сети.
BGP (англ. Border Gateway Protocol, протокол граничного шлюза) —
основной протокол динамической маршрутизации в Интернете.
BGP, в отличие от других протоколов динамической маршрутизации,
предназначен для обмена информацией о маршрутах не между отдельными
маршрутизаторами, а между целыми автономными системами, и поэтому, помимо
информации о маршрутах в сети, переносит также информацию о маршрутах на
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
автономные системы. BGP не использует технические метрики, а осуществляет
выбор наилучшего маршрута исходя из правил, принятых в сети.
MikroTik RouterOS – сетевая операционная система на базе Linux. Данная
операционная система предназначена для установки на аппаратные
маршрутизаторы Mikrotik RouterBoard. Так же данная система может быть
установлена на ПК, превращая его в маршрутизатор, предоставляющий такие
функции, как правила брандмауэра, VPN сервер и клиент, формирование
качественной пропускной способности, беспроводную точку доступа и другие
часто используемые функции маршрутизации и подключения сетей. Операционная
система лицензирована в эскалации уровней, в каждом релизе тем больше функций
RouterOS, чем больше номер уровня. Лицензирование платные и эскалируются в
соответствии с функциями релиза. Существует программное обеспечение под
названием Winbox, которое предоставляет сложный графический интерфейс для
операционной системы RouterOS. Программное обеспечение также позволяет
соединеняться через FTP, Telnet, и SSH. Существует также API, который позволяет
создавать специализированные приложения для управления и мониторинга.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
3 ВНЕДРЕНИЕ СПРОЕКТИРОВАННОЙ СТРУКТУРЫ
3.1 Подготовительные работы
3.1.1 Закупка программного обеспечения
Покупку программного обеспечения, а именно Mikrotik RouterOS, произведем

у компании Mикрокомп(http://www.mikc.ru), которая является сертифицированным
дистрибъютером MikroTik и Routerboard в России. Для начала необходимо
определится с выбором уровня лицензии, для этого рассмотрим таблицы 3.1 и 3.2.
Таблица 3.1 – Уровни лицензии Mikrotik RouterOS
0
Уровень 1 3 4 5 6
Свободны
лицензии Демо WISP CPE WISP WISP Контроллер
й
не
Обновление до - ROS v5.x ROS v5.x ROS v6.x ROS v6.x
обновляется
Тех. поддержка
при первонач-й - - - 15 дней 30 дней 30 дней
настройке
Беспроводная лимит
- - да да да
точка доступа 24 часа
Беспроводной лимит
да да да да да
клиент, бридж 24 часа
Протоколы
маршрутизации лимит
да да да да да
RIP, OSPF, 24 часа
BGP
лимит не не не
EoIP туннели 1 1
24 часа ограничено ограничено ограничено
лимит не
PPPoE туннели 1 1 200 500
24 часа ограничено
лимит не не
PPTP туннели 1 1 200
24 часа ограничено ограничено
L2TP туннели 1 1 200
OVPN туннели 1 1 200
VLAN лимит не не не
1 1
интерфейсы 24 часа ограничено ограничено ограничено
Правила
лимит не не не
брандмауэра 1 1
24 часа ограничено ограничено ограничено
P2P
лимит не не не не
NAT правила 1
24 часа ограничено ограничено ограничено ограничено
Активных
лимит не
пользователей 1 1 200 500
Хот-Спот
лимит
Radius клиент - да да да да
24 часа
лимит 24 не не не не
Queues 1
часа ограничено ограничено ограничено ограничено
лимит
Веб-прокси - да да да да
24 часа
Активных
лимит не
сессий в User 1 10 20 50
Manager
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Таблица 3.2 – Стоимость лицензий Mikrotik RouterOS
Лицензия MikroTik SW/L3 WISP AP (Level 3) 845 рублей

Попробовать RouterOS можем в любой момент, зайдя на сайт

www.mikrotik.com и загрузив инсталляционный образ CD. Условно бесплатная
программа обеспечивает работу всего функционала без ограничений в течение 24
часов. После инсталляции условно-бесплатной версии RouterOS на PC, для
продолжения ее использования, нужно будет купить лицензионный ключ. Есть
четыре доступных типа лицензионных ключей RouterOS, в таблице они обозначены
как "Уровень лицензии". Самый низкий уровень 3, у него есть функциональная
возможность беспроводного клиента и ограниченное число активных
пользователей. Самый высокий – уровень 6, у него нет никаких ограничений.
Независимо от выбранного уровня, лицензия RouterOS позволяет
использовать неограниченное количество интерфейсов и включает в себя
лимитированную тех. поддержку по email. Лицензия RouterOS позволяет
устанавливать любые обновления, выпускаемые MikroTik, в пределах ограничения
выбранного уровня лицензии. Возможно продолжение использования RouterOS на
том финальном выпуске версии, который был приобретен – лицензия RouterOS
никогда не истекает.
Важно отметить, что каждая лицензия связана с носителем, на который она
установлена. Это означает, что для каждого маршрутизатора требуется отдельный
ключ лицензии.
Сравнив необходимый функционал и стоимость, останавливаемся на 5-ом
уровне лицензии (Level 5), как на достаточном. После совершения оплаты, по
электронной почте получаем уникальный ключ, который необходимо ввести после
установки ОС.
3.1.2 Закупка аппаратного обеспечения
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
В качестве маршрутизатора был выбран сервер HP Proliant DL360 G4p 3.4
Bundle, в комплект которого входит:
− Шасси с двумя блоками питания (G4p);
− 2 процессора Intel Xeon 3.4;
− 4GB PC2-3200 ECC DRAM;
− 2x73GB HDD SCSI U320.
Было принято решение приобретать его в интернет-магазине shop.NAG.ru
(ООО «НАГ»), его цена составляет 19 874 рублей. Доставка из Екатеринбурга
осуществляется любой удобной транспортной компанией в течение недели после
оплаты.
3.1.3 регистрация автономной системы и блока адресов в RIPE
Для проведения процедуры регистрации и получения блока адресов и

автономной системы был выбран ресурс www.tanhost.ru.
Для регистрации PI (провайдеро-независимых адресов) или AS (автономной
системы) необходимо прислать заявку в произвольной форме в которой
обязательно должны указать следующую информацию:
1) Форма собственности и полное название компании / организации;
2) Адреса компании / организации (юридический, физический и почтовый
адреса);
3) Банковские реквизиты, вид налогообложения, ФИО руководителя;
4) Контактные данные компании (телефон, email, факс и адрес веб-сайта);
5) Сканированную копию свидетельства о государственной регистрации
компании / организации;
6) Контактные данные административного контакта (адрес, телефон, ФИО, e-
mail) и технического контакта, которые будут вписаны в получаемые объекты. Это
может быть одно и то же лицо. Если у административного и технического контакта
уже есть RIPE-handle, сообщить его;
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
7) Описание сети в свободной форме, желательно с планом развития на два
года, а такаже приложите список используемого в сети сетевого оборудования (вид
оборудование, тип-производитель-модель, например, Router-Cisco-7301);
8) Опишите карту использования адресного пространства (краткое описание
как и куда планируется использовать IP адреса, например dialup - 64 IP адреса,
домашняя сеть - 256 IP адресов и т.д.);
9) Укажите е-mail адреса и номера автономных систем не менее двух партнеров
(Интернет-провайдеров), с которыми планируется строить BGP-взаимодействие. Эти
данные понадобятся для получения AS (автономной системы).
Получив предварительную информацию, фирма оформит заявку на
регистрацию ресурсов и отправит её в RIPE NCC и/или ARIN. Стоимость услуг по
регистрации PI блока /23 (512 адресов) и автономной системы (AS) составляет –
15 168 рублей, ежегодная поддержка – 8 000 рублей. В стоимость услуги включена
поддержка регистрации ресурсов в течение 1 года после регистрации, то есть
первый ежегодный платеж оплачивается через год после регистрации.
По итогам был получен блок адресов: 195.191.242.0/23; и автономная система
с номером 50714.
3.2 Разработка конфигурационных файлов маршрутизатора
3.2.1 Разработка конфигурации для взаимодействия по протоколу

RADIUS-сервера
Начнем с настройки radius-клиента:

/radius add address=192.168.1.200 secret=radsecret service=ppp
здесь указываем, что адресом RADIUS-сервера является 192.168.1.200,
секретным ключом является radsecret, сервис, который будет производить
аутентификацию – ppp.
/radius incoming set accept=yes port=1700
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Этой командой разрешаем входящие соединения от RADIUS-сервера на 1700
порту.
Теперь необходимо настроить ppp-сервис:
/ppp aaa set accounting=yes use-radius=yes interim-update=300
/ppp profile set default local-address=195.191.242.1
Первой командой разрешаем аккаунтинг с помощью RADIUS, интервал
обновления выставляем 300 секунд. Второй редактируем профиль по умолчанию –
default, и назначаем адрес сервера, который будет назначаться для ppp-туннелей, а
именно 195.191.242.1
И наконец запустим службу PPPoE:
/interface pppoe-server server add interface=ether1 \
service-name=swn authentication=chap
указываем, что принимать запросы необходимо на интерфейсе ether1, имя
сервиса назначаем swn, тип аутентификации chap (символ «\» в конце первой
строки означает продолжение команды на следующую строку).
/add action=change-mss chain=forward new-mss=1440 \
protocol=tcp src-address=195.191.242.0/23 tcp-flags=syn
/add action=change-mss chain=forward \
dst-address=195.191.242.0/23 new-mss=1440 protocol=tcp tcp-flags=syn
эти две команды необходимы для корректировки MSS (maximum segment size
- максимальный размер сегмента TCP), значение 1440 установлено потому что
размер MTU у нас составляет 1480 байт, и необходимо указывать на 40 байт
меньше.
3.2.2 Разработка конфигурации для протокола BGP
Сперва настроим глобальный процесс BGP:

/routing bgp instance
set default as=50714 client-to-client-reflection=yes disabled=no \
ignore-as-path-len=yes name=default out-filter="" \
redistribute-connected=no redistribute-ospf=no \
redistribute-other-bgp=no redistribute-rip=no \
redistribute-static=no router-id=195.191.242.1 routing-table=""
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Добавим свою сеть в список анонсируемых нами сетей вышестоящим
провайдерам:
/routing bgp network add network=195.191.242.0/23 synchronize=no
Теперь необходимо добавить bgp-партнеров:
/routing bgp peer
add address-families=ip as-override=no default-originate=never \
disabled=no hold-time=3m in-filter=isp1-in instance=default \
multihop=no name=isp1 nexthop-choice=default out-filter=\
isp1-out passive=no remote-address=195.22.193.166 remote-as=\
49531 remove-private-as=no route-reflect=no tcp-md5-key="" ttl=\
default use-bfd=no
add address-families=ip as-override=no default-originate=never \
disabled=no hold-time=3m in-filter=isp2-in instance=default \
multihop=no name=isp2 nexthop-choice=propagate out-filter=\
isp2-out passive=no remote-address=194.95.246.117 remote-as=\
48326 remove-private-as=no route-reflect=no tcp-md5-key="" ttl=\
default use-bfd=no
Теперь необходимо настроить фильтры, выход разрешен только для нашей
сети, если Mikrotik попытается отправить другие сети, фильтр этого сделать не
позволит:
/router filter
add action=accept chain=isp1-out disabled=no invert-match=no \
prefix=195.191.242.0/23 prefix-length=23
add action=discard chain=isp1-out disabled=no invert-match=no \
prefix=0.0.0.0/0 prefix-length=1-32
первым правилом разрешаем отдавать нашу сеть, а вторым – запрещаем
отдавать остальные. Тоже самое делаем и для второго провайдера:
/router filter
add action=accept chain=isp2-out disabled=no invert-match=no \
prefix=195.191.242.0/23 prefix-length=23
add action=discard chain=isp2-out disabled=no invert-match=no \
prefix=0.0.0.0/0 prefix-length=1-3
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
После успешного соединения с операторами-партнерами мы увидим, что от
каждого из них получили примерно по 355000 маршрутов, теперь маршрутизатор
знает как добраться до каждого уголка Интернета.
3.3 Разработка конфигурационных файлов сервера с АСР
На сервере АСР нам достаточно настроить сервер FreeRADIUS. В

/etc/freeradius/radiusd.conf в секции modules описываем секции:
billing_preauth
exec billing_preauth {
program = "/billing/libexec/rauth.pl pre_auth"
wait = yes
input_pairs = request
shell_escape = yes
#output = no
output_pairs = config
}
billing_postauth
exec billing_postauth {
program = "/billing/libexec/rauth.pl post_auth"
wait = yes
shell_escape = yes
#output = no
output_pairs = config
}
billing_auth
exec billing_auth {
program = "/billing/libexec/rauth.pl"
wait = yes
shell_escape = yes
output = no
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
output_pairs = reply
}
billing_acc
exec billing_acc {
program = "/billing/libexec/racct.pl"
wait = yes
shell_escape = yes
output = no
}
в секции exec:
exec {
wait = yes
shell_escape = yes
output = none
}
Файл /etc/freeradius/sites-enable/default - правим секции authorize, preacct, post-
auth. Остальное в этих секциях ремарим.
authorize {
preprocess
abills_preauth
mschap
files
abills_auth
}
preacct {
preprocess
abills_acc
}
post-auth {
Post-Auth-Type REJECT {
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
abills_postauth
}
}
в файле /etc/freeradius/users
DEFAULT Auth-Type = Accept
в файле /etc/freeradius/clients.conf прописываем адрес нашего Mikrotik`a
client 192.168.1.1 {
secret = radsecret
shortname = mikrotik
nastype = other
}
На этом настройка завершена теперь можно запустить сервер командой
#: /etc/init.d/freeradius start
3.4 Настройка клиентов
Настройка подключения для выхода в интернет для Windows 7

1 – левой кнопкой мыши кликаем на ярлычёк около часов
2 – левой кнопкой мыши на ссылку «Центр управления сетями и общим
доступом»
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Рисунок 3.1 – Настройка клиентского компьютера(1)
3 – левой кнопкой мыши кликаем на ссылку «Настройка нового подключения
или сети»
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Если у Вас уже были ранее созданные подключения, то может быть выведено
следующее окно, его мы пропускаем и кликаем левой кнопкой мыши на кнопку
«Далее»

4 – левой кнопкой мыши кликаем на ссылку «Подключение к Интернету»
5 – левой кнопкой мыши кликаем на кнопку «Далее»

6 – левой кнопкой мыши кликаем на ссылку «Высокоскоростное (с РРPоЕ)»
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
7 – в поле «Имя пользователя» вводим логин данный Нам при подключении
8 – в поле пароль необходимо ввести пароль данный Нам при подключении
Найти Логин/пароль можно в бумажном виде в Приложении
№3/Техническое приложение.
Важно! При вводе пароля учитывайте БОЛЬШИЕ маленькие буквы!
9 – в поле «Имя пользователя» вводим «Подключение интернет SWNet»
10 – левой кнопкой мыши кликаем на кнопку «Подключить»
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
13 – левой кнопкой мыши кликаем на ярлычёк около часов
14 – левой кнопкой мыши на ссылку «Подключение интернет SWNet», далее
появится кнопка
«Подключение»
15 – левой кнопкой мыши на кнопку «Подключение»
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
16 – Проверьте, в области Пользователь/пароль, в данных полях должный
быть сохранены Ваш логин/пароль.
17 – левой кнопкой мыши на кнопку «Подключение»
Покупку программного обеспечения, а именно Mikrotik RouterOS, произведем

у компании Mикрокомп(http://www.mikc.ru), которая является сертифицированным
дистрибъютером MikroTik и Routerboard в России.
Независимо от выбранного уровня, лицензия RouterOS позволяет
использовать неограниченное количество интерфейсов и включает в себя
лимитированную тех. поддержку по email. Лицензия RouterOS позволяет
устанавливать любые обновления, выпускаемые MikroTik, в пределах ограничения
выбранного уровня лицензии. Возможно продолжение использования RouterOS на
том финальном выпуске версии, который был приобретен – лицензия RouterOS
никогда не истекает.
Для регистрации PI (провайдеро-независимых адресов) или AS (автономной
системы) необходимо прислать заявку в произвольной форме. Получив
предварительную информацию, фирма оформит заявку на регистрацию ресурсов и
отправит её в RIPE NCC и/или ARIN. Стоимость услуг по регистрации PI блока /23
(512 адресов) и автономной системы (AS) составляет – 15 168 рублей, ежегодная
поддержка – 8 000 рублей. В стоимость услуги включена поддержка регистрации
ресурсов в течение 1 года после регистрации, то есть первый ежегодный платеж
оплачивается через год после регистрации. По итогам был получен блок адресов:
195.191.242.0/23; и автономная система с номером 50714.
После успешного соединения с операторами-партнерами мы увидим, что от
каждого из них получили примерно по 355000 маршрутов, теперь маршрутизатор
знает как добраться до каждого уголка Интернета.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
4 ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ
4.1 Постановка задачи
Для любой компании необходим рост не только за счет роста рынка, но и за

счет увеличения доли участия на рынке. Важной составляющей, необходимой для
роста, является качество предоставляемых услуг. Целью дипломного проекта
является увеличение качества услуг, предоставляемых предприятием ООО «СКС».
Известно, что текущая конфигурация центрального узла связи компании
работает на уровне близком к пику своих возможностей, поэтому необходимость
модернизации является актуальным вопросом. В дипломном проекте описаны шаги
к решению данного вопроса. Одним из таких шагов, и первой задачей, является
разделение функций одного сервера на сервер АСР и маршрутизатор NAS. Это
увеличит качество услуг для текущей емкости абонентской базы, а также даст
возможность для увеличения этой емкости, что в свою очередь даст возможность
роста компании в целом.
Одним из составляющих качества услуг связи является способ абонентского
доступа. Наиболее популярными способами доступа среди как ведущих, так и
малых операторов ШПД являются PPTP, L2TP, PPPoE и PrivateVLAN. У
протоколов PPTP и L2TP существует один важный недостаток – это необходимость
корректной конфигурации IP-адресации у абонентов, практика компании показала,
что настройки часто сбиваются по тем или иным причинам, что увеличивает
нагрузку на службу поддержки и приводит к появлению недовольства
пользователей. Способ доступа, именуемый как PrivateVLAN технически сложен
для реализации, для его внедрения необходима поддержка со стороны
оборудования «последней мили». Самым оптимальным вариантом оказался PPPoE,
он не имеет недостатков PPTP и L2TP, для его внедрения не нужно
дополнительных затрат на дорогостоящее оборудование как в случае с
PrivateVLAN. Второй задачей дипломного проекта является внедрение PPPoE.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
И последней, третей задачей дипломного проекта является устранение
системы трансляции адресов NAT с заменой на внешние адреса и полноценную
маршрутизацию Интернета BGP-4.
Ориентировочно конфигурация узла связи может эксплуатироваться в
течение двух лет.
4.2 Оценка стоимости внедрения проекта
Сметная стоимость включает следующие составляющие:

− заработную плату научных работников;
− затраты на электроэнергию;
− затраты на комплектующие изделия и расходные материалы;
− отчисления в фонд внебюджетного страхования;
− накладные расходы.
Основная заработная плата специалистов, проводящих ОКР, определяется с
учетом количества инженерно-технических работников, их квалификации,
трудоемкости работ и часовых тарифных ставок исполнителей.
Таблица 4.1 – Основная заработная плата специалистов
N п/п Этапы Исполнители Часовая Трудоемкость Заработная
разработки тарифная работ, ч плата, руб
ставка,
руб/ч
1 Разработка Системный 40 8 000
проекта администратор 200
2 Настройка Системный
оборудования администратор 200
60 12 000
Итого заработная плата: 20 000
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Основная заработная плата определяется по формуле:
З о = Ti S чi (4.1)
где Ti – трудоемкость i-го вида работ, ч;
S чi – часовая тарифная ставка исполнителя при выполнении i-го вида работ.
З о1 =T1 S ч1 З о1 = 40 ⋅ 200 = 8000 руб ,
З о 2 = T2 S ч2 З о 2 = 60 ⋅ 200 = 12000 руб ,
З о = Ti S чi = 8000 + 12000 = 20000 руб
Дополнительная заработная плата определяется следующим образом:

Зд = Зо k − Зо
(4.2)
З д = З о k = (8000 + 12000 ) ⋅ 1,1 − 20000 = 22000 − 20000 = 2000 руб.
Для основной группы налогоплательщиков установлены следующие тарифы:
− Пенсионный фонд Российской Федерации - 26%
− Фонд социального страхования Российской Федерации - 2,9%
− Федеральный фонд обязательного медицинского страхования - 2,1%
− Территориальные фонды обязательного медицинского страхования - 3%.
Таким образом, в общая сумма страховых взносов составит 34 процента,
вместо 26 процентов по ЕСН, как было ранее (без учета регрессии). r = 34%:
Зо + З д
Rвн = r
100 , (4.3)
20000 + 2000 22000 ⋅ 34

Rвн = 34 % = = 7480 руб
100 100
Аналогичным образом определяются накладные расходы, учитывающие

затраты на управление и хозяйственное обслуживание проводимых работ.
Зо + З д
Н= µ
100 (4.4)
20000 + 2000 22000 ⋅ 20

Н= ⋅ 20% = = 4400 руб
100 100
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Расчеты затрат на электроэнергию выполняется с учетом потребляемой
мощности отдельных электроприемников Рg (кВт), длительности эксплуатации
оборудования при проведении ОКР tg (ч) и тарифа на электроэнергию Цэ
(руб./кВтч).
G
З э = ∑ Pg t g Ц э
g =1 (4.5)
З э = Pg t g Ц э =17520 ⋅ 2,82 ⋅ 0,5 = 49406 ,4 ⋅1,41 = 24703 ,2 руб
Зэ – затраты на электроэнергию в течение 2 лет
Таблица 4.2 – Расчёт затрат на электроэнергию в течение 2 лет
Наименование Длительность Потребляемая Время Тариф, Стоимость,

прибора эксплуатации мощность, работы, руб/кВтч руб
кВт ч
Сервер HP 2 года 17 520 0,5кВт 24 2,82 24 703,2
Proliant DL360 ч
G4p 3.4 Bundle
Итого за электроэнергию за 2 года 24 703,2
Данные по ценам на эти материалы формируются в основном на договорной
основе и обговариваются на подготовительном этапе. В таблице 4.3 приведен
расчет затрат на основные и вспомогательные материалы, используемые в работе.
Источником цен является официальные прайс-листы производителей
оборудования.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Таблица 4.3 – Затраты на комплектующие изделия
Наименование Тип, марка Количе Цена за 1 Стоимость,
изделия ство, ед. руб. руб.
шт.
HP Proliant DL360 G4p 1

Сервер 19 874 19 874
3.4 Bundle
Программное Mikrotik RouterOS 1

2 000 2 000
обеспечение
Регистрация PI блока / 1
Услуги 23 и автономной 15 168 15 168
системы AS
Итого затрат на комплектующие изделия: 37 042
Таблица 4.4 – Затраты на материалы

Единица Цена Стоимость,
Кол-
Наименование материала единиц руб
измерения во
ы
Пэтч-корд шт 1 50 50
Шнур питания шт 2 60 120
Итого затрат на материалы: 170
Суммарные затраты на комплектующие изделия можно определить по
формуле (4.6):
К
C k = ∑l k Z k
(4.6)
k =1
C k = 19874 + 2000 + 15168 = 37042 руб
Где Ck – суммарные затраты на комплектующие изделия, lk – количество

комплектующего изделия k-го типа; Zk – цена единицы k-го изделия.
Суммарные затраты на материалы можно определить по формуле:
J
С м = ∑Pj f j ; (4.7)
j =1
С м = 50 + (2 ⋅ 60 ) = 170 руб
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
где См – суммарные затраты на материалы, Pj – норма расхода j-го
материала; f j – цена единицы материала.
Общие затраты на создание локальной вычислительной сети
определяется путем суммирования отдельных составляющих:
S НИОКР = З о + З д + З э + Rвн + Н + (С м + С к ) k тр , (4.8)
S НИОКР = 20000 + 2000 + 24703 ,2 + 7480 + 4400 + (170 + 37042 )1,05 = 97655 ,8 руб
где k тр – коэффициент транспортно-заготовительных расходов (обычно

принимаются в размере 1,05).
4.3 Окупаемость проекта
С внедрением данного проекта предприятие сможет наращивать абонентскую

базу на своих кабельных сетях со скоростью 30 абон./мес. Чистая прибыль
составляет 60 руб. с каждого абонента, предполагаемый рост доходов отражен в
таблице 4.5.
Таблица 4.5 – Рост доходов
Месяц Увеличение доходов, руб.
Июль `11 1800
Август `11 3600
Сентябрь `11 5400
Октябрь `11 7200
Ноябрь `11 9000
Декабрь `11 10800
Январь `12 12600
Февраль `12 14400
Март `12 16200
Апрель `12 18000
Итого: 99000
Из таблицы 4.5 видно, что данный проект окупится через 10 месяцев после
внедрения.
4.4 Вывод по разделу
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Реализация данного проекта позволит:
1) Повысить качество связи;
2) Повысить комфортность абонентов;
3) Увеличить максимальную емкость абонентской базы;
4) Увеличить масштабируемость узла связи.
С внедрением данного проекта предприятие сможет наращивать абонентскую
базу на своих кабельных сетях со скоростью 30 абон./мес.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
5 ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ЖИЗНЕДЕЯТЕЛЬНОСТИ
ПЕРСОНАЛА
Эргономические требования к рабочему месту

Проектирование рабочих мест, снабженных видеотерминалами, относится к
числу важных проблем эргономического проектирования в области
вычислительной техники.
Рабочее место и взаимное расположение всех его элементов должно
соответствовать антропометрическим, физическим и психологическим
требованиям. Большое значение имеет также характер работы. В частности, при
организации рабочего места программиста должны быть соблюдены следующие
основные условия: оптимальное размещение оборудования, входящего в состав
рабочего места и достаточное рабочее пространство, позволяющее осуществлять
все необходимые движения и перемещения.
Эргономическими аспектами проектирования видеотерминальных рабочих
мест, в частности, являются: высота рабочей поверхности, размеры пространства
для ног, требования к расположению документов на рабочем месте (наличие и
размеры подставки для документов, возможность различного размещения
документов, расстояние от глаз пользователя до экрана, документа, клавиатуры и
т.д.), характеристики рабочего кресла, требования к поверхности рабочего стола,
регулируемость элементов рабочего места [20].
Главными элементами рабочего места программиста являются стол и кресло.
Основным рабочим положением является положение сидя.
Рабочая поза сидя вызывает минимальное утомление программиста.
Рациональная планировка рабочего места предусматривает четкий порядок и
постоянство размещения предметов, средств труда и документации. То, что
требуется для выполнения работ чаще, расположено в зоне легкой досягаемости
рабочего пространства.
Моторное поле – пространство рабочего места, в котором могут
осуществляться двигательные действия человека.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Максимальная зона досягаемости рук – это часть моторного поля рабочего
места, ограниченного дугами, описываемыми максимально вытянутыми руками
при движении их в плечевом суставе.
Оптимальная зона – часть моторного поля рабочего места, ограниченного
дугами, описываемыми предплечьями при движении в локтевых суставах с опорой
в точке локтя и с относительно неподвижным плечом.
8 0 0 6 0 0 4 0 0 2 0 0 0 2 0 0 4 0 0 6 0 0 8 0 0 а - зона максимальной
8 0 0 досягаемости;
а б - зона досягаемости
пальцев при
6 0 0 вытянутой руке;
б
в - зона легкой
4 0 0 досягаемости ладони;
д г в г - оптимальное
пространство для
2 0 0 грубой ручной работы;
д - оптимальное
0 пространство для
тонкой ручной работы.
Рисунок 5.1 Зоны досягаемости рук в горизонтальной плоскости.

Оптимальное размещение предметов труда и документации в зонах
досягаемости:
ДИСПЛЕЙ размещается в зоне а (в центре);
СИСТЕМНЫЙ БЛОК размещается в предусмотренной нише стола;
КЛАВИАТУРА - в зоне г/д;
«МЫШЬ» - в зоне в справа;
СКАНЕР в зоне а/б (слева);
ПРИНТЕР находится в зоне а (справа);
ДОКУМЕНТАЦИЯ: необходимая при работе - в зоне легкой досягаемости
ладони – в, а в выдвижных ящиках стола - литература, неиспользуемая постоянно.
На рис. 5.2 показан пример размещения основных и периферийных
составляющих ПК на рабочем столе программиста.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
1 2 3
4 5 6
Рисунок 5.2 Размещение основных и периферийных составляющих ПК.

1 – сканер, 2 – монитор, 3 – принтер, 4 – поверхность рабочего стола,
5 – клавиатура, 6 – манипулятор типа «мышь».
Для комфортной работы стол должен удовлетворять следующим условиям
[20]:
− высота стола должна быть выбрана с учетом возможности сидеть свободно, в
удобной позе, при необходимости опираясь на подлокотники;
− нижняя часть стола должна быть сконструирована так, чтобы программист
мог удобно сидеть, не был вынужден поджимать ноги;
− поверхность стола должна обладать свойствами, исключающими появление
бликов в поле зрения программиста;
− конструкция стола должна предусматривать наличие выдвижных ящиков (не
менее 3 для хранения документации, листингов, канцелярских принадлежностей).
− высота рабочей поверхности рекомендуется в пределах 680-760мм. Высота
поверхности, на которую устанавливается клавиатура, должна быть около 650мм.
Большое значение придается характеристикам рабочего кресла. Так,
рекомендуемая высота сиденья над уровнем пола находится в пределах 420-550мм.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Поверхность сиденья мягкая, передний край закругленный, а угол наклона спинки
– регулируемый.
Необходимо предусматривать при проектировании возможность различного
размещения документов: сбоку от видеотерминала, между монитором и
клавиатурой и т.п. Кроме того, в случаях, когда видеотерминал имеет низкое
качество изображения, например заметны мелькания, расстояние от глаз до экрана
делают больше (около 700мм), чем расстояние от глаза до документа (300-450мм).
Вообще при высоком качестве изображения на видеотерминале расстояние от глаз
пользователя до экрана, документа и клавиатуры может быть равным.
Положение экрана определяется:
− расстоянием считывания (0,6…0,7м);
− углом считывания, направлением взгляда на 20° ниже горизонтали к
центру экрана, причем экран перпендикулярен этому
направлению.
Должна также предусматриваться возможность регулирования экрана:
− по высоте +3 см;
− по наклону от -10° до +20° относительно вертикали;
− в левом и правом направлениях.
Большое значение также придается правильной рабочей позе пользователя.
При неудобной рабочей позе могут появиться боли в мышцах, суставах и
сухожилиях. Требования к рабочей позе пользователя видеотерминала следующие:
− голова не должна быть наклонена более чем на 20°,
− плечи должны быть расслаблены,
− локти - под углом 80°…100°,
− предплечья и кисти рук - в горизонтальном положении.
Причина неправильной позы пользователей обусловлена следующими
факторами: нет хорошей подставки для документов, клавиатура находится
слишком высоко, а документы – низко, некуда положить руки и кисти,
недостаточно пространство для ног.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
В целях преодоления указанных недостатков даются общие рекомендации:
лучше передвижная клавиатура; должны быть предусмотрены специальные
приспособления для регулирования высоты стола, клавиатуры и экрана, а также
подставка для рук [20].
Существенное значение для производительной и качественной работы на
компьютере имеют размеры знаков, плотность их размещения, контраст и
соотношение яркостей символов и фона экрана. Если расстояние от глаз оператора
до экрана дисплея составляет 60…80 см, то высота знака должна быть не менее
3мм, оптимальное соотношение ширины и высоты знака составляет 3:4, а
расстояние между знаками – 15…20% их высоты. Соотношение яркости фона
экрана и символов - от 1:2 до 1:15 [21].
Во время пользования компьютером медики советуют устанавливать монитор
на расстоянии 50-60 см от глаз. Специалисты также считают, что верхняя часть
видеодисплея должна быть на уровне глаз или чуть ниже. Когда человек смотрит
прямо перед собой, его глаза открываются шире, чем когда он смотрит вниз. За
счет этого площадь обзора значительно увеличивается, вызывая обезвоживание
глаз. К тому же если экран установлен высоко, а глаза широко открыты,
нарушается функция моргания. Это значит, что глаза не закрываются полностью,
не омываются слезной жидкостью, не получают достаточного увлажнения, что
приводит к их быстрой утомляемости.
Создание благоприятных условий труда и правильное эстетическое
оформление рабочих мест на производстве имеет большое значение как для
облегчения труда, так и для повышения его привлекательности, положительно
влияющей на производительность труда.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
ЗАКЛЮЧЕНИЕ
В ходе дипломной работы были детально изучены наиболее популярные
среди операторов ШПД методы абонентского доступа такие как PPTP (Point-to-
Point Tunneling Protocol), L2TP (Layer 2 Transport Protocol) PrivateVLAN (Private
Virtual Local Area Network) и PPPoE (Point-to-Point Protocol over Ethernet),
рассмотрена система трансляции адресов NAT (Native Address Translation) и
протокол маршрутизации Интернета BGP-4 (A Border Gateway Protocol 4).
По итогам изучения был разработан план по внедрению проекта в Обществе с
ограниченной ответственностью «Ставропольские коммуникационные сети»,
поставлены задачи проекта, а именно:
− разделение функций одного физического сервера на сервер
Автоматизированной системы расчетов и маршрутизатор NAS (Network Access
Server);
− внедрение PPPoE;
− устранение системы трансляции адресов NAT с заменой на внешние адреса и
полноценную маршрутизацию Интернета BGP-4.
По поставленным задачам разработаны схемы и конфигурации как
программного, так и аппаратного обеспечения. План был принят и утвержден
руководством компании, впоследствии были выделены необходимые финансовые
средства для приобретения программного и аппаратного обеспечения.
Результатом первой задачи стала установка выделенного сервера для
маршрутизации с установкой на него специализированной операционной системы
Mikrotik RouterOS.
По итогам исполнения второй задачи был изменен протокол авторизации
пользователей и проведена настройка каждого абонентского компьютера.
Результатом третьей задачи стало приобретение блока адресов
195.191.242.0/23 и автономной система с номером 50714, а также произведено
введение их в эксплуатацию.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Спустя месяц упорной работы проект введен в эксплуатацию и на данный
момент обслуживает всех абонентов компании. Качество услуг возросло, оценкой
этому может служить отсутствие жалоб на плавающую скорость, тогда как до
реализации такие жалобы время от времени присутствовали.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ
1. Wikipedia – свободная энциклопедия. (http://ru.wikipedia.org)
2. RFC 2637 (http://tools.ietf.org/html/rfc2637)
5. Российский сайт об интернет-провайдинге Nag.ru. (http://nag.ru)
6. IEEE 802.1q (http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf)
17. Перевод RFC 3022 (http://rfc2.ru/3022.rfc)
18. Паркхерст, У.Р. Справочник по командам и настройке протокола BGP-4
маршрутизаторов Cisco. – М.: «Вильямс», 2002. – 384с.
20. Зинченко, В.П. Основы эргономики. – М.: МГУ, 1979. – 179с.
21. Безопасность жизнедеятельности. /Под ред. Н.А. Белова - М.: Знание, 2000 -
364с.
Лист
Подпис
МГУПИ 230102.12ПЗ 99
ь
Левадний А. Д. Организация абонентского доступа к сети Интернет на
предприятии ООО «Ставропольские коммуникационные сети». Дипломный
проект. – Ставрополь, 2011 г., – 99 с.
Научный руководитель: к.т.н., доцент Бережной В. В.

Рецензент:
Дипломный проект выполнен мною самостоятельно. Все использованные в

работе материалы из опубликованной литературы и других источников имеют
ссылки на них.
«_______»__________________2011 г.
Левадний Александр Дмитриевич _______________________

(подпись)
Дипломный проект сдан на кафедру «_______» июня 2011 г. и

зарегистрирован в журнале под № ___________
__________________
(подпись зав. кафедрой)
Защищён «___» июня 2011 г.
Протокол № _________ от «_____» июня 2011 г.
Оценка: __________________________________
Секретарь ГАК ____________________________

(подпись)

Диплом Левадний

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Диплом Левадний

Uploaded by

Copyright:

Available Formats

ТИТУЛЬНЫЙ ЛИСТ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

Кафедра «Автоматизированные системы управления»

_____________________ Бережной В.В.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

СТУДЕНТ __Левадний Александр Дмитриевич _____________

Дата выдачи задания _________________________________

Руководитель дипломного проекта _______________(____Бережной В. В. ___)

1ДИАГНОСТИЧЕСКИЙ АНАЛИЗ АСОИУ ПРЕДПРИЯТИЯ .................................9

1.1Анализ организационно-штатной структуры предприятия ООО «СКС»...9

2ПРОЕКТИРОВАНИЕ СТРУКТУРЫ ЧАСТИ ЯДРА СЕТИ НА ПРЕДПРИЯТИИ

2.1Разработка схемы разделения задач на два выделенных сервера..............38

3ВНЕДРЕНИЕ СПРОЕКТИРОВАННОЙ СТРУКТУРЫ..........................................71

5ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ЖИЗНЕДЕЯТЕЛЬНОСТИ ПЕРСОНАЛА..92

СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ..................................................99

3 ВНЕДРЕНИЕ СПРОЕКТИРОВАННОЙ СТРУКТУРЫ.........ERROR: REFERENCE

3.1 Подготовительные работы............................Error: Reference source not found

4 ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ..............ERROR: REFERENCE

4.1 Постановка задачи.........................................Error: Reference source not found

5 ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ЖИЗНЕДЕЯТЕЛЬНОСТИ ПЕРСОНАЛА

ЗАКЛЮЧЕНИЕ.....................................ERROR: REFERENCE SOURCE NOT FOUND

СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ. ERROR: REFERENCE SOURCE

1.1 Анализ организационно-штатной структуры предприятия ООО

1.1.1 Организационная структура управления компании

Предприятие имеет небольшой штат сотрудников – 11 человек. Для большей

Веб- Системный Оператор службы

Старший монтажник Старший монтажник

Монтажник Монтажник Монтажник Монтажник

Рисунок 1.1 – Организационная схема управления

1.1.2 Должностные обязанности сотрудников

Во главе компании находится Генеральный директор и выполняет следующие

1.2.1 Анализ решаемых задач предприятия

ООО «Ставропольские коммерческие сети» в рамках торговой марки SWNet

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

1.3 Методы организации абонентского доступа

PPTP (англ. Point-to-Point Tunneling Protocol) — туннельный протокол типа

L2TP (англ. Layer 2 Tunneling Protocol — протокол туннелирования второго

Биты 0-15 Биты 16-31

Flags and Version Info Length (опционально)

Offset Size (опционально) Offset Pad (опционально)

PPPoE (англ. Point-to-point protocol over Ethernet) — сетевой протокол

На протяжении уже довольно долгого времени одной из наиболее

Рисунок 1.2 – Архитектура с общим VLAN

Контроль локального трафика* Ограниченный Полный

Количество точек контроля

Путь локального трафика** Оптимальный Неоптимальный

Сложность реализации Ниже Выше

* Контроль трафика требуется для гибкого управления межабонентским

Рисунок 1.3 – Централизованная модель VLAN на пользователя

Контроль локального Полный Полный

Количество точек контроля Малое Малое

«Паразитный» Нет Нет

Защита от типовых атак Обеспечивается Обеспечивается

Сложность реализации Ниже Выше

Конфигурация Унифицированная Индивидуальная

Использование адресного Эффективное Неэффективное

1.4 Постановка задачи на модернизацию используемого в компании

1.4.1 Существующий метод

В настоящее время в организации используется следующая схема доступа в

Рисунок 1.6 – Существующий метод доступа

Для большего понимания системы взаимодействия и возможностей биллинга

Рисунок 1.7 – Схема взаимодействия АСР с сервисами

Как видим, на данный момент все необходимые сервисы установлены на

Сетевая карта 1 – Физический

СТУДЕНТ Левадний Александр Дмитриевич ___________

Руководитель дипломного проекта _____________(Бережной В. В. _)