Dopustiti TLS passthrough vezu u NGINX stream kontekstu

NGINX može odbiti TCP TLS relej bez prekidanja TLS-a. Stavite pravilo dopuštanja u stream, ne u HTTP location, i provjerite koja adresa partnera dolazi.

Prosljeđivanje šifrovanih bajtova bez ikakvog držanja certifikata je ono što radi TLS passthrough relej, a taj raspored je i praktičan i pomalo zbunjujuć. Pošto se ništa ne dešifruje, ne postoji ništa u obliku HTTP-a za filtriranje, pa uobičajeni location blok i njegova pravila pristupa ovdje nemaju koristi. Odluka koju NGINX može donijeti tiče se same veze: koji mrežni partner je pokucao i treba li ga uopšte propustiti.

Odluka pripada stream-u, ne HTTP-u

U stream kontekstu NGINX radi sa TCP sesijama. Vidi adresu partnera veze i može na nju primijeniti uređena pravila allow i deny prije nego ijedan bajt stigne do backend-a. To je potpuna odluka o prijemu i ne zahtijeva privatni ključ, certifikat ni HTTP parsiranje.

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

Ta tri reda nikada ne zamjenjuju jedan drugi. Kopiranje HTTP direktive pristupa u bilo koju datoteku koja spominje port 443 ne mijenja ništa, jer stream server nikada ne čita http kontekst.

Prihvatite vezu prije nego je propustite

Pretpostavite postojeću instalaciju s dostupnim modulima stream i stream-access, VPN klijente koji drže izvorne adrese u 10.90.0.0/24, i backend na 192.168.50.20:443 koji već poslužuje željeni HTTPS identitet.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Čitajte to kao fragment novog listenera, a ne kao izravnu zamjenu radne konfiguracije. Prvo pregledajte postojeće listenere i include, jer drugi listener na već zauzetom portu pada pri reload-u, a ne u vrijeme zahtjeva.

Primijetite šta nedostaje: nema listen ... ssl, nema direktive certifikata. NGINX prosljeđuje šifrovani tok, a backend prekida TLS i predstavlja certifikat koji klijent provjerava. Klijent koji ne prođe allowlist dobija odbijenu TCP sesiju, a ne HTTP 403 stranicu, i svaki alat koji očekuje statusni kod prijaviće nešto beskorisno.

Šta allowlist pokriva, a šta ne

Ako relej već bira backendove po imenu servera, ssl_preread i map mogu nastaviti taj posao, pod uslovom da je modul dostupan. Ime još uvijek daje klijent, i ništa u predstavljanju imena ne dokazuje da se klijent pridružio VPN-u.

Primjerno pravilo pokriva cijeli stream listener. To ga čini lošim za jednu ulaznu tačku koja opslužuje mješavinu javnih i VPN-only sajtova, gdje bi bilo potrebno izuzeće po imenu; odvojeni listeneri su obično jasniji od politike zavisne od imena koju niko ne može pročitati.

Vrijedi imenovati još dvije praznine. Podudaranje prefiksa ne govori ništa o tome kroz koje je sučelje paket stigao, a HTTP pravilo negdje drugdje ne može ograničiti ovaj listener. Oboje su razlozi da politiku ulaza na nivou hosta držite u slici, umjesto da jedan allow red smatrate cijelom granicom. Zapišite granicu kao dvije kontrole koje se moraju slagati, tako da svaka promjena bilo koje od njih bude pregledana.

Čiju adresu NGINX zaista vidi?

Balanser opterećenja, drugi proxy ili source NAT mogu postaviti posrednika ispred NGINX-a, pa partner koji se vidi nije unutrašnja adresa VPN klijenta. Ispitajte stvarnu putanju prije nego odaberete prefiks, jer allowlist napisan za pogrešnu adresu ili pušta sve iza prevodioca ili nikoga.

PROXY protokol i obrada stvarnog IP-a su legitimni odgovori i moraju se konfigurisati samo za kompatibilne, izričito pouzdane pošiljaoce. Oba mehanizma vjeruju onome što pošiljalac kaže, i upravo zato lista pošiljalaca mora biti kratka. Vjerovanje identitetskom zaglavlju od bilo kojeg internet klijenta ne čini izvorne informacije ponovo pouzdanim; ono pretvara ispravno odbijanje u krivotvoreni prijem.

Testirajte oba ishoda prije reload-a

Provjerite konfiguraciju, uradite reload, zatim testirajte dvaput: novu dopuštenu sesiju koja mora raditi i odbijenu koja ne smije. Zadržite normalnu provjeru certifikata backend-a u dopuštenom testu, jer relej koji se povezuje ali ne može provjeriti backend riješio je jedan problem i stvorio drugi.

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

Provjerite rutu do backend-a i odgovor odvojeno. Prolazak allowlista dokazuje samo da je NGINX prihvatio sesiju; ne može natjerati nedostupni backend da odgovori i ne može popraviti povratnu putanju koja je nedostajala prije nego što ste počeli.

Povezani članci