TLS-passthrough-ühenduse lubamine NGINX-i stream-kontekstis

NGINX saab TCP TLS-relay tagasi lükata ilma TLS-i lõpetamata. Pane lubamisreegel stream-konteksti, mitte HTTP locationisse, ja kontrolli, milline peer-aadress saabub.

Krüpteeritud baitide edasisaatmine ilma sertifikaati kunagi hoidmata on TLS-passthrough-relay töö, ja see lahendus on mugav ning samal ajal veidi segane. Kuna midagi ei dekrüpteerita, pole olemas midagi HTTP-kujulist, mille järgi filtreerida, seega tavaline location-plokk ja selle juurdepääsureeglid ei aita siin. Otsus, mille NGINX saab teha, puudutab ühendust ennast: milline võrgu-peer koputas ja kas see peer üldse edasi saata.

Otsus kuulub stream-konteksti, mitte HTTP-sse

stream-kontekstis töötab NGINX TCP-sessioonidega. Ta näeb ühenduse peer-aadressi ja saab rakendada sellele järjestatud allow- ja deny-reegleid enne, kui ükski bait backendini jõuab. See on täielik vastuvõtuotsus ja see ei nõua privaatvõtit, sertifikaati ega HTTP-parsimist.

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

Need kolm rida ei asenda kunagi üksteist. HTTP juurdepääsudirektiivi kopeerimine faili, mis mainib porti 443, ei muuda midagi, sest stream-server ei loe kunagi http-konteksti.

Võta ühendus vastu enne selle edasisaatmist

Eeldage olemasolevat paigaldust, kus on saadaval moodulid stream ja stream-access, VPN-kliendid hoiavad lähteaadresse vahemikus 10.90.0.0/24 ja backend asub aadressil 192.168.50.20:443 ning teenindab juba kavandatud HTTPS-identiteeti.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lugege seda uue listeneri fragmendina, mitte töötava konfiguratsiooni otsese asendusena. Vaadake esmalt üle olemasolevad listenerid ja include-id, sest teine listener juba hõivatud pordil ebaõnnestub reload’i ajal, mitte päringu ajal.

Pange tähele, mis puudub: listen ... ssl puudub, sertifikaadidirektiiv puudub. NGINX saadab krüpteeritud voo edasi ning backend lõpetab TLS-i ja esitab sertifikaadi, mida klient valideerib. Klient, kes allowlisti ei läbi, saab oma TCP-sessiooni tagasilükkamise, mitte HTTP 403 lehe, ja iga tööriist, mis ootab olekukoodi, teatab midagi kasutut.

Mida allowlist katab ja mida mitte

Kui relay valib juba backendeid serverinime järgi, saavad ssl_preread ja map seda tööd jätkata, kui moodul on saadaval. Nime esitab endiselt klient ja miski nime esitamises ei tõesta, et klient on VPN-iga liitunud.

Näidisreegel katab kogu stream-listeneri. See muudab selle sobimatuks ühele sissepääsupunktile, mis teenindab avalike ja ainult VPN-i saitide segu, kus oleks vaja erandit iga nime kohta; eraldi listenerid on tavaliselt selgemad kui nimest sõltuv poliitika, mida keegi lugeda ei suuda.

Tasub nimetada veel kahte lünka. Prefiksi vastavus ei ütle midagi selle kohta, millise liidese kaudu pakett saabus, ja HTTP-reegel mujal ei saa seda listenerit piirata. Mõlemad on põhjused hoida hostitasandi sissepääsupoliitikat pildil, selle asemel et pidada üht allow-rida kogu piiriks. Kirjutage piir kahe kontrollina, mis peavad kokku langema, et mõlema muutmine läbiks ülevaatuse.

Kelle aadressi NGINX tegelikult näeb?

Koormusjaotur, teine proxy või source NAT võib panna NGINX-i ette vahendaja, seega peer, mida ta näeb, ei ole VPN-kliendi sisemine aadress. Uurige tegelikku teed enne prefiksi valimist, sest vale aadressi jaoks kirjutatud allowlist kas laseb kõik tõlkija taga läbi või mitte kedagi.

PROXY-protokoll ja tegeliku IP käsitlemine on õigustatud vastused ja neid tuleb seadistada ainult ühilduvate, selgelt usaldatud saatjate jaoks. Mõlemad mehhanismid usuvad seda, mida saatja ütleb, ja täpselt seetõttu peab saatjate nimekiri olema lühike. Identiteedipäise usaldamine ükskõik milliselt internetikliendilt ei muuda lähteinfot uuesti usaldusväärseks; see muudab õige keeldumise võltsitud vastuvõtuks.

Testige mõlemat tulemust enne reload’i

Valideerige konfiguratsioon, tehke reload ja seejärel testige kaks korda: uus lubatud sessioon, mis peab töötama, ja keelatud, mis ei tohi. Jätke lubatud testi tavaline backend-sertifikaadi valideerimine, sest relay, mis ühendub, kuid ei suuda backendit valideerida, on ühe probleemi lahendanud ja teise tekitanud.

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

Kontrollige ka backend-marsruuti ja vastust eraldi. Allowlisti läbimine tõestab ainult, et NGINX võttis sessiooni vastu; see ei saa panna kättesaamatut backendit vastama ega parandada tagasiteed, mis puudus enne, kui te alustasite.

Seotud artiklid