Dopustiti TLS passthrough vezu u NGINX stream kontekstu

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

Prosljeđivanje šifriranih bajtova bez ikakvog držanja certifikata je ono što radi TLS passthrough relej, a taj je raspored praktičan i pomalo zbunjujuć. Budući da se ništa ne dešifrira, 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 je mrežni partner pokucao i treba li ga uopće propustiti.

Odluka pripada streamu, ne HTTP-u

U stream kontekstu NGINX radi s TCP sesijama. Vidi adresu partnera veze i može na nju primijeniti uređena pravila allow i deny prije nego ijedan bajt stigne do backenda. To je potpuna odluka o prihvatu 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 retka nikada ne zamjenjuju jedan drugi. Kopiranje HTTP direktive pristupa u bilo koju datoteku koja spominje port 443 ne mijenja ništa, jer stream poslužitelj 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 reloadu, a ne u vrijeme zahtjeva.

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

Što allowlist pokriva, a što ne

Ako relej već bira backende po imenu poslužitelja, ssl_preread i map mogu nastaviti taj posao, pod uvjetom 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 točku koja poslužuje mješavinu javnih i samo VPN stranica, gdje bi bilo potrebno izuzeće po imenu; odvojeni listeneri obično su jasniji od politike ovisne o imenu koju nitko 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 razini hosta držite u slici, umjesto da jedan allow redak 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 zapravo vidi?

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

PROXY protokol i obrada stvarne IP adrese su legitimni odgovori i moraju se konfigurirati samo za kompatibilne, izričito pouzdane pošiljatelje. Oba mehanizma vjeruju onome što pošiljatelj kaže, i upravo zato popis pošiljatelja mora biti kratak. Vjerovanje identifikacijskom zaglavlju od bilo kojeg internetskog klijenta ne čini izvorne informacije ponovno pouzdanima; ono pretvara ispravno odbijanje u krivotvoreni prihvat.

Testirajte oba ishoda prije reloada

Provjerite konfiguraciju, napravite reload, zatim testirajte dvaput: novu dopuštenu sesiju koja mora raditi i odbijenu koja ne smije. Zadržite uobičajenu provjeru certifikata backenda 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 i rutu do backenda 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