Salli TLS-läpivientiyhteyden NGINXin stream-kontekstissa
NGINX voi hylätä TCP TLS -välityksen lopettamatta TLS:ää. Laita sallintasääntö streamiin, ei HTTP-locationiin, ja tarkista, mikä vertaisosoite saapuu.
Salattujen tavujen välittäminen ilman, että sertifikaattia koskaan pidetään, on TLS-läpivientireleen tehtävä, ja järjestely on kätevä ja samalla hieman hämmentävä. Koska mitään ei pureta, mitään HTTP:n muotoista ei ole suodatettavaksi, joten tavallinen location-lohko ja sen käyttösäännöt eivät auta tässä. Päätös, jonka NGINX voi tehdä, koskee itse yhteyttä: mikä verkon vertainen koputti ja pitäisikö se ylipäätään välittää.
Päätös kuuluu streamiin, ei HTTP:hen
stream-kontekstissa NGINX työskentelee TCP-istuntojen kanssa. Se näkee yhteyden vertaisosoitteen ja voi soveltaa siihen järjestettyjä allow- ja deny-sääntöjä ennen kuin yksikään tavu saavuttaa backendin. Se on täydellinen hyväksymispäätös, eikä se vaadi yksityistä avainta, sertifikaattia tai HTTP-jäsennystä.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
Nuo kolme riviä eivät koskaan korvaa toisiaan. HTTP-käyttödirektiivin kopioiminen tiedostoon, joka mainitsee portin 443, ei muuta mitään, koska stream-palvelin ei koskaan lue http-kontekstia.
Hyväksy yhteys ennen sen välittämistä
Oletetaan olemassa oleva asennus, jossa stream- ja stream-access-moduulit ovat käytettävissä, VPN-asiakkaat pitävät lähdeosoitteita osoitteessa 10.90.0.0/24 ja backend on osoitteessa 192.168.50.20:443 ja tarjoaa jo aiottua HTTPS-identiteettiä.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}Lue tämä uuden listenerin katkelmana, älä käynnissä olevan kokoonpanon suorana korvaajana. Käy ensin läpi olemassa olevat listenerit ja includet, sillä toinen listener jo varatulla portilla epäonnistuu reloadissa, ei pyyntöhetkellä.
Huomaa, mikä puuttuu: ei listen ... ssl, ei sertifikaattidirektiiviä. NGINX välittää salatun virran, ja backend lopettaa TLS:n ja esittää sertifikaatin, jonka asiakas validoi. Asiakas, joka ei läpäise allowlistia, saa TCP-istuntonsa hylättynä, ei HTTP 403 -sivua, ja mikä tahansa työkalu, joka odottaa tilakoodia, raportoi jotain hyödytöntä.
Mitä allowlist kattaa ja mitä ei
Jos rele valitsee backendit jo palvelimen nimen mukaan, ssl_preread ja map voivat jatkaa sitä työtä, jos moduuli on käytettävissä. Nimen toimittaa edelleen asiakas, eikä nimen esittäminen todista, että asiakas on liittynyt VPN:ään.
Esimerkkisääntö kattaa koko stream-listenerin. Se tekee siitä sopimattoman yhdelle sisäänkäyntipisteelle, joka palvelee julkisten ja vain VPN:lle tarkoitettujen sivustojen sekoitusta, missä tarvittaisiin poikkeus nimeä kohti; erilliset listenerit ovat yleensä selkeämpiä kuin nimestä riippuva käytäntö, jota kukaan ei voi lukea.
Kaksi muuta aukkoa kannattaa nimetä. Etuliitteen täsmäytys ei kerro, mistä rajapinnasta paketti saapui, eikä HTTP-sääntö muualla voi rajoittaa tätä listeneria. Molemmat ovat syitä pitää isäntätason sisäänkäyntikäytäntö kuvassa sen sijaan, että yhtä allow-riviä pidettäisiin koko rajana. Kirjoita raja kahdeksi kontrolliksi, joiden on oltava yhtä mieltä, jotta kummankin muutos katselmoidaan.
Kenen osoitteen NGINX todella näkee?
Kuormantasain, toinen proxy tai source NAT voi asettaa välittäjän NGINXin eteen, joten havaittu vertainen ei ole VPN-asiakkaan sisäinen osoite. Tutki todellinen polku ennen etuliitteen valintaa, sillä väärälle osoitteelle kirjoitettu allowlist joko päästää kaikki kääntäjän takana tai ei ketään.
PROXY-protokolla ja todellisen IP:n käsittely ovat laillisia vastauksia, ja ne on määritettävä vain yhteensopiville, nimenomaisesti luotetuille lähettäjille. Molemmat mekanismit uskovat, mitä lähettäjä sanoo, ja juuri siksi lähettäjäluettelon on oltava lyhyt. Identiteettiotson luottaminen miltä tahansa internet-asiakkaalta ei tee lähdetiedoista jälleen luotettavia; se muuttaa oikean hylkäyksen väärennettyyn hyväksyntään.
Testaa molemmat tulokset ennen reloadia
Validoi kokoonpano, tee reload ja testaa sitten kahdesti: uusi sallittu istunto, jonka on toimittava, ja hylätty, jonka ei pidä toimia. Pidä tavallinen backend-sertifikaatin varmennus sallitussa testissä, sillä rele, joka yhdistää mutta ei voi validoida backendia, on ratkaissut yhden ongelman ja luonut toisen.
nginx -t
ss -tnp | grep ':443'Tarkista myös backend-reitti ja vastaus erikseen. Allowlistin läpäiseminen todistaa vain, että NGINX hyväksyi istunnon; se ei voi saada saavuttamatonta backendia vastaamaan eikä korjata paluupolkua, joka puuttui ennen kuin aloitit.