IPv6, c’est cool, sauf que c’est pas cool !
Pour faire court, surtout côté MacOS/iOS, si t’as pas une adresse IPv6 sur la machine qui consulte ton serveur en IPv6 eh bien tu ne l’atteindra pas ! De plus, au taf, le firewall ne laisse pas passer les paquets IPv6 (je la fait courte parce que ce n’est pas tout à fait ça, mais tu vois l’idée), donc pas d’accès non plus au serveur configuré uniquement en IPv6.
Donc retour à la case départ avec les besoins suivants :
- Une Box avec une IP publique unique
- Un premier serveur déjà configuré qui écoute sur les ports 80 et 443
- Un deuxième serveur qui devra lui aussi écouter sur les mêmes ports (80 et 443)
- LetsEncrypt doit tourner sur les deux serveurs (pas question de stocker les certificats du 2e sur le 1er)
- Et non, pas de modification des ports sur le 2e serveur (ce qui eut pu être une solution à bas coût, de mon côté)
Du coup, un haproxy sur le 1er serveur pour rediriger les (sous-)domaines gérés par le 2e, et faire en sorte que les requêtes LetsEncrypt ne soient pas bloquées par le 1er pour assurer le renouvellement des certificats sur le 2e serveur.
Eh bien sûr, toute la doc que je trouve parle de gérer les certificats LetsEncrypt sur le 1er serveur uniquement. Probablement parce que c’est le plus simple.
Bref, j’ai pas fini de faire des tests…
De plus ma contrainte de ne pas changer les ports d’écoute sur le premier serveur va poser problème puisque haproxy va lui aussi vouloir écouter sur ces ports. Je ne vais peut-être pas pouvoir échapper à la modification habituelle de la config du ou des serveurs web et devoir reprendre ça quand je les installerai dans leur infra définitive…
Et si j’ajoutais un petit Raspberry devant les deux serveurs, avec pour seule mission de router les requêtes HTTP/HTTPS vers les bons serveurs en fonction des domaines ? Du coup le schéma serait plutôt comme ceci :
1 De Nicolas -
Pourquoi as-tu besoin de gérer les certificats sur les deux serveurs ? Si le deuxième serveur n’est qu’interne (accessible en reverse proxy) alors il n’a pas besoin de certificat et n’a pas besoin d’adresse IP publique. Ou alors j’ai lu trop vite et je n’ai pas compris.
2 De Franck -
J’attendais cette question :-)
Parce que ce n’est pas la configuration finale de ces deux serveurs qui vont migrer prochainement au taf où la config est complètement différente — je n’ai pas de problème d’IP unique par exemple.
En attendant qu’ils migrent, je m’occupe de les configurer ici, en tv-travail, derrière une IP unique et j’ai pas envie de me retaper toute la config quand j’irai les installer au taf.
3 De Franck -
Pour résumer, les requêtes HTTP(s) destinées au 1er (nextcloud) restent sur le serveur ou est installé haproxy, tout le reste (80/443) est routé vers le second.