Tillate ei TLS-passthrough-tilkopling i NGINX stream-kontekst

NGINX kan avvise eit TCP TLS-relay utan å avslutte TLS. Legg tillatingsregelen i stream, ikkje i ein HTTP location, og kontroller kva peer-adresse som kjem.

Å senda vidare krypterte byte utan nokon gong å halde sertifikatet er det eit TLS-passthrough-relay gjer, og ordninga er både praktisk og litt forvirrande. Fordi ingenting vert dekryptert, finst det ingenting HTTP-forma å filtrere på, så den vanlege location-blokka og tilgangsreglane hennar har ingen verdi her. Avgjerda NGINX har til rådvelde gjeld sjølve tilkoplinga: kva nettverkspeer som banka på, og om den peeren i det heile skal sendast vidare.

Avgjerda høyrer heime i stream, ikkje i HTTP

I stream-konteksten arbeider NGINX med TCP-økter. Ho ser peer-adressa til tilkoplinga og kan bruke ordna allow- og deny-reglar på henne før nokon byte når backend. Det er ei fullstendig tilgangsavgjerd, og ho krev 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

Dei tre linjene erstattar aldri kvarandre. Å kopiere eit HTTP-tilgangsdirektiv til fila som nemner port 443 endrar ingenting, fordi stream-tenaren aldri les http-konteksten.

Tillat tilkoplinga før du sender henne vidare

Gå ut frå ei eksisterande installasjon med stream- og stream-access-modulane tilgjengelege, VPN-klientar som held kjeldeadresser i 10.90.0.0/24, og ein backend på 192.168.50.20:443 som alt 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 eit fragment av ein ny listener, ikkje som ein direkte erstatning for ein fungerande konfigurasjon. Gå gjennom eksisterande listenarar og includes først, fordi ein andre listener på ein port som alt er bunden feilar ved reload, ikkje ved førespurnadstidspunktet.

Legg merke til kva som manglar: ingen listen ... ssl, ingen sertifikatdirektiv. NGINX sender den krypterte straumen vidare, og backend avsluttar TLS og presenterer sertifikatet klienten validerer. Ein klient som ikkje klarar allowlista får TCP-økta si avvist, ikkje ei HTTP 403-side, og eitkvart verktøy som ventar ein statuskode vil rapportere noko ubrukeleg.

Kva allowlista dekkjer og ikkje dekkjer

Viss relayet alt vel backendar etter tenarnamn, kan ssl_preread og eit map halde fram med den jobben, så sant modulen er tilgjengeleg. Namnet vert framleis levert av klienten, og ingenting ved å presentere eit namn provar at klienten har blitt med i VPN-en.

Dømeregelen dekkjer heile stream-listeneren. Det gjer han ueigna for eitt einskilt inngangspunkt som tener ei blanding av offentlege nettstader og nettstader berre for VPN, der det ville trengjast eit unntak per namn; separate listenarar er vanlegvis klarare enn ein namneavhengig policy som ingen kan lese.

To fleire hol er verd å nemne. Eit prefiks samsvar seier ingenting om kva grensesnitt pakken kom inn på, og ein HTTP-regel ein annan stad kan ikkje avgrense denne listeneren. Begge er grunnar til å halde inngangspolicyen på vertsnivå i biletet i staden for å handsame éi allow-linje som heile grensa. Skriv ned grensa som to kontrollar som må stemme overeins, slik at ei endring i kvar av dei vert gjennomgått.

Kven si adresse ser NGINX eigentleg?

Ein lastbalansar, ein annan proxy eller source NAT kan setje ein mellommann framfor NGINX, så peeren ein ser er ikkje den indre adressa til VPN-klienten. Undersøk den verkelege vegen før du vel eit prefiks, fordi ei allowliste skriven for feil adresse antingen slepp alle bak omsetjaren inn eller ingen.

PROXY-protokollen og handsaming av ekte IP er legitime svar, og dei må berre konfigurerast for kompatible, eksplisitt betrudde avsendarar. Begge mekanismane trur på det avsendaren seier, og det er nettopp derfor avsendarlista må vere kort. Tillit til ein identitetsheader frå ein kvar internettklient gjer ikkje kjeldeinformasjonen påliteleg igjen; det gjer ei korrekt avvising om til ei forfalska godkjenning.

Test båe utfalla før reload

Valider konfigurasjonen, gjer reload, og test deretter to gonger: ei ny tillaten økt som må fungere, og ei avvist som ikkje skal. Hald vanleg backend-sertifikatvalidering i den tillatne testen, fordi eit relay som koplar til men ikkje kan validere backend har løyst eitt problem og skapt eit anna.

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

Kontroller også ruta til backend og svaret separat. Å klare allowlista provar berre at NGINX godtok økta; det kan ikkje få ein utilgjengeleg backend til å svare, og det kan ikkje reparere ein returveg som mangla før du byrja.

Relaterte artiklar