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

10

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

альтернативный текст

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

  • Когда удаленный пользователь запрашивает 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), чтобы отличить защищенный трафик от незащищенного трафика с помощью использования другого порта сервера ... )
alemartini
источник
«Когда удаленный пользователь запрашивает http: // myhost.com:8080/specialurl ... Программа, выполняющая роль шлюза уровня приложения, должна иметь возможность обновить соединение до зашифрованного сеанса (без изменения портов)» ... как это возможно на стороне клиента? Будет ли клиентский браузер поддерживать запуск SSL через URL, который не содержит https?
Адам Бренд
Привет, Адам, и спасибо, что оставили свой комментарий. После запроса myhost.com:8080/specialurl браузер должен быть перенаправлен на myhost.com:8080/specialurl . Я не уверен насчет других браузеров, но последние версии Opera и Firefox, кажется, поддерживают это без проблем.
Алемартини

Ответы:

1

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

Вы когда-нибудь развертывали такое решение в производственной среде?

Я не - и я бы никогда не рекомендовал это делать. Как консультант я стараюсь поощрять своих клиентов использовать стандартизированные и проверенные технологии. Кажется, ни одна система не может должным образом реализовать эти RFC, за исключением крайних случаев - и это не было бы тем, что я хотел бы предложить или поддержать.

SirStan
источник
Привет, Стэн, и спасибо за отзывы. Я не знал о Гризли, и, к сожалению, я не знаком с Java. Вы когда-нибудь развертывали такое решение в производственной среде? Было бы здорово, если бы вы могли поделиться примером, показывающим, как это сделать. Еще раз спасибо, Алекс.
Алемартини
Хорошо, спасибо за редактирование вашего ответа и добавление дополнительной информации. Как вы можете видеть, я теперь сузил свой вопрос, заявив более четко, что я ищу зрелый продукт. Посмотрим, придет ли кто-нибудь хороший ответ на этот вопрос. Трудно поверить, что Apache - это единственное приложение в мире Linux, которое поддерживает RFC2817. Но если это так, или если никто не имеет реального опыта развертывания чего-то подобного с другим продуктом, я думаю, что у меня не будет выбора, кроме как попытаться решить это с помощью Apache.
Алемартини
0

Apache вам здесь не поможет. Он может прослушивать только HTTP или HTTPS-соединения (но не оба) на любом заданном порту.

Насколько я знаю, не существует «зрелого продукта», который бы реализовывал эту функциональность. Попросите сетевого администратора пробить еще одну дыру в брандмауэре или настроить туннель VPN или SSH к внешней конечной точке, где вы можете настроить несколько портов прослушивания.

сумеречный
источник