>[оверквотинг удален]
>> Кроме того Radius / TATACS не являеются частью IPSEC :)
>> Это отдельные протоколы - и к чему вы их вспомлини даже не
>> знаю.
>> Я просил вас показать именно в IPSec как это сделать - вы
>> показываете на сторонние вещи :)
>> Которые еще никак не связаны с задачей рассылки ключевых сертификтов.
> на текущий момент есть несколько распростаннённых реализаций ipsec -- одна от cisco
> в винде, klips в linux'ах.
> обычно для работы ipsec необходима служба IKE -- которая заведует авторизацией,аутентификацией
> ну и ключами кодирования.Нужна - но она не является частью IPSec :) IKE это отдельная часть от ipsec.
> обычно эта самая IKE (например racoon или strongswan) легко и просто уонектится
> к radius серверу для AA, также часто бывает что сама служба
> (обе перечисленные) умеют работать с сертификатами, со службами отзыва оных
Еще раз - с каких пор Radius является частью IPSec?
Это уже следующая сущность :)
Кроме того как бы с offline - когда нету прямой связи между узлами и надо где-то хранить ключевые сертификаты.
Еще вдруг потребуется что бы кто-то ключи генеровал - это что-то еще надо думать?
сколько костылей - вместо того что бы брать и ставить один комплекс :)
>[оверквотинг удален]
>>>> Костыли или не костыли - не вам решать. По ТЗ было такое
>>>> требование - оно реализовано.
>>> ну наконец вы признали что вы таки српать хотели на то как
>>> разумно -- было ТЗ мы ляпили -- точно так-же как ляпили
>>> новый tcp стёк -- ох,,, да какими-бы понятиями я не оперировал
>>> -- такое никак как костылестроение подругому, как быдлокод не назвать
>> TCP стек нужен для реализации IDS - что бы фильтровать через себя
>> все пакеты и держать state machine адекватную сокету. Хотя видимо это
>> слишком сложное объяснение :)
> видел я ваше IDS -- можете не продолжать
Когда я его реализовывал - типовые ошибки оно фильтровало, что сделали после того как вышло из лаборатории - я даже не в курсе :)
>[оверквотинг удален]
>>> в одну политику
>> Видимо Ыксперт тут вы. Я зарание сказал пользоваться только IPSec tunneling mode,
>> а не создавать gre тунель который будет шифроваться ipsec с роутингом
>> через этот gre тунель. В этом случае вам потребуется полика для
>> каждой сети и каждого endpoint.
>> Вы же описали использование ipsec в режиме transport mode :)
>> http://en.wikipedia.org/wiki/IPsec
> что только начал пользоваться гуглём и ничего лучше не того?
> вырезка из man setkey (всё то-же самое умет делать стандартная утилита ip
> -- только формат ввода другой)
да да :) только количество правил будет больше чем 1
> -----------
> это из примера
> так вот нижеприведённые записи будут пользоваться одним политикой
> spdadd 10.0.11.41/32[21] 10.0.11.33/32[any] any
>
> -P out ipsec esp/tunnel/192.168.0.1-192.168.1.2/require ;
> spdadd 10.0.11.42/32[21] 10.0.11.32/32[any] any
>
> -P out ipsec esp/tunnel/192.168.0.1-192.168.1.2/require ;
а теперь представим на одном конце сети
10.0.1.0/24, 10.0.5.0/24, 10.0.9.0/24
на другом конце будет 10.0.2.0/24, 10.0.6.0/24, 10.0.10.0/24 -
вопрос - сколько правил потребуется?
Теперь усложним задачу
появится третья нода у которой сети
10.0.3.0/24, 10.0.7.0/24, 10.0.11.0/24
сколько правил потребуется?
теперь оцени сколько правил потребуется каждый раз добавлять если каждая следующая нода будет иметь тоже 3 сетки за собой?
твой первый ответ
>>
правила
>>> фильтрации указывают какой трифик этой политикой будет пользоваться. хоть 40 подсетей
>>> в одну политику
>>
то есть вы считаете что 1 политикой вы можете описать обмен между
{10.0.1.0/24, 10.0.5.0/24, 10.0.9.0/24 } и {10.0.2.0/24, 10.0.6.0/24, 10.0.10.0/24}.
Я правильно вас понял ?
лана - можете не оправдываться, все уже и так понятно :)
> ваш высочайший профуровень.... короче диву даюсь, господин профессиАнал не пробЫвал читать
> rfc или какую другую более техническую литературу?
можно и на rfc - но вдруг будет сложно будет читать? если сразу не было понятно что CA не входит в задачу ipsec протокола и стандартов на него :) Для этого существует свой набор стандартов ;-)
>[оверквотинг удален]
>>>> Не - можно написать свое.
>>> читовы,читовы -- как-же оне не додумальсь написать ещё и свой CA, ах
>>> -- да это наверное потому что вся инфраструктура относительно сертификатов уже
>>> была, и нет не говорите мне что придумывать свою уникальное CA
>>> было не костылестроение.
>> Нету инфрастуктуры сертификатов. просто у OpenVPN ключевой центр совмешен с центральным
>> серверов, и принципиально не может быть обменов клиент-клиент без конекта на
>> центральный сервер.
> как-же, а давайте спросим сколько зарабытывает тот-же VeriSign, нет -- конечно же
> это вы это изобрели
Кто говорит о изобретении? Всегда говорится о реализации. это чуть разные вещи :)
На сим и закончим. Спасибо за развлечение :-)
