Puncte:0

Transmiteți certificate HTTPS de la serverele din aval prin proxy NGINX către client

drapel de

Am o flotă de computere Ubuntu edge care găzduiesc servere HMI web simple. Mulți se află în spatele IP-urilor dinamice unde redirecționarea portului nu este disponibilă.

Deci, pentru a le accesa fiecare folosește autossh pentru a crea un tunel invers într-un server proxy cloud central. Apoi pot accesa fiecare cu https://proxy.mydomain.com:6001, 6002 etc. Acest lucru funcționează.

Acum vreau să folosesc NGINX, astfel încât să nu fie nevoie să ne amintim numerele de port. Deci, fiecare unitate ar avea propriul subdomeniu: https://site1.mydomain.com, site2, etc. Toate subdomeniile ar indica serverul meu proxy. NGINX ar trebui apoi să se uite la subdomeniu și să transmită traficul https către portul de tunel invers corespunzător.

Configurația NGINX este afișată mai jos.

Problema mea în acest moment este că NGINX vrea să definesc un certificat SSL. Cu toate acestea, aș dori să folosesc certificatele deja instalate pe fiecare dintre computerele edge.

Deci, cum aș proceda pentru a transmite acele certificate prin proxy-ul NGINX către client?

Dacă acest lucru nu este posibil - care este cel mai bun mod de a defini unul sau certificate separate pe serverul proxy care pot fi utilizate pentru toate subdomeniile?

Server {
    asculta 443 ssl;
    nume_server site1.mydomain.com;
    Locație / {
        proxy_set_header Gazdă $gazdă;
        proxy_pass https://127.0.0.1:6001;
        proxy_ssl_server_name activat;
        proxy_redirect dezactivat;
    }
}

Server {
    asculta 443 ssl;
    nume_server site2.mydomain.com;
    Locație / {
        proxy_set_header Gazdă $gazdă;
        proxy_pass https://127.0.0.1:6002;
        proxy_ssl_server_name activat;
        proxy_redirect dezactivat;
    }
}

ACTUALIZAȚI Pentru cei curioși, am putut să folosesc proiectul „SNIProxy” în loc de NGINX și am rezolvat această problemă. Certificatele HTTPS au trecut fără probleme.

Puncte:0
drapel cn

Ați putea folosi un certificat cu wildcard *.mydomain.com pentru proxy.
Această cheie privată + certificat ar funcționa pentru orice subdomeniu.
Fie gratuit de la let's encrypt (certbot), fie plătit de la un CA, cum ar fi digicert.

djdomi avatar
drapel za
nu uitați să adăugați domain.tld ȘI *.domain.tld altfel certificatul dvs. nu are informații lipsă ;)
Puncte:0
drapel us

Puteți folosi curent modulul pentru a trece prin protocolul TLS așa cum este către clienți.

Eu nu am folosit această configurație, așa că s-ar putea să nu fie 100% exactă, dar ar trebui să arate principiile.

curent {
    asculta 443;
    ssl_preread on;
    proxy_connect_timeout 1s;
    proxy_timeout 3s;
    proxy_pass $amonte;
}

harta $ssl_preread_server_name $upstream {
    site1.example.com 127.0.0.1:6001;
    site2.example.com 127.0.0.2:6002;
    site-ul implicit1;
}

În curent bloc, activăm pre-citirea datelor protocolului SSL. Nginx extrage câmpul SNI în $ssl_preread_server_name variabil.

Folosim Hartă caracteristică pentru a converti numele serverului precitit în destinație. Apoi destinația este folosită ca curent modul proxy_pass destinaţie.

Aici nginx citește doar numele de gazdă pentru conexiunea SSL și apoi trimite proxy conexiunea TCP către destinația pentru acel nume de gazdă.

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.