Laat ’n TLS-deurvoerverbinding in die NGINX-stream-konteks toe

Om versleutelde grepe deur te stuur sonder om ooit die sertifikaat te hou, is wat ’n TLS-deurvoer-aflos doen, en die reëling is gerieflik maar effens verwarrend. Aangesien niks ontsleutel word nie, bestaan daar niks HTTP-vormigs om op te filter nie, so die gewone location-blok en sy toegangsreëls het hier geen waarde nie. Die besluit wat NGINX kan neem, gaan oor die verbinding self: watter netwerkeweknie geklop het, en of daardie eweknie hoegenaamd deurgevoer moet word.

Die besluit hoort in stream, nie in HTTP nie

In die stream-konteks werk NGINX met TCP-sessies. Dit sien die eweknie-adres van die verbinding en kan geordende allow- en deny-reëls daarop toepas voordat enige grepe die backend bereik. Dit is ’n volledige toelatingsbesluit en dit vereis geen private sleutel, geen sertifikaat en geen HTTP-ontleding nie.

Daardie drie rye vervang mekaar nooit nie. Om ’n HTTP-toegangsrichtlijn in watter lêer ook al na poort 443 verwys, te kopieer, verander niks, want die stream-bediener lees nooit die http-konteks nie.

Laat die verbinding toe voordat jy dit deurvoer

Aanvaar ’n bestaande installasie met die stream- en stream-access-modules beskikbaar, VPN-kliënte wat bronadresse in 10.90.0.0/24 hou, en ’n backend by 192.168.50.20:443 wat reeds die beoogde HTTPS-identiteit bedien.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lees dit as ’n nuwe-luisteraar-fragment, nie as ’n direkte vervanging vir ’n werkende konfigurasie nie. Hersien eers bestaande luisteraars en includes, want ’n tweede luisteraar op ’n poort wat reeds gebind is, misluk by herlaai eerder as by versoektyd.

Let op wat ontbreek: geen listen ... ssl nie, geen sertifikaatrichtlijn nie. NGINX voer die versleutelde stroom deur, en die backend beëindig TLS en wys die sertifikaat wat die kliënt valideer. ’n Kliënt wat die toelatingslys misluk, kry sy TCP-sessie verwerp, nie ’n HTTP 403-bladsy nie, en enige hulpmiddel wat ’n statuskode verwag, sal iets onbehulpsaams rapporteer.

Wat die toelatingslys dek en nie dek nie

As die aflos reeds backends volgens bedienernaam kies, kan ssl_preread en ’n map daardie taak bly doen, mits die module beskikbaar is. Die naam word steeds deur die kliënt verskaf, en niks aan die verskaffing van ’n naam bewys dat die kliënt by die VPN aangesluit het nie.

Die voorbeeldreël dek die hele stream-luisteraar. Dit maak dit ’n swak pas vir een toegangspunt wat ’n mengsel van openbare en slegs-VPN-webwerwe bedien, waar ’n uitsondering per naam nodig sou wees; aparte luisteraars is gewoonlik duideliker as ’n naamafhanklike beleid wat niemand kan lees nie.

Twee verdere gapings is die moeite werd om te noem. ’n Voorvoegselpassing sê niks oor watter koppelvlak die pakket op aangekom het nie, en ’n HTTP-reël elders kan nie hierdie luisteraar beperk nie. Albei is redes om gasheervlak-ingangsbeleid in die prentjie te hou eerder as om een allow-lyn as die hele grens te beskou. Skryf die grens neer as twee kontroles wat moet ooreenstem, sodat ’n verandering aan enigeen hersien word.

Watter adres sien NGINX werklik?

’n Lasbalanseerder, nog ’n proxy of bron-NAT kan ’n tussenganger voor NGINX plaas, so die eweknie wat dit sien, is nie die VPN-kliënt se binne-adres nie. Ondersoek die werklike pad voordat jy ’n voorvoegsel kies, want ’n toelatingslys wat vir die verkeerde adres geskryf is, laat óf almal agter die vertaler toe óf niemand nie.

PROXY-protokol en regte-IP-hantering is wettige antwoorde, en hulle moet slegs vir versoenbare, uitdruklik vertroude senders opgestel word. Albei meganismes glo wat die sender sê, en dit is juis waarom die senderlys kort moet wees. Om ’n identiteitskop van enige internetkliënt te vertrou, maak broninligting nie weer betroubaar nie; dit verander ’n korrekte weiering in ’n vervalste aanvaarding.

Toets albei uitkomste voordat jy herlaai

Valideer die konfigurasie, herlaai, en toets dan twee keer: ’n nuwe toegelate sessie wat moet werk, en een wat geweier word en nie moet nie. Hou normale backend-sertifikaatverifikasie in die toegelate toets, want ’n aflos wat verbind maar die backend nie kan valideer nie, het een probleem opgelos en ’n ander geskep.

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

Kontroleer die backend-roete en die antwoord ook afsonderlik. Om die toelatingslys te slaag bewys net dat NGINX die sessie aanvaar het; dit kan nie ’n onbereikbare backend laat antwoord nie, en dit kan nie ’n terugpad herstel wat voor jou begin ontbreek het nie.