înregistrare Logare
Puncte:0
avatar Server

Utilizați Nginx proxy pass (reverse proxy) pentru a servi un site găzduit Apache cu SSL

drapel us
Jason Hollowell

Am căutat pe forumuri (și în alte părți de pe web) și am găsit informații similare, dar aparent nu identice. Sper că nu dublez aici.

Am un site care rulează pe un server Apache. Are deja un certificat SSL (prin LetsEncrypt) și rulează fără probleme.

Am configurat recent o mașină „în fața” ei care rulează Nginx. Acea mașină deservește trei domenii (cu un certificat de la LetsEncrypt).

Aș dori să transmit cereri pentru domeniul de pe mașina Apache prin Nginx, dar întâmpin probleme în a afla setările corecte. Am făcut acest lucru cu două mașini de servire Apache în trecut, fără prea multe dificultăți, dar sunt nou în Nginx și, în mod clar, nu sunt suficient de priceput cu el.

Configurarea serverului virtual pe care o am pe mașina Nginx (printr-un router) este:

Server {
    ascultați domain.pointing.to.apache.com:443 ssl;
    nume_server domain.pointing.to.apache.com;
    Locație / {
        root 192.168.11.14/var/www/html/;
        proxy_set_header X-Forwarded-Host $gazdă:$port_server;
        proxy_set_header X-Forwarded-Server $gazdă;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass domain.pointing.to.apache.com;
    }
}

Dar, desigur, lui Nginx nu îi place acest lucru și nu se va reîncărca după adăugarea vs. Orice sfat etc. va fi cel mai apreciat.

Notă - Bănuiesc că este evident, dar 192.168.11.14 este în spatele routerului meu și nu este expus direct la rețea.

Jason

Editare/Actualizare:

Informații importante lipsesc din întrebarea mea inițială:

  1. Mașina Nginx orientată spre rețea pe care vreau să-l inversez proxy către Apache deservește și trei subdomenii ale domeniului meu principal pe care vreau să-l inversez proxy (sub1.mydomain.com, sub2.mydomain.com, sub3.mydomain.com). Toate trei au un certificat SSL de la LetsEncrypt.

  2. Serverul Apache din rețeaua locală avea și un certificat emis de LetsEncrypt, care deservește mydomain.com până când am pus mașina Nginx în fața lui.

  3. Am șters acum certificatele SSL de pe mașina Apache, am șters serverul virtual https și am configurat un server virtual simplu pentru portul 80.

  4. Setarea mea implicită Nginx trimite solicitări către http //www.mydomain.com, care pur și simplu partajează o pagină html foarte plictisitoare pentru moment.

  5. Am instalat certificate SSL pentru domeniul https //www.mydomain.com pe caseta Nginx și vreau să folosesc recomandarea oferită de Tero pentru a inversa solicitările https de proxy pe mydomain.com către și de la caseta locală Apache. După cum urmează:

Server {

    asculta 443 ssl;
    ssl_certificate /etc/letsencrypt/live/www.mydomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.mydomain.com/privkey.pem;
    
    nume_server www.domeniulmeu.com;
    Locație / {
        proxy_set_header X-Forwarded-Host $gazdă:$port_server;
        proxy_set_header X-Forwarded-Server $gazdă;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://192.168.11.14;
    }
}

Problema este că primesc o eroare 502 Bad Gateway de la mașina Nginx... deci cred că am ceva în neregulă cu setările Nginx... Mă apropii, dar nu chiar acolo. În plus, am observat că încearcă să accesez www.domeniulmeu.com fara https nu mai serveste pagina html plictisitoare...se transfera/rescriu pe https -> www.domeniulmeu.com și la aceeași poartă 502 proastă.

566
1 + 0
Puncte:2
avatar Server
drapel us
Tero Kilkanen

Există patru erori în configurația dvs.:

  1. asculta directiva acceptă numai adrese IP, dacă doriți să vă legați la o anumită interfață. Cu toate acestea, în practică, vă legați bine la toate interfețele, deci asculta 443 ssl E deajuns.

  2. rădăcină locația specifică calea sistemului de fișiere către fișierele pe care nginx ar trebui să le servească direct. Din moment ce dvs / locația trebuie să fie inversată, specificând rădăcină nu este deloc necesar, deoarece niciun fișier nu este servit de nginx. Deci, eliminați rădăcină directivă.

  3. proxy_pass necesită o adresă URL către serverul din amonte. În acest caz, ar trebui să fie proxy_pass https://192.168.11.4.

  4. Nu ați specificat certificatul TLS/cheia privată, acestea trebuie specificate cu certificat_ssl și cheie_certificat_ssl directive.

Deci, în general, configurația dvs. ar trebui să fie:

Server {
    asculta 443 ssl;
    ssl_certificate /cale/spre/certificat;
    ssl_certificate_key /cale/la/cheie;
    
    nume_server domain.pointing.to.apache.com;
    Locație / {
        proxy_set_header X-Forwarded-Host $gazdă:$port_server;
        proxy_set_header X-Forwarded-Server $gazdă;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://192.168.11.4;
    }
}

Dacă doriți să utilizați certificate Letsencrypt pe serverul proxy invers, trebuie să serviți /.bine cunoscute directorul de pe server:

Server {
    asculta 80;

    locație /.cunoscut {
        try_files $uri =404;
    }

    Locație / {
        # Redirecționează solicitările http către https
        returnează 301 https://domain.pointing.to.apache.com;
    }
}

Cu această configurație, puteți rula Certbot pe serverul proxy invers, care va valida apoi dreptul de proprietate asupra domeniului și va obține certificatul/cheia.

Cu toate acestea, cu această configurație, nu puteți rula Certbot pe serverul care rulează în rețeaua locală. Dacă rețeaua locală este considerată sigură, atunci vă sugerez să utilizați http în loc de https între serverul proxy invers și serverul de rețea locală.

Dacă https este necesar între serverul proxy invers și serverul de rețea locală, atunci puteți utiliza această configurație:

Server {
    asculta 80;

    # Încercați să serviți fișiere `.well-cunoscut` din sistemul de fișiere local. Dacă nu este găsit, trimiteți la serverul din amonte
    locație /.cunoscut {
        try_files $uri @local;
    }

    locație @local {
        trece_proxy http://192.168.11.4;
    }

    Locație / {
        returnează 301 https://domain.pointing.to.apache.com;
    }
}
0 + 9
drapel us
Jason Hollowell
Tero, mulțumesc foarte mult pentru ajutor. Din păcate, trebuie să fac ceva greșit. Am editat setările disponibile pentru site-uri, am activat și am încercat să reîncarc Nginx, dar am primit următoarea eroare: „număr invalid de argumente în directiva „ssl_certificate””. Certificatul SSL se află pe serverul de la distanță (192.168.11.4 în acest exemplu), ceea ce nu ar trebui să fie o problemă... sau nu?
0
Răspunde
drapel us
Tero Kilkanen
Trebuie să aveți un certificat pe serverul pe care este instalat nginx și să introduceți calea către fișierele certificat/cheie în directivele corespunzătoare.
0
Răspunde
drapel us
Jason Hollowell
Tero, mulțumesc din nou. Mi-a fost teamă că probabil așa era. Deci, problema mea este că nu sunt sigur că înțeleg cum să instalez certificate pe mașina mea cu acces la net pentru un domeniu care urmează să fie deservit din spatele acelei mașini orientate către net. Când rulez certbot, se verifică pentru a se asigura că eu (mașina mea și IP-ul) răspund la IP-ul (domeniul) pentru care încerc să obțin certificatul, dar mașina mea care se confruntă cu rețea nu va răspunde (nu cred), deoarece nu Nu aveți un server virtual configurat pentru a asculta acel domeniu.
0
Răspunde
drapel us
Jason Hollowell
În plus, este posibil să am o configurare prea complicată aici, deoarece domeniul meu principal este cel care urmează să fie deservit de mașina din rețeaua mea locală printr-o altă mașină (care rulează Nginx) care deservește trei subdomenii din acel domeniu. (de exemplu, one.mydomain.com, two.mydomain.com și three.mydomain.com sunt pe mașina orientată spre net, iar domeniul meu.com se află pe computerul din spatele mașinii orientate către net). De ce a fost configurat în acest fel este o poveste lungă... este chiar posibil ceea ce fac aici?
0
Răspunde
drapel us
Tero Kilkanen
Am adăugat mai multe informații despre cum ați putea gestiona certificatele pe serverul proxy invers orientat către net.
0
Răspunde
drapel us
Jason Hollowell
Tero, mulțumesc din nou pentru ajutor și răbdare. Simt că sunt aproape acolo. Am eliminat certificatele ssl de pe serverul rețelei locale, am trecut la deservirea site-ului pe http (80), am folosit informațiile actualizate pe care le-ați furnizat și am avut nevoie să adaug server_name pentru certbot pentru a identifica domeniul pentru care doream un certificat. Toate au funcționat bine, dar acum primesc o eroare de gateway 502 greșită când încerc să accesez domeniul. Îmi voi actualiza întrebarea pentru o formatare mai ușoară/mai clară pentru a arăta ce am acum.
0
Răspunde
drapel us
Tero Kilkanen
Vă rugăm să rețineți că atunci când serverul din amonte este peste `http`, trebuie să utilizați `proxy_pass http://192.168.11.4;`. Aveți `https://192.168.11.4` în configurația dvs.
0
Răspunde
drapel us
Jason Hollowell
Tero - mulțumesc încă o dată. Da, asta a fost o problemă. Eliminarea „s”-ului mă duce peste eroarea 502 și acum primesc o eroare „prea multe redirecționări”... care cred că este de la Apache pe mașina locală... va trebui să caut acum și să văd ce gresesc din partea aia.
0
Răspunde
drapel us
Jason Hollowell
Tero - Mulțumesc foarte mult pentru tot sprijinul și răbdarea dumneavoastră. Eroarea 502 a fost cauzată de unele setări legate de https rămase în fișierul serverului meu virtual de pe mașina Apache. Le-am trecut cu vederea complet în partea de jos a dosarului. Am eliminat totul și funcționează perfect. :-) Am nevoie să fac câteva ajustări minore în aplicația mea care rulează în spatele proxy-ului invers (proxy_client_headers), dar odată ce au fost făcute, totul funcționează ca un farmec. Mulțumesc din nou pentru ajutor. :-)
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.