Tutorial Tunneling SSH et serveurs SAMBA

Alex M

Sujets

• Netbios
• Putty (jeu vidéo)
• Routeur
• Tutoriel
• Étant Donnés
• Ordinateur personnel

Informations

• Publié par: Zoun
• Nombre de lectures: 227
• Langue: Français

Extrait

Tutorial

Tunneling SSH et serveurs SAMBA

Le but du tutorial est d’accéder au travers d’un tunnel SSH à des serveurs SAMBA

situés sur un réseau d’entreprise, comme s’ils faisaient partie du réseau local, et de

pouvoir monter les ressources partagées par les moyens SAMBA natifs de Windows.

Depuis une station qui n’utilise pas Netbios/IP en local.

C’est le cas de toutes les station qui :

ƒ

Ne partagent pas de ressources (stations non situées sur des réseaux locaux, stations

qui ne partagent pas en samba, …)

ƒ

Sont sur des réseaux locaux simples (sans routeurs) dont tous les ordinateurs sont sous

Windows et partagent leur ressources au travers du protocole Novell Netbios natif

(activé par défaut sous les Win9x ; activable sous WinXP).

Ces ordinateurs n’ont pas besoins de Netbios/IP.

Il suffit alors de désactiver NetBIOS sur toutes les connexions IP actives (local, WiFi,

Firewire, …). Cette option se trouve dans l’onglet WINS des propriétés avancées du protocole

TCP/IP.

Il suffit ensuite d’indiquer à PuTTY de rediriger le port netbios-ssn (139) vers le serveur

samba voulu.

Depuis une station qui utilise Netbios/IP en local.

C’est le cas de toutes les stations qui ont des partages locaux et qui sont situées sur des

réseaux locaux qui sont entièrement établis sur le protocole IP (réseaux locaux complexes ou

mixant des stations Windows à d’autres).

Le port netbios-ssn étant utilisé en local, et Windows ne permettant pas de spécifier le port de

connexion Samba dans sa syntaxe

\\point.distant\partage

, il est impossible de rediriger un

port local différent du port 139 vers le serveur samba. Mais Windows permet d’activer ou de

désactiver Netbios/IP sur certaines interfaces.

Le premier point consiste donc à ajouter à la station locale une carte réseau virtuelle sur

laquelle Netbios/IP n’est pas activée. Comme la carte ne sera connectée à aucun réseau,

personne ne sera empêché d’accéder aux partages situés sur la station locale. Or la carte peut

avoir des adresses IP locales ce qui permet de rediriger des ports de ces adresses vers des

serveurs quelconques. Par contre, il faudra attribuer à cette carte un nombre d’adresse

identique au nombre de serveurs samba que l’on veut atteindre par tunnels SSH.

Pour installer cette carte virtuelle, il faut ajouter manuellement une carte de bouclage

Microsoft.

Une nouvelle connexion apparaît alors dans le panneau des connexions réseau.

Attribuez ensuite à cette connexion autant d’adresses IP que nécessaires (en utilisant des

adresses situées dans l’espaces des IP privées non routables).

Et pensez bien à désactiver Netbios/IP pour cette interface (c’est pour ça qu’on l’a créé ! ).

Enfin sous PuTTY, redirigez les ports netbios-ssn des adresses de l’interface nouvellement

créée vers les serveurs samba de votre choix. Attention à bien faire écouter PuTTY sur

«

IP_PRIVEE:139 »

et non pas sur «

*:139 »

.

Généralisation du procédé

Le procédé précédant, consistant à créer une interface réseau virtuelle est l’unique moyen de

communiquer avec un serveur samba au travers d’un tunnel SSH si l’on utilise le port netbios-

ssn en local. Mais il est aussi extrêmement pratique pour créer un hôte virtuel mappant tous

les services d’un hôte réel et ainsi pouvoir accéder aux services d’un serveur sur les numéros

de ports d’origine. Par exemple, si un serveur fait serveur web, samba et pop3, on peut faire la

configuration suivante :

Et ainsi référer à

193.54.10.10

en utilisant

192.168.10.10

pour accéder à tous les services du

serveur sur leur port d’origine. Seule l’adresse IP change. L’utilisation des services dans des

applications cliente au travers du tunnel est ainsi plus aisée (exemple : il suffit de taper

http://192.168.10.10

pour avoir accès à la page web du serveur, il n’y a plus besoin de

spécifier de port étant donnée qu’il est mappé sur le port http par défaut).

En faisant ceci pour plusieurs serveurs au travers de plusieurs adresses IP virtuelles, on peut

ainsi recréer un réseau d’hôtes virtuelles mappant tous les services d’un réseau d’entreprise.

Diffusion du service à un réseau local

Avec la méthode vue précédemment, une seule station peut accéder aux hôtes virtuelle : celle

qui lance PuTTY avec une interface réseau virtuelle. Mais cette méthode étant lourde, il serait

intéressant que les stations situées sur le même réseau local puissent aussi voir et accéder aux

hôtes virtuelles.

Pour ceci, il faut d’abord séparer les réseaux locaux et virtuels en donnant deux adresses de

réseau différentes (exemple : prendre 192.168.0.0/24 pour le réseau local et utiliser

192.168.10.0/24 pour les adresses de l’interface virtuelle). Ensuite il faut installer PuTTY sur

un ordinateur capable de faire du routage d’une interface vers l’autre et ainsi router l’interface

physique vers l’interface virtuelle. Il faut aussi indiquer à PuTTY que les tunnels doivent être

accessibles par les stations adjacentes.

Enfin, il faut créer une route statique des adresses appartenant au réseau virtuel vers la

passerelle qui héberge PuTTY au niveau du routeur du réseau local.

Les adresses réseau étant différentes, les stations locales passeront par le routeur du réseau

pour essayer d’accéder à ce pool d’adresses virtuelles. Ce dernier routera alors vers la station

qui fait du tunneling SSH qui elle-même routera les paquets d’une interface vers l’autre. Les

paquets seront alors pris en charge par PuTTY.

Dans ce schéma, il suffit alors d’une seule station qui crée un tunnel SSH et toutes les autres

stations qui ont un accès au réseau local, qu’il soit physique (RJ, Wifi) ou distant (SSH, VPN,

RDP), peuvent accéder au réseau d’entreprise distant comme si elle en faisait partie.

Schéma illustratif du procédé :

Dans l’exemple ci-dessus, le routeur maître doit avoir une route statique de 192.168.10.0/24 vers

192.168.0.100 du coté de son interface interne (192.168.0.254). La route doit être diffusable en

interne au cas où le réseau local comporte d’autres routeurs définissant des sous-réseaux mais pas en

externe (w.x.y.z)

Conclusion

Comparaison entre la fusion de réseau par SSH et par VPN :

ƒ

SSH arrive au même niveau d’utilisabilité que VPN en permettant la fusion de réseaux

sauf que dans le cas de SSH, les adresses IP changent du coté client.

ƒ

La protection du réseau d’entreprise est identique dans les 2 cas (ex : un vers situé sur

une des stations locales peut se propager vers tout le réseau d’entreprise).

ƒ

La protection du client est assurée par SSH alors qu’elle ne l’est pas par VPN (ex : un

vers situé sur le réseau d’entreprise ne peut pas remonter vers le client en SSH alors

qu’il peut en VPN)

ƒ

SSH est plus difficile à mettre en oeuvre coté client que le VPN.