1. Introduction

Comme nous travaillons avec Netkit, nous n'avons pas d'interface graphique pour tester les services, mais cela n'est pas très important, puisque sous GNU/Linux, il existe toujours des outils en mode texte. Par contre, on indiquera comment faire pour utiliser les clients graphiques de la machine hôte.

Le lab Netkit est normalement déjà configuré au niveau de DNS, nous allons l'utiliser, mais nous allons tout d'abord vérifier que chaque machine, et le service DNS, sont bien configurés.

1.1. Rappels sur la configuration

Pour le lecteur qui nous rejoindrait, comme vous le constatez, vous avez raté trois articles. C'est dommage ! Mais ne vous inquiétez pas, vous pouvez retrouver les faits importants, à savoir le schéma du réseau que nous vous proposons, les configurations Netkit et la manière de l'utiliser, sur notre site [FL]. Bien sûr, si vous ne souhaitez connaître que les aspects théoriques, n'hésitez pas à continuer votre lecture, cela n'est en rien bloquant !

• La machine 'S' est serveur DNS, nous n'utiliserons que ce serveur DNS là, pas le secondaire.
• La machine 'C461' est en IPv6 uniquement : 2001:db8:46::61/64.
• La machine 'C462' est en IPv4 uniquement : 192.168.46.62.

Les commandes ci-dessous, réalisées sur les clients 'C461' et 'C462', doivent fonctionner correctement :

et de la même façon pour tous les autres alias www, pop, imap... Par ailleurs, la machine R doit accéder à Internet car nous en aurons besoin.

Si tout vous semble en ordre, nous pouvons démarrer.

2. Le service SSH

Le protocole SSH, pour Secure SHell, permet de faire communiquer deux machines à l'aide d'un client et d'un serveur. Il crée un canal chiffré et permet à l'utilisateur d'avoir accès à un shell sur la machine distante. Sous GNU/Linux et autres Unix, la commande la plus employée est ssh. Sous Microsoft Windows, c'est en général le client libre putty. Cela étant dit, concentrons-nous sur la configuration de SSH sur le serveur S.

La configuration est réalisée dans le fichier : /etc/ssh/sshd_config. Deux paramètres sont en commentaires :

En décommentant l'une des deux lignes, on peut indiquer sur quelle pile IP (4 ou 6) on souhaite que le service fonctionne. En décommentant la première ligne, la commande netstat indiquera :

et en décommentant la deuxième ligne, netsat indiquera :

En ne conservant que cette dernière option, vous ne pourrez pas vous connecter à partir de 'C461' :

Si les deux lignes sont commentées, ce qui est la configuration par défaut, sshd utilisera toutes les interfaces et tous les protocoles. Avant de tenter une connexion, nous lançons un analyseur de trame afin de pouvoir regarder a posteriori ce qui se passe. Nous pouvons tenter une connexion à partir des clients 'C461' et 'C462' vers le serveur (sur Netkit, le mot de passe de root est root) :

et sur l'autre :

Sur le serveur, on identifie bien les sessions IPv4 et IPv6 initiées par les clients :

Revenons sur notre analyseur. En l'occurrence, nous avons employé tshark, mais nous aurions tout aussi bien pu prendre tcpdump ou wireshark :

Nous voyons bien que la connexion depuis C461 s'effectue en IPv6, alors que celle depuis C462, ci-dessous, est effectuée en IPv4 :

Ce premier essai montre que si un service est conçu pour supporter les deux piles de protocoles, comme c'est le cas pour de nombreux démons, la mise en œuvre peut rester assez simple.

2.1. Le problème du séparateur ':' (deux points)

Ce séparateur sert, dans certains cas, à préciser le port de destination. On peut, parfois, utiliser l'option -p pour indiquer le port, comme :

mais ça devient moins lisible pour SSH quand on souhaite, par exemple, créer un tunnel avec une instruction équivalente à :

qui retourne :

Il faut, en fait, mettre l'adresse IPv6 entre crochets (ou alors utiliser le nom de la machine distante). Les instructions deviennent :

et là, effectivement, ça fonctionne.