Povoliť priechodné TLS spojenie v kontexte stream v NGINX

NGINX môže odmietnuť TCP TLS relay bez ukončenia TLS. Pravidlo povolenia patrí do stream, nie do HTTP location, a overte, ktorá adresa partnera prichádza.

Preposielanie šifrovaných bajtov bez toho, aby ste niekedy držali certifikát, je to, čo robí relay s priechodom TLS, a toto usporiadanie je pohodlné a zároveň trochu mätúce. Keďže sa nič nedešifruje, neexistuje nič v podobe HTTP na filtrovanie, takže obvyklý blok location a jeho prístupové pravidlá tu nemajú žiadny úžitok. Rozhodnutie, ktoré NGINX má, sa týka samotného spojenia: ktorý sieťový partner zaklopal a či sa má vôbec prepustiť.

Rozhodnutie patrí do stream, nie do HTTP

V kontexte stream pracuje NGINX s TCP reláciami. Vidí adresu partnera spojenia a môže na ňu uplatniť usporiadané pravidlá allow a deny skôr, než sa akýkoľvek bajt dostane do backendu. Je to úplné rozhodnutie o prijatí a nevyžaduje súkromný kľúč, certifikát ani HTTP parsovanie.

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

Tie tri riadky sa nikdy nezastupujú. Kopírovanie HTTP direktívy prístupu do súboru, ktorý spomína port 443, nič nemení, pretože server stream nikdy nečíta kontext http.

Prijmite spojenie skôr, než ho prepustíte

Predpokladajte existujúcu inštaláciu s dostupnými modulmi stream a stream-access, VPN klientov, ktorí držia zdrojové adresy v 10.90.0.0/24, a backend na 192.168.50.20:443, ktorý už poskytuje zamýšľanú identitu HTTPS.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Čítajte to ako fragment nového listeneru, nie ako priamu náhradu fungujúcej konfigurácie. Najprv prejdite existujúce listenery a include, pretože druhý listener na už obsadenom porte zlyhá pri reloade, nie v čase požiadavky.

Všimnite si, čo chýba: žiadny listen ... ssl, žiadna direktíva certifikátu. NGINX preposiela šifrovaný tok a backend ukončuje TLS a predkladá certifikát, ktorý klient overuje. Klient, ktorý neprejde allowlistom, dostane odmietnutú TCP reláciu, nie stránku HTTP 403, a každý nástroj, ktorý očakáva stavový kód, nahlási niečo neužitočné.

Čo allowlist pokrýva a čo nie

Ak relay už vyberá backendy podľa názvu servera, ssl_preread a map môžu túto prácu robiť ďalej, ak je modul dostupný. Názov stále dodáva klient a nič na predložení názvu nedokazuje, že sa klient pripojil k VPN.

Pravidlo z príkladu pokrýva celý listener stream. To ho robí nevhodným pre jeden vstupný bod, ktorý obsluhuje zmes verejných a iba VPN stránok, kde by bola potrebná výnimka pre každé meno; samostatné listenery sú zvyčajne jasnejšie než politika závislá od názvu, ktorú nikto nevie prečítať.

Stojí za to pomenovať dve ďalšie medzery. Zhoda prefixu nič nehovorí o tom, ktorým rozhraním paket prišiel, a HTTP pravidlo inde tento listener obmedziť nemôže. Oboje sú dôvody držať politiku vstupu na úrovni hostiteľa v obraze, namiesto toho, aby sa jeden riadok allow považoval za celú hranicu. Zapíšte hranicu ako dve kontroly, ktoré musia súhlasiť, aby každá zmena ktorejkoľvek z nich prešla revíziou.

Čiu adresu NGINX skutočne vidí?

Nástroj na vyvažovanie záťaže, iný proxy alebo source NAT môžu pred NGINX postaviť sprostredkovateľa, takže partner, ktorý sa vidí, nie je vnútorná adresa VPN klienta. Pred voľbou prefixu preskúmajte skutočnú cestu, pretože allowlist napísaný pre nesprávnu adresu buď pustí všetkých za prekladačom, alebo nikoho.

Protokol PROXY a spracovanie skutočnej IP sú legitímne odpovede a musia sa konfigurovať len pre kompatibilných, výslovne dôveryhodných odosielateľov. Oba mechanizmy veria tomu, čo odosielateľ hovorí, a práve preto musí byť zoznam odosielateľov krátky. Dôvera v hlavičku identity od akéhokoľvek internetového klienta nerobí zdrojové informácie znova dôveryhodnými; mení správne odmietnutie na sfalšované prijatie.

Otestujte oba výsledky pred reloadom

Overte konfiguráciu, vykonajte reload a potom testujte dvakrát: novú povolenú reláciu, ktorá musí fungovať, a odmietnutú, ktorá nesmie. V povolenom teste ponechajte bežné overenie certifikátu backendu, pretože relay, ktorý sa pripojí, ale nedokáže overiť backend, vyriešil jeden problém a vytvoril iný.

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

Skontrolujte tiež trasu k backendu a odpoveď zvlášť. Prejdenie allowlistom dokazuje len to, že NGINX reláciu prijal; nemôže prinútiť nedostupný backend odpovedať a nemôže opraviť spätnú cestu, ktorá chýbala predtým, než ste začali.

Súvisiace články