[devel] Re: [d-kernel] IPSec

[devel] Re: [d-kernel] IPSec

[Ed V. Bartosh]

>>>>> "DO" == Denis Ovsienko writes:

 DO>  Готов kernel-modules-ipsec_tunnel-std-up-0.9-alt1.0.src.rpm Из
 DO>  него собираются:
 DO>  kernel-modules-ipsec_tunnel-std-up-0.9-alt1.0.i586.rpm
 DO>  ipsecadm-0.9-alt1.0.i586.rpm
Оч хорошо, спасибо.
  
 DO>  Первый --- модуль IPSec для kernel-image-std-up-2.4.21rel-alt6
 DO>  Второй --- админтул для модуля После установки имеем возможность
 DO>  получить статические туннели IPSec с shared static keys.
Статические - это как ?
А поддержка x.509 ожидается ? Что там есть из enc-alg, auth-algs ?
А чем это круче, чем FreeS/WAN ?

-- 
Best regards,
Ed V. Bartosh

[devel] IPSec

[Denis Ovsienko]

Итак, получилось. Что конкретно:
За образец брался kernel-modules-sensors-std-up-2.7.0-alt5

Готов kernel-modules-ipsec_tunnel-std-up-0.9-alt1.0.src.rpm
Из него собираются:
kernel-modules-ipsec_tunnel-std-up-0.9-alt1.0.i586.rpm
ipsecadm-0.9-alt1.0.i586.rpm

Первый --- модуль IPSec для kernel-image-std-up-2.4.21rel-alt6
Второй --- админтул для модуля
После установки имеем возможность получить статические туннели IPSec с
shared static keys. Данный комплект отлично работает с ALM2.0, в который
был топором вбит этот самый модуль (тогда он конфликтовал с FreeS/WAN,
теперь нет), хотя в CryptoAPI поменялись имена модулей.
Теперь логическим завершением работы будет создание ifup-ipsec,
ifdown-ipsec, ifcfg-ipsec1.example и добавление их в net-scripts. Для
net-scripts у меня уже давно готовы такие скрипты для IP-туннелей и
сделана часть работы для миграции net-scripts полностью на iproute2.

src.rpm к заливке готов, единственно что sisyphus_check не находит моего
ключа, да я и сам его не нахожу в alt-gpgkeys :(
Касательно net-scripts: IP-часть я могу отдать хоть сейчас, IPSec ---
надеюсь, к концу недели, а насчёт iproute2 не могу сказать, там я зарылся
в некоторых функциях, нужно несколько свободных дней, которых нет.
Кстати, в рамках iproute2 migration я приделал фичу к ipcalc из
net-scripts. :)

--
    DO4-UANIC

Re: [devel] Re: [d-kernel] IPSec

[Denis Ovsienko]

>  DO>  Первый --- модуль IPSec для kernel-image-std-up-2.4.21rel-alt6
>  DO>  Второй --- админтул для модуля После установки имеем возможность
>  DO>  получить статические туннели IPSec с shared static keys.
> Статические - это как ?
> А поддержка x.509 ожидается ? Что там есть из enc-alg, auth-algs ?
> А чем это круче, чем FreeS/WAN ?
Я зимой был на orange party в офисе и рассказывал. Просьбам моим не вняли
и я собрал его сам, дождавшись, пока устаканится policy и появятся образцы
для подражания. Вот мои соображения:
1. В наших ядрах приложен CryptoAPI patch, в котором имеется всё
необходимое для работы IPSec. В то же время FreeS/WAN дублирует в себе
порядочное подмножество этих функций (отсюда и модуль в 291 КБ). CIPE
вообще, насколько я помню, наполовину работает в user-space. ipsec_tunnel
создаёт туннель средствами ядра.
3. Туннели статические. То есть администратор, определив алгоритмы и ключи
шифрования/подписи в каждом направлении, больше ничего настраивать не
должен.
То есть я не говорю, что это лучше в любой ситуации. Где-то лучше
FreeS/WAN. Для конкретно этого решения очень хорошая область применения
--- постоянный туннель, не зависящий от демонов и работы/неработы DNS,
например, связь 2-х офисов через враждебную/недоверенную сеть. Там, где
начинается динамика, и средства другие. Так что принимая за критерий
соответствие целей полученным результатам, вещь полезная.
2. В качестве cipher/digest может быть выбран любой модуль из
/lib/modules/`uname -r`/kernel/crypto/{ciphers|digests}
Это настоящий IPSec-туннель. Ядрёный ;)

--
    DO4-UANIC

[devel] Re: [d-kernel] IPSec

[Marat Khairullin]

On Wed, 23 Jul 2003 19:02:13 +0300 (EEST)
Denis Ovsienko <pilot@dgtu.donetsk.ua> wrote:

> Это настоящий IPSec-туннель. Ядрёный ;)

Т.е. это быстрее, чем user-space/daemon ...?
А насколько безопаснее?

Re: [devel] Re: [d-kernel] IPSec

[Denis Ovsienko]

> > Это настоящий IPSec-туннель. Ядрёный ;)
> Т.е. это быстрее, чем user-space/daemon ...?
> А насколько безопаснее?
1. Наверное, быстрее. Могу сказать, что Celeron-666 на 3DES-192bit
в состоянии пропустить не более 30Mbit/s --- считать много приходится,
наверное. Если кто-то может дать ещё benchmark, то пожалуйста.
2. Я не специалист по криптографии, просто для меня это работало (и
работает) надёжно и именно так, как мне нужно. Как водится, я ничего
не гарантирую, просто облегчаю жизнь себе и тем, кому понравится. :)

--
    DO4-UANIC