Dovoliti povezavo TLS passthrough v kontekstu stream v NGINX

NGINX lahko zavrne posredovanje TCP TLS, ne da bi končal TLS. Pravilo dovoljenja vstavite v stream, ne v HTTP location, in preverite, kateri naslov partnerja pride.

Posredovanje šifriranih bajtov, ne da bi kdaj imeli certifikat, je tisto, kar počne relay TLS passthrough, in ta ureditev je priročna in hkrati nekoliko zmedena. Ker se nič ne dešifrira, ni ničesar v obliki HTTP za filtriranje, zato običajni blok location in njegova pravila dostopa tukaj nimajo nobene vrednosti. Odločitev, ki jo ima NGINX, se nanaša na samo povezavo: kateri omrežni partner je potrkal in ali naj se sploh posreduje.

Odločitev spada v stream, ne v HTTP

V kontekstu stream NGINX dela s sejami TCP. Vidi naslov partnerja povezave in lahko nanj uporabi urejena pravila allow in deny, preden kateri koli bajt doseže backend. To je popolna odločitev o sprejemu in ne zahteva zasebnega ključa, certifikata ali razčlenjevanja HTTP.

MechanismWhat it decidesWhere it lives
stream allow/denyWhether this TCP peer is relayedstream server block
ssl_preread mapWhich backend a named connection goes tostream, with the preread module
HTTP location ruleWhether an HTTP request is servedhttp server block

Te tri vrstice se nikoli ne nadomeščajo. Kopiranje direktive dostopa HTTP v katero koli datoteko, ki omenja vrata 443, ne spremeni ničesar, ker strežnik stream nikoli ne bere konteksta http.

Sprejmite povezavo, preden jo posredujete

Predpostavite obstoječo namestitev z razpoložljivima moduloma stream in stream-access, odjemalci VPN, ki hranijo izvorne naslove v 10.90.0.0/24, in backend na 192.168.50.20:443, ki že streže predvideno identiteto HTTPS.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Berite to kot delček novega listenerja, ne kot neposredno zamenjavo delujoče konfiguracije. Najprej pregledjte obstoječe listenerje in include, ker drugi listener na že zasedenih vratih ne uspe pri reloadu, ne ob zahtevi.

Bodite pozorni, kaj manjka: nobenega listen ... ssl, nobene direktive certifikata. NGINX posreduje šifriran tok, backend pa konča TLS in predstavi certifikat, ki ga odjemalec preveri. Odjemalec, ki ne prestane allowlista, dobi zavrnjeno sejo TCP, ne strani HTTP 403, in vsako orodje, ki pričakuje kodo stanja, bo poročalo o nečem neuporabnem.

Kaj allowlist pokriva in kaj ne

Če relay že izbira backende po imenu strežnika, lahko ssl_preread in map to delo nadaljujeta, če je modul na voljo. Ime še vedno zagotavlja odjemalec in nič pri predstavitvi imena ne dokazuje, da se je odjemalec pridružil VPN.

Pravilo iz primera pokriva celoten listener stream. Zaradi tega je neprimerno za eno vstopno točko, ki streže mešanico javnih spletnih mest in spletnih mest samo za VPN, kjer bi bila potrebna izjema za vsako ime; ločeni listenerji so običajno jasnejši od politike, odvisne od imena, ki je nihče ne more prebrati.

Vredno je omeniti še dve vrzeli. Ujemanje predpone ne pove ničesar o tem, skozi kateri vmesnik je prišel paket, in pravilo HTTP drugje ne more omejiti tega listenerja. Oboje so razlogi, da politiko vstopa na ravni gostitelja ohranite v sliki, namesto da eno vrstico allow obravnavate kot celotno mejo. Zapišite mejo kot dva nadzora, ki se morata ujemati, da se vsaka sprememba katerega koli od njiju pregleda.

Čigav naslov NGINX dejansko vidi?

Razporejevalnik obremenitve, drug proxy ali source NAT lahko pred NGINX postavijo posrednika, zato opaženi partner ni notranji naslov odjemalca VPN. Pred izbiro predpone preglejte dejansko pot, ker allowlist, napisan za napačen naslov, bodisi spusti vse za prevajalnikom bodisi nikogar.

Protokol PROXY in obravnava pravega IP so legitimni odgovori in jih je treba konfigurirati le za združljive, izrecno zaupanja vredne pošiljatelje. Oba mehanizma verjameta temu, kar pravi pošiljatelj, in prav zato mora biti seznam pošiljateljev kratek. Zaupanje glavi identitete katerega koli internetnega odjemalca ne naredi izvornih informacij znova zanesljivih; spremeni pravilno zavrnitev v ponarejen sprejem.

Preizkusite oba izida pred reloadom

Preverite konfiguracijo, izvedite reload in nato preizkusite dvakrat: novo dovoljeno sejo, ki mora delovati, in zavrnjeno, ki ne sme. V dovoljenem testu ohranite običajno preverjanje certifikata backend, ker je relay, ki se poveže, a ne more preveriti backenda, rešil en problem in ustvaril drugega.

nginx -t
ss -tnp | grep ':443'

Preverite tudi pot do backenda in odgovor ločeno. Prehod skozi allowlist dokazuje le, da je NGINX sejo sprejel; ne more prisiliti nedosegljivega backenda, da odgovori, in ne more popraviti povratne poti, ki je manjkala, preden ste začeli.

Sorodni članki