# Указываем tls-ключ

tls-auth keys/ta.key 0

# Таймаут до реконекта

tls-timeout 120

# Выбираем алгоритм хеширования

auth MD5

# Включаем шифрацию пакетов

cipher BF-CBC

# Проверяем активность подключения каждые 10 секунд, если в течении 120 сек. нет ответа, подключение закрывается

keepalive 10 120

# Сжатие трафика

comp-lzo

# От какого пользователя и группы будет работать OpenVPN

user nobody

group nobody

# Не перечитывать ключи после получения SIGUSR1 или ping-restart

persist-key

# Не закрывать и переоткрывать TUN\TAP устройство, после получения SIGUSR1 или ping-restart

persist-tun

# Логгирование

status /var/log/openvpn/openvpn-status.log

log /var/log/openvpn/openvpn.log

# Уровень информации для отладки

verb 3

Создаем файлы с настройками для клиентов. В каталоге /etc/openvpn/ccd на сервере создаем файл office, sklad, mag1, mag2 (имя файла - имя которому выдан сертификат) следующего содержания:

office

ifconfig-push 10.10.200.2 10.10.200.1

iroute 192.168.53.0 255.255.255.0

sklad

ifconfig-push 10.10.200.3 10.10.200.1

iroute 192.168.53.0 255.255.255.0

mag1

ifconfig-push 10.10.200.4 10.10.200.1

mag2

ifconfig-push 10.10.200.5 10.10.200.1

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

На этом настройка сервера заканчивается, запускаем OpenVPN:

colo> service openvpn start

Если все правильно, то должно появиться виртуальное tun устройство:

colo> ifconfig tun0

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.10.200.1 P-t-P:10.10.200.2 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:9 errors:0 dropped:0 overruns:0 frame:0

TX packets:24 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

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

Переходим к настройке клиентов. Все конфигурационные файлы одинаковые, поэтому рассмотрим один из них. На маршрутизаторах office и sklad устанавливаем OpenVPN, так же как и для сервера.

Создадим конфигурационный файл client.conf:

dev tun

proto udp

remote 195.2.240.68 #(реальный ip сервера)

port 5000

client

resolv-retry infinite

ca keys/ca.crt

cert keys/client.crt

key keys/client.key

tls-client

tls-auth keys/ta.key 1

auth MD5

cipher BF-CBC

ns-cert-type server

comp-lzo

persist-key

persist-tun

#добавление маршрута к сети за сервером. Эта строчка не нужна для конфиг. файлов магазинов

up /etc/openvpn_up.sh

status /var/log/openvpn/openvpn-status.log

log /var/log/openvpn/openvpn.log

verb 3

Создадим скрипт openvpn_up.sh для автоматического добавления маршрута:

#!/bin/sh

/sbin/route add -net 172.16.100.0 netmask 255.255.255.0 gw 10.10.200.1 tun0

На этом настройка OpenVPN закончена. Копируем эти файлы на office и sklad. Далее запускаем OpenVPN. Если не запустился, смотрим логи.

Но на этом еще не все. Теперь нам надо включить трансляцию адресов (NAT) чтобы пакеты от клиентской машины, попадая на сервер могли уйти в Интернет и соответственно возвращались назад:

colo> iptables --t nat --A POSTROUTING --s 10.10.200.0/24 --o eth1 --j MASQUERADE

Теперь 3 сети «видят» друг друга. Настроим подключение с магазинов к серверам. На компьютерах в магазинах, стоит операционная система Windows XP. Скачиваем с официального сайта дистрибутив OpenVPN и устанавливаем. Затем в установленном каталоге в папку config кладем наши ключи и конфигурационный файл mag1. После этого можно запускать.

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

Пример вывода нешифрованного трафика:

18:27:15.752295 IP cl230-175-182-213.cl.metrocom.ru.40887 > 195.2.240.68.ssh: . 2826496:2827944(1448) ack 1009 win 10080 <nop,nop,timestamp 2791385847 256970382>

18:27:15.752347 IP 195.2.240.68.ssh > cl230-175-182-213.cl.metrocom.ru.40887: . ack 2783056 win 65535 <nop,nop,timestamp 256970382 2791385774,nop,nop,sack 1 {2785952:2827944}>

18:27:15.755042 IP cl230-175-182-213.cl.metrocom.ru.40887 > 195.2.240.68.ssh: . 2827944:2829392(1448) ack 1009 win 10080 <nop,nop,timestamp 2791385850 256970382>

18:27:15.755096 IP 195.2.240.68.ssh > cl230-175-182-213.cl.metrocom.ru.40887: . ack 2783056 win 65535 <nop,nop,timestamp 256970382 2791385774,nop,nop,sack 1 {2785952:2829392}>

Пример зашифрованного:

18:24:18.247960 IP 195.2.240.68.sieve > cl230-175-182-213.cl.metrocom.ru.sieve: UDP, length 113

18:24:18.248040 IP 195.2.240.68.sieve > cl230-175-182-213.cl.metrocom.ru.sieve: UDP, length 113

18:24:18.250915 IP cl230-175-182-213.cl.metrocom.ru.sieve > 195.2.240.68.sieve: UDP, length 1441

18:24:18.251291 IP 195.2.240.68.sieve > cl230-175-182-213.cl.metrocom.ru.sieve: UDP, length 113

2.2 Реализация на основе технологии SSH

2.2.1 SSH-туннель

Предположим, что офис, склад и магазины (информация о сети в пункте 2.1) работают только на серверах в терминальном режиме. Тогда существует очень простой, а самое главное быстрый способ организации VPN туннеля. С помощью пакета OpenSSH на software маршрутизаторах можно делать шифрованный канал только по одному нужному порту. Для работы с терминальным сервером, клиенты используют протокол RDP, который использует 3389 порт (схема такой работы представлена на рисунке 2.2.2.1). Синим, отмечен ssh-туннель, по которому будет работать RDP протокол.

Рис.2.2.2.1 Использование ssh-туннелей

Реализация, как говорилось раньше, очень проста, только у OpenSSH есть недостаток: при большом простое канала он рвется. Но и для этой проблемы есть простое решение. Пакет autoSSH, по дополнительному порту при простое шлет heartbeat пакет и канал не падает. Создадим 2 канала до двух терминальных серверов:

colo> export AUTOSSH_DEBUG=1

colo> export AUTOSSH_GATETIME=0

colo> export AUTOSSH_PORT=20037

colo> autossh -f -N -g -l root -L 1002:172.16.100.33:3389 195.2.240.68

colo> export AUTOSSH_PORT=20040

colo> autossh -f -N -g -l root -L 1002:172.16.100.34:3389 195.2.240.68

Рассмотрим команды подробнее:

colo> autossh -f -N -g -c aes256 -l root -L 1002:172.6.100.33:3389 195.2.240.68

Параметры:

· -f: Работать в фоновом режиме, а не подключаться на хост;

· -N: Не исполнять удаленные команды;

· -g: Разрешает подключение удаленным хостам;

· -c: Включаем шифрацию;

· -l: Имя пользователя, от которого подключаемся к серверу;

· -L Прописываем, какой локальный порт используем для подключения и на какой сервер и порт подключаемся.

На этом настройка шифрованного туннеля закончена и можно работать! Если нам нужно добавить еще один туннель, то с помощью команды export AUTOSSH_PORT=20050 добавляем еще один порт для посылки heartbeat пакетов и прописываем ту же команду поднятия ssh туннеля, но уже с другим портом.

2.2.2 SSH VPN

Реализуем ту же схему корпоративной сети, которую создавали при помощи пакета OpenVPN, но уже с помощью встроенного в linux системы пакета OpenSSH. Нам хватит рассмотреть соединение 2-х сетей, так как для подключения еще одной сети нужно будет провести те же самые действия.

С версии 4.3, OpenSSH поддерживает устройства tun/tap, позволяющие создавать шифрованный туннель. Это очень похоже на OpenVPN, основанный на TLS.

Шифрованный туннель создается на основе одного TCP соединения, что весьма удобно, для быстрого поднятия простого VPN, на IP.

Сначала нужно дописать в конфигурационный файл OpenSSH строки, что он имеет право создавать устройства tun/tap и заходить с правами root. В конфигурационном файле /etc/ssh/sshd_config, должны стоять следующие опции:

PermitRootLogin yes

PermitTunnel yes

У нас есть две сети, сеть office с адресом 192.168.53.0/24 и сеть colo с адресом 172.16.100.0/24. Для создания защищенной VPN сети нужно проделать следующие действия:

1. Подключится с одного маршрутизатора через SSH на другой с опцией -w;

2. Настройка IP адреса SSH туннеля делается единожды на сервере и на клиенте.

3. Добавить маршрут для обеих сетей.

4. Если нужно, включить NAT на внутреннем интерфейсе шлюза.

Будем подключаться из сети office к сети colo. Соединение начинается с маршрутизатора office, а команды выполняются на маршрутизаторе сети colo, то есть, настраиваем маршрутизатор colo:

#С помощью опции w c параметрами 0:0 говорим, что при подключении создать на клиенте и сервере виртуальные устройства tun0. Параметр -c включает шифрацию, параметр -C сжатие трафика.

office> ssh -c aes256 -C -w0:0 root@195.2.240.68

#Следующие команды уже выполняются на маршрутизаторе сети colo. Задаем ip адрес и маску подсети

colo> ifconfig tun0 10.0.1.1 netmask 255.255.255.252

# Добавляем маршрут до сети office

colo> route add -net 192.168.53.0 netmask 255.255.255.0 dev tun0

# Включаем NAT, если не включен

colo> echo 1 > /proc/sys/net/ipv4/ip_forward

# Прописываем правило с помощью средств iptables для переброса пакетов из VPN сети в реальную

colo> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Теперь настроим машрутизатор office:

office> ifconfig tun0 10.0.1.2 netmask 255.255.255.252

office> route add -net 172.16.100.0 netmask 255.255.255.0 dev tun0

office> echo 1 > /proc/sys/net/ipv4/ip_forward

office> iptables -t nat -A POSTROUTING -o eth1 -j

На этом настройка закончена, VPN сеть построена. Для подключения отдельных компьютеров с операционной системой Windows XP (магазины), используется клиент SSH Putty.

2.3 Оценка производительности каналов корпоративной сети

В разделах 2.1 и 2.2 рассмотрены две технологии (OpenVPN, SSH) создания защищенных корпоративных сетей, используя VPN. На сегодняшний день технология OpenVPN лидирует на рынке построения защищенных сетей, в то время как туннелирование при помощи SSH только начинает входить в повседневность. Для того чтобы понять какую технологию необходимо применить в реальных условиях при конкретных требованиях, предъявляемых корпоративной сети, нужно оценить их производительность и обосновать их достоинства и недостатки.

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

2.3.1 Оценка производительности при использовании технологии OpenVPN

Для построения графиков производительности канала созданного при помощи OpenVPN будем использовать данные, полученные при тестировании из приложения 1.

Рис. 2.3.1 Графики значений RTT

На рис. 2.3.1 представлены графики значений RTT. Из них видно, что разница между каналом без VPN и каналом с использованием VPN, не является существенной. Также включение опции сжатия не влияет на время отклика.



Рис. 2.3.2 Графики пропускной способности канала

На рис. 2.3.2 представлены графики пропускной способности канала, из которых можно сделать следующие выводы:

· При использовании созданного канала VPN с шифрацией с помощью ключа AES-256-CBC потеря в производительности 0,5 мбит/сек, что составило 5,1% от канала без использования VPN;

· При включении сжатия шифрованного трафика наблюдаем прирост скорости в 3 мбит/сек, что составило 32.9%.

Рис.2.3.3 Графики загрузки ЦП

На рис. 2.3.3 представлены графики загрузки ЦП на маршрутизаторах при использовании OpenVPN c шифрацией трафика, при включенном и отключенном сжатии. По средним значениям загрузки, как и полагалось, самую высокую нагрузку дает шифрация трафика с использованием сжатия - 14.992%.

Основываясь на полученных графиках, произведём оценку производительности каналов VPN, построенных при помощи OpenVPN.

1. Критерий «Загрузка ЦП» при полученных значениях является несущественным, так как это маршрутизатор и других процессов требующих большое потребление ЦП нет;

2. Критерий «RTT» также является несущественным, так как разница от времени отклика при опытах без VPN оказалась меньше всего на 0,5 мс;

3. На графиках пропускной способности каналов можно наблюдать падение скорости при использовании средств VPN на 0,5 мбит/сек в среднем. В настоящее время это не является существенным, так как Интернет-провайдеры предоставляют свои услуги на больших скоростях, где такое падение не будет играть большой роли.

4. При использовании сжатия трафика виден заметный прирост к пропускной способности канала, на 3 мбит/сек. Конечно при этом сильно возрастает загрузка на ЦП, но как говорилось раньше, это не играет большой роли.

Подведем итоги. Создавая защищенную корпоративную сеть на основе технологии OpenVPN, получаем одну общую сеть на несколько офисов с шифрацией передаваемых данных и приростом скорости за счет сжатия трафика с удобством обмена информацией. Технология OpenVPN полностью оправдывает себя. Её использование ведет к росту производительности работы с информацией по сети. Из минусов выделяется некоторая сложность настройки и создания VPN сети. Из плюсов - кроссплатформенность.

2.3.2 Оценка производительности при использовании технологии SSH

Для построения графиков производительности канала созданного при помощи SSH будем использовать данные, полученные при тестировании из приложения 2.

Рис.2.3.4. Графики значений RTT

На рис. 2.3.4 представлены графики, по которым можно судить о времени отклика при работе ssh. В среднем время увеличилось на 0.8 мс. Это значение не является критичным даже для самых привередливых программ.

Рис.2.3.5 Графики пропускной способности канала

На рис. 2.3.5 представлены графики пропускной способности канала. Результаты получились приблизительно такими же, что и при использовании OpenVPN.

Рис.2.3.6 Графики загрузки ЦП

На рис. 2.3.6 представлены графики загрузки ЦП при использовании ssh с шифрацией с сжатием трафика и без. При включении шифрации виден большой скачок нагрузки на ЦП. Среднее значение - 37.9%. Это довольно много, но не является критичным.

Из полученных данных можно сделать следующий вывод: производительность при использовании сжатия трафика возросла примерно на 25%, но при этом значительно выросла нагрузка на ЦП. Из достоинств этой технологии хочется выделить возможность создания ssh-туннелей по отдельным портам, что при определенных условиях дает множество плюсов, например, возможность иметь автоматическое включение резервного канала, при отсутствии связи на одном из маршрутизаторов. Также нужно отметить простоту создания и настройки VPN сети, кроссплатформенность, высокая надежность, легкая масштабируемость.

2.3.3 Выбор между технологиями SSH и OpenVPN

Составим сравнительную таблицу, основываясь на полученных опытным путем данных.

	OpenVPN	SSH
Сложность создания	Достаточно сложная настройка. Сложность настройки маршрутизации для нескольких сетей, возможны трудности с firewall.	Легкая настройка, не требующая особых знаний. На все создание уходит не больше 10 минут.
Масштабируемость	Подключение еще одной сети или клиента, влечет изменение конфигурационных файлов на сервере и добавление их на клиента. За счет OpenVPN клиента под Windows имеет преимущество перед SSH. Не требует обучения персонала.	Для подключения еще одной сети нужно повторить те же действия, что и при объединении предыдущих. Для подключения Windows компьютеров, требуется однократное обучение персонала.
Производительность	За счет сжатия можно добиться отличных результатов, превышающих исходное соединение. Сжатие идет выборочно, т.е. что сжать нельзя - пропускается. Это уменьшает нагрузку на ЦП.	Производительность чуть ниже, чем у OpenVPN. Сжимается весь трафик - большие нагрузки на ЦП.
Загрузка ЦП	В среднем не больше 15%	В среднем не больше 38%
Кроссплатформенность	Да	Да
RTT	На 0,5 мс больше, чем у исходного соединения	На 0,8 мс больше, чем у исходного соединения
Документация	Масса документации на официальном сайте. Многочисленные форумы и обсуждения.	Документация есть в встроенном справочнике. Информации по настройке пока что мало.
Доп. возможности	-	Создание ssh-туннелей.
Внедрение в сущ. сеть	Могут быть проблемы с настройкой firewall'а.	Легкое внедрение.
Защищенность	Шифрация 256 битным AES ключом	Шифрация 256 битным AES ключом
Распространенность	Лидирующая технология создания VPN сетей.	Сам протокол ssh существует очень давно, но создание ssh VPN сетей на сегодняшний день встречается редко.

Рассмотрев все плюсы и минусы, предпочтительным решением будет использование обоих технологий вместе. От SSH взять SSH-туннели, а от OpenVPN создание VPN сетей.

Глава 3. Создание комплекса систем мониторинга корпоративной сети

3.1 Слежение за состоянием серверов и сетевого оборудования. Nagios

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

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

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

colo> yum install gcc glibc glibc-common gd gd-devel

# Устанавливаем web-сервер Apache

colo> yum install httpd

# Создаем юзера и группу с правами которых будет работать nagios

colo> useradd -m nagios

colo> groupadd nagcmd

# Создаем пароль для юзера

colo> passwd nagios

# Добавляем nagios и apache в одну группу, чтобы не было проблем с правами на запуск скриптов на web-сервере

colo> /usr/sbin/usermod -a -G nagcmd nagios

colo> /usr/sbin/usermod -a -G nagcmd apache

Ставим систему:

# Скачиваем последнюю версию системы и модули к ней

colo> wget http://osdn.dl.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz

colo> wget http://osdn.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz

# Распаковываем скаченный архив и переходим в каталог

colo> tar xzf nagios-3.2.1.tar.gz

colo> cd nagios-3.2.1

# Конфигурируем установочный пакет и проверяем удовлетворение зависимостей

colo>./configure

# Если все хорошо, прошло без ошибок, собираем пакет и устанавливаем

colo> make all

colo> make install

colo> make install-init

colo> make install-config

colo> make install-commandmode

# Прописываем настройки в Apache

colo> make install-webconf

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

colo> tar xzf nagios-plugins-1.4.11.tar.gz

colo> cd nagios-plugins-1.4.11

colo>./configure

colo> make

colo> make install

# Ставим пароль на вход в web-интерфейс с помощью утилиты htpasswd

colo> htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

# Проверяем правильность конфигурационного файла

colo> /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

# Если ошибок и предупреждений нет, запускаем Nagios и Apache

colo> service nagios start

colo> service httpd restart

Проверить то, что система заработала, можно зайдя на web-интерфейс: http://ip.адрес.сервера/nagios. В нашем случае ip-адрес: 195.2.240.68. Если сервер Apache запущен и сайт системы nagios в конфигурационный файл прописан верно, то должны увидеть страницу авторизации. После ввода связки логин-пароль должна открыться страница приветствия Nagios (рис.3.1.1). Если по какой-то причине этого не произошло, смотрим ошибки в логах apache в каталоге /var/log/httpd.

Рассмотрим навигационное меню:

· Home - Страница приветствия. Можно узнать о возможных обновлениях системы;

· Documentation - Большое количество документации по настройке системы;

· Tactical Overview - Представляет собой сбор краткой информации об объектах, за которыми ведется мониторинг;

· Map - Отображает карту сети, отмечая зеленым цветом работающие сервера и красным отключенные (рис. 3.1.2);

· Hosts - Показывает состояние каждого наблюдаемого объекта в отдельности

· Services - Показывает состояние запущенных процессов на серверах, а также RTT, количество свободного места, загрузка процессора и памяти(рис. 3.1.3);

· Event log - Отчеты системы мониторинга.

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

Рис.3.1.2 Представление пункта меню Map

Рис.3.1.2 Представление пункта меню Services

Система мониторинга Nagios работает на нескольких конфигурационных файлах, с помощью которых настраиваются методы слежения и объекты, за которыми следим. Расположены эти файлы в директории /usr/local/nagios/etc.

Рассмотрим их подробнее:

1. nagios.cfg - Главный конфигурационный файл. В нём описано, где лежат остальные файлы, объявлены переменные, настраивается система логов, под каким пользователем работать и т.д.;

2. commands.cfg - Файл, в котором описаны команды для опроса серверов о их работоспособности, запущенных процессов и т.д.;

3. contacts.cfg - Описаны контакты, которым надо посылать оповещения системы о сбоях на серверах;

4. groups.cfg - Описываются группы и сервера, которые в них входят;

5. hosts.cfg - Описывается шаблон для добавляемого оборудования. В нём указывается период опроса серверов, время отсылки предупреждений;

6. WindowsServer.cfg - Пример описания Windows сервера;

7. LinuxServer.cfg - Пример описания Linux сервера.

Опрос серверов идет по протолку SNMP (Simple Network Management Protocol -- протокол простого управления сетями). Для слежения за Windows серверами, нужно дополнительно поставить программу Nsclient++.

Рассмотрим пример конфигурационного файла Windows сервера:

define host

{

# Используем шаблон, созданный заранее

use generic-host ;

# Имя сервера

host_name sql-1c ;

# Альяс на имя (псевдоним)

alias sql-1c ;

# Указываем, есть ли перед этим сервером еще один сервер. Это нужно для древовидного представления сети

parents vh0.arscraft.ru ;

# Ip адрес сервера

address 172.16.100.34 ; IP address of the host

# Иконка для отображения в web-интерфейсе. Необязательный параметр

icon_image 1c.jpg

statusmap_image 1c.jpg

# Дополнительную информацию о сервере можно записать здесь

notes_url http://vh0.arscraft.ru/nagios/notes/info-sql1c.txt

}

# Объявляем сервисы, за которыми будем следить. Так как это 1С и sql сервер, будем следить за работоспособностью этих процессов, а также за нагрузкой на процессор.

# Следим за 1С процессом

define service{

use generic-service

host_name sql-1c

service_description Ragent

check_command check_nt!PROCSTATE!-d SHOWALL -l ragent.exe

}

# Следим за sql процессом

define service{

use generic-service

host_name sql-1c

service_description SQL-Server

check_command check_nt!PROCSTATE!-d SHOWALL -l sqlservr.exe

}

# Следим за нагрузкой на процессор

define service{

use generic-service

host_name sql-1c

service_description CPU Load

check_command check_nt!CPULOAD!-l 5,80,90

}

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

colo> usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Если ошибок и предупреждений нет, перезагружаем Nagios:

colo> service nagios reload

Можно зайти на сайт и посмотреть что получилось.

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

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

***** Nagios *****

Notification Type: PROBLEM

Host: 1c-sql

State: DOWN

Address: 172.16.100.34

Info: (Host Check Timed Out)

Date/Time: Tue Apr 12 09:43:56 MSD 2011

В результате установки и настройки системы Nagios появляются следующие возможности мониторинга корпоративной сети:

· Мониторинг сетевых служб (SMTP, POP3, HTTP, NNTP, ICMP и т.д.);

· Мониторинг состояния хостов (загрузка процессора, использование диска, системные логи) в большинстве сетевых операционных систем;

· Простая архитектура модулей расширений (плагинов) позволяет, используя любой язык программирования по выбору (Shell, C++, Perl, Python, PHP, C# и другие), легко разрабатывать свои собственные способы проверки служб;

· Параллельная проверка служб;

· Возможность определять иерархии хостов сети с помощью «родительских» хостов, позволяет обнаруживать и различать хосты, которые вышли из строя, и те, которые недоступны;

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

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

· Автоматическая ротация лог-файлов;

· Возможность организации совместной работы нескольких систем мониторинга с целью повышения надёжности и создания распределенной системы мониторинга;

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

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

3.2 Слежение за производительностью серверов. Cacti

Cacti -- open-source веб-приложение, система позволяет строить графики при помощи RRDtool. Cacti собирает статистические данные за определённые временные интервалы и позволяет отобразить их в графическом виде. Преимущественно используются стандартные шаблоны для отображения статистики по загрузке процессора, выделению оперативной памяти, количеству запущенных процессов, использованию дисковых ресурсов, использованию входящего/исходящего трафика.

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

Устанавливать и настраивать систему будем на маршрутизатор colo. Система Cacti требует большого количества дополнительного ПО. Веб-сервер у нас уже установлен, поэтому этот пункт пропускаем и начинаем установку:

# Устанавливаем дополнительное ПО: Mysql, php, perl и библиотеки для них

colo> yum install mysql mysql-server mysql-devel httpd httpd-devel php php-mysql php-gd phpimap

php-ldap php-odbc php-pear php-xml php-xmlrpc php-mcrypt curl curl-devel perl-lib libxml2 php-mbstring phpmyadmin

# Запускаем mysql. Одновременно происходит его конфигурация

colo> service mysqld start

Переходим к установке Cacti:

# Установим зависимости нужные Cacti

colo> yum install -y net-snmp net-snmp-utils rrdtool php-snmp

# Добавляем в автозагрузку и запустим сервис SNMP

colo> chkconfig snmpd on

colo> service snmpd start

# Скачиваем пакеты Cacti:

colo> wget www.cacti.net/downloads/cacti-0.8.7g.tar.gz

colo> wget www.cacti.net/downloads/pia/cacti-plugin-0.8.7g-PA-v2.9.tar.gz

# Разархивируем их

colo> tar -xzvf cacti-0.8.7g.tar.gz

colo> tar -xzvf cacti-plugin-0.8.7g-PA-v2.9.tar.gz

# Создаём рабочую папку Cacti на сервере

colo> mkdir /var/www/cacti

# Копируем содержимое распакованной папки Cacti в рабочую папку Cacti

colo> cp -rf cacti-0.8.7g/* /var/www/cacti/

# Создаём в системе юзера для Cacti и дадим ему соответствующие права

colo> useradd -c CactiUser -d /var/www/cacti/ -s /sbin/nologin cactiuser

colo> chown -R cactiuser /var/www/cacti/log /var/www/cacti/rra

# Создаём базу данных для Cacti с привилегиями для cactiuser:

colo> mysql -u root -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 55

Server version: 5.0.77 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create database cacti;

mysql> GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY 'password';

mysql> flush privileges;

mysql> quit

# Импортируем структуру Cacti в ее базу

colo> mysql -u cactiuser -p cacti < /var/www/cacti/cacti.sql

Enter password: (password)

# Настраиваем доступ Cacti в ее базу данных

colo> nano /var/www/cacti/include/config.php

$database_type = "mysql";

$database_default = "cacti";

$database_hostname = "localhost";

$database_username = "cactiuser";

$database_password = "password";

$database_port = "3306";

# Переходим в рабочую директорию Cacti и устанавливаем фиксы официальными патчами

colo> cd /var/www/cacti

colo> wget www.cacti.net/downloads/patches/0.8.7g/data_source_deactivate.patch

colo> wget www.cacti.net/downloads/patches/0.8.7g/graph_list_view.patch

colo> wget www.cacti.net/downloads/patches/0.8.7g/html_output.patch

colo> wget www.cacti.net/downloads/patches/0.8.7g/ldap_group_authenication.patch

colo> wget www.cacti.net/downloads/patches/0.8.7g/script_server_command_line_parse.patch

colo> wget www.cacti.net/downloads/patches/0.8.7g/ping.patch

colo> wget www.cacti.net/downloads/patches/0.8.7g/poller_interval.patch

colo> patch -p1 -N < data_source_deactivate.patch

colo> patch -p1 -N < graph_list_view.patch

colo> patch -p1 -N < html_output.patch

colo> patch -p1 -N < ldap_group_authenication.patch

colo> patch -p1 -N < script_server_command_line_parse.patch

colo> patch -p1 -N < ping.patch

colo> patch -p1 -N < poller_interval.patch

# Создаем cacti.conf с следующим содержанием, чтобы включить вебдоступ

colo> nano /etc/httpd/conf.d/cacti.conf

Alias /cacti /var/www/cacti

<Directory /var/www/cacti/>

DirectoryIndex index.php

Options -Indexes

AllowOverride all

order deny,allow

deny from all

allow from 192.168.1.0/24 (you can do it like "allow from all")

AddType application/x-httpd-php .php

php_flag magic_quotes_gpc on

php_flag track_vars on

</Directory>

# Перезагружаем веб-сервер Апач

colo> service httpd restart

# Создаём задачу Cron для Cacti

colo> nano /etc/cron.d/cacti

*/5 * * * * cactiuser php /var/www/cacti/poller.php > /dev/null 2>&1

С этого момента можно начать использовать базовую инсталляцию Cacti. Добавление серверов, за которыми будем следить, осуществляется через веб-интерфейс, доступный по адресу: http://ip.адрес.сервера/cacti. Но сначала нужно поставить на отслеживаемые сервера пакет snmp и переписать конфигурационный файл доступа /etc/snmp/snmpd.conf:

syslocation Test.syscontact INF <sysadmin@arscraft.ru>

# sec.name source community (password)

com2sec Mybox localhost public

com2sec cacti ip.адрес.сервера public

com2sec Outside default public

# group.name sec.model sec.name

group RWGroup v2c Mybox

group ROGroup v1 cacti

group ROGroup v2c cacti

group Others v2c Outside

view all included .1 80

view system included system fe

# context sec.model sec.level prefix read write notif

access ROGroup "" any noauth exact all none none

access RWGroup "" v2c noauth exact all all all

access Others "" v2c noauth exact system none all

Примеры получившихся графиков представлены на рисунках 3.2.1, 3.2.2, 3.2.3, 3.2.4.

Рис.3.2.1 График использования Интернет-канала



Рис.3.2.2 График средней загрузки процессора

Рис.3.2.3 График использования дискового пространства

Рис.3.2.4 График отклика сервера(RTT)

3.3 Фильтрация и анализ трафика корпоративной сети

3.3.1 Proxy сервер

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

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

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

Чтобы осуществлять фильтрацию, нужно чтобы весь http трафик проходил через специальный proxy сервер.

Proxy сервер - служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к proxy-серверу и запрашивает какой-либо ресурс (например, e-mail), расположенный на другом сервере. Затем proxy-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (в случаях, если proxy имеет свой кэш). В некоторых случаях запрос клиента или ответ сервера может быть изменён proxy-сервером в определённых целях. Также proxy-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак и помогает сохранять анонимность клиента.

Реализовать переброс запросов на proxy-сервер можно двумя путями:

1. Явно указать в браузере адрес proxy-сервера (не рекомендуется из-за неудобства переключения в случае падения сервера);

2. Пересылать весь трафик, пришедший на порты 80, 8080 маршрутизатора на proxy-сервер при помощи правил iPtables.

В дипломе я буду использовать второй метод. Proxy-сервер будем устанавливать на маршрутизатор colo. В качестве ПО установим proxy-сервер SQUID.

Squid - программный пакет, реализующий функцию кэширующего proxy-сервера для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS. Разработан сообществом как программа с открытым исходным кодом (распространяется в соответствии с GNU GPL). Все запросы выполняет как один неблокируемый процесс ввода/вывода.

Установка производится из стандартного репозитория одной командой:

colo> yum install squid

После первой установки необходимо проинициализировать кеш:

colo> squid -z

Переходим к настройке. Нужно решить следующую задачу - закрыть доступ на развлекательные сайты и социальные сети, закрыть доступ на скачку *.exe, *.sys, *.bat, *.sys, *.mp3, *.avi, *.mp4, *.mov файлов.

Основная конфигурация proxy-сервера находится в файле /etc/squid/squid.conf. Отредактируем его под нашу задачу:

# Указываем порт на котором будем слушать запросы, и указываем тип Proxy «прозрачный», т.к. пересылаем пакеты средствами маршрутизатора

http_port 3128 transparent

# ACL (Access Control List -- список контроля доступа) -- определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено этому субъекту проводить над объектом. С помощью acl описываем объекты, с которыми будем работать

# Описываем объекты и создаем правила доступа к ним

acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl to_localhost dst 127.0.0.0/8

acl SSL_ports port 443

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 # https

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

# Описываем нашу локальную сеть

acl localnet src 172.16.100.0/24

# Описываем файл, в котором записаны расширения запрещенных типов файлов

acl banfiles urlpath_regex -i "/etc/squid/include/permblock.files.acl"

# Описываем файл, в котором записан список сайтов, запрещенных к просмотру

acl banurl dstdomain -i "/etc/squid/include/permblock.url.acl"

# Создаем список для аудио и видео контента с помощью mime типов

acl banvideo rep_mime_type content-type audio

acl banvideo rep_mime_type content-type video

# Запрещаем доступ из сети к запрещенным типам файлов, сайтам и контенту.

http_access deny localnet banfiles

http_access deny localnet banurl

http_reply_access deny all banvideo

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

http_access allow localnet

# Для всех остальных запрещаем всё

http_access deny all

Не забудим оставить права для администратора, добавив нужную acl запись. Рассмотрим файлы с запрещающими списками:

Permblock.files.acl:

\.exe$

\.msi$

\.bat$

\.sys$

Permblock.url.acl:

.vkontakte.ru

.odnoklassniki.ru

.durov.ru

.vk.ru

.youtube

.rutube

…

Осталось перенаправить запросы с 80, 8080 портов на 3128. Добавляем в цепочку iptables следующее правило:

$fw -t nat -A PREROUTING -p tcp -m multiport --dport 80,8080 -i eth1 -j DNAT --to 127.0.0.1:3128

Теперь трафик идет через proxy-сервер с фильтрацией. Также с помощью Proxy-сервера при необходимости можно создавать лимиты по потреблению трафика, работать по расписанию и заменять рекламные баннеры на web-страницах на свои.

3.3.2 Анализатор логов Proxy сервера

Ещё одной из частых задач является анализ трафика по двум причинам:

1. Слежение за деятельностью сотрудника. Предотвращение нарушения дисциплины и правил работы в компании;

2. Создание лимитов на трафик, для снижения расходов компании.

Proxy-сервер Squid при прохождении трафика записывает всю информацию (откуда запрос, что запрашивают, время, размер и т.д.) в log файл. Остается лишь проанализировать его и вывести информацию в удобном для человека виде. Пример лога proxy-сервера Squid:

1305189384.038 340 84.52.97.69 TCP_MISS/200 33232 GET http://www.banius.ru/manager/zakaz/ shop6 DIRECT/77.222.42.202 text/html

1305189384.369 147 84.52.97.69 TCP_MISS/200 7306 GET http://www.banius.ru/manager/modules/ms/images/li.gif shop6 DIRECT/77.222.42.202 text/html

1305189448.705 1001 195.239.137.178 TCP_MISS/200 1363 POST http://mail.google.com/a/banius.ru/? shop7 DIRECT/74.125.79.18 text/javascript

1305189550.826 243750 195.239.137.178 TCP_MISS/200 638 GET http://mail.google.com/a/banius.ru/channel/bind? shop7 DIRECT/74.125.79.18 text/plain

Анализировать трафик будем специальным бесплатным ПО LightSquid.

Все необходимые компоненты (Perl, Gd, httpd) уже были установлены раньше, поэтому переходим непосредственно к установка LightSquid:

Скачиваем с сайта http://lightsquid.sourceforge.net/ последнюю версию программы версии 1.8.

# Разархивируем скаченный архив в каталог /var/www/html/

colo> tar -xzf lightsquid-1.8.tgz

colo> cd lightsquid-1.8

# Даем права на выполнение скриптов

colo> chmod +x *.cgi

colo> chmod +x *.pl

colo> chown -R apache:apache *

# Вносим изменения в файл конфигурации Apache /etc/httpd/conf/httpd.conf

Alias /lightsquid "/usr/local/www/lightsquid-1.8"

<Directory "/var/www/html/lightsquid-1.8">

AddHandler cgi-script .cgi

AllowOverride All

</Directory>

# Перезагружаем web-сервер для применения изменений

colo> service httpd restart

# Переходим в каталог с распакованным lightsquid

colo> cd /var/www/html/lightsquid-1.8

# Проверяем на правильность файл конфигурации. Если выдает ошибки, скорее всего неправильно написаны пути до нужных программе каталогов. Исправить это можно в файле lightsquid.cfg

colo> ./check-setup.pl

# Если ошибок нет, то добавляем задачу анализа трафика каждые полчаса в cron

colo> crontab -e

*/55 * * * * /var/www/html/lightsquid-1.8/lightparser.pl

На этом установка закончена. При необходимости, есть возможность занести адреса, с которых идет трафик, в группы и дать им имена.

Проверить работу можно по адресу http://ip.адрес.сервера/lightsquid.

Пример работы анализатора трафика представлен на рисунках 3.3.2.1, 3.3.2.2, 3.3.2.3.



Рис.3.2.2.1 Пример отчета LightSquid

Рис.3.2.2.2 Посещенные сайты

Рис.3.2.2.3 График по использованию трафика по дням

3.4 Учет трафика корпоративной сети. Разработка web интерфейса

Если слежение за деятельностью сотрудника можно реализовать средствами анализа http трафика, то задача подсчета трафика решается только частично, так как считается только http трафик.

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

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

IPCad (Cisco IP accounting simulator) -- это программа для учета трафика, которая может вести подсчет несколькими механизмами, например через интерфейсы BPF, libpcap и iptables. Есть один недостаток: результаты выводятся прямо в консоль, без какой-либо фильтрации. Поэтому к пакету IPCad нужно доработать интерфейс.

Начнем с установки IPCad:

router> wget http://lionet.info/soft/ipcad-3.6.6.tar.gz

# Распаковываем архив и переходим в каталог

router>tar -xvzf ipcad-3.6.6.tar.gz

router>cd ipcad-3.6.6

# Конфигурируем пакет

router>./configure

# Собираем и устанавливаем пакет

router>make

router>make install

# Переделываем конфигурационный файл под свои нужды

router> nano /usr/local/etc/ipcad.conf

# Указываем не разбирать трафик по портам. Эта опция сильно нагружает маршрутизатор

capture-ports disable;

# Указываем, какой интерфейс слушать

interface eth1;

# Настройки программы по умолчанию

netflow export version 5;

netflow export destination 127.0.0.1 9998;

pidfile = /var/run/ipcad.pid;

dumpfile = ipcad.dump;

buffers = 64k;

# Разделять статистику по каждому IP-адресу для подсети 192.168.23.0/24.

# «aggregate 192.168.0.0/24» указывает ipcad диапазон адресов сети.

# «strip 32» означает, что в статистику необходимо заносить все 32 бита адреса, принадлежащего данному адресному диапазону

aggregate 192.168.23.0/24 strip 32;

# Описываем политики доступа к статистике ipcad. root может полностью управлять (делать backup, просматривать и изменять таблицы подсчета). Все остальные могут лишь просматривать статистику.

rsh enable at 127.0.0.1;

rsh root@127.0.0.1 admin;

rsh root@127.0.0.1 backup;

rsh root@127.0.0.1;

rsh 127.0.0.1 view-only;

# “Время жизни” и тайм-аут IP пакета.

rsh ttl = 3;

rsh timeout = 30;

# Опция 'memory_limit задает количество памяти для хранения содержимого одного потока данных.

memory_limit = 10m;

Для получения статистики запускаем программу:

colo> /usr/local/bin/ipcad -rds

colo> rsh localhost show ip accounting

Получим вывод в консоль:

…

192.168.23.14 83.156.177.10 1 131

178.67.60.119 192.168.23.14 1 305

192.168.23.14 202.152.243.92 1 131

192.168.23.14 178.67.60.119 1 131

192.168.23.14 77.77.44.16 1 131

192.168.23.196 192.168.23.201 2873 186687

192.168.23.201 192.168.23.196 4274 3838143

Accounting data age is 4

Accounting data age exact 269

Accounting data saved 1305215070

Interface eth1: received 375320822, 5 m average 41518 bytes/sec, 60 pkts/sec

Flow entries made: 569

NetFlow cached flows: 27

Memory usage: 0% (63728 from 10485760)

Free slots for rsh clients: 9

IPCAD uptime is 49 days 51 minutes

Такой результат не всем будет понятен, да и запускать программу вручную не самый удобный способ подсчитывать трафик. Для решения этой проблемы нужно создать удобный веб-интерфейс. Всю информацию о трафике будем заносить в базу данных СУБД MySql. Создаем базу данных stat и нужные нам таблицы (users, download, upload, tmp), в которые будем записывать статистику.

Создадим скрипт “stat.sh”, который будет запускать команду получения статистики и записывать результат в файл, а затем запускать скрипт “collect.pl“, отвечающий за добавление информации в базу данных.

Скрипт stats.sh:

#!/bin/bash

rsh 127.0.0.1 clear ip accounting > /dev/null

rsh 127.0.0.1 show ip accounting checkpoint > /tmp/ipcad.stat

/usr/local/etc/collect.pl

rm /tmp/ipcad.stat

Часть скрипта collect.pl :

#!/usr/bin/perl

use DBI;

#Логин / пароль

$dbuser = "root";

$dbpassword = "password";

dbh = DBI->connect("DBI:mysql:stat:localhost",$dbuser,$dbpassword) or die "can't connect to database ", $dbh->errstr, __LINE__;

open(FIL, "/tmp/ipcad.stat") || die;

while($line=<FIL>) {

@mass = split(" ",$line);

$dbh -> do ("INSERT INTO `tmp` ( `id` , `date` , `time` , `src` , `srcp` , `dst` , `dstp` , `bytes` , `proto`,`class` ) VALUES ('', CURDATE( ) , CURTIME( )$

}

close(FIL);

Скрипт stat.sh нужно запускать каждые 20-25 минут, поэтому добавляем задачу в cron:

router> crontab -e

0,20,40,55 * * * * /usr/local/etc/stat

Тепрь все нужные данные находятся в базе данных, осталось только вытащить их на сайт. Для этого разрабатываем несколько web-страниц. Код главной страницы index.php находится в приложении 3.

В итоге получаем систему подсчета трафика в удобном табличном виде (рис. 3.4.1), со следующими возможностями:

· Учет любого трафика для каждого пользователя отдельно;

· Установка лимита трафика, при превышении которого на почту системному администратору приходит извещение.

Рис.3.4.1 Таблица ипользования Интернет трафика

Заключение

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

1. Построена защищенная корпоративная сеть на основе VPN, используя технологии OpenVPN и SSH;

1. Рассмотрены методы организации VPN сетей: клиент-серверный, туннелирование, точка-точка;

2. Получены табличные значения пропускной способности защищенных интернет каналов для технологий OpenVPN и SSH. Дана практическая оценка производительности этих каналов созданной копроративной сети. Полученные результаты позволяют сделать общий вывод: при построении корпоративной сети целесообразно использовать обе технологии - с помощью OpenVPN создавать защищенные сети, с помощью SSH - ssh-туннели и создание подключений для администрирования;

3. Рассмотрены решения для мониторинга корпоративной сети: Nagios, Cacti, Ipcad, LightSquid. Сделан вывод об использовании этих решений в одном комплексе;

4. С целью фильтрации трафика и слежения за деятельностью персонала установлен, настроен и введен в работу proxy-сервер;

5. Введена в эксплуатацию система мониторинга, состоящая из рассмотренных в работе компонентов: Nagios, Cacti, Ipcad, LightSquid;

6. Разработан web-интерфейс для системы учета трафика.

Список используемой литературы

1. А.В. Соколов, В.Ф.Шаньгин. Защита информации в распределенных корпоративных сетях и системах. - М.:ДМК Пресс, 2002. - 656с.

2. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. - 2001 г. 668 с.

3. Олег Колесников, Брайан Хетч. LINUX. Создание виртуальных частных сетей (VPN). - Издательство "КУДИЦ-ОБРАЗ" 2002 г. 464 с.

4. Свободная энциклопедия, URL: http://www.wikipedia.org

5. Статьи о linux системах, URL: http://www.opennet.ru/

6. Статьи об установке и настройке различных пакетов программ под Linux/Unix системы,URL: http://www.lissyara.su/

7. Коллективный блог новостей, аналитических статей, связанных с высокими технологиями и Интернетом, URL: http://habrahabr.ru/

Приложение 1

Таблица значений пропускной способности Интернет канала, используя OpenVPN.

№	Без VPN	OpenVPN
		AES-256-CBC	Шифрование с сжатием трафика
	RTT	Скорость	RTT	Скорость	Цп №1	Цп №2	RTT	Скорость	Цп №1	Цп №2
1	1,438	9,57	2,016	9,10	7,7	6	1,856	12,10	10,7	8,3
2	1,551	9,51	1,925	9,10	4,7	8,3	2,119	12,10	17	8,7
3	1,532	9,58	1,990	9,10	6,6	6,3	2,245	12,10	10,7	8,3
4	1,474	9,59	2,246	9,09	6	8,7	2,236	12,10	25,6	11
5	1,481	9,59	2,258	9,10	5,7	8	2,191	12,10	10,3	8,7
6	1,471	9,59	2,344	9,10	7,7	6,3	2,212	12,10	10,3	8,7
7	1,694	9,50	2,360	9,10	8,3	8,7	2,262	12,10	7,3	7,7
8	1,519	9,58	2,285	9,10	3	8,7	2,304	12,10	30,1	11,7
9	1,470	9,59	2,336	9,09	7,6	6,3	2,208	12,10	12,7	8,7
10	1,470	9,60	2,317	9,09	6,3	8,3	2,212	12,10	11	8,7
11	1,575	9,58	2,282	9,09	6,3	8,7	2,258	12,10	23,3	11,7
12	1,475	9,59	2,319	9,10	6	6,7	2,203	12,10	14	8,3
13	1,686	9,60	2,224	9,09	4,7	8,7	2,267	12,10	10,7	7,7
14	1,725	9,59	2,258	9,10	4	8,3	2,238	12,10	10,3	11,3
15	1,706	9,58	1,941	9,09	7,7	6,7	2,312	12,10	29,3	8,7
16	1,744	9,60	2,155	9,10	6,7	8,7	2,187	12,10	11	8,3
17	1,551	9,60	2,313	9,09	7,3	6,3	2,224	12,10	9,7	11
18	1,529	9,60	2,226	9,10	7,3	8,7	2,190	12,00	8,3	9
19	1,449	9,58	2,240	9,09	8,7	8	2,288	12,00	31,3	9,3
20	1,467	9,62	2,218	9,10	8	8,3	2,176	12,10	11,3	9,7
21	1,499	9,59	2,200	9,10	7	8,7	2,196	12,10	11	9,3
22	1,399	9,60	2,283	9,09	9,7	6,3	2,150	12,10	21	8,7
23	1,545	9,59	2,264	9,10	7	8	1,825	12,10	16	7,3
24	1,530	9,59	2,278	9,09	6,6	8,7	2,226	12,10	11,6	12,7
25	1,374	9,58	2,244	9,09	8,7	8,3	2,273	12,10	10,3	8,3
Ср	1,534	9,584	2,221	9,096	6,772	7,788	2,194	12,092	14,992	9,272

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

· № - номер опыта. Под опытом понимаем передачу файла из одной сети в другую в течении 10 секунд;

· Без VPN - опыты производились без использования технологии VPN;