Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

#!/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 уже содержит все необходимые изменения! Дополнительную информацию по этой теме вы найдете по адресу:

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.

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. Вот это сюрприз! :) Все члены группы устанвливают в качестве исходящего, свой адрес, а не адрес группы.

ping –c 2 224.0.0.1

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