{"id":1922,"date":"2025-05-11T18:42:24","date_gmt":"2025-05-11T16:42:24","guid":{"rendered":"https:\/\/www.memoiresecondaire.fr\/?p=1922"},"modified":"2025-05-11T22:18:20","modified_gmt":"2025-05-11T20:18:20","slug":"acces-a-distance-en-cas-de-coupure-tunnel-ssh-et-relais-5g","status":"publish","type":"post","link":"https:\/\/www.memoiresecondaire.fr\/?p=1922","title":{"rendered":"Acc\u00e8s \u00e0 distance en cas de coupure : Tunnel SSH et Relais 5G"},"content":{"rendered":"\n

Lorsque la connexion Internet principale tombe et que la seule alternative est une liaison de secours limit\u00e9e, comme un partage de connexion 5G, qui ne permet pas la redirection de ports entrants, comment maintenir l’acc\u00e8s aux services autoh\u00e9berg\u00e9s ? Cet article d\u00e9taille une m\u00e9thode technique pour r\u00e9tablir l’acc\u00e8s externe \u00e0 l’infrastructure interne en utilisant un tunnel SSH invers\u00e9 via un serveur interm\u00e9diaire (VPS) et en reconfigurant temporairement le r\u00e9seau local pour utiliser la connexion de secours.<\/em><\/p>\n\n\n\n

\n\n\n\n

Le Probl\u00e8me : Perte de Redirection de Ports<\/strong><\/p>\n\n\n\n

Dans une configuration classique d’auto-h\u00e9bergement, votre routeur principal redirige les requ\u00eates entrantes (sur les ports 80, 443, etc.) depuis Internet vers les machines appropri\u00e9es de votre r\u00e9seau local. Lorsqu’une coupure survient et que vous basculez sur une connexion de secours via un t\u00e9l\u00e9phone (partage de connexion USB ou Wi-Fi), cette nouvelle connexion ne permet g\u00e9n\u00e9ralement pas de configurer ces redirections de ports. Votre r\u00e9seau interne peut acc\u00e9der \u00e0 Internet, mais Internet ne peut plus initier de connexions vers votre r\u00e9seau.<\/p>\n\n\n\n

La Solution : Tunnel SSH Invers\u00e9 via un VPS Relais<\/strong><\/p>\n\n\n\n

La m\u00e9thode que nous allons d\u00e9crire contourne cette limitation en inversant le flux de connexion. Au lieu que l’ext\u00e9rieur se connecte directement \u00e0 votre r\u00e9seau, une machine de votre r\u00e9seau interne va initier une connexion sortante<\/em> s\u00e9curis\u00e9e (un tunnel SSH) vers un serveur externe (un VPS) disposant d’une IP publique statique. Ce VPS servira de point de relais : il \u00e9coutera les requ\u00eates entrantes de l’ext\u00e9rieur sur les ports standard (80, 443) et les transmettra \u00e0 votre r\u00e9seau interne \u00e0 travers<\/em> le tunnel SSH d\u00e9j\u00e0 \u00e9tabli.<\/p>\n\n\n\n

Chapitre 1 : R\u00e9tablir la Connectivit\u00e9 Internet Locale<\/strong><\/p>\n\n\n\n

La premi\u00e8re \u00e9tape est de s’assurer que votre r\u00e9seau interne puisse acc\u00e9der \u00e0 Internet via la connexion de secours (le t\u00e9l\u00e9phone 5G).<\/p>\n\n\n\n

    \n
  1. Brancher le t\u00e9l\u00e9phone et activer le partage de connexion :<\/strong> Connectez votre t\u00e9l\u00e9phone \u00e0 une machine de votre r\u00e9seau 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\u00e9riph\u00e9rique r\u00e9seau (souvent nomm\u00e9 usb-tether ou similaire) devrait appara\u00eetre sur la machine interne.<\/li>\n\n\n\n
  2. Activer l’interface r\u00e9seau :<\/strong> Activez la nouvelle interface si elle ne l’est pas automatiquement.
    sudo ifup usb-tether

    Attention, le nom de l’interface r\u00e9seau va changer \u00e0 chaque connexion du t\u00e9l\u00e9phone. C’est super relou, et j’ai du batailler un peu pour avoir un nom fixe (usb-tether). Google est votre ami.

    V\u00e9rifiez que l’interface a obtenu une adresse IP du t\u00e9l\u00e9phone :
    ip a
    <\/li>\n\n\n\n
  3. Activer le forwarding IP :<\/strong> Pour que la machine interne puisse router le trafic des autres machines du r\u00e9seau, le forwarding IP doit \u00eatre activ\u00e9.
    sudo nano \/etc\/sysctl.conf

    D\u00e9commentez ou ajoutez la ligne suivante :
    net.ipv4.ip_forward=1

    Appliquez la modification sans red\u00e9marrer :
    sudo sysctl -p
    <\/li>\n\n\n\n
  4. Configurer la traduction d’adresses r\u00e9seau (NAT) :<\/strong> Les paquets provenant de votre r\u00e9seau local (192.168.1.0\/24) doivent \u00eatre r\u00e9\u00e9crits 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<\/li>\n<\/ol>\n\n\n\n
      \n
    • -t nat : Sp\u00e9cifie la table NAT.<\/li>\n\n\n\n
    • -A POSTROUTING : Ajoute une r\u00e8gle \u00e0 la cha\u00eene POSTROUTING (appliqu\u00e9e juste avant que le paquet ne quitte la machine).<\/li>\n\n\n\n
    • -s 192.168.1.0\/24 : Source des paquets (votre r\u00e9seau local).<\/li>\n\n\n\n
    • -o usb-tether : Interface de sortie (celle du t\u00e9l\u00e9phone).<\/li>\n\n\n\n
    • -j MASQUERADE : Action de masquerade (NAT dynamique utilisant l’IP de l’interface de sortie).<\/li>\n<\/ul>\n\n\n\n

      \u00c0 ce stade, la machine interne peut acc\u00e9der \u00e0 Internet via le t\u00e9l\u00e9phone.<\/p>\n\n\n\n

      Chapitre 2 : Rerouter le R\u00e9seau Local<\/strong><\/p>\n\n\n\n

      Maintenant que la machine interne a une connexion Internet fonctionnelle, il faut indiquer aux autres machines du r\u00e9seau d’utiliser cette machine comme passerelle par d\u00e9faut.<\/p>\n\n\n\n

        \n
      1. Modifier la passerelle par d\u00e9faut via DHCP : Votre serveur DHCP (chez moi, dnsmasq sur 192.168.1.1) attribue normalement la passerelle par d\u00e9faut. Modifiez sa configuration pour qu’il distribue l’adresse IP de la machine interne (192.168.1.3) comme passerelle.
        Connectez-vous en SSH \u00e0 votre serveur DNS\/DHCP :
        ssh utilisateur@192.168.1.1

        \u00c9ditez 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
        <\/li>\n<\/ol>\n\n\n\n
          \n
        • dhcp-option=3 : Sp\u00e9cifie l’option DHCP pour la passerelle par d\u00e9faut (router).<\/li>\n\n\n\n
        • 192.168.1.3 : La nouvelle adresse IP de la passerelle.<\/li>\n<\/ul>\n\n\n\n
            \n
          1. Appliquer la nouvelle passerelle sur les clients :<\/strong> Les machines clientes doivent renouveler leur bail DHCP pour obtenir la nouvelle adresse de passerelle.<\/li>\n<\/ol>\n\n\n\n
              \n
            • Sur Linux :<\/strong> Red\u00e9marrez le service r\u00e9seau ou utilisez sudo dhclient -r && sudo dhclient.<\/li>\n\n\n\n
            • Sur Windows :<\/strong> Ouvrez une invite de commande et ex\u00e9cutez ipconfig \/renew.<\/li>\n\n\n\n
            • Sur macOS :<\/strong> D\u00e9sactivez puis r\u00e9activez l’interface r\u00e9seau dans les param\u00e8tres.<\/li>\n<\/ul>\n\n\n\n
                \n
              1. V\u00e9rifier la nouvelle passerelle :<\/strong> Sur une machine cliente, v\u00e9rifiez que la passerelle par d\u00e9faut est bien 192.168.1.3.<\/li>\n<\/ol>\n\n\n\n
                  \n
                • Sur Windows :<\/strong> ipconfig \/all<\/li>\n\n\n\n
                • Sur Linux\/macOS :<\/strong> ip r ou netstat -rn<\/li>\n<\/ul>\n\n\n\n
                    \n
                  1. Tester la connectivit\u00e9 externe :<\/strong> V\u00e9rifiez que les machines du r\u00e9seau peuvent acc\u00e9der \u00e0 Internet.<\/li>\n<\/ol>\n\n\n\n
                      \n
                    • Tester un ping direct (sans r\u00e9solution DNS) :
                      ping 1.1.1.1
                      <\/li>\n\n\n\n
                    • Tester un ping avec r\u00e9solution DNS :
                      ping www.google.fr
                      <\/li>\n<\/ul>\n\n\n\n

                      Si ces pings fonctionnent, tout le r\u00e9seau utilise maintenant la connexion de secours pour sortir.<\/p>\n\n\n\n

                      Chapitre 3 : Cr\u00e9er le Tunnel Invers\u00e9<\/strong><\/p>\n\n\n\n

                      Maintenant que le r\u00e9seau interne peut communiquer vers l’ext\u00e9rieur, nous allons \u00e9tablir un tunnel SSH invers\u00e9 depuis la machine interne vers votre VPS externe.<\/p>\n\n\n\n

                        \n
                      1. Pr\u00e9parer le VPS pour le tunnelling SSH :<\/strong> Connectez-vous en SSH \u00e0 votre VPS externe.
                        ssh utilisateur_vps@adresse_ip_publique_vps

                        \u00c9ditez le fichier de configuration du d\u00e9mon SSH :
                        sudo nano \/etc\/ssh\/sshd_config

                        Assurez-vous que les lignes suivantes sont pr\u00e9sentes et activ\u00e9es :
                        AllowTcpForwarding yes
                        GatewayPorts yes
                        <\/li>\n<\/ol>\n\n\n\n
                          \n
                        • AllowTcpForwarding yes : Autorise les redirections de ports.<\/li>\n\n\n\n
                        • GatewayPorts yes : Permet de lier le port redirig\u00e9 \u00e0 l’adresse IP publique du VPS, le rendant accessible depuis Internet (et pas seulement depuis le VPS lui-m\u00eame).<\/li>\n<\/ul>\n\n\n\n

                          Note sur les ports 80\/443 et PermitRootLogin : Tenter de lier directement les ports 80 et 443 avec un tunnel SSH invers\u00e9 peut \u00e9chouer si un autre service (comme un serveur web) \u00e9coute d\u00e9j\u00e0 sur ces ports, ou si l’utilisateur SSH n’a pas les permissions suffisantes (ports < 1024 n\u00e9cessitent 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\u00e8me de permission.Si vous devez lier directement 80\/443 et que vous \u00eates certain qu’aucun autre service ne les utilise, vous pourriez tenter d’\u00e9tablir la connexion SSH en tant que root sur le VPS. Cela n\u00e9cessite d’autoriser la connexion root via SSH, ce qui est fortement d\u00e9conseill\u00e9 pour des raisons de s\u00e9curit\u00e9. Si vous choisissez cette voie temporairement, modifiez sshd_config sur le VPS :PermitRootLogin yes
                          N’oubliez pas de d\u00e9sactiver PermitRootLogin yes et de red\u00e9marrer sshd une fois le d\u00e9pannage termin\u00e9 ou si vous optez pour la m\u00e9thode du proxy inverse (recommand\u00e9e).<\/strong> La m\u00e9thode la plus propre est d’utiliser un port diff\u00e9rent pour le tunnel et un proxy inverse sur le VPS.<\/p>\n\n\n\n

                            \n
                          1. Red\u00e9marrer le service SSH sur le VPS :<\/strong>
                            sudo systemctl restart sshd
                            <\/li>\n\n\n\n
                          2. \u00c9tablir le tunnel invers\u00e9 depuis la machine interne :<\/strong> 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<\/li>\n<\/ol>\n\n\n\n
                              \n
                            • -i <chemin_vers_votre_cle_ssh>.pem : Sp\u00e9cifie la cl\u00e9 priv\u00e9e SSH \u00e0 utiliser (recommand\u00e9 pour l’automatisation).<\/li>\n\n\n\n
                            • -N : Ne pas ex\u00e9cuter de commande distante.<\/li>\n\n\n\n
                            • -T : D\u00e9sactiver l’allocation d’un pseudo-terminal.<\/li>\n\n\n\n
                            • -R <Port_Externe>:<IP_Interne>:<Port_Interne> : Configure la redirection invers\u00e9e. Le trafic arrivant sur <Port_Externe> du VPS est redirig\u00e9 vers <IP_Interne>:<Port_Interne> via le tunnel.<\/li>\n\n\n\n
                            • utilisateur_vps@adresse_ip_publique_vps : Les informations de connexion au VPS.<\/li>\n<\/ul>\n\n\n\n

                              Si vous avez utilis\u00e9 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\u00e8s s\u00e9curis\u00e9e, mais c’est ce qui permet d’ouvrir les ports <1024 sans autre \u00e9tapes techniques. En vrai, il faudrait plut\u00f4t passer par un reverse proxy sur le VPS. Mais je voulais aller vite.<\/p>\n\n\n\n

                                \n
                              1. Maintenir le tunnel actif :<\/strong> La commande ssh seule se terminera si la connexion est interrompue. Utilisez autossh pour red\u00e9marrer 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\u00e9marre automatiquement au boot.<\/li>\n<\/ol>\n\n\n\n

                                Chapitre 4 : Modifier le DNS Externe<\/strong><\/p>\n\n\n\n

                                Pour que vos noms de domaine pointent vers votre VPS qui sert de relais, vous devez modifier vos enregistrements DNS externes.<\/p>\n\n\n\n

                                  \n
                                1. Acc\u00e9der \u00e0 la gestion DNS :<\/strong> Connectez-vous \u00e0 l’interface de gestion DNS chez votre registrar (l\u00e0 o\u00f9 vous avez achet\u00e9 votre nom de domaine memoiresecondaire.fr).<\/li>\n\n\n\n
                                2. Modifier les enregistrements A\/AAAA :<\/strong> Modifiez l’enregistrement A (pour IPv4) et \u00e9ventuellement AAAA (pour IPv6) pour votre domaine principal (memoiresecondaire.fr) et pour les sous-domaines (l’enregistrement wildcard *.memoiresecondaire.fr est id\u00e9al ici) pour qu’ils pointent vers l’adresse IP publique de votre VPS.<\/li>\n<\/ol>\n\n\n\n
                                    \n
                                  • Type : A<\/li>\n\n\n\n
                                  • Nom : * (pour le wildcard, couvre tous les sous-domaines)<\/li>\n\n\n\n
                                  • Valeur : <adresse_ip_publique_du_vps><\/li>\n\n\n\n
                                  • Type : A<\/li>\n\n\n\n
                                  • Nom : @ (pour le domaine principal lui-m\u00eame)<\/li>\n\n\n\n
                                  • Valeur : <adresse_ip_publique_du_vps><\/li>\n<\/ul>\n\n\n\n

                                    Les modifications DNS peuvent prendre un certain temps \u00e0 se propager sur Internet (propagation DNS).<\/p>\n\n\n\n

                                    Chapitre 5 : V\u00e9rification<\/strong><\/p>\n\n\n\n

                                    Une fois toutes les \u00e9tapes pr\u00e9c\u00e9dentes effectu\u00e9es, vous devriez pouvoir acc\u00e9der \u00e0 vos services depuis l’ext\u00e9rieur.<\/p>\n\n\n\n

                                      \n
                                    1. Vider le cache DNS local :<\/strong> Sur la machine externe depuis laquelle vous testez l’acc\u00e8s, videz le cache DNS pour vous assurer qu’elle utilise les nouvelles informations DNS.<\/li>\n<\/ol>\n\n\n\n
                                        \n
                                      • Sur Windows :<\/strong> Ouvrez une invite de commande et ex\u00e9cutez ipconfig \/flushdns.<\/li>\n\n\n\n
                                      • Sur Linux :<\/strong> sudo systemd-resolve –flush-caches ou red\u00e9marrez le service r\u00e9seau.<\/li>\n\n\n\n
                                      • Sur macOS :<\/strong> sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder<\/li>\n<\/ul>\n\n\n\n
                                          \n
                                        1. Tester l’acc\u00e8s via le navigateur :<\/strong> Ouvrez un navigateur et essayez d’acc\u00e9der \u00e0 un de vos services en utilisant son nom de domaine complet, par exemple jellyfin.memoiresecondaire.fr. La requ\u00eate devrait maintenant passer par l’IP de votre VPS, traverser le tunnel SSH, atteindre votre proxy inverse interne, et finalement votre service.<\/li>\n<\/ol>\n\n\n\n

                                          Conclusion<\/strong><\/p>\n\n\n\n

                                          Cette m\u00e9thode, bien que n\u00e9cessitant plusieurs \u00e9tapes de configuration (r\u00e9tablissement de la connexion de secours, reroutage du r\u00e9seau local, mise en place du tunnel SSH invers\u00e9 et mise \u00e0 jour DNS), offre une solution efficace pour maintenir l’acc\u00e8s externe \u00e0 votre infrastructure auto-h\u00e9berg\u00e9e m\u00eame en cas de d\u00e9faillance de votre connexion Internet principale et de l’impossibilit\u00e9 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\u00f4le total sur le processus. N’oubliez pas de revenir \u00e0 votre configuration r\u00e9seau et DNS d’origine une fois que votre connexion Internet principale est r\u00e9tablie.<\/p>\n","protected":false},"excerpt":{"rendered":"

                                          Lorsque la connexion Internet principale tombe et que la seule alternative est une liaison de secours limit\u00e9e, comme un partage de connexion 5G, qui ne permet pas la redirection de ports entrants, comment maintenir l’acc\u00e8s aux services autoh\u00e9berg\u00e9s ? Cet article d\u00e9taille une m\u00e9thode technique pour r\u00e9tablir l’acc\u00e8s externe \u00e0 l’infrastructure interne en utilisant un […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55],"tags":[],"class_list":["post-1922","post","type-post","status-publish","format-standard","hentry","category-informatique"],"_links":{"self":[{"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=\/wp\/v2\/posts\/1922","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1922"}],"version-history":[{"count":3,"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=\/wp\/v2\/posts\/1922\/revisions"}],"predecessor-version":[{"id":1925,"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=\/wp\/v2\/posts\/1922\/revisions\/1925"}],"wp:attachment":[{"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1922"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1922"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.memoiresecondaire.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1922"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}