Подскажите, пожалуйста, что происходит здесь? (На этом же хосте успешно получаю сертификат на домен при помощи CertBot). Порты 443 и 80 проброшены наружу (хотя 80 в итоге хотелось бы закрыть, если это вообще получится). #215
Comments
|
Тут по логам видно две проблемы:
|
Порт 80 можно закрыть - lets-proxy2 работает через tls-alpn-01 валидацию - по тому же 443-му порту, на котором и слушает траффик и 80й порт для него не нужен. Но нужно чтобы сам lets-proxy мог обращаться на 80й порт по тому же IP-адресу на который приходят запросы (в варианте настроек по-умолчанию). |
|
|
Меня смущает вопрос как в докер-контейнере (и можно ли) lets-proxy2 будет обращаться к websockify по "внешнему" IP-адресу. Конечно надо проверить, но что-то я сильно подозреваю, что внутри контейнера это работать не будет. |
В большинстве случаев этого должно хватать, если у вас не хватает - хорошо бы понять как в вашем случае можно автоматически определять публичный IP. Чтобы обойти это прямо сейчас - можно выключить проверку домена по IP-адресу (параметр IPSelf) - тогда прокся не будет самостоятельно проверять адрес домена перед походом в letsencrypt и может превышать лимиты неавторизованных запросов когда на ваш IP-адрес будут ходить роботы с несуществующими доменами. Можно указать разрешённые IP-адреса в поле IPWhiteList.
Если задавать домены в конфиге и их список заранее известен - возможно вам тогда не нужен lets-proxy и можно поставить nginx/apache + certbot для получения сертификатов и прописывания настроек. Тогда и доп. фоновых процессов держать не нужно.
Опишите вашу схему - куда приходит обращается клиент, как идёт запрос, куда lets-proxy должен его передавать. |
|
Клиент посылает запрос из браузера на сервер, ответ на который отдаёт ему TurboVNC через websockify. noVNC (веб-клиент VNC) является по сути набором html+css+js, для которых websockify есть чем-то вроде веб-сервера. lets-proxy2 мне подходит идеально, потому что до моих с ним экспериментов я запускал самописный скрипт на питоне, который вызывает CertBot, и подсовывал сертификат в виде опции websockify. Это в целом работает, но есть проблема горячего перечитывания сертификата на лету в случае, если сервер не будет перезапускаться очень долго (> 3 месяцев). Даже если я повешу питон-скрипт, обновляющий сертификат, на cron, он перевыпустит сертификат, но websockify не подхватит новый сертификат без перезапуска. А чтобы организовать ему перезапуск и не убить сессию активного клиента - надо дополнительно каким-то образом отслеживать его активность. Что является дополнительной проблемой, и не такой уж и простой. Так что прокси, прозрачно преобразующий https в http и умеющий обновлять сертификат горячим способом без перезапуска серверной части - это просто очень хорошее решение. Я приложу свой питон-скрипт. Он берёт доменное имя для получения сертификата из socket.gethostname() (команда Этот питон-скрипт, работающий при помощи CertBot'а, не устраивает меня только тем, что websockify не умеет по-горячему перечитывать сертификат без перезапуска. Поэтому сам собой напрашивается вариант проксирования https в http. В принципе, если Вы заинтересованы в работе lets-proxy2 в разных хитрых условиях, то я готов подождать сколько надо, придумайте что-то изящное для моего случая. Но я не знаю как заставить noVNC писать имя домена в заголовках. Может он со стороны клиента (в браузере) сам ресолвит домен, браузер проверяет сертификат, а потом скрипт обращается к серверу исключительно по IP-адресу. Возможно, что это не единственная софтинка, которая так делает. Про nginx + свой этот питон-скрипт я подумаю, если уж совсем не получится ничего добиться от lets-proxy2. Но, в любом случае, спасибо Вам за помощь. |
|
А где в этой схеме должен быть прокси? По моим представлениям схема должна быть примерно такой:
И в этой схеме запрос в проксю должен приходить из клиентского браузера, чтобы весь трафик между клиентом и сервером шёл по https. |
|
Ну вот, Вы правильно описали схему. Прокси должен быть в докер-контейнере, чтобы было проще разворачивать весь тандем на разных хостах. При таком подходе надо замаппить во внешнюю систему папку, где lets-proxy2 хранит файлы сертификатов. Чтобы они были доступны при следующем запуске lets-proxy2. Я рассматриваю вариант, когда прокси может быть и вне контейнера. Это менее удобно, но почему бы и нет. Так не придётся маппить хранилище сертификатов. В этом случае lets-proxy2 будет слушать внешний порт 443 и переадресовывать на порт 80, который переадресован на докер-контейнер (порт 80, опять же, слушает websockify внутри контейнера). Более предпочтительно конечно запрятать прокси в контейнер, чтобы упростить и ускорить деплой. |
|
Да, Вы предлагали поместить lets-proxy2 в другой контейнер. Для упрощения я бы всё же не стал так делать, а поместил бы всю систему вместе с прокси в один. А фоновую работу можно попробовать организовать при помощи supervisord, например. Я в этом не силён, но что-то такое можно попробовать нагуглить для фоновой работы в докере. |
Тогда запрос в проксю должен идти из браузера пользователя, в т.ч. подключение к noVNC - тоже через lets-proxy, если там http/https. т.е. прокся должна принимать именно запрос от браузера клиента, тогда с заголовками всё должно быть хорошо.
Да
Как вариант можно использовать docker-compose, а в нём указать параметр Сеть будет использоваться хостовая и если там на интерфейсе есть публичный IP-адрес - он определится автоматически. |
|
noVNC же живёт в браузере клиента в виде скриптов, так что запрос идёт от браузера. А подскажите ещё, пожалуйста, что происходит здесь. Домен (jitsi.ldnova.com) точно поступает из заголовков.
|
|
У этого домена IP-адрес не входит в список разрешённых (IP-адрес домена определился как 127.0.0.1):
Чтобы получить сертификат домен должен указывать на публичный IP-адрес, т.к. на него придёт запрос от letsencrypt. |
|
Понятно, спасибо. Как-то всё сложно с lets-proxy2. Попробую nginx + CertBot. Закрываю тему. |
Подскажите, пожалуйста, что происходит здесь? (На этом же хосте успешно получаю сертификат на домен при помощи CertBot). Порты 443 и 80 проброшены наружу (хотя 80 в итоге хотелось бы закрыть, если это вообще получится).
Originally posted by @Oleg-N-Cher in #202 (comment)
The text was updated successfully, but these errors were encountered: