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