Atļaut TLS passthrough savienojumu NGINX stream kontekstā

NGINX var noraidīt TCP TLS relay, nepabeidzot TLS. Ievietojiet atļaujas noteikumu stream, nevis HTTP location, un pārbaudiet, kāda peer adrese pienāk.

Šifrētu baitu pārsūtīšana, nekad neturot sertifikātu, ir tas, ko dara TLS passthrough relay, un šis izkārtojums ir ērts un vienlaikus mazliet mulsinošs. Tā kā nekas netiek atšifrēts, nav nekā HTTP formā, ko filtrēt, tāpēc parastais location bloks un tā piekļuves noteikumi šeit neko nedod. Lēmums, kas NGINX ir pieejams, attiecas uz pašu savienojumu: kurš tīkla peer pieklauvēja un vai šis peer vispār jāpārsūta.

Lēmums pieder stream, nevis HTTP

stream kontekstā NGINX strādā ar TCP sesijām. Tas redz savienojuma peer adresi un var tai piemērot sakārtotus allow un deny noteikumus, pirms jebkurš baits sasniedz backend. Tas ir pilnīgs uzņemšanas lēmums, un tam nav vajadzīga privātā atslēga, sertifikāts vai HTTP analīze.

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

Šīs trīs rindas nekad neaizstāj viena otru. HTTP piekļuves direktīvas kopēšana jebkurā failā, kas piemin portu 443, neko nemaina, jo stream serveris nekad nelasa http kontekstu.

Uzņemiet savienojumu pirms tā pārsūtīšanas

Pieņemsim, ka ir esoša instalācija ar pieejamiem stream un stream-access moduļiem, VPN klienti glabā avota adreses 10.90.0.0/24, un backend adresē 192.168.50.20:443 jau nodrošina paredzēto HTTPS identitāti.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lasiet to kā jauna listener fragments, nevis kā tiešu strādājošas konfigurācijas aizstājēju. Vispirms pārskatiet esošos listener un include, jo otrs listener jau aizņemtā portā neizdodas reload laikā, nevis pieprasījuma laikā.

Ievērojiet, kas trūkst: nav listen ... ssl, nav sertifikāta direktīvas. NGINX pārsūta šifrēto plūsmu, un backend pabeidz TLS un uzrāda sertifikātu, ko klients validē. Klients, kas neiztur allowlist, saņem noraidītu TCP sesiju, nevis HTTP 403 lapu, un jebkurš rīks, kas gaida statusa kodu, ziņos par kaut ko bezjēdzīgu.

Ko allowlist aptver un ko ne

Ja relay jau izvēlas backend pēc servera nosaukuma, ssl_preread un map var turpināt šo darbu, ja modulis ir pieejams. Nosaukumu joprojām nodrošina klients, un nekas nosaukuma uzrādīšanā nepierāda, ka klients ir pievienojies VPN.

Piemēra noteikums aptver visu stream listener. Tas padara to nepiemērotu vienam ieejas punktam, kas apkalpo publisku un tikai VPN paredzētu vietņu maisījumu, kur būtu vajadzīgs izņēmums katram nosaukumam; atsevišķi listener parasti ir skaidrāki nekā no nosaukuma atkarīga politika, ko neviens nevar izlasīt.

Ir vērts nosaukt vēl divas nepilnības. Prefiksa atbilstība neko nepasaka par to, pa kuru saskarni pakete ienāca, un HTTP noteikums citur nevar ierobežot šo listener. Abi ir iemesli paturēt hosta līmeņa ingress politiku ainā, nevis uzskatīt vienu allow rindu par visu robežu. Pierakstiet robežu kā divas kontroles, kurām jāsakrīt, lai jebkuras no tām izmaiņas tiktu pārskatītas.

Kādu adresi NGINX patiešām redz?

Slodzes balansētājs, cits proxy vai source NAT var novietot starpnieku NGINX priekšā, tāpēc novērotais peer nav VPN klienta iekšējā adrese. Pirms prefiksa izvēles pārbaudiet reālo ceļu, jo allowlist, kas rakstīts nepareizajai adresei, vai nu ielaiž visus aiz tulkotāja, vai nevienu.

PROXY protokols un reālā IP apstrāde ir likumīgas atbildes, un tās jākonfigurē tikai saderīgiem, skaidri uzticamiem sūtītājiem. Abi mehānismi tic tam, ko saka sūtītājs, un tieši tāpēc sūtītāju sarakstam jābūt īsam. Uzticēšanās identitātes galvenei no jebkura interneta klienta neatgriež avota informāciju uzticamu; tā pārvērš pareizu atteikumu viltotā pieņemšanā.

Pārbaudiet abus rezultātus pirms reload

Validējiet konfigurāciju, veiciet reload, pēc tam pārbaudiet divreiz: jaunu atļautu sesiju, kurai jāstrādā, un noraidītu, kurai nevajadzētu. Saglabājiet parasto backend sertifikāta pārbaudi atļautajā testā, jo relay, kas savienojas, bet nevar validēt backend, ir atrisinājis vienu problēmu un radījis citu.

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

Pārbaudiet arī maršrutu uz backend un atbildi atsevišķi. Allowlist iziešana pierāda tikai to, ka NGINX ir pieņēmis sesiju; tas nevar likt nesasniedzamam backend atbildēt un nevar salabot atgriešanās ceļu, kura trūka pirms sākšanas.

Saistītie raksti