Projet PAINS : Caddy | partie 11

Salutations,

Après plusieurs jours sans article sur ce projet PAIN, je reviens en force. Le prochain article sera sur le côté matériel, puisqu'il y a eu de gros changements dont on parlera plus tard.
Là, on va parler de reverse proxy.

Cela fait 2 jours que j'y suis car sur internet, je n'ai pas trouvé d'informations croustillantes pour bien savoir comment faire, avec quoi et des comparaisons entre les solutions. Mais à force de déterrer des sites WEB et des vidéos de quelques années, on trouve ce qu'on cherche. 

Donc après avoir trouvé plusieurs solutions possibles, comme HA-proxy, NMP, Nginx ou Apache2 avec des plugins... Mon choix s'est porté sur Caddy2.

J'aurais voulu une interface graphique, mais si la gestion des certificats est automatique, pas grave si on a pas d'interface.

Donc on va installer ça.
Leur documentation est plutôt fun à lire, même si Google m'a aussi un peu aidé.

On commence par installer une LXC Debian13 :

Ensuite on suit la documentation : 

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
chmod o+r /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install caddy

Et on peut faire les configurations. On a plein de façons de configurer, c'est incroyable, mais on va s'aider de cette documentation :

On se rend dans le fichier /etc/caddy/Caddyfile et on écrit la syntaxe suivante pour que le reverse proxy puisse fonctionner :

sous.nomDE.domaine {
        reverse_proxy 192.168.x.x
}

et on fait ça pour chaque service.

Et puis sur OPNsense et la box Orange, il faut aussi rediriger les ports 80 et 443 vers notre petit Caddy.

Sauf que j'ai un souci.
Ma box orange ne veut pas faire de la translation d'adresse sur les ports 443 et 80.
Au début je pensais à un conflit avec un autre appareil ou un des mes services existants. Mais non. 
Donc la solution : 

Sur la box, on redirige le port 443 et 80 sur un autre port ( dans mon exemple, 2502 et 2503 ), puis sur OPNsense on remet les ports à leur valeur originale. ça n'a aucun sens mais ça marche. 

Maintenant on arrive à un deuxième souci, mais plus logique.

On avait, par le passé, mis en place un service pour avoir une mesure du débit internet. Je l'avais laissé en HTTP, n'ayant pas de données sensibles, puis laissé vivre sa vie. En mettant en place Caddy, il a fait une superbe chose : 

Il l'a mis tout seul en HTTPS avec un certificat Let's Encrypt.
Superbe, ça montre que tout fonctionne automatiquement, et plus besoin des bidouilles passées...

Mais qu'en est-il des sites étant déjà HTTPS ?
Ça marche mais pas entièrement...

Le souci c'est que , comme l'indique l'erreur , on se connecte bien HTTPS, mais la requête de Caddy sur notre Nextcloud est faite en HTTP. Donc Nextcloud lui répond ça, et donc nous répond ça aussi.
Donc il faut mettre nextcloud en HTTP et lui préciser que pour l'atteindre, il y a du HTTPS à un moment donné. Et faire ça pour les autres services.

Donc on va laisser la CMD de caddy de côté pour aller voir celle de Nextcloud.

On se dirige dans /etc/apache2/sites-enabled/LeBonFichierDe.conf et on retire les lignes SSL :

Nous allons ensuite dans /var/www/nextcloud/config/config.php , et allons rajouter en 'trusted_domains' le nom de domaine qu'on lui à attribué

On rajoute aussi ces deux lignes : 

L'ip étant celle de notre reverse proxy

et ça fonctionne ! 

Maintenant, pareil pour le pufferpanel, on retire les lignes du SSL. Et c'est tout.
Pour rustdesk, c'est un peu plus spécial, donc on n'y touchera pas.

Caddy fonctionnant aussi avec les API, on pourrait voir par la suite, de modifier la config en temps réel pour, par exemple, rediriger vers une page maintenance, quand un des services est en... maintenance.
Mais ce sera pour un prochain épisode, sûrement au moment où je mettrais en place mon système de monitoring.
Le prochain article sera plus "physique" pour ensuite passer sur le déplacement de ce site web, des DNS du nom de domaine et de la mise en place de syncthing ( ou équivalent ).

Bonne soirée !