Как прокси-сервер обрабатывает нетрафик HTTP?
У меня есть приложение, которое делает небезопасное соединение по non-http порту демону сервера. Мы используем этот инструмент внутренне. Мог бы быть случай для некоторых наших пользователей для работы вне нашего средства. Я не хочу небезопасные соединения, сделанные из внешней стороны в наше средство. Этот трафик не шифруется и мог представлять угрозу.
Моя мысль состояла в том, чтобы использовать приложение как OSX Proxifier для проксирования трафика моего определенного приложения к прокси-серверу по https, использующему ssl. Я затем установил бы прокси-сервер, но что я не понимаю, как или то, если для прокси возможно затем передать те данные к другому серверу.
Существует несколько стандартных способов проксирования входящего общего сетевого трафика («обратное проксирование»).
Если входящий трафик - это только HTTP (S), то веб-сервер может его перенаправить . См. Например ProxyPass в Apache.
Произвольный входящий трафик TCP может быть проксирован с помощью SOCKS . Клиент с поддержкой SOCKS оборачивает свой запрос в запрос SOCKS и отправляет его на сервер SOCKS, который интерпретирует и перенаправляет запрос. Это часто делается с помощью ssh, который предлагает параметр DynamicForward для настройки прокси-сервера SOCKS. Он открывает порт, который прослушивает клиентский хост, пересылает SOCKS-трафик через зашифрованное соединение, а также интерпретирует и направляет его на сервер. Многим сетевым клиентам можно приказать использовать прокси-сервер SOCKS.
Другой распространенный способ - туннелирование трафика через SSL. stunnel, например, сделает это. На клиенте он прослушивает порт, обертывает трафик в SSL и отправляет его на сервер. На сервере stunnel разворачивает SSL и перенаправляет трафик в настроенную службу.
Вы можете отправлять разные типы трафика на один и тот же порт, часто 443, используя мультиплексор портов на другом конце, чтобы выяснить, какой тип трафик и направьте его в нужную службу. sslh и sshttp - два, которые обрабатывают общий случай мультиплексирования HTTP и SSH на одном порту, например, завернутые в SSL и отправленные на порт 443. Наконец, TCPMUX - протокол, который был разработан для мультиплексирования портов. xinetd, например, может его интерпретировать, но он не реализован ни в одном из известных мне клиентов. (Вы бы хотели обернуть его в SSL.)