Как обрабатывать зашифрованные и незашифрованные http-соединения через один порт

Пожалуйста, взгляните на следующую диаграмму.

Как это должно работать?

• Когда удаленный пользователь запрашивает http: // myhost.com:8080/*, запрос должен быть перенаправлен на http-сервер, который прослушивает порт 8008 интерфейса обратной связи. Это легкая часть.

• Когда удаленный пользователь запрашивает http: // myhost.com:8080/specialurl ...

  • Программа, выполняющая роль шлюза прикладного уровня, должна иметь возможность обновить соединение до зашифрованного сеанса ( без изменения портов ).

  • После установления зашифрованного сеанса с удаленным браузером он должен переслать запрос программе C, которая прослушивает порт 8000 интерфейса обратной связи.

Мои вопросы :

1. Вы когда-нибудь развертывали подобное решение в производственной среде? Если у тебя есть...
2. Какой продукт вы использовали в качестве шлюза приложений?
3. Не могли бы вы привести пример конфигурации?

Жесткие ограничения :

• У меня нет контроля над брандмауэром , и единственный порт, через который я могу получать внешний трафик на внутренний сервер, это 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 к внешней конечной точке, где вы можете настроить несколько портов прослушивания.