И для 10.0.0.11:

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

Чтобы проверить только что созданную конфигурацию, достаточно дать команду 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> в двух файлах. В качестве альтернативы я могу предложить откомпилированную версию.

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

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