[NGINX] instellen als reverse proxy bij bestaande ssl config

[Verwijderd]

Op dit moment draai ik thuis Nextcloud op een Ubuntu 20 servertje met NGINX als webserver en certificaten afgehandeld door Let's encrypt. Deze is rechtstreeks met het internet verbonden en heeft een eigen publieke domeinnaam. Ik heb géén DNS provider die api-calls ondersteund, mocht dat relevant zijn.

Wat ik eigenlijk wil is de bestaande NC server gebruiken voor een paar meer diensten zoals Mastodon en Diaspora. Deze wil ik graag achter een reverse proxy hebben, i.v.m. veiligheid maar ook zodat ik daar netjes via een domeinnaam naar toe kan gaan. Liefst zou ik het interne verkeer ook https houden.

Ik ben _heel_ erg lang bezig geweest om de NGINX config goed te krijgen, ook voor webfinger dingen en ben nu een beetje huiverig geworden om nog wat te proberen.

Is er iemand hier die mij kan helpen met het aanpassen van een bestaande setup met NGINX met LE certificaten naar eentje met een reverse proxy (ook NGINX?) en ook LE certificaten? Ik kan wel guides vinden naar een compleet nieuwe setup, maar dat wil ik liever niet.

[Lethalis]

Je zal toch echt dingen moeten uitproberen en dan kunnen mensen hier daar weer bij helpen als je ergens tegen aanloopt.

Mijn idee hierbij zou simpelweg zijn om nieuwe server blocks te definiëren voor aparte (sub)domeinen en de nextcloud config zodoende met rust te laten.

In de nieuwe server blocks kun je d.m.v. proxy_pass requests doorsturen, waardoor nginx voor die (sub) domeinen als reverse proxy werkt.

[ Voor 21% gewijzigd door Lethalis op 23-07-2021 23:10 ]

[MartinMeijerink]

Kun je wat concreter zijn door /etc/nginx/nginx.conf ff te posten, en ook de configfiles die je daarin geincludeerd hebt?
En wat dat proberen betreft, je kan toch heel makkelijk ff een backup maken van je configfiles, en als het niet goed werkt zet je het gewoon weer terug.

[Verwijderd]

Ik ging er eigenlijk een beetje vanuit dat er wel meer mensen zijn die van een enkel domein over willen stappen naar meerdere. Vandaar dat ik eigenlijk gewoon hoop dat iemand er bij kan helpen, sample configs of wat ook. Dingen waar je op moet letten?

Aparte subdomeinen zonder de NC config aan te passen kan denk ik niet omdat Let's encrypt de certificaten aanvraagt via 80/443? Daar zal ik dan toch iets voor moeten regelen, maar daar wordt het al lastig. Bijna alle guides gaan uit van een nieuwe situatie met meerdere domeinen of exact de situatie die ik al heb.

Ik heb nog niet iets kunnen vinden met een uitleg om van 1 domein naar meerdere domeinen via een reverse proxy te gaan...

[Lethalis]

Verwijderd schreef op vrijdag 23 juli 2021 @ 23:16:
Ik heb nog niet iets kunnen vinden met een uitleg om van 1 domein naar meerdere domeinen via een reverse proxy te gaan...

http://nginx.org/en/docs/http/server_names.html

[Verwijderd]

/etc/nginx/nginx.conf :

code:

user www-data;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
multi_accept on;
use epoll;
}
http {
server_names_hash_bucket_size 64;
upstream php-handler {
server unix:/run/php/php7.4-fpm.sock;
}
include /etc/nginx/mime.types;
include /etc/nginx/proxy.conf;
include /etc/nginx/ssl.conf;
include /etc/nginx/header.conf;
include /etc/nginx/optimization.conf;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'"$host" sn="$server_name" '
'rt=$request_time '
'ua="$upstream_addr" us="$upstream_status" '
'ut="$upstream_response_time" ul="$upstream_response_length" '
'cs=$upstream_cache_status' ;
access_log /var/log/nginx/access.log main;
add_header X-Frame-Options "SAMEORIGIN" always;
sendfile on;
send_timeout 3600;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=500 inactive=10m;
open_file_cache_errors on;
keepalive_timeout 65;
reset_timedout_connection on;
server_tokens off;
resolver 192.168.1.1;
# resolver IP is your Router-IP (e.g. your FritzBox)
resolver_timeout 10s;
include /etc/nginx/conf.d/*.conf;
}

in conf.d:

letsencrypt.conf

code:

server {
server_name 127.0.0.1;
listen 127.0.0.1:81 default_server;
charset utf-8;
access_log /var/log/nginx/le.access.log main;
error_log /var/log/nginx/le.error.log warn;
location ^~ /.well-known/acme-challenge/ {
allow all;
default_type "text/plain";
root /var/www/letsencrypt;
}
}

nextcloud.conf

code:

server {
    if ($host = mijn.domein.nl) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


server_name mijn.domein.nl;
#Your DDNS adress, (e.g. from desec.io or no-ip.com)
listen 80 default_server;
}
server {
server_name mijn.domein.nl;
listen 443 ssl http2 default_server;
root /var/www/nextcloud/;
access_log /var/log/nginx/nextcloud.access.log main;
error_log /var/log/nginx/nextcloud.error.log warn;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

location ^~ /.well-known/acme-challenge {
proxy_pass http://127.0.0.1:81;
proxy_set_header Host $host;
}

#location / {
#return 301 https://$host$request_uri;
#}


location ^~ /.well-known {
# The following 6 rules are borrowed from `.htaccess`

        location = /.well-known/carddav     { return 301 /remote.php/dav/; }
        location = /.well-known/caldav      { return 301 /remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
        location ^~ /.well-known            { return 301 /index.php$uri; }

        try_files $uri $uri/ =404;
    }

client_max_body_size 10240M;
location / {
rewrite ^ /index.php;
}
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ \.(?:flv|mp4|mov|m4a)$ {
mp4;
mp4_buffer_size 100m;
mp4_max_buffer_size 1024m;
fastcgi_split_path_info ^(.+\.php)(/.*)$;
try_files $fastcgi_script_name =404;
include fastcgi_params;
include php_optimization.conf;
fastcgi_pass php-handler;
fastcgi_param HTTPS on;
}
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$>
fastcgi_split_path_info ^(.+\.php)(/.*)$;
include fastcgi_params;
include php_optimization.conf;
fastcgi_pass php-handler;
fastcgi_param HTTPS on;
}
location ~ ^/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
location ~ \.(?:css|js|woff|svg|gif|png|html|ttf|ico|jpg|jpeg)$ {
try_files $uri /index.php$uri$is_args$args;
access_log off;
expires 30d;
}

    ssl_certificate /etc/letsencrypt/live/mijn.domein.nl/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mijn.domein.nl/privkey.pem; # managed by Certbot
}

[Verwijderd]

Lethalis schreef op vrijdag 23 juli 2021 @ 23:22:
[...]

http://nginx.org/en/docs/http/server_names.html

Ik wordt daar geen wijs uit de syntax en er staat ook niets beschreven over ssl certs enzo. Maar misschien denk ik te moeilijk.

De term server blocks leverde me in elk geval ook deze link op, die had ik nog niet eerder gevonden: https://www.nginx.com/res...s/examples/server_blocks/ .

Misschien dat ik die maar eens ga proberen en dan ga kijken wat er omvalt

[Daantje20]

Je kan er ook voor kiezen deze oplossing te gebruiken.

https://nginxproxymanager.com/

[Hero of Time]

Er is zo ontzettend veel informatie te vinden over Nginx en hoe deze als reverse proxy is te gebruiken inclusief SSL, dat ik mij een beetje verbaas dat je hier moeite mee hebt. Je hebt nu ook netjes je config geplaatst, maar initieel geef je aan 'veel tevergeefs te hebben geprobeerd' zonder aan te geven wat dat zoal is.

Elke webserver heeft een config stuk per domein, dus je moet niet opeens gaan verwachten dat je in 1 server { } blok van Nginx opeens 10 domeinen op kan geven en dat het dan allemaal naar wat anders gaat.

Als laatste punt, Nginx is een stuk software voor servers. Je topic past daarom beter in het forum wat daarvoor bedoelt is. Ik verplaats je topic dan ook naar Server Software.

[Blokker_1999]

ugh, config die niet uitgelijnd is, zo moeilijk om te lezen.

Terwijl ik door je nextcloud conf ging heb ik trouwens een foutje opgemerkt. Op lijn 65 in het codeblock hierboven is achteraan wat weggevallen bij het copy/pasten hoop ik. Ik mis minstens een sluitend ) en een openend {

Als je in jet /etc/nginx dir gaat kijken zie je normaalgezien 2 directories staan: sites-available en sites-enabled. De 2de bevat symlinks naar bestanden in de eerste. En meestal heb je dan 1 bestand per (sub)domein. En dat gaat perfect met meerdere domeinen. Werken met meerdere (sub)domeinen in 1 bestand kan natuurlijk ook perfect. Voorbeeldje uit mijn eigen thuisserver:

code:

server {
        listen 80;
        listen [::]:80;
        server_name router.domein.be router;
        return 302 https://192.168.4.1/;
}

server {
        listen 80;
        listen [::]:80;
        server_name storage.domein.be storage;
        return 302 http://192.168.8.188:5000/;
}

Al wordt het bij wat grotere configs dan wat onoverzichtelijker. Maar voor elk (sub)domein heb je dus ergens een eigen server blok nodig, waarin je dan ook weer een config voor je SSL kunt opzetten. En de kans is groot dat certbot alles voor je zal regelen ivm de certificaten. Merk net op het subdomein bij mij thuis dat aan rproxy doet naar een andere server zelfs geen config staat voor de acme-challange op die server af te vangen. Certbot doet het dus op een andere manier.

En voor je je configs begint aan te passen, maak er even een kopie van, kan je altijd razendsnel terug. Daarna kan je beginnen aanpassen. En als er iets niet werkt, kijk dan in je logs waarom het niet werkt. Zowel de access als error log kunnen heel goede informatie geven. En ook certbot geeft heel goed weer waarom een certificaat niet kon aangemaakt worden.

[Verwijderd]

Hero of Time schreef op zaterdag 24 juli 2021 @ 12:46:
Er is zo ontzettend veel informatie te vinden over Nginx en hoe deze als reverse proxy is te gebruiken inclusief SSL, dat ik mij een beetje verbaas dat je hier moeite mee hebt. Je hebt nu ook netjes je config geplaatst, maar initieel geef je aan 'veel tevergeefs te hebben geprobeerd' zonder aan te geven wat dat zoal is.

Elke webserver heeft een config stuk per domein, dus je moet niet opeens gaan verwachten dat je in 1 server { } blok van Nginx opeens 10 domeinen op kan geven en dat het dan allemaal naar wat anders gaat.

Als laatste punt, Nginx is een stuk software voor servers. Je topic past daarom beter in het forum wat daarvoor bedoelt is. Ik verplaats je topic dan ook naar Server Software.

Er is misschien wel teveel te vinden voor nginx en reverse proxy. Maar zoals ik al aangaf: een simpel diagrammetje zoals hoe je dat moet doen met de server blokken en hoe het gaat werken met certbot is toch echt lastig te vinden. Per item wordt duidelijk uitgelegd wat het doen, maar een overzichtsplaatje met waar wat past is toch wel handig in mijn ogen. Maar goed: ik zit ook niet in NGINX verder, dus waarschijnlijk zijn mijn zoekopdrachten ook niet altijd even nuttig

[Verwijderd]

Daantje20 schreef op zaterdag 24 juli 2021 @ 11:16:
Je kan er ook voor kiezen deze oplossing te gebruiken.

https://nginxproxymanager.com/

Kijk, dat snap ik dus niet: hoe kan het nu in vredesnaam dat ik die nog niet een keer ben tegengekomen tijdens al mijn zoektochten? Thanks!

[Verwijderd]

Blokker_1999 schreef op zaterdag 24 juli 2021 @ 13:16:
ugh, config die niet uitgelijnd is, zo moeilijk om te lezen.

Terwijl ik door je nextcloud conf ging heb ik trouwens een foutje opgemerkt. Op lijn 65 in het codeblock hierboven is achteraan wat weggevallen bij het copy/pasten hoop ik. Ik mis minstens een sluitend ) en een openend {

Als je in jet /etc/nginx dir gaat kijken zie je normaalgezien 2 directories staan: sites-available en sites-enabled. De 2de bevat symlinks naar bestanden in de eerste. En meestal heb je dan 1 bestand per (sub)domein. En dat gaat perfect met meerdere domeinen. Werken met meerdere (sub)domeinen in 1 bestand kan natuurlijk ook perfect. Voorbeeldje uit mijn eigen thuisserver:

code:

server {
        listen 80;
        listen [::]:80;
        server_name router.domein.be router;
        return 302 https://192.168.4.1/;
}

server {
        listen 80;
        listen [::]:80;
        server_name storage.domein.be storage;
        return 302 http://192.168.8.188:5000/;
}

Al wordt het bij wat grotere configs dan wat onoverzichtelijker. Maar voor elk (sub)domein heb je dus ergens een eigen server blok nodig, waarin je dan ook weer een config voor je SSL kunt opzetten. En de kans is groot dat certbot alles voor je zal regelen ivm de certificaten. Merk net op het subdomein bij mij thuis dat aan rproxy doet naar een andere server zelfs geen config staat voor de acme-challange op die server af te vangen. Certbot doet het dus op een andere manier.

En voor je je configs begint aan te passen, maak er even een kopie van, kan je altijd razendsnel terug. Daarna kan je beginnen aanpassen. En als er iets niet werkt, kijk dan in je logs waarom het niet werkt. Zowel de access als error log kunnen heel goede informatie geven. En ook certbot geeft heel goed weer waarom een certificaat niet kon aangemaakt worden.

Dat bedoelde ik met "ik durf niet meer aan mijn config te komen". Zodra ik die blokjes neerzet bij regel 65 geeft nginx -t aan dat de config niet meer geldig is. Ook als ik (op mijn manier) probeer om al die ~location zooi in één blok te krijgen is het me nog nooit gelukt om een werkende config te krijgen. Vooral het hele webfinger gedoe heeft me echt uren gekost om een werkende config te krijgen

Als ik jouw verhaal zo lees en naar je config kijk denk ik dat het redelijk vergelijkbaar is qua functionaliteit. En dit sample kan ik dus beter lezen dan de samples op de Nginx website. Zal aan mijn beperkte ervaring liggen.

Ik ga vandaag of morgen eens even wat extra servertjes installeren en dan eens kijken of het niet "gewoon werkt", ook met certbot. Als dat niet werkt ga ik de Nginx proxy manager toch maar eens proberen.

Thanks!

[Blokker_1999]

Het is heel eenvoudig om fouten te maken in je config als je zelf aan het aanpassen gaat. Ik maak ze ook regelmatig. Dan moet ik soms meer dan eens gaan zoeken waar de fout juist zit, maar de logs helpen je goed op weg. Meestal is het ofwel een ontbrekende ; op het einde van een lijn of een } dat er te veel/weinig staat.

[Osiris]

En zoals @Blokker_1999 ook al aangaf: je configuratie is niet fatsoenlijk uitgelijnd. Daardoor mis je overzicht en is het een stuk makkelijker om een bepaald stukkie configuratie op compleet de verkeerde plek neer te zetten. Zo hoort een server {}-blok natuurlijk niet binnen een ánder server {}-blok. Maar als je niet doorhebt dat je überhaupt al ín zo'n blok zit, door verkeerde uitlijning, dan gaat 't al snel mis.

[Hero of Time]

Verwijderd schreef op zondag 25 juli 2021 @ 20:43:
[...]

Er is misschien wel teveel te vinden voor nginx en reverse proxy. Maar zoals ik al aangaf: een simpel diagrammetje zoals hoe je dat moet doen met de server blokken en hoe het gaat werken met certbot is toch echt lastig te vinden. Per item wordt duidelijk uitgelegd wat het doen, maar een overzichtsplaatje met waar wat past is toch wel handig in mijn ogen. Maar goed: ik zit ook niet in NGINX verder, dus waarschijnlijk zijn mijn zoekopdrachten ook niet altijd even nuttig

Er is toch normaal in de documentatie te vinden wat een server { } blok doet? Alle overige configuratie komt daar in. Voor een domein of hoeveel server_aliassen je aan dat stukje wilt geven. Wil je niet dat domein.tld, bla.domein.tld en superprivate.domein.tld allemaal hetzelfde doen, dan moet je die domeinnamen in aparte server { } blokken zetten en elk hun eigen aparte config geven qua document root, proxy_pass, of wat je er ook voor nodig hebt.

Lets Encrypt bied Certbot aan en deze heeft ondersteuning voor verschillende webservers. Alle webservers die het ondersteund krijgen die via aparte packages. Heb je die geïnstalleerd, dan moet je config bepaalde dingen bevatten zodat Certbot z'n ding er mee kan doen. Dit is ook op de site van Certbot gedocumenteerd.

[Falcon]

Daarnaast is het misschien een idee om alles in containers draaien op bijv Docker.

Hier kun je ook gebruik maken van dockerhub voor voorbeeld images van containers.

Doe alles in een github repo voor je versiebeheer dmv git in combi met VSCode met de diver extensions en linting/validators.