Lorsque la connexion Internet principale tombe et que la seule alternative est une liaison de secours limitée, comme un partage de connexion 5G, qui ne permet pas la redirection de ports entrants, comment maintenir l’accès aux services autohébergés ? Cet article détaille une méthode technique pour rétablir l’accès externe à l’infrastructure interne en utilisant un tunnel SSH inversé via un serveur intermédiaire (VPS) et en reconfigurant temporairement le réseau local pour utiliser la connexion de secours.
Le Problème : Perte de Redirection de Ports
Dans une configuration classique d’auto-hébergement, votre routeur principal redirige les requêtes entrantes (sur les ports 80, 443, etc.) depuis Internet vers les machines appropriées de votre réseau local. Lorsqu’une coupure survient et que vous basculez sur une connexion de secours via un téléphone (partage de connexion USB ou Wi-Fi), cette nouvelle connexion ne permet généralement pas de configurer ces redirections de ports. Votre réseau interne peut accéder à Internet, mais Internet ne peut plus initier de connexions vers votre réseau.
La Solution : Tunnel SSH Inversé via un VPS Relais
La méthode que nous allons décrire contourne cette limitation en inversant le flux de connexion. Au lieu que l’extérieur se connecte directement à votre réseau, une machine de votre réseau interne va initier une connexion sortante sécurisée (un tunnel SSH) vers un serveur externe (un VPS) disposant d’une IP publique statique. Ce VPS servira de point de relais : il écoutera les requêtes entrantes de l’extérieur sur les ports standard (80, 443) et les transmettra à votre réseau interne à travers le tunnel SSH déjà établi.
Chapitre 1 : Rétablir la Connectivité Internet Locale
La première étape est de s’assurer que votre réseau interne puisse accéder à Internet via la connexion de secours (le téléphone 5G).
- Brancher le téléphone et activer le partage de connexion : Connectez votre téléphone à une machine de votre réseau interne (dans cet exemple, ma machine proxmox avec l’IP 192.168.1.3) via USB et activez le partage de connexion. Un nouveau périphérique réseau (souvent nommé usb-tether ou similaire) devrait apparaître sur la machine interne.
- Activer l’interface réseau : Activez la nouvelle interface si elle ne l’est pas automatiquement.
sudo ifup usb-tether
Attention, le nom de l’interface réseau va changer à chaque connexion du téléphone. C’est super relou, et j’ai du batailler un peu pour avoir un nom fixe (usb-tether). Google est votre ami.
Vérifiez que l’interface a obtenu une adresse IP du téléphone :
ip a - Activer le forwarding IP : Pour que la machine interne puisse router le trafic des autres machines du réseau, le forwarding IP doit être activé.
sudo nano /etc/sysctl.conf
Décommentez ou ajoutez la ligne suivante :
net.ipv4.ip_forward=1
Appliquez la modification sans redémarrer :
sudo sysctl -p - Configurer la traduction d’adresses réseau (NAT) : Les paquets provenant de votre réseau local (192.168.1.0/24) doivent être réécrits avec l’adresse IP de la machine interne sur l’interface usb-tether avant de sortir.
sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o usb-tether -j MASQUERADE
- -t nat : Spécifie la table NAT.
- -A POSTROUTING : Ajoute une règle à la chaîne POSTROUTING (appliquée juste avant que le paquet ne quitte la machine).
- -s 192.168.1.0/24 : Source des paquets (votre réseau local).
- -o usb-tether : Interface de sortie (celle du téléphone).
- -j MASQUERADE : Action de masquerade (NAT dynamique utilisant l’IP de l’interface de sortie).
À ce stade, la machine interne peut accéder à Internet via le téléphone.
Chapitre 2 : Rerouter le Réseau Local
Maintenant que la machine interne a une connexion Internet fonctionnelle, il faut indiquer aux autres machines du réseau d’utiliser cette machine comme passerelle par défaut.
- Modifier la passerelle par défaut via DHCP : Votre serveur DHCP (chez moi, dnsmasq sur 192.168.1.1) attribue normalement la passerelle par défaut. Modifiez sa configuration pour qu’il distribue l’adresse IP de la machine interne (192.168.1.3) comme passerelle.
Connectez-vous en SSH à votre serveur DNS/DHCP :
ssh utilisateur@192.168.1.1
Éditez le fichier de configuration de dnsmasq :
sudo nano /etc/dnsmasq.conf
Trouvez la ligne dhcp-option=3,… et modifiez-la :
dhcp-option=3,192.168.1.3
- dhcp-option=3 : Spécifie l’option DHCP pour la passerelle par défaut (router).
- 192.168.1.3 : La nouvelle adresse IP de la passerelle.
- Appliquer la nouvelle passerelle sur les clients : Les machines clientes doivent renouveler leur bail DHCP pour obtenir la nouvelle adresse de passerelle.
- Sur Linux : Redémarrez le service réseau ou utilisez sudo dhclient -r && sudo dhclient.
- Sur Windows : Ouvrez une invite de commande et exécutez ipconfig /renew.
- Sur macOS : Désactivez puis réactivez l’interface réseau dans les paramètres.
- Vérifier la nouvelle passerelle : Sur une machine cliente, vérifiez que la passerelle par défaut est bien 192.168.1.3.
- Sur Windows : ipconfig /all
- Sur Linux/macOS : ip r ou netstat -rn
- Tester la connectivité externe : Vérifiez que les machines du réseau peuvent accéder à Internet.
- Tester un ping direct (sans résolution DNS) :
ping 1.1.1.1 - Tester un ping avec résolution DNS :
ping www.google.fr
Si ces pings fonctionnent, tout le réseau utilise maintenant la connexion de secours pour sortir.
Chapitre 3 : Créer le Tunnel Inversé
Maintenant que le réseau interne peut communiquer vers l’extérieur, nous allons établir un tunnel SSH inversé depuis la machine interne vers votre VPS externe.
- Préparer le VPS pour le tunnelling SSH : Connectez-vous en SSH à votre VPS externe.
ssh utilisateur_vps@adresse_ip_publique_vps
Éditez le fichier de configuration du démon SSH :
sudo nano /etc/ssh/sshd_config
Assurez-vous que les lignes suivantes sont présentes et activées :
AllowTcpForwarding yes
GatewayPorts yes
- AllowTcpForwarding yes : Autorise les redirections de ports.
- GatewayPorts yes : Permet de lier le port redirigé à l’adresse IP publique du VPS, le rendant accessible depuis Internet (et pas seulement depuis le VPS lui-même).
Note sur les ports 80/443 et PermitRootLogin : Tenter de lier directement les ports 80 et 443 avec un tunnel SSH inversé peut échouer si un autre service (comme un serveur web) écoute déjà sur ces ports, ou si l’utilisateur SSH n’a pas les permissions suffisantes (ports < 1024 nécessitent root). Si vous recevez des messages d’erreur (Warning: remote port forwarding failed for listen port…), cela indique probablement un conflit de port ou un problème de permission.Si vous devez lier directement 80/443 et que vous êtes certain qu’aucun autre service ne les utilise, vous pourriez tenter d’établir la connexion SSH en tant que root sur le VPS. Cela nécessite d’autoriser la connexion root via SSH, ce qui est fortement déconseillé pour des raisons de sécurité. Si vous choisissez cette voie temporairement, modifiez sshd_config sur le VPS :PermitRootLogin yes
N’oubliez pas de désactiver PermitRootLogin yes et de redémarrer sshd une fois le dépannage terminé ou si vous optez pour la méthode du proxy inverse (recommandée). La méthode la plus propre est d’utiliser un port différent pour le tunnel et un proxy inverse sur le VPS.
- Redémarrer le service SSH sur le VPS :
sudo systemctl restart sshd - Établir le tunnel inversé depuis la machine interne : Connectez-vous depuis la machine interne vers le VPS en demandant la redirection des ports 80 et 443 du VPS vers l’IP et les ports de votre proxy inverse interne (ici, 192.168.1.2:80 et 192.168.1.2:443).
ssh -i <chemin_vers_votre_cle_ssh>.pem -N -T -R 80:192.168.1.2:80 -R 443:192.168.1.2:443 utilisateur_vps@adresse_ip_publique_vps
- -i <chemin_vers_votre_cle_ssh>.pem : Spécifie la clé privée SSH à utiliser (recommandé pour l’automatisation).
- -N : Ne pas exécuter de commande distante.
- -T : Désactiver l’allocation d’un pseudo-terminal.
- -R <Port_Externe>:<IP_Interne>:<Port_Interne> : Configure la redirection inversée. Le trafic arrivant sur <Port_Externe> du VPS est redirigé vers <IP_Interne>:<Port_Interne> via le tunnel.
- utilisateur_vps@adresse_ip_publique_vps : Les informations de connexion au VPS.
Si vous avez utilisé PermitRootLogin yes et que vous vous connectez en root :ssh -i <chemin_vers_votre_cle_ssh>.pem -N -T -R 80:192.168.1.2:80 -R 443:192.168.1.2:443 root@adresse_ip_publique_vps
La connexion en root n’est pas très sécurisée, mais c’est ce qui permet d’ouvrir les ports <1024 sans autre étapes techniques. En vrai, il faudrait plutôt passer par un reverse proxy sur le VPS. Mais je voulais aller vite.
- Maintenir le tunnel actif : La commande ssh seule se terminera si la connexion est interrompue. Utilisez autossh pour redémarrer automatiquement le tunnel.
autossh -M 0 -N -T -R 80:192.168.1.2:80 -R 443:192.168.1.2:443 utilisateur_vps@adresse_ip_publique_vps
Configurez autossh en tant que service systemd sur la machine interne pour qu’il démarre automatiquement au boot.
Chapitre 4 : Modifier le DNS Externe
Pour que vos noms de domaine pointent vers votre VPS qui sert de relais, vous devez modifier vos enregistrements DNS externes.
- Accéder à la gestion DNS : Connectez-vous à l’interface de gestion DNS chez votre registrar (là où vous avez acheté votre nom de domaine memoiresecondaire.fr).
- Modifier les enregistrements A/AAAA : Modifiez l’enregistrement A (pour IPv4) et éventuellement AAAA (pour IPv6) pour votre domaine principal (memoiresecondaire.fr) et pour les sous-domaines (l’enregistrement wildcard *.memoiresecondaire.fr est idéal ici) pour qu’ils pointent vers l’adresse IP publique de votre VPS.
- Type : A
- Nom : * (pour le wildcard, couvre tous les sous-domaines)
- Valeur : <adresse_ip_publique_du_vps>
- Type : A
- Nom : @ (pour le domaine principal lui-même)
- Valeur : <adresse_ip_publique_du_vps>
Les modifications DNS peuvent prendre un certain temps à se propager sur Internet (propagation DNS).
Chapitre 5 : Vérification
Une fois toutes les étapes précédentes effectuées, vous devriez pouvoir accéder à vos services depuis l’extérieur.
- Vider le cache DNS local : Sur la machine externe depuis laquelle vous testez l’accès, videz le cache DNS pour vous assurer qu’elle utilise les nouvelles informations DNS.
- Sur Windows : Ouvrez une invite de commande et exécutez ipconfig /flushdns.
- Sur Linux : sudo systemd-resolve –flush-caches ou redémarrez le service réseau.
- Sur macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Tester l’accès via le navigateur : Ouvrez un navigateur et essayez d’accéder à un de vos services en utilisant son nom de domaine complet, par exemple jellyfin.memoiresecondaire.fr. La requête devrait maintenant passer par l’IP de votre VPS, traverser le tunnel SSH, atteindre votre proxy inverse interne, et finalement votre service.
Conclusion
Cette méthode, bien que nécessitant plusieurs étapes de configuration (rétablissement de la connexion de secours, reroutage du réseau local, mise en place du tunnel SSH inversé et mise à jour DNS), offre une solution efficace pour maintenir l’accès externe à votre infrastructure auto-hébergée même en cas de défaillance de votre connexion Internet principale et de l’impossibilité de rediriger les ports. Elle s’appuie sur des technologies standard (SSH, iptables, DNS) et un minimum de ressources externes (un petit VPS), vous donnant un contrôle total sur le processus. N’oubliez pas de revenir à votre configuration réseau et DNS d’origine une fois que votre connexion Internet principale est rétablie.