Dans le dernier point de ce chapitre, j’aimerais aborder la question des tunnels via SSH. C’est un sujet très important à comprendre, et je vous montrerai plus tard dans un LAB comment cela peut être configuré.
Comme vous le savez, SSH est un protocole très sécurisé qui nous permet de nous connecter à distance à des périphériques réseau afin de les configurer. Il utilise des clés RSA qui sont considérées comme des clés asymétriques sécurisées protégeant la communication avec les périphériques réseau que nous configurons, y compris les informations d’identification que nous enverrons à ces périphériques pour être authentifiés.
Comme SSH est un protocole sécurisé, nous pouvons en tirer profit en faisant passer par le tunnel SSH une partie du trafic pour atteindre des dispositifs à l’intérieur de notre réseau distant qui peuvent ne pas être sécurisés. Imaginez, par exemple, que vous souhaitiez utiliser le bureau à distance de Windows pour accéder à l’une des machines internes de l’un de vos collègues qui rencontre des difficultés sur son PC. Si vous vous connectez directement au PC en utilisant le bureau à distance de Windows, cette méthode est considérée comme non sécurisée. Ce que vous pouvez faire à la place, c’est établir une connexion SSH avec le routeur de ce réseau distant, puis à l’intérieur du tunnel SSH, vous pouvez envoyer le trafic du bureau à distance de Windows à ce PC, et toutes vos communications avec ce PC seront alors sécurisées.
Permettez-moi de vous montrer une illustration pour faciliter votre compréhension :
Supposons que je sois chez moi et que je veuille accéder au serveur web de mon entreprise. Imaginons que le serveur web ait une adresse IP privée (derrière un NAT) et qu’il fonctionne sur le port http 80, qui est un port non sécurisé. Si, d’une manière ou d’une autre, je pouvais atteindre le serveur via l’internet sur le port 80, toutes mes communications avec ce serveur web seraient vues sur l’internet parce que le port 80 envoie tout en clair.
Ce que je peux faire à la place, c’est exécuter une connexion SSH au routeur de l’entreprise, puis je dois exécuter un SSH Forwarder sur ce routeur dans lequel je peux passer tout mon trafic vers ce serveur web via le tunnel SSH sécurisé, ce qui signifie que même si j’utilise le port 80 pour atteindre le serveur web, je sais que tout est sécurisé parce que le trafic http sera à l’intérieur du tunnel SSH que j’ai déjà créé.
La bonne nouvelle est que le routeur MikroTik peut être un SSH forwarder, et ce paramètre est disponible sur RouterOS v7.
Assez de théorie, appliquons ceci sur un LAB et voyons comment nous pouvons le configurer.
LAB: Tunnelisation via SSH
J’ai ce scénario LAB. Je suis capable depuis mon PC (via internet) de me connecter en SSH à R1. J’ai ajouté R2 qui a http activé sur lui. J’ai défini des IP entre R1 et R2 sur leurs interfaces Ether2 comme vous le voyez dans le graphique, de sorte que R1 peut atteindre R2 et vice versa.
Mon idée est de me connecter en SSH à R1, puis d’utiliser ce tunnel SSH pour transmettre mon trafic http à R2 afin d’atteindre le Webfig de R2 sur le port 80. De cette façon, je sais que je peux configurer R2 via http de manière sécurisée en utilisant le tunnel SSH, même si le port 80 est un port non sécurisé.
Pour pouvoir le faire, je devrais :
- Activez SSH sur R1.
- Faire de R1 un redirecteur SSH.
- Effectuer quelques réglages sur le logiciel putty de sorte que lorsque je me connecte en SSH à R1, je puisse atteindre R2 sur le port 80 via ce tunnel SSH.
Nous allons les faire une par une. Tout d’abord, vérifions si SSH est activé sur R1 :
Veuillez nous excuser, l'accès complet à la leçon est réservé aux membres uniquement...

Satisfaction 100 % garantie !
Aucune question posée, quoi qu'il en soit !
0 commentaires