Un reverse proxy devant Perforce ou pas : le pour et le contre
Avant de montrer comment mettre nginx devant Perforce, que j’ai fait dans l’article dédié
, il faut poser la vraie question, celle qu’on saute d’habitude: faut-il le faire. Parce que p4d sait terminer son propre TLS et que l’ajout d’un intermédiaire n’est gratuit nulle part. Quatre approches et ce qu’elles coûtent.
Le piège commun : l’IP du client
Un point traverse tout le reste, alors autant le poser d’abord. Dès qu’un intermédiaire termine ou relaie la connexion, p4d risque de voir l’adresse de cet intermédiaire et non celle du client. Cela casse le logging par IP, les protections côté serveur qui s’appuient sur l’adresse et les triggers qui la lisent. Chacune des options ci-dessous se juge en partie là-dessus, donc gardez-le en tête.
Option A : terminaison TLS par nginx en niveau 4
nginx termine le TLS dans un bloc stream et relaie le TCP en clair vers p4d.
Le pour: les certificats vivent au même endroit que ceux de Jenkins ou du reste du parc, renouvelés par le même outil ACME, ce qui est précisément l’intérêt quand on héberge déjà d’autres services derrière le même nginx. On centralise une bonne fois la politique TLS, les ciphers, les versions.
Le contre: c’est l’option où p4d perd le plus l’IP du client, puisqu’il ne voit que le proxy local. Et nginx ne comprend rien au protocole P4, donc il ne filtre, ne journalise et ne route rien au niveau applicatif, il déplace juste le point de terminaison TLS.
Option B : TLS natif de p4d
p4d termine son propre TLS, avec un P4PORT en ssl: et un P4SSLDIR, sans intermédiaire.
Le pour: la simplicité et p4d voit la vraie IP du client, donc logging, protections et triggers fonctionnent comme prévu. Le chiffrement est de bout en bout, sans machine de plus à tenir.
Le contre: les certificats sont gérés à part, hors de la mécanique ACME centralisée, souvent en self-signed avec un p4 trust à diffuser aux clients. Si tout le reste du parc est en Let’s Encrypt automatisé, Perforce devient l’exception qu’on oublie de renouveler.
Option C : passthrough SNI par nginx
nginx ne déchiffre pas, il lit le SNI avec ssl_preread et relaie la connexion TLS intacte vers p4d, qui la termine.
Le pour: on garde le TLS de bout en bout et le certificat sur p4d, tout en passant par un point d’entrée unique, utile pour router plusieurs services TLS sur une même adresse selon le nom demandé.
Le contre: ça ne restaure pas l’IP du client, qui reste masquée au niveau TCP et ça ne mutualise toujours pas les certificats puisque c’est p4d qui les porte. On cumule un peu les inconvénients des deux premières options sans en prendre les avantages, sauf si le routage SNI est le vrai besoin.
Option D : les outils maison, P4Broker et P4P
Perforce fournit ses propres façades, le P4Broker et le P4P , qui eux comprennent le protocole.
Le pour: le broker parle P4, donc il filtre, redirige, journalise et applique des règles au niveau applicatif, ce qu’aucun proxy générique ne sait faire. Le P4P, lui, est un cache pour les sites distants, qui évite de retransférer les mêmes gros binaires à chaque client. Ce sont les bons outils quand le besoin est Perforce, pas TLS. Le contre: ce ne sont pas des terminateurs TLS à vocation de mutualisation. Si l’objectif unique est d’offrir le certificat au même endroit que le reste, le broker est une brique lourde pour une tâche légère et il faut quand même traiter le TLS par-dessus.
Le choix que je fais
Si Perforce est le seul service à exposer, le TLS natif de p4d est le plus honnête: rien à intercaler, l’IP client préservée, un p4 trust à diffuser une fois.
Si Perforce vit à côté d’un Jenkins et d’autres services déjà derrière nginx et que la vraie valeur est d’avoir un seul endroit pour les certificats et la politique TLS, la terminaison niveau 4 se défend, à condition d’assumer la perte de l’IP client ou de la récupérer autrement.
Et si le besoin est Perforce lui-même, filtrage, redirection, cache de site distant, alors ce sont le broker et le proxy maison qu’il faut regarder, pas un reverse proxy générique. Le comment de l’option retenue ici est dans nginx devant Perforce
.
[edit: 2026] L’implémentation Ansible de tout ceci: le rôle nginx .