Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
Проверьте настройки политик безопасности (выполните строки 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)!
7.4. Другое программное обеспечение для работы с ipsec
Томас Уолпаски (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/.
7.5. Взаимодействие с другими операционными системами через ipsec.
FIXME: Этот раздел ждет своего писателя!
7.5.1. Windows.
Андреас Йеллингаус (Andreas Jellinghaus) < [email protected]inka.de> утверждает: "win2k: работает для случая с предопределенными ключами и IP-адресом в качестве идентификатора (не думаю, что Windows поддерживает FQDN или строки USERFQDN). Сертификаты также должны работать, но я их не пробовал.".
7.5.2. Check Point VPN-1 NG
Питер Биринджер ( 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.
Глава 8. Маршрутизация групповых сообщений.
FIXME: Место редактора вакантно!
Multicast-HOWTO достаточно сильно устарел и по этой причине может быть местами неточен, а иногда и совершенно неверным.
Для того, чтобы иметь возможность маршрутизации групповых сообщений, необходимо определенным образом сконфигурировать ядро Linux. Это, в свою очередь, требует, чтобы вы определились — какой из протоколов групповой маршрутизации будет использоваться. На сегодняшний день, существует четыре основных протокола: DVMRP (групповая версия протокола RIP unicast), MOSPF (то же самое, но для OSPF), PIM-SM (Protocol Independent Multicast-Sparse Mode) — Протокол Групповой Маршрутизации, не зависящий от "обычного" протокола маршрутизации, который применяется для маршрутизации групповых сообщений в малочисленные группы (слово "sparse" можно перевести как "рассеянные", или "разреженные", или "малочисленные". прим перев.) и PIM-DM (то же самое, но для групп с компактным расположением).
Однако, в ядре Linux, эти опции отсутствуют, потому что собственно протокол обслуживается отдельными приложениями, выполняющими маршрутизацию, такими как Zebra, mrouted или pimd . Тем не менее включение дополнительных опций в ядре необходимо.
Независимо от протокола групповой рассылки необходимо включить опции IP: multicasting и IP: multicast routing. Для DVMRP и MOSPF этого будет вполне достаточно. Если вы предполагаете использовать протокол маршрутизации PIM, то вы дополнительно должны разрешить опции PIM-SM version 1 или PIM-SM version 2 , в зависимости от версии протокола PIM , используемого в вашей сети.
После того, как вы разберетесь с необходимыми опциями и пересоберете ядро, вы заметите, что во время загрузки, среди прочих, в списке присутствует протокол IGMP. Это Протокол Управления Группами (IGMP — Internet Group Management Protocol). К моменту написания этих строк, Linux поддерживал только версии 1 и 2 протокола IGMP , хотя версия 3 уже вышла. Однако для нас это не имеет большого знаения, поскольку IGMP v3 достаточно нов и его дополнительные возможности еще не скоро найдут широкое применение. В дальнейшем описании мы будем предполагать использование самых основных характеристик протокола IGMPv2, хотя будем встречаться и с IGMPv1.
Итак, мы разрешили групповую маршрутизацию в ядре. Теперь необходимо "сообщить" ему — что собственно со всем этим делать. Это означает, что нужно добавить в таблицу маршрутизации виртуальную сеть для групповых рассылок.
ip route add 224.0.0.0/4 dev eth0
(Естественно, в данном случае предполагается, что маршрутизация производится через устройство eth0! Если вы используете другое устройство – измените команду соответствующим образом)
А теперь "включим" перенаправление (forwarding):
echo 1 > /proc/sys/net/ipv4/ip_forward
и попробуем – что у нас получилось. Для этого ping-анем предопределенную группу, с адресом 224.0.0.1 (этот адрес зарезервирован IANA и обозначает "все узлы в данной сети". прим. перев.). В результате все машины в локальной сети, на которых включена поддержка возможности обслуживания групповых рассылок, должны ответить. Вы наверняка заметите, что все ответившие "подписываются" своим собственным IP-адресом, а не адресом 224.0.0.1. Вот это сюрприз! :) Все члены группы устанвливают в качестве исходящего, свой адрес, а не адрес группы.
