Présentation de la réalisation

Cette réalisation, la plus ancienne de mon alternance chez Alcante, consistait à mettre en place une solution d’accès distant sécurisé aux installations de téléphonie de nos clients. L’entreprise déploie chez ses clients des serveurs de téléphonie IPBX reposant sur Asterisk (avec la pile PJSIP), qu’elle doit pouvoir administrer et maintenir à distance. Jusqu’alors, cet accès reposait sur l’ouverture de redirections de port sur le réseau de chaque client, une pratique à la fois peu sûre et difficile à généraliser.

J’ai conçu et déployé, en toute autonomie, un serveur distant faisant office de passerelle : un tunnel reverse SSH établit une liaison permanente et chiffrée entre un port local du réseau de chaque client et ce serveur central. L’entreprise dispose ainsi d’une connexion distante permanente et sécurisée vers chaque installation, sans jamais exposer les réseaux clients à Internet. Ce projet fut ma première expérience du protocole SSH et de l’usage d’un serveur distant comme passerelle — une base qui m’a ensuite servi pour le développement du SSH sur mes projets IoT.

Introduction et objectifs

L’objectif était de fournir à l’entreprise un moyen fiable et sûr d’atteindre à distance les IPBX installés chez les clients, tout en supprimant les contraintes et les risques liés à l’ouverture de ports. Les objectifs principaux étaient les suivants :

• Sécurité : garantir un accès distant entièrement chiffré et authentifié, sans exposer les réseaux clients à Internet ;
• Permanence : maintenir une liaison disponible en continu, capable de se rétablir automatiquement après une coupure ou un redémarrage ;
• Simplicité de déploiement : disposer d’une solution reproductible d’un client à l’autre, indépendante des contraintes de pare-feu et de routeur propres à chaque site.

Contexte humain

Comme pour mes autres réalisations, le projet m’a été confié dans le cadre de mon alternance au sein de l’entreprise Alcante, dont j’étais le seul concepteur et développeur : j’ai mené le projet de bout en bout, de la réflexion sur la sécurité jusqu’à la mise en production. L’entreprise est composée de deux personnes :

• Jorge Beja, mon tuteur, dirigeant et technicien de l’entreprise, qui réalise les installations de téléphonie et est à l’origine de la commande ;
• Isabelle Saraiva, secrétaire, qui gère les commandes clients et assure en partie la comptabilité de l’entreprise.

Contexte technique

L’architecture repose sur deux extrémités reliées par un tunnel SSH. Côté client, une machine sous distribution Linux (Ubuntu ou Debian) héberge le serveur de téléphonie Asterisk et sa pile PJSIP ; c’est elle qui initie la connexion vers l’extérieur. Côté entreprise, un serveur distant sous Ubuntu (accessible via alcante.eu) joue le rôle de passerelle centrale vers laquelle tous les clients se connectent.

La liaison est assurée par OpenSSH, configuré en reverse SSH : c’est la machine du client qui établit le tunnel vers le serveur central, exposant en retour un port local (celui de l’IPBX) sur le serveur distant. L’entreprise peut ainsi joindre l’installation du client en se connectant simplement au port correspondant sur sa passerelle, sans qu’aucun port n’ait été ouvert sur le réseau du client.

Pour rendre cette liaison permanente, j’ai associé autossh, qui surveille le tunnel et le rétablit automatiquement en cas de coupure, à un service systemd qui relance la connexion au démarrage de la machine. Le tunnel se reconnecte ainsi de lui-même après une panne réseau ou un redémarrage, sans intervention manuelle.

L’authentification s’effectue exclusivement par clés SSH, sans mot de passe : cela supprime tout risque de fuite ou de compromission d’identifiant et garantit que seules les machines autorisées peuvent établir le tunnel.

L’enjeu

L’enjeu était de dépasser les limites de la méthode alors employée : l’ouverture de redirections de port sur le routeur de chaque client. Cette pratique expose directement un service interne sur Internet, ce qui en fait une cible privilégiée pour les scans et les tentatives d’intrusion, et élargit inutilement la surface d’attaque du réseau client.

Au-delà de la sécurité, l’ouverture de port n’était pas toujours réalisable : selon les pare-feux et les routeurs en place chez le client, ou l’absence d’adresse IP publique fixe, la redirection était parfois impossible ou instable. Il fallait donc une solution homogène, fonctionnant quel que soit l’environnement réseau du client, et c’est précisément ce qu’apporte le tunnel reverse SSH, initié depuis l’intérieur du réseau client.

Les risques

Le principal point de vigilance tient à la nature même de la solution : le serveur central concentre l’accès à l’ensemble des installations clientes, ce qui en fait un élément particulièrement sensible. Une compromission de cette passerelle exposerait potentiellement tous les clients ; sa sécurisation est donc déterminante.

Pour limiter ce risque, l’authentification repose exclusivement sur des clés SSH, sans aucun mot de passe, ce qui écarte les attaques par force brute et tout risque de fuite d’identifiant. À ce stade, la sécurité ne va pas au-delà de cette authentification par clés ; un renforcement — notamment un cloisonnement plus strict entre les accès des différents clients — est à l’étude pour une prochaine évolution.

Les étapes

Le projet s’est déroulé selon les grandes étapes suivantes :

• Étude du besoin et de la solution : analyse des limites de l’ouverture de port et choix du reverse SSH comme alternative ;
• Mise en place du serveur passerelle sous Ubuntu et configuration d’OpenSSH ;
• Configuration côté client : établissement du tunnel reverse SSH depuis la machine Asterisk, mise en place de l’authentification par clés ;
• Fiabilisation de la liaison : intégration d’autossh et création d’un service systemd pour la reconnexion automatique après coupure ou redémarrage ;
• Déploiement progressif sur le parc client et passage en production.

Méthodologie de suivi

Le suivi du projet s’est fait de manière itérative avec mon tuteur : après validation du principe de la solution, j’ai mis en place puis testé le tunnel sur un premier client pilote, avant de généraliser progressivement au reste du parc. Chaque déploiement était l’occasion de vérifier la stabilité de la liaison et d’ajuster la configuration avant de passer au client suivant.

Gestion du code source et traçabilité

Ce projet reposant sur de la configuration système plutôt que sur du développement applicatif, j’ai veillé à documenter précisément la procédure de déploiement (configuration d’OpenSSH, mise en place d’autossh et du service systemd, génération et installation des clés) afin de pouvoir la reproduire de façon fiable d’un client à l’autre et de faciliter la maintenance ultérieure.

Les acteurs

Trois types d’acteurs sont intervenus sur ce projet :

• Moi-même, en tant que concepteur et déployeur unique de la solution, de la réflexion sur la sécurité jusqu’à la mise en production ;
• Jorge Beja, mon tuteur, à l’origine de la commande et de la validation de la solution ;
• Les clients de l’entreprise, dont les installations de téléphonie sont désormais administrées à distance via la passerelle.

Les résultats

La solution est aujourd’hui en production et a entièrement remplacé l’ouverture de ports pour une dizaine de clients. Chaque installation de téléphonie est désormais accessible à distance de façon permanente et sécurisée, sans qu’aucun port ne soit exposé sur le réseau des clients. La reconnexion automatique assurée par autossh et systemd garantit la disponibilité de la liaison, y compris après une coupure ou un redémarrage.

Ce projet a rempli son objectif : il a supprimé les risques et les contraintes liés aux redirections de port tout en offrant à l’entreprise un accès fiable et homogène à l’ensemble de son parc.

Les lendemains du projet

Cette réalisation constitue la base de mon expérience du SSH et des serveurs distants employés comme passerelle. Les principes mis en œuvre ici — reverse SSH, tunnels permanents, authentification par clés — m’ont ensuite directement servi pour concevoir l’accès distant de mes projets IoT (Abeille puis Modlink).

La solution continue par ailleurs d’évoluer. Le principal axe d’amélioration porte sur le renforcement de la sécurité, notamment un cloisonnement plus strict entre les accès des différents clients. À plus long terme, une évolution envisagée consisterait à déployer un boîtier ESP32 associé à un proxy SOCKS5 pour donner accès à l’ensemble du réseau du client, ce qui supposerait toutefois de mettre en place une marge de sécurité importante afin de prévenir tout abus.

Mon regard critique

Avec le recul, ce projet a été particulièrement formateur, car il a posé les fondations de compétences que j’ai réutilisées tout au long de mon alternance. Étant ma première approche du SSH, il m’a demandé un réel travail d’apprentissage, notamment pour comprendre le fonctionnement du reverse SSH et fiabiliser la reconnexion automatique du tunnel.

Le principal point d’amélioration reste la sécurité : la solution repose aujourd’hui essentiellement sur l’authentification par clés, et un cloisonnement plus poussé entre clients renforcerait la robustesse de l’ensemble. Ce projet m’a néanmoins permis de mesurer ma capacité à concevoir et déployer seul une infrastructure réseau critique, et de gagner en autonomie sur les questions de sécurité et d’administration système.