Создаём VPN на основе vtun::Журнал СА 4.2003
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5077
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6321
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7575
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7899
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6952
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Создаём VPN на основе vtun

Архив номеров / 2003 / Выпуск №4 (5) / Создаём VPN на основе vtun

Рубрика: Администрирование /  Продукты и решения   | Дополнительные материалы

АНДРЕЙ БЕШКОВ

Создаем VPN на основе vtun

Компания, в которой я работаю, довольно быстро развивается, появляются новые филиалы, соответственно, увеличивается количество внутренних сетей. Настал момент, когда появилась необходимость соединить эти разрозненные сети в единое пространство. Нам нужна надежная, безопасная и защищенная от «подглядывания» система связи. Единственной возможностью выполнить все предъявленные требования является создание своей корпоративной VPN. В сети так много сайтов, объясняющих каждому, как престижно иметь в своем распоряжении VPN. Но ни один из них не публикует детального описания, как этого добиться. Побродив несколько дней по просторам Интернета, но так и не найдя подробного описания процесса развертывания VPN, решил написать об этом сам.

Я буду использовать vtun, написанный Максимом Краснянским на основе пакета VPPP. Главная страница проекта vtun находится по адресу: http://vtun.sourceforge.net. Вы можете спросить, почему именно vtun. Ведь можно было использовать что-либо вроде PPP поверх SSH, IPSEC или GRE. Возможно, в ближайшее время я напишу о работе с IPSEC или OpenVPN. Главными достоинствами vtun являются простота в установке, гибкость настройки и отличная документация. Vtun достаточно хорошо защищает от атак, основанных на действиях злоумышленника, находящегося между двумя машинами туннеля. Этот тип атак обычно называют MIM (Men In the Middle), чаще всего злоумышленник пытается выполнить одно или несколько из следующих действий – изменить содержимое передаваемых пакетов, повторно проиграть записанную последовательность пакетов, выдать себя за одну из сторон, участвующих в передаче данных.

Поддерживаются разнообразные типы туннелей IP, Ethernet, PPP, SLIP. В качестве туннеля можно использовать даже pipe и TTY. Для шифрования потока данных используется OpenSSL. Доступны алгоритмы blowfish с ключом в 128 бит или MD5 с ключом той же длины. Компрессия потока производится с помощью библиотек lzo или zlib. Следует отметить, что zlib работает только с tcp-туннелями. Если в вашей операционной системе нет библиотек zlib или lzo, и вы не смогли установить их самостоятельно, значит придется отключить компрессию. Это снизит скорость передачи данных. Но все же не окажет решающего влияния на работу vtun. Официально vtun работает на следующих операционных системах: Linux, Solaris, FreeBSD, NetBSD, OpenBSD и другие BSD-клоны. В принципе vtun должен работать на любой платформе, для которой есть универсальный драйвер tun/tap. Устройство tun используется для туннелирования IP-фреймов, а tap соответственно для Ethernet-фреймов. С помощью tun/tap пользовательские программы получают возможность самостоятельно обрабатывать IP-пакеты. Для некоторых операционных систем необходимо перекомпилировать ядро с поддержкой tun/tap-устройств. Vtun работает на основе клиент-серверной модели. Соответственно, для создания туннеля на одном из хостов, демон vtun должен быть запущен как сервер, а на другом как клиент.

Если между клиентом и сервером находится брандмауэр, значит необходимо разрешить прохождение пакетов, адресованных на порт 5000. Попытки провести vpn-туннель через систему с NAT, скорее всего, завершатся фатально. Проблема в том, что NAT изменяет содержимое проходящих пакетов. Поэтому ни один пакет не пройдет проверку контрольной суммы.

После запуска демон, выполняющий роль сервера, по умолчанию начинает слушать порт 5000. При попытке подсоединиться на этот порт происходит аутентификация клиента на основе пароля, записанного в конфигурационном файле /usr/local/etc/vtund.conf. Пароль применяется для аутентификации клиента всего лишь один раз на протяжении всей сессии. После успешной аутентификации сервер с помощью функции fork запускается еще один демон vtun, которому передается клиентское соединение. Новый демон будет существовать до тех пор, пока соединение не будет разорвано. В то же время родительский демон продолжает ждать новых соединений. Это значит, что единственный демон может обслуживать множество одновременных подключений. Количество поддерживаемых соединений зависит только от мощности процессора и наличия оперативной памяти.

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

Давайте представим, что у нас есть филиал, магазин и офис, использующие адреса из пространства частных сетей. Необходимо эти подразделения соединить с помощью VPN. Для этих целей мы будем использовать реальные IP-адреса, выданные нам провайдером из сети 80.80.20.0. Для соединения сетей нам понадобятся три компьютера. На каждом из них будет по три сетевых интерфейса. Два реальных и один виртуальный. Более подробно это показано в приведенной ниже таблице.

 

Система

Имя машины

Внутренняя подсеть

Внутренний интерфейс

Внешний интерфейс

Виртуальный интерфейс tun

Офис

FreeBSD 4.5

vpn_office

192.168.30.0

192.168.30.251

ed0

80.80.20.2

ed1

192.168.0.2

Филиал

Debian Linux 3.0

vpn_filial

192.168.20.0

192.168.20.251

eth0

80.80.20.1

eth1

192.168.0.1

Магазин

Solaris 2.7

vpn_shop

192.168.40.0

192.168.40.251

le0

80.80.20.3

le1

192.168.0.3

Схема соединения наших сетей выглядит так:

Рисунок 1

Это значит, что каждая из наших сетей может напрямую взаимодействовать с двумя другими. Далее мы опишем установку vtun для каждой из операционных систем. Клоны BSD-систем, в отличие от Linux, сразу после установки по умолчанию имеют работающее и правильно настроенное устройство tun. Поэтому для FreeBSD нам не придется его создавать. По большей части установка одинакова для всех систем. Наиболее подробно будет обсуждаться процедура установки программного обеспечения для FreeBSD по причине наибольшей любви к этой системе. В описаниях инсталляции для других систем внимание будет особо заостряться на отличиях. Это должно дать возможность легко поставить и настроить vtun для любой из трех обсуждаемых систем.

Под FreeBSD установить vtun можно тремя способами: с помощью пакетов, через порты или ручным способом. Мне больше нравится третий вариант, так как он дает гораздо большую возможность для контроля над происходящим. Итак, приступим к установке программного обеспечения по третьему способу.

Берем исходник портированной библиотеки lzo отсюда http://www.freebsd.org/cgi/pds.cgi?ports/archivers/lzo. Если не удалось скачать, то берем дистрибутив здесь: http://www.oberhumer.com/opensource/lzo. Распаковываем и собираем в комплектации по умолчанию.

# tar zxvf lzo-1.08.tar.gz

# cd lzo-1.08

# ./configure

# make

# make check

# make test

# make install

Скачиваем исходный код vtun. Конфигурируем его c указанием, где искать библиотеки и заголовочные файлы библиотеки lzo.

# tar zxvf vtun-2.5.tar.gz

# cd vtun

# ./configure --with-lzo-headers=/usr/local/include/ --with-lzo-lib=/usr/local/lib

Случается, что команда ./configure завершается с ошибкой. Вероятнее всего, это означает, что система не смогла обнаружить библиотеку lzo. Если вам не удастся самостоятельно избавиться от этой ошибки, значит придется отключить поддержку lzo. Vtun может работать и без библиотеки lzo. Для этого выполните команду:

# ./configure --disable-lzo

А затем, как положено, выполняем компиляцию и установку.

# make

# make install

Если все прошло гладко, значит пришло время заняться конфигурационными файлами каждой из трех машин. В нашем случае машина vpn_office будет выполнять роль сервера, соответственно, vpn_filial и vpn_shop станут клиентами. Конфигурационный файл vtun для FreeBSD находится в директории /usr/local/etc/vtund.conf.

Давайте посмотрим, из чего состоит конфигурационный файл хоста vpn_office.

options {

port 5000;

ifconfig /sbin/ifconfig;

route /sbin/route;

}

default    {

compress lzo:9;

speed 0;

}

filial {{                 # описываем клиента филиал                       

    pass secret;

    type tun;

    proto udp;

    encr yes;

    keepalive yes;

up {

ifconfig "%% 192.168.0.2 192.168.0.1 netmask 255.255.255.255 mtu 1450 up";

route "add -net 192.168.20.0/24 192.168.0.1";

};

down {

ifconfig "%% down";

route "delete 192.168.20.0";

};

} 

shop {                      # описываем клиента магазин

    pass secret;        

    type tun;;            

    proto udp;           

    encr yes;           

    keepalive yes;     

up {

ifconfig "%% 192.168.0.2 192.168.0.3 netmask 255.255.255.255 mtu 1450 up";

route "add -net 192.168.40.0/24 192.168.0.3";

};

down {

ifconfig "%% down";

route "delete 192.168.40.0";

};

}

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

  • port – номер порта, на котором демон будет ждать входящие соединения от клиентов;
  • ifconfig – путь к программе ifconfig. Эта программа необходима для управления сетевыми интерфейсами;
  • route – путь к программе route. Используется для работы с маршрутами прохождения сетевых пакетов;
  • compress – опция управления сжатием передаваемых данных. Может принимать значения lzo, zlib и no. Этой опцией можно указать, какую библиотеку мы будем использовать для компрессии потока. Второе значение описывает степень сжатия. Чем больше число, тем сильнее будет сжатие. Но в то же время стоит помнить: верхние значения сжатия заставят демона потреблять гораздо больше ресурсов процессора . Максимальное значение сжатия равно 9. Если компиляцию с поддержкой lzo выполнить не удалось, то можно отключить сжатие, установив значение compress no;
  • speed – ограничение, накладываемое на скорость передачи данных. Позволяет притормозить передачу данных особо жадных до трафика клиентов;
  • pass – пароль, используемый при аутентификации входящего соединения;
  • type – тип соединения. Может принимать значения tun, ether, pipe, tty;
  • proto – описывает протокол, используемый для передачи данных. Может принимать значения udp и tcp;
  • encr – включаем шифрование соединения. Может принимать значения no или yes;
  • keepalive – пытаться восстанавливать соединение, если оно будет прервано. Может принимать значения no или yes.

Секция up описывает действия, выполняемые при удачном соединении. Рассмотрим ее на примере клиента filial. Внутри мы описываем способ конфигурирования виртуального интерфейса с адресом 192.168.0.2. Затем привязываем этот интерфейс соединением типа точка точка к другому виртуальному интерфейсу 192.168.0.1. И завершаюшим штрихом настраиваем маршрутизацию для сети 192.168.20.0/24 через интерфейс с адресом 192.168.0.1.

Также стоит рассмотреть секцию down, описывающую действия, выполняемые при разрыве соединения. Нам необходимо удалить виртуальный интерфейс tun и разрушить маршрутизацию для сети 192.168.40.0/24.

Комбинацией опций type и proto можно создать разные виды туннелей:

Ethernet-туннель

type ether ;

proto udp;

up {

ifconfig «%% xxxxxxxx»;

};

Ethernet-туннель позволяет работать с любым протоколом, работающим поверх Ethernet. Например, IP, IPX, Appletalk, DECnet. Компрессию можно производить, используя lzo. Если lzo не работает, то нужно установить proto tcp и compress zlib.

IP-туннель

type tun;

proto udp;

up {

ifconfig "%% xxxxxxxx";

};

SLIP- или PPP-туннель

type tcp;

proto udp;

up {

ifconfig "%% xxxxxxxx";

};

pipe- или TTY-туннель

type tun;

proto tcp;

up {

program /xx/xx "xyyyyyyyyy";

};

TTY- или pipe-туннель может работать с любыми программами. Возможно применение сжатия, шифрования и даже ограничения пропускной способности. Для туннеля типа pipe лучше всего использовать протокол proto tcp. Можно, конечно, использовать и proto udp, но работать такой туннель будет нестабильно.

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

Машина vpn_shop работает под управлением Solaris 2.7. Для нее установка программного обеспечения будет немного отличаться. Кроме упомянутых раньше lzo и vtun, нам понадобятся исходные коды универсального TUN/TAP-драйвера и библиотеки OpenSSL.

Процедура установки универсального TUN/TAP драйвер хорошо автоматизирована и довольно-таки проста:

# tar zxvf tun-1.0.tar.gz

# cd tun-1.0

# ./configure

# make install

В стандартной поставке Solaris 2.7 OpenSSL отсутствует, как и библиотека lzo, поэтому будем ставить их сами. Взять дистрибутив OpenSSL можно на сайте проекта openssl.org. С помощью ключей указываем, что библиотеки должны установиться в /usr/local/lib, заголовочные файлы по умолчанию в /usr/local/include/openssl, а все остальное в /usr/local/openssl.

# tar openssl-0.9.5a.tar.gz

# cd openssl-0.9.5a

# ./configure --prefix=/usr/local --openssldir=/usr/local/openssl

# make

# make test

# make install

Пришло время собрать lzo. Как всегда, делаем это вручную:

# tar zxvf lzo-1.08.tar.gz

# cd lzo-1.08

# ./configure

# make

# make check

# make test

# make install

Постепенно мы добрались и до vtun, обратите особое внимание на ключи команды configure.

# tar zxvf vtun-2.5.tar.gz

# cd vtun

# ./configure --with-lzo-headers=/usr/local/include/ --with-lzo-lib=/usr/local/lib --with-ssl-lib=/usr/local/lib

--with-ssl-headers=/usr/local/include/openssl

# make

# make install

Если компиляция прошла без ошибок, значит мы сделали все правильно и можем переходить к конфигурированию vtun. Файл настроек vtun находится в /usr/local/etc/vtund.conf. Вносим в него следующие:

options {

port 5000;

ifconfig /usr/sbin/ifconfig;

route /usr/sbin/route;

}

default {

compress lzo:9;

speed 0;

}

shop {

    pass secret;

    type tun;

    proto udp;

    encr yes;

    keepalive yes;

# обратите внимание на синтаксис команд ifconfig и route

# есть отличия от FreeBSD в обозначении сетей, а также в создании и разрушении роутинга

up {

ifconfig "%% 192.168.0.3 netmask 255.255.255.0 192.168.0.2  up";

route "add net 192.168.30.0 192.168.0.2 1";

};

down {

ifconfig "%% down";

route "delete net 192.168.30.0 192.168.0.2 1";

};

}

Для того чтобы при первом соединении с другими машинами команда route отработала корректно, нужно добавить в файл /etc/netmasks запись такого вида:

192.168.30.0 255.255.255.0

Закончив с Solaris, примемся за работу над Linux. К сожалению, с ним все не так просто, как с двумя предыдущими системами. Перед тем как воспользоваться услугами vtun, нужно вручную создать устойство tun, в стандартной поставке оно отсутствует. Наш Linux работает на ядре версии 2.4. Значит файл устройства будет находиться в /dev/net/tun. Создадим нужное нам устройство с помощью команды:

# mknod /dev/net/tun c 10 200

Установка программного обеспечения под Debian длилась дольше всего и для меня превратилась в долгую и мучительную процедуру. С помощью apt-get ставим пакет vtun, поставлявшийся вместе с Debian. Заставить его работать мне так и не удалось. Но ставить все равно стоит, потому что он разложит необходимые файлы по местам и создаст между ними нужные взаимосвязи.

# apt-get install vtun

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

# apt-get install liblzo-dev

# apt-get install libssl-dev

Заметного сдвига это не принесло, и я принялся рыскать в поисках решения по Интернету. Постепенно пришло понимание, что таких бедолаг, как я, довольно много. После более тщательного исследования выяснилось, что из-за изменений, внесенных в ядро на пути к версии 2.4, vtun пакет от Debian и не должен был работать. Теперь нам нужно установить пакет демона vtund.

# apt-get install vtund

После всех этих приключений берем стандартный дистрибутив vtun, используемый нами для остальных систем, и компилируем его с настройками по умолчанию. Скомпилировав исходный код, команду make install не выполняем. Вместо нее вручную заменяем старый выполняемый файл, находящийся в директории /usr/local/sbin/, своим новым файлом.

Для ядра 2.4 необходимо, чтобы модуль поддержки tun был загружен в оперативную память. Такого результата можно добиться с помощью команды modprobe tun. После этого нам необходимо включить поддержку vtun в ядре. Ищем в тексте ядра строку Universal TUN/TAP device driver (CONFIG_TUN). Я думаю, вы знаете, что нужно делать, чтобы пересобрать ядро. После этого в конфигруационный файл vtun нужно внести такой текст.

options {

port 5000;

ifconfig /sbin/ifconfig;

route /sbin/route;

}

default {

compress lzo:9;

speed 0;

}

filial {

    pass secret;

    type tun;

    proto udp;

    encr yes;

    keepalive yes;

up {

ifconfig "%% 192.168.0.1 pointopoint 192.168.0.2 mtu 1450";

route "add -net 192.168.30.0/24 192.168.0.2";

};

down {

ifconfig "%% down";

route "delete -net 192.168.30.0";

};

}

Скачать все конфигурационные файлы можно здесь: http://onix.opennet.ru/files/vtun-cfg.tar.gz.

В связи с тем, что в файлах vtund.conf находится пароль соединения, доступ к ним должен иметь только пользователь root. После всех этих манипуляций можно запускать vtun. На машине vpn_office запускаем демон в режиме сервера.

vpn_office# vtund -s

На другой консоли смотрим на сообщения об ошибках.

vpn_office# tail -f /var/log/messages

Если ошибок не появилось, значит все у нас хорошо. Соответственно, на хостах vpn_shop и vpn_filial запускаем демоны в режиме клиента.

vpn_shop# vtund -p shop 80.80.20.2

vpn_filial# vtund -p filial 80.80.20.2ф

Снова ждем ошибок. Не дождавшись, смотрим, какие сетевые интерфейсы у нас подняты на каждой из машин. Больше всего нас интересуют интерфейсы vtun0 и vtun1. У вас должны получиться примерно такие данные:

vpn_office# ifconfig -u

ed0: flags=8843 mtu 1500

 inet 192.168.30.251 netmask 0xffffff00 broadcast 192.168.30.255

 inet6 fe80::280:48ff:fedf:66f7%ed0 prefixlen 64 scopeid 0x1

 ether 00:80:48:df:66:f7

ed1: flags=8843 mtu 1500

 inet 80.80.20.2 netmask 0xffffff00 broadcast 80.80.20.255

 inet6 fe80::240:95ff:fe45:9ce2%ed1 prefixlen 64 scopeid 0x2

 ether 00:40:95:45:9c:e2

lo0: flags=8049 mtu 16384

 inet6 ::1 prefixlen 128

 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5

 inet 127.0.0.1 netmask 0xff000000

tun0: flags=8051 mtu 1450

 inet6 fe80::280:48ff:fedf:66f7%tun0 prefixlen 64 scopeid 0x8

 inet 192.168.0.2 --> 192.168.0.3 netmask 0xffffffff

 Opened by PID 1143

tun1: flags=8051 mtu 1450

 inet6 fe80::280:48ff:fedf:66f7%tun1 prefixlen 64 scopeid 0x9

 inet 192.168.0.2 --> 192.168.0.1 netmask 0xffffffff

 Opened by PID 1150

vpn_shop# ifconfig –a

lo0: flags=849 mtu 8232

     inet 127.0.0.1 netmask ff000000

le0: flags=863 mtu 1500

     inet 192.168.40.251 netmask ffffff00 broadcast 192.168.40.255

     ether 00:80:48:b6:43:5f

le1: flags=863 mtu 1500

     inet 80.80.20.3 netmask ffffff00 broadcast 80.80.20.255

     ether 00:02:b3:65:0f:47

tun0: flags=8d1 mtu 1500

     inet 192.168.0.3 --> 192.168.0.2 netmask ffffffff

     ether 0:0:0:0:0:0

vpn_filial#  /sbin/ifconfig

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0

          UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1

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

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

          Collisions:0

eth0    Link encap:Ethernet  HWaddr  00:80:48:c7:c7:9b

          inet addr:192.168.20.251      Bcast:192.168.20.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:78 errors:0 dropped:0 overruns:0 frame:10

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

          Collisions:0

          Interrupt:3

eth1    Link encap:Ethernet  HWaddr  00:02:2e:f1:17:26

          inet addr:80.80.20.1       Bcast:80.80.20.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:49 errors:1 dropped:0 overruns:0 frame:15

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

          Collisions:1

          Interrupt:4

tun0:   Link encap:Point-to-Point Protocol

          inet addr:192.168.0.1 P-t-P: 192.168.0.2    Mask:255.255.255.0

          UP POINTPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:155 errors:0 dropped:0 overruns:0 frame:15

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

          Collisions:0

Теперь можно попробовать, как работает наша виртуальная частная сеть. Выполним команду ping на хостах vpn_filial и vpn_office. Таким образом мы сможем проверить прохождение пакетов от vpn_filial к vpn_office и от vpn_shop к vpn_office.

vpn_filial#  ping 192.168.30.251

PING 192.168.30.251 (192.168.30.251): 56 data bytes

64 bytes from 192.168.30.251: icmp_seq=0 ttl=64 time=5.788 ms

64 bytes from 192.168.30.251: icmp_seq=1 ttl=64 time=5.724 ms

64 bytes from 192.168.30.251: icmp_seq=2 ttl=64 time=5.683 ms

64 bytes from 192.168.30.251: icmp_seq=3 ttl=64 time=5.685 ms

--- 192.168.30.251 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max = 5.683/5.720/5.788 ms

vpn_office# ping 192.168.40.251

PING 192.168.30.251 (192.168.30.251): 56 data bytes

64 bytes from 192.168.40.251: icmp_seq=0 ttl=64 time=6.092 ms

64 bytes from 192.168.40.251: icmp_seq=1 ttl=64 time=5.785 ms

64 bytes from 192.168.40.251: icmp_seq=2 ttl=64 time=5.851 ms

64 bytes from 192.168.40.251: icmp_seq=3 ttl=64 time=5.826 ms

--- 192.168.30.251 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max/stddev = 5.785/5.888/6.092/0.120 ms

Судя по всему, туннели исправно передают пакеты в обе стороны и все работает наилучшим образом. Теперь давайте проверим, как работает шифрование. Нужно посмотреть, что и в каком виде передается по интерфейсам tun0 – 192.168.0.2 и ed1 – 80.80.20.2. Давайте начнем прослушивание интерфейсов, участвующих в передаче данных, с помощью программы tcpdump. В то же время с машины vpn_shop начинаем пинговать интерфейс 192.168.40.251, принадлежащий машине vpn_office.

vpn_office# tcpdump -i tun0 –lenx 

13:33:14.573619 AF 2 84: 192.168.0.2 > 192.168.40.251: icmp: echo request

                   4500 0054 0cc3 0000 4001 c398 c0a8 0002

                   c0a8 28fb 0800 edcc c904 0000 ede7 cc3d

                   9505 0700 0809 0a0b 0c0d 0e0f 1011 1213

                   1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

                   2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

                    3435 3637

13:33:14.573665 AF 2 84: 192.168.40.251 > 192.168.0.2: icmp: echo reply

                    4500 0054 1b3f 0000 4001 b51c c0a8 28fb

                    c0a8 0002 0000 f5cc c904 0000 ede7 cc3d

                    9505 0700 0809 0a0b 0c0d 0e0f 1011 1213

                    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

                    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

                     3435 3637

13:33:15.583143 AF 2 84: 192.168.0.2 > 192.168.40.251: icmp: echo request

                    4500 0054 0cc6 0000 4001 c395 c0a8 0002

                    c0a8 28fb 0800 42a6 c904 0100 eee7 cc3d

                    3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213

                    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

                    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

                     3435 3637

13:33:15.583194 AF 2 84: 192.168.40.251 > 192.168.0.2: icmp: echo reply

                    4500 0054 1b43 0000 4001 b518 c0a8 28fb

                    c0a8 0002 0000 4aa6 c904 0100 eee7 cc3d

                    3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213

                    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

                    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

                     3435 3637

13:33:16.590000 AF 2 84: 192.168.0.2 > 192.168.40.251: icmp: echo request

                    4500 0054 0cc6 0000 4001 c395 c0a8 0002

                    c0a8 28fb 0800 42a6 c904 0100 eee7 cc3d

                    3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213

                    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

                    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

                    3435 3637

13:33:16.590120 AF 2 84: 192.168.40.251 > 192.168.0.2: icmp: echo reply

                   4500 0054 1b43 0000 4001 b518 c0a8 28fb

                   c0a8 0002 0000 4aa6 c904 0100 eee7 cc3d

                   3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213

                   1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

                   2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

                    3435 3637

На предыдущем листинге явно видно содержимое тестовых ICMP-пакетов. А теперь внимательно посмотрим, в каком виде эти пакеты путешествуют по небезопасной сети 80.80.20.0/24.

vpn_office# tcpdump -i ed1 –lenx 

13:33:14.573441 0:40:95:45:9c:e2 0:2:b3:65:f:47 0800 140: 80.80.20.2.5000 > 80.80.20.3.1035: udp 98

                  4500 007e 0cc4 0000 4011 a506 5050 1402

                  5050 1403 1388 040b 006a f9e2 0060 7db0

                  f6ef dd81 4638 917a 5a80 7f48 87d7 7bc9

                  459f 97f0 b95a 95cf 87b1 29ce b2d7 8f50

                  228e 6b8f eafb 1f5d ae9d 7518 2085 2da9

                8c85

13:33:14.574798 0:2:b3:65:f:47 0:40:95:45:9c:e2 0800 140: 80.80.20.3.1035 > 80.80.20.2.5000: udp 98

                 4500 007e 1b40 0000 4011 968a 5050 1403

                 5050 1402 040b 1388 006a 998c 0060 7db0

                 f6ef dd81 4638 5390 c84e 886e 466d ffcd

                 df10 9010 5995 fcdd b315 92fb 6a1d 8f50

                 228e 6b8f eafb 1f5d ae9d 7518 2085 2da9

               8c85

13:33:15.582910 0:40:95:45:9c:e2 0:2:b3:65:f:47 0800 140: 80.80.20.2.5000 > 80.80.20.3.1035: udp 98

                 4500 007e 0cc7 0000 4011 a503 5050 1402

                 5050 1403 1388 040b 006a 28fd 0060 7db0

                 f6ef dd81 4638 3048 4e92 e692 1c3d 5fa3

                 c2a6 bc50 8fa5 79d3 c0c2 6537 c74b 1e84

                 b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9

               8c85

13:33:15.584332 0:2:b3:65:f:47 0:40:95:45:9c:e2 0800 140: 80.80.20.3.1035 > 80.80.20.2.5000: udp 98

                4500 007e 1b44 0000 4011 9686 5050 1403

                5050 1402 040b 1388 006a cd92 0060 7db0

                f6ef dd81 4638 f41d cb55 f37d 1229 dbb6

                14f7 14d1 08e3 a204 5045 74a0 7807 1e84

                b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9

              8c85

13:33:15.593910 0:40:95:45:9c:e2 0:2:b3:65:f:47 0800 140: 80.80.20.2.5000 > 80.80.20.3.1035: udp 98

              4500 007e 0cc7 0000 4011 a503 5050 1402

              5050 1403 1388 040b 006a 28fd 0060 7db0

              f6ef dd81 4638 3048 4e92 e692 1c3d 5fa3

              c2a6 bc50 8fa5 79d3 c0c2 6537 c74b 1e84

              b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9

            8c85

13:33:15.594237 0:2:b3:65:f:47 0:40:95:45:9c:e2 0800 140: 80.80.20.3.1035 > 80.80.20.2.5000: udp 98

            4500 007e 1b44 0000 4011 9686 5050 1403

            5050 1402 040b 1388 006a cd92 0060 7db0

            f6ef dd81 4638 f41d cb55 f37d 1229 dbb6

            14f7 14d1 08e3 a204 5045 74a0 7807 1e84

            b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9

           8c85

Как мы могли убедиться, все пакеты движутся через публичную сеть в зашифрованном виде. Мы создали туннели VPN1 и VPN2 между тремя частными сетями. Теперь машина vpn_office сможет общаться с любой машиной из всех трех сетей. Но в то же время машины vpn_shop и vpn_filial могут взаимодействовать лишь с машиной vpn_office, но не друг с другом. При таком способе соединения сетей у нас получилась топология типа звезда. Такая конструкция не очень надежна. Если хост vpn_office по каким-либо причинам выйдет из строя, вся система VPN перестанет существовать. Чтобы избежать подобных плачевных результатов, нам необходимо создать резервный туннель VPN3 между хостами vpn_shop и vpn_filial. Это даст им возможность работать друг с другом напрямую, не полагаясь на хост vpn_office.

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

filial_to_shop {

    pass secret;

    type tun;

    proto udp;

    encr yes;

    keepalive yes;

up {

ifconfig "%% 192.168.0.3 netmask 255.255.255.0 192.168.0.1  up";

route "add net 192.168.20.0 192.168.0.1 1";

};

down {

ifconfig "%% down";

route "delete net 192.168.20.0 192.168.0.1 1";

};

Затем запускаем сервер:

vpn_shop#  vtund -s

В свою очередь, в конфигурацию хоста vpn_filial добавим вот такие строки:

filial_to_shop {

    pass secret;

    type tun;

    proto udp;

    encr yes;

    keepalive yes;

up {

ifconfig "%% 192.168.0.1 pointopoint 192.168.0.3  mtu 1450";

route "add -net 192.168.30.0/24 192.168.0.3";

};

down {

ifconfig "%% down";

route "delete -net 192.168.30.0 ";

};

А теперь запускаем клиента :

vpn_shop# vtund -p filial_to_shop 80.80.20.1

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


Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru