Puncte:0

Serviciu multiplu cu diferite porturi cum configurați proxy nginx

drapel in

Am urmatoarea structura:

ip public <-> vm host <-> vms

Există două vms: vm1_proxy_nginx vm2_service_docker_vm (folosind porturile 9000-9005)

Service_VM este un server de bord care funcționează pe porturile expuse 9001, 9002 și 9005 pentru autentificare, autentificare și comunicarea de înregistrare a datelor între utilizatorii și vm.

Acum am redirecționat în nginx reverse proxy http și https la /9001 pentru autentificare.

Apoi am aflat că această configurație duce la probleme deoarece comunicarea înapoi nu este oferită (după conectarea cu succes, redirecționarea serverului către serviciul tablou de bord 9002)

https://ip.ip.ip.io:9002/?token=

Are cineva idee cum să rezolve această problemă fără a pierde problemele de securitate și ssl?

Știu că reimplementarea serviciului pentru a nu folosi porturi expuse astfel, dar am nevoie între timp de o soluție....

Puncte:0
drapel br

Cea mai ușoară modalitate de a rezolva acest lucru este să păstrați toate porturile standard și să creați doar 2 blocuri de server în configurația dvs., unul pentru fiecare port, acționând ca proxy invers, redirecționând tot traficul către portul țintă. De exemplu:

Server {
        asculta 9001 ssl http2;
        ssl_certificate *cale-spre-certificat*;
        ssl_certificate_key *patch-to-private-key;
        nume_server xyz.yourdomain.com;

              proxy_set_header Gazdă $gazdă;
              proxy_set_header X-Real-IP $adresă_la distanță;
              proxy_pass http://*ipofupstreamserver*:9001;
}

Server {
        asculta 9002 ssl http2;
        ssl_certificate *cale-spre-certificat*;
        ssl_certificate_key *patch-to-private-key;
        nume_server xyz.yourdomain.com;

              proxy_set_header Gazdă $gazdă;
              proxy_set_header X-Real-IP $adresă_la distanță;
              proxy_pass http://*ipofupstreamserver*:9002;
}

Server {
        asculta 9005 ssl http2;
        ssl_certificate *cale-spre-certificat*;
        ssl_certificate_key *patch-to-private-key;
        nume_server xyz.yourdomain.com;

              proxy_set_header Gazdă $gazdă;
              proxy_set_header X-Real-IP $adresă_la distanță;
              proxy_pass http://*ipofupstreamserver*:9005;
}

Poate fi necesar să vă adaptați dacă doriți să utilizați http sau https pentru comunicarea în amonte, desigur, sau puteți pune frontend-ul care va prezenta interfața de conectare pe un port standard 443 dacă ar trebui să fie public și există o mulțime de alte opțiuni pentru tweak, dar asta ar trebui să te facă să începi.

user3882511 avatar
drapel in
merci pentru ajutor. ascultă 9001 înseamnă că trebuie să deschid și acest port sau? ce se întâmplă dacă vreau să folosesc doar porturile implicite de intrare 80 și 443. Și folosesc rproxy pentru a vă conecta la porturile de serviciu interne 9001, 9002, 9005 Este posibil?
drapel br
@user3882511 bine dacă aplicația dvs. funcționează fără acele porturi, atunci da. Dacă necesită acele porturi, atunci nu. problema este că, dacă aplicația dvs. presupune că poate folosi acele porturi și cere browserului să facă o conexiune la acele porturi, dar acestea sunt blocate, atunci nu poate fi stabilită nicio conexiune... astfel că lucrurile probabil nu vor funcționa :)

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.