Autoriser une connexion TLS passthrough dans le contexte stream de NGINX

NGINX peut refuser un relais TCP TLS sans terminer TLS. Placez la règle d’admission dans stream, pas dans un location HTTP, et vérifiez quelle adresse de pair arrive.

Transmettre des octets chiffrés sans jamais détenir le certificat, voilà ce que fait un relais TLS passthrough, et ce montage est à la fois pratique et un peu déroutant. Comme rien n’est déchiffré, il n’existe rien de forme HTTP à filtrer, donc le bloc location habituel et ses règles d’accès ne servent à rien ici. La décision dont dispose NGINX porte sur la connexion elle-même : quel pair réseau a frappé, et si ce pair doit être relayé du tout.

La décision relève de stream, pas de HTTP

Dans le contexte stream, NGINX travaille avec des sessions TCP. Il voit l’adresse de pair de la connexion et peut y appliquer des règles allow et deny ordonnées avant qu’aucun octet n’atteigne le backend. C’est une décision d’admission complète, et elle ne demande ni clé privée, ni certificat, ni analyse 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

Ces trois lignes ne se substituent jamais l’une à l’autre. Copier une directive d’accès HTTP dans le fichier qui mentionne le port 443 ne change rien, car le serveur stream ne lit jamais le contexte http.

Admettez la connexion avant de la relayer

Supposez une installation existante avec les modules stream et stream-access disponibles, des clients VPN conservant des adresses source dans 10.90.0.0/24, et un backend à 192.168.50.20:443 qui sert déjà l’identité HTTPS prévue.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lisez cela comme un fragment de nouveau listener, non comme un remplacement direct d’une configuration en production. Passez d’abord en revue les listeners et include existants, car un second listener sur un port déjà lié échoue au reload, pas au moment de la requête.

Remarquez ce qui manque : pas de listen ... ssl, pas de directive de certificat. NGINX relaie le flux chiffré, et le backend termine TLS et présente le certificat que le client valide. Un client qui échoue à l’allowlist voit sa session TCP rejetée, pas une page HTTP 403, et tout outil qui attend un code de statut signalera quelque chose d’inutile.

Ce que couvre l’allowlist et ce qu’elle ne couvre pas

Si le relais choisit déjà les backends par nom de serveur, ssl_preread et une map peuvent continuer ce travail, à condition que le module soit disponible. Le nom est toujours fourni par le client, et rien dans la présentation d’un nom ne prouve que le client a rejoint le VPN.

La règle d’exemple couvre tout le listener stream. Cela la rend inadaptée à un point d’entrée unique servant un mélange de sites publics et de sites réservés au VPN, où une exception par nom serait nécessaire ; des listeners séparés sont généralement plus clairs qu’une politique dépendante du nom que personne ne peut lire.

Deux autres lacunes méritent d’être nommées. Une correspondance de préfixe ne dit rien de l’interface par laquelle le paquet est arrivé, et une règle HTTP ailleurs ne peut pas contraindre ce listener. Les deux sont des raisons de garder la politique d’entrée au niveau de l’hôte dans le tableau plutôt que de traiter une ligne allow comme toute la frontière. Écrivez la frontière comme deux contrôles qui doivent s’accorder, afin que tout changement de l’un ou l’autre soit relu.

Quelle adresse NGINX voit-il réellement ?

Un répartiteur de charge, un autre proxy ou un source NAT peuvent placer un intermédiaire devant NGINX, si bien que le pair observé n’est pas l’adresse interne du client VPN. Inspectez le chemin réel avant de choisir un préfixe, car une allowlist écrite pour la mauvaise adresse soit admet tout le monde derrière le traducteur, soit personne.

Le protocole PROXY et la gestion de l’IP réelle sont des réponses légitimes, et elles ne doivent être configurées que pour des expéditeurs compatibles et explicitement de confiance. Les deux mécanismes croient ce que dit l’expéditeur, et c’est précisément pourquoi la liste des expéditeurs doit être courte. Faire confiance à un en-tête d’identité venant de n’importe quel client Internet ne rend pas les informations de source fiables à nouveau ; cela transforme un refus correct en une acceptation falsifiée.

Testez les deux issues avant de recharger

Validez la configuration, rechargez, puis testez deux fois : une nouvelle session autorisée qui doit fonctionner, et une refusée qui ne doit pas. Gardez la vérification normale du certificat backend dans le test autorisé, car un relais qui se connecte mais ne peut pas valider le backend a résolu un problème et en a créé un autre.

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

Vérifiez aussi la route vers le backend et la réponse séparément. Passer l’allowlist prouve seulement que NGINX a accepté la session ; cela ne peut pas faire répondre un backend injoignable, ni réparer un chemin de retour qui manquait avant que vous ne commenciez.

Articles similaires