Je pense que tu es bloqué par ton nombre limité de machines. Dans un monde idéal, tu as un/plusieurs reverse-proxy dédiés à ça en dual-stack devant ton infrastructure qui pourrait être en IPv6-only (ou généralement, derrière des IPv4 privées). Avec tes deux serveurs, t’es obligé de partir sur ta solution #1. Je partage l’avis que c’est un peu nul (mais c’est pas trop cher).
La #3 reste la solution la plus pragmatique et d’une certaine façon la plus propre sans tout bouleverser. Après tout, ton besoin c’est de faire du dual-stack...
Par contre pour ton histoire de certificat, soit il me manque une information, soit tu t’embêtes un peu : si tu pars sur l’idée d’un reverse proxy, tu dois lui faire gérer à la fois l’IPv4 et l’IPv6, séparer les deux stacks c’est vraiiiment chercher des ennuis. Tu auras donc besoin que d’un seul certificat dessus, et tu renvoies le trafic sans TLS sur ton autre machine.
Je réponds quand même à tes questions sur la gestion des certificats sur plusieurs machines : les deux scénarios que tu as décrit peuvent se faire et présentent chacun leurs lots de contraintes. Si tu souhaites synchroniser les certificats, ça demande un peu d’outillage mais c’est gérable. L’autre voie qui consiste à générer plusieurs certificats pour des noms de domaine identiques est réalisable : dans certains contextes c’est la seule option. Ça multiplie les emmerdes pour la bonne gestion des certificats, de leur rotation, et d’éviter qu’ils se perdent dans la nature par contre. Pour la validation, je crois que y’a un monde où ça passe si tu le fais par HTTP, mais c’est super bancal. Le plus safe serait de valider par DNS pour ne pas dépendre de la bonne volonté de Lets Encrypt de taper en IPv6 ou en IPv4.
# Sujet du commentaire
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Reverse proxy pour rendre accessible en IPv4 un service IPv6. Évalué à 3.
Je pense que tu es bloqué par ton nombre limité de machines. Dans un monde idéal, tu as un/plusieurs reverse-proxy dédiés à ça en dual-stack devant ton infrastructure qui pourrait être en IPv6-only (ou généralement, derrière des IPv4 privées). Avec tes deux serveurs, t’es obligé de partir sur ta solution #1. Je partage l’avis que c’est un peu nul (mais c’est pas trop cher).
La #3 reste la solution la plus pragmatique et d’une certaine façon la plus propre sans tout bouleverser. Après tout, ton besoin c’est de faire du dual-stack...
Par contre pour ton histoire de certificat, soit il me manque une information, soit tu t’embêtes un peu : si tu pars sur l’idée d’un reverse proxy, tu dois lui faire gérer à la fois l’IPv4 et l’IPv6, séparer les deux stacks c’est vraiiiment chercher des ennuis. Tu auras donc besoin que d’un seul certificat dessus, et tu renvoies le trafic sans TLS sur ton autre machine.
Je réponds quand même à tes questions sur la gestion des certificats sur plusieurs machines : les deux scénarios que tu as décrit peuvent se faire et présentent chacun leurs lots de contraintes. Si tu souhaites synchroniser les certificats, ça demande un peu d’outillage mais c’est gérable. L’autre voie qui consiste à générer plusieurs certificats pour des noms de domaine identiques est réalisable : dans certains contextes c’est la seule option. Ça multiplie les emmerdes pour la bonne gestion des certificats, de leur rotation, et d’éviter qu’ils se perdent dans la nature par contre. Pour la validation, je crois que y’a un monde où ça passe si tu le fais par HTTP, mais c’est super bancal. Le plus safe serait de valider par DNS pour ne pas dépendre de la bonne volonté de Lets Encrypt de taper en IPv6 ou en IPv4.