In TLS-passthrough-ferbining talitte yn ’e NGINX stream-kontekst

NGINX kin in TCP TLS-relay wegerje sûnder TLS te beëinigjen. Set de tastienregel yn stream, net yn in HTTP location, en kontrolearje hokker peer-adres oankomt.

Fersifere bytes trochjaan sûnder ea it sertifikaat te hâlden is wat in TLS-passthrough-relay docht, en de opstelling is handich en tagelyk wat ferwarrend. Om’t neat ûntsifere wurdt, is der neat fan HTTP-foarm om op te filterjen, dus it gewoane location-blok en syn tagongsregels hawwe hjir gjin nut. De beslissing dy’t NGINX hat, giet oer de ferbining sels: hokker netwurkpeer oanbuorde, en oft dy peer wol trochjûn wurde moat.

De beslissing heart yn stream, net yn HTTP

Yn ’e stream-kontekst wurket NGINX mei TCP-sesjes. It sjocht it peer-adres fan ’e ferbining en kin dêr oardere allow- en deny-regels op tapasse foardat ien byte it backend berikt. Dat is in folsleine tastimmingbeslissing, en dy freget gjin privekaai, sertifikaat of HTTP-analyse.

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

Dy trije rigen ferfange inoar nea. In HTTP-tagongsdirektive kopiearje yn it bestân dat poarte 443 neamt feroaret neat, want de stream-tsjinner lêst nea de http-kontekst.

Talit de ferbining foardat jo har trochjaan

Nim in besteande ynstallaasje oan mei de modules stream en stream-access beskikber, VPN-klanten dy’t boarne-adressen yn 10.90.0.0/24 hâlde, en in backend op 192.168.50.20:443 dy’t al de bedoelde HTTPS-identiteit tsjinnet.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lês dit as in fragmint fan in nije listener, net as in direkte ferfanging fan in wurkjende konfiguraasje. Besjoch earst de besteande listeners en include, want in twadde listener op in poarte dy’t al beset is, falt by reload, net op it momint fan it fersyk.

Merk op wat der mist: gjin listen ... ssl, gjin sertifikaatdirektive. NGINX jout de fersifere stream troch, en it backend beëiniget TLS en presintearret it sertifikaat dat de klant falidearret. In klant dy’t de allowlist net hellet, kriget syn TCP-sesje wegere, net in HTTP 403-side, en elk ark dat in statuskoade ferwachtet, meldt wat nutteleas.

Wat de allowlist dekt en wat net

As de relay al backends kiest op tsjinnernamme, kinne ssl_preread en in map dat wurk dwaan bliuwe, mits de module beskikber is. De namme wurdt noch altyd troch de klant levere, en neat oan it presintearjen fan in namme bewiist dat de klant by de VPN kaam is.

De foarbyldregel dekt de hiele stream-listener. Dat makket him ûngeskikt foar ien yngongspunt dat in mingsel fan iepenbiere en allinnich-VPN-sites tsjinnet, dêr’t in útsûndering per namme nedich wêze soe; aparte listeners binne meastentiids dúdliker as in fan namme ôfhinklik belied dat nimmen lêze kin.

Twa oare gatten binne it neamen wurdich. In prefix-oerienkomst seit neat oer hokker ynterface it pakket oankaam, en in HTTP-regel earne oars kin dizze listener net beheine. Beide binne redenen om it yngongsbelied op hostnivo yn byld te hâlden ynstee fan ien allow-rige as de hiele grins te behanneljen. Skriuw de grins del as twa kontrôles dy’t oerienkomme moatte, sadat in feroaring yn ien fan beide neisjoen wurdt.

Hokker adres sjocht NGINX eins?

In loadbalancer, in oare proxy of source NAT kin in tuskenpersoan foar NGINX sette, dus de peer dy’t er sjocht is net it ynderlike adres fan ’e VPN-klant. Undersykje it echte paad foardat jo in prefix kieze, want in allowlist skreaun foar it ferkearde adres lit of alle minsken efter de oersetter ta of nimmen.

It PROXY-protokol en behanneling fan echte IP binne legitime antwurden, en se moatte allinnich konfigurearre wurde foar kompatibele, eksplisyt fertroude stjoerders. Beide meganismen leauwe wat de stjoerder seit, en dêrom moat de stjoerderslist koart wêze. Fertrouwen op in identiteitskop fan hokker ynternetklant dan ek makket de boarney nfollmaasje net wer betrouber; it ferwikselet in korrekte wegering yn in ferfalske tastimming.

Test beide útkomsten foardat jo reload

Falidearje de konfiguraasje, reload, en test dan twa kear: in nije tastiene sesje dy’t wurkje moat, en in wegere dy’t net moat. Hâld de gewoane backend-sertifikaatferifikaasje yn ’e tastiene test, want in relay dy’t ferbynt mar it backend net falidearje kin, hat ien probleem oplost en in oar makke.

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

Kontrolearje ek de backend-rûte en it antwurd apart. De allowlist helje bewiist allinnich dat NGINX de sesje akseptearre hat; it kin in net berikber backend net antwurdzje litte, en it kin in weromwei net reparearje dy’t miste foardat jo begûnen.

Relatearre artikelen