Une baie serveur montée de A à Z par mes soins.😄

Un brassage réseau aux petits oignons, rien ne dépasse ! 😄

Deux infrastructures dans la même baie : celle de la maison mère et celle de la filiale.
Un réseau d’entreprise avec une ligne spécialisée (LS) et un backup, qui dessert les postes de travail de la maison mère, ainsi que le firewall (visible en haut de l’image).
À côté, on trouve le brassage d’un réseau secondaire dédié à la filiale, composé d’une box Internet classique, d’un switch, et d’un serveur hébergeant l’application.

Mais dis-moi, Jamie, pourquoi on se complique la vie ?

🚢 Histoire d’une astuce réseau : contourner les limites sans les violer

Une filiale a récemment acheté une solution logicielle pour gérer son parc de containers. Ce logiciel, installé sur un serveur local (visible sur la photo), fonctionne parfaitement en intranet :

Il dessert les agents du site via leurs ordinateurs de bureau, tous connectés au même réseau local.
Il alimente aussi les agents de terrain, qui déplacent les containers ou les amènent aux chauffeurs poids lourds, via des tablettes connectées en Wi-Fi.

💡 Jusqu’ici, tout va presque bien (sauf peut-être le choix du Wi-Fi pour les tablettes, mais passons).

⚠️ Le problème

Deux employés de cette filiale travaillent physiquement dans les bureaux de la maison mère, sur le réseau de la maison mère.

Or, cette maison mère refuse catégoriquement que le logiciel du parc tourne sur son infrastructure. Aucun déploiement, aucune base de données, aucune dépendance sur ses serveurs.

➡️ Elle autorise toutefois que ce logiciel fonctionne uniquement dans l’infrastructure de la filiale, c’est-à-dire au niveau du parc de containers.

🎯 L’objectif

Permettre aux deux employés de la filiale, situés physiquement dans les locaux de la maison mère, d’accéder à l’application sans jamais installer ni exécuter le logiciel sur l’infrastructure de la maison mère.

💡 La solution : tunnel SSH sur le port 443 + RDP

Et c’est là que réside tout le génie de l’approche technique.

Un serveur SSH a été installé sur le serveur applicatif du parc (celui qui héberge le logiciel).
Ce serveur SSH a été configuré pour écouter sur le port 443 — un port généralement ouvert même à travers des firewalls stricts (car utilisé pour le HTTPS).
Depuis les postes Windows des deux utilisateurs dans les bureaux de la maison mère :
- On utilise PuTTY pour établir une connexion SSH sortante vers ce serveur distant (celui du parc).
- PuTTY est configuré pour faire du port forwarding local.
- On redirige le port RDP (3389) du serveur de la filiale vers un port local, par exemple le port 3386.

🧠 Résultat : depuis la maison mère, on ouvre un mstsc (Remote Desktop) sur localhost:3386.
Cela lance une session Bureau à distance vers le serveur du parc, via un tunnel chiffré, sans jamais exposer le logiciel sur le réseau de la maison mère.

Tips : PuTTy permet de configuer le proxy pour etablir la connection

✅ Avantages :

Aucune installation sur l’infrastructure de la maison mère
Connexion chiffrée et fiable (via SSH)
Contournement intelligent du firewall sans tricher : le port 443 est normalement ouvert pour le web
Respect des règles internes des deux entités
Solution peu coûteuse (hormis la limite à deux connexions RDP simultanées…)

🛑 Le seul frein : Windows limite à deux sessions Bureau à distance simultanées sans licence supplémentaire. Pour aller plus loin, il faudrait investir… mais c’est une autre histoire.

Tuto ssh portforward

🧰 Mini tutoriel : SSH Tunnel + Port Forwarding avec PuTTY

Objectif :

Accéder à un Bureau à distance (RDP) d’un serveur distant via un tunnel SSH, en passant un firewall qui ne laisse sortir que le port 443.

Étape 1 : Préparer le serveur distant (filiale)

Installer et configurer OpenSSH Server sur le serveur applicatif.
Modifier la configuration SSH pour écouter sur le port 443 :
Dans /etc/ssh/sshd_config :

Port 443

Puis redémarrer le service :

sudo systemctl restart sshd

Étape 2 : Configurer PuTTY (sur un PC de la maison mère)

Host Name : IP publique ou DNS du serveur du parc
Port : 443
Connection type : SSH

🔸 Allez ensuite dans :

Connection > SSH > Tunnels
- Source port : 3386
- Destination : localhost:3389(le port RDP du serveur distant)
- Cochez : « Local » et « Auto »
- Cliquez sur « Add »

🔸 Revenez à la section « Session », sauvegardez votre configuration, puis cliquez sur « Open » pour lancer le tunnel.

Étape 3 : Se connecter via Bureau à distance

Ouvrez mstsc.exe et entrez :

localhost:3386

Vous accéderez au bureau du serveur distant comme s’il était en local.

🧩 Conclusion

Cette solution est un modèle de contournement intelligent dans un cadre contraint. Elle montre comment, grâce aux tunnels SSH et au port forwarding, on peut :

respecter des règles d’architecture réseau strictes
sécuriser les accès
éviter des coûts d’intégration élevés
et offrir une expérience utilisateur transparente pour des agents déportés.

Une belle démonstration que les bonnes idées techniques naissent souvent dans la contrainte.

Histoire de tech: serveur