Salut les expert·es du web et les autres moules de l’incubateur d’excellence qu’est LinuxFr.
J’ai deux machines qui hébergent des applications web différentes sur un même réseau local. Ce réseau local a une seule IPv4 publique. Pour le moment, toutes les applications visibles de l’extérieur en IPv4 tournent sur la même machine, la seconde machine n’offre ses services qu’en IPv6.
Malheureusement, l’une des applications web hébergées sur la machine IPv6 doit parler au reste du monde (ActivityPub) et une partie du reste du monde est coincée dans le passé en IPv4. Qu’à cela ne tienne, me suis-je dit, un reverse proxy sur la machine IPv4 et le tour est joué. Mais la vie n’est pas si simple, parce-que je ne crois pas pouvoir utiliser un certificat (valide) différent pour la connexion IPv4 et celle IPv6, et mes deux machines qui avant n’avaient pas besoin de se parler, deviendraient interdépendantes pour pouvoir servir toutes deux l’application à la même adresse avec le même certificat.
Les solutions auxquelles je pense sont :
- mettre en reverse proxy la connexion en IPv4 et en IPv6 sur la machine visible en IPv4 depuis l’extérieur. La machine IPv6 ne dialoguerait donc jamais directement avec l’extérieur. Ça marcherait, mais c’est nul parce-que ce montage n’a aucune raison d’être en IPv6, complique beaucoup les choses, introduit un goulet d’étranglement commun et surcharge inutilement la machine IPv4 ;
- partager les certificats de la machine IPv6 sur celle IPv4, une simple copie de ne suffit pas car il faut que les deux restent synchronisées quand les certificats sont renouvelés. Ça marcherait aussi, c’est un peu moins nul mais frustrant car ça ajoute de la complexité et une nouvelle brique qui peut dysfonctionner. Point bonus en cas de dysfonctionnement du partage, si le proxy IPv4 merdouille, le service IPv6 peut être perçu comme non fonctionnel vu de l’extérieur alors qu’il fonctionnerait encore parfaitement en IPv6 ;
- racheter toutes les adresses IPv4 encore disponibles pour faire flamber les prix et forcer à l’adoption massive d’IPv6 par tout le monde. Ça risque de marcher pour les 10 premières adresses, mais si les prix flambent comme mon projet le demande, je n’aurai pas assez de toute ma fortune personnelle pour contraindre financièrement le monde entier, la vie est injuste ;
- utiliser plusieurs certificats pour un même nom de domaine (donc des certificats différents en IPv6 et en IPv4), ce serait l’idéal. Est-ce que ça se fait, y a-t-il des précautions à prendre ? Mes certificats actuels sont émis par Let’s Encrypt, y a-t-il un moyen de lui demander de faire la validation en IPv4 pour une machine et en IPv6 pour l’autre, sachant que le nom de domaine aurait des enregistrements A et AAAA qui pointeraient sur des machines différentes ?
Merci de votre aide face à cette épineuse question !
# Sujet du commentaire
Posté par Sacha Trémoureux (site web personnel) . Évalué à 3 (+2/-0).
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.
# Au passage
Posté par cg . Évalué à 4 (+2/-0).
J'ai vu de la lumière, je me permet… Avoir tes machines derrière un reverse proxy, placé dans une zone tampon vulgairement nommée DMZ, me semble au contraire une bonne idée en terme de sécurité.
Les flux entrants passent par un reverse proxy, les flux sortants passent par un proxy classique. Ainsi tes serveurs ne parlent pas directement avec l'hostile Internet, IPv4 ou IPv6.
[^] # Re: Au passage
Posté par Sacha Trémoureux (site web personnel) . Évalué à 3 (+2/-0).
C’est le mieux oui, mais il faudrait à l’auteur une troisième machine si il veut pas avoir un serveur qui fasse reverse en même temps qu’applicatif !
[^] # Re: Au passage
Posté par jyes . Évalué à 2 (+0/-0).
Merci pour vos retours à tous les deux. Je vais donc me diriger vers une solution avec reverse proxy IPv4 et IPv6 depuis la machine accessible en IPv4 depuis l’extérieur. Ça n’est pas idéal, même selon vos conseils car je ne vais pas ajouter de troisième machine, mais de toute façon, comme je l’avais dit dans ma question « c’est nul », mais si ça marche…
# Rachat des IPv4
Posté par cg . Évalué à 4 (+2/-0).
Il semble que tu n'es pas le premier à avoir l'idée : Cogent se sert de la valeur des IPv4 comme garantie financière :).
[^] # Re: Rachat des IPv4
Posté par totof2000 . Évalué à 3 (+1/-0). Dernière modification le 05 mai 2024 à 13:42.
Hum ..
Le truc c'est que si tu achètes des IPV4 pour faire monter le prix de celles-ci afin de pousser le monde à IPV6, tu te retrouveras en fin d'opération avec des IPV4 que tu auras payées bien cher, mais qui ne vaudront plus rien … De loin ça me fait penser à la problématique des taxi qqui ont eu leurs plaques gratuitement mais qui se sont mis à les revendre entre eux à prix prohibitifs: ilsse sont mis eux-même en galère par appat du gain (mais les gouvernements successifs sont responsables d'avoir laissé faire).
Du coup ça explique la réticence des opérateurs réseau à passer à IPV6 : ils vont "perdre" de l'argent ( ou plutôt leurs actifs vont perdre de la valeur).
Il faudrait que la législation empêche ce genre de pratique, ou taxe fortement les IPV4 (avec interdiction de répercuter le cout de la taxe sur les clients) pour pousser à la bascule vers IPV6. Je ne suis pas fan de la méthode de l'impôt popur forcer aux bonnes pratiques, mais dans ce cas précis, pour accélérer la transition, je pourrais bien faire une exception.
# Proxy SNI
Posté par GG (site web personnel) . Évalué à 3 (+1/-0).
Y a un truc qui s'appelle Proxy SNI.
C'est pris en charge par Nginx, ou HaProxy.
L'intérêt de HAproxy, c'est qu'il pourra le faire aussi pour les emails, contrairement à Nginx.
Le Proxy SNI ne va pas toucher au certificat de sécurité, mais il saura transmettre à la bonne machine, et c'est cette dernière qui gèrera la partie SSL.
L'intérêt, c'est que si tes serveurs ne sont pas double-stack, c'est pas un soucis, tant que le Proxy SNI l'est.
Tu peux avoir un Proxy SNI pour IPv4, et un autre pour IPv6, ça ne pose aucun soucis.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Proxy SNI
Posté par jyes . Évalué à 2 (+0/-0).
J‘avais vu passer mais je ne voyais pas comment l’utiliser. C’est une bonne solution mais je n’ai pas vu comment le faire avec Nginx. Je vais tenter d’installer sniproxy dans un conteneur qui prendra toutes les connexions IPv4 et les redistribuera. Et je ne touche pas à IPv6, car pas besoin de mettre une rustine sur système qui fonctionne déjà.
Merci du tuyau !
[^] # Re: Proxy SNI
Posté par GG (site web personnel) . Évalué à 3 (+1/-0).
Pour Nginx, il faut combiner "pre-read" et "stream" :
https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Proxy SNI
Posté par jyes . Évalué à 3 (+1/-0).
Merci beaucoup ! Le logiciel sniproxy qui me semblait plus simple est abandonné, notamment car nginx le fait. Je vais donc me rabattre sur nginx. Et puis, avec cette doc sous les yeux, ce n‘est pas si compliqué que ça à faire avec nginx non plus.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.