The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Установка защищенного соединения на FreeBSD через IPSec (security ipsec vpn freebsd bsd auth tunnel)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: security, ipsec, vpn, freebsd, bsd, auth, tunnel,  (найти похожие документы)
From: softerra Subject: Установка защищенного соединения на FreeBSD через IPSec Установка защищенного соединения на FreeBSD Перевод опубликован на http://www.softerra.ru/freeos/15905 Статья является переводом текста Майка ДеГро-Берча (Mike DeGraw-Bertsch), опубликованного по адресу http://www.onlamp.com/pub/a/bsd/2001/12/10/ipsec.html Сокращение IPSec происходит от 'IP security'. Это протокол, который предлагает методы прозрачного шифрования и аутентифицирования всего интернет-трафика на пакетном уровне. Таким образом, даже потенциально небезопасные протоколы, такие как SMTP, могут быть надежно защищены. IPSec является неотъемлемой частью IPv6, для IPv4 он является необязательным 'прикрученным' дополнением. Однако несмотря на это IPSec работает, и работает очень хорошо! IPSec основан на двух ключевых компонентах: аутентификационном заголовке (Authentication Header (AH) и инкапсуляционном протоколе безопасности (Encapsulating Security Protocol (ESP). AH предоставляет аутентификацию, подтверждая, что присланный отправителем пакет действительно пришел от него, и что этот пакет действительно содержит те данные, которые были посланы. ESP шифрует данные в пакете и может так же предоставлять аутентификационные услуги (подробнее об аутентификации через ESP смотрите на сайте рабочей группы IPSec -- http://www.ietf.org/html.charters/ipsec-charter.html). ESP и AH могут быть использованы в режиме транспорта и туннеля. Транспортный режим предоставляет защищенное соединение между двумя точками, тогда как туннель дает VPN-подобное соединение (VPN-соединение позволяет пользователям находящимся вне локальной сети иметь к ней защищенный доступ). В транспортном режиме данные (а в случае AH, заголовок, например IP адрес отправителя) пакета подписываются и/или шифруются. Затем пакет передается по назначению, где он проверяется, дешифруется и далее обрабатывается как обычный IP пакет. Транспортный режим чаще используется для передачи данных между двумя узлами. В транспортном режиме происхождение пакета имеет значение, поэтому шифрованный трафик не может проходить через сети, в которых используется NAT. В туннельном режиме AH или ESP (и иногда оба) шифруют весь пакет с данными и помещают результат внутрь нового пакета. Этот пакет отправляется на другую сторону туннеля, где данные расшифровываются и проверяются. После этого восстановленный первоначальный пакет обрабатывается как обычно, и, если необходимо, пересылается к необходимой цели. Туннельный режим лучше всего подходит для обмена трафиком между двумя маршрутизаторами, или узлом и маршрутизатором. Так как исходный пакет находится в неприкосновенности, туннельный режим ESP позволяет пакетам проходить через NAT-сети. Туннельный режим ESP является отличным способом защитить незащищенные участки сети. К примеру благодаря беспроводной сети я пишу эту статью на ноутбуке, сидя в гостиной. Поскольку WEP (Wireless Equivalent Privacy - протокол шифрования используемый в беспроводных устройствах) крайне незащищен, весь трафик между ноутбуком и Интернетом шифруется и туннелируется к моей базе беспроводного доступа (FreeBSD-сервер). Таким образом никто не может поглядеть мой трафик, когда он путешествует 'по воздуху'. Это также означает что никто другой не может использовать мое беспроводное соединение - но об этом в следующий раз. Установка IPSec IKE (не Эйзенхауэр) Во-первых вы должны сконфигурировать оба компьютера для использования IKE (Internet Key Exchange). IKE - это протокол который позволяет IPSec обмениваться шифровальными ключами безопасно и автоматически. В FreeBSD (и NetBSD), IKE поддерживается демоном racoon. Racoon является стандартным для FreeBSD 4.0 и выше. Для гарантии совместимости, однако, неплохой идеей будет убедиться что обе системы оснащены одинаковыми версиями racoon. Проще всего это сделать установив на обеих системах racoon из коллекции портов (/usr/ports/security/racoon). Конфигурационные файлы racoon по умолчанию находятся в /usr/local/etc/racoon/ и называются racoon.conf и pke.txt (их следует создать из файлов .dist, находящихся в этом каталоге). Это то немногое, что необходимо сделать с .conf файлом, тем не менее вы можете 'поиграться' с временем жизни ключей (находится в строке lifetime time xxx <min|sec|hour>). Чем короче время жизни ключа тем выше защищенность соединения, однако задание излишне короткого времени жизни ключа может привести к повышенной загрузке процессора, а так же к паузам в связи, связанными с повторной выдачей ключей. Самым важным файлом в нашей ситуации является pke.txt. Этот файл должен иметь права на доступ 600, владельцем должен выступать root, при несоблюдении этого условия racoon откажется его использовать. Этот файл содержит предварительно разделенный ключ, т.е. секретную информацию, которая должна быть известна обоим сторонам для инициирования соединения. Итак настало время практического примера. Установим защищенный туннель между узлом mason (10.0.0.2), он будет сервером туннеля и gluon (10.0.0.77), который будет туннельным клиентом. Пусть разделенный ключ будет macplusbsdcool. На mason'е pke.txt должен выглядеть так: 10.0.0.77 macplusbsdcool Аналогично на gluon'е: 10.0.0.2 macplusbsdcool Теперь запустим racoon на обеих машинах: /usr/local/sbin/racoon -f /usr/local/etc/racoon.conf -l /var/log/racoon.log Политики Обе системы готовы к обмену ключами: Но они еще не знают что это необходимо сделать. Последний шагом является конфигурирование на каждом узле IPSec-политик - правил, которые описывают как и когда применять IPSec. Для настройки политик используется программа setkey. setkey считывает ввод из файла или из командной строки. Поскольку мы хотим сделать туннель постоянным, нам следует записать политики в файл и читать их на этапе загрузки командой setkey -f /etc/ipsec.rules (организацию запуска racoon и setkey при загрузке оставим читателю). Итак мы хотим что бы все пакеты клиента, шифровались и туннелировались через сервер mason. На сервере все пакеты к gluon'у также должны шифроваться. Таким образом ipsec.rules на gluon'е должна выглядеть следующим образом: spdadd 10.0.0.77 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.0.77-10.0.0.2/require; spdadd 0.0.0.0/0 10.0.0.77 any -P in ipsec esp/tunnel/10.0.0.2-10.0.0.77/require; А на mason'е: spdadd 0.0.0.0/0 10.0.0.77 any -P out ipsec esp/tunnel/10.0.0.2-10.0.0.77/require; spdadd 10.0.0.77 0.0.0.0/0 any -P in ipsec esp/tunnel/10.0.0.77-10.0.0.2/require; Эти строки хорошо сами себя объясняют. spdadd указывает, что создается новая IPSec-политика (как противоположность шифрованию ключа при ручной настройке IPSec соединения - не беспокойтесь, вам не придется этого делать). any говорит, что политика применяется к любому протоколу. out и in указывают направление движения пакетов. И наконец esp/:/require; указывают что ядро должно использовать IPSec в туннельном режиме и туннелировать пакеты от одного IP к другому. Все вышеизложенное полностью применимо к IPv6, для этого необходимо просто использовать IPv6-адреса. Применим политики выполнив на обеих машинах команду setkey, описанным выше образом. Тестирование С запущенным на обеих машинах racoon'ом и примененными политиками, проверим созданный туннель командой ping. Если все настроено правильно, то после некоторой паузы, вызванной необходимостью инициировать туннель обменявшись ключами, мы увидим успешные ICMP-ответы. Для того что бы увериться в том, что наше соединение действительно использует IPSec, следует запустить утилиту tcpdump на клиенте и воспользовавшись утилитой ping обратиться к каким-нибудь машинам в сети. Вы должны увидеть похожую картину: 13:58:39.045831 gluon > mason: ESP(spi=0x099e806d,seq=0x723) 13:58:39.046566 mason > gluon: ESP(spi=0x0d8d15b6,seq=0x6b2) 13:58:39.187444 gluon > mason: ESP(spi=0x099e806d,seq=0x724) (frag 64877:1480@0+) Если вы видите не только ESP-трафик, значит что-то не так. Убедитесь, что адрес назначения на клиенте 0.0.0.0/0. Если вы не видите вообще никакого ESP-трафика, то это явная ошибка настройки. Проверьте, что политики согласованы на клиенте и сервере. Убедитесь, что ключи в файле pke.txt одинаковы на обоих машинах и IP-адреса корректны. Если все проверено, поглядите лог-файл /var/log/racoon.log на предмет обнаружения сообщений об ошибках. Одно слово в качестве предупреждения - если вы перезагрузите одну из машин и внезапно ощутите проблему с соединением, сбросьте ключи на обеих машинах запустив команду setkey -F. Вероятно, произошла рассинхронизация ключей. Итоги Сейчас вы должны получить работающий IPSec-туннель между вашим клиентом и сервером. Пользуйтесь беспроводным подключением, наслаждаясь тем, что никто не может подсмотреть ваши данные! Ссылки на дополнительные материалы по теме 1) FreeBSD IPSec mini-HOWTO http://asherah.dyndns.org/~josh/ipsec-howto.txt 2) FreeBSD Handbook. Chapter 10 Security. 9 IPSec http://www.freebsd.org/handbook/ipsec.html 3) NetBSD IPSec http://www.netbsd.org/Documentation/network/ipsec/ 4) Общие сведения о протоколе IPSec (на русском языке) http://www.ixbt.com/comm/ipsecure.shtml

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, jonik (?), 19:34, 11/01/2004 [ответить]  
  • +/
    > Туннельный режим лучше всего подходит для обмена трафиком между двумя маршрутизаторами, или узлом и маршрутизатором.

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру