Выбрать главу

Блок 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 — все должно работать.

7.2.4. Как сохранить настройки туннеля в безопасности.

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

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

$ openssl dgst upstairs.public

MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1

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

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

7.3. Туннели ipsec

Выше мы обсуждали работу с 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)!