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).

1. 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.
2. 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
   
3. 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
   
4. 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.

1. 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.

2. 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.

3. 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

4. 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.

1. 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.

2. Redémarrer le service SSH sur le VPS :
   sudo systemctl restart sshd
   
3. É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.

4. 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.

1. 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).
2. 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.

1. 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

2. 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.

La grande mode du moment, c’est l’AI générative ou LLM pour Large Language Model. Je suis bien sûr très intéressé par ces applications, tant en termes de génération de texte ou d’image pour des usages pro (résumé, mails, génération de modèles, programmation) et persos (jeu de rôle). Pour cela, on peut utiliser les classiques et plus connus Midjourney ou ChatGPT ou se tourner vers l’open-source et ses bienfaits. Cet article se base principalement sur une vidéo de NetworkChuck que je vous invite à visionner (en anglais), et à diverses informations rassemblées sur le net.

Petit disclaimer : je suis parfaitement conscient de l’impact que ces technologies peuvent avoir sur les métiers de création, illustrateurs, traducteurs, ou autres. Je sais aussi comment sont nourris les modèles de données, la plupart du temps sans considération ni rémunérations pour les auteurs (dont je suis parfois), et c’est un problème grave dont il faut s’occuper dès maintenant. Je n’encourage pas le commerce de produits générés par IA, livres ou images. Je ferai peut-être ultérieurement un article plus complet sur mon positionnement.

---

Matériel

Contrairement à ce que dit la vidéo de NetworkChuck, pas besoin d’une machine de guerre à base de double RTX 4090 et je ne sais combien de RAM. Vous aurez des résultats parfaitement satisfaisants avec une machine relativement récente. Par contre, une carte graphique Nvidia me semble obligatoire. C’est elle qui fera les calculs, et plus elle sera puissante, plus les retours seront rapides. Le système peut toutefois tourner sur CPU uniquement.

Personnellement j’ai une RTX 4070 12 Go, mais une génération précédente fera parfaitement l’affaire. Idem, n’importe quel processeur un peu récent ira bien.

Par contre, si vous ne disposez que d’un laptop ou un minipc, je ne garantis pas le résultat.

WSL

La plupart des programmes et commandes fonctionnent sur tous les systèmes, mais je trouve que le plus simple c’est Wsl, la version Windows de Linux.

On commence par l’activer en lançant la commande suivante dans le terminal de Windows.

wsl --install

Ca ne prend que quelques minutes.

Si vous utilisez le Terminal de Windows, vous aurez automatiquement une nouvelle entrée.

Cliquez dessus pour ouvrir une session Ubuntu.

Il vous demandera un nom d’utilisateur et un mot de passe, puis vous aurez accès à la ligne de commande.

Ubuntu + Docker

Commencez par mettre à jour Ubuntu avec les commandes suivantes :

sudo apt update && sudo apt upgrade

Puis installez Docker

sudo apt install docker.io

Tout est prêt !

Ollama

Ollama est un outil permettant de télécharger et d’utiliser n’importe quel modèle de données disponibles en open-source (et gratuitement) sur le site de Huggin Face, la principale communauté AI. C’est un serveur qui tourne en arrière-plan et qui peut être utilisé en ligne de commande ou via une interface Web qu’on installera juste après.

Pour l’installer, tapez la commande suivante :

curl -fsSL https://ollama.com/install.sh | sh

Au bout de quelques minutes, vous aurez accès à l’application.

Téléchargez un modèle, je suggère le plus puissant du moment, avec un excellent rapport taille/qualité, Llama3

ollama pull llama3

Attention, c’est un fichier de 5Go, la vitesse dépend de la qualité de votre ligne.

Pour tester :

ollama run llama3

Yeah \o/

OpenWeb UI

C’est un logiciel qui donne une interface graphique à Ollama, ressemblant fortement à celle de ChatGPT ou you.com. On peut télécharger des modèles, discuter avec eux, uploader des fichiers pour les interroger et faire plein de choses cools.

Pour l’installer (toujours dans notre session Ubuntu)

docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main

La commande peut faire peur, mais elle dit juste que l’application doit tourner dans docker, que l’image s’appelle open-webui et que le serveur ollama tourne en local. Rien de foufou ou de dangereux.

Comme pour les précédentes commandes, il va télécharger ses fichiers et tout lancer tout seul.

Pour savoir si cela fonctionne, lancer votre navigateur préféré et faites le pointer sur :

http://localhost:8080

Dans le menu du haut, vous pouvez choisir vote modèle (llama3).

Dans le chat du bas, vous pouvez taper votre question ou demande pour commencer à l’utiliser.

Vous pouvez aussi cliquer sur le petit + en bas à gauche pour envoyer un fichier pour l’interroger. Ça marche avec du texte, mais par la suite, on pourra envoyer une image pour lui faire décrire un prompt qu’on enverra ensuite dans Stable Diffusion.

Le micro permet d’envoyer du son qui sera analysé par Whisper et transformé en texte.

Enfin, les résultats peuvent être lus par une voix synthétique en un clic, je vous montre ça après.

Conclusion de la partie 1

En quelques commandes, on a installé un système complet, accessible facilement, quasiment aussi puissant que le dernier ChatGPT. Si un modèle plus puissant sort en open-source, il sera rendu disponible dans l’application en une commande (ou quelques clics dans l’interface).

Dans la partie 2, nous installerons les autres outils et nous verrons comment les utiliser et les faire échanger entre eux.

J’ai un laptop dell de ce modèle qui a été préinstallé avec plein de crapware. J’ai pas mal de souci avec et j’ai décidé de tout réinstaller. Cet article est là pour m’aider le jour où je voudrais le refaire.

BIOS / Driver disque dur

Par défaut le disque dur n’est pas visible par l’installateur de Windows, même dans sa version 11. Il est possible pendant l’installation d’utiliser les drivers trouvables sur le site du support de Dell si on les a mis sur la clé USB d’installation. Cela dit, si le système voit que le disque principal n’est pas le premier (0) alors il refusera de s’installer.

Une astuce est de passer dans le Bios pour changer la manière dont le disque est géré, pour passer de RST (une espère de Raid dont je ne comprends pas bien l’interêt) à AHCI/NVME.

Une fois relancé, l’installeur de Windows retrouve sans problème ses petits et accepte de s’installer.

Pour accéder au Bios => F12 pendant le démarrage pour accéder aux options de boot puis il y a un lien vers le bios lui-même. Il faut aller dans Stockage, puis cliquer sur AHCI/NVME.

Rebooter, F12 de nouveau, puis booter sur la clé USB d’installation.

Astuce : decrap

Windows installe des tas de crapwares par défaut, notamment des pubs, des liens vers des applis ou des jeux. Cette action est dépendante de l’endroit choisi lors de l’installation.

Pour réduire ces installations malvenues, il faut indiquer à l’installeur la région : « Anglais (International) ».

De là, il va continuer, puis mettre un message d’erreur.

Il faut cliquer sur Ignorer puis terminer l’installation normalement.

Astuce : Compte local

Windows 11 nous fait bien galérer et tente de nous obliger à se connecter avec un compte MS.

Pour éivter cela, il faut débrancher son câble éthernet, ou couper la connexion Wifi si elle est active, puis cliquer sur : « Je n’ai pas internet » et « Continuer avec un compte limité ».

J’ai récupéré récemment un vieux HP ProDesk 400 G3, un mini PC format 1L anciennement utilisé comme machine de bureau. Après l’avoir un peu boosté avec de la RAM (passage à 16Go), j’ai fait quelques tests dessus, et s’il est difficilement utilisable en mode bureau (processeur faiblard, disque dur mécanique), il est beaucoup plus intéressant en mode serveur. Voulant le mettre dans un coin avec le moins de câble possible, j’ai voulu y coller ma clé Wifi Archer T3U, évidemment sans driver Linux. Ma procédure précédente ne fonctionnant pas, j’ai de nouveau cherché et trouvé une solution pour la faire fonctionner, le tout en ligne de commande, sous le très récent Débian 12.

---

Installation Debian 12

J’ai installé une Debian 12 toute fraiche en téléchargeant un ISO netinstall. Pas d’interface graphique, juste un serveur SSH et basta.

Comme précédemment, le driver sera compilé à partir d’un dépôt git. Donc j’installe tous mes outils, git, sudo (non installé par défaut dans debian), module-assistant, lshw (pour vérifier le matériel). La compilation m’ayant fait une erreur, j’ai dû aussi installer le paquet dkms.

Je vérifie avec un lsusb que la clé est bien reconnue par la machine.

Elle apparait bien, première étape ok.

Compilation du module

Ensuite récupération du code puis compilation et installation. Source de la méthode.

sudo m-a prepare
git clone https://github.com/RinCat/RTL88x2BU-Linux-Driver
cd RTL88x2BU-Linux-Driver
make
sudo make install
sudo modprobe 88x2bu

Pour vérifier que le matériel est maintenant correctement piloté, j’utilise la commande lshw

La commande ip link show donne aussi un bon résultat.

Je note le nom de l’interface (wlxd03745a8f9ca) pour la suite.

Configuration du réseau

Source de la méthode

J’ai choisi d’utiliser l’outil iwd qui me semble très simple à mettre en place.

J’installe le paquet iwd puis j’ouvre le fichier de configuration pour décommenter la ligne permettant à iwd de configurer automatiquement le réseau (EnableNetworkConfiguration).

Il faut maintenant lancer le service iwd et l’activer pour que le wifi survive à un redémarrage.

systemctl --now enable iwd

Accéder au wifi

J’utilise la commande iwctl en mode interactif et en utilisateur.

iwctl

La commande help permet de voir toutes les instructions possible.

Pour ma part :

station wlxd03745a8f9ca scan
station wlxd03745a8f9ca get-networks
station wlxd03745a8f9ca connect <réseau>

Il va demander le mot de passe du réseau. Puis, vous pouvez sortir avec exit.

La commande : ip a, vous permet de voir si l’interface a bien récupéré une adresse ip en DHCP.

Pour un serveur, il est plus pratique d’utiliser des adresses ip statiques, mais je préfère les gérer de manière centralisée sur mon DHCP en définissant un bail statique.

Conclusion

La méthode me paraît beaucoup plus simple à mettre en place, surtout dans un contexte sans interface graphique et j’avoue avoir fait une bonne découverte avec iwd qui gère très facilement le réseau en cli.

Si vous n’arrivez pas à vous connecter après la procédure, ou si vous n’avez pas récupéré d’ip, essayez de relancer le service (sudo systemctl restart iwd) ou de redémarrer la machine (ce que j’ai dû faire).

Dans mon nouveau boulot, en attendant un recrutement spécifique, je me retrouve à faire de l’administration système, notamment sur Microsoft 365. L’outil est extrêmement efficace en entreprise et permet un travail collaboratif très étendu. Cela dit, les outils d’admin sont une plaie absolue, ou rien n’est cohérent. Si pour les utilisateurs, le boulot est fait, en arrière-plan c’est un enfer. Par exemple, il n’y aucune option nulle part pour récupérer simplement les membres d’une liste de distribution. Sauf en powershell…

---

Installation des outils

• On ouvre évidemment un terminal Powershell en mode administrateur.
  À chaque fois qu’il demande une validation, vous dites Oui [O] bien sûr, sinon ça marche pas.

Install-Module PowershellGet -Force
Install-Module -Name ExchangeOnlineManagement

• On active l’exécution des scripts qui n’est pas possible par défaut.

Set-ExecutionPolicy RemoteSigned

• On importe le module Exchange.

Import-Module ExchangeOnlineManagement

• Enfin, on se connecte

Connect-ExchangeOnline

Là ça ouvre une page web où vous pouvez mettre votre login et mot de passe.
C’est possible uniquement si vous êtes admin hein.
Si ça marche, vous allez tomber sur ça :

Action

Maintenant c’est tout con :

Get-DistributionGroupMember -Identity « <le nom de la liste » | Select-Object -Property « DisplayName », »PrimarySmtpAddress » | Export-Csv c:\liste.csv

Le GetDistributionGroupMember fait ce qu’il dit, il récupère l’intégralité des membres, avec toutes leurs informations.

Le Select-Objet permet de réduire les champs à uniquement le nom et l’adresse. Faite un test sans cette commande, puis ouvrez le fichier généré pour voir la liste des champs. Y’en a plein.

Enfin, l’Export-Csv balance l’ensemble dans un fichier ouvrable par n’importe quel tableur.

Conclusion

Ce n’est pas très compliqué, mais ce n’est pas pratique. Il doit probablement y avoir des outils qui lancent ces commandes en arrière-plan, des trucs qui ne viennent pas de MS, mais je ne les connais pas. Si vous avez des connaissances dans ce sujet, je serai ravi de les connaitre.