TLS-passthrough kapcsolat engedélyezése a NGINX stream környezetében

Titkosított bájtok továbbítása anélkül, hogy valaha is birtokolnánk a tanúsítványt, ez az, amit egy TLS-passthrough relé tesz, és ez az elrendezés kényelmes és kissé zavaró egyszerre. Mivel semmi sem fejtődik vissza, nincs semmi HTTP alakú, amire szűrni lehetne, ezért a szokásos location blokk és hozzáférési szabályai itt nem használnak semmit. A NGINX rendelkezésére álló döntés magára a kapcsolatra vonatkozik: melyik hálózati peer kopogtatott, és egyáltalán tovább kell-e engedni.

A döntés a streambe tartozik, nem a HTTP-be

A stream környezetben a NGINX TCP-munkamenetekkel dolgozik. Látja a kapcsolat peer-címét, és rendezett allow és deny szabályokat alkalmazhat rá, mielőtt bármely bájt elérné a backendet. Ez teljes beengedési döntés, és nem igényel privát kulcsot, tanúsítványt vagy HTTP-elemzést.

Az a három sor soha nem helyettesíti egymást. Egy HTTP hozzáférési direktíva átmásolása abba a fájlba, amelyik a 443-as portot említi, semmit sem változtat, mert a stream kiszolgáló soha nem olvassa az http környezetet.

Engedje be a kapcsolatot, mielőtt továbbítja

Tételezzen fel egy meglévő telepítést elérhető stream és stream-access modulokkal, VPN-klienseket, amelyek forráscímeket tartanak a 10.90.0.0/24 tartományban, és egy backendet a 192.168.50.20:443 címen, amely már a szándékolt HTTPS-identitást szolgálja ki.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Ezt egy új listener töredékeként olvassa, nem egy működő konfiguráció közvetlen helyettesítéseként. Először tekintse át a meglévő listenereket és include-okat, mert egy második listener egy már lekötött porton reloadkor bukik el, nem kéréskor.

Figyelje meg, mi hiányzik: nincs listen ... ssl, nincs tanúsítvány-direktíva. A NGINX továbbítja a titkosított adatfolyamot, a backend pedig lezárja a TLS-t és bemutatja a tanúsítványt, amelyet a kliens ellenőriz. Az allowlistet nem teljesítő kliens TCP-munkamenete elutasításra kerül, nem HTTP 403 oldalt kap, és minden eszköz, amely állapotkódot vár, valami haszontalant fog jelenteni.

Mit fed le az allowlist és mit nem

Ha a relé már kiszolgálónév szerint választ backendeket, a ssl_preread és egy map tovább végezheti ezt a munkát, feltéve, hogy a modul elérhető. A nevet továbbra is a kliens adja, és a név bemutatása nem bizonyítja, hogy a kliens csatlakozott a VPN-hez.

A példaszabály a teljes stream listenert lefedi. Ez alkalmatlanná teszi egyetlen belépési pontra, amely nyilvános és csak VPN-es oldalak keverékét szolgálja ki, ahol névenkénti kivételre lenne szükség; a külön listenerok általában világosabbak, mint egy névfüggő szabályzat, amelyet senki sem tud elolvasni.

Érdemes megnevezni két további rést. Egy előtag-egyezés semmit sem mond arról, melyik interfészen érkezett a csomag, és egy máshol lévő HTTP-szabály nem korlátozhatja ezt a listenert. Mindkettő ok arra, hogy a hosztszintű belépési szabályzatot képben tartsuk, ahelyett hogy egy allow sort tekintenénk a teljes határnak. Írja le a határt két ellenőrzésként, amelyeknek egyezniük kell, hogy bármelyikük változása felülvizsgálatra kerüljön.

Melyik címet látja a NGINX valójában?

Egy terheléselosztó, egy másik proxy vagy egy source NAT közvetítőt tehet a NGINX elé, így a megfigyelt peer nem a VPN-kliens belső címe. Vizsgálja meg a valódi útvonalat, mielőtt előtagot választ, mert a rossz címre írt allowlist vagy mindenkit beenged a fordító mögött, vagy senkit.

A PROXY protokoll és a valódi IP kezelése legitim válaszok, és csak kompatibilis, kifejezetten megbízható küldők számára konfigurálhatók. Mindkét mechanizmus hisz annak, amit a küldő mond, és éppen ezért kell a küldők listájának rövidnek lennie. Egy identitásfejléc megbízása bármely internetes klienstől nem teszi újra megbízhatóvá a forrásinformációt; egy helyes elutasítást hamis elfogadássá alakít.

Mindkét eredményt tesztelje reload előtt

Érvényesítse a konfigurációt, töltsön újra, majd teszteljen kétszer: egy új engedélyezett munkamenetet, amelynek működnie kell, és egy elutasítottat, amelynek nem. Tartsa meg a szokásos backend-tanúsítvány-ellenőrzést az engedélyezett tesztben, mert egy relé, amely kapcsolódik, de nem tudja érvényesíteni a backendet, egy problémát megoldott és egy másikat teremtett.

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

Ellenőrizze a backend útvonalát és a választ külön is. Az allowlist átlépése csak azt bizonyítja, hogy a NGINX elfogadta a munkamenetet; nem kényszerítheti válaszra az elérhetetlen backendet, és nem javíthatja a visszaút hiányát, amely a kezdés előtt hiányzott.