Попытка заставить Websockify/noVNC работать через обратный прокси

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

а именно:

Я запускаю его как ./utils/launch.sh --vnc localhost:5901

если я подключусь к нему как https://<machine>:6080/vnc.html?host=<machine>&port=6080

он отлично работает, и я могу подключиться к сеансу vnc

Однако я хочу иметь возможность подключиться к нему через обратный прокси-сервер через порт 443.

В Apache 2.4.10 (-8 в Debian Jessie) я настроил свою прокси-линию так, чтобы

ProxyPass /home http://127.0.0.1:6080/
ProxyPassReverse /home http://127.0.0.1:6080/
ProxyPass /websockify wss://127.0.0.1:6080/websockify retry=3
ProxyPassReverse /websockify wss://127.0.0.1:6080/websockify retry=3

и я подключаюсь к нему как https://<machine>/vnc.html?host=<machine>&port=6080

Это все еще работает, так как пока выборка html/javascript проходит через обратный прокси-сервер, я все еще говорю соединению через веб-сокет, чтобы пройти через 6080, и это работает.

Однако, когда я меняю его на https://<machine>/vnc.html?host=<machine>&port=443

Я отлично получаю html/javascript, но когда он устанавливает соединение, в firefox (и chrome и IE, но эта ошибка конкретно из firefox) я быстро получаю

Firefox can't establish a connection to the server at wss://<machine>/websockify.

а в noVNC вижу сообщение об ошибке

127.0.0.1: ignoring socket not ready

google-chrome websocket apache firefox vnc
person spotter    schedule 31.12.2014    source источник
comment
Большая часть этой мотивации заключается в том, чтобы позволить мне поддерживать сеанс переадресации порта ssh на хосте перехода и иметь noVNC только для прослушивания на локальном хосте, чтобы я мог защитить доступ к нему паролем. Еще одним преимуществом было бы то, что он мог бы работать даже в ограниченных средах, когда я могу получить к нему доступ только через 443.   -  person spotter    schedule 31.12.2014

Ответы (1)


arrow_upward
3
arrow_downward

Оказывается, если кто-то хочет проксировать веб-сокеты через прокси-сервер https, нужно сделать часть прокси-сервера обычными веб-сокетами (ws://), а не безопасными веб-сокетами (wss://), что имеет смысл, поскольку прокси-сервер https обрабатывал бы ssl порция уже и делать нечего.

ProxyPass /websockify ws://127.0.0.1:6080/websockify retry=3
ProxyPassReverse /websockify ws://127.0.0.1:6080/websockify retry=3

внесите это изменение, и все работает.

person spotter    schedule 05.01.2015
comment
Вы уверены, что поток веб-сокета зашифрован в этой настройке, и у вас есть цитата или способ, которым я мог бы это проверить? Я рассматриваю его для использования в глобальной сети, поэтому все должно быть зашифровано. - person Headbank; 23.11.2019
comment
да, apache выполняет терминацию ssl. в противном случае это не сработает, так как оно устанавливает ssl-соединение с apache. - person spotter; 25.11.2019