Lejo një lidhje TLS passthrough në kontekstin stream të NGINX
NGINX mund të refuzojë një relay TCP TLS pa përfunduar TLS. Vendos rregullin e lejes në stream, jo në një location HTTP, dhe kontrollo cila adresë peer arrin.
Përcjellja e bajtëve të kriptuar pa mbajtur kurrë certifikatën është ajo që bën një relay TLS passthrough, dhe kjo skemë është e përshtatshme dhe njëkohësisht pak e ngatërruar. Meqenëse asgjë nuk dekriptohet, nuk ekziston asgjë në formë HTTP për të filtruar, kështu që blloku i zakonshëm location dhe rregullat e tij të aksesit nuk kanë asnjë vlerë këtu. Vendimi që ka NGINX ka të bëjë me vetë lidhjen: cili peer i rrjetit trokiti dhe nëse ai peer duhet përcjellë fare.
Vendimi i përket stream, jo HTTP
Në kontekstin stream NGINX punon me sesione TCP. Ai sheh adresën peer të lidhjes dhe mund të zbatojë mbi të rregulla allow dhe deny të renditura përpara se ndonjë bajt të arrijë backendin. Ky është një vendim i plotë pranimi dhe nuk kërkon çelës privat, certifikatë ose analizë HTTP.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
Ato tre rreshta nuk zëvendësojnë kurrë njëri-tjetrin. Kopjimi i një direktive aksesi HTTP në çdo skedar që përmend portën 443 nuk ndryshon asgjë, sepse serveri stream nuk lexon kurrë kontekstin http.
Prano lidhjen përpara se ta përcjellësh
Supozo një instalim ekzistues me modulet stream dhe stream-access të disponueshme, klientë VPN që mbajnë adresa burimi në 10.90.0.0/24, dhe një backend në 192.168.50.20:443 që tashmë ofron identitetin HTTPS të synuar.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}Lexoje këtë si fragment të një listeneri të ri, jo si zëvendësim të drejtpërdrejtë të një konfigurimi që funksionon. Shqyrto fillimisht listenerët dhe include ekzistues, sepse një listener i dytë në një portë tashmë të zënë dështon në reload, jo në momentin e kërkesës.
Vër re çfarë mungon: asnjë listen ... ssl, asnjë direktivë certifikate. NGINX përcjell rrjedhën e kriptuar, dhe backend-i përfundon TLS dhe paraqet certifikatën që klienti vërteton. Një klient që nuk kalon allowlist-in merr sesionin TCP të refuzuar, jo një faqe HTTP 403, dhe çdo mjet që pret një kod statusi do të raportojë diçka të pavlerë.
Çfarë mbulon allowlist-i dhe çfarë jo
Nëse relay-i tashmë zgjedh backend-et sipas emrit të serverit, ssl_preread dhe një map mund të vazhdojnë atë punë, me kusht që moduli të jetë i disponueshëm. Emri vazhdon të jepet nga klienti, dhe asgjë në paraqitjen e një emri nuk provon se klienti iu bashkua VPN-së.
Rregulli i shembullit mbulon të gjithë listener-in stream. Kjo e bën atë të papërshtatshëm për një pikë të vetme hyrjeje që shërben një përzierje faqesh publike dhe faqesh vetëm për VPN, ku do të nevojitej një përjashtim për çdo emër; listenerët e veçantë janë zakonisht më të qartë sesa një politikë e varur nga emri që askush nuk mund ta lexojë.
Vlen të përmenden edhe dy boshllëqe të tjera. Përputhja e prefiksit nuk thotë asgjë për atë se nëpër cilin ndërfaqe erdhi paketa, dhe një rregull HTTP diku tjetër nuk mund ta kufizojë këtë listener. Të dyja janë arsye për ta mbajtur politikën e hyrjes në nivel hosti në pamje, në vend që një rresht allow të konsiderohet e gjithë kufiri. Shkruaje kufirin si dy kontrolle që duhet të pajtohen, në mënyrë që çdo ndryshim në cilindo prej tyre të rishikohet.
Adresën e kujt e sheh NGINX në të vërtetë?
Një balancues ngarkese, një proxy tjetër ose source NAT mund të vendosin një ndërmjetës përpara NGINX, kështu që peer-i i vëzhguar nuk është adresa e brendshme e klientit VPN. Inspekto shtegun e vërtetë përpara se të zgjedhësh një prefiks, sepse një allowlist i shkruar për adresën e gabuar ose pranon të gjithë pas përkthyesit ose askënd.
Protokolli PROXY dhe trajtimi i IP-së reale janë përgjigje legjitime, dhe duhet të konfigurohen vetëm për dërgues të përputhshëm dhe shprehimisht të besuar. Të dyja mekanizmat besojnë atë që thotë dërguesi, dhe pikërisht për këtë lista e dërguesve duhet të jetë e shkurtër. Besimi te një kokë identiteti nga çdo klient interneti nuk i bën përsëri të besueshme informacionet e burimit; e kthen një refuzim të saktë në një pranim të falsifikuar.
Testo të dyja rezultatet përpara reload
Vërteto konfigurimin, bëj reload, pastaj testo dy herë: një sesion i ri i lejuar që duhet të funksionojë, dhe një i refuzuar që nuk duhet. Mbaj verifikimin normal të certifikatës së backend-it në testin e lejuar, sepse një relay që lidhet por nuk mund të vërtetojë backend-in ka zgjidhur një problem dhe ka krijuar një tjetër.
nginx -t
ss -tnp | grep ':443'Kontrollo veçmas edhe shtegun drejt backend-it dhe përgjigjen. Kalimi i allowlist-it provon vetëm se NGINX e pranoi sesionin; nuk mund të detyrojë një backend të paarritshëm të përgjigjet dhe nuk mund të riparojë një shteg kthimi që mungonte përpara se të filloje.