Веб-прокси, чтобы избежать переадресации портов
Привет. Интересно, может ли кто-нибудь помочь мне определить, какое решение использовать. Мне нужно запустить облачный сервер, который действует как прокси для HTTP-запросов, но на стороне веб-сервера у меня нет фиксированного IP-адреса или возможности открыть порт доступа к приложению (например, 8080), который был бы переадресацией портов. Идея состоит в том, чтобы веб-сервер подключался к решению облачного сервера и оставался в постоянном соединении в ожидании запросов. В свою очередь, клиент делает запрос к облачному серверному решению, которое предоставляет доступ к приложению веб-сервера, завершая цикл связи HTTP между клиентом и сервером.
Кто-нибудь знает, какую технологию или решение я могу использовать для решения этой проблемы?
Привет!
Основываясь на ответе Давидго, может ли эта структура быть хорошей идеей?
(Правильное решение - для серверов IIS отключать статические IP-адреса и платить за них. Мне не нравится приведенное ниже решение, так как оно не будет стабильным "серверного уровня". Я не вдавался в вопросы безопасности - запустите соответствующий брандмауэры и / или ограничения портов в зависимости от ситуации)
Решение состоит из двух частей - первая - сделать веб-серверы «доступными» для «Облака». Для этого я бы использовал OpenVPN (его можно было бы заменить на другие туннели или VPNS) - в частности, я бы запустил VPN-сервер «в облаке», и каждый сервер приложений .Net мог бы связываться с сервером OpenVPN в облаке. Мне нравится OpenVPN, потому что он может довольно быстро реагировать на восстановление при изменении IP-адресов, использует UDP и прост и повсеместен.
Вторая часть - это передача ваших данных миру. В зависимости от ваших требований существует множество решений. Одним из таких решений может быть запуск обратного прокси, такого как Apache или NGINX, с правилами proxy_pass. Вы можете получить доступ к удаленным серверам по их IP-адресам OpenVPN RFC 1918, и mod_proxy будет указывать направление. Самый простой способ - разместить службы Apache и OpenVPN в одной и той же VPN, но вы можете разместить их в одной сети на разных виртуальных машинах для масштабируемости, если вы обрабатываете сетевую маршрутизацию. (Помните, что вам необходимо иметь как статический внешний IP-адрес, так и IP-адреса VPN "internal / RFC1918", способные связываться друг с другом.
Конечно, вам не обязательно использовать Apache или NGINX. Вы можете использовать Squid и кэширование статического контента или даже полностью отказаться от прокси и использовать правила IPTables DNAT для VPN-сервера, если у вас все в порядке с доступом к серверам через отдельные порты.