Puncte:0

NGINX opensource: asigurați comunicarea criptată între echilibrator și noduri

drapel tr

Am configurat un echilibrator de încărcare care trebuie să comunice cu celelalte noduri folosind TLS. Acest lucru este important, deoarece nodurile back-end nu sunt într-o rețea privată. Configurația este cea de mai jos.

Rezultatul este că Nginx revine 502 Bad Gateway, iar Nginx pare să nu poată redirecționa către domeniile mele. În plus, din moment ce folosesc sursa deschisa versiunea, I nu poti folosește rezolva cuvânt cheie în configurația amonte. Cum pot schimba această configurație pentru a avea Nginx să cripteze datele între example.com -> backendX.example.com?

NOTĂ: dacă folosesc IP-uri în loc de adrese URL în blocul din amonte, echilibrarea încărcăturii funcționează, dar nu cred că este criptată

EROARE:

*3 eroare de verificare a certificatului SSL în amonte: (2: nu se poate obține certificatul emitentului) în timp ce se face legătura SSL către amonte, client: 0.0.0.0, server: lb.example.com

Rezultat al openssl s_client -connect backend1.example.com:

Lanț de certificate
 0 s:CN = backend1.example.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
în amonte example.com{
   minimum_conn;
   server backend1.example.com;
   server backend2.example.com;
}

Server {

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

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

                proxy_ssl_trusted_certificate /etc/letsencrypt/.../chain.pem;
                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

}

#### NGINX -T
utilizator www-date;
worker_proceses auto;
pid /run/nginx.pid;
includ /etc/nginx/modules-enabled/*.conf;

evenimente {
    conexiuni_muncitor 768;
    # multi_accept on;
}

http {

    ##
    # Setări de bază
    ##

    sendfile activat;
    tcp_nopush activat;
    tcp_nodelay activat;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;
    resolver 8.8.8.8 8.8.4.4 valid=30s;
    includ /etc/nginx/mime.types;
    aplicație de tip_default/octet-stream;

    ##
    # Setări SSL
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Eliminarea SSLv3, ref: POODLE
    ssl_prefer_server_ciphers activat;

    ##
    # Setări de înregistrare
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Setări Gzip
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied orice;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Configurații gazdă virtuală
    ##

    includ /etc/nginx/conf.d/*.conf;
    includ /etc/nginx/sites-enabled/*;
}

în amonte example.com{
   minimum_conn;
   server backend1.example.com;
   server backend2.example.com;
}

Server {

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

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

                proxy_ssl_trusted_certificate /etc/letsencrypt/.../chain.pem;
                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

}

Server {
    dacă ($gazdă = lb.example.com) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot


    asculta 80 default_server;
    asculta [::]:80 default_server;

    nume_server lb.example.com;
    întoarce 404; # gestionat de Certbot


}

# fișier de configurare /etc/letsencrypt/options-ssl-nginx.conf:
# Acest fișier conține parametri importanți de securitate. Dacă modificați acest fișier
# manual, Certbot nu va putea oferi automat securitate viitoare
# actualizări. În schimb, Certbot va imprima și va înregistra un mesaj de eroare cu o cale către
# fișierul actualizat la care va trebui să vă referiți atunci când actualizați manual
# acest fișier.

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers dezactivat;

ssl_ciphers „ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHACH3840:-DHACH3820:ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA";

nginx -t nginx: sintaxa fișierului de configurare /etc/nginx/nginx.conf este ok nginx: fișierul de configurare /etc/nginx/nginx.conf testul a reușit

djdomi avatar
drapel za
de ce folosești https și un port pentru upstream? un port este necesar doar în cazul în care nu aveți niciun port standard utilizat
AndreaCostanzo1 avatar
drapel tr
@djdomi Am încercat și eu fără a specifica porturile. A fost o încercare pe care am făcut-o pentru a mă asigura că nu asta era problema
djdomi avatar
drapel za
ambele backend-uri pot fi rezolvate?
AndreaCostanzo1 avatar
drapel tr
@djdomi Da, ambele sunt accesibile cu navigarea normală folosind adresa lor URL
AndreaCostanzo1 avatar
drapel tr
@djdomi Am reparat exemplul. Oricum, domeniul folosit de DNS-ul meu și domeniul folosit de celelalte noduri sunt toate diferite
djdomi avatar
drapel za
Vă rugăm să împărtășiți ieșirea lui nginx -t și apoi nginx -T fiecărui server pentru că, IMHO, partea ssl cert arată ciudat [uitați aici ca exemplu] (https://www.digitalocean.com/community/tutorials/how-to- set-up-nginx-load-balancing-with-ssl-termination)
AndreaCostanzo1 avatar
drapel tr
@djdomi Adăugat mai jos. Celelalte noduri back-end sunt servere preexistente pe apache pe care le-am folosit de mult timp. Încercam doar să folosesc nginx ca echilibrator de încărcare pentru a-l pune între ele. Dacă elimin URL-urile și folosesc IP-uri în amonte, totul funcționează bine, dar problema utilizării IP-urilor este că nu știu dacă comunicarea este criptată
Michael Hampton avatar
drapel cz
Trebuie să fi specificat un `resolver`, dar nu văd unul nicăieri. Conform [docs](https://nginx.org/r/resolver), acestea trebuie să meargă în blocuri `http`, `server` sau `location`.
AndreaCostanzo1 avatar
drapel tr
Există (în setările mele http)! Dar tot nu merge
Michael Hampton avatar
drapel cz
OK, văd acum. Am căutat intrările dvs. error_log, dar nu le găsesc în postarea dvs. Vă rugăm să încercați să faceți o altă solicitare și apoi să postați noile intrări error_log.
AndreaCostanzo1 avatar
drapel tr
@MichaelHampton a aflat problema, dar nu cum să o rezolv: în timpul strângerii de mână SSL, nu trimit certificat de încredere CA. Cum o pot repara? EROARE: *3 eroare de verificare a certificatului SSL în amonte: (2: nu se poate obține certificatul emitentului) în timp ce SSL handshaking la amonte, client: 0.0.0.0, server: lb.example.com,
AndreaCostanzo1 avatar
drapel tr
@MichaelHampton Am schimbat certificatul CA de încredere cu /etc/ssl/certs/ca-certificates.crt; iar acum eroarea este *1 certificatul SSL în amonte nu se potrivește cu „nume-amonte” în timp ce handshaking SSL la amonte

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.