LINUX:Fichier HOSTS
But
Dans un autre article, nous avions abordé la notion d'adressage IP qui permet d'attribuer une adresse unique et identifiante à chaque machine et matériel connecté à un réseau. Par exemple, une machine a l'adresse 172.217.168.195. Ce n° est similaire à un n° de téléphone. Or il est plus facile pour un humain de retenir un nom qui lui parle plutôt qu'un n°. Pour cette raison, on donne à chaque machine un nom qui nous parle. A l'adresse donnée en exemple plus haut correspond le nom www.google.be.
Nous préférons rechercher un n° de téléphone via le nom de la personne que nous voulons contacter, que de retenir son n°. Anciennement cette recherche se faisait dans un bottin de téléphone. Pour un réseau, il existe un équivalent: le serveur DNS. Au niveau d'Internet, un ensemble de ces serveurs agissent de concert et se répartissent la tâche. Vous pouvez en mettre en place un sur votre réseau local privé mais il n'aura aucun impact sur ceux d'Internet; il ne pourra contenir normalement que la correspondance de vos machines locales et faire appel à ceux d'Internet pour les machines d'Internet.
Dans le contexte d'un réseau local surtout privé ou réduit, on ne trouve pas de serveur DNS local. Et si on en a un, il faut que les machines locales y fassent référence sinon il est inutile. Dans cette situation, nous sommes souvent en présence de peu de machines. Il existe une parade à l’absence de serveur DNS local: le fichier HOSTS. Alors que le serveur DNS a l'avantage d'une mise à jour de ces couples "adresse IP-nom de machine" centralisée, ce fichier HOSTS doit être adapté sur chaque machine qui le nécessite. Pour un nombre réduit de machines (une à cinq), cette tâche n'est pas trop lourde.
Lors d'une recherche, ce fichier "hosts" sera utilisé avant le serveur DNS; si la recherche est couronnée de succès, elle ne va pas plus loin.
Le fichier "hosts"
Ce fichier hosts existe aussi bien sous Windows que sous les différents Unix dont Linux.
Sous Windows (version "32 bits et plus), il se situe dans l'arborescence du système; classiquement on le trouve dans le répertoire C:\windows\system32\drivers\etc.
Sous Unix, il se trouve dans le répertoire /etc.
Par défaut, il ne contient que la correspondance du "localhost" en IPv4 et IPv6.
On ouvre ce fichier texte avec un éditeur de texte simple (surtout pas avec un traitement de texte tel Microsoft Word !!!). On y ajoute autant de lignes que d'adresses IP différentes que l'on désire ajouter. Chaque ligne comprend une adresse IP en première position suivie de son ou ses noms de machine. Chaque champs est séparé du suivant par au moins un espace.
Par exemple, si nous avons la machine "serverdb" dont l'adresse IP est "192.168.1.100" et que nous voulons qu'elle soit connue aussi avec son nom de domaine local "serverdb.home.dom" et en outre que cette machine héberge un serveur WEB dont on désire y accéder via le nom "www.home.dom", on ajoutera dans le fichier "hosts" la ligne suivante.
192.168.1.100 serverdb serverdb.home.dom www.home.dom
Cette recherche a une importance prépondérante dans le cadre d'utilisation de certificats de sécurité. En effet la validation du certificat et donc l'accès au serveur WEB ou MAIL sécurisé par exemple, se fait sur base du nom et non de l'adresse IP.
Un autre cas à signaler est le suivant. Supposons que vous avez dans votre réseau local un serveur WEB connu des serveurs DNS mondiaux et qui est accessible à partie d'Internet.
A partie d'Internet pas de problème, le serveur DNS mondial va fournir en correspondance l'adresse IP publique de votre router de votre ISP (une bbox 3 chez Proximus en Belgique par exemple). Ce router fera la transposition de cette adresse IP publique avec l'adresse IP privée, locale de votre serveur et lui enverra la requête.
Par contre, si vous utilisez votre PC pour accéder à votre serveur WEB qui se trouve sur votre propre réseau local en utilisant son nom Internet, le DNS mondial vous renverra son adresse IP publique et non l'adresse IP locale; ce qui va poser quelques problèmes. Dans ce cas, vous pouvez ajouter au fichier "hosts" son nom public derrière son adresse IP locale pour court-circuiter ce phénomène. Ce problème peut apparaître aussi quand vous voulez utiliser directement sur le serveur WEB un appel local HTTP à des fins de tests ou quand une procédure locale au niveau du serveur WEB générée par de serveur WEB lui-même veut exécuter un module du serveur WEB (appel HTTP), cette astuce est d'un grand secours surtout dans un environnement de multiples serveurs WEB travaillant en "load-balancing".
Par exemple, si le nom public du serveur de notre exemple ci-dessus est "www.adbweb.gslb.eu", le fichier devient:
192.168.1.100 serverdb serverdb.home.dom www.home.dom www.adbweb.gslb.eu
L'autre solution consiste à prévoir l'utilisation de son nom local et de ne pas utiliser son nom public dans un cadre local.