Перевод: Сгибнев Михаил
Эта страница находится в постоянной разработке, все Ваши замечания и
предложения принимаются здесь (http://www.netbsd.org/cgi-bin/feedback.cgi).
IPsec FAQ
* Начало
* IPsec = AH + ESP + IPcomp + IKE
* Транспортный режим и туннельный режим
* Управление правилами IPsec
* Конфигурирование поддержки IPsec в ядре
* Пример конфигурации: host-to-host encryption
* Пример конфигурации: host-to-host authentication
* Пример конфигурации: host-to-host encryption+authentication
* Пример конфигурации: IPsec VPN
* Пример конфигурации: Leaf-node tunnel
* Конфигурирование ключей AH/ESP с использованием IKE
* Установка ключей IPsec вручную и настройка правил начальной загрузки
* Взаимодействие с ipfilter
* Частые ошибки и методы отладки
* Известные проблемы
* Совместимость и соответствие стандарту
* Совместимость API с другими стеками IPsec
* Книги и другие дополнительные материалы
Другие ссылки
* FreeBSD IPsec mini-HOWTO , включая взаимодействие с Windows 2000
http://asherah.dyndns.org/~josh/ipsec-howto.txt
* KAME project
http://www.kame.net/
* KAME's NetBSD Implementation Note
http://orange.kame.net/dev/cvsweb.cgi/kame/netbsd/sys/netinet6/IMPLEMENTATION
* KAME's Implementation Note некоторые разделы могут быть не применимы к NetBSD
http://orange.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION
* implementaion differences between KAME platforms
http://orange.kame.net/dev/cvsweb.cgi/kame/COVERAGE
Начало
Код IPsec (IP security protocol) был добавлен в дистрибутив NetBSD в
июне 1999 года и включен в состав NetBSD 1.5 и более поздних. IPsec
предоставляет гарантию подлинности/конфиденциальности при обмене
информацией между двумя узлами IPsec. IPsec поддерживает IPv6 и IPv4.
Обратите внимание, что использование IPsec требует переконфигурации
ядра, так как поддержка IPsec не включена в ядро GENERIC.
Окружение пользователя включает поддержку IPsec там, где это возможно,
и поэтому не требует переконфигурирования, даже если Вы переключаетесь
между ядром, поддерживающим IPsec и не поддерживающим IPsec.
Если у Вас симтема младше 1.5, то ситуация следующая:
* Если Вы используете NetBSD 1.4.x, Вы можете посетить проект
KAME (http://www.kame.net/). В разделе посвященном IPsec Вы можете
найти патч для IPv6/IPsec одним tar.gz файлом. Этот патч подходит
для IPv4 и IPv6.
* Если ВЫ используете NetBSD-current выпущенную до ноября 1999, то
необходимо использовать специальный файл конфигурации ядра
(GENERIC.v6) для поддержки IPsec.
* Если ВЫ используете NetBSD-current выпущенную после 1999, то файл
конфигурации GENERIC содержит в себе закомментированые строки,
отвечающие за поддержку IPsec.
* До июня 2000 код, отвечающий за IPsec, поставлялся отдельно.
Обновите Ваше дерево каталогов, как указано здесь
(http://netbsd.org/Documentation/network/ipsec/oldtree.html). Если Вы
используете NetBSD-current, выпущенную после июня 2000 года, то
необходимый код уже интегрирован в дерево системы.
Внимание: мы иногда используем термин "IP security" в достаточно
широком смысле, включающем в себя системы сетевой защиты, фильтрации
пакетов и т.д.
IPsec = AH + ESP + IPcomp + IKE
IPsec состоит из нескольких отдельных протоколов, перечисленных ниже:
* Authentication Header (AH): обеспечивает гарантию подлинности
пакетов, прикрепляя крипто-сумму к пакетам. Если Вы получаете
пакет с АХ, и операция проверки контрольной суммы была успешна, то
Вы можете быть уверены по крайней мере, в двух вещах, при условии,
что удаленный хост и Вы используете одинаковый ключ при шифровании
и этот ключ никому неизвестен:
+ Пакет был сгенерирован именно удаленным хостом, а не
имитирован
+ Пакет не изменялся в процессе доставки
В отличие от других протоколов, АХ шифрует весь пакет, от
заголовка IP до конца пакета.
* Encapsulating Security Payload (ESP): обеспечивает гарантию
конфиденциальности пакетов, шифруя пакеты с использованием
алгоритмов кодирования. Если Вы получаете пакет с ESP и успешно
декодируете его, то можете быть уверены в том, что пакет небыл
перехвачен при доставке, при условии, что удаленный хост и Вы
используете одинаковый ключ при шифровании и этот ключ никому
неизвестен.
* IP payload compression (IPcomp): ESP обеспечивает кодирование
пакетов, однако кодирование имеет тенденцию отрицательно
сказываться на компрессии (такой, как ppp-компрессии). IPcomp
предоставляет возможность сжать пакет перед использованием ESP
(Конечно, Вы можете использовать и один IPcomp).
* Internet Key Exchange (IKE): Как отмечено выше, AH и ESP требуют
обмена секретными ключами между удаленными хостами. Для сохранения
связи между удаленными хостами мы должны обговорить метод обмена
ключами. IKE делает это возможным.
AH, ESP и IPcomp включены в код ядра. IKE представлен демоном,
функционирующем в окружении пользователя. Ядро и окружение
пользователя будут взаимодействовать между собой используя таблицу
управления ключами.
IKE - опциональная функция, Вы можете конфигурировать секретные ключи
для AH/ESP вручную, однако поймите, что Вы не можете использовать один
и тот же ключ все время, так как при длительном использовании ключа
увеличивается риск компрометации передаваемой информации.
Внимание: безопасность IPsec зависит от безопасности секретных ключей.
Если секретные ключи скомпрометированы, IPsec больше не предоставляет
гарантии безопасности передаваемой информации.
Имеются два RFC, определяющих работу IPSec - старый RFC1825 и
новый RFC2401.
http://www.normos.org/ietf/rfc/rfc1825.txt
http://www.normos.org/ietf/rfc/rfc2401.txt
userland programs IKE daemon
^ | AF_INET{,6} socket ^ | PF_KEY socket
=== | | =========================== | | ======== Kernel/user boundary
| v | v
transport layer, TCP/UDP key management table
^ | ^ | key information
| | | |
| v | v
IP input/output logic <-------> AH/ESP/IPcomp logic
^ |
| v
Network drivers (ethernet)
Транспортный режим и туннельный режим
AH, ESP и IPcomp имеют два режима работы: транспортный и туннельный.
Транспортный режим шифрует трафик между двумя удаленными хостами, а
туннельный режим обеспечивает инкапсуляцию пакетов в новый пакет
IPv4/v6. Туннельный режим разработан для использования VPN шлюзами.
[[transport mode]]
my host ======== peer's host
transport
mode
[[tunnel mode]]
(a) (b) (c)
my host ---- my VPN gateway ======== peer's VPN gateway ---- peer's host
tunnel mode
packets on (a): [IP: me->peer] payload
packets on (b): [IP: mygw->peergw] ESP [IP: me->peer] payload
<------------------------> encrypted
packets on (c): [IP: me->peer] payload
Управление правилами IPsec
Хотя ядро знает как защитить пакет, оно не знает какой пакет защищать.
Как раз "правила" IPSec и указывают ядру, какие пакеты должны быть
защищены.
Правило IPSec может быть реализовано per-packet или per-socket
способами.
* Per-packet: конфигурируется в ядре, так же как и пакетный фильтр.
Описывается как "Шифровать все пакеты, уходящие к 10.1.1.0/24".
Это наиболее подходит IPsec маршрутизатору.
* Per-socket: конфигурируется с использованием утилиты
setsockopt(2) для каждого конкретного сокета. Выглядит как
"Шифровать все исходящие пакеты с этого сокета". Наиболее подходит
для запуска серверных частей IPsec-aware программ.
Правило IPSec определяет IPsec протокол (AH, ESP или IPcomp),
применяемый к пакету. Вы можете таким образом сконфигурировать ядро,
чтобы использовать любую комбинацию AH, ESP и IPcomp. Вы даже можете
применять один протокол несколько раз к одному пакету, например
несколько операций ESP (польза этого сомнительна и может иметь только
академический интерес).
Конфигурирование поддержки IPsec в ядре
Обратитесь к tracking NetBSD-current для получения более детальной
информации (http://netbsd.org/Documentation/current/).
1. Раскомментируйте следующие строки в Вашем файле конфигурации ядра:
options IPSEC
options IPSEC_ESP
2. Соберите новое ядро
3. Установите ядро и перезагрузитесь
Окружение пользователя по умолчанию поддерживает IPSec и не требует
пересборки.
Дополнительно Вы можете установить racoon и/или isakmpd.
Пример конфигурации: host-to-host encryption
Если Вы хотите запустить host-to-host соединение (транспортный режим)
с секретными ключами, сконфигурированными вручную, то следущий вариант
вам подойдет. Для ручного конфигурирования ключей воспользуемся
утилитой setkey(8).
#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF
Первые две строки конфигурируют секретные ключи, используемые ESP.
Десятичное число называется (security parameter index). Это значение
может быть добавлено в пакет ESP и затем передано удаленному хосту,
что позволит ему получить секретный ключ. Номер должен быть уникальным
для каждого узла.
* С хоста 10.1.1.1 до хоста 20.1.1.1 используется алгоритм 3DES-CBC
с секретным ключом "hogehogehogehogehogehoge". Этот трафик
идентифицируется SPI 9876.
* С 20.1.1.1 на 10.1.1.1 трафик шифруется алгоритмом 3DES-CBC с
использованием секретного ключа
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
Последняя строка конфигурирует per-packet правило IPSec на этом узле.
По этой конфигурации узел 10.1.1.1 передает шифрованные пакеты на
20.1.1.1 всякий раз, когда секретный ключ конфигурируется в ядре. Эта
конфигурация не запрещает прохождение незашифрованных пакетов между
10.1.1.1 и 20.1.1.1. Если Вы хотите отклонять незашифрованные пакеты,
добавьте следующую строку:
spdadd 20.1.1.1 10.1.1.1 any -P in ipsec esp/transport//require;
На другом хосте (20.1.1.1) конфигурация будет похожа на
нижеприведенную. Обратите внимание, что адреса меняются в строке
"spdadd", а не в строке "add".
#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 20.1.1.1, peer is on 10.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 20.1.1.1 10.1.1.1 any -P out ipsec esp/transport//use;
EOF
Синтаксис конфигурации правил описан в ipsec_set_policy(3).
Запустите tcpdump(8) для того, чтобы убедиться, что пакеты
зашифрованы и их невозможно прочитать.
Вышеупомянутый пример использует удобочитаемые секретные ключи. Однако
использование таких ключей может послужить причиной компрометации
информации. Для реальной работы используйте бинарные ключи.
Длина ключа определяется алгоритмом. Для 3des-cbc длинна ключа должна
быть 192 бит (= 24 байта). Если Вы установите ключ короче/длиннее, то
это вызовет ошибку в setkey(8).
При использовании других алгоритмов конфигурация очень похожа. Вот
пример для rijndael-cbc (известного как AES). rijndael-cbc использует
128, 192 или 256 битные ключи. Здесь используется 128 битный ключ.
#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
# rijndael-cbc with 128bit key
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E rijndael-cbc "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF
Пример конфигурации: host-to-host authentication
AH конфигурируется как и ESP.
#! /bin/sh
#
# packet will look like this: IPv4 AH payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga";
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec ah/transport//use;
EOF
Пример конфигурации: host-to-host encryption+authentication
Если Вы конфигурируете секретные ключи и для AH и для ESP, то Вы
можете использовать их одновременно. Документация IPsec поддерживает
AH поверх ESP.
#! /bin/sh
#
# packet will look like this: IPv4 AH ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga";
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use ah/transport//use;
EOF
Пример конфигурации: IPsec VPN
Прежде всего, есть несколько проблем, связанных с конфигурированием
IPsec VPN:
* Маршрутизация должна быть настроена правильно.
* Не пытайтесь использовать туннельное IPsec устройство в качестве
NAT или пакетного фильтра. IPsec и NAT несовместимые протоколы.
Тем более, что из-за ограничений реализации и спецификации они не
совсем хорошо работают в системах 1.5. В настоящее время мы
пытаемся улучшить эту ситуацию, смотри "Interaction with
ipfilter" для получения более подробной информации.
* Конфигурирование VPN отличается от установки к установке. До сих
пор нет четкого определения, что такое VPN. Если Вы посылаете
вопрос в список рассылки, то должны описать что Вы хотите
получить, что у Вас есть и текущую сетевую конфигурацию.
Следующий пример имеет следующую сетевую конфигурацию: Задачи:
* Необходимо соединить машины с адресами из разных приватных
диапазонов сетей (10.0.1.0/24 и 10.0.2.0/24, рассматривайте это
как соединение машины в Кологриве и машины в Кукуево).
* Трафик между двумя облаками должен ходить без потерь
* Денег на аренду/прокладку волокон никто не дает.
#! /bin/sh
#
# Note that routing should be set up in advance, i.e. for this example:
#route -n add -net 10.0.2.0 10.0.2.1
#route -n add 10.0.2.1 10.0.1.1
# packet will look like this: IPv4 ESP IPv4 payload
# the node is on 10.0.1.1/20.0.0.1, peer is on 10.0.2.1/20.0.0.2
setkey -c <<EOF
add 20.0.0.1 20.0.0.2 esp 13245 -E blowfish-cbc "blowfishtest.001" ;
add 20.0.0.2 20.0.0.1 esp 13246 -E blowfish-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec esp/tunnel/20.0.0.1-20.0.0.2/require ;
spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec esp/tunnel/20.0.0.2-20.0.0.1/require ;
EOF
Пример конфигурации: Leaf-node tunnel
Этот туннельный режим может использоваться в случаях, когда необходимо
шифрация трафика от хоста до следующего роутера, откуда он должен идти
дальше в открытом виде. Например, беспроводное соединение хоста на
маршрутизатор, потому что защита 802.11 WEP очень слабая. Настройка
для хоста:
#! /bin/sh
#
# the node is on 10.0.1.5, router is on 10.0.1.1
setkey -c <<EOF
add 10.0.1.1 10.0.1.5 esp 1011 -E rijndael-cbc "rijndaeltest.001" ;
add 10.0.1.5 10.0.1.1 esp 1012 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.0.1.5/32 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.1.5-10.0.1.1/require;
spdadd 0.0.0.0/0 10.0.1.5/32 any -P in ipsec esp/tunnel/10.0.1.1-10.0.1.5/require;
EOF
В настройках для роутера поменяйте 'out' и 'in' в команде spdadd.
Конфигурирование ключей AH/ESP с использованием IKE
Здесь мы описываем следующую конфигурацию:
* Узел А и В используют транспортный режим ESP.
* Требуется использование ESP для обоих хостов для обмена пакетами
по всем протоколам.
* Используется IKE, хосты А и В аутентифицируются через обмен ранее
известными ключами.
Пожалуйста, тщательно следуйте инструкции. Запустите tcpdump(8) для
контроля за проходящими пакетами, вывод команды "netstat-sn" также
может сказать много интересного о работе IPSec.
1. Скачайте и установите racoon, версии не раньшей, чем
20000923a.
2. Скопируйте /usr/pkg/share/examples/racoon/racoon.conf.sample в
/etc/racoon/racoon.conf. Измените параметры в racoon.conf
сообразно своим требованиям. Очень критично то, чтобы на обоих
хостах использовалась одинаковая конфигурация racoon.conf.
3. racoon будет следовать параметрам IPsec, установленных в ядре при
определении ключей. Поэтому, мы должны конфигурировать IPsec в
ядре, используя setkey (8). На узле А правила IPsec будут
конфигурироваться следующим образом. В этом примере "A" и "B"
являются числовыми значениями адресов IPv4/v6.
A# setkey -c
spdadd A B any -P out ipsec esp/transport//require;
spdadd B A any -P in ipsec esp/transport//require;
^D
4. Для узла В:
B# setkey -c
spdadd B A any -P out ipsec esp/transport//require;
spdadd A B any -P in ipsec esp/transport//require;
^D
5. На обоих узлах подготовьте файс с ключами. Очень критично
правильно выставить разрешения для этого файла, иначе IPsec только
зря будет отнимать процессорное время (racoon не будет читать файл
со слабыми правами доступа).
7. Попробуйте обменяться пакетами между А и В. Вы должны увидеть
несколько сообщений от racoon и ключи должны установиться.
A# ping -n B
(with some delay, you will start seeing replies)
^C
A# setkey -D
Вы должны будете увидеть ключи, установленные racoon.
racoon договорится о ключах, основываясь на заданных правилах. Изменяя
описания правил мы можем легко менят конфигурацию для использования в
других случаях. Следующий пример конфигурирует ключи для такой
ситуации:
* Это почтовый сервер. Необходимо использование транспортного режима
AH, для каждого входящего соединения POP(TCP port 110) на машине
А. В - это клиент, который контактирует с А.
1. Конфигурация правил на A указывает не использовать AH для
локального трафика(обратите внимание, что racoon не может
обменяться ключами сам с собой). Порядок следования правил
очень важен, если его изменить, конфигурация не будет
работать.
A# setkey -c
spdadd A[110] A tcp -P out none;
spdadd A A[110] tcp -P in none;
spdadd A[110] 0.0.0.0/0 tcp -P out ipsec ah/transport//require;
spdadd 0.0.0.0/0 A[110] tcp -P in ipsec ah/transport//require;
^D
B# setkey -c
spdadd B A[110] tcp -P out ipsec ah/transport//require;
spdadd A[110] B tcp -P in ipsec ah/transport//require;
^D
2. Все остальное конфигурируется также, как и в примере выше.
Установка ключей IPsec вручную и настройка правил начальной загрузки
rc.conf(5) имеет специальный раздел, отведенный IPSec. ipsec=YES
запустит следующую команду во время начальной загрузки перед любой
сетевой активностью:
/sbin/setkey -f /etc/ipsec.conf
Например, Вы можете осуществлять безопасное монтирование /usr по NFS.
/etc/ipsec.conf должен содержать допустимые параметры для setkey(8),
по образу и подобию примеров, приведенных ранее, только без setkey -c
<<EOF ... EOF.
Взаимодействие с ipfilter
NetBSD включает в состав дистрибутива ipf(4), ipfilter от Darren
Reed. ipf(4) осуществляет фильтрацию пакетов, а правила IPsec
очень похожи на фильтрацию пакетов. Поэтому возможны конфликты при
взаимодействии.
В NetBSD 1.5 ipf(4) и IPsec туннельного режима взаимодействуют с собой
не очень хорошо. Пожалуйста, не конфигурируйте на отдельном узле
правила фильтрации ipf(4) и туннельный режим IPsec (типа NAT and IPsec
в одном флаконе).
С февраля 2001 в NetBSD-current взаимодействие ipf(4)/IPsec происходит
следующим образом:
* ipf(4) рассматривает пакеты только родного формата. ipf(4)
просматривает пакеты перед IPsec на входе и после IPsec на выходе.
Даже зная порядок обработки помните о следующем:
* Если Вы хотите, чтобы IPSec пакеты проходили ipf(4), Вы не
должны их запрещать правилами фильтрации. Вы должны разрешить IP
пакеты с определенным номером протокола (50 для ESP, 51 для AH).
Внимание: номер протокола это совсем не то, что номер порта
TCP/UDP.
* Пакет исходил из туннельных устройств (gif(4) и ipip(4)) будет
проходить через ipf(4). Возможно Вам потребуется идентифицировать
пакеты используя директивы имени интерфейса в ipf.conf(5).
Эти изменения доступны в NetBSD 1.6, 1.5.1 и более поздних.
Следующая диаграмма показывает новый порядок обработки пакетов:
outbound processing:
userland programs IKE daemon
| AF_INET{,6} socket ^ | PF_KEY socket
=========== | =========================== | | ======== Kernel/user boundary
v | v
transport layer, TCP/UDP key management table
| ^ | key information
| | |
v | v
+---->IP input/output logic <-------> AH/ESP/IPcomp logic
| | (incl. IPsec tunnel encapsulation)
tunnel |
devices |
| ipfilter rules
| |
+---------+
v
Network drivers (ethernet)
Частые ошибки и методы отладки
* Случается, люди путают следующие три понятия. Только понимание
вопроса позволит Вам писать работоспособные конфигурации.
* IPsec с ключами, установленными вручную.
В NetBSD для генерации ключей используется setkey(8). Ключи
остаются постоянными до повторной ручной генераци.
* IPsec с IKE, ключи заранее известны.
В NetBSD используется racoon. Аутентификация устройств
происходит по заранее определенным ключам. IPsec динамически
вносит ключи в ядро и автоматически меняет их через какое-то
время.
* IPsec с IKE, с использованием сертификатов.
В NetBSD используется racoon. Аутентификация происходит по
файлам сертификатов. racoon предоставляет IPSec динамически
сгенерированные ключи ключи, которые устанавливаются в ядро и
периодически изменяются.
Конфигурировать IPsec не просто! Есть очень много параметров,
которые должны контролироваться и отладка работы должна быть проведена
со всей серьезностью. Почитайте документы/книги/запросы на комментарии
или наймите консультантов перед тем, как конфигурировать IPSec.
Используйте tcpdump во время отладки сети. Даже с учетом того, что
трафик шифрован, Вы можете получить информацию о движении пакетов.
Если имеются ошибки с запуском racoon, используйте режим отладки для
вывода наиболее полной информации.
Конфигурация Вашей NetBSD машины и удаленной машины действительно
должна быть одинаковой. Пакет должен быть сгенерирован тем протоколом
и алгоритмом кодирования, который ожидает удаленная сторона. Если это
не так,то такие ошибки очень трудно отслеживаются. В IPsec ошибки
кодирования/идентификации будут отмечены как отброшенные пакеты, так
что все пакеты, отброшенные по причине неправильной конфигурации не
вызовут сообщения об ошибке.
На медленных машинах возможна ситуация, когда не произойдет обмена
ключами между racoon и демоном IKE, так как время обмена ключами
регулируется утилитой net.key.larval_lifetime sysctl MIB, по умолчанию
равной 30 сек. Если машины действительно медленные, то попробуйте
повысить это значение.
Известные проблемы
* Туннельный режим AH не работает из-за ограничений реализации
механизма правил в ядре IPSec. Не используйте этот режим.
* racoon находится в постоянной разработке и поэтому может иметь
свои ошибки/ограничения. Смотрите pkg/DESCR для получения более
подробной информации.
* IPsec и ipf плохо уживаются вместе.
* IPSec правила не проверяют ничего, кроме соответствия протоколам
tcp/udp. Используйте протокол "any" (только при соответствии
адресу), если хотите сделать сеть более безопасной Проблема
существует для любых пакетных фильтров.
Совместимость и соответствие стандарту
Реализация KAME IPsec (включенная в дерево NetBSD) соответствует
последнему набору IPsec стандартов. KAME's NetBSD Implementation
Note включает список где подтверждается функциональная совместимость.
Обратите нимание на то, что возможно изменение функциональности. Также
может оказаться что NetBSD и удаленное устройство будут работать
только в определенной конфигурации.
Совместимость API с другими стеками IPsec
Если Вы пишете приложения, взаимодействующие с IPsec, то Вас может
заинтересовать вопрос совместимости API различных платформ.
Мы имеем RFC2367 PF_KEY API для того, чтобы управлять базой ключей
в ядре. Основная часть этого API доступна в других реализациях стека
IPsec для UNIX-like систем и с некоторой степенью может быть
совместима (например, OpenBSD также использует PF_KEY API).
Нет никакого документа, который определяет API управления правилами
IPsec, поэтому не ожидается никакой совместимости со стеками IPsec
non-KAME.
Нет никакого стандарта для синтаксиса файла конфигурации. Вы будете
должны конвертировать его, если Вы хотите копировать конфигурацию с
non-NetBSD IPsec устройства.
С тех пор как NetBSD и FreeBSD совместно используют IPsec codebase от
одного производителя (KAME) появилась совместимость API. Обратите
внимание, что, однако, есть различия в NetBSD коде IPsec и FreeBSD
коде IPsec, так как используются разные версии KAME.
* NetBSD 1.5 включает стек KAME IPsec начала июня 2000.
* FreeBSD 4.0-RELEASE включает стек KAME IPsec начала ноября 1999.
* Нет никакого различия в в руководстве ipsec key configuration,
kernel behavior on AH/ESP operation, или ipsec_set_policy(3)
API.
* Есть различия в поведении PF_KEY socket, libipsec API for PF_KEY и
еще нескольких других. Вы можете поймать проблемы в том случае,
если будете писать приложения работающие с PF_KEY socket
непосредственно (такие как IKE daemon, racoon или утилита
управления ключами типа setkey(8)).
В течении развития от NetBSD 1.4 к NetBSD 1.5 код KAME IPsec
импортировался три раза. Импорты содержат обратно-несовместимые
изменения в API. Удостоверьтесь, что используете последний код.
Начиная с NetBSD 1.5 предоставляется бинарная совместимость или
проверка версии API.
Книги и другие дополнительные материалы
Есть буквально тонны доступных книг.
Search Barnes & Noble for books on "IPsec" (NOTE: мы не рекламируем этот магазин)
http://search.barnesandnoble.com/booksearch/results.asp?WRD=ipsec
Vova
