Admetre una connexió TLS passthrough al context stream de NGINX

NGINX pot refusar un relé TCP TLS sense acabar la TLS. Posa la regla d’admissió a stream, no en un location HTTP, i comprova quina adreça de pare arriba.

Reenviar bytes xifrats sense tenir mai el certificat és el que fa un relé TLS passthrough, i aquesta disposició és còmoda i una mica confusa alhora. Com que no es desxifra res, no hi ha res amb forma d’HTTP per filtrar, així que el bloc location habitual i les seves regles d’accés no serveixen aquí. La decisió de què disposa NGINX tracta de la connexió mateixa: quin pare de la xarxa ha trucat i si cal reenviar-lo.

La decisió pertany a stream, no a HTTP

Al context stream, NGINX treballa amb sessions TCP. Veu l’adreça del pare de la connexió i pot aplicar-hi regles allow i deny ordenades abans que cap byte arribi al backend. És una decisió d’admissió completa i no requereix cap clau privada, ni certificat, ni anàlisi HTTP.

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

Aquestes tres files no es substitueixen mai les unes a les altres. Copiar una directiva d’accés HTTP al fitxer que esmenti el port 443 no canvia res, perquè el servidor stream no llegeix mai el context http.

Admet la connexió abans de reenviar-la

Suposa una instal·lació existent amb els mòduls stream i stream-access disponibles, clients VPN que mantenen adreces d’origen a 10.90.0.0/24, i un backend a 192.168.50.20:443 que ja serveix la identitat HTTPS prevista.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Llegeix-ho com un fragment de listener nou, no com una substitució directa d’una configuració en funcionament. Revisa primer els listeners i els include existents, perquè un segon listener en un port ja ocupat falla en el reload, no en el moment de la petició.

Fixa’t en què falta: no hi ha listen ... ssl, no hi ha directiva de certificat. NGINX reenvia el flux xifrat, i el backend acaba la TLS i presenta el certificat que valida el client. Un client que no passa la allowlist rep la seva sessió TCP rebutjada, no una pàgina HTTP 403, i qualsevol eina que esperi un codi d’estat informarà d’alguna cosa inútil.

Què cobreix la allowlist i què no

Si el relé ja tria backends pel nom del servidor, ssl_preread i un map poden continuar fent aquesta feina, sempre que el mòdul estigui disponible. El nom encara el proporciona el client, i res en presentar un nom demostra que el client s’hagi unit a la VPN.

La regla d’exemple cobreix tot el listener stream. Això la fa inadequada per a un sol punt d’entrada que serveixi una barreja de llocs públics i llocs només per a VPN, on caldria una excepció per nom; els listeners separats solen ser més clars que una política dependent del nom que ningú no pot llegir.

Val la pena anomenar dues llacunes més. Una coincidència de prefix no diu res sobre per quina interfície ha arribat el paquet, i una regla HTTP en un altre lloc no pot restringir aquest listener. Totes dues són raons per mantenir la política d’ingrés a nivell d’host a la imatge en lloc de tractar una línia allow com tota la frontera. Escriu la frontera com dos controls que han de coincidir, perquè qualsevol canvi en un d’ells es revisi.

Quina adreça veu realment NGINX?

Un balancejador de càrrega, un altre proxy o un source NAT poden posar un intermediari davant de NGINX, així que el pare que observa no és l’adreça interna del client VPN. Inspecciona el camí real abans de triar un prefix, perquè una allowlist escrita per a l’adreça equivocada o bé admet tothom darrere del traductor o bé ningú.

El protocol PROXY i el tractament d’IP real són respostes legítimes, i només s’han de configurar per a remitents compatibles i explícitament de confiança. Tots dos mecanismes creuen el que diu el remitent, i precisament per això la llista de remitents ha de ser curta. Confiar en una capçalera d’identitat de qualsevol client d’internet no fa que la informació d’origen torni a ser fiable; converteix un refús correcte en una acceptació falsificada.

Prova els dos resultats abans del reload

Valida la configuració, fes reload i després prova dues vegades: una sessió nova permesa que ha de funcionar i una de rebutjada que no ha de funcionar. Mantén la verificació normal del certificat del backend a la prova permesa, perquè un relé que connecta però no pot validar el backend ha resolt un problema i n’ha creat un altre.

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

Comprova la ruta al backend i la resposta per separat també. Passar la allowlist només demostra que NGINX ha acceptat la sessió; no pot fer que un backend inabastable respongui, ni pot reparar un camí de tornada que faltava abans que comencessis.

Articles relacionats