В статье "Racoon Roadwarrior Configuration (http://www.howtoforge.com/racoon_roadwarrior_vpn)" продемонстрирована настройка Racoon (http://ipsec-tools.sourceforge.net/) для организации IPSec туннелей для клиентов с динамическими IP.URL: http://www.howtoforge.com/racoon_roadwarrior_vpn
Новость: https://www.opennet.ru/opennews/art.shtml?num=9038
Эх, если бы он не был еще и таким "тяжелым" - можно было бы использовать, а так задержки на этом тунеле не детские.
Кстати, я вот прочитал статью и так и не понял, а почему для Linux? Как по мне, то точно так же можно будет сделать и под *BSD и под другими осями куда racoon портирован.
А что для Вас не тяжелое?
openvpn
оно работает в userspaace и больше чем 10 мегбит вы врядли получите. IPSEC работает в ядре - поэтому меньше грузит проц -> имеет большую проиводительность
Если я не прав приведите свои аргументы.
Нормальную производительность и низкую латентность при > 10Мбпс могут обеспечить только аппаратные модули AES или 3DES, в каком бы space'е vpn-концентратор не работал.
Погоняйте голос Г711 в транке хотя бы 20 линий на совтовом vpn + 10Мбпс остального трафика - узнаете. И QoS не поможет.
1. Racoon входит в состав ipsec tools - штатный вариант организации автоматического обмена ключами соединения IPSec на всех BSD (если не путаю isakmpd он вытеснил окончательно). Видимо Linux более модное слово...
2. Не в курсе как у Linux, для тех кому "горько надо очень быстро" в FreeBSD есть вариант FastIPSEC. Статистикой по вопросу не владею,но полагаю слово FAST (в совокупностьи с подразумевающимся аппаратным обеспчением) стоит там не зря и решит критичный вопрос. Хотя ИМХО, взяв эту же статью и рисунок из нее, где роадвариор сидит в инете или за инетом, пропускной способности обычного IPSEC подключенния хватит для прозрачной, с точки зрения пользователя, работы. С точки зрения трафика прирост в случае туннелирования = sizeof(IP HEADER). Проседание можно будет пожалуй заметить на слабых CPU (АМД К5 333 работал в ЛВС wifi шлюзом без ощутимых потерь под FreeBSD 5.2.1 и большую проблему создавлял тогда еще сыроватый racoon. Большие файлы гонялись регулярно).
3. Здесь же на opennet уже пару лет лежат ссылки на более концептуально изложенные howto.
Давно темой не интересовался, может сейчас вопрос решен. Но раньше Traversal NAT в racoon под FreeBSD,например, не работал. Соответственно, когда сами клиенты находятся за NAT, IPSEC туннель не поднимался. Для подобных решений, имхо, лучше использовать L2TP.
Уже точно год как работает это дело в линухе - правда в то время патчилось ядро. Сейчас уже мб и ванильное умеет.
и ванильное умеет и openswan умеет
насчет ракуна в линухе не знаю, в бсд с год в стандартной поставке
В openbsd это решено достаточно давно и без ракуна, штатно в поставке с помощью isakmpd
В версии 4.0 используется ipsecctl
Ракун ведь всего лишь IKE-демон, а кто в BSD будет SA поднимать (которое в /etc/ipsec.conf прописаны)? Может поэтому и написано про linux, что там он обе функции выполняет? :-\p.s. У меня родной ядерный freebsd-шный ipsec на паре p4-2400 50Мбит выдавал (5мег в секунду)...
50 Мбит при каком количестве пакетов в сек - вот когда у вас будет их около 30 тысяч/c то Вы задумаетесь.