Caniatáu cysylltiad TLS passthrough yng nghyd-destun stream NGINX

Anfon beitiau amgryptiedig ymlaen heb ddal y dystysgrif o gwbl yw gwaith relái TLS passthrough, ac mae’r trefniant yn gyfleus ac ychydig yn ddryslyd ar yr un pryd. Gan nad oes dim yn cael ei ddatgryptio, nid oes dim ar ffurf HTTP i hidlo arno, felly nid oes unrhyw ddefnydd i’r location block arferol a’i reolau mynediad yma. Mae’r penderfyniad sydd ar gael i NGINX yn ymwneud â’r cysylltiad ei hun: pa gymar rhwydwaith a gnociodd, ac a ddylid ei anfon ymlaen o gwbl.

Mae’r penderfyniad yn stream, nid yn HTTP

Yng nghyd-destun stream mae NGINX yn gweithio gyda sesiynau TCP. Mae’n gweld cyfeiriad cymar y cysylltiad a gall gymhwyso rheolau allow a deny trefnus iddo cyn i unrhyw beit gyrraedd y backend. Penderfyniad derbyn cyflawn yw hwn ac nid oes angen allwedd breifat, tystysgrif na dosrannu HTTP.

Nid yw’r tair rhes hynny byth yn cymryd lle ei gilydd. Nid yw copïo cyfarwyddyd mynediad HTTP i ba bynnag ffeil sy’n crybwyll porth 443 yn newid dim, oherwydd nid yw gweinydd stream byth yn darllen y cyd-destun http.

Derbyniwch y cysylltiad cyn ei anfon ymlaen

Tybiwch fod gosodiad presennol gyda’r modiwlau stream a stream-access ar gael, cleientiaid VPN yn cadw cyfeiriadau ffynhonnell yn 10.90.0.0/24, a backend yn 192.168.50.20:443 sydd eisoes yn gwasanaethu’r hunaniaeth HTTPS a fwriedir.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Darllenwch hyn fel darn listener newydd, nid fel disodliad uniongyrchol o ffurfweddiad sy’n gweithio. Adolygwch y listeneriaid a’r include presennol yn gyntaf, oherwydd mae ail listener ar borth sydd eisoes wedi’i rwymo yn methu ar reload, nid ar amser y cais.

Sylwch beth sydd ar goll: dim listen ... ssl, dim cyfarwyddyd tystysgrif. Mae NGINX yn anfon y ffrwd amgryptiedig ymlaen, ac mae’r backend yn terfynu TLS ac yn cyflwyno’r dystysgrif y mae’r cleient yn ei dilysu. Mae cleient sy’n methu’r allowlist yn cael ei sesiwn TCP wedi’i gwrthod, nid tudalen HTTP 403, a bydd unrhyw offeryn sy’n disgwyl cod statws yn adrodd rhywbeth diwerth.

Beth mae’r allowlist yn ei gynnwys a beth nad yw

Os yw’r relái eisoes yn dewis backendau yn ôl enw’r gweinydd, gall ssl_preread a map barhau i wneud y gwaith hwnnw, cyhyd â bod y modiwl ar gael. Mae’r cleient yn dal i gyflenwi’r enw, ac nid yw cyflwyno enw yn profi bod y cleient wedi ymuno â’r VPN.

Mae rheol yr enghraifft yn cwmpasu’r listener stream cyfan. Mae hynny’n ei gwneud yn anaddas ar gyfer un pwynt mynediad sy’n gwasanaethu cymysgedd o safleoedd cyhoeddus a safleoedd VPN yn unig, lle byddai angen eithriad fesul enw; mae listeneriaid ar wahân fel arfer yn gliriach na pholisi sy’n dibynnu ar enw na all neb ei ddarllen.

Mae dau fwlch arall yn werth eu henwi. Nid yw cyfatebiaid rhagddodiad yn dweud dim am ba ryngwyneb y daeth y pecyn i mewn arno, ac ni all rheol HTTP yn rhywle arall gyfyngu’r listener hwn. Mae’r ddau yn reswm dros gadw polisi mynediad ar lefel y gwesteiwr yn y darlun yn hytrach na thrin un llinell allow fel y ffin gyfan. Ysgrifennwch y ffin fel dau reolydd y mae’n rhaid iddynt gytuno, fel bod newid i’r naill neu’r llall yn cael ei adolygu.

Cyfeiriad pwy mae NGINX yn ei weld mewn gwirionedd?

Gall cydbwysedd llwyth, proxy arall neu source NAT roi cyfryngwr o flaen NGINX, felly nid yw’r cymar a welir yn gyfeiriad mewnol y cleient VPN. Archwiliwch y llwybr go iawn cyn dewis rhagddodiad, oherwydd mae allowlist a ysgrifennwyd ar gyfer y cyfeiriad anghywir naill ai’n derbyn pawb y tu ôl i’r cyfieithydd neu’n gwrthod pawb.

Protocol PROXY a thrin IP go iawn yn atebion cyfreithlon, ac ni ddylid eu ffurfweddu ond ar gyfer anfonwyr cydnaws, y gellir ymddiried ynddynt yn benodol. Mae’r ddau fecanwaith yn credu’r hyn y mae’r anfonwr yn ei ddweud, a dyna’n union pam mae’n rhaid i’r rhestr anfonwyr fod yn fyr. Nid yw ymddiried mewn pennawd hunaniaeth gan unrhyw gleient rhyngrwyd yn gwneud gwybodaeth ffynhonnell yn ddibynadwy eto; mae’n troi gwrthodiad cywir yn dderbyniad ffug.

Profwch y ddau ganlyniad cyn reload

Dilyswch y ffurfweddiad, gwnewch reload, yna profwch ddwywaith: sesiwn newydd a ganiateir sy’n rhaid iddi weithio, ac un a wrthodwyd na ddylai weithio. Cadwch y dilysu tystysgrif backend arferol yn y prawf a ganiateir, oherwydd mae relái sy’n cysylltu ond na all ddilysu’r backend wedi datrys un broblem ac wedi creu un arall.

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

Gwiriwch y llwybr backend a’r ateb ar wahân hefyd. Nid yw pasio’r allowlist yn profi ond bod NGINX wedi derbyn y sesiwn; ni all wneud i backend na ellir ei gyrraedd ateb, ac ni all drwsio llwybr dychwelyd a oedd ar goll cyn i chi ddechrau.