Как обрабатывать зашифрованные и незашифрованные HTTP-соединения через один порт
Обратите внимание на следующую диаграмму.
Как это должно работать?
Когда удаленный запрос http: // myhost.com:8080/*, запрос должен быть перенаправлен на http-сервер, который прослушивает порт 8008 интерфейса обратной связи. Это легкая часть.
Когда удаленный пользователь запрашивает http: // myhost.com:8080/specialurl ...
Программа, выступающая в роли шлюза уровня приложения, должна иметь возможность обновлять соединение до зашифрованного сеанса (без смены портов)
После установления зашифрованного сеанса с удаленным браузером он должен перенаправить запрос программе C, которая прослушивает порт 8000 интерфейса обратной связи.
Мои вопросы:
- Вы когда-нибудь развертывали подобное решение в производственной среде? Если у вас есть...
- Какой продукт вы использовали в качестве шлюза приложений?
- Не могли бы вы привести пример конфигурации?
Жесткие ограничения:
- я нет контроля над брандмауэром, и единственный порт, через который я могу получить внешний трафик на внутренний сервер, - это 8080. Номер порта не имеет значения, дело в том, что на уровне межсетевого экрана открыт только один порт, который перенаправляет входящий трафик на внутренний сервер.
- Внутренний сервер должен работать под управлением Linux (в настоящее время он работает под управлением Debian Lenny)
- Удаленным пользователям не нужно ничего, кроме текущего веб-браузера и подключения к Интернету для доступа к этому серверу. Это означает, что обратная переадресация портов через SSH здесь не подходит.
- Мне нужен продукт, который был протестирован на производстве и который можно легко развернуть. Я не собираюсь разрабатывать собственный шлюз приложений (если бы это было так, я бы задавал этот вопрос при переполнении стека вместо того, чтобы задавать его при сбое сервера).
Мягкие ограничения:
- Я бы не хотел использовать Apache в качестве шлюза приложений (хотя я готов сделать это, если это единственно возможный выбор)
- Если возможно, шлюз приложений должен быть зрелым программным продуктом с открытым исходным кодом.
Продукты, опробованные на уровне шлюзов приложений (безуспешно)
- nginx
- lighttpd
- фунт
Соответствующие RFC
- RFC2817 (... объясняет, как использовать механизм обновления в HTTP / 1.1 для инициирования безопасности транспортного уровня (TLS) через существующее TCP-соединение. Это позволяет незащищенному и защищенному HTTP-трафику использовать один и тот же хорошо известный порт. ...)
- RFC2818 (... описывает, как использовать TLS для защиты HTTP-соединений через Интернет. Текущая практика состоит в том, чтобы использовать слой HTTP через SSL (предшественник TLS), отличая защищенный трафик от небезопасного с помощью другого порта сервера. ...)
Один порт, чтобы управлять ими всеми, показывает, что кто-то хотя бы реализовал его в мире Java.
Вы когда-нибудь развертывали такое решение в производственной среде?
Я не делал - и никогда не рекомендовал бы это делать. Как консультант я стараюсь побуждать своих клиентов использовать стандартизированные и проверенные технологии. Кажется, что ни одна система не реализует эти RFC должным образом, за исключением крайних случаев - и это не то, что я хотел бы предлагать или поддерживать.
Apache здесь не поможет. Он может прослушивать только соединения HTTP или HTTPS (но не оба сразу) на любом заданном порту.
Насколько мне известно, не существует «зрелого продукта», реализующего эту функциональность. Попросите сетевого администратора пробить вам еще одну дыру в брандмауэре или настройте туннель VPN или SSH к внешней конечной точке, где вы можете настроить несколько портов прослушивания.