Puncte:4

Echilibrare de încărcare NGINX: nume ssl în amonte

drapel tr

Am următoarea configurație Nginx pentru a echilibra sarcina între diferite noduri. Totuși, când încerc să redirecționez traficul pe care îl obțin 502 Bad Gateway.

Citind jurnalul de erori, am aflat că problema este legată de faptul că echilibratorul meu de încărcare Nginx încearcă să verifice valabilitatea certificatului X509 NU pentru diferitele noduri (backend1.example.com, backend2.example.com), ci pentru numele amonte backend.example.com (fara numarul), ceea ce duce la eroarea prezentată mai jos.

Cum îi pot spune lui nginx să folosească numele de gazdă al nodului redirecționat, în locul celui din amonte?

Jurnalul erorilor:

Certificatul SSL în amonte nu se potrivește cu „backend.example.com” în timp ce handshaking SSL în amonte...

CONFIGURARE:

în amonte backend.example.com {
   minimum_conn;
   server backend1.example.com:443
   server backend2.example.com:443
}
Server {

        asculta [::]:443 ssl ipv6only=on;
        asculta 443 ssl;
        nume_server example.com;

        Locație / {
                proxy_pass https://backend.example.com;

                proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
                proxy_ssl_session_reuse activat;
                proxy_ssl_verify on;
                proxy_ssl_verify_depth 2;
                proxy_set_header Gazdă $gazdă;
        }
    ssl_certificate /etc/letsencrypt/.../fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/.../privkey.pem; # gestionat de Certbot
    includ /etc/letsencrypt/options-ssl-nginx.conf; # gestionat de Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # gestionat de Certbot

}
Puncte:3
drapel in

Directiva ngx_http_proxy_module de care aveți nevoie este proxy_ssl_name

Puteți remedia această problemă în mai multe moduri:

  1. Încercați să o setați proxy_ssl_name $proxy_host;

  2. Folosiți certificatul ssl wildcard.

  3. Dacă se află în rețeaua internă, utilizați conexiunea http pentru upstream fără criptare dublă în exces și permiteți conectarea http pe partea amonte numai de la serverul proxy invers

  4. Plasați același certificat în amonte pe fiecare nod și setați-l pentru un nume așteptat proxy_ssl_name backend.example.com;

AndreaCostanzo1 avatar
drapel tr
1. nu funcționează deoarece setează `backend.example.com` 3. rețeaua nu este privată, acesta este motivul principal al criptării între nodurile lb și back-end. Puteți explica cum să faceți față certificatelor wildcard? (Trebuie să generez unul și apoi să îl copiez pe fiecare nod back-end. Se poate face direct prin certbot?)
drapel in
încercați să redenumiți backend-ul în amonte de la numele FQDN la doar „backend”, de exemplu `proxy_ssl_name $proxy_host; backend proxy_pass; proxy_ssl activat; proxy_ssl_verify pe;`
drapel in
da, puteți emite un certificat wild card direct cu certbot, dar cu validare suplimentară, de exemplu cu cloud flare dns dacă îl utilizați, încercați acest [articol](https://idolsgate.com/blog/wildcard-SSL-certificate-with- letsencrypt-on-Centos-7/) funcționează pentru mine
AndreaCostanzo1 avatar
drapel tr
redenumirea nu funcționează. Cred că singura soluție disponibilă rămâne utilizarea unui certificat SSL partajat
Puncte:1
drapel jp

Conform nginx dezvoltatorilor trebuie să partajați același certificat TLS între toate serverele backend. Consultați următorul raport de eroare https://trac.nginx.org/nginx/ticket/1307#comment:5

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.