FrancoisAEn fait, tu déportes la DMZ chez ton hébergeur de VPS ou de serveur dédié.
Zatalyzça me travaille ce que vous racontez. Je *sais* que je n'ai pas le cognitif pour comprendre, mais ça me travaille quand même, donc... je vais poser mes questions de noob.
Pour le moment on a le souci suivant en ipv4 (parce que sauf erreur en ipv6 ça se poserait pas) : tout le flux arrive sur une seule ipv4 et sur les ports 80/443. On a un hyperviseur et des VM, toutes derrière ça. On redirige tout le trafic 80/443 vers le proxy nginx, qui ensuite renvoie aux bonnes VM. Sauf que si on ne souhaite pas terminer la partie chiffrée sur le proxy (et que ce soit ensuite en clair entre le proxy et les VM), heu... On fait comment ? Parce que ok, le SNI passthrough ça marchait mais ça va plus marcher, mais j'ai pas compris si y'avait une alternative dans cette config précise.
ZatalyzJe précise bien : j'ai *besoin* des certifs sur certaines VM. Pas que pour le mail, même si c'est évidement le plus classique. Et on est encore avec de l'ipv4 et une seule ip, donc
Zatalyz(pour l'ipv6, n'hésitez surtout pas à bosser sur le sujet, faire la doc, les manips, etc ; pas que je ne veux pas mais je suis incapable à ce stade d'explorer ce truc en plus des autres choses à faire, et de toute façon l'ipv4 continue d'exister et demande à être gérée)
Zatalyzvotre redirection TCP est juste si on a un flux facile à chopper (genre tout le trafic du port 25 renvoyé sur la VM "mail"), c'est bien ça ? les règles de pare-feu de base, mais qui ne tiennent pas compte du nom de domaine qu'on tente de joindre ?
Zatalyz(ne me demandez pas pourquoi le certif doit être sur les vm en bout de chaine, je ne sais plus les détails, mais ça a été écrit à un moment, je sais juste que "il faut")
tychoZat : c'est bien ça oui, et non il n'y a pas de solution pour ce que tu cherches à faire
tychoenfin pas de solution autre que passer en IPv6-only
tychoou avoir une terminaison TLS au niveau du reverse-proxy, ce qui n'empêche pas d'également avoir du TLS (voir même du mTLS) entre le reverse-proxy et le serveur
tychoperso j'ai du mal à voir ce qui justifie que le reverse-proxy ne puisse pas assurer la terminaison TLS
tychoj'ai l'impression, et je peux me tromper, que ça peut avoir été décidé afin d'éviter d'avoir du trafic en clair entre le reverse-proxy et le serveur, car ce n'est pas si simple que ça à mettre en œuvre
tycholes 2 possibilités principales pour faire ça c'est, au choix :
tycho- utiliser un certif public mais utilisant un challenge qui ne soit ni http-01 ni tls-alpn-01, ce qui laisse dns-01 qui est peu pratique et dns-persist-01 qui n'est pas encore arrivé mais arrive prochainement
tycho- utiliser une autorité de certification personelle, ce qui est un brin délicat à mettre en œuvre et à maintenir
tychobref, si c'est bien ça la cause, alors à mon avis la solution est d'attendre l'arrivée de dns-persist-01 et de miser dessus pour tous les certifs et ainsi d'assurer à al fois la terminaison TLS au niveau du reverse-proxy et un trafic chiffré entre le reverse-proxy et le serveur
glorfOui pour la redirection de port TCP, tu peux pas faire du proxy intelligent : soit t'envoies tout le trafic vers une machine, soit pas, tu peux pas te baser sur le nom de domaine pour rediriger ; le TCP n'a pas cette connaissance
glorfIl te faut un protocole comme HTTP qui lui fonctionne nativement avec des noms de domaine, et donc un serveur http peut faire des redirections intelligentes et séparer le trafic
glorfMais ça dépend du protocole, par exemple SMTP et ssh n'ont pas cette notion là de nom de domaine non plus
glorfMa solution ça marche juste pour du mail, car si nginx termine le tls pour SMTP/IMAP, il a pas besoin de proxy de manière intelligente derrière : il envoie tout à une machine