Tutorial Tunneling SSH et serveurs SAMBA
9
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
9
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
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 ...
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.
