Exposer mes services, derrière du CGNAT sans Cloudflare
Mars 2025
A la maison, sur mon serveur Proxmox, j'héberge plusieurs VMs qui servent ce blog, une page web pour un futur projet, mon microblog, mon espace Nextcloud, mon agrégateur de flux RSS et une instance BorgBackup pour héberger des sauvegardes d'amis proches.
Quand tout va bien, grâce à ma connexion fibre et mon adresse IPV4 publique, il m'est possible d'exposer très facilement tous ses services en liant mes sous-domaines à mon IP offerte par ma LiveBox :
Or, lorsque cette fibre tombe en panne, je dois utiliser une connexion 4G de secours, qui elle, ne m'offre pas d'IPV4 publique en direct ! Ma connexion 4G partage une seule IPV4 publique avec toute une ribambelle d'autres clients 4G grâce à ce qu'on appelle le CGNAT. Ce mécanisme ne me permet pas d'exposer mes services, je devais trouver alors une solution de contournement.
La solution, simple, rapide, gratuite, c'est de mettre en place un tunnel Cloudflare. J'installe un client sur mon serveur principal, je confie la gestion de mes domaines à Cloudflare, je configure un tunnel et je peux de nouveau exposer mes services.
Sauf que Cloudflare c'est la lave 🌋 puisqu'il est en passe de devenir le premier proxy et gendarme du web, on lui donne un pouvoir sans précédent pour contrôler le traffic mondial : il peut décider d'autoriser telle ou telle connexion sous couvert de protéger contre les attaques DDOS, de filtrer les contenus CSAM et de bloquer des logiciels malveillants... mais comme d'habitude, confier une telle mission à un acteur privé, c'est échanger la sécurité contre la liberté : demain Cloudflare deviendra un méga gendarme de la toile qui aura le droit de te donner accès à tel ou tel service en ligne seulement si tu corresponds à ses critères. Il pourrait couper l'accès aux navigateurs tierces, à des smartphones qu'il juge obsolète, à certains systèmes d'exploitation, à certaines adresse IP ou pays... bref je n'ai pas envie d'alimenter cette machine.
Alors il était devenu évident pour moi que je devais me passer d'une telle solution. Je voulais apprendre à configurer mon propre proxy, à la demande, sans avoir recours à un tel acteur : donc pas de VPN ni d'alternatives à Cloudflare comme Tailscale ou autres. Je savais que c'était possible notamment en utilisant un VPS et en configurant un tunnel SSH. Mais je ne maîtrisais pas du tout le sujet et je n'avais que vaguement lu quelques commentaires sur le net. Jusqu'à ce que je prenne le taureau par les cornes en supprimant mon compte Cloudflare et en faisant mes recherches sur le net. C'est là que j'ai trouvé les 4 ressources qui m'ont permis d'atteindre mon objectif :
- How to access a Linux server behind NAT via reverse SSH tunnel
- How to use a Reverse SSH tunnel to reach a server behind a NAT
- Roll your own Ngrok with Nginx, Letsencrypt, and SSH reverse tunnelling
- SSH Reverse Tunneling
C'est la source N°3 qui donne une vraie vue d'ensemble pour ce que je souhaitais faire et qui m'a conforter dans le fait que c'était possible puisque ma configuration actuelle correspond exactement à la situation décrite dans son article.
Ma VM principale fait tourner un NGINX configuré pour router, en fonction des sous-domaines, les requêtes vers les bons services. Les certificats SSL sont gérés grâce au plugin qui va bien avec Certbot. Ainsi je remplissais déjà les pré-requis pour qu'un "SSH reverse Tunneling" fonctionne. Il ne me manquait plus qu'à :
- Configurer un VPS
- J'ai choisi de prendre une droplet sous Debian 12, hébergée sur un serveur en Allemange via DigitalOcean
- J'ai modifié la configuration du fichier /etc/ssh/sshd_config pour y mettre GatewayPorts à yes
- Rediriger mes domaines vers l'IP publique du VPS
- J'ai configuré ce qu'il fallait dans mon gestionnaire OVHCloud
- Ouvrir un tunnel SSH depuis ma VM principale
- Avec la ligne de commande ssh -fN -R 443:localhost:443 root@[IPV4 Publique VPS]
Et comme par magie, juste avec l'aide de SSH, je pouvais continuer à utiliser mes services en HTTPS en passant depuis mon propre proxy, sans Cloudflare :
