SNIproxy

[vitus_wagner]

Нашел тут замечательный инстурмент SNIProxy

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

Под Bananian собралось, тестирвоать еще не тестировал, потому что для тестирования нужно иметь хотя бы два https-ных сервера, в локальной сети. А у меня в ЭТОЙ сети нет ни одного.

Хотя, конечно, такую штуку надо держать на роутере, а не на одном из серверов внутри сети. Но собирать ее под dd-wrt или openwrt мне ломы.

Comments

[vitus_wagner]

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

sniproxy не выполняет никаких криптографических операций. Она смотрит на расширение SNI которое не зашифровано, и, в зависимости от этого, перенаправялет соединение тому или иному внутреннему серверу.

То есть с точки зрения внутренних серверов всё выглядит так, как будто с ними соединение осуществляется непосредственно, по отдельному IP.

У этих серверов могут быть разные реализации TLS, они могут работать на разных операционных системах, иметь разные хранилища сертификатов и даже разный административный контроль. И при этом входной IP адрес и порт - общие.

[foboss.livejournal.com]

Nginx научился работать в режиме "ssl passthrough" (без терминации сессий SSL) начиная с 1.9.0 (в opensource версии, в "Nginx+" раньше).

А так, как правило для целей tcp-проксирования ставят HAProxy. Он умеет очень многое: тот же ProxyProtocol, который отправляет на backend ip-адрес клиента в режиме TCP (без терминации ssl!) или, к примеру, можно сделать так, что на 80 порту браузеру будет отдаваться nginx/apache, а ssh-клиенту — sshd.