Tillad en TLS-passthrough-forbindelse i NGINX stream-kontekst

NGINX kan afvise et TCP TLS-relay uden at afslutte TLS. Læg tilladelsesreglen i stream, ikke i et HTTP location, og kontroller, hvilken peer-adresse der ankommer.

At videresende krypterede bytes uden nogensinde at holde certifikatet er, hvad et TLS-passthrough-relay gør, og ordningen er både bekvem og en smule forvirrende. Fordi intet dekrypteres, findes der intet HTTP-formet at filtrere på, så det sædvanlige location-blok og dets adgangsregler har ingen værdi her. Den beslutning, NGINX kan træffe, handler om selve forbindelsen: hvilken netværkspeer der bankede på, og om den peer overhovedet skal videresendes.

Beslutningen hører i stream, ikke i HTTP

I stream-konteksten arbejder NGINX med TCP-sessioner. Den ser forbindelsens peer-adresse og kan anvende ordnede allow- og deny-regler på den, før nogen bytes når backend. Det er en fuldstændig adgangsbeslutning, og den kræver ingen privat nøgle, intet certifikat og ingen HTTP-parsning.

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

De tre rækker erstatter aldrig hinanden. At kopiere en HTTP-adgangsdirektiv til den fil, der nævner port 443, ændrer intet, fordi stream-serveren aldrig læser http-konteksten.

Tillad forbindelsen, før du videresender den

Antag en eksisterende installation med stream- og stream-access-modulerne tilgængelige, VPN-klienter der holder kildeadresser i 10.90.0.0/24, og en backend på 192.168.50.20:443, der allerede leverer den tilsigtede HTTPS-identitet.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Læs det som et nyt listener-fragment, ikke som en direkte erstatning for en fungerende konfiguration. Gennemgå først eksisterende listenere og includes, fordi en anden listener på en port, der allerede er bundet, fejler ved reload og ikke på anmodningstidspunktet.

Læg mærke til, hvad der mangler: ingen listen ... ssl, ingen certifikatdirektiv. NGINX videresender den krypterede strøm, og backend afslutter TLS og præsenterer det certifikat, klienten validerer. En klient, der ikke består allowlisten, får sin TCP-session afvist, ikke en HTTP 403-side, og ethvert værktøj, der forventer en statuskode, rapporterer noget ubrugeligt.

Hvad allowlisten dækker, og hvad den ikke dækker

Hvis relayet allerede vælger backends efter servernavn, kan ssl_preread og et map fortsætte med det arbejde, forudsat at modulet er tilgængeligt. Navnet leveres stadig af klienten, og intet ved at præsentere et navn beviser, at klienten er med i VPN’en.

Eksempelreglen dækker hele stream-listeneren. Det gør den uegnet til et enkelt indgangspunkt, der betjener en blanding af offentlige websteder og websteder kun for VPN, hvor der ville være brug for en undtagelse pr. navn; separate listenere er normalt klarere end en navneafhængig politik, som ingen kan læse.

To yderligere huller er værd at nævne. Et præfiks-match siger intet om, hvilket interface pakken ankom på, og en HTTP-regel et andet sted kan ikke begrænse denne listener. Begge er grunde til at holde værtsniveauets ingress-politik i billedet i stedet for at behandle én allow-linje som hele grænsen. Skriv grænsen ned som to kontroller, der skal stemme overens, så en ændring i hver af dem bliver gennemgået.

Hvis adresse ser NGINX egentlig?

En load balancer, en anden proxy eller source NAT kan sætte en mellemled foran NGINX, så den peer, den ser, er ikke VPN-klientens indre adresse. Undersøg den rigtige vej, før du vælger et præfiks, fordi en allowliste skrevet til den forkerte adresse enten tillader alle bag oversætteren eller ingen.

PROXY-protokol og håndtering af rigtig IP er legitime svar, og de må kun konfigureres for kompatible, udtrykkeligt betroede afsendere. Begge mekanismer tror på, hvad afsenderen siger, og det er netop derfor, afsenderlisten skal være kort. Tillid til en identitetsheader fra enhver internetklient gør ikke kildeoplysningerne troværdige igen; den forvandler en korrekt afvisning til en forfalsket adgang.

Test begge udfald, før du reloader

Valider konfigurationen, reload, og test derefter to gange: en ny tilladt session, der skal virke, og en afvist, der ikke må. Behold normal backend-certifikatvalidering i den tilladte test, fordi et relay, der forbinder, men ikke kan validere backenden, har løst ét problem og skabt et andet.

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

Kontroller også backend-ruten og svaret separat. At bestå allowlisten beviser kun, at NGINX accepterede sessionen; det kan ikke få en utilgængelig backend til at svare, og det kan ikke reparere en returvej, der manglede, før du begyndte.

Relaterede artikler