LINUX.ORG.RU
ФорумAdmin

reverse_proxy to nextcloud

 , ,


1

1

Хочу перед клаудом поставить реверс прокси nginx. Соответственно прикрутить let’s encrypts на проксю, а трафик с прокси, так как nginx и клауд в одной LAN-сети, отправлять как proxy_pass http://192.168.0.21, но исходя из доки клауда, я понял что клауд не станет работать у себя на хосте по http, а будет толькоо по https. Получается придётся геморройничить с сертификатами и на проксе для клауда и на самом клауде? Подскажите, был ли у кого-нибудь подобный кейс или как упростить вариант с сертификатами…


А в чем проблема? Nginx будет прекрасно проксировать хоть на http, хоть на https. Дополнительно настраивать надо будет только в случае, если бекенд требует авторизацию по сертификатам, но и в этом случае все несложно.

У меня работает с почти дефолтным конфигом из доки + certbot:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    server_name  <SERVER_NAME>;

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

    #http2 on;                                 # uncomment to enable HTTP/2        - supported on nginx v1.25.1+
    #http3 on;                                 # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+
    #quic_retry on;                            # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+
    #add_header Alt-Svc 'h3=":443"; ma=86400'; # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+
    #listen 443 quic reuseport;                # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+

    location = /.well-known/carddav {
        return 301 $scheme://$host:$server_port/remote.php/dav;
    }
    location = /.well-known/caldav {
        return 301 $scheme://$host:$server_port/remote.php/dav;
    }
    location = /.well-known/openid-configuration {
        return 301 $scheme://$host:$server_port/index.php/apps/oidc/openid-configuration;
    }

    location / {
        proxy_pass <BACKEND_ADDR>;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        #proxy_buffers 16 4k;
        #proxy_buffer_size 2k;
        proxy_busy_buffers_size   512k;
        proxy_buffers           4 512k;
        proxy_buffer_size         256k;

        client_body_buffer_size 512k;
        proxy_read_timeout 86400s;
        client_max_body_size 0;

        # Websocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload";
    }
    
    listen 443 ssl; # managed by Certbot
    ssl_certificate <SSL_CERT>; # managed by Certbot
    ssl_certificate_key <SSL_KEY>; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    server_name <SERVER_NAME>;

    listen 80;
    return 301 https://$host$request_uri;
}
POLTER ★★
()
Ответ на: комментарий от POLTER

@POLTER Получается это у тебя конфиг на проксе, а на самом клауде покажешь? И второе, какой-нибудь онлиофис либо колабору прикручивал к клауду? Если да, то как? На одном хосте или в докере либо разнесены по разным виртуалкам?

Shprot
() автор топика

я понял что клауд не станет работать у себя на хосте по http, а будет толькоо по https.

Понял неверно. Единственное, что не не работает в такой связке - встроенный CODE сервер, из-за требования использовать тот же протокол, что и на реверс-прокси. Не работает, по сути только очень редкий юзкейс.

einhander ★★★★★
()

выкини нджинкс свой, зачем он тебе для таких задач? если нагрузки особо не будет смотри в сторону решений, которые могут автоматизированно обновлять серты и следить за ними, по пути делая все тоже самое что и нжинкс.

traefik, caddy

NorthernBlow
()
Ответ на: комментарий от NorthernBlow

У меня другое мнение по поводу готовых решений. Когда у тебя что-то поляжет в готовом решении, ты будешь искать причину и потратишь на это кучу времени, но когда ты делаешь всё «ручками» сам, то ты знаешь как и что у тебя работает.

Автоматизация обновления сертификатов - acme, let’s encrypt + cron
Мониторинг жизни сертификатов - zabbix, prometheus и т.п.

Зачем изобретать велосипед?

P.S> Хотелось бы услышать от «эксперта» чем плох nginx

Shprot
() автор топика
Ответ на: комментарий от Shprot

я не «эксперт» ни разу. Просто есть мнение что это наверное, не очень было бы оптимально. Смотри сам, если есть желание потыкать нжинкс то почему бы и нет. Он то по большей части для больших нагрузок изначально задумывался. А облако селф-хостед сходу навевает на мысли, что ты не будешь наверняка туда-сюда с сотен устройств гонять гигабайты.

NorthernBlow
()