применение ssl для субдоменов

Это походит на задание для IPSEC мне.

IPSEC "испекся в" к современным дистрибутивам Linux. Это абсолютно очевидно для прикладного уровня, и "просто работает". Я пошел бы тем путем для коммуникации внутримашины, которая должна остаться частной.

"Хост для хостинга" конфигурации IPsec с предобщими ключами довольно прост. В CentOS, например, уже существует метод для конфигурирования этих соединений от хоста к хосту как части нормальной функциональности "сетевых сценариев" (см. http://www.centos.org/docs/4/4.5/Security_Guide/s1-ipsec-host2host.html).

В зависимости от распределения Linux Вы используете, может быть очень легко настроить, или Вам, вероятно, придется сделать немного работы. Вам не будет нужен никакой запуск VPN / сценарии завершения работы, туннельные контрольные сценарии, и т.д. - он будет все "просто работать" на уровне 3. Это, мне, походит на решение для победы.

Править:

Я использую OpenVPN часто и в большой степени, таким образом, я не "dissing" на OpenVPN здесь, но как решение Вашей конкретной проблемы, я думаю, что это является субоптимальным по следующим причинам (в порядке моей степени беспокойства):

• Это создает параллельную сетевую инфраструктуру. Необходимо будет быть уверены, что коммуникация внутрихоста использует правильные целевые IP-адреса, таким образом, что связь перемещается через VPN, а не общедоступную сеть IP. Это могло быть особенно забавой, если Вы планируете использовать имена DNS, так как необходимо будет сделать что-то к DNS (или создание безопасного от хосты, hostB-безопасного, и т.д. имена хостов, или создание DNS "представление", которое всегда возвращает "безопасные" IP-адреса, когда запросы прибывают из "безопасных" хостов) быть уверенным, что Вы разрешаете имена к "безопасному" дюйм/с VPN.

• OpenVPN точка-точка. Необходимо будет настроить сетку туннелей OpenVPN или направить трафик OpenVPN, "концентрируют и говорил" через единственный хост. IPSEC является полностью одноранговым, и можно легко настроить ячеистую топологию с IPSEC и динамическим манипулированием. С предобщим манипулированием это - немного больше работы, но можно настроить ячеистую топологию тот путь, также.

• OpenVPN является программой пространства пользователя, которая должна будет быть запущена. Это не огромное соглашение, но жизни IPSEC в пространстве ядра и "просто работает" w/o запускающий любые программы пространства пользователя, после того как оно настроено.

Я не добираюсь, почему люди думают, что IPSEC так ненавистно трудно настроить. IPSEC с предобщими ключами столь же легко настроить на современных дистрибутивах как OpenVPN со статическими ключами (если не moreso - обычно Ваши дескрипторы дистрибутива, запускающие/останавливающие его автоматически). IPSEC с динамическим манипулированием, с помощью PKI, требует почти тех же самых шагов как конфигурирования OpenVPN с основанной на сертификате аутентификацией.

Сложность OpenVPN, создающего параллельную топологию сети со вторым набором IP-адресов, была бы уничтожителем для меня. Я хотел бы, чтобы мои хосты смогли говорить с помощью тех же IP-адресов, что они получают незащищенную связь с, "автоволшебно" шифруя соединения друг между другом прозрачно.

Редактирование 2:

Поскольку, что описанный плакат, я думаю, IPSEC походит на лучшее решение (по причинам, которые я описал выше). Если бы плакат говорил о взаимодействии с другими операционными системами, и не только смотрящий безопасный коммуникация между некоторыми хостами, то я рекомендовал бы OpenVPN конкретно.

Я согласился бы, что взаимодействие различных реализаций IPsec Linux с чем-либо еще является трудным (как взаимодействует почти любой IPSEC почти с любым другим IPSEC implmentation, на самом деле). Мне удалось получить Cisco ЯЩИК ДЛЯ ПРОБНОЙ МОНЕТЫ к туннельной работе OpenSWAN, и я имел некоторый успех со статически включенными туннелями, прибывающими из машин Windows. Я даже не коснулся любого механизма Juniper, таким образом, я не могу говорить с ним вообще.

Я использовал OpenSWAN (когда это был FreeSWAN, на самом деле), и я соглашусь, что документы являются трудными. Так как Redhat "выбрал" инструменты KAME для управления стеком Linux 2.6 IPSEC ядра, я остановил followng OpenSWAN. В течение буквально нескольких раз, что мне был нужен от хоста к хосту IPSEC в последние несколько лет (на RHEL или CentOS - все я действительно работаю с в мире Linux), инструменты KAME сделали прекрасный. Я использовал "официальную" документацию от RHEL и документацию от стройплощадки KAME с успехом.