Чтобы быть более конкретным, я планирую создать сайт электронной коммерции с балансировкой нагрузки. Два балансировщика нагрузки будут принимать https-соединения от трубок, а затем, как это характерно для ssl, им необходимо будет проверить соединение, расшифровать его, а затем перенаправить зашифрованный UN-запрос на серверы приложений.
В безопасной частной сети все было бы хорошо, однако я хочу запустить эту настройку с виртуальными машинами (slicehost). Теоретически машины должны быть в частной сети, однако вполне возможно, что машина (срез) другого человека может каким-то образом отслеживать трафик внутри сети. Я должен предположить, что сеть небезопасна.
Так. Я подумал об использовании ssh, и кто-то предложил мне использовать VPN (который я раньше не настраивал и о котором мало что знаю). Если я использую ssh, мне нужно будет постоянно контролировать соединение и проверять его работоспособность.
Думаю, я хотел бы знать, что делают другие люди?
Чем менее сложен, тем лучше (т. Е. Чем меньше вещей может пойти не так и потребовать контроля)
Это установка Linux. Я думаю об использовании фунта для балансировщика нагрузки. Еще нужно провести несколько тестов с этой стороны. Также начали читать о nginx.
OpenVPN действительно хорошая и гораздо более простая «альтернатива» IPSEC. OpenVPN - это полнофункциональное решение SSL VPN с открытым исходным кодом, которое живет в пространстве пользователя. Мультиплатформенность (windows, linux, osx ..) включает все основные дистрибутивы Linux.
Пример настройки:
Сначала мы генерируем статический ключ (не такой безопасный, но простой):
$ openvpn --genkey --secret static.key
(скопируйте этот ключ через scp на свои клиенты / серверы)
Сервер конфигурации (/etc/openvpn/server.conf)
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
Клиент конфигурации (/etc/openvpn/client.conf)
remote myserver.address.com
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
Убедитесь, что порт UDP 1194 открыт на сервере.
Запустить на клиент / сервер:
# server
openvpn --config /etc/openvpn/server.conf
# client
openvpn --config /etc/openvpn/client.conf
Чтобы убедиться, что VPN работает, вы должны иметь возможность пинговать 10.8.0.2 с сервера и 10.8.0.1 с клиента.
Для меня это звучит как работа для IPSEC.
IPSEC встроен в современные дистрибутивы Linux. Он полностью прозрачен для прикладного уровня и «просто работает». Я бы пошел по этому пути для внутримашинного общения, которое должно оставаться конфиденциальным.
Конфигурация IPSEC «от хоста к хосту» с предварительными общими ключами довольно проста. В CentOS, например, уже есть метод настройки этих соединений между хостами как часть обычных функций «сетевых скриптов» (см. http://www.centos.org/docs/4/4.5/Security_Guide/s1-ipsec-host2host.html).
В зависимости от используемого вами дистрибутива Linux его может быть очень легко настроить, или вам, возможно, придется немного поработать. Вам не понадобятся сценарии запуска / выключения VPN, сценарии мониторинга туннелей и т. Д. - все будет «просто работать» на уровне 3. Это, на мой взгляд, звучит как выигрышное решение.
Редактировать:
Я использую OpenVPN часто и интенсивно, поэтому я не «критикую» OpenVPN здесь, но в качестве решения вашей конкретной проблемы я считаю его неоптимальным по следующим причинам (в порядке степени моей озабоченности):
Создает параллельную сетевую инфраструктуру. Вы должны быть уверены, что ваше соединение внутри хоста использует правильные IP-адреса назначения, чтобы сообщения передавались через VPN, а не через общедоступную IP-сеть. Это может быть особенно интересно, если вы планируете использовать DNS-имена, поскольку вам нужно будет что-то сделать с вашим DNS (либо создать имена хостов hostA-secure, hostB-secure и т. Д., Либо создать «представление» DNS, которое всегда возвращает «безопасные» IP-адреса, когда запросы поступают от «безопасных» хостов), чтобы быть уверенным, что вы разрешаете имена в «безопасные» IP-адреса VPN.
OpenVPN - это точка-точка. Вам необходимо настроить сетку туннелей OpenVPN или направить трафик OpenVPN «концентратор и луч» через один хост. IPSEC полностью одноранговый, и вы можете легко настроить топологию ячеистой сети с помощью IPSEC и динамического ввода ключей. С предварительным разделением ключей это немного больше, но вы также можете настроить топологию сетки таким же образом.
OpenVPN - это программа пользовательского уровня, которую необходимо запустить. В этом нет ничего страшного, но IPSEC живет в пространстве ядра и "просто работает" без запуска каких-либо программ пользовательского пространства после его настройки.
Я не понимаю, почему люди думают, что IPSEC так ужасно сложно настроить. IPSEC с предварительными общими ключами так же легко настроить в современных дистрибутивах, как OpenVPN со статическими ключами (если не более того - обычно ваш дистрибутив автоматически запускает / останавливает его). IPSEC с динамическим ключом и использованием PKI требует почти тех же шагов, что и настройка OpenVPN с аутентификацией на основе сертификатов.
Сложность OpenVPN создания параллельной сетевой топологии со вторым набором IP-адресов была бы для меня убийцей. Я бы хотел, чтобы мои хосты могли разговаривать, используя те же IP-адреса, с которыми они получают незащищенную связь, «автоматически» прозрачно шифруя соединения между собой.
Изменить 2:
Для того, что описал плакат, я думаю, что IPSEC звучит как лучшее решение (по причинам, которые я описал выше). Если бы на плакате говорилось о взаимодействии с другими операционными системами, а не просто о защите связи между некоторыми хостами, я бы рекомендовал OpenVPN специально.
Я согласен с тем, что взаимодействие различных реализаций IPSEC Linux с чем-либо еще затруднено (как и взаимодействие почти любого IPSEC с почти любым другим внедрением IPSEC). Мне удалось заставить работать туннели Cisco PIX для OpenSWAN, и я добился некоторого успеха со статическими туннелями, идущими с компьютеров Windows. Я никогда даже не касался шестерен можжевельника, поэтому вообще не могу с ними разговаривать.
Я использовал OpenSWAN (на самом деле, когда это был FreeSWAN), и я согласен с тем, что документация сложна. Поскольку RedHat «выбрал» инструменты KAME для управления стеком IPSEC ядра Linux 2.6, я перестал следовать OpenSWAN. За последние несколько лет, когда мне понадобился IPSEC между хостами (на RHEL или CentOS - все, с чем я действительно работаю в мире Linux), инструменты KAME работали отлично. Я успешно использую "официальную" документацию от RHEL и документацию с сайта проекта KAME.
Для простого туннеля ssh с самоконтролем я использую автосш. Однако имейте в виду, что с высокой пропускной способностью вам, вероятно, придется потратить время на настройку полной VPN, поскольку ssh не так хорошо работает с большими объемами трафика.