Лак для использования для https

Question

Вот ситуация. У меня есть клиенты по защищенной сети (https), которые разговаривают с несколькими бэкэндами. Теперь я хотел установить обратный прокси-сервер для основной балансировки нагрузки (на основе данных заголовка или файлов cookie) и небольшого кэширования. Итак, я думал, что лак может быть полезен.

Но лак не поддерживает ssl-соединение. Как я читал во многих местах, цитируя, "Varnish does not support SSL termination natively". Но я хочу каждое соединение, т. Е. клиент-лак и лак-бэкенд будут превышать https. Я не могу иметь текстовые данные в любой точке сети (есть ограничения), поэтому ничего не может быть использовано в качестве SSL-терминатора (или может быть?).

Итак, вот вопросы:

• Во-первых, что это значит (если кто-то может объяснить в простых терминах), что «Лак не поддерживает прекращение SSL изначально».
• Во-вторых, этот сценарий хорош для реализации с использованием лака?
• И, наконец, если лак не является хорошим соперником, следует переключиться на другой обратный прокси. Если да, то что будет подходящим для сценария? (HA, Nginx и т.д.)

Answer 1

что это значит (если кто-то может объяснить в простых терминах), что «Лак не поддерживает прекращение SSL нативно»

Это не означает, что лак имеет встроенного - Поддержка SSL. Он не может работать по пути с SSL, если SSL не обрабатывается отдельным программным обеспечением.

Это архитектурное решение, автором Лака, который обсуждал его созерцанием интегрирующей SSL в Varnish еще в 2011 году

Он основан это на ряде факторов, не последним из которых было желающих сделать это право, если вообще, соблюдая стандартную библиотеку де-факто для SSL, является openssl, которая представляет собой лабиринтную коллекцию из более чем 300 000 строк кода, и он не был уверен в этой кодовой базе и не имел шансов на благоприятную соотношение затрат и выгод.

Его вывод в то время был, одним словом, «нет».

Это не одна из вещей, о которых я мечтал делать в детстве, и если мне снится об этом сейчас, я называю это кошмаром.

https://www.varnish-cache.org/docs/trunk/phk/ssl.html

Он вновь концепцию в 2015 году

Его заключение, опять же, был "нет".

код трудно, криптографический код двойного плюса жесткий, если не двойной квадрат-жесткий, и миру действительно не нужен еще один кусок кода, который делает половину жопы работы в криптографии.

...

Когда я смотрю на то, как HAProxy Вилли Tarreau, я с трудом, чтобы увидеть какие-либо значительные возможности для улучшения.

Нет, лак по-прежнему не будет поддерживать поддержку SSL/TLS.

Вместо этого в Varnish 4.1 мы добавили поддержку протокола Willys PROXY, который позволяет передавать дополнительные данные из прокси-сервера, завершающего SSL, например HAProxy, в Larnish.

https://www.varnish-cache.org/docs/trunk/phk/ssl_again.html

Это расширение может упростить интеграцию лака в окружающую среду с требованиями шифрования, поскольку она обеспечивает еще один механизм для сохранения идентичности оригинального браузера в выгруженном настройки SSL.

Этот сценарий хорош для реализации с использованием лака?

Если вам нужен лак, используйте его, осознавая, что SSL необходимо обрабатывать отдельно. Обратите внимание, однако, что это не обязательно означает, что незашифрованный трафик должен пересекать вашу сеть ... хотя это делает более сложную и голодную настройку процессора.

ничто другое не может быть использован в качестве SSL-терминатора (или может быть?)

Протокол SSL может быть переложена на лицевой стороне Лака, и восстановила на задней стороне Varnish, все на той же машине, которая работает с лаком, но отдельными процессами, с использованием HAProxy или stunnel или nginx или других решений перед и после лака. Любой трафик в ящике работает в пределах одного хоста, поэтому, возможно, это не точка уязвимости, если сам хост защищен, так как он никогда не покидает машину.

если лак не является хорошим соперником, я должен переключиться на какой-то другой обратный прокси-сервер

Это полностью зависит от того, что вы хотите, и потребность в стеке, его стоимости/выгоды для вас, ваш уровень знаний, доступность ресурсов и другие факторы. Каждый вариант имеет свой собственный набор возможностей и ограничений, и, конечно же, неслыханно использовать более одного в одном стеке.