Tillat en TLS-passthrough-tilkobling i NGINX sin stream-kontekst

NGINX kan avvise et TCP TLS-relay uten å avslutte TLS. Legg tillatelsesregelen i stream, ikke i en HTTP location, og kontroller hvilken peer-adresse som kommer.

Å videresende krypterte byte uten noen gang å holde sertifikatet er det et TLS-passthrough-relay gjør, og ordningen er både praktisk og litt forvirrende. Fordi ingenting dekrypteres, finnes det ingenting HTTP-formet å filtrere på, så den vanlige location-blokken og dens tilgangsregler har ingen verdi her. Avgjørelsen NGINX kan ta gjelder selve tilkoblingen: hvilken nettverkspeer som banket på, og om den peeren i det hele tatt skal videresendes.

Beslutningen hører hjemme i stream, ikke i HTTP

I stream-konteksten arbeider NGINX med TCP-økter. Den ser tilkoblingens peer-adresse og kan anvende ordnede allow- og deny-regler på den før noen byte når backend. Det er en fullstendig tilgangsbeslutning, og den krever ingen privat nøkkel, sertifikat eller HTTP-parsing.

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 radene erstatter aldri hverandre. Å kopiere et HTTP-tilgangsdirektiv til filen som nevner port 443 endrer ingenting, ettersom stream-serveren aldri leser http-konteksten.

Tillat tilkoblingen før du videresender den

Anta en eksisterende installasjon med stream- og stream-access-modulene tilgjengelige, VPN-klienter som holder kildeadresser i 10.90.0.0/24, og en backend på 192.168.50.20:443 som allerede leverer den tiltenkte HTTPS-identiteten.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Les dette som et fragment av en ny listener, ikke som en direkte erstatning for en fungerende konfigurasjon. Gå gjennom eksisterende listenere og includes først, fordi en andre listener på en port som allerede er bundet feiler ved reload, ikke ved forespørselstidspunktet.

Legg merke til hva som mangler: ingen listen ... ssl, ingen sertifikatdirektiv. NGINX videresender den krypterte strømmen, og backend avslutter TLS og presenterer sertifikatet klienten validerer. En klient som ikke består allowlisten får TCP-økten sin avvist, ikke en HTTP 403-side, og ethvert verktøy som forventer en statuskode vil rapportere noe ubrukelig.

Hva allowlisten dekker og ikke dekker

Hvis relayet allerede velger backends etter servernavn, kan ssl_preread og et map fortsette med den jobben, forutsatt at modulen er tilgjengelig. Navnet leveres fortsatt av klienten, og ingenting ved å presentere et navn beviser at klienten har blitt med i VPN-en.

Eksempelregelen dekker hele stream-listeneren. Det gjør den uegnet for ett enkelt inngangspunkt som betjener en blanding av offentlige nettsteder og nettsteder kun for VPN, der det ville være behov for et unntak per navn; separate listenere er vanligvis klarere enn en navneavhengig policy som ingen kan lese.

To flere hull fortjener å nevnes. Et prefiks samsvar sier ingenting om hvilket grensesnitt pakken kom inn på, og en HTTP-regel et annet sted kan ikke begrense denne listeneren. Begge er grunner til å holde inngangspolicyen på vertsnivå i bildet i stedet for å behandle én allow-linje som hele grensen. Skriv ned grensen som to kontroller som må stemme overens, slik at en endring i hver av dem blir gjennomgått.

Hvis adresse ser NGINX egentlig?

En lastbalanserer, en annen proxy eller source NAT kan sette en mellommann foran NGINX, så peeren den ser er ikke VPN-klientens indre adresse. Undersøk den virkelige veien før du velger et prefiks, fordi en allowliste skrevet for feil adresse enten slipper alle bak oversetteren inn eller ingen.

PROXY-protokollen og håndtering av ekte IP er legitime svar, og de må bare konfigureres for kompatible, eksplisitt betrodde avsendere. Begge mekanismene tror på det avsenderen sier, og det er nettopp derfor avsenderlisten må være kort. Tillit til en identitetsheader fra enhver internettklient gjør ikke kildeinformasjonen pålitelig igjen; det gjør en korrekt avvisning om til en forfalsket godkjenning.

Test begge utfallene før reload

Valider konfigurasjonen, gjør reload, og test deretter to ganger: en ny tillatt økt som må fungere, og en avvist som ikke skal. Behold vanlig backend-sertifikatvalidering i den tillatte testen, fordi et relay som kobler til men ikke kan validere backend har løst ett problem og skapt et annet.

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

Sjekk også ruten til backend og svaret separat. Å bestå allowlisten beviser bare at NGINX godtok økten; det kan ikke få en utilgjengelig backend til å svare, og det kan ikke reparere en returvei som manglet før du begynte.

Relaterte artikler