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


Настройка L2TP для модели хост-хост



страница13/13
Дата04.11.2016
Размер5.4 Mb.
Просмотров3339
Скачиваний0
1   ...   5   6   7   8   9   10   11   12   13

4.4 Настройка L2TP для модели хост-хост


Будет реализована схема на рис 1.24

l2tp_хост-хост.jpgРисунок 1.24 соединение хост-хост по протоколу L2TP

4.4.1Настройка сервера FreeBSD_L2TP_server в качестве L2TP-сервера


Для настройки протокола L2TP необходим установленный программный пакет MPD5, процесс установки которого описан в пункте 4.3.1. Вся настройка MPD5 для работы в качестве L2TP сервера сводиться к тому, что просто редактируется файл mpd.conf до следующего вида:

startup:


set user foo bar admin

set user foo1 bar1

set console self 127.0.0.1 5005

set console open

set web self 0.0.0.0 5006

set web open

default:

load l2tp_server

l2tp_server:

# Создаем диапазон присваеваемых IP адрессов.

# Define dynamic IP address pool.

set ippool add pool1 10.10.0.5 10.10.0.100

# Create clonable bundle template named B

create bundle template B

set iface enable proxy-arp

set iface idle 1800

set iface enable tcpmssfix

set ipcp yes vjcomp

# Specify IP address pool for dynamic assigment.

set ipcp ranges 10.10.0.1/24 ippool pool1

set ipcp dns 10.10.0.1

# The five lines below enable Microsoft Point-to-Point encryption

# (MPPE) using the ng_mppc(8) netgraph node type.

set bundle enable compression

set ccp yes mppc

set mppc yes e40

set mppc yes e128

set mppc yes stateless

# Create clonable link template named L

create link template L l2tp

# Set bundle template to use

set link action bundle B

# Multilink adds some overhead, but gives full 1500 MTU.

set link enable multilink

set link yes acfcomp protocomp

set link no pap chap

set link enable chap

set link keep-alive 10 60

# We reducing link mtu to avoid GRE packet fragmentation

set link mtu 1460

# Configure l2tp

# IP адресс нашего VPN сервера. (Собственно адресс машины с фряхой)

set l2tp self 192.168.222.1

# Allow to accept calls

set link enable incoming

Сохраняем изменения и редактируем уже файл с паролями (mpd.secret):

test testpass 10.10.0.5

Добавляем mpd в автозапуск

echo 'mpd_enable="YES"' >> /etc/rc.conf

Теперь можно запустить mpd5:

/usr/local/etc/rc.d/mpd5 start

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

Этими действиями мы настроили MPD5 на работу в режиме L2TP сервера.

4.4.2 Настройка сервера FreeBSD_L2TP_client в качестве L2TP-клиента


Для того чтобы MPD5 работал в качестве L2TP-клиента, необходимо привести файл конфигурации mpd.conf к следующему виду:

startup:


default:
        load MIEM_L2TP

MIEM_L2TP:


        create bundle static L2TP
        set bundle disable compression
        set bundle disable round-robin
        set bundle disable encryption
        set bundle disable crypt-reqd
        set bundle disable bw-manage
        set bundle disable ipv6cp
        set bundle enable ipcp
        set ipcp no vjcomp
        set iface mtu 1460
        set iface idle 0
        set iface enable tcpmssfix

# пути к скриптам настроек для соединения


        set iface up-script /usr/local/etc/mpd5/up.sh
        set iface down-script /usr/local/etc/mpd5/down.sh
        create link static L2 l2tp
        set link action bundle L2TP
        set link latency 0
        set link max-redial 0
        set link disable incoming acfcomp protocomp magicnum check-magic shortseq
        set link deny chap-msv2 chap-msv1 pap eap acfcomp protocomp shortseq
        set link accept chap-md5
        set link keep-alive 10 75

# адрес сервера, к которому подключаться


        set l2tp peer 192.168.222.1

#Поля логин и пароль


        set auth authname "test"
        set auth password "testpass"

open


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

Создадим скрипты настроек маршрутизации по-умолчанию при запуске туннеля и его остановке (файлы up.sh и down.sh) и дадим им права на выполнение:

touch /usr/local/etc/mpd5/up.sh

chmod +x /usr/local/etc/mpd5/up.sh

touch /usr/local/etc/mpd5/up.sh

chmod +x /usr/local/etc/mpd5/up.sh

Отредактируем файл up.sh до следующего вида:

#!/bin/sh


# Set gateway
gw=`netstat -rn | awk '$1=="default"{print $2}'`
route delete $4
route add $4 $gw
route delete default
route add default $4
echo $4  > /tmp/mpd_dr
echo $gw > /tmp/mpd_gw

Файл down.sh должен иметь вид:

#!/bin/sh
dr=`cat /tmp/mpd_dr`
gw=`cat /tmp/mpd_gw`
route delete $dr
route delete default
route add default $gw
rm -f /tmp/mpd_dr
rm -f /tmp/mpd_gw

После этих действий можно запускать MPD на сервере FreeBSD_L2TP_client.

Добавляем mpd в автозапуск и запускаем:

echo 'mpd_enable="YES"' >> /etc/rc.conf

/usr/local/etc/rc.d/mpd5 start

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

Этими действиями мы настроили MPD5 на работу в режиме L2TP клиента.

Теперь, необходимо убедиться, что на обоих серверах создано новое сетевое соединение и что сервера могут свободно общаться через L2TP-туннель. Для этого выполним команду ifconfig на обоих серверах. На каждом должно появиться новое устройство ng0, что демонстрирует рисунок 1.25 и 1.26.



Рис. 1.25 ifсonfig на сервере FreeBSD_L2TP_server

Рис. 1.26 ifсonfig на сервере FreeBSD_L2TP_client

Как видно из рисунков 1.25 и 1.26 серверу выдается адрес 10.10.0.1, а клиенту 10.10.0.5.

Теперь, необходимо проверить прохождение пакетов через наш туннель. Будем обмениваться icmp-пакетами с помошью команды ping с сервером FreeBSD_L2TP_server с сервера FreeBSD_L2TP_server. В это время на сервере FreeBSD_L2TP_server будет запущена утилита tcpdump, которая будет прослушивать туннельный адаптер ng0. Рис. 1.27 это демонстрирует.

Рис. 1.27 ifсonfig и tcpdump на серверах FreeBSD_L2TP_client и FreeBSD_L2TP_server

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



4.5 Настройка IPSec для модели сеть-сеть


Будет реализована схема на рисунке 1.28:

ipsec_сеть-сеть.jpgРис 1.28 соединение сеть-сеть по протоколу IPSec

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

options IPSEC_NAT_T

Это не так. Нормально данная опция работает только с оборудованием фирмы CISCO. Что к данной модели – не применимо.

Убедитесь, что в rc.conf отсутствует опция включения NAT.

4.5.1 Включение поддержки IPSec в ядре FreeBSD на серверах FreeBSD_IPSec_server и FreeBSD_IPSec_client


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

  • options IPSEC – включает поддержку IPSec;

  • options IPSEC_NAT_T – включает поддержку работы протокола IPSec за NAT;

  • options IPSEC_FILTERTUNNEL - функция представлена для расширения возможности фильтровать туннелируемые пакеты;

  • options IPSEC_DEBUG – включает отладочный режим, для подробного отчета в логах;

  • device cryptoвключение поддержки gif интерфейса, через который будет идти зашифрованный трафик.

Для этого создадим свой файл конфигурации ядра в каталоге kernels в домашней директории пользователя server, скопировав его из системного каталога /usr/src/sys/i386/conf/:

mkdir /home/server/kernels

cp /usr/src/sys/i386/conf/GENERIC /home/server/kernels/server

cd /usr/src/sys/i386/conf

ln –s /home/server/kernels/server

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

nano server

options IPSEC

options IPSEC_NAT_T

options IPSEC_FILTERTUNNEL

options IPSEC_DEBUG

device crypto

Теперь, переходим в каталог /usr/src и даем команду на сборку, установку ядра и последующую перезагрузку.

make buildkernel KERNCONF=server

make installkernel KERNCONF=server

reboot


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

4.5.2 Настройка виртуального интерфейса gif


Для настройки gif интерфейсов, необходимо на обоих серверах открыть файл /etc/rc.conf и добавить в него строки:

gif_interfaces=”gif1” # на клиенте – gif0

gifconfig_gif1=192.168.5.23 192.168.5.21 # настраиваем интерфейс на #соединение по реальным IP-адресам.

# на клиенте эта строчка примет вид gifconfig_gif1=192.168.5.21 192.168.5.23

static_routes=”vpn” # заводим статический маршрут под именем vpn

route_vpn=”192.168.55.0/24 –interface gif1” # любой пакет адресованный в #сеть 192.168.55.0/24 будет принудительно проходить через gif-интерфейс.

#на клиенте это выглядело бы так: route_vpn=”192.168.44.0/24 –interface gif0”

export route_vpn # загрузить статический маршрут при каждом запуске сервера.

После добавления этих строк в конфигурационные файлы серверов FreeBSD_IPSec_server и FreeBSD_IPSec_client, необходимо перезагрузить сервера и ввести команду ifconfig gif1 на сервере и ifconfig gif0 на клиенте. Результаты этих команд показаны на рисунке 1.29.

Рис 1.29 результат команды ifconfig gif 1 и ifconfig gif0

Далее, необходимо проверить, работает ли туннель. Если с сервера FreeBSD_IPSec_server делать ping до сервера FreeBSD_IPSec_client, то пакеты должны идти. Рисунок 1.30 демонстрирует это:



Рис 1.30 Обмен пакетами между FreeBSD_IPSec_server и FreeBSD_IPSec_client

После того, как туннель заработал, можно перейти непосредственно к настройке IPSec. Для настройки параметров безопасности (security associations) есть два варианта. Можно настроить их вручную для обоих серверов, задав алгоритм шифрования, ключи для шифрования и так далее, или использовать демоны, реализующие Internet Key Exchange protocol (IKE), который сделает это за нас.

Рекомендуется второе. Помимо прочего, этот способ более прост.

Редактирование и отображение политики безопасности выполняется с помощью setkey. По аналогии, setkey используется для настройки таблиц политики безопасности ядра так же, как route используется для настройки таблиц маршрутизации ядра. Setkey также может отображать текущие параметры безопасности, и продолжая аналогию дальше, это соответствует netstat –r.

Существует множество демонов для управления параметрами безопасности в FreeBSD. Здесь будет описано использование одного из них, racoon — он доступен в составе порта ipsec-tools.

4.5.3 Настройка демона racoon


Даемон racoon должен работать на обоих серверах. На каждом из серверов он настраивается с IP адресом другого конца VPN, и секретным ключом (должен быть одним и тем же на обоих серверах).

Эти два демона подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный нами). Затем демоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много — он сломал ключ, который два демона уже сменили на другой.

Настройки racoon сохраняются в файле /usr/local/etc/racoon/racoon.conf. Другим компонентом настройки racoon, который потребуется изменить, является «предварительный ключ», который racoon ищет в файле /usr/local/etc/raccoon/raccoon.conf.

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

Psk.txt содержит строку для каждого удаленного сервера, с которым происходит соединение. В нашем примере два сервера. Каждый файл psk.txt будет содержать одну строку (каждый конец VPN общается только с другим концом).

На сервере FreeBSD_IPSec_server эта строка будет выглядеть так:

192.168.5.21 hello

То есть публичный IP-адрес противоположной стороны, пробел и текстовая строка c секретной фразой.

На сервере FreeBSD_IPSec_client эта строка будет выглядеть так:

192.168.5.23 hello

То есть публичный IP адрес удаленной стороны и та же секретная фраза.

Теперь отредактируем на обоих серверах файл racoon.conf до следующего вида:

path pre_shared_key "/usr/local/etc/racoon/psk.txt";

log info;

padding {

maximum_length 20;

randomize off;

strict_check off;

exclusive_tail off;

}

listen {



isakmp 192.168.5.23; # на клиенте будет 192.168.5.21

strict_address;

# adminsock "/var/db/racoon/racoon.sock";

}

timer {



counter 5;

interval 20 sec;

persend 1;

phase1 30 sec;

phase2 15 sec;

}

remote 192.168.5.21 { # на клиенте будет 192.168.5.23



exchange_mode aggressive,main;

lifetime time 24 hour;

my_identifier address;

peers_identifier address;

passive off;

generate_policy off;

proposal {

encryption_algorithm 3des;

hash_algorithm sha1;

authentication_method pre_shared_key;

dh_group 2;

}

}



sainfo anonymous {

encryption_algorithm 3des;

authentication_algorithm hmac_md5, hmac_sha1;

lifetime time 1 hour ;

compression_algorithm deflate;

}

После изменения конфигурационного файла, необходимо добавить правила политик безопасности для трафика, который мы будем шифровать. Например, для трафика идущего от сервера FreeBSD_IPSec_server это правило будет эквивалентно словам:



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

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

Для сервера FreeBSD_IPSec_client будет то же самое, но наоборот (в обратную сторону).

Теперь, нам необходимо создать эти правила на обоих серверах. На сервере FreeBSD_IPSec_server отредактируем файл /usr/local/etc/ipsec.conf до следующего содержания:

flush;

spdflush;



spdadd 192.168.44.0/24 192.168.55.0/24 any -P out ipsec esp/tunnel/192.168.5.23-192.168.5.21/require;

spdadd 192.168.55.0/24 192.168.44.0/24 any -P in ipsec esp/tunnel/192.168.5.21-192.168.5.23/require;

На сервере FreeBSD_IPSec_client этот файл будет иметь обратный вид:

flush;


spdflush;

spdadd 192.168.55.0/24 192.168.44.0/24 any -P out ipsec esp/tunnel/192.168.5.21-192.168.5.23/require;

spdadd 192.168.44.0/24 192.168.55.0/24 any -P in ipsec esp/tunnel/192.168.5.23-192.168.5.21/require;

После этого необходимо запустить racoon и IPSec на обоих серверах. Это делается добавлением в rc.conf следующих строк:

ipsec_enable="YES"

ipsec_file="/usr/local/etc/ipsec.conf"

racoon_enable="YES"

racoon_create_dirs="YES"

Сохраняем изменения, перезагружаем сервера.

После перезагрузки, необходимо убедиться в том, что туннель работает правильно. Для этого, на сервере FreeBSD_IPSec_server запустим tcpdump на интерфейсе gif1, а с сервера FreeBSD_IPSec_client будет командой ping обмениваться пакетами с FreeBSD_IPSec_server (рис. 1.31).



Рис. 1.31 Результат ping и tcpdump

Еще немного теории.

Существует 2 базы. SAD и SPD. С обеими работа осуществляется через утилиту setkey.

SA [setkey -D] - связь (ассоциация) безопасности. Это термин IPSec для обозначения соединения. При установленном соединении для каждого используемого протокола создается пара SA. Пара, т.к. SA - это однонаправленное соединение, а данные передаются в обоих направлениях. SA- пары хранятся на каждом узле. Если есть SA - соединение установлено.

SPD [setkey -DP] - база политик безопасности. Политики безопасности указывают, какой именно трафик надо шифровать. И какой трафик приходит шифрованным. Если на одном сервере укажем, например, что исходящий трафик на порту 1701 надо шифровать, а на соседе не указываем, что на порт 1701 приходит шифрованный трафик, то ничего работать не будет.
Данная база может заполняться из setkey.conf путем setkey -f setkey.conf. Но в конфигурационном файле raccoon.conf есть интересная опция generate_policy on;. Если на Сервере FreeBSD_IPSec_server ее поставить в on, то на сервере будут создаваться политики, соответствующие политикам на клиенте. Например, если на клиенте FreeBSD_IPSec_client мы укажем, что исходящий трафик на порт 1701 необходимо шифровать, то на сервере автоматически создастся правило, что входящий трафик с данного клиента на порт 1701 будет шифрованным. Для начала рекомендую поставить on и оставить политики на сервере пустыми. Они заполнятся в соответствии с клиентом. На клиенте же необходимо заполнять вручную. Если взаимодействие политик будет настроено неправильно, шифрование не заработает и SA не создастся.

Реультат команды setkey –D сервера FreeBSD_IPSec_server показан на рисунке 1.32:



Рис. 1.32 setkeyD на сервере FreeBSD_IPSec_server

Реультат команды setkey –DP сервера FreeBSD_IPSec_server показан на рисунке 1.33:



Рис 1.33 setkeyDP на сервере FreeBSD_IPSec_server

Видно, что ассоциации и политики шифрования трафика созданы.
Каталог: data -> 2013
2013 -> Федеральное государственное автономное образовательное
2013 -> «Визуальный образ персонажей массового кинематогрфа в историческом контексте»
2013 -> 2 раздел анализ предметной области 5
2013 -> Магистерская диссертация
2013 -> Влияние вовлеченности на готовность платить за коллекционные товары
2013 -> Выражение гендерных характеристик в англоязычном "глянцевом" дискурсе
2013 -> Продакт Плейсмент и перспективы его развития в сети Интернет
2013 -> 1Лекции первого полугодия
2013 -> «Правовое рассмотрение компьютерного мошенничества», Ницца, 22 октября 1992 года, грамота «весьма достойно»


Поделитесь с Вашими друзьями:
1   ...   5   6   7   8   9   10   11   12   13


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал