Leyfa TLS-passthrough-tengingu í stream-samhengi NGINX

NGINX getur hafnað TCP TLS-relay án þess að ljúka TLS. Setjið leyfisregluna í stream, ekki í HTTP location, og athugið hvaða peer-vistfang berst.

Að senda dulkóðuð bæti áfram án þess að halda nokkurn tíma skírteininu er það sem TLS-passthrough-relay gerir, og fyrirkomulagið er bæði þægilegt og svolítið ruglingslegt. Þar sem ekkert er afkóðað er ekkert HTTP-laga til að sía á, svo venjulega location-blokkin og aðgangsreglur hennar gera hér ekkert gagn. Ákvörðunin sem NGINX hefur snýst um tenginguna sjálfa: hvaða netpeer bankaði uppá og hvort eigi að senda þann peer áfram yfirhöfuð.

Ákvörðunin á heima í stream, ekki í HTTP

Í stream-samhenginu vinnur NGINX með TCP-lotum. Það sér peer-vistfang tengingarinnar og getur beitt raðaðar allow- og deny-reglur á hana áður en nokkur bæti nær backend. Þetta er fullkomin inntökuákvörðun og krefst engs einkalykils, skírteinis né HTTP-greiningar.

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

Þessar þrjár línur koma aldrei í stað hver annarrar. Að afrita HTTP-aðgangsfyrirmæli í hvaða skrá sem nefnir port 443 breytir engu, því stream-þjónninn les aldrei http-samhengið.

Takið við tengingunni áður en þið sendið hana áfram

Gerið ráð fyrir núverandi uppsetningu með stream- og stream-access-einingunum tiltækum, VPN-biðlarar sem halda upprunavistföngum í 10.90.0.0/24, og backend á 192.168.50.20:443 sem þegar þjónar fyrirhugaðri HTTPS-identitet.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lesið þetta sem brot af nýjum listener, ekki sem beina staðgengil fyrir virka uppsetningu. Farið fyrst yfir núverandi listenere og include, því annar listener á porti sem er þegar bundið mistekst við reload, ekki við beiðnina.

Takið eftir hvað vantar: ekkert listen ... ssl, engin skírteinisfyrirmæli. NGINX sendir dulkóðaða strauminn áfram, og backend lýkur TLS og kynnir skírteinið sem biðlarinn staðfestir. Biðlari sem fellur á allowlist fær TCP-lotunni sinni hafnað, ekki HTTP 403-síðu, og hvert tól sem býst við stöðukóða mun tilkynna eitthvað gagnslaust.

Hvað allowlistin nær yfir og hvað ekki

Ef relayið velur þegar backend eftir þjónsheiti geta ssl_preread og map haldið áfram að gera það verk, að því tilskildu að einingin sé tiltæk. Biðlarinn gefur enn heitið, og ekkert við að kynna heiti sannar að biðlarinn hafi gengið í VPN.

Dæmisreglan nær yfir allan stream-listenerinn. Það gerir hana óhentuga fyrir eitt inngangspunkt sem þjónar blöndu af opinberum síðum og síðum eingöngu fyrir VPN, þar sem undantekning fyrir hvert heiti þyrfti; aðskildir listenerar eru venjulega skýrari en heitisbundin stefna sem enginn getur lesið.

Vert er að nefna tvær eyður til viðbótar. Forskeytissamsvörun segir ekkert um hvaða tengi pakkinn kom inn á, og HTTP-regla annars staðar getur ekki takmarkað þennan listener. Bæði eru ástæður til að halda inngangsstefnu á hýsilstigi í myndinni í stað þess að líta á eina allow-línu sem alla mörkin. Skrifið mörkin sem tvær stýringar sem verða að stemma, svo að breyting á hvorri um sig sé yfirfarin.

Hvers vistfang sér NGINX í raun?

Hleðsludreifir, annar proxy eða source NAT geta sett millilið fyrir framan NGINX, svo peerinn sem sést er ekki innra vistfang VPN-biðlarans. Kannið raunverulegu leiðina áður en þið veljið forskeyti, því allowlist skrifuð fyrir rangt vistfang hleypir annaðhvort öllum á bak við þýðandann inn eða engum.

PROXY-samskiptareglan og meðferð raunverulegs IP eru lögmæt svör, og þau má aðeins stilla fyrir samhæfa, sérstaklega treysta sendendur. Báðar aðferðirnar trúa því sem sendandinn segir, og einmitt þess vegna verður sendendalistinn að vera stuttur. Að treysta auðkennishaus frá hvaða internethiðlara sem er gerir upprunaupplýsingarnar ekki treystandi aftur; það breytir réttri synjun í fölsuðu samþykki.

Prófið bæði útkomurnar fyrir reload

Staðfestið uppsetninguna, gerið reload, prófið svo tvisvar: nýja leyfða lotu sem verður að virka, og hafnaða sem á ekki að virka. Haldið venjulegri backend-skírteinisstaðfestingu í leyfða prófinu, því relay sem tengist en getur ekki staðfest backend hefur leyst eitt vandamál og skapað annað.

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

Athugið líka leiðina að backend og svarið sérstaklega. Að komast í gegnum allowlist sannar aðeins að NGINX hafi tekið við lotunni; það getur ekki látið óaðgengilegan backend svara, og það getur ekki lagað afturleið sem vantaði áður en þið byrjuðuð.

Tengdir greinar