En ce début d’année, je me suis mis en tête de me refaire un petit lab autohébergé avec quelques services pour mon usage personnel. L’idée était de pouvoir créer des VM à la volée, mais surtout d’exposer de façon sécuriser des services web sur internet 🪄
Les challenges de l’exposition sur Internet #
La principale difficulté à laquelle nous sommes confrontés quand on souhaite faire de l’autohébergement, c’est l’exposition de nos services sur Internet. Nous devons faire face à quelques problématiques réseaux et sécurité pour nous protéger de la jungle d’internet.
C’est un secret pour personne, nous sommes en pénurie d’ipv4 en Europe. C’est pourquoi de nombreux opérateurs télécom n’attribuent plus une adresse IP par box, mais préfère recourir au NAT. Ils partagent ainsi une IP pour plusieurs clients. Cette IP est souvent dynamique et peut changer au redémarrage de votre box internet. Pas très pratique pour faire pointer un nom de domaine vers votre réseau. On s’expose aussi aux risques d’attaques DDoS qui satureront rapidement votre bande passante.
Le deuxième inconvenant est la mise en place du port forwarding. Il faut créer des règles réseau en ouvrant des ports vers l’extérieur sur sa box, et rediriger les flux entrant vers notre serveur. L’opération n’est pas complexe, mais doit être réitérée en cas de changement de box ou d’opérateur.
Enfin, nous aurons besoin de certificats TLS signés par une autorité de certification pour supporter HTTPS. Sans ça, les appareils qui se connecteront à nos services afficheront des messages d’alertes. Pas très sexy le gros warning rouge quand on visite votre blog 🥲
Et c’est pourquoi j’utilise les Cloudflare Tunnels⚡
Le service tunnel propose de créer des tunnels sécurisés entre votre serveur et les infrastructures de Cloudflare en répondant à toutes les problématiques cités précédemment. Plus besoin d’ouvrir de ports, le tunnel passe à travers votre box et expose seulement le trafic que vous lui autorisez de router.
Mise en place #
Je vais partir du principe que vous avez déjà un nom de domaine configuré vers Cloudflare, un projet Zero Trust et une machine tournant sous linux. Dans mon cas j’utiliserai mon serveur sous debian 11.
La première étape consiste à installer le client cloudflared pour la mise en place du tunnel. Nous ajoutons la clef GPG puis le dépôt Debian. Enfin, nous installons le paquet avec apt.
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared bookworm main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install -y cloudflared
Une fois l’utilitaire installé, nous activons le service systemd et le lançons.
sudo systemctl enable --now cloudflared
La suite se passe sur la console Cloudflare. Nous sélectionnons le domaine que l’on souhaite utiliser.
Puis nous nous rendons sur la page Access, puis dans la console Zero Trust.
Dans la console Zero Trust, nous nous rendons dans la section Tunnels.
Et nous créons un tunnel. À la fin de l’opération, nous obtenons une commande à utiliser sur notre serveur pour l’activer.
Le tunnel est désormais actif. Maintenant, il ne nous reste plus qu’à choisir le flux que nous souhaitons rediriger vers le tunnel. Nous pouvons d’ailleurs mettre en place plusieurs redirections dans un seul tunnel 🔥. Dans mon cas je souhaite exposer une instance d’uptime kuma exposé en local sur le port 4002.
Et voila, c’est déployé ! 🙌
Quelques inconvénients #
Malgré le côté magique des tunnels proposés par Cloudflare, il faut néanmoins soulever quelques points assez importants qui peuvent vous faire hésiter à leur utilisation.
Le premier est l’obligation de configurer votre domaine pour utiliser Cloudflare comme fournisseur de DNS. De facto, Cloudflare devient ainsi un maillon important de votre infrastructure dont vous ne pourrez pas échapper. Il n’est pas possible de donner seulement le contrôle d’un sous domaine mais requière une délégation complète du domaine.
Le deuxième point est l’aspect déchiffrement du trafic. Les tunnels Cloudflare agissent comment un reverse proxy et gèrent. De plus, l’entreprise étant américaine elle est soumis aux lois extraterritoriale. Cela permet au gouvernement américain de pouvoir demander l’accès aux données transitant par leur serveurs. Pas très rassurant😬
Un dernier point un peu gênant pour mes usages est le non support du protocole UDP. Pour le moment ce n’est pas grave, mais ça peut être un point bloquant pour héberger des services non web comme des serveurs de jeu vidéo utilisant UDP. On peut aussi prévoir l’arrivé de HTTP/3 et du protocole QUIC rendant UDP nécessaire.
La suite #
Pour le moment, je suis plutôt satisfait de ce setup et j’aime beaucoup les services de Cloudflare. Leur blog tech est d’ailleurs très cool à suivre avec une bonne dose d’ingénierie et de l’open source.
À termes, je souhaite me séparer de leurs services en utilisant un VPS que j’administrerai. Il existe énormément d’outils pour créer des tunnels entre serveurs. L’idée serait d’utiliser Caddy comment point de terminaison TLS. Puis d’envoyer le trafic à travers internet en utilisant un tunnel chiffré utilisant du NAT Traversal pour joindre le serveur hébergé à la maison.
En ce moment je commence à regarder quel outil simple serai optimal pour mon usage. J’utilise aussi Tailscale pour garder un accès SSH d’un peu partout, mais dans un réseau overlay privé. J’ai reçu plusieurs recommandations pour tester Zrok, mais ça c’est pour un prochain épisode 😄
Merci à Quentin, Sébastien et Nicolas pour leur relecture attentive 📝
