Au début, on retient les adresses. Le NAS en .20, l'hyperviseur en .10, le service de supervision en .35. Puis les services se multiplient, on ajoute des ports, et on finit par tenir une liste dans un fichier texte.
L'étape suivante est généralement le fichier hosts, dupliqué sur chaque machine. Ça fonctionne — jusqu'à la troisième machine, ou le premier changement d'adresse.
Le principe : un résolveur qui fait autorité
La solution consiste à faire tourner sur votre réseau un résolveur qui fait autorité sur votre domaine interne. Toutes les machines l'utilisent comme serveur DNS, distribué automatiquement par le service DHCP.
Il répond lui-même pour vos noms internes, et transmet le reste vers l'extérieur. Une seule modification chez lui se propage instantanément à tout le réseau. Plus de fichiers hosts, plus de duplication.
C'est aussi l'endroit naturel pour un filtrage à l'échelle du réseau, si vous en voulez un — les mêmes outils font souvent les deux.
Le piège du domaine inventé
Vient alors la question du nom. La tentation est d'inventer une extension : quelque chose en .lan, .home ou .local, qui sonne juste et ne coûte rien.
C'est une mauvaise idée, pour deux raisons distinctes.
D'abord, une extension non déléguée aujourd'hui peut être attribuée publiquement demain. Vos noms internes entrent alors en conflit avec de vrais noms de l'internet, avec des symptômes incompréhensibles selon le résolveur interrogé. Ce n'est pas théorique : plusieurs extensions largement utilisées en interne ont fini par exister publiquement.
Ensuite, certaines extensions sont déjà réservées à d'autres usages par les standards — notamment pour la découverte de services sur le réseau local — et les utiliser pour du DNS classique provoque des comportements erratiques, en particulier sur les systèmes Apple.
La réponse propre : un sous-domaine d'un domaine que vous possédez. Vous contrôlez le nom, personne ne vous le prendra, et il vous ouvre la porte des certificats reconnus.
La vue partagée : un nom, deux réponses
Le mécanisme qui rend l'ensemble confortable s'appelle la vue partagée : le même nom répond différemment selon d'où l'on demande.
Depuis chez vous, le résolveur interne renvoie l'adresse privée du service : le trafic reste local, rapide, sans passer par l'extérieur. Depuis n'importe où ailleurs, le DNS public renvoie l'adresse publique, et vous arrivez par le chemin prévu.
L'intérêt est de n'avoir qu'une seule adresse à retenir. Vos favoris fonctionnent à la maison comme en déplacement, sans deux jeux de liens à maintenir.
Cela évite aussi une bizarrerie fréquente : sans cela, une machine du réseau qui demande le nom public obtient l'adresse publique, sort du réseau, et revient — ce qui fonctionne parfois, échoue souvent selon l'équipement, et dégrade toujours les performances.
Les certificats, sans avertissement
Un point qui surprend souvent : un certificat atteste d'un nom, pas d'une adresse. Si votre navigateur demande un nom couvert par le certificat, la validation réussit — que ce nom résolve vers une adresse privée est sans importance.
Vous pouvez donc obtenir un certificat public reconnu pour un service qui n'est jamais exposé à l'internet. La seule contrainte est d'utiliser une validation par DNS plutôt que par accès HTTP, puisque l'autorité ne peut pas joindre votre service.
C'est la façon la plus simple d'obtenir du HTTPS propre en interne, sans déployer une autorité de certification maison sur chaque appareil — exercice qui devient vite pénible dès qu'on ajoute des téléphones ou des appareils dont on ne contrôle pas le magasin de certificats.
Deux pièges d'exploitation
Le DNS chiffré du navigateur. Les navigateurs modernes peuvent envoyer leurs requêtes DNS directement à un résolveur public, en contournant celui du système. Vos noms internes cessent alors de résoudre — mais uniquement dans le navigateur. La résolution fonctionne en ligne de commande, ce qui rend le diagnostic déroutant. Il faut désactiver cette fonction ou la faire pointer vers votre résolveur.
Le résolveur unique. S'il tombe, plus rien ne résout sur le réseau, y compris les noms publics. Le symptôme ressemble à une panne d'internet totale, alors que la connexion fonctionne parfaitement. Deux résolveurs distribués par le DHCP suppriment ce risque. À défaut, gardez au moins un accès par adresse IP à vos équipements critiques : le jour où le DNS tombe, c'est votre seule porte d'entrée.
L'ordre de mise en place
Déclarez d'abord un sous-domaine sur un domaine que vous possédez. Installez ensuite le résolveur et créez quelques entrées de test, sans toucher au DHCP. Vérifiez la résolution en interrogeant explicitement ce résolveur. Ce n'est qu'une fois cela concluant que vous le distribuez par DHCP à l'ensemble du réseau — et vous ajoutez le second en même temps, tant que vous y êtes.
Questions fréquentes
Quel domaine utiliser pour son réseau interne ?
lan.mondomaine.fr. N'inventez pas d'extension : les extensions non déléguées peuvent être attribuées publiquement à tout moment, et vos noms internes entreraient alors en conflit avec de vrais noms de l'internet. C'est déjà arrivé à des extensions largement utilisées en interne. Un sous-domaine que vous contrôlez vous coûte le prix d'un domaine et vous évite définitivement le problème.Qu'est-ce que la vue partagée et à quoi sert-elle ?
Peut-on utiliser un certificat public sur une adresse IP privée ?
nas.lan.mondomaine.fr et que le certificat couvre ce nom, la validation réussit — que le nom résolve vers une adresse privée n'a aucune importance. Il faut simplement obtenir le certificat par une validation DNS, puisque le service n'est pas joignable depuis l'internet.
Commentaires