На сегодняшний день существует две реализации IPSEC в Linux. Для ядер 2.2 и 2.4 — это пакет FreeS/WAN, который является первой основной реализацией IPSEC. Этот проект имеет два сайта: официальный — http://www.freeswan.org/ и неофициальный — http://www.freeswan.ca/. FreeS/WAN не вошел в состав ядра по ряду причин. Наиболее часто упоминается причина "политического" характера, связанная с Американскими законодательством, запрещающим экспорт технологий шифрования. Кроме того, этот пакет довольно трудно интегрируется в ядро Linux, что еще больше осложняет их слияние.

В добавок ко всему, многие высказывают обеспокоенность качеством кода. В Интернет существует достаточное количество документации, описывающей процесс установки FreeS/WAN.

Начиная с версии 2.5.47, в ядре Linux появилась встроенная поддержка IPSEC. Реализация ее была выполнена Алексеем Кузнецовым и Дэйвом Миллером (Dave Miller), на основе разработок USAGI IPv6 group. С этой версии, CryptoAPI Джеймса Морриса (James Morris), так же стал частью ядра — его средствами выполняется собственно шифрование.

Этот документ будет описывать только IPSEC версии 2.5 (и выше). FreeS/WAN рекомендуется для пользователей Linux 2.4, но вам следует знать, что его конфигурирование сильно отличается от "родного" IPSEC. И наверное следует упомянуть о существовании "заплаты", которая делает возможной работу пользовательских утилит FreeS/WAN с "родным" для Linux IPSEC.

Начиная с версии ядра Linux 2.5.49, для работы IPSEC уже не требуется наложения заплат.

Note

Пользовательские утилиты, для работы с IPSEC, вы найдете по адресу: http://sourceforge.net/projects/ipsec-tools. В этот пакет, кроме всего прочего, входит ряд программ, основанных на Racoon.

При пересборке ядра обязательно включите опции PF_KEY, AH, ESP и все опции в CryptoAPI! 

Warning 

Автор этой главы полный кретин (впрочем у меня есть причины сомневаться в этом — прим. перев.) в области IPSEC! Если в этой главе вы столкнетесь с неизбежными ошибками, пожалуйста, сообщите о них Берту Хьюберту (Bert Hubert), по адресу: <ahu@ds9a.nl>.

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

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

IPSEC — довольно сложная тема. В Интернет вы найдете множество разнообразной информации по ней. Этот документ концентрируется на проблемах настройки, запуска и объяснении основных принципов функционирования. Все примеры базируются на Racoon, который уже упоминался выше.

Note

Наиболее распространенные примеры настройки iptables не позволяют прохождение пакетов IPSEC! Чтобы сделать это возможным, вам следует добавить следующие правила: iptables –A xxx –p 50 –j ACCEPT и iptables –A xxx –p 51 –j ACCEPT.

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

Шифрование, в IPSEC, выполняется протоколом ESP (Encapsulating Security Payload — Инкапсулированные Защищенные Данные), аутентификация — протоколом AH (Authentication Header — Заголовок Аутентификации). Вы можете сконфигурировать их оба, или один из них.

И ESP, и AH опираются на Security Association (защищенный виртуальный канал, или контекст безопасности). Security Association (SA) — однонаправленное логическое соединение (от отправителя к получателю) между двумя системами, поддерживающими протокол IPSec, которое однозначно идентифицируется следующими тремя параметрами: 

• индексом защищенного соединения (Security Parameter Index, SPI — 32-битная константа, используемая для идентификации различных SA c одинаковыми IP-адресом получателя и протоколом безопасности);

• IP-адресом получателя IP-пакетов (IP Destination Address);

• протоколом безопасности (Security Protocol — AH или ESP).

Пример создания защищенного канала (SA) для протокола AH может выглядеть следующим образом:

add 10.0.0.11 10.0.0.216 ah 15700 –A hmac-md5 "1234567890123456";

Эта строка говорит нам, что: "Создается защищенный канал от узла сети с адресом 10.0.0.11, к узлу сети с адресом 10.0.0.216. Что это данные аутентификации, которая выполняется протоколом AH, с использованием алгоритма шифрования hmac-md5 и ключом 1234567890123456.". Эта инструкция помечена индексом SPI — 15700. Здесь есть один интересный момент — каждый защищенный виртуальный канал используется для передачи данных только в одном направлении (в данном примере: от 10.0.0.11 к 10.0.0.216). В случае необходимости двустороннего обмена создаются два виртуальных канала. Более того, для каждого из протоколов создаются свои виртуальные защищенные каналы передачи данных. Таким образом, если предполагается двусторонний обмен, с использованием обоих протоколов — и AH, и ESP, то создаются 4 защищенных канала, по одному на каждое направление для каждого из протоколов.

Пример создания защищенного канала (SA) для протокола ESP:

add 10.0.0.11 10.0.0.216 esp 15701 –E 3des-cbc "123456789012123456789012";

Этот пример говорит: "Создается защищенный канал от 10.0.0.11 к 10.0.0.216, в котором данные должны шифроваться алгоритмом 3des-cbc с ключом 123456789012123456789012". Индекс SPI — '15701'.

Фактически, может существовать любое число практически идентичных SA, но при этом, все они отличаются различными индексами SPI. Пока что мы видели только то, как описываются виртуальные каналы безопасности (SA), но до сих пор не встретили ни одного описания политик безопасности (правил обработки получаемых пакетов). Для того, чтобы назначить эти правила, необходимо описать политику безопасности. Она может включать в себя такие действия, как: "обрабатывать пакет с помощью IPSEC, если это возможно" или "сбросить пакет".

Типичный пример назначения политики безопасности:

spdadd 10.0.0.216 10.0.0.11 any –P out ipsec

   esp/transport//require

   ah/transport//require;

Применительно к хосту 10.0.0.216, это означает, что весь трафик, отправляемый хосту 10.0.0.11 должен быть зашифрован и "обернут" протоколом AH, подтверждающим подлинность. Обратите внимание, этот пример не описывает, какой из имеющихся каналов (SA) должен использоваться, это означает, что право выбора оставляется за ядром.

Другими словами, Политика Безопасности описывает ЧТО следует предпринять в том или ином случае, а защищенный канал (SA) – КАК получить данные.

Исходящие пакеты "подписываются" соответствующим SPI (КАК). Ядро использует его для нужд шифрования и аутентификации так, чтобы удаленный хост мог выполнить необходимые проверки и дешифрацию.

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

Для хоста 10.0.0.216:

#!/sbin/setkey –f

add 10.0.0.216 10.0.0.11 ah 24500 –A hmac-md5 "1234567890123456";

add 10.0.0.216 10.0.0.11 esp 24501 –E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any –P out ipsec

   esp/transport//require

   ah/transport//require;

Для хоста 10.0.0.11, те же самые SA, но без политики безопасности:

#!/sbin/setkey –f

add 10.0.0.216 10.0.0.11 ah 24500 –A hmac-md5 "1234567890123456";

add 10.0.0.216 10.0.0.11 esp 24501 –E 3des-cbc "123456789012123456789012";

В этой конфигурации попробуем дать команду ping 10.0.0.11 с хоста 10.0.0.216. В результате получим такой вывод от tcpdump:

22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)

22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply

Обратите внимание на то, как возвращается ответ на запрос – он передается в открытом виде. В то время как сам запрос не распознается утилитой tcpdump, но зато она показывает SPI для AH и ESP, которые инструктируют хост 10.0.0.11, КАК выполнить проверку подлинности и дешифровать данные.

Следует сделать несколько замечаний по поводу этих примеров. Такая конфигурация не обеспечивает достаточный уровень безопасности. Проблема состоит в том, что политика безопасности описывает только — ЧТО должен сделать хост 10.0.0.216 при передаче данных хосту 10.0.0.11 и КАК их передать, а для хоста 10.0.0.11 описывается КАК он может получить эти данные, но нет правил, описывающих ЧТО он должен предпринять при получении нешифрованных пакетов, идущих от 10.0.0.216!

Таким образом, если злоумышленник будет в состоянии выполнить "подмену" (spoofing) IP-адреса, то он сможет отправлять незашифрованные данные хосту 10.0.0.11, который примет их! Для устранения этой проблемы нужно прописать политику безопасности для хоста 10.0.0.11:

#!/sbin/setkey –f

spdadd 10.0.0.216 10.0.0.11 any –P IN ipsec

   esp/transport//require

   ah/transport//require;

Это описание сообщает хосту 10.0.0.11, что весь входящий трафик от хоста 10.0.0.216 должен иметь подтверждение подлинности (AH) и должен быть зашифрован (ESP).

Ниже приводится полная конфигурация сетевых узлов 10.0.0.11 и 10.0.0.216, для двустороннего обмена данными. Полная конфигурация для хоста 10.0.0.216:

#!/sbin/setkey –f

flush;

spdflush;

# AH

add 10.0.0.11 10.0.0.216 ah 15700 –A hmac-md5 "1234567890123456";

add 10.0.0.216 10.0.0.11 ah 24500 –A hmac-md5 "1234567890123456";

# ESP

add 10.0.0.11 10.0.0.216 esp 15701 –E 3des-cbc "123456789012123456789012";

add 10.0.0.216 10.0.0.11 esp 24501 –E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any –P out ipsec

   esp/transport//require

   ah/transport//require;

spdadd 10.0.0.11 10.0.0.216 any –P in ipsec

   esp/transport//require

   ah/transport//require;

И для 10.0.0.11:

#!/sbin/setkey –f

flush;

spdflush;

# AH

add 10.0.0.11 10.0.0.216 ah 15700 –A hmac-md5 "1234567890123456";

add 10.0.0.216 10.0.0.11 ah 24500 –A hmac-md5 "1234567890123456";

# ESP

add 10.0.0.11 10.0.0.216 esp 15701 –E 3des-cbc "123456789012123456789012";

add 10.0.0.216 10.0.0.11 esp 24501 –E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.11 10.0.0.216 any –P out ipsec

   esp/transport//require

   ah/transport//require;

spdadd 10.0.0.216 10.0.0.11 any –P in ipsec

   esp/transport//require

   ah/transport//require;

Обратите внимание — в этом примере использованы идентичные ключи шифрования для обоих направлений. Однако, это не является обязательным требованием.

Чтобы проверить только что созданную конфигурацию, достаточно дать команду setkey –D, которая выведет перечень контекстов защиты (виртуальных защищенных каналов) или setkey –DP, которая отобразит сконфигурированные политики безопасности.

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

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

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

Другая проблема состоит в том, что при работе с ключевой информацией "вручную", как это описано выше, мы заранее точно определяем алгоритмы и используемую длину ключа, что в свою очередь требует тесной координации с удаленной стороной. Желательно было бы иметь возможность определения более широкой политики назначения ключей, например так: "Мы можем использовать алгоритмы 3DES и Blowfish, с длиной ключа не менее, чем…".

Решение этих проблем берет на себя Протокол Обмена Ключами — IKE (Internet Key Exchange), позволяющий обмениваться сгенерированными, автоматически и случайным образом, ключами. Передача ключей осуществляется с помощью асимметричной технологии кодирования, в соответствии с предопределенными алгоритмами.

В Linux IPSEC 2.5, реализация этих возможностей выполнена в виде демона KAME 'racoon' IKE. Начиная с 9 ноября 2003 года, доступны исходные тексты racoon, в пакете iptools, распространяемом Алексеем, хотя, возможно, вам придется удалить строки #include <net/route.h> в двух файлах. В качестве альтернативы я могу предложить откомпилированную версию.

Note

Протокол IKE работает через UDP порт 500, предоставьте ему такую возможность, внеся соответствующие изменения в ваш набор правил для iptables.

Как уже говорилось ранее, в случае автоматической настройки, обновление и обмен ключевой информацией выполняется без нашего участия. Очевидно, что при этом "на лету" создаются защищенные каналы (SA), которые, как это ни странно, не обеспечиваются какой-либо политикой безопасности.

Таким образом, чтобы воспользоваться преимуществами IKE, необходимо установить для него политику безопасности. Для этого создается такая политика, которая не связана с каким-либо конкретным защищенным каналом (SA). Когда ядро обнаружит такую политику, то оно передаст ее демону IKE, который в свою очередь будет использовать ее в своей работе.

Повторюсь еще раз: Политика Безопасности определяет — ЧТО следует предпринять в том или ином случае, а Контекст Безопасности (защищенный канал) определяет – КАК производить обмен данными. Автоматическое управление ключевой информацией позволяет нам избежать неприятностей только с определением "ЧТО предпринять".

Kame racoon имеет достаточно неплохие настройки по-умолчанию, так что мы не будем их касаться. Как уже говорилось выше, мы должны определить только политику безопасности, оставив право на создание защищенных каналов за демоном IKE.

В этом примере, мы опять вернемся к нашим хостам 10.0.0.11 и 10.0.0.216, и еще раз попробуем установить защищенное соединение между ними, но на сей раз с помощью racoon. Для упрощения конфигурации будем использовать предопределенные ключи, сертификаты X.509 будут обсуждаться в отдельном разделе (см. раздел Автоматизация с использованием сертификатов X.509 ).

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

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

remote anonymous

{

 exchange_mode aggressive,main;

 doi ipsec_doi;

 situation identity_only;

 my_identifier address;

 lifetime time 2 min; # sec,min,hour

 initial_contact on;

 proposal_check obey; # obey – повиноваться, требованиям и ограничениям

 proposal {

  encryption_algorithm 3des;

  hash_algorithm sha1;

  authentication_method pre_shared_key;

  dh_group 2 ;

 }

}

sainfo anonymous {

 pfs_group 1;

 lifetime time 2 min;

 encryption_algorithm 3des ;

 authentication_algorithm hmac_sha1;

 compression_algorithm deflate ;

}

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

Кроме того, в настройках задана самоидентификация на основе собственного IP-адреса (my_identifier address). Затем объявляются используемые алгоритмы шифрования — 3des и sha1 и указывается, что будут использоваться предопределенные ключи, расположенные в файле psk.txt.

Содержимое файлов psk.txt с ключами приводится ниже. Для разных хостов они различны. Для хоста 10.0.0.11:

10.0.0.216 password2

Для хоста 10.0.0.216:

10.0.0.11 password2

Назначте владельцем файла суперпользователя (root), и установите права доступа 0600, в противном случае racoon откажется доверять их содержимому.

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

#!/sbin/setkey –f

flush;

spdflush;

spdadd 10.0.0.216 10.0.0.11 any –P out ipsec

       esp/transport//require;

spdadd 10.0.0.11 10.0.0.216 any –P in ipsec

       esp/transport//require;

На хосте 10.0.0.11:

#!/sbin/setkey –f

flush;

spdflush;

spdadd 10.0.0.11 10.0.0.216 any –P out ipsec

       esp/transport//require;

spdadd 10.0.0.216 10.0.0.11 any –P in ipsec

       esp/transport//require;

Теперь все готово к запуску racoon! После того, как он будет запущен, попробуем установить сеанс связи, через telnet, с хоста 10.0.0.11 на хост 10.0.0.216, впрочем можно и наоборот. racoon тут же начнет "переговоры" с удаленным хостом:

12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA

  request for 10.0.0.11 queued due to no phase1 found.

12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new

  phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]

12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode.

12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID:

  KAME/racoon

12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find

  the proper pskey, try to get one by the peer's address.

12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA

  established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680

12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2

  negotiation: 10.0.0.216[0]<=>10.0.0.11[0]

12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established:

  ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b)

12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:

  ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)

Если теперь дать команду setkey –D, чтобы просмотреть список созданных защищенных каналов, мы получим такой вывод:

10.0.0.216 10.0.0.11

        esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000)

        E: 3des-cbc 5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04

        A: hmac-sha1 c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99

        seq=0x00000000 replay=4 flags=0x00000000 state=mature

        created: Nov 11 12:28:45 2002   current: Nov 11 12:29:16 2002

        diff: 31(s)     hard: 600(s)    soft: 480(s)

        last: Nov 11 12:29:12 2002      hard: 0(s)   soft: 0(s)

        current: 304(bytes)     hard: 0(bytes) soft: 0(bytes)

        allocated: 3    hard: 0 soft: 0

        sadb_seq=1 pid=17112 refcnt=0

10.0.0.11 10.0.0.216

        esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000)

        E: 3des-cbc d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a

        A: hmac-sha1 41ccc388 4568ac49 19e4e024 628e240c 141ffe2f

        seq=0x00000000 replay=4 flags=0x00000000 state=mature

        created: Nov 11 12:28:45 2002   current: Nov 11 12:29:16 2002

        diff: 31(s)     hard: 600(s)    soft: 480(s)

        last:                           hard: 0(s) soft: 0(s)

        current: 231(bytes)     hard: 0(bytes) soft: 0(bytes)

        allocated: 2    hard: 0 soft: 0

        sadb_seq=0 pid=17112 refcnt=0

А команда setkey –DP — список политик безопасности, даст такой результат:

10.0.0.11[any] 10.0.0.216[any] tcp

        in ipsec

        esp/transport//require

        created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002

        lifetime:0(s) validtime:0(s)

        spid=3616 seq=5 pid=17134

        refcnt=3

10.0.0.216[any] 10.0.0.11[any] tcp

        out ipsec

        esp/transport//require

        created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002

        lifetime:0(s) validtime:0(s)

        spid=3609 seq=4 pid=17134

        refcnt=3

Если этот вариант у вас не работает, проверьте — все ли файлы конфигурации принадлежат суперпользователю (root) и доступны на чтение только ему. Чтобы запустить racoon в приоритетном режиме, используйте ключ '-f'. Чтобы указать ему местоположение файла конфигурации — ключ '-f'. Для того, чтобы увеличить детальность, добавьте инструкцию 'log debug;' в racoon.conf.

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

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

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

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

Для начала создадим сертификат для нашего хоста, с именем laptop. Начнем с генерации "запроса на сертификат":

$ openssl req –new –nodes –newkey rsa:1024 –sha1 –keyform PEM –keyout \

 laptop.private –outform PEM –out request.pem

Здесь будет предложено ответить на ряд вопросов:

Country Name (2 letter code) [AU]:NL

State or Province Name (full name) [Some-State]:.

Locality Name (eg, city) []:Delft

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced Routing & Traffic Control

Organizational Unit Name (eg, section) []:laptop

Common Name (eg, YOUR name) []:bert hubert

Email Address []:ahu@ds9a.nl

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Заполните поля запроса по своему усмотрению.

Теперь создадим собственно сертификат, подписанный самим собой:

$ openssl x509 –req –in request.pem –signkey laptop.private –out \

 laptop.public

Signature ok

subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \

 Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl

Getting Private key

После этого файл request.pem можно удалить.

Повторите эту процедуру для всех ваших компьютеров. Вы можете свободно передавать сгенерированные открытые ключи (файлы .public), но сохраняйте файлы .private в секрете!

Теперь, после того как мы создали открытый и секретный ключи, мы можем передать их racoon.

Вернемся к нашей предыдущей конфигурации хостов 10.0.0.11 ('upstairs') и 10.0.0.216 ('laptop').

В файл racoon.conf , на 10.0.0.11, добавим: path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.216

{

 exchange_mode aggressive,main;

 my_identifier asn1dn;

 peers_identifier asn1dn;

certificate_type x509 "upstairs.public" "upstairs.private";

peers_certfile "laptop.public";

 proposal {

  encryption_algorithm 3des;

  hash_algorithm sha1;

  authentication_method rsasig;

  dh_group 2 ;

 }

}

Тем самым сообщив racoon, что сертификаты находятся в каталоге /usr/local/etc/racoon/certs/. Кроме того, добавим раздел, описывающий удаленный компьютер 10.0.0.216.

Строки asn1dn говорят о том, что локальный и удаленный идентификаторы следует извлекать из открытых ключей. Это — 'subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl' из листинга, приведенного выше.

Строка certificate_type указывает имена файлов с локальными открытым и секретным ключами. peers_certfile указывает, что открытый ключ удаленного узла следует взять из файла laptop.public.

Блок proposal остается, по сравнению с предыдущей конфигурацией, практически без изменений, за исключением authentication_method для которого теперь указано rsasig, что означает — использовать для аутентификации RSA открытый/секретный ключи.

Аналогичные изменения вносятся и в конфигурацию хоста 10.0.0.216:

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.11

{

 exchange_mode aggressive,main;

 my_identifier asn1dn;

 peers_identifier asn1dn;

 certificate_type x509 "laptop.public" "laptop.private";

 peers_certfile "upstairs.public";

 proposal {

  encryption_algorithm 3des;

  hash_algorithm sha1;

  authentication_method rsasig;

  dh_group 2 ;

 }

}

После внесения изменений в конфигурацию, нам необходимо разместить файлы ключей. На машине 'upstairs', в каталоге /usr/local/etc/racoon/certs, следует разместить файлы upstairs.private, upstairs.public и laptop.public.

Note

ВНИМАНИЕ! Владельцем этого каталога должен быть суперпользователь (root) и ему должны быть назначены права доступа 0700, иначе racoon откажется работать с ним!

А на машине 'laptop', опять же в каталоге /usr/local/etc/racoon/certs, нужно разместить файлы laptop.private, laptop.public и upstairs.public. Короче говоря, на каждом хосте должны размещаться его собственные открытый и секретный ключи, а так же открытые ключи удаленных систем.

Проверьте настройки политик безопасности (выполните строки spdadd, из раздела Пример). Теперь запустите racoon — все должно работать.

Чтобы иметь возможность установить защищенное соединение с удаленной стороной, необходимо обменяться открытыми ключами. Несмотря на то, что открытый ключ можно распространять свободно, очень важно сохранить его целостность. Другими словами, всегда следует проверять — не получили ли вы "кота в мешке".

Сделать это довольно просто, OpenSSL имеет команду digest, которая вычисляет контрольную сумму файла с ключом:

$ openssl dgst upstairs.public

MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1

После получения вашего ключа, удаленная сторона так же вычисляет его контрольную сумму и, если они совпали (сообщить свою контрольную сумму вы может при личной встрече или по телефону), то все в порядке!

Другой вариант — воспользоваться услугами третьей доверенной стороны – Certificate Authority, которая может подписать созданные вами сертификаты.

Выше мы обсуждали работу с IPSEC в так называемом транспортном режиме, где обе стороны взаимодействуют друг с другом посредством протоколов IPSEC. Однако, это довольно редкий случай, чаще встречается другой вариант — когда в транспортном режиме работают только маршрутизаторы, обеспечивая защищенными каналами связи компьютеры, находящиеся за ними. Такой режим работы называется туннельным режимом.

Настройка такого режима выполняется достаточно просто. Предположим, что нам необходимо "проложить" туннель от хоста, с адресом 10.0.0.216, к хосту, с адресом 10.0.0.11, через сеть 130.161.0.0/16. Для этого, на хосте 10.0.0.216 выполним следующие действия:

#!/sbin/setkey –f

flush;

spdflush;

add 10.0.0.216 10.0.0.11 esp 34501

        -m tunnel

        -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.0/24 130.161.0.0/16 any –P out ipsec

           esp/tunnel/10.0.0.216-10.0.0.11/require;

Обратите внимание на параметр -m tunnel — это очень важно. Сначала конфигурируется шифрование протоколом ESP для защищенного канала (SA) между конечными точками туннеля — 10.0.0.216 и 10.0.0.11.

Затем создается собственно туннель. Эта инструкция указывает ядру на необходимость шифрования всего трафика, который маршрутизируется из сети 10.0.0.0/24 в сеть 130.161.0.0/16. И наконец этот трафик должен быть отправлен хосту 10.0.0.11.

На компьютере 10.0.0.11 также необходимо выполнить некоторую настройку:

#!/sbin/setkey –f

flush;

spdflush;

add 10.0.0.216 10.0.0.11 esp 34501

        -m tunnel

        -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.0/24 130.161.0.0/16 any –P in ipsec

           esp/tunnel/10.0.0.216-10.0.0.11/require;

Если вы были внимательны, то наверняка заметили, что конфигурации обоих узлов сети практически одинаковые. Исключение составляет аргумент -P out, который для 10.0.0.11 изменился на -P in. В отличие от предыдущих примеров, на этот раз мы настроили передачу данных только в одном направлении. "Постройку" второй половины туннеля оставляем вам, в качестве самостоятельного упражнения.

У такой конфигурации есть еще одно название — proxy ESP , которое более точно отражает ее назначение.

Note

Для того, чтобы туннель заработал, в ядре должна быть разрешена возможность форвардинга (IP Forwarding)!

Томас Уолпаски (Thomas Walpuski) написал "заплату" для isakpmd (из OpenBSD), которая делает возможной совместную работу этого пакета и Linux 2.5 IPSEC. И даже больше! Теперь исходный код isakpmd в cvs уже содержит все необходимые изменения! Дополнительную информацию по этой теме вы найдете по адресу: http://bender.thinknerd.de/%7Ethomas/IPsec/isakmpd-linux.html.

isakpmd очень сильно отличается от racoon, но он многим нравится. Вы сможете найти его здесь: http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/. Получить более подробную информацию об OpenBSD CVS — здесь: http://www.openbsd.org/anoncvs.html. Томас также собрал тарболл (http://bender.thinknerd.de/%7Ethomas/IPsec/isakmpd.tgz) для тех, кто лишен возможности работы с CVS.

Кроме того, имеются "заплаты", которые обеспечивают взаимодействие FreeS/WAN с linux 2.5 ipsec. Вы найдете их здесь: http://gondor.apana.org.au/%7Eherbert/freeswan/.

FIXME: Этот раздел ждет своего писателя!

Андреас Йеллингаус (Andreas Jellinghaus) <aj@dungeon.inka.de> утверждает: "win2k: работает для случая с предопределенными ключами и IP-адресом в качестве идентификатора (не думаю, что Windows поддерживает FQDN или строки USERFQDN). Сертификаты также должны работать, но я их не пробовал.".

Питер Биринджер ( Peter Bieringer) сообщает: Ниже приводятся некоторые результаты (тестировался только туннельный режим, auth=SHA1):

DES: ok

3DES: ok

AES-128: ok

AES-192: not supported by CP VPN-1

AES-256: ok

CAST* : not supported by used Linux kernel

Tested version: FP4 aka R54 aka w/AI

Дополнительная информация — по адресу:

http://www.fw-1.de/aerasec/ng/vpn-racoon/CP-VPN1-NG-Linux-racoon.html.