Eng TLS-Passthrough-Verbindung am NGINX-Stream-Kontext erlaaben

NGINX kann en TCP-TLS-Relay ofleenen, ouni TLS ze beenden. Setzt d’Erlabnesregel an stream, net an engem HTTP-Location, a kontrolléiert, wéi eng Peer-Adress ukommt.

Verschlësselt Bytes weiderzeschécken, ouni jee den Zertifikat ze halen, dat ass wat en TLS-Passthrough-Relay mécht, an d’Anuerdnung ass bequem a gläichzäiteg e bësse verwierrend. Well näischt dechiffréiert gëtt, gëtt et näischt a Form vun HTTP fir ze filteren, dofir hunn de gewéinleche Location-Block an seng Zougrëffsregelen hei kee Wäert. D’Entscheedung, déi NGINX huet, betrëfft d’Verbindung selwer: wéi en Netzwierk-Peer ugeklappt huet, an ob dee Peer iwwerhaapt weidergeleet soll ginn.

D’Entscheedung gehéiert an stream, net an HTTP

Am stream-Kontext schafft NGINX mat TCP-Sessiounen. Et gesäit d’Peer-Adress vun der Verbindung a kann der Rei no allow- an deny-Regelen drop uwenden, ier iergendee Byte de Backend erreecht. Dat ass eng komplett Zoulossungsentscheedung, an et brauch kee private Schlëssel, keen Zertifikat an keng 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

Déi dräi Zeile ersetzen sech ni géigesäiteg. Eng HTTP-Zougrëffsdirektiv an d’Datei ze kopéieren, déi de Port 443 ernimmt, ännert näischt, well de Stream-Server den http-Kontext ni liest.

Loosst d’Verbindung zou, ier Dir se weiderleet

Huelt un, et gëtt eng bestehend Installatioun mat de Modulen stream a stream-access, VPN-Clienten, déi Quelladressen an 10.90.0.0/24 halen, an e Backend op 192.168.50.20:443, dee schonn déi virgesinn HTTPS-Identitéit ubitt.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Liest dat als Fragment vun engem neien Listener, net als direkten Ersatz vun enger funktionéierender Konfiguratioun. Kuckt d’éischt déi existent Listeneren an Include un, well en zweeten Listener op engem Port, dee schonn occupéiert ass, beim Reload feelt, net bei der Ufro.

Mierkt wat feelt: keen listen ... ssl, keng Zertifikatsdirektiv. NGINX leet de verschlësselte Stroum weider, an de Backend beendet TLS a presentéiert den Zertifikat, deen de Client validéiert. E Client, deen d’Allowlist net passéiert, kritt seng TCP-Sessioun ofgeleent, net eng HTTP-403-Säit, an all Instrument, dat e Statuscode erwaart, mellt eppes Onnëtzles.

Wat d’Allowlist deckt an wat net

Wann de Relay schonn Backends no Servernumm auswielt, kënnen ssl_preread an eng Map déi Aarbecht weider maachen, wann de Modul verfügbar ass. Den Numm gëtt nach ëmmer vum Client geliwwert, an näischt drun, en Numm ze presentéieren, beweist, datt de Client an de VPN agetrueden ass.

D’Beispillregel deckt de ganzen Stream-Listener. Dat mécht se ongëeegent fir een eenzegen Agang, dee seng Mëschung aus ëffentlechen an nëmmen-VPN-Säiten zerwéiert, wou eng Ausnam pro Numm néideg wier; getrennt Listeneren sinn normalerweis méi kloer wéi eng nummofhängeg Politik, déi keen liesen kann.

Zwou weider Lücken ass et wäert ze nennen. Eng Prefix-Iwwereneestëmmung seet näischt doriwwer, iwwer wéi eng Interface de Pak ukomm ass, an eng HTTP-Regel soss engem kann dësen Listener net aschränken. Béid sinn Grënn, d’Ingress-Politik op Host-Niveau am Bild ze halen, amplaz eng allow-Zeil als déi ganz Grenz ze behandelen. Schreift d’Grenz als zwou Kontrollen, déi mussen iwwereneestëmmen, sou datt eng Ännerung un enger vun hinnen iwwerpréift gëtt.

Wiem seng Adress gesäit NGINX tatsächlech?

En Loadbalancer, en anere Proxy oder Source-NAT kann en Tëschemann virun NGINX setzen, dofir ass de Peer, deen een gesäit, net d’intern Adress vum VPN-Client. Ënnersicht de richtege Wee, ier Dir e Prefix auswielt, well eng Allowlist, déi fir déi falsch Adress geschriwwe gouf, entweder jiddereen hannert dem Iwwersetzer erlaabt oder keen.

De PROXY-Protokoll an d’Behandlung vun der richteger IP si legitim Äntwerten, a si däerfen nëmme fir kompatibel, ausdrécklech vertraut Sender konfiguréiert ginn. Béid Mechanismen gleewen, wat de Sender seet, an dat ass genee de Grond, firwat d’Senderlëscht kuerz muss sinn. Engem Identitéitskapp vun engem Internet-Client ze vertrauen mécht d’Quellinformatioun net erëm vertrauenswierdeg; et verwandelt eng richteg Oflehnung an eng gefälscht Unerkennung.

Test béid Resultater virum Reload

Validéiert d’Konfiguratioun, maacht e Reload, a test dann zweemol: eng nei erlaabt Sessioun, déi muss funktionéieren, an eng ofgeleent, déi net däerf. Halt déi normal Backend-Zertifikatspréifung am erlaabten Test, well en Relay, deen sech verbënnt awer de Backend net validéiere kann, ee Problem geléist an en anert geschaf huet.

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

Kuckt och de Backend-Wee an d’Äntwert getrennt. D’Allowlist ze passéieren beweist just, datt NGINX d’Sessioun ugeholl huet; et kann en onerreechbare Backend net äntwerten, an et kann en Zeréckwee net reparéieren, deen virum Ufank gefeelt huet.

Ähnlech Artikelen