TLS passthrough konexio bat onartzea NGINX-en stream testuinguruan

NGINXek TCP TLS errele bat ukatu dezake TLS amaitu gabe. Onarpen araua stream-en jarri, HTTP location batean ez, eta egiaztatu zein peer helbide iristen den.

Byte zifratuak inoiz ziurtagiria eduki gabe birbidaltzea da TLS passthrough errele batek egiten duena, eta antolaketa erosoa eta pixka bat nahasia da aldi berean. Ezer deszifratzen ez denez, ez dago HTTP itxurarik iragazteko, beraz ohiko location blokeak eta haren sarbide arauek ez dute balio hemen. NGINXek duen erabakia konexioari berari buruzkoa da: zein sare peer-ek jo zuen eta peer hori birbidali behar den ala ez.

Erabakia stream-en dago, ez HTTP-n

stream testuinguruan NGINX TCP saioekin lan egiten du. Konexioaren peer helbidea ikusten du eta allow eta deny arau ordenatuak aplika dakizkioke, byte bat ere backend-era iritsi aurretik. Onarpen erabaki osoa da eta ez du gako pribaturik, ziurtagiririk ezta HTTP analisirik behar.

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

Hiru errenkada horiek ez dute inoiz elkar ordezkatzen. HTTP sarbide direktiba bat 443 portua aipatzen duen fitxategira kopiatzeak ez du ezer aldatzen, stream zerbitzariak ez baitu inoiz http testuingurua irakurtzen.

Onartu konexioa birbidali aurretik

Eman ezazu stream eta stream-access moduluak dituen instalazio bat dagoela, VPN bezeroek jatorrizko helbideak 10.90.0.0/24-en gordetzen dituztela, eta 192.168.50.20:443-n backend bat dagoela jada aurreikusitako HTTPS identitatea ematen duena.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Irakurri hau listener berri baten zati gisa, ez funtzionatzen duen konfigurazioaren ordezkapen zuzen gisa. Berrikusi lehendik dauden listener eta include-ak, portu bat okupatuta duen bigarren listener batek reload garaian huts egiten baitu, ez eskaera garaian.

Ohartu zer falta den: ez dago listen ... ssl, ez dago ziurtagiri direktibarik. NGINXek fluxu zifratua birbidaltzen du, eta backend-ek TLS amaitzen du eta bezeroak baliozkotzen duen ziurtagiria aurkezten du. allowlista gainditzen ez duen bezeroak bere TCP saioa ukatuta jasoko du, ez HTTP 403 orri bat, eta egoera kode bat espero duen edozein tresnak zerbait alferrikakoa emango du.

Zer hartzen du allowlistak eta zer ez

Erreleak jada backend-ak zerbitzari izenaren arabera aukeratzen baditu, ssl_preread eta map batek lan hori egiten jarrai dezakete, modulua eskuragarri badago. Izena bezeroak ematen du oraindik, eta izen bat aurkezteak ez du frogatzen bezeroa VPN-era batu denik.

Adibideko arauak stream listener osoa hartzen du. Hori desegokia egiten du webgune publikoen eta VPN soilik direnen nahasketa bat zerbitzatzen duen sarrera puntu bakarrerako, non izen bakoitzeko salbuespena beharko litzatekeen; listener bereiziak argiagoak izan ohi dira inork irakurri ezin duen izenaren menpeko politikak baino.

Merezi du beste bi hutsune aipatzea. Aurrizki baten bat-etortzeak ez du esaten paketea zein interfazetatik iritsi zen, eta beste leku bateko HTTP arau batek ezin du listener hau mugatu. Biak dira host mailako sarrera politika irudian edukitzeko arrazoiak, allow lerro bat muga osoa dela hartu beharrean. Idatzi muga ados egon behar duten bi kontrol gisa, horietako edozeinetan aldaketak berrikuspena izan dezan.

Zein helbide ikusten du NGINXek benetan?

Karga banatzaile batek, beste proxy batek edo source NAT-ek bitarteko bat jar dezakete NGINXen aurrean, beraz ikusten duen peer-a ez da VPN bezeroaren barne helbidea. Aztertu benetako bidea aurrizkia aukeratu aurretik, helbide okerrarentzat idatzitako allowlist batek itzultzailearen atzeko guztiak onartzen baititu edo inor ez.

PROXY protokoloa eta benetako IParen tratamendua erantzun zilegiak dira, eta soilik bidaltzaile bateragarri eta esplizituki fidagarrientzat konfiguratu behar dira. Bi mekanismoek bidaltzaileak esaten duena sinesten dute, eta horregatik zehazki bidaltzaileen zerrendak laburra izan behar du. Interneteko edozein bezeroren identitate goiburu batean fiatzea ez du jatorri informazioa berriro fidagarri egiten; ukapen zuzen bat onarpen faltsutu bihurtzen du.

Probatu bi emaitzak reload aurretik

Baliozkotu konfigurazioa, egin reload, eta gero probatu bitan: baimendutako saio berri batek funtzionatu behar du, eta ukatu batek ez. Mantendu backend ziurtagiriaren egiaztapen arrunta baimendutako proban, konektatzen duen baina backend-a baliozkotu ezin duen errele batek arazo bat konpondu eta beste bat sortu baitu.

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

Egiaztatu backend bidea eta erantzuna bereizita ere. allowlista gainditzeak NGINXek saioa onartu duela frogatzen du soilik; ezin du iristezin den backend bat erantzutera behartu, eta ezin du hasi aurretik falta zen itzulera bide bat konpondu.

Erlazionatutako artikuluak