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

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

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

УЧРЕЖДЕНИЯВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ»

Кафедра «Автоматизированные системы управления»Специальность 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 – Схема взаимодействия сервисов__________________________________

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

Руководитель дипломного проекта _______________(____Бережной В. В. ___) (подпись, фамилия и инициалы) Студент _______________(___ Левадний А. Д. _) (подпись, фамилия и инициалы)

Изм. Лист № докум. Подпись

Дата

Лист

МГУПИ 230102.12ПЗ

Разраб. ЛеваднийПровер. Бережной

Н. Контр.

Утверд.

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

предприятии ООО «СКС». Пояснительная записка.

Лит. Листов

Филиал МГУПИ г.Ставрополь

АСОИУ-061

АСОИУ-062

Содержание

Введение...........................................................................................................................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.1 PPTP......................................................................................................14

1.3.2 L2TP......................................................................................................16

1.3.3 PPPoE....................................................................................................19

1.3.4 PriviteVLAN.........................................................................................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

2.1.3 Детальное рассмотрение механизма авторизации пользователя....44


Дата

Лист

МГУПИ 230102.12ПЗ

Разраб. ЛеваднийПровер. Бережной

Н. Контр.

Утверд.

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

предприятии ООО «СКС». Пояснительная записка.

Лит. Листов

Филиал МГУПИ г.Ставрополь

АСОИУ-061

АСОИУ-062


Дата

Лист

99МГУПИ 230102.12ПЗ

2.2 Разработка метода устранения NAT и перехода на внешнюю адресацию

Интернета ................................................................................................................ 47

2.2.1 Детальное рассмотрение системы NAT ............................................... 47

2.2.2 Детальное рассмотрение протокола маршрутизации BGP ................ 55

2.2.3 Разработка плана по внедрению ........................................................... 64

2.3 Выбор программного и технического обеспечения ...................................... 65

2.3.1 Выбор программного обеспечения для маршрутизатора .................. 65

2.3.2 Выбор программного обеспечения для сервера АСР ......................... 66

2.3.3 Выбор аппаратного обеспечения для маршрутизатора ...................... 67

2.4 Выводы по разделу ........................................................................................... 68

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

3.1 Подготовительные работы .............................................................................. 71

3.1.1 Закупка программного обеспечения .................................................... 71

3.1.2 Закупка аппаратного обеспечения ....................................................... 73

3.1.3 регистрация автономной системы и блока адресов в RIPE ............... 73

3.2 Разработка конфигурационных файлов маршрутизатора ............................ 74

3.2.1 Разработка конфигурации для взаимодействия по протоколу

RADIUS-сервера ............................................................................................. 74

3.2.2 Разработка конфигурации для протокола BGP ................................... 75

3.3 Разработка конфигурационных файлов сервера с АСР ................................ 77

3.4 Настройка клиентов ......................................................................................... 79

3.5 Выводы по разделу ........................................................................................... 84

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

4.1 Постановка задачи ............................................................................................ 85

4.2 Оценка стоимости внедрения проекта ........................................................... 86

4.3 Окупаемость проекта ....................................................................................... 90

4.4 Вывод по разделу ............................................................................................. 91

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


Дата

Лист

99МГУПИ 230102.12ПЗ

ЗАКЛЮЧЕНИЕ ................................................................................................................ 97

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


Дата

Лист

99МГУПИ 230102.12ПЗ

ВВЕДЕНИЕ

Рынок телекоммуникационных услуг, предоставляемых на базе технологии

широкополосного доступа, на текущий момент находится в стадии активного

роста. Проникновение в России выросло на 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-процентным потенциалом роста до прогнозной цены, равной


Дата

Лист

99МГУПИ 230102.12ПЗ

34 долл./АДР, а по прогнозу EV/EBITDA оценены на уровне 4.2. МТС является

фаворитом в секторе.

Для любой компании необходим рост не только за счет роста рынка, но и за

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

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

является увеличение качества услуг, предоставляемых предприятием ООО «СКС».

Известно, что текущая конфигурация центрального узла связи компании

работает на уровне близком к пику своих возможностей, поэтому необходимость

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

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

разделение функций одного физического сервера на сервер АСР и маршрутизатор

NAS. Это увеличит качество услуг для текущей емкости абонентской базы, а также

даст возможность для увеличения этой емкости, что в свою очередь даст

возможность роста компании в целом.

Одним из составляющих качества услуг связи является способ абонентского

доступа. Наиболее популярными способами доступа среди как ведущих, так и

малых операторов ШПД являются PPTP, L2TP, PPPoE и PrivateVLAN. У

протоколов PPTP и L2TP существует один важный недостаток – это необходимость

корректной конфигурации IP-адресации у абонентов, практика компании показала,

что настройки часто сбиваются по тем или иным причинам, что увеличивает

нагрузку на службу поддержки и приводит к появлению недовольства

пользователей. Способ доступа, именуемый как PrivateVLAN технически сложен

для реализации, для его внедрения необходима поддержка со стороны

оборудования «последней мили». Самым оптимальным вариантом оказался PPPoE,

он не имеет недостатков PPTP и L2TP, для его внедрения не нужно

дополнительных затрат на дорогостоящее оборудование как в случае с

PrivateVLAN. Второй задачей дипломного проекта является внедрение PPPoE.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

системы трансляции адресов NAT с заменой на внешние адреса и полноценную

маршрутизацию Интернета BGP-4.

В первом разделе дипломного проекта рассматривается организационная

структура предприятия, основные программные и аппаратные средства, а также

схемы их взаимодействия. Во втором разделе – осуществляется планирование

решений и детально изучается теоретический материал, необходимый для

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

непосредственно внедрению проекта, а именно закупке необходимых компонентов,

разработке конфигураций и настройке клиентов. В четвертом разделе

рассчитывается экономический эффект от внедрения проекта. Пятый раздел

посвящен обеспечению безопасности жизнедеятельности персонала, а именно

эргономическим требованиям к рабочему месту. И в заключении подведены итоги

проделанной работы.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

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

«СКС»

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

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

наглядности структуры предприятия, она схематически изображена на рисунке 1.1.

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

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

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

функции:

организует всю работу предприятия;

Генеральный директор

Главный бухгалтер

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

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

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

Веб-разработчик


Дата

Лист

99МГУПИ 230102.12ПЗ

несет полную ответственность за его состояние и состояние трудового

коллектива;

представляет предприятие во всех учреждениях и организациях;

распоряжается имуществом предприятия;

заключает договора;

поиск поставщиков материала;

сбыт продукции (т.е. поиск клиентов);

издает приказы по предприятию в соответствии с трудовым

законодательством, принимает и увольняет работников;

применяет меры поощрения и налагает взыскания на работников

предприятия;

открывает в банках счета предприятия.

Главный бухгалтер:

руководит работой по планированию и экономическому стимулированию на

предприятии, повышению производительности труда, выявлению и использованию

производственных резервов улучшению организации производства, труда и

заработной платы;

разрабатывает нормативы для образования фондов экономического

стимулирования;

проводит всесторонний анализ результатов деятельности предприятия;

разрабатывает мероприятия по снижению себестоимости и повышению

рентабельности предприятия, улучшению использования производственных фондов,

выявлению и использованию резервов на предприятии;

осуществляет учет средств предприятия и хозяйственных операций с

материальными и денежными ресурсами ;

устанавливает результаты финансово-хозяйственной деятельности


производит финансовые расчеты с заказчиками и поставщиками, связанные с

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


Дата

Лист

99МГУПИ 230102.12ПЗ

также получение кредитов в банке, своевременный возврат ссуд, взаимоотношение с

государственным бюджетом.

Основными обязанностями системного администратора являются:

обновление и настройка биллинговой системы;

настройка и сопровождение коммутаторов и маршрутизаторов сети

оператора;

обслуживание ядра сети;

подготовка и сохранение резервных копий данных, их периодическая

проверка и уничтожение;

установка и конфигурирование необходимых обновлений для операционной

системы и используемых программ;

установка и конфигурирование нового аппаратного и программного

обеспечения;

создание и поддержание в актуальном состоянии пользовательских учётных

записей;

ответственность за информационную безопасность в компании;

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

планирование и проведение работ по расширению сетевой структуры


решение сложных технических проблем пользователей.

Обязанности веб-разработчика:

администрирование сайта компании;

разработка веб-сервисов для личного кабинета абонента;

веб-дизайн.

Обязанности оператора технической поддержки:

прием звонков абонентов;

прием заказов на подключение;

помощь в решении проблем пользователей;

назначение монтажника для выезда к пользователю на дом;


Дата

Лист

99МГУПИ 230102.12ПЗ

ведение табеля подключений.

Обязанности старшего монтажника:

подключение новых пользователей;

монтаж кабельных систем;

монтаж узлов и оборудования;

управление своей группой монтажников.

Обязанности монтажника:

подключение новых пользователей;

монтаж кабельных систем;

монтаж узлов и оборудования;

выезд на дом к пользователю для устранения неполадок.

1.2 Анализ задач, решаемых ООО «СКС»

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

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

предоставляет услуги широкополосного доступа в Интернет на основе технологии

ETTH ( Ethernet To The Home).

Компания основа в 2008 году и на данный момент предоставляет услуги

более 400-ам абонентам.

В качестве дополнительного бесплатного сервиса компания предоставляет

доступ к городской файлообменной сети основанной на технологи Direct

Connection, а также доступ к игровым серверам.

Для оплаты услуг компания сотрудничает с большинством из известных

платежных систем, такими как:

RosExpress;

Comepay;

QIWI;

Rapida;

Сбербанк РФ.


Дата

Лист

99МГУПИ 230102.12ПЗ

Основными задачами компании являются:

Построение сети передачи данных;

Подключение клиента к сети;

Техническая поддержка и сопровождение клиента во время пользования

услугой;

Постоянная работа над увеличением качества связи.

1.2.2 Анализ текущего состояния информационных технологий в

компании

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

обеспечения как проприетарного, так и свободно распространяемого (Open Source).

Сервер оснащен операционной системой Debian GNU/Linux. Для обеспечения

необходимого функционала используется программное обеспечение:

Сервер баз данных MySQL;

Веб-сервер Apache;

Сервер авторизации FreeRADIUS;

Сервер доступа Poptop;

Программный комплекс iptables/iproute/tc;

Приложение реализующее выполнение скриптового языка Perl;

Биллинговая система (или АСР – Автоматизированная Система Расчетов)

собственной разработки.

Компьютер главного бухгалтера оснащен:

операционная система Windows XP Professional;

программный комплекс OpenOffice.org;

система 1С Бухгалтерия.

Компьютеры генерального директора и оператора службы поддержки

оснащены:

операционная система Ubuntu 11.04;

офисный пакет OpenOffice.org.

Компьютеры системного администратора и веб-разработчика оснащены:


Дата

Лист

99МГУПИ 230102.12ПЗ

операционная система 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 используется для инициации и управления

GRE-соединением. PPTP сложно перенаправлять за сетевой экран, так как он

требует одновременного установления двух сетевых сессий.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

PPTP был объектом множества анализов безопасности, в нём были

обнаружены различные серьёзные уязвимости. Известные относятся к


Дата

Лист

99МГУПИ 230102.12ПЗ

используемым протоколам аутентификации 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

История и будущее

Опубликованный в 1999 году как предлагаемый стандарт RFC 2661[3], L2TP

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


Дата

Лист

99МГУПИ 230102.12ПЗ

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;

Инкапсуляция IPSec. Затем полученное L2TP-сообщение заключается в

оболочку с заголовком и трейлером IPSec ESP (Encapsulating Security Payload),


Дата

Лист

99МГУПИ 230102.12ПЗ

трейлером проверки подлинности IPSec, обеспечивающим целостность сообщения и

проверку подлинности, и заголовком IP. В заголовке IP-адреса источника и

приемника соответствуют VPN-клиенту и VPN-серверу.

В завершение L2TP выполняет вторую PPP-инкапсуляцию для подготовки

данных к передаче.

L2TP пакет состоит из:

Таблица 1.1 – Структура L2TP пакета

Значения полей:

Flags and version – Флаги, указывающие тип пакета (управляющий или

данные) и наличие полей с длиной, номером последовательности и сдвигом.

Length (опционально) – Полная длина сообщения в байтах, есть только когда

установлен флаг длины..

Tunnel ID – Отображает идентификатор управляющего соединения.

Session ID – Отображает идентификатор сессии внутри туннеля.

Ns (опционально) – Последовательный номер для данных или управляющего

сообщения, начиная с 0 и увеличиваясь на единицу (по модулю 216) для каждого

отправленного сообщения. Существует, когда установлен соответствующий флаг.

Nr (опционально) – Последовательный номер сообщения, ожидаемого для

принятия. Nr устанавливается как Ns последнего полученного сообщения плюс

один (по модулю 216). В сообщениях с данными, Nr зарезервирован, и, если

существует, ОБЯЗАН быть проигнорирован.

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

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

Tunnel ID Session ID

Ns (опционально) Nr (опционально)

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

Payload data


Дата

Лист

99МГУПИ 230102.12ПЗ

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.

Это позволяет применять традиционное PPP-ориентированное ПО для

настройки соединения, которое использует не последовательный канал, а пакетно-

ориентированную сеть (как Ethernet), чтобы организовать классическое соединение

с логином, паролем для Интернет-соединений. Также, IP-адрес по другую сторону

соединения назначается только когда PPPoE соединение открыто, позволяя

динамическое переиспользование IP адресов.


Дата

Лист

99МГУПИ 230102.12ПЗ

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 серверов, то все они посылают ответ. Клиент

выбирает подходящий сервер и посылает ему запрос на соединение. Сервер

посылает клиенту подтверждение с уникальным идентификатором сессии, все

последующие кадры в сессии будут иметь этот идентификатор. Таким образом,

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

идентифицируется идентификатором сессии и MAC-адресами клиента и сервера.

Затем в этом канале поднимается PPP соединение, а уже в PPP пакеты

упаковывается IP-трафик.

PPPoE Discovery (PPPoED)

PADI — PPPoE Active Discovery Initiation.


Дата

Лист

99МГУПИ 230102.12ПЗ

Если пользователь хочет подключиться к интернету по 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

ответило PADO-пакетом, пользовательская машина выбирает DSL-AC конкретный

POP, используя пришедшие имена или имена сервисов.

Пример PADO-пакета:

Frame 2 (60 bytes on wire, 60 bytes captured)

http://ru.wikipedia.org/wiki/%D0%9B%D0%B5%D0%B9%D0%BF%D1%86%D0%B8%D0%B3


Дата

Лист

99МГУПИ 230102.12ПЗ

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.

Преимущества схемы:

IP-заголовки в Ethernet среде игнорируются. То есть пользователь может

назначить IP-адрес своей сетевой карте, но это не приведет к «обвалу» сети

(теоретически, при работе с сетевым концентратором не должно произойти «обвала»

http://ru.wikipedia.org/wiki/Nortel_Networks


Дата

Лист

99МГУПИ 230102.12ПЗ

и при смене пользователем MAC-адреса даже на адрес сервера, а при работе с

сетевым коммутатором все зависит от конструкции коммутатора);

Каждое соединение отделено от других (работает в своем канале);

Настройки (IP-адрес, адрес шлюза, адреса DNS серверов) могут передаваться

сервером;

PPP соединение легко аутентифицируется и обсчитывается (например, при

помощи RADIUS);

PPP соединение можно шифровать. Например, при работе с сетевым

концентратором (когда на каждой сетевой карте может быть виден весь Ethernet-

трафик) прочитать чужой IP-трафик весьма затруднительно.

1.3.4 PriviteVLAN

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

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

использования в них архитектуры «VLAN на пользователя» или выделение

каждого абонента в отдельный широковещательный сегмент[5].

Для того, чтобы понять для чего нужна архитектура «VLAN на

пользователя», вначале рассмотрим традиционную и наиболее простую

архитектуру с общим VLAN, когда все устройства сети находятся в одном

широковещательном домене (рисунок 1.2).

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

Такая архитектура достаточно легко реализуется и создает небольшую

нагрузку на центральное оборудование сети, обеспечивающее доступ в Интернет,

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

абонентами по кратчайшему пути через ближайшие коммутаторы.


Дата

Лист

99МГУПИ 230102.12ПЗ

Основные недостатки архитектуры с общим VLAN:

Изоляция абонентов на втором уровне отсутствует (Layer2), что создает

опасность сетевых атак: подмена абонентом своего IP- или MAC-адреса, установка

несанкционированного DHCP-сервера, ARP Spoofing, переполнение таблицы MAC-

адресов коммутатора;

Точками контроля локального трафика становятся коммутаторы доступа,

которых в сети достаточно много. Это приводит к проблеме управления большим

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

стоимости еще и ограничены по функциональности.

Для решения первой проблемы используются управляемые коммутаторы

доступа с поддержкой функций безопасности (DHCP Snooping, IP Source Guard,

Port Security, Dynamic ARP Inspection). Решение второй проблемы с точкой

контроля локального трафика требует принципиальной перестройки архитектуры

сети. И одним из получивших применение способов стал переход на архитектуру

«VLAN на пользователя».


Дата

Лист

99МГУПИ 230102.12ПЗ

Таблица 2 – Сравнение архитектур «Общий VLAN» и «VLAN на

пользователя»

Общий VLANVLAN на пользователя

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

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

Большое Малое

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

«Паразитный» широковещательный трафик***

Есть Нет

Защита от типовых атак

Обеспечивается функциями на коммутаторе доступа

Обеспечивается архитектурой

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

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

трафиком, например, для блокировки доступа к локальным ресурсам сети при

отрицательном балансе

** Необходимость прохождения локального трафика через точку контроля

ведет к удлинению пути трафика между абонентами, что может увеличить нагрузку

на каналы

*** При масштабировании сети широковещательный трафик создает

ощутимую нагрузку на каналы связи и абонентские устройства

Архитектура «VLAN на пользователя», как следует из названия,

подразумевает выделение для каждого абонента своего собственного VLAN.


Дата

Лист

99МГУПИ 230102.12ПЗ

Рассмотрим вариант реализации такой архитектуры, предлагаемый ведущими

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

абонентского трафика является устройство 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).


Дата

Лист

99МГУПИ 230102.12ПЗ

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

В чем же основные достоинства децентрализованной модели? Во-первых, как

и в централизованной сохраняется изоляция абонентов на втором уровне, тем

самым решаются проблемы безопасности. Во-вторых, точками контроля

локального трафика теперь являются коммутаторы агрегации, количество которых

по сравнению с коммутаторами доступа в сети значительно меньше и они более

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

трафик теперь не обрабатывается BRAS.

Недостатки децентрализованной модели:

Ограничение в 4096 VLAN на каждый коммутатор агрегации;

Неэффективное использование адресного пространства (может быть решено

использованием проприетарной функции IP Unnumbered on SVI на коммутаторах

Cisco);

Необходимость ручной конфигурации большого количества VLAN-

интерфейсов на коммутаторах агрегации;

Индивидуальная конфигурация на каждом коммутаторе доступа.

Несмотря на недостатки, именно эта модель получила широкое

распространение среди Ethernet-операторов, в основном за счет улучшенной

управляемости сети по сравнению с архитектурой с общим VLAN, а также

снижением нагрузки на BRAS за счет обмена нетарифицируемым локальным

трафиком через коммутаторы агрегации.

Итак, изучив существующие подходы к построению архитектуры

операторских Ethernet-сетей, в ходе реализации одного из недавних проектов по

построению сети MetroEthernet, мы задались вопросом: Возможно ли найти


Дата

Лист

99МГУПИ 230102.12ПЗ

альтернативный подход и получить архитектуру по функциональности схожую с

децентрализованной моделью, но лишенную ее недостатков? Таким образом, была

поставлена задача - обеспечить безопасность и сохранить возможность контроля

локального трафика на Layer3-коммутаторах агрегации, но при этом избежать

создания большого числа 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.


Дата

Лист

99МГУПИ 230102.12ПЗ

Рисунок 1.5 – Архитектура с использованием Private VLAN и Local ProxyARP

Контроль локального трафика в данном случае осуществляется на

коммутаторе агрегации с помощью списков доступа VLAN ACL.

Задача обеспечения безопасности решается аналогично схеме с общим VLAN

– включением на коммутаторах доступа функций DHCP Snooping, Port Security, IP

Source Guard и Dynamic ARP Inspection.

Проблема с «паразитным» широковещательным трафиком отсутствует, так

как каждый абонент находится в собственном изолированном широковещательном

домене. Широковещательные пакеты доходят только до коммутатора агрегации и

не передаются остальным абонентам внутри общего VLAN.

В результате получилась архитектура по функциональным возможностям

аналогичная децентрализованной схеме с VLAN на пользователя, но избавленная

от её недостатков. Так как все пользователи находятся в одном VLAN, то

конфигурация коммутаторов доступа упрощается и становится унифицированной.

Конфигурация коммутаторов агрегации также упрощается за счет необходимости

только в одном VLAN-интерфейсе.


Дата

Лист

99МГУПИ 230102.12ПЗ

Таблица 1.3 – Сравнение архитектур «PrivateVLAN + Local Proxy ARP» и

«VLAN на пользователя»

PrivateVLAN +

Local Proxy ARP

VLAN на пользователя

Контроль локального трафика

Полный Полный

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

Малое Малое

«Паразитный» широковещательный трафик

Нет Нет

Защита от типовых атак Обеспечивается функциями на коммутаторе доступа

Обеспечивается архитектурой

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

Конфигурация коммутаторов доступа

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

Использование адресного пространства

Эффективное Неэффективное

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

метода

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


Дата

Лист

99МГУПИ 230102.12ПЗ

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

Интернет (рисунок 1.6):

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

Абонент посылает запрос (1) на подключение к серверу pptpd (реализуется

протокол PPTP) и передает свои «логин» и «пароль»;

Сервер pptpd посылает запрос (2) RADIUS-серверу на возможность

авторизации пользователя;

ИНТЕРНЕТ

Физический сервер

Сетевая карта 1 – eth1


NAS pptpd

Шейпер tc

Iptables SNAT

FreeRADIUS

Billing

MySQL

Абонент 1

Абонент 2

Абонент 3

(1) (1)

(1)

(5)

(7)

(2)

(3)

(4)(6)

Операторская сеть

(8)

(8) (8)

(9)

(10)

(11)


Дата

Лист

99МГУПИ 230102.12ПЗ

RADIUS-сервер запрашивает (3) данные из биллинговой системы, которая в

свою очередь проверяет (4) данные в базе MySQL;

При положительном ответе (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) Веб сервер. Используется для визуализации и управления системой;


Дата

Лист

99МГУПИ 230102.12ПЗ

4) RADIUS сервер. Используется для авторизации пользователей на серверах

доступа (NAS) поддерживающих RADIUS (RFC 2866, RFC 2865,) авторизацию или

аккаунтинг;

5) Сервера доступа. Устройства служащие для предоставления услуги

пользователям. Могут быть как базированные на PC устройствах так и аппаратные

(Cisco, Juniper, Zyxel, D-Link);

6) Администраторы системы. Администраторы и менеджеры работы с

клиентами управляющие бизнес процессом;

7) Пользователи которым предоставляются услуги.

1.4.3 Постановка задачи

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

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

составляет 80-90%, что показывает, что сервер работает на максимуме и

соответственно качество связи ухудшается с увеличением количества абонентов.

Увеличение мощности сервера может временно решить проблему с

загруженностью, но масштабируемость становится не возможной.

В ходе прохождения преддипломной практики и изучения специфики работы

биллинговой системы, организации было предложено решение проблемы с

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

протокол доступа PPTP на PPPoE, т.к. последний обладает рядом преимуществ

такими как:

IP-заголовки в Ethernet среде игнорируются. То есть пользователь может

назначить IP-адрес своей сетевой карте, но это не приведет к «обвалу» сети

(теоретически, при работе с сетевым концентратором не должно произойти «обвала»

и при смене пользователем MAC-адреса даже на адрес сервера, а при работе с

сетевым коммутатором все зависит от конструкции коммутатора).

Каждое соединение отделено от других (работает в своем канале).

Настройки (IP-адрес, адрес шлюза, адреса DNS серверов) могут передаваться

сервером.

http://www.ietf.org/rfc/rfc2865.txt

http://www.ietf.org/rfc/rfc2866.txt


Дата

Лист

99МГУПИ 230102.12ПЗ

PPP соединение легко аутентифицируется и обсчитывается (например, при

помощи RADIUS).

PPP соединение можно шифровать. Например, при работе с сетевым

концентратором (когда на каждой сетевой карте может быть виден весь Ethernet-

трафик) прочитать чужой IP-трафик весьма затруднительно.

Также было предложено отказаться от трансляции адресов (NAT) в пользу

чистой маршрутизации «белых» адресов, потому что NAT имеет ряд недостатков:

Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии

работать, если на пути между взаимодействующими хостами есть трансляция

адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов,

могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не

только в заголовках IP, но и на более высоких уровнях (например, в командах

протокола FTP). См. Application-level gateway.

Из-за трансляции адресов «много в один» появляются дополнительные

сложности с идентификацией пользователей и необходимость хранить полные логи

трансляций.

DoS со стороны узла, осуществляющего NAT — если NAT используется для

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

иллюзию DoS-атаки на сервис (множество успешных и неуспешных попыток).

Например, избыточное количество пользователей ICQ за NAT приводит к проблеме

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

скорости подключений. Частичным решением проблемы является использование

пула адресов (группы адресов), для которых осуществляется трансляция.

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

Трансляция порт-адрес) при работе с пиринговыми сетями и некоторыми другими

программами, в которых необходимо не только инициировать исходящие

соединения, но также принимать входящие. Однако, если NAT устройство и ПО,

требующее дополнительной настройки, поддерживают технологию Universal Plug &


Дата

Лист

99МГУПИ 230102.12ПЗ

Play, то в этом случае настройка произойдет полностью автоматически и прозрачно

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

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

(рисунок 1.8):

Рисунок 1.8 – Предлагаемая схема взаимодействия

Как видно на схеме, сервисы непосредственной передачи трафика и сервисы

биллинговой системы разнесены на маршрутизатор и выделенный сервер

соответственно. Для проведения данной модернизации на выделенном сервере

ИНТЕРНЕТ

Маршрутизатор

Физический сервер

Сетевая карта 1 – eth1Сетевая карта 1 – eth1


Абонент 1 Абонент 3

Абонент 2 Операторская сеть

PPPoERADIUS-сервер

Billing

MySQL WEB серверПолитики

шейпинга и маршрутизации


Дата

Лист

99МГУПИ 230102.12ПЗ

достаточно отключить сервис доступа pptpd и деактивировать функции

маршрутизации и передачи трафика. В качестве маршрутизатора предпологается

использовать мощный 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 адресов.

http://www.mikrotik.com/


Дата

Лист

99МГУПИ 230102.12ПЗ

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

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

80-90%, что показывает, что сервер работает на максимуме и соответственно

качество связи ухудшается с увеличением количества абонентов. Увеличение

мощности сервера может временно решить проблему с загруженностью, но

масштабируемость становится не возможной.

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

организации было предложено решение проблемы с загруженностью. Также для

улучшения качества связи было предложено изменить протокол доступа PPTP на

PPPoE.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

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

2.1.1 Графическое представление модели

Изобразим графически структуру связей на различных уровнях

представления. Рассмотрим схему физической структуры на рисунке 2.1:

Рисунок 2.1 – Физическая структура сети


Дата

Лист

99МГУПИ 230102.12ПЗ

Логическая схема связей взаимодействия изображена на рисунке 2.2.

Рисунок 2.2 – Логическая схема взаимодействия

И наконец, рассмотрим логическую схему взаимодействия, объектами в

которой являются службы и сервисы (рисунок 2.3).

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

2.1.2 Детальное рассмотрение протокола RADIUS-сервера

RADIUS (англ. Remote Authentication in Dial-In User Service) — протокол

AAA (Authentication, Authorization и Accounting), разработанный для передачи

сведений между центральной платформой AAA и оборудованием Dial-Up/VPN

Маршрутизатор Cервер АСР

Клиент

ИНТЕРНЕТ

Клиент Клиент

NASPPPoE

Клиент КлиентКлиент

Сервер RADIUS

СерверБаз Данных

Служба маршрутизации

BGP

ИНТЕРНЕТ


Дата

Лист

99МГУПИ 230102.12ПЗ

доступа (NAS, Network Access Server) и системой биллинга (то есть, системой

тарификации использованных ресурсов конкретным абонентом/пользователем)[1].

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


Дата

Лист

99МГУПИ 230102.12ПЗ

(RADIUS) в форме проекта стандарта и RFC 2866[12] под названием RADIUS

Accounting в виде «информационного RFC».

Изначально концепция RADIUS состояла в обеспечении удаленного доступа

через коммутируемое телефонное соединение. Со временем выкристаллизовались и

другие области применения этой технологии. К ним относятся серверы

виртуальных частных сетей (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, с которого

начинается собственно аутентификация и авторизация попытки доступа в сеть;


Дата

Лист

99МГУПИ 230102.12ПЗ

Access-Accept – "доступ разрешен". С помощью этого ответа на запрос

доступа клиенту RADIUS сообщается, что попытка соединения была успешно

аутентифицирована и авторизована;

Access-Reject – "доступ не разрешен". Этот ответ сервера RADIUS означает,

что попытка доступа к сети не удалась. Такое возможно в том случае, если

пользовательских данных недостаточно для успешной аутентификации или доступ

для пользователя не авторизован;

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


Дата

Лист

99МГУПИ 230102.12ПЗ

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

доступа, требующего данный протокол. Так как CHAP требует использования

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

проверки подлинности, например MS-CHAP версии 2.

Операционные системы семейства Windows Server 2003 поддерживают

протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности,

создание более надежных начальных ключей шифрования данных для 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.


Дата

Лист

99МГУПИ 230102.12ПЗ

2.1.3 Детальное рассмотрение механизма авторизации пользователя

Вызов-ответ (англ. Challenge-response authentication) — способ

аутентификации, при котором секрет (в данном случае пароль) не передаётся по

каналу связи[1].

Простейший способ такой аутентификации (при хранении паролей в

открытом виде):

Клиент, желающий пройти аутентификацию, дает запрос на начало сеанса

связи, в ответ на это вызываемая сторона (сервер) посылает произвольную, но

всякий раз разную информацию (например, текущие дату и время) клиенту;

Клиент дописывает к полученному запросу пароль и от этой строки

вычисляет какой-либо хэш (например, 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) и передаёт его серверу. Хеш-функция является алгоритмом

http://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F

http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA

http://ru.wikipedia.org/wiki/MD5

http://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88-%D0%BA%D0%BE%D0%B4

http://ru.wikipedia.org/w/index.php?title=%D0%A1%D0%B5%D1%80%D0%B2%D0%B5%D1%80_%D1%83%D0%B4%D0%B0%D0%BB%D1%91%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B0&action=edit&redlink=1

http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA


Дата

Лист

99МГУПИ 230102.12ПЗ

одностороннего (необратимого) шифрования (преобразования), поскольку значение

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

хеш-коду с математической точки зрения невозможно за приемлемое время.

Сервер, которому доступен пароль пользователя, выполняет те же самые

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

совпадения учётные данные клиента удалённого доступа считаются подлинными.

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. Получившийся результат

высылаем вместе со своим именем. Удалённая сторона, зная наш пароль и

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

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


Дата

Лист

99МГУПИ 230102.12ПЗ

Таким образом, пароль не передается в открытом виде, но удалённая сторона

должна хранить наш пароль в открытом виде.

Рассмотрим как отреагирует NAS при поступлении запроса пользователя на

аутентификацию:

Пользователь пытается пройти аутентификацию на NAS;

NAS смотрит в первый попавшийся RADIUS сервер и посылает пакет для

установки связи(запрос на доступ);

Если ответ не получен в течение определённого тайм-аута, то NAS либо

опрашивает RADIUS сервер ещё раз, либо ищет альтернативный сервер;

RADIUS сервер смотрит ip адрес NAS и проверяет ключ симметричного

шифрования, если ip адрес и ключ соответствуют тому, что написано в

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

Invalid Key. Проверка осуществляется генерацией и шифрацией случайной строки.

Далее передаваемые между клиентом и сервером RADIUS данные шифруются

данным ключом;

Сервер RADIUS проверяет пароль пользователя (по сети передается md5 хеш

пароля), помимо пароля сервер может также проверить ip адрес и порт NAS, если эти

данные неверны, то сервер посылает NAS пакет "Доступ запрещён", содержащий код

ошибки, который также может содержать текстовое описание ошибки, отображаемое

для пользователя;

Если же данные пользователя верны, то сервер посылает NAS пакет "Доступ

разрешён", содержащий данные о сервисе (PPP, SLIP, login) и некоторые

специфические параметры сервиса, например, ip адрес, номер подсети, MTU для PPP

сервиса в виде пар параметр=значение(AV пар).


Дата

Лист

99МГУПИ 230102.12ПЗ

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].

Сетевая топология за пределами локального домена может изменяться по

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

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

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

домена также требуется соответствующим образом изменять. Эти изменения могут

оставаться незаметными для пользователей внутри домена при централизованном

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

Базовая трансляция во многих случаях может обеспечивать доступ

пользователей из частной сети во внешние сети, а также доступ извне к некоторым

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

внутренних задач, а доступ во внешние сети требуется нерегулярно, такая схема

будет весьма удобна.


Дата

Лист

99МГУПИ 230102.12ПЗ

Многие пользователи SOHO и удаленные сотрудники используют в своих

офисах множество узлов с приложениями TCP/UDP, но имеют лишь один адрес IP,

выделенный их маршрутизатору провайдером для доступа во внешнюю сеть. Эта

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

трансляции NAPT, который позволяет множеству узлов из локальной сети

одновременно получить доступ во внешние сети с использованием единственного

адреса IP, выделенного для их маршрутизатора.

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

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

одним NAT-маршрутизатором. Одним из вариантов решения задачи является

организация NAT на граничном маршрутизаторе, который является единственным

для краевого домена и все пакеты IP, адресованные в домен или исходящие из него,

проходят через этот маршрутизатор. Существуют также варианты решения задачи

при использовании множества устройств NAT. Например, частная сеть может

иметь две разных точки выхода в сети различных провайдеров и поток пакетов той

или иной сессии внутреннего хоста может проходить через любое устройств NAT,

которое будет обеспечивать лучшую метрику для внешнего хоста. При отказе

одного из маршрутизаторов NAT оставшийся маршрутизатор сможет обслуживать

трафик для всех соединений. Однако в этой модели при смене маршрутизации во

время организованной сессии и переключении на другой маршрутизатор NAT

соединение данной сессии будет разорвано. В качестве варианта решения этой

проблемы можно использовать одинаковую конфигурацию NAT на обоих

маршрутизаторах обмен информацией соединений для обеспечения безопасного

переключения трафика между маршрутизаторами.

Трансляция адресов не зависит от приложений и часто сопровождается

специализированными шлюзами (ALG для мониторинга и изменения передаваемой

информации. FTP является наиболее популярным представителем ALG на

устройствах NAT. Приложениям, которым требуется наличие ALG, недопустимо


Дата

Лист

99МГУПИ 230102.12ПЗ

передавать свои данные в шифрованном виде, поскольку это будет нарушать

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

Недостатком этого решения является сквозная значимость адресов 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.

Рисунок 2.4 - Традиционная конфигурация NAT

Внутренний ip адрес

Внешний ip адрес

маршрутизатор


Компьютер


Компьютер

ИНТЕРНЕТ


Дата

Лист

99МГУПИ 230102.12ПЗ

Фазы трансляции для сеанса:

Привязка адреса. При использовании 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-


Дата

Лист

99МГУПИ 230102.12ПЗ

адреса отправителя и получателя. Исключением являются случаи когда контрольная

сумма заголовка 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, а также контрольная сумма


Дата

Лист

99МГУПИ 230102.12ПЗ

вложенного заголовка IP должны быть изменены. Требуется также изменить

значение контрольной суммы заголовка ICMP с учетом изменений, внесенных в

данные. Для случая 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 поддерживают преобразование имен для внешних хостов, но не поддерживают


Дата

Лист

99МГУПИ 230102.12ПЗ

для внутренних. Если в частной сети нет внутренних серверов DNS, все запросы

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

внешних хостов.

Обработка опций 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


Дата

Лист

99МГУПИ 230102.12ПЗ

первый блок представляет собой одну сеть класса A, второй – 16 последовательных

сетей класса B, а третий – 256 последовательных сетей класса C.

Организации, которые решили использовать адреса из указанных блоков,

могут делать это без какого-либо согласования с IANA или реестром Internet.

Адресное пространство может, таким образом, использоваться одновременно во

множестве организаций с трансляцией 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.


Дата

Лист

99МГУПИ 230102.12ПЗ

2.2.2 Детальное рассмотрение протокола маршрутизации BGP

BGP (англ. Border Gateway Protocol, протокол граничного шлюза) —

основной протокол динамической маршрутизации в Интернете[1].

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 октетов. Каждое


Дата

Лист

99МГУПИ 230102.12ПЗ

сообщение имеет заголовок фиксированного размера. Объем информационных

полей зависит от типа сообщения.

Здесь уместно заметить, что Интернет - это клуб джентльменов. Очень

многие узлы пропускают через себя значительный транзитный трафик, который

ограничивает возможности непосредственных клиентов узла. Как правило, этот

трафик никак не оплачивается. Администраторы могут в рамках протокола BGP

существенно ограничить или даже исключить такой транзитный трафик, но они

обычно этого не делают, понимая, что их клиенты создают такой же транзитный

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

сеть Интернет на ряд враждующих феодальных крепостей.

Рисунок 2.6 – Формат BGP-сообщений об изменениях маршрутов

Поле маркер содержит 16 октетов и его содержимое может легко

интерпретироваться получателем. Если тип сообщения "OPEN", или если код

идентификации в сообщении open равен нулю, то поле маркер должно быть

заполнено единицами. Маркер может использоваться для обнаружения потери

синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет

общую длину сообщения в октетах, включая заголовок. Значение этого поля

должно лежать в пределах 19-4096. Поле тип представляет собой код

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

1 OPEN (открыть)

2 UPDATE (изменить)

3 NOTIFICATION (внимание)

4 KEEPALIVE (еще жив)


Дата

Лист

99МГУПИ 230102.12ПЗ

BGP отличается от RIP и OSPF тем, что использует TCP в качестве

транспортного протокола. Две системы, использующие BGP, связываются друг с

другом и пересылают посредством TCP полные таблицы маршрутизации.

После того как связь на транспортном протокольном уровне установлена,

первое сообщение, которое должно быть послано - это OPEN. При успешном

прохождении этого сообщения партнер должен откликнуться сообщением

KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме

заголовка сообщение open содержит следующие поля (Рисунок 2.7):

Рисунок 2.7 – Формат сообщения open

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

BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS

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

отправитель предлагает занести в таймер сохранения. После получения сообщения

OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно

выбирается меньшее из полученного в сообщении open и значения, определенного

при конфигурации системы (0-3сек). Время сохранения определяет максимальное

время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя

UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный

идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех

интерфейсов локальной сети). Если два узла установили два канала связи друг с

другом, то согласно правилам должен будет сохранен канал, начинающийся в узле,

BGP-идентификатор которого больше. Предусмотрен механизм разрешения

проблемы при равных идентификаторах.


Дата

Лист

99МГУПИ 230102.12ПЗ

Одно-октетный код идентификации позволяет организовать систему доступа,

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

идентификационных данных должно иметь нулевую длину. При неравном нулю

коде идентификации должна быть определена процедура доступа и алгоритм

вычисления кодов поля маркера. Длина поля идентификационных данных

определяется по формуле:

Длина сообщения = 29 + длина поля идентификационных данных.

Минимальная длина сообщения open составляет 29 октетов, включая заголовок.

Сообщения типа UPDATE (изменения) используются для передачи

маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет

сообщить об одном новом маршруте или объявить о закрытии группы маршрутов,

причем объявление об открытии нового и закрытии старых маршрутов возможно в

пределах одного сообщения. Сообщение UPDATE всегда содержит стандартный

заголовок и может содержать другие поля в соответствии со схемой(Рисунок 2.8):

Рисунок 2.8 – Формат update-сообщения

Если длина списка отмененных маршрутов равна нулю, ни один маршрут не

отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные

маршруты имеет переменную длину и содержит список IP-адресных префиксов

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

формат(Рисунок 2.9):


Дата

Лист

99МГУПИ 230102.12ПЗ

Рисунок 2.9 – Формат записи отмененных маршрутов

Длина префикса (в битах), равная нулю означает, что префикс соответствует

всем IP-адресам, а сам имеет нулевой размер. Поле префикс содержит IP-адресные

префиксы, за которыми следуют разряды, дополняющие их до полного числа

октетов. Значения этих двоичных разрядов смысла не имеют.

Нулевое значение полной длины списка атрибутов пути говорит о том, что

информация о доступности сетевого уровня в 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, то третий и четвертый октеты


Дата

Лист

99МГУПИ 230102.12ПЗ

атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут

пути характеризуют значение атрибута и интерпретируются согласно флагам

атрибута.

Атрибуты пути бывают "стандартные обязательные" (well-known mandatory),

"стандартные на усмотрение оператора", "опционные переходные" и "опционные

непереходные". Стандартные атрибуты должны распознаваться любыми BGP-

приложениями. Опционные атрибуты могут не распознаваться некоторыми

приложениями. Обработка нераспознанных атрибутов задается битом 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.


Дата

Лист

99МГУПИ 230102.12ПЗ

Маршрутная политика это не часть протокола, она определяет решения, когда

место назначения достижимо несколькими путями, политика отражает

соображения безопасности, экономические интересы и пр. Количество сетей в

пределах одной AS не лимитировано. Один маршрутизатор на много сетей

позволяет минимизировать таблицу маршрутов.

BGP использует три таймера:

Connectretry (сбрасывается при инициализации и коррекции; 120 сек);

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-пакета. Концепция классов сетей и субсети находятся вне рамок этой

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


Дата

Лист

99МГУПИ 230102.12ПЗ

кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень

предпочтительности маршрута для собственной AS), который упрощает процедуру

выбора маршрута. Атрибут INTER_AS_METRICS переименован в

MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей).

Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые

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

принятия решения, которая имеет три фазы:

Вычисление степени предпочтения для каждого маршрута, полученного от

соседней 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 означает диапазон адресов


Дата

Лист

99МГУПИ 230102.12ПЗ

192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 -

192.1.255.255, таким образом, число, следующее после косой черты, задает

количество двоичных разрядов префикса. Это представление используется при

описании политики маршрутизации и самих маршрутов. Для приведенных

примеров это в терминах масок выглядит следующим образом:

Рисунок 2.10 – 24 и 17 длины префикса сети

Следует помнить, что маски с разрывами здесь недопустимы. Ниже

приведена таблица метрик маршрутизации для различных протоколов(Таб. 2.5).

Таблица 2.1 – Метрики маршрутизации для различных протоколов.

Протокол Метрика ДиапазонКод "маршрут недостижим"

RIPhelloBGP

Число скачковЗадержка в msНе определена

0-150-299990-65534

163000065535

Колонка "маршрут недостижим" содержит коды метрики, которые говорят о

недоступности маршрута. Обычно предполагается, что если послан пакет из точки

<А> в точку <B>, то маршруты их в одном и другом направлении совпадают. Но

это не всегда так. Пример, когда маршруты пакетов "туда" и "обратно" не

совпадают, представлен на рисунке 2.11. В предложенной схеме имеется две ЭВМ

"Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора "GW-2" и

"GW-1".


Дата

Лист

99МГУПИ 230102.12ПЗ

Рисунок 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

адресов: телекоммуникационные компании, промышленные предприятия,


Дата

Лист

99МГУПИ 230102.12ПЗ

административные учреждения, академические институты. LIR имеет полномочия

получать независимые ресурсы в RIPE NCC в интересах пользователя. Для

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

пользователем (End User) и LIR. Общие условия контракта изложены в документе

ripe-452 (см. также: перевод ripe-452 на русский язык). Одним из условий является

регулярная оплата за полученные ресурсы. Размер оплаты устанавливает LIR.

Запрос в RIPE NCC

Независимые ресурсы можно получить в RIPE NCC, заключив договор с этой

организацией. В этом случае Вы получаете статус "Direct Assignment User".

Получать независимые ресурсы в качестве "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. Так же данная система может быть

установлена на ПК, превращая его в маршрутизатор, предоставляющий такие


Дата

Лист

99МГУПИ 230102.12ПЗ

функции, как правила брандмауэра, VPN сервер и клиент, формирование

качественной пропускной способности, беспроводную точку доступа и другие

часто используемые функции маршрутизации и подключения сетей. Операционная

система лицензирована в эскалации уровней, в каждом релизе тем больше функций

RouterOS, чем больше номер уровня. Лицензирование платные и эскалируются в

соответствии с функциями релиза. Существует программное обеспечение под

названием Winbox, которое предоставляет сложный графический интерфейс для

операционной системы RouterOS. Программное обеспечение также позволяет

соединеняться через 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 серверов мира с точки зрения развёртывания и

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


Дата

Лист

99МГУПИ 230102.12ПЗ

Может работать на встраиваемых системах с небольшим количеством памяти,

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

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

многие коммерческие серверы. В настоящее время FreeRADIUS используется как

основа для разработки коммерческих RADIUS серверов.

FreeRADIUS был основан в августе 1999 года Аланом ДеКоком и Микуэлом

ван Смуренбергом. Микуэл ранее написал Cistron RADIUS сервер, который

получил широкое распространение. С того момента сервер Livingston больше не

поддерживается. Командой 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


Дата

Лист

99МГУПИ 230102.12ПЗ

В комплект входит:

Шасси с двумя блоками питания (G4p);

2 процессора Intel Xeon 3.4;

4GB PC2-3200 ECC DRAM;

2x73GB HDD SCSI U320;

В комплект не входит Rail Kit.

Технические характеристики HP DL360 G4:

До 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), разработанный для передачи


Дата

Лист

99МГУПИ 230102.12ПЗ

сведений между центральной платформой AAA и оборудованием Dial-Up/VPN

доступа (NAS, Network Access Server) и системой биллинга (то есть, системой

тарификации использованных ресурсов конкретным абонентом/пользователем).

Вызов-ответ (англ. Challenge-response authentication) — способ

аутентификации, при котором секрет (в данном случае пароль) не передаётся по

каналу связи.

Простейший способ такой аутентификации (при хранении паролей в

открытом виде):

Клиент, желающий пройти аутентификацию, дает запрос на начало сеанса

связи, в ответ на это вызываемая сторона (сервер) посылает произвольную, но

всякий раз разную информацию (например, текущие дату и время) клиенту;

Клиент дописывает к полученному запросу пароль и от этой строки

вычисляет какой-либо хэш (например, MD5) и отправляет его серверу;

Сервер проделывает с посланным значением аналогичные действия и

сравнивает результат. Если значения хэшей совпадают, то авторизация считается

успешной.

Базовая трансляция сетевых адресов или Basic NAT представляет собой метод

отображения адресов IP из одной группы в другую, прозрачного для конечных

пользователей. Трансляция сетевых адресов и номеров портов или NAPT - метод, с

помощью которого множество сетевых адресов и соответствующих портов

TCP/UDP (Transmission Control Protocol/User Datagram Protocol) преобразуется в

один сетевой адрес и номер порта TCP/UDP. Оба метода вместе называют

традиционной трансляцией адресов (traditional NAT). NAT обеспечивает механизм

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

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

Необходимость преобразования (трансляции) адресов IP возникает в тех

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

пределами сети из соображений сохранения тайны или по той причине, что эти

адреса корректны только внутри сети.


Дата

Лист

99МГУПИ 230102.12ПЗ

BGP (англ. Border Gateway Protocol, протокол граничного шлюза) —

основной протокол динамической маршрутизации в Интернете.

BGP, в отличие от других протоколов динамической маршрутизации,

предназначен для обмена информацией о маршрутах не между отдельными

маршрутизаторами, а между целыми автономными системами, и поэтому, помимо

информации о маршрутах в сети, переносит также информацию о маршрутах на

автономные системы. BGP не использует технические метрики, а осуществляет

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

MikroTik RouterOS – сетевая операционная система на базе Linux. Данная

операционная система предназначена для установки на аппаратные

маршрутизаторы Mikrotik RouterBoard. Так же данная система может быть

установлена на ПК, превращая его в маршрутизатор, предоставляющий такие

функции, как правила брандмауэра, VPN сервер и клиент, формирование

качественной пропускной способности, беспроводную точку доступа и другие

часто используемые функции маршрутизации и подключения сетей. Операционная

система лицензирована в эскалации уровней, в каждом релизе тем больше функций

RouterOS, чем больше номер уровня. Лицензирование платные и эскалируются в

соответствии с функциями релиза. Существует программное обеспечение под

названием Winbox, которое предоставляет сложный графический интерфейс для

операционной системы RouterOS. Программное обеспечение также позволяет

соединеняться через FTP, Telnet, и SSH. Существует также API, который позволяет

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


Дата

Лист

99МГУПИ 230102.12ПЗ

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Демо

3WISP CPE

4 WISP

5 WISP

6 Контроллер

Обновление до -не

обновляетсяROS v5.x ROS v5.x ROS v6.x ROS v6.x

Тех. поддержка при первонач-й

настройке- - - 15 дней 30 дней 30 дней

Беспроводная точка доступа

лимит 24 часа

- - да да да

Беспроводной клиент, бридж


да да да да да

Протоколы маршрутизации

RIP, OSPF, BGP


да да да да да

EoIP туннелилимит 24 часа

1 1не

ограниченоне


ограничено

PPPoE туннелилимит 24 часа

1 1 200 500не


PPTP туннелилимит 24 часа

1 1 200не



L2TP туннелилимит 24 часа

1 1 200не



OVPN туннелилимит 24 часа

1 1 200не


ограниченоVLAN

интерфейсылимит 24 часа

1 1не



ограниченоПравила

брандмауэра P2P


1 1не




NAT правилалимит 24 часа

1не




ограниченоАктивных

пользователей Хот-Спот


1 1 200 500не


Radius клиентлимит 24 часа

- да да да да

Queuesлимит 24

часа1

не ограничено




Веб-проксилимит 24 часа

- да да да да

Активных сессий в User

Manager


1 10 20 50не



Дата

Лист

99МГУПИ 230102.12ПЗ

Таблица 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), как на достаточном. После совершения оплаты, по

электронной почте получаем уникальный ключ, который необходимо ввести после

установки ОС.


Дата

Лист

99МГУПИ 230102.12ПЗ

3.1.2 Закупка аппаратного обеспечения

В качестве маршрутизатора был выбран сервер 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, сообщить его;


Дата

Лист

99МГУПИ 230102.12ПЗ

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.


Дата

Лист

99МГУПИ 230102.12ПЗ

/radius incoming set accept=yes port=1700

Этой командой разрешаем входящие соединения от 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 \


Дата

Лист

99МГУПИ 230102.12ПЗ

redistribute-static=no router-id=195.191.242.1 routing-table=""

Добавим свою сеть в список анонсируемых нами сетей вышестоящим

провайдерам:

/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


Дата

Лист

99МГУПИ 230102.12ПЗ

После успешного соединения с операторами-партнерами мы увидим, что от

каждого из них получили примерно по 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


Дата

Лист

99МГУПИ 230102.12ПЗ

output = no

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

}


Дата

Лист

99МГУПИ 230102.12ПЗ

post-auth {

Post-Auth-Type REJECT {

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 – левой кнопкой мыши на ссылку «Центр управления сетями и общим

доступом»


Дата

Лист

99МГУПИ 230102.12ПЗ

Рисунок 3.1 – Настройка клиентского компьютера(1)

3 – левой кнопкой мыши кликаем на ссылку «Настройка нового подключения

или сети»



Дата

Лист

99МГУПИ 230102.12ПЗ

Если у Вас уже были ранее созданные подключения, то может быть выведено

следующее окно, его мы пропускаем и кликаем левой кнопкой мыши на кнопку

«Далее»


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

5 – левой кнопкой мыши кликаем на кнопку «Далее»



Дата

Лист

99МГУПИ 230102.12ПЗ

6 – левой кнопкой мыши кликаем на ссылку «Высокоскоростное (с РРPоЕ)»


7 – в поле «Имя пользователя» вводим логин данный Нам при подключении

8 – в поле пароль необходимо ввести пароль данный Нам при подключении

Найти Логин/пароль можно в бумажном виде в Приложении

№3/Техническое приложение.

Важно! При вводе пароля учитывайте БОЛЬШИЕ маленькие буквы!

9 – в поле «Имя пользователя» вводим «Подключение интернет SWNet»

10 – левой кнопкой мыши кликаем на кнопку «Подключить»


Дата

Лист

99МГУПИ 230102.12ПЗ


13 – левой кнопкой мыши кликаем на ярлычёк около часов

14 – левой кнопкой мыши на ссылку «Подключение интернет SWNet», далее

появится кнопка

«Подключение»

15 – левой кнопкой мыши на кнопку «Подключение»



Дата

Лист

99МГУПИ 230102.12ПЗ

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 маршрутов, теперь маршрутизатор

знает как добраться до каждого уголка Интернета.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

4.1 Постановка задачи

Для любой компании необходим рост не только за счет роста рынка, но и за

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

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

является увеличение качества услуг, предоставляемых предприятием ООО «СКС».

Известно, что текущая конфигурация центрального узла связи компании

работает на уровне близком к пику своих возможностей, поэтому необходимость

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

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

разделение функций одного сервера на сервер АСР и маршрутизатор NAS. Это

увеличит качество услуг для текущей емкости абонентской базы, а также даст

возможность для увеличения этой емкости, что в свою очередь даст возможность

роста компании в целом.

Одним из составляющих качества услуг связи является способ абонентского

доступа. Наиболее популярными способами доступа среди как ведущих, так и

малых операторов ШПД являются PPTP, L2TP, PPPoE и PrivateVLAN. У

протоколов PPTP и L2TP существует один важный недостаток – это необходимость

корректной конфигурации IP-адресации у абонентов, практика компании показала,

что настройки часто сбиваются по тем или иным причинам, что увеличивает

нагрузку на службу поддержки и приводит к появлению недовольства

пользователей. Способ доступа, именуемый как PrivateVLAN технически сложен

для реализации, для его внедрения необходима поддержка со стороны

оборудования «последней мили». Самым оптимальным вариантом оказался PPPoE,

он не имеет недостатков PPTP и L2TP, для его внедрения не нужно

дополнительных затрат на дорогостоящее оборудование как в случае с

PrivateVLAN. Второй задачей дипломного проекта является внедрение PPPoE.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

системы трансляции адресов NAT с заменой на внешние адреса и полноценную

маршрутизацию Интернета BGP-4.

Ориентировочно конфигурация узла связи может эксплуатироваться в

течение двух лет.

4.2 Оценка стоимости внедрения проекта

Сметная стоимость включает следующие составляющие:

заработную плату научных работников;

затраты на электроэнергию;

затраты на комплектующие изделия и расходные материалы;

отчисления в фонд внебюджетного страхования;

накладные расходы.

Основная заработная плата специалистов, проводящих ОКР, определяется с

учетом количества инженерно-технических работников, их квалификации,

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

Таблица 4.1 – Основная заработная плата специалистов

N п/п Этапы разработки

Исполнители Часовая тарифная ставка, руб/ч

Трудоемкость работ, ч

Заработная плата, руб

1 Разработка проекта

Системный администратор

40200

8 000

2 Настройка оборудования

Системный администратор

60200

12 000

Итого заработная плата: 20 000


Дата

Лист

99МГУПИ 230102.12ПЗ

Основная заработная плата определяется по формуле:

(4.1)

где – трудоемкость i-го вида работ, ч;

– часовая тарифная ставка исполнителя при выполнении i-го вида работ.

Дополнительная заработная плата определяется следующим образом:

(4.2)

руб.

Для основной группы налогоплательщиков установлены следующие тарифы:

Пенсионный фонд Российской Федерации - 26%

Фонд социального страхования Российской Федерации - 2,9%

Федеральный фонд обязательного медицинского страхования - 2,1%

Территориальные фонды обязательного медицинского страхования - 3%.

Таким образом, в общая сумма страховых взносов составит 34 процента,

вместо 26 процентов по ЕСН, как было ранее (без учета регрессии). r = 34%:

, (4.3)

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

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

(4.4)

Расчеты затрат на электроэнергию выполняется с учетом потребляемой

мощности отдельных электроприемников Рg (кВт), длительности эксплуатации


Дата

Лист

99МГУПИ 230102.12ПЗ

оборудования при проведении ОКР tg (ч) и тарифа на электроэнергию Цэ

(руб./кВтч).

(4.5)

– затраты на электроэнергию в течение 2 лет

Таблица 4.2 – Расчёт затрат на электроэнергию в течение 2 лет

Наименование прибора

Длительность эксплуатации

Потребляемая мощность, кВт

Время работы, ч

Тариф, руб/кВтч

Стоимость, руб

Сервер HP Proliant DL360 G4p 3.4 Bundle

2 года 17 520 ч

0,5кВт 24 2,82 24 703,2

Итого за электроэнергию за 2 года 24 703,2

Данные по ценам на эти материалы формируются в основном на договорной

основе и обговариваются на подготовительном этапе. В таблице 4.3 приведен

расчет затрат на основные и вспомогательные материалы, используемые в работе.

Источником цен является официальные прайс-листы производителей

оборудования.


Дата

Лист

99МГУПИ 230102.12ПЗ

Таблица 4.3 – Затраты на комплектующие изделия

Наименование изделия

Тип, марка Количество, шт.

Цена за 1 ед. руб.

Стоимость, руб.

Сервер HP Proliant DL360 G4p 3.4 Bundle

119 874 19 874

Программное обеспечение

Mikrotik RouterOS 12 000 2 000

Услуги

Регистрация PI блока /23 и автономной системы AS

1

15 168 15 168

Итого затрат на комплектующие изделия: 37 042

Таблица 4.4 – Затраты на материалы

Наименование материалаЕдиницаизмерения

Кол-во

Цена единицы

Стоимость, руб

Пэтч-корд шт 1 50 50

Шнур питания шт 2 60 120

Итого затрат на материалы: 170Суммарные затраты на комплектующие изделия можно определить по

формуле (4.6):

(4.6)

Где – суммарные затраты на комплектующие изделия, – количество

комплектующего изделия k-го типа; – цена единицы k-го изделия.

Суммарные затраты на материалы можно определить по формуле:

(4.7)


Дата

Лист

99МГУПИ 230102.12ПЗ

где – суммарные затраты на материалы, – норма расхода j-го материала;

– цена единицы материала.

Общие затраты на создание локальной вычислительной сети

определяется путем суммирования отдельных составляющих:

, (4.8)

где – коэффициент транспортно-заготовительных расходов (обычно

принимаются в размере 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 месяцев после

внедрения.


Дата

Лист

99МГУПИ 230102.12ПЗ

4.4 Вывод по разделу

Реализация данного проекта позволит:

1) Повысить качество связи;

2) Повысить комфортность абонентов;

3) Увеличить максимальную емкость абонентской базы;

4) Увеличить масштабируемость узла связи.

С внедрением данного проекта предприятие сможет наращивать абонентскую

базу на своих кабельных сетях со скоростью 30 абон./мес.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

Эргономические требования к рабочему месту

Проектирование рабочих мест, снабженных видеотерминалами, относится к

числу важных проблем эргономического проектирования в области

вычислительной техники.

Рабочее место и взаимное расположение всех его элементов должно

соответствовать антропометрическим, физическим и психологическим

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

организации рабочего места программиста должны быть соблюдены следующие

основные условия: оптимальное размещение оборудования, входящего в состав

рабочего места и достаточное рабочее пространство, позволяющее осуществлять

все необходимые движения и перемещения.

Эргономическими аспектами проектирования видеотерминальных рабочих

мест, в частности, являются: высота рабочей поверхности, размеры пространства

для ног, требования к расположению документов на рабочем месте (наличие и

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

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

т.д.), характеристики рабочего кресла, требования к поверхности рабочего стола,

регулируемость элементов рабочего места [20].

Главными элементами рабочего места программиста являются стол и кресло.

Основным рабочим положением является положение сидя.

Рабочая поза сидя вызывает минимальное утомление программиста.

Рациональная планировка рабочего места предусматривает четкий порядок и

постоянство размещения предметов, средств труда и документации. То, что

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

рабочего пространства.

Моторное поле – пространство рабочего места, в котором могут

осуществляться двигательные действия человека.


Дата

Лист

99МГУПИ 230102.12ПЗ

Максимальная зона досягаемости рук – это часть моторного поля рабочего

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

при движении их в плечевом суставе.

Оптимальная зона – часть моторного поля рабочего места, ограниченного

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

в точке локтя и с относительно неподвижным плечом.

Рисунок 5.1 Зоны досягаемости рук в горизонтальной плоскости.

Оптимальное размещение предметов труда и документации в зонах

досягаемости:

ДИСПЛЕЙ размещается в зоне а (в центре);

СИСТЕМНЫЙ БЛОК размещается в предусмотренной нише стола;

КЛАВИАТУРА - в зоне г/д;

«МЫШЬ» - в зоне в справа;

СКАНЕР в зоне а/б (слева);

ПРИНТЕР находится в зоне а (справа);

ДОКУМЕНТАЦИЯ: необходимая при работе - в зоне легкой досягаемости

ладони – в, а в выдвижных ящиках стола - литература, неиспользуемая постоянно.

На рис. 5.2 показан пример размещения основных и периферийных

составляющих ПК на рабочем столе программиста.

0 200 400 600 800200400600800

200

0

400

600

800а

б

вгд

а - зона максимальной досягаемости;

б - зона досягаемости пальцев при вытянутой руке;

в - зона легкой досягаемости ладони;

г - оптимальное пространство для грубой ручной работы;

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


Дата

Лист

99МГУПИ 230102.12ПЗ

Рисунок 5.2 Размещение основных и периферийных составляющих ПК.

1 – сканер, 2 – монитор, 3 – принтер, 4 – поверхность рабочего стола,

5 – клавиатура, 6 – манипулятор типа «мышь».

Для комфортной работы стол должен удовлетворять следующим условиям

[20]:

высота стола должна быть выбрана с учетом возможности сидеть свободно, в

удобной позе, при необходимости опираясь на подлокотники;

нижняя часть стола должна быть сконструирована так, чтобы программист

мог удобно сидеть, не был вынужден поджимать ноги;

поверхность стола должна обладать свойствами, исключающими появление

бликов в поле зрения программиста;

конструкция стола должна предусматривать наличие выдвижных ящиков (не

менее 3 для хранения документации, листингов, канцелярских принадлежностей).

высота рабочей поверхности рекомендуется в пределах 680-760мм. Высота

поверхности, на которую устанавливается клавиатура, должна быть около 650мм.

Большое значение придается характеристикам рабочего кресла. Так,

рекомендуемая высота сиденья над уровнем пола находится в пределах 420-550мм.

1 2 3

5 64


Дата

Лист

99МГУПИ 230102.12ПЗ

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

– регулируемый.

Необходимо предусматривать при проектировании возможность различного

размещения документов: сбоку от видеотерминала, между монитором и

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

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

делают больше (около 700мм), чем расстояние от глаза до документа (300-450мм).

Вообще при высоком качестве изображения на видеотерминале расстояние от глаз

пользователя до экрана, документа и клавиатуры может быть равным.

Положение экрана определяется:

расстоянием считывания (0,6…0,7м);

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

экрана, причем экран перпендикулярен этому направлению.

Должна также предусматриваться возможность регулирования экрана:

по высоте +3 см;

по наклону от -10 до +20 относительно вертикали;

в левом и правом направлениях.

Большое значение также придается правильной рабочей позе пользователя.

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

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

голова не должна быть наклонена более чем на 20,

плечи должны быть расслаблены,

локти - под углом 80…100,

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

Причина неправильной позы пользователей обусловлена следующими

факторами: нет хорошей подставки для документов, клавиатура находится

слишком высоко, а документы – низко, некуда положить руки и кисти,

недостаточно пространство для ног.


Дата

Лист

99МГУПИ 230102.12ПЗ

В целях преодоления указанных недостатков даются общие рекомендации:

лучше передвижная клавиатура; должны быть предусмотрены специальные

приспособления для регулирования высоты стола, клавиатуры и экрана, а также

подставка для рук [20].

Существенное значение для производительной и качественной работы на

компьютере имеют размеры знаков, плотность их размещения, контраст и

соотношение яркостей символов и фона экрана. Если расстояние от глаз оператора

до экрана дисплея составляет 60…80 см, то высота знака должна быть не менее

3мм, оптимальное соотношение ширины и высоты знака составляет 3:4, а

расстояние между знаками – 15…20% их высоты. Соотношение яркости фона

экрана и символов - от 1:2 до 1:15 [21].

Во время пользования компьютером медики советуют устанавливать монитор

на расстоянии 50-60 см от глаз. Специалисты также считают, что верхняя часть

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

прямо перед собой, его глаза открываются шире, чем когда он смотрит вниз. За

счет этого площадь обзора значительно увеличивается, вызывая обезвоживание

глаз. К тому же если экран установлен высоко, а глаза широко открыты,

нарушается функция моргания. Это значит, что глаза не закрываются полностью,

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

приводит к их быстрой утомляемости.

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

оформление рабочих мест на производстве имеет большое значение как для

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

влияющей на производительность труда.


Дата

Лист

99МГУПИ 230102.12ПЗ

ЗАКЛЮЧЕНИЕ

В ходе дипломной работы были детально изучены наиболее популярные

среди операторов ШПД методы абонентского доступа такие как 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, а также произведено

введение их в эксплуатацию.


Дата

Лист

99МГУПИ 230102.12ПЗ

Спустя месяц упорной работы проект введен в эксплуатацию и на данный

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

этому может служить отсутствие жалоб на плавающую скорость, тогда как до

реализации такие жалобы время от времени присутствовали.


Дата

Лист

99МГУПИ 230102.12ПЗ

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

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с.

Левадний А. Д. Организация абонентского доступа к сети Интернет на

предприятии ООО «Ставропольские коммуникационные сети». Дипломный

проект. – Ставрополь, 2011 г., – 99 с.

Научный руководитель: к.т.н., доцент Бережной В. В.

Рецензент:

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

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

ссылки на них.

«_______»__________________2011 г.

Левадний Александр Дмитриевич _______________________ (подпись)

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

зарегистрирован в журнале под № ___________

__________________ (подпись зав. кафедрой)

Защищён «___» июня 2011 г.

Протокол № _________ от «_____» июня 2011 г.

Оценка: __________________________________

Секретарь ГАК ____________________________ (подпись)

Documents

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