☰

Обновлять:

tag-icon • tag-icon reverse-proxy
Обновлять:

У меня есть домашний сервер Matrix и веб-приложение Django, расположенные на виртуальных машинах 192.168.81и 192.168.83соответственно. Домашний сервер создан с помощьюматрица-docker-ansible-deployи работает на nginx. Он получает и обновляет SSL-сертификаты черезТрафиксДавайте зашифруем.

Веб-приложение использует собственный сертификат Let's Encrypt. Хотя я могу получить и заставил их работать независимо, у меня возникли проблемы с их совместной работой на тех же портах 80 и 443.

После настройки обратного прокси-сервера на стороне веб-приложения для перенаправления трафика с его домена, вот так:

        SSLEngine On
        SSLCertificateFile /etc/letsencrypt/live/mysite.org/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/mysite.org/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/mysite.org/fullchain.pem

        # Enable SSL Proxy Engine
        SSLProxyEngine On
        ProxyPass / https://192.168.1.83/
        ProxyPassReverse / https://192.168.1.83/

Я получил:

[Wed Jan 17 07:13:21.567813 2024] [core:notice] [pid 33994:tid 125031783462784] AH00094: Command line: '/usr/sbin/apache2'
[Wed Jan 17 07:15:23.409061 2024] [proxy:error] [pid 34272:tid 125031640188608] (20014)Internal error (specific information not available): [client 192.168.1.85:44054] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83)
[Wed Jan 17 07:15:23.409180 2024] [proxy:error] [pid 34272:tid 125031640188608] [client 192.168.1.85:44054] AH00898: Error during SSL Handshake with remote server returned by /
[Wed Jan 17 07:15:23.409209 2024] [proxy_http:error] [pid 34272:tid 125031640188608] [client 192.168.1.85:44054] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 192.168.1.85 ()
[Wed Jan 17 07:15:23.715825 2024] [proxy:error] [pid 34273:tid 125031648581312] (20014)Internal error (specific information not available): [client 192.168.1.85:44070] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83), referer: https://192.168.1.83/
[Wed Jan 17 07:15:23.715945 2024] [proxy:error] [pid 34273:tid 125031648581312] [client 192.168.1.85:44070] AH00898: Error during SSL Handshake with remote server returned by /favicon.ico, referer: https://192.168.1.83/
[Wed Jan 17 07:15:23.715970 2024] [proxy_http:error] [pid 34273:tid 125031648581312] [client 192.168.1.85:44070] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 192.168.1.85 (), referer: https://192.168.1.83/

Обновлять:

Поскольку запуск двух серверов на одном и том же порту почти наверняка приведет к сбою SSL-сертификации (если только мы не хотим, чтобы они использовали один и тот же сертификат и использовали обратный прокси-сервер на отдельном сервере для перенаправления трафика с отдельных доменов на их собственные внутренние серверы), я хотел быиспользуйте порты, отличные от 80 и 443для размещения моего веб-приложения.

Как мне это сделать?

решение1

Это связано с тем, что сертификат SSL/TLS, представленный бэкэндом, 192.168.1.83:443, недействителен, поскольку для действительного сертификата всегда требуется доменное имя.

Я считаю, если вы где-то откроетеhttps://192.168.1.83/в браузере (конечно, если IP-адрес 192.168.1.83 доступен), вы получите предупреждение «Соединение не защищено».

Ваши варианты (примерно в порядке сложности):

  1. Слепо доверяйте сети бэкэнда и используйте SSL только на прямом прокси, подключаясь к бэкэндам через обычный http. Если ваш прямой прокси Apache работает на той же машине, что и эти виртуальные машины, и вы управляете как прямым прокси, так и виртуальными машинами, вот что я бы сделал.
  2. Если вы не доверяете внутренней сети и не выполняете шифрование как на внешнем, так и на внутреннем конце, то вам нужно либо
    • используйте доменные имена, действительные для сертификата, для подключения к бэкэнду (возможно, настроив IP-адрес для домена в файле hosts), убедитесь, что сам сертификат действителен и обновляется
    • явно установите доверие к сертификатам для этого соединения в конфигурации Apache
    • настройте собственный центр сертификации для внутренних служб и настройте его как доверенный на прямом прокси-сервере (но учтите, что вы легко можете оказаться в опасной зоне, если начнете работать с собственным центром сертификации!)
    • Я бы не рекомендовал настраивать прямой прокси-сервер для подключения через SSL без надлежащей проверки сертификата (например, отключения SSLProxy*опций) и вместо этого использовать вариант 1, если внутренняя сеть является доверенной, и один из трех вышеперечисленных вариантов в противном случае.
  3. Шифруйте только на бэкэнде и используйте балансировку нагрузки SNI вместо вашего прямого прокси-сервера Apache для пересылки https-трафика на ваш бэкэнд без повторного шифрования (на мой взгляд, это более продвинутая настройка, чем вариант 1, и я не знаю, подходит ли Apache для этого приложения).

Связанный контент