nginx reverse proxy guru gezocht :)

[tdemeyer]

Collega's,

Is hier iemand die NGINX in een reverse proxy config kent als zijn broekzak? Ik zou wat hulp kunnen gebruiken. Linux is niet mijn specialiteit, ik trek mijn plan, maar dan ook niet meer dan dat.

De situatie/
Wij hebben meerdere sites op ons intern netwerk, laten we ze voor 't gemak site1.local.lan, site2.local.lan noemen. Deze sites zijn via HTTPS bereikbaar. Certificaten van de interne sites worden door onze eigen interne "let's encrypt" uitgedeeld (gaat stukken makkelijker dan onze domein CA's hiervoor te gebruiken )
Diezelfde sites moeten extern ook bereikbaar zijn via (weer voor 't gemak) site1.extern.be en site2.extern.be.

Momenteel werkt dit vrij goed middels een windows server met IIS + ARR en URL rewrite.
Momenteel lopen we tegen een paar 'speciallekes' aan (out of scope hier), waardoor duidelijk wordt dat deze combinatie niet de meest eenvoudige is om te configureren... (niet het minst het gebrek aan deftige ondersteuning)

Daarom wil ik wil even bekijken of eea met NGINX eenvoudiger kan..
Dus ik heb een standaard ubuntu server + NGINX installatie erop (en certbot voor de let's encrypt certificaten)

Een paar dingen waar ik hulp kan gebruiken:

- in alle tutorials gaat men uit van een configfile <servernaam>.conf. Ben ik correct dat er effektief een conf file per serverbestemming moet gemaakt worden (dus in mijn voorbeeld heb ik een server1.conf en server2.conf nodig)?
- van buitenaf wil ik eigenlijk geen http verkeer toestaan, terwijl in tutorials een "listen 80" staat, maar geen "listen 443"? Ik vermoed dat het let' encrypt verhaal hier een rol in speelt.
- verkeer dat niet bestemd is voor een interne server mag genegeerd worden (dus wat mij betreft mag de default nginx pagina weg)
- dingen die ik nu nog niet heb opgemerkt...

Ik zoek: ofwel een uitgewerkt voorbeeld voor een conf file, waar ik kan op verder borduren of een goeie tutorial die ik kan volgen (ik heb er al een pak waar de output van commando's door versieverschillen bvb anders is dan wat in de tutorials staan, wat al eens tot verwarring kan leiden...)

[glorang]

Meer thuis in Apache reverse proxies, maar NGINX ook wel eens opgezet. Heb nog volgend werkend voorbeeld teruggevonden:

Code: Selecteer alles

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

server {
        listen 80;
        listen [::]:80 default_server;
        rewrite ^(.*) https://external.domain.com permanent;
}

server {
        listen 443 ssl;
        listen [::]:443 ssl;

        ssl on;
        ssl_certificate /etc/ssl/certs/<cert>.crt;
        ssl_certificate_key /etc/ssl/private/<cert>.key;

        server_name external.domain.com;

        location / {
                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_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_pass https://internal.domain.com;
        }
}

- in alle tutorials gaat men uit van een configfile <servernaam>.conf. Ben ik correct dat er effektief een conf file per serverbestemming moet gemaakt worden (dus in mijn voorbeeld heb ik een server1.conf en server2.conf nodig)?

Maakt niet uit, beide werken normaal maar meest propere is config per host/domein in sites-available en dan symlinken naar sites-enabled.

- van buitenaf wil ik eigenlijk geen http verkeer toestaan, terwijl in tutorials een "listen 80" staat, maar geen "listen 443"? Ik vermoed dat het let' encrypt verhaal hier een rol in speelt.

Zie example, server die op 80 listent verwijderen.

- verkeer dat niet bestemd is voor een interne server mag genegeerd worden (dus wat mij betreft mag de default nginx pagina weg)

De symlink naar de default site in sites-enabled verwijderen en NGINX herstarten zou voldoende moeten zijn.