Guide d'administration système : services IP

Chapitre 10 Présentation détaillée de TCP/IP et IPv4 (référence)

Ce chapitre fournit des informations de référence sur les fichiers de configuration réseau pour les réseaux TCP/IP, notamment les types de réseau, leur objectif et le format d'entrée des fichiers. Les bases de données réseau existantes sont également décrites en détails. En outre, ce chapitre explique comment la structure des adresses IPv4 est définie à partir de classifications réseau et de numéros de sous-réseaux.

Le présent chapitre contient les informations suivantes :

Nouveautés de TCP/IP et IPv4 - présentation détaillée

Dans Solaris 10 7/07, le fichier /etc/inet/ipnodes devient obsolète. Comme expliqué dans chaque procédure, utilisez le chemin /etc/inet/ipnodes uniquement pour les versions précédentes de Oracle Solaris 10.

Fichiers de configuration TCP/IP

Chaque système du réseau obtient ses informations de configuration TCP/IP des fichiers de configuration TCP/IP et bases de données réseau ci-dessous :

fichier /etc/hostname.interface ;
fichier /etc/nodename ;
fichier /etc/defaultdomain ;
fichier /etc/defaultrouter (facultatif) ;
base de données hosts ;
dans Solaris 10 11/06 et les versions antérieures, base de données ipnodes ;
base de données netmasks (facultatif).

Lors de l'installation, le programme d'installation de Oracle Solaris crée ces fichiers. Vous pouvez également les modifier manuellement, comme indiqué dans cette section. Les bases de données réseau hosts et netmasks sont lues par les services de noms disponibles sur les réseaux Oracle Solaris. Le concept de base de données réseau est décrit à la section Bases de données réseau et fichier nsswitch.conf Dans Solaris 10 11/06 et les versions antérieures, pour plus d'informations sur le fichier ipnodes, reportez-vous à la section Base de données ipnodes.

Fichier `/etc/hostname.interface`

Ce fichier définit les interfaces réseau physiques sur l'hôte local. Au moins un fichier /etc/hostname.interface doit exister sur le système local. Le programme d'installation de Oracle Solaris crée un fichier /etc/hostname.interface pour la première interface détectée lors de l'installation. Cette interface possède généralement le plus petit numéro de périphérique, par exemple eri0. Elle constitue l'interface réseau principale. Si le programme d'installation détecte d'autres interfaces, vous pouvez également les configurer au cours du processus d'installation.

Remarque –

Si vous créez d'autres fichiers de nom d'hôte pour la même interface, ces fichiers doivent également suivre le format de nom hostname.[0-9]*, par exemple : hostname.qfe0.a123. Des noms tels que hostname.qfe0.bak ou hostname.qfe0.old ne sont pas valides et seront ignorés par les scripts pendant l'initialisation du système.

Une interface ne doit contenir qu'un seul fichier de nom d'hôte correspondant. Si vous créez un autre fichier de nom d'hôte pour une interface avec un nom de fichier valide, tels que /etc/hostname.qfe et /etc/hostname.qfe.a123 , les scripts d'initialisation tenteront de configurer les données en référençant le contenu des deux fichiers de nom d'hôte et cela peut générer des erreurs. Pour éviter ce genre d'erreurs, indiquez un nom de fichier non valide pour le fichier de nom d'hôte à ne pas utiliser dans la configuration.

Si vous ajoutez une interface réseau supplémentaire au système après l'installation, vous devez créer un fichier /etc/hostname.interface pour cette interface, comme indiqué à la section Configuration d'une interface physique après l'installation du système. En outre, pour que le logiciel Oracle Solaris reconnaisse et utilise la nouvelle interface réseau, le pilote de périphérique de l'interface doit être chargé dans le répertoire correspondant. Reportez-vous à la documentation accompagnant la nouvelle interface réseau pour obtenir le nom d'interface adéquat et les instructions du pilote de périphérique.

Le fichier /etc/hostname.interface de base contient une entrée : l'adresse IPv4 ou le nom d'hôte associé à l'interface réseau. L'adresse IPv4 peut s'exprimer au format décimal avec points classique ou en notation CIDR. Si l'entrée du fichier /etc/hostname.interface est un nom d'hôte, celui-ci doit également se trouver dans le fichier /etc/inet/hosts.

Par exemple, soit smc0 l'interface réseau principale d'un système appelé tenere. L'entrée du fichier /etc/hostname.smc0 peut être une adresse IPv4 selon la numérotation décimale avec points ou en notation CIDR, ou le nom d'hôte tenere.

Remarque –

IPv6 définit les interfaces réseau à l'aide du fichier /etc/hostname6.interface. Pour plus d'informations, reportez-vous à la section Fichier de configuration d'interface IPv6.

Fichier `/etc/nodename`

Ce fichier doit contenir une entrée : le nom d'hôte du système local. Par exemple, sur le système timbuktu, le fichier /etc/nodename contiendrait l'entrée timbuktu.

Fichier `/etc/defaultdomain`

Ce fichier doit contenir une entrée : le nom complet du domaine administratif auquel appartient le réseau de l'hôte local. Vous pouvez fournir ce nom au programme d'installation Oracle Solaris ou modifier le fichier plus tard. Pour plus d'informations sur les domaines de réseau, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .

Fichier `/etc/defaultrouter`

Ce fichier peut contenir une entrée pour chaque routeur directement connecté au réseau. L'entrée doit correspondre au nom de l'interface réseau servant de routeur entre les réseaux. La présence du fichier /etc/defaultrouter indique que le système prend en charge le routage statique.

Base de données `hosts`

La base de données hosts contient les adresses IPv4 et noms d'hôtes des systèmes résidant sur le réseau. Si vous utilisez le service de noms NIS ou DNS, ou le service d'annuaire LDAP, la base de données hosts est mise à jour dans une base de données conçue pour les informations d'hôte. Par exemple, sur un réseau exécutant NIS, la base de données hosts est mise à jour dans le fichier hostsbyname.

Si vous utilisez des fichiers locaux en tant que service de noms, la base de données hosts est mise à jour dans le fichier /etc/inet/hosts. Ce fichier contient les noms d'hôtes et les adresses IPv4 de l'interface réseau principale, des autres interfaces réseau connectées au système et toute autre adresse réseau que le système doit vérifier.

Remarque –

Pour assurer la compatibilité avec les systèmes d'exploitation BSD, le fichier /etc/hosts définit un lien symbolique vers /etc/inet/hosts.

Format de fichier `/etc/inet/hosts`

Le fichier /etc/inet/hosts utilise la syntaxe de base ci-dessous. Pour obtenir les informations complètes relatives à cette syntaxe, reportez-vous à la page de manuel hosts(4).

adresse-IPv4 nom-hôte [pseudo] [#commentaire]

adresse-IPv4: Contient l'adresse IPv4 de chaque interface que l'hôte local doit reconnaître.
nom-hôte: Contient le nom d'hôte attribué au système lors de la configuration, ainsi que les noms d'hôtes attribués aux interfaces réseau supplémentaires que l'hôte local doit reconnaître.
[pseudo]: Champ facultatif contenant un pseudo pour l'hôte.
[#commentaire]: Champ de commentaire facultatif.

Fichier `/etc/inet/hosts` initial

Lors de l'exécution du programme d'installation Oracle Solaris sur un système, le programme configure le fichier /etc/inet/hosts initial. Ce fichier contient les entrées minimales requises par l'hôte local. Les entrées incluent l'adresse loopback, l'adresse IPv4 de l'hôte et le nom d'hôte.

Par exemple, le programme d'installation Oracle Solaris peut créer le fichier /etc/inet/hosts suivant pour le système tenere indiqué dans la Figure 5–1 :

Exemple 10–1 Fichier `/etc/inet/hosts` pour système `tenere`

127.0.0.1     localhost         loghost    #loopback address
192.168.200.3   tenere                      #host name

Adresse loopback

Dans l'Exemple 10–1, l'adresse IPv4 127.0.0.1 constitue l'adresse loopback. L'adresse loopback est l'interface réseau réservée utilisée par le système local pour permettre les communications entre processus. L'hôte utilise cette adresse pour s'envoyer des paquets à lui-même. La commande ifconfig utilise l'adresse loopback pour la configuration et les tests, comme expliqué à la section Contrôle de la configuration de l'interface avec la commande ifconfig. Tout système du réseau TCP/IP doit utiliser l'adresse IP 127.0.0.1 pour le loopback IPv4 sur l'hôte local.

Nom de l'hôte

L'adresse IPv4 192.168.200.1 et le nom tenere constituent l'adresse et le nom d'hôte du système local. Ils sont attribués à l'interface réseau principale du système.

Interfaces réseau multiples

Certains systèmes possèdent plusieurs interfaces réseau, car ils constituent des routeurs ou des hôtes multiréseau. Chaque interface réseau connectée au système requiert sa propre adresse IP et le nom associé. À l'installation, vous devez configurer l'interface réseau principale. Si un système présente plusieurs interfaces lors de l'installation, le programme d'installation Oracle Solaris vous invite à configurer également ces interfaces supplémentaires. Vous pouvez configurer les interfaces supplémentaires ou une partie d'entre elles à l'installation, ou les configurer manuellement plus tard.

Une fois l'installation de Oracle Solaris terminée, vous pouvez configurer des interfaces supplémentaires pour un routeur ou un hôte multiréseau en ajoutant ces informations au fichier /etc/inet/hosts du système. Pour de plus amples informations sur la configuration de routeurs et d'hôtes multiréseau, reportez-vous aux sections Configuration d'un routeur IPv4 et Configuration des hôtes multiréseaux.

L'Exemple 10–2 présente le fichier /etc/inet/hosts du système timbuktu illustré sur la Figure 5–1.

Exemple 10–2 Fichier `/etc/inet/hosts` pour le système `timbuktu`

127.0.0.1        localhost     loghost
192.168.200.70   timbuktu      #This is the local host name
192.168.201.10   timbuktu-201  #Interface to network 192.9.201

Avec ces deux interfaces, timbuktu connecte les réseaux 192.168.200 et 192.168.201 en tant que routeur.

Impact des services de noms sur la base de données `hosts`

Les services de noms NIS et DNS, et le service d'annuaire LDAP mettent à jour les adresses et les noms d'hôtes sur un ou plusieurs serveurs. Ces serveurs mettent à jour les bases de données hosts contenant les informations de tous les hôtes et routeurs (le cas échéant) du réseau du serveur. Pour de plus amples informations sur ces services, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Service de nom assuré par les fichiers locaux

Sur un réseau utilisant des fichiers locaux pour le service de noms, les systèmes s'exécutant en mode de fichiers locaux consultent leurs fichiers /etc/inet/hosts individuels pour connaître les adresses IPv4 et noms d'hôtes des autres systèmes du réseau. Par conséquent, les fichiers /etc/inet/hosts de ces systèmes doivent contenir les informations suivantes :

adresse loopback ;
adresse IPv4 et nom d'hôte du système local (interface réseau principale) ;
adresse IPv4 et nom d'hôte des interfaces réseau supplémentaires connectées à ce système, le cas échéant ;
adresses IPv4 et noms d'hôtes des hôtes résidant sur le réseau local ;
adresses IPv4 et noms d'hôtes de tout routeur que ce système doit connaître, le cas échéant ;
adresse IPv4 de tout système auquel le système doit faire référence via son nom d'hôte.

La Figure 10–1 présente le fichier /etc/inet/hosts du système tenere. Ce système s'exécute en mode fichiers locaux. Comme vous pouvez le constater, le fichier contient les adresses IPv4 et noms d'hôtes de tous les systèmes du réseau 192.9.200. Il contient également l'adresse IPv4 et le nom d'interface timbuktu-201. Cette interface connecte le réseau 192.9.200 au réseau 192.9.201.

Un système configuré en tant que client réseau consulte le fichier local /etc/inet/hosts pour connaître son adresse loopback et son adresse IPv4.

Figure 10–1 Fichier `/etc/inet/hosts` pour un système s'exécutant en mode fichiers locaux

Présente un exemple de fichier d'hôtes pour un système s'exécutant en mode fichiers locaux.

Base de données `ipnodes`

Remarque –

La base de données ipnodes n'est plus incluse dans les versions supérieures à Solaris 10 11/06. Dans ces versions, les fonctions IPv6 de ipnodes migrent vers la base de données hosts.

Le fichier /etc/inet/ipnodes conserve les adresses IPv4 et IPv6. En outre, vous pouvez enregistrer les adresses IPv4 en numérotation décimale avec points classique ou selon la notation CIDR. Ce fichier sert de base de données locale et associe les noms des hôtes à leurs adresses IPv4 et IPv6. N'enregistrez pas les noms d'hôtes ni leurs adresses dans des fichiers statiques, par exemple /etc/inet/ipnodes. Toutefois, à des fins de test, enregistrez les adresses IPv6 dans un fichier de la même façon que les adresses IPv4 sont enregistrées dans /etc/inet/hosts. Le fichier ipnodes applique les mêmes conventions de format que le fichier hosts. Pour de plus amples informations sur /etc/inet/hosts, reportez-vous à la section Base de données hosts. Le fichier ipnodes est décrit dans la page de manuel ipnodes(4).

Les applications compatibles IPv6 font appel à la base de données /etc/inet/ipnodes. La base de données /etc/hosts existante, contenant exclusivement des adresses IPv4, reste identique afin de servir les applications existantes. Si la base de données ipnodes n'existe pas, les applications IPv6 font appel à la base de données hosts existante.

Remarque –

Pour ajouter des adresses IPv4, insérez-les à la fois dans les fichiers hosts et ipnodes. Insérez les adresses IPv6 dans le fichier ipnodes uniquement.

Exemple 10–3 Fichier `/etc/inet/ipnodes`

Groupez les adresses de nom d'hôte selon le nom d'hôte, comme indiqué dans cet exemple.

#
# Internet IPv6 host table
# with both IPv4 and IPv6 addresses
#
::1     localhost
2001:db8:3b4c:114:a00:20ff:fe78:f37c   farsite.com farsite farsite-v6
fe80::a00:20ff:fe78:f37c     farsite-11.com farsitell
192.168.85.87   				 farsite.com farsite farsite-v4
2001:db8:86c0:32:a00:20ff:fe87:9aba   nearsite.com nearsite nearsite-v6
fe80::a00:20ff:fe87:9aba     nearsite-11.com nearsitell
10.0.0.177  				 nearsite.com nearsite nearsite-v4 loghost

Base de données `netmasks`

La base de données netmasks ne doit être modifiée à la configuration du réseau que si vous avez configuré la création de sous-réseaux sur le réseau. La base de données netmasks est constituée d'une liste de réseaux et des masques de sous-réseau associés.

Remarque –

Lors de la création de sous-réseaux, chaque nouveau réseau doit constituer un réseau physiquement distinct. Vous ne pouvez pas appliquer la création de sous-réseaux à un réseau physique unique.

Qu'est-ce que la création de sous-réseaux ?

La création de sous-réseaux permet d'optimiser l'espace d'adressage IPv4 32 bits limité et de réduire la taille des tables de routage d'un interréseau étendu. Quelle que soit la classe d'adresse, la création de sous-réseaux permet d'allouer une partie de l'espace d'adressage hôte à des adresses réseau, afin d'utiliser des réseaux supplémentaires. La partie de l'espace d'adressage hôte allouée aux nouvelles adresses réseau est appelée numéro de sous-réseau.

Outre une utilisation plus efficace de l'espace d'adressage IPv4, la création de sous réseau offre de nombreux avantages administratifs. Le routage peut devenir très compliqué lorsque les réseaux deviennent nombreux. Dans une petite organisation, par exemple, un numéro de classe C peut être attribué à chaque réseau local. Lorsque l'organisation s'étend, l'administration de nombreux numéros de réseau peut devenir complexe. Il s'avère alors judicieux d'allouer quelques numéros de réseau de classe B à chaque grande division de l'organisation. Par exemple, allouez un réseau de classe B au service Ingénierie, un réseau de classe B au service Opérations, etc. Ensuite, vous pouvez diviser chaque réseau de classe B en réseaux supplémentaires, à l'aide des numéros de réseau supplémentaires, obtenus grâce à la création de sous-réseaux. Cette division permet également de réduire le volume d'informations de routage transférées entre les routeurs.

Création du masque de réseau des adresses IPv4

Lors de la création de sous-réseaux, vous devez sélectionner un masque de réseau englobant le réseau. Le masque de réseau détermine les bits de l'espace d'adressage hôte qui représentent le numéro de sous-réseau et les bits qui représentent le numéro d'hôte. Pour rappel, l'adresse IPv4 complète est constituée de 32 bits. Selon la classe d'adresse, de 8 à 24 bits sont disponibles pour représenter l'espace d'adressage hôte. Le masque de réseau est spécifié dans la base de données netmasks.

Si vous souhaitez utiliser des sous-réseaux, définissez le masque de réseau avant de configurer TCP/IP. Si vous souhaitez installer le système d'exploitation au sein d'une configuration réseau, vous devez indiquer le masque du réseau au programme d'installation Oracle Solaris.

Comme décrit à la section Conception d'un schéma d'adressage IPv4, les adresses IP 32 bits se décomposent en une partie réseau et une partie hôte. Les 32 bits sont divisés en 4 octets. Chaque octet est attribué au numéro de réseau ou au numéro d'hôte, selon la classe à laquelle appartient le réseau.

Par exemple, dans une adresse IPv4 de classe B, les 2 octets de gauche sont attribués au numéro de réseau, tandis que les 2 octets de droite sont attribués au numéro d'hôte. Dans l'adresse IPv4 de classe B 172.16.10, vous pouvez attribuer les 2 octets de droite aux hôtes.

Pour implémenter la création de sous-réseaux, vous devez appliquer aux adresses de sous-réseau une partie des bits correspondant aux octets attribués au numéro d'hôte. Par exemple, un espace d'adressage hôte de 16 bits assure l'adressage de 65 534 hôtes. Si vous appliquez le troisième octet aux adresses de sous-réseau et le quatrième octet aux adresses d'hôte, vous pouvez adresser jusqu'à 254 réseaux, contenant chacun 254 hôtes maximum.

Les bits des octets d'adresse hôte appliqués aux adresses de sous-réseau et ceux qui sont appliqués aux adresses d'hôte sont déterminés par un masque de sous-réseau. Les masques de sous-réseau permettent de sélectionner des bits à partir de tout octet pour les utiliser en tant qu'adresses de sous-réseau. Les bits de masque de réseau doivent être contigus, mais ils n'ont pas besoin de s'aligner sur les limites d'octet.

Le masque de réseau peut s'appliquer à une adresse IPv4 à l'aide de l'opérateur de bit logique AND. Cette opération permet de sélectionner les positions du numéro de réseau et du numéro de sous-réseau dans l'adresse.

Les masques de réseau peuvent s'exprimer à l'aide de leur représentation binaire. Vous pouvez effectuer la conversion de notation binaire à décimale à l'aide d'une calculatrice. L'exemple suivant présente les formes binaires et décimales du masque de réseau.

Si le masque de réseau 255.255.255.0 est appliqué à l'adresse IPv4 172.16.41.101, le résultat est l'adresse IPv4 de 172.16.41.0.

172.16.41.101 & 255.255.255.0 = 172.16.41.0

En notation binaire, l'opération est la suivante :

10000001.10010000.00101001.01100101 (adresse IPv4)

AND

11111111.11111111.11111111.00000000 (masque de réseau)

À présent, le système recherche le numéro de réseau 172.16.41 au lieu du numéro de réseau 172.16. Si le réseau possède le numéro 172.16.41, il correspond à ce que le système recherche. Comme vous pouvez attribuer jusqu'à 254 valeurs au troisième octet de l'espace d'adressage IPv4, la création de sous-réseaux permet de créer un espace d'adressage pour 254 réseaux alors que, auparavant, l'espace n'était disponible que pour un réseau.

Si vous fournissez l'espace d'adressage à deux réseaux supplémentaires seulement, vous pouvez utiliser le masque de sous-réseau suivant :

255.255.192.0

Le résultat de ce masque de réseau est le suivant :

11111111.11111111.1100000.00000000

Ce résultat laisse encore 14 bits disponibles pour les adresses hôte. Comme tous les 0 et les 1 sont réservés, au moins 2 bits doivent être réservés pour le numéro d'hôte.

Fichier `/etc/inet/netmasks`

Si le réseau exécute NIS ou LDAP, les serveurs de ces services de noms mettent à jour les bases de données netmasks. Pour les réseaux utilisant des fichiers locaux comme service de noms, cette information est enregistrée dans le fichier /etc/inet/netmasks.

Remarque –

Pour assurer la compatibilité avec les systèmes d'exploitation BSD, le fichier /etc/netmasks correspond à un lien symbolique vers /etc/inet/netmasks.

L'exemple suivant présente le fichier /etc/inet/netmasks d'un réseau de classe B.

Exemple 10–4 Fichier `/etc/inet/netmasks` pour un réseau de classe B

 # The netmasks file associates Internet Protocol (IPv4) address
 # masks with IPv4 network numbers.
 #
 # 	network-number	netmask
 #
 # Both the network-number and the netmasks are specified in
 # “decimal dot” notation, e.g:
 #
 #        128.32.0.0   255.255.255.0
 192.168.0.0  255.255.255.0

Si le fichier /etc/netmasks n'existe pas, créez-le à l'aide d'un éditeur de texte. Utilisez la syntaxe suivante :

network-number	netmask-number

Pour des informations plus détaillées, reportez-vous à la page de manuel netmasks(4).

À la création de numéros de masque de réseau, saisissez le numéro de réseau attribué par le FAI ou l'IR (Internet Registry, registre Internet) (et non le numéro de sous-réseau) et le numéro de masque de réseau dans /etc/inet/netmasks. Chaque masque de sous-réseau doit être spécifié sur une ligne distincte.

Exemple :

128.78.0.0	    255.255.248.0

Vous avez également la possibilité de saisir des noms symboliques correspondant aux numéros de réseau dans le fichier /etc/inet/hosts. Ensuite, vous pouvez utiliser ces noms de réseau au lieu des numéros de réseau en tant que paramètres de commandes.

Démon de services Internet `inetd`

Le démon inetd lance les services Internet standard à l'initialisation du système et peut redémarrer un service lorsque le système est en cours d'exécution. Le SMF (Service Management Facility, utilitaire de gestion de service) permet de modifier les services Internet standard et d'indiquer au démon inetd de démarrer d'autres services, le cas échéant.

Exécutez les commandes SMF suivantes pour gérer les services démarrés par inetd :

svcadm: Permet d'effectuer des tâches administratives sur un service, telle que l'activation, la désactivation et le redémarrage. Pour de plus amples informations, reportez-vous à la page de manuel svcadm(1M).
svcs: Permet d'effectuer des requêtes relatives au statut d'un service. Pour de plus amples informations, reportez-vous à la page de manuel svcs(1).
inetadm: Permet d'afficher et modifier les propriétés d'un service. Pour de plus amples informations, reportez-vous à la page de manuel inetadm(1M).

La valeur du champ proto dans le profil inetadm d'un service particulier indique le protocole de couche de transport sur lequel le service s'exécute. Si le service gère exclusivement des requêtes IPv4, le champ proto doit être défini sur tcp, udp ou sctp.

Les instructions d'utilisation des commandes SMF sont fournies à la section SMF Command-Line Administrative Utilities du System Administration Guide: Basic Administration .
Pour une tâche utilisant les commandes SMF afin d'ajouter un service s'exécutant sur SCTP, reportez-vous à la section Ajout de services utilisant le protocole SCTP.
Pour obtenir des informations sur l'ajout de services gérant à la fois des requêtes IPv4 et des requêtes IPv6, reportez-vous à la section Démon de services Internet inetd

Bases de données réseau et fichier `nsswitch.conf`

Les bases de données réseau sont des fichiers fournissant des informations requises pour configurer le réseau. Les bases de données réseau sont les suivantes :

hosts ;
netmasks ;
base de données ethers ;
bootparams ;
protocols ;
services ;
networks.

À la configuration, vous modifiez les bases de données hosts et netmasks, si le réseau se décompose en sous-réseaux. Deux bases de données réseau, bootparams et ethers, permettent de configurer les systèmes en tant que clients réseau. Les autres bases de données sont employées par le système d'exploitation et requièrent rarement des modifications.

Le fichier nsswitch.conf ne constitue pas une base de données réseau, mais vous devez le configurer avec la base de données réseau adéquate. nsswitch.conf spécifie le service de noms à utiliser pour un système particulier : fichiers locaux, NIS, DNS ou LDAP.

Impact des services de noms sur les bases de données réseau

Le format de la base de données réseau dépend du type de service de noms sélectionné pour le réseau. Par exemple, la base de données hosts contient au moins le nom d'hôte et l'adresse IPv4 du système local, ainsi que toute interface réseau directement connectée au système local. Cependant, la base de données hosts peut contenir d'autres adresses IPv4 et noms d'hôtes, selon le type de service de noms utilisé sur le réseau.

Les bases de données réseau s'utilisent comme suit :

Les réseaux employant des fichiers locaux comme service de noms se basent sur des fichiers des répertoires /etc/inet et /etc.
NIS utilise des bases de données appelées cartes NIS.
DNS utilise les enregistrements avec des informations d'hôte.

Remarque –

Les fichiers de données et d'initialisation DNS ne correspondent pas exactement aux bases de données réseau.

La figure ci-dessous présente les différentes formes de base de données hosts utilisées par ces services de noms.

Figure 10–2 Formes de base de données `hosts` utilisées par les services de noms

Cette figure indique comment les services de noms DNS, NIS, NIS+ et les fichiers locaux stockent les bases de données hôte.

Le tableau ci-dessous répertorie les bases de données réseau, ainsi que les fichiers locaux et cartes NIS correspondants.

Remarque –

La base de données ipnodes a été supprimée des versions Oracle Solaris suivant la version 10 11/06.

Tableau 10–1 Bases de données réseau et fichiers de service de noms correspondants


Base de données réseau	Fichiers locaux	Cartes NIS
`hosts`	`/etc/inet/hosts`	`hosts.byaddr hosts.byname`
`ipnodes`	`/etc/inet/ipnodes`	`ipnodes.byaddr ipnodes.byname`
`netmasks`	`/etc/inet/netmasks`	`netmasks.byaddr`
`ethers`	`/etc/ethers`	`ethers.byname ethers.byaddr`
`bootparams`	`/etc/bootparams`	`bootparams` ;
`protocols`	`/etc/inet/protocols`	`protocols.byname protocols.bynumber`
`services`	`/etc/inet/services`	`services.byname`
`networks`	`/etc/inet/réseaux`	`networks.byaddr networks.byname`

Ce manuel décrit les bases de données réseau telles qu'elles sont perçues par les réseaux utilisant des fichiers locaux pour les services de noms.

Vous trouverez des informations sur la base de données hosts à la section Base de données hosts.
Vous trouverez des informations sur la base de données netmasks à la section Base de données netmasks.
Pour Solaris 10 11/06 et les versions antérieures, vous trouverez des informations sur la base de données ipnodes à la section Base de données ipnodes.

Pour de plus amples informations sur les correspondances de bases de données réseau dans NIS, DNS et LDAP, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Fichier `nsswitch.conf`

Le fichier /etc/nsswitch.conf définit l'ordre de recherche des bases de données réseau. Le programme d'installation Oracle Solaris crée un fichier /etc/nsswitch.conf par défaut pour le système local, selon le service de noms indiqué lors de l'installation. Si vous avez sélectionné l'option Aucun, en indiquant les fichiers locaux à utiliser pour le service de noms, le fichier nsswitch.conf obtenu est similaire à l'exemple ci-dessous.

Exemple 10–5 `nsswitch.conf` pour réseaux utilisant des fichiers pour le service de noms

# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file contains "switch.so" as a
# nametoaddr library for "inet" transports.

passwd:          files
group:           files
hosts:           files
networks:        files
protocols:       files
rpc:             files
ethers:          files
netmasks:        files
bootparams:      files
publickey:       files
# At present there isn't a 'files' backend for netgroup; the
# system will figure it out pretty quickly,
# and won't use netgroups at all.
netgroup:        files
automount:       files
aliases:         files
services:        files
sendmailvars:    files

La page de manuel nsswitch.conf(4) décrit le fichier en détail. La syntaxe de base est la suivante :

base-de-données service-de-noms-à-rechercher

Le champ base-de-données indique l'un des divers types de bases de données recherchés par le système d'exploitation. Par exemple, le champ peut spécifier une base de données affectant les utilisateurs, telle que passwd ou aliases, ou une base de données réseau. Le paramètre nom-de-service-à-rechercher peut prendre les valeurs files, nis ou nis+ pour les bases de données réseau. La base de données hosts peut également rechercher le service de noms dns. Vous avez également la possibilité de répertorier plusieurs services de noms, par exemple nis+ et files.

Dans l'Exemple 10–5, la seule option de recherche indiquée est files. Par conséquent, outre les informations de base de données réseau, les fichiers résidant dans les répertoires /etc et /etc/inet du système local lui fournissent les informations de sécurité et de montage automatique.

Modification de `nsswitch.conf`

Le répertoire /etc contient le fichier nsswitch.conf créé par le programme d'installation Oracle Solaris. Ce répertoire contient également des fichiers de modèles pour les services de noms suivants :

nsswitch.files ;
nsswitch.nis ;

Pour passer d'un service de noms à un autre, copiez le modèle adéquat dans nsswitch.conf. Vous pouvez également modifier le fichier nsswitch.conf et changer le service de noms par défaut pour rechercher individuellement des bases de données.

Par exemple, sur un réseau exécutant NIS, il peut s'avérer nécessaire de modifier le fichier nsswitch.conf sur les clients du réseau. Le chemin de recherche pour les bases de données bootparams et ethers doit indiquer files comme première option, puis nis. L'exemple suivant présente les chemins de recherche corrects.

Exemple 10–6 `nsswitch.conf` pour un client d'un réseau exécutant NIS

# /etc/nsswitch.conf:#
.
.
passwd:        files nis
group:         files nis

# consult /etc "files" only if nis is down.
hosts:         nis    [NOTFOUND=return] files
networks:      nis    [NOTFOUND=return] files
protocols:     nis    [NOTFOUND=return] files
rpc:           nis    [NOTFOUND=return] files
ethers:        files  [NOTFOUND=return] nis
netmasks:      nis    [NOTFOUND=return] files	
bootparams:    files  [NOTFOUND=return] nis
publickey:     nis    
netgroup:      nis

automount:     files nis
aliases:       files nis

# for efficient getservbyname() avoid nis
services:      files nis
sendmailvars:  files

Pour de plus amples informations sur le basculement entre les services de noms, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Base de données `bootparams`

La base de données bootparams contient des informations utilisées par les systèmes configurés pour s'initialiser en mode client réseau. Vous devez modifier cette base de données si le réseau possède des clients réseau. Les procédures sont expliquées à la section Configuration des clients réseau La base de données est élaborée à partir des informations saisies dans le fichier /etc/bootparams.

La page de manuel bootparams(4) indique la syntaxe complète de cette base de données. La syntaxe de base est la suivante :

nom-système fichier-clés nom-serveur:chemin

Pour chaque système client du réseau, l'entrée peut contenir les informations suivantes : le nom du client, une liste de clés, les noms des serveurs et des chemins. Le premier élément de chaque entrée est le nom du système client. Tous les autres éléments sont facultatifs. Reportez-vous à l'exemple ci-dessous.

Exemple 10–7 Base de données `bootparams`

myclient   root=myserver : /nfsroot/myclient  \
swap=myserver : /nfsswap//myclient \
dump=myserver : /nfsdump/myclient

Dans cet exemple, le terme dump= indique aux hôtes client de ne pas rechercher un fichier de vidage.

Entrée de caractère générique pour `bootparams`

Dans la plupart des cas, utilisez l'entrée de caractère générique lors de la modification de la base de données bootparams pour prendre en charge les clients. Cette entrée se présente comme suit :

*  root=server:/path dump=:

L'astérisque (*) indique que cette entrée s'applique à tous les clients non spécifiquement nommés dans la base de données bootparams.

Base de données `ethers`

La base de données ethers est élaborée à partir d'informations entrées dans le fichier /etc/ethers. Cette base de données associe les noms d'hôtes à leurs adresses MAC (Media Access Control, contrôle d'accès média). Ne créez une base de données ethers que si vous exécutez le démon RARP. En d'autres termes, vous devez créer cette base de données si vous configurez des clients réseau.

RARP utilise le fichier pour mapper les adresses MAC aux adresses IP. Si vous exécutez le démon RARP in.rarpd, vous devez configurer le fichier ethers et mettre à jour ce fichier sur tous les hôtes exécutant le démon afin de refléter les modifications réalisées sur le réseau.

La page de manuel ethers(4) indique la syntaxe complète de cette base de données. La syntaxe de base est la suivante :

MAC-address   hostname   #comment

adresse-MAC: Adresse MAC de l'hôte
nom-hôte: Nom officiel de l'hôte
#commentaire: Toute note que vous souhaitez joindre à une entrée du fichier

Le constructeur de l'équipement fournit l'adresse MAC. Si un système n'affiche pas l'adresse MAC lors de l'initialisation du système, reportez-vous aux manuels du matériel pour obtenir de l'aide.

Lors de l'ajout d'entrées à la base de données ethers, assurez-vous que les noms d'hôtes correspondent aux noms principaux dans la base de données hosts et, pour Solaris 10 11/06 et les versions antérieures, la base de données ipnodes, non les pseudos, comme indiqué ci-dessous.

Exemple 10–8 Entrées de la base de données `ethers`

8:0:20:1:40:16  fayoum
8:0:20:1:40:15  nubian 
8:0:20:1:40:7   sahara    # This is a comment
8:0:20:1:40:14  tenere

Autres bases de données réseau

Les autres bases de données réseau ont rarement besoin d'être modifiées.

Base de données `networks`

La base de données networks associe les noms de réseau à des numéros de réseau, afin de permettre à certaines applications d'utiliser et d'afficher les noms au lieu des numéros. La base de données networks se base sur les informations du fichier /etc/inet/réseaux. Ce fichier contient les noms de tous les réseaux auxquels le réseau se connecte via les routeurs.

Le programme d'installation Oracle Solaris configure la base de données networks initiale. Toutefois, si vous ajoutez un réseau à la topologie réseau existante, vous devez mettre à jour cette base de données.

La page de manuel networks(4) contient la syntaxe complète de /etc/inet/networks. Le format de base est le suivant :

network-name  network-number  nickname(s)  #comment

nom-réseau: Nom officiel du réseau
numéro-réseau: Numéro attribué par le FAI ou l'IR (Internet Registry, registre Internet)
pseudo: Tout autre nom appliqué au réseau
#commentaire: Toute note que vous souhaitez joindre à une entrée du fichier

Il est impératif de mettre à jour le fichier networks. Le programme netstat utilise les informations de cette base de données pour générer les tables d'état.

Un exemple de fichier /etc/networks est fourni ci-dessous.

Exemple 10–9 Fichier `/etc/networks`

#ident	"@(#)networks	1.4	92/07/14 SMI"	/* SVr4.0 1.1	*/
#
# The networks file associates Internet Protocol (IP) network
# numbers with network names. The format of this file is:
#
# 	network-name		 	 network-number		 	 nicnames . . .

# The loopback network is used only for intra-machine communication
loopback		 	 127

#
# Internet networks
#
arpanet     10	   arpa  # Historical
#
# local networks

eng   192.168.9 #engineering
acc   192.168.5 #accounting
prog  192.168.2 #programming

Base de données `protocols`

La base de données protocols répertorie les protocoles TCP/IP installés sur le système et leurs numéros de protocole. Le programme d'installation Oracle Solaris crée automatiquement la base de données. Ce fichier requiert rarement des tâches d'administration.

La page de manuel protocols(4) décrit la syntaxe de cette base de données. Un exemple de fichier /etc/inet/protocols est fourni ci-dessous.

Exemple 10–10 Fichier `/etc/inet/protocols`

#
# Internet (IP) protocols
#
ip    0   IP    # internet protocol, pseudo protocol number
icmp  1   ICMP  # internet control message protocol
tcp   6   TCP   # transmission control protocol
udp  17   UDP   # user datagram protocol

Base de données `services`

La base de données services répertorie les noms des services TCP et UDP, ainsi que leurs numéros de port connus. Cette base de données est employée par les programmes faisant appel aux services réseau. La base de données services est créée automatiquement lors de l'installation de Oracle Solaris. En général, cette base de données ne requiert aucune tâche d'administration.

Vous trouverez les informations complètes de syntaxe dans la page de manuel services(4) Un extrait de fichier /etc/inet/services classique est fournit ci-dessous.

Exemple 10–11 Fichier `/etc/inet/services`

#
# Network services
#
echo      7/udp
echo      7/tcp
echo      7/sctp6
discard   9/udp     sink null
discard   11/tcp
daytime   13/udp
daytime   13/tcp
netstat   15/tcp
ftp-data  20/tcp
ftp       21/tcp
telnet    23/tcp
time      37/tcp    timeserver
time      37/udp    timeserver
name      42/udp    nameserver
whois     43/tcp    nickname

Protocoles de routage dans Oracle Solaris

Cette section décrit les protocoles de routage pris en charge par Oracle Solaris 10 : RIP (Routing Information Protocol, protocole d'informations de routage) et RDISC (ICMP Router Discovery, détection de routeur ICMP). RIP et RDISC constituent des protocoles TCP/IP standard. Pour obtenir la liste complète des protocoles de routage de Oracle Solaris 10, reportez-vous au Tableau 5–1 et au Tableau 5–2.

RIP (Routing Information Protocol)

Le protocole RIP est implémenté par le démon de routage in.routed qui démarre à l'initialisation du système. Exécuté sur un routeur avec l'option s, le démon in.routed renseigne la table de routage du noyau en indiquant une route pour chaque réseau accessible et publie l'accessibilité via toutes les interfaces réseau.

Exécuté sur un hôte avec l'option q, le démon in.routed extrait les informations de routage mais ne publie pas l'accessibilité. Sur les hôtes, vous pouvez extraire les informations de routage de deux façons :

Ne spécifiez pas l'indicateur S (S majuscule : mode d'économie d'espace). in.routed construit une table de routage complète exactement de la même manière que sur un routeur.
Spécifiez l'indicateur S. in.routed crée une table de routage minimale pour le noyau, contenant une seule route par défaut pour chaque routeur disponible.

Protocole RDISC (ICMP Router Discovery)

Les hôtes utilisent RDISC pour obtenir les informations de routage des autres routeurs. Par conséquent, lorsque les hôtes exécutent RDISC, les routeurs doivent également exécuter un autre protocole, par exemple RIP, afin d'échanger les informations de routeur.

RDISC est implémenté par le démon in.routed, qui doit s'exécuter à la fois sur les routeurs et sur les hôtes. Sur les hôtes, in.routed utilise RDISC pour détecter les routes par défaut des routeurs qui se publient eux-mêmes via RDISC. Sur les routeurs, in.routed utilise RDISC pour publier les routes par défaut des hôtes sur les réseaux directement connectés. Reportez-vous aux pages de manuel in.routed(1M) et gateways(4).

Classes de réseau

Remarque –

Les numéros de réseau basés sur les classes ne sont plus disponibles auprès de l'IANA, mais de nombreux réseaux existants restent basés sur les classes.

Cette section décrit en détail les classes de réseau IPv4. Chaque classe utilise l'espace d'adressage IPv4 32 bits de manière différente, en attribuant un nombre de bits spécifique à la partie réseau de l'adresse. Il existe trois classes : classe A, classe B et classe C.

Numéros de réseau de la classe A

Dans un numéro de réseau de classe A, les 8 premiers bits correspondent à la partie réseau de l'adresse IPv4.” Les 24 bits suivants contiennent la partie hôte de l'adresse IPv4, comme illustré sur la figure suivante.

Figure 10–3 Allocation des octets dans une adresse de classe A

Le diagramme indique que les bits 0 à 7 correspondent à la partie réseau tandis que les 24 autres bits correspondent à la partie hôte d'une adresse IPv4 32 bits de classe A.

Les valeurs attribuées au premier octet des numéros de réseau de classe A sont définies dans la plage 0–127. Prenons l'exemple de l'adresse IPv4 75.4.10.4. La valeur 75 du premier octet indique que l'hôte se trouve dans un réseau de classe A. Les octets suivants, 4.10.4, établissent l'adresse de l'hôte. Seul le premier octet d'un numéro de classe A est enregistré auprès de l'IANA. L'utilisation des trois octets suivants est laissée à la discrétion du propriétaire du numéro de réseau. Il existe seulement 127 réseaux de classe A. Chacun de ces numéros peut contenir 16 777 214 hôtes maximum.

Numéros de réseau de la classe B

Dans un numéro de réseau de classe B, les 16 premiers bits correspondent au numéro de réseau et les 16 bits suivants au numéro d'hôte. Le premier octet d'un numéro de réseau de classe B est défini dans la plage 128–191. Dans le numéro 172.16.50.56, les premiers octets, 172.16, sont enregistrés auprès de l'IANA et constituent l'adresse réseau. Les deux derniers octets, 50.56, correspondent à l'adresse hôte. Ils sont attribués à la discrétion du propriétaire du numéro de réseau. La figure suivante illustre une adresse de classe B.

Figure 10–4 Allocation des octets dans une adresse de classe B

Le diagramme indique que les bits 0 à 15 correspondent à la partie réseau tandis que les 16 autres bits correspondent à la partie hôte d'une adresse IPv4 32 bits de classe B.

Les adresses de classe B sont souvent attribuées à des organisations dont les réseaux contiennent de nombreux hôtes.

Numéros de réseau de la classe C

Dans un numéro de réseau de classe C, les 24 premiers bits correspondent au numéro de réseau et les 8 bits suivants au numéro d'hôte. Les numéros de réseau de classe C conviennent aux réseaux composés d'un petit nombre d'hôtes n'excédant pas 254. Un numéro de réseau de classe C occupe les trois premiers octets d'une adresse IPv4. Seul le quatrième octet est attribué à la discrétion du propriétaire du réseau. La figure ci-dessous illustre les octets d'une adresse de classe C.

Figure 10–5 Allocation des octets dans une adresse de classe C

Le diagramme indique que les bits 0 à 23 correspondent à la partie réseau tandis que les 8 autres bits correspondent à la partie hôte d'une adresse IPv4 32 bits de classe C.

Le premier octet d'un numéro de réseau de classe C est défini dans la plage 192–223. Les deuxième et troisième octets sont tous les deux compris entre 1 et 255. 192.168.2.5 est un exemple type d'adresse de classe C. Les trois premiers octets, 192.168.2, constituent le numéro de réseau. Le dernier octet, soit 5 dans cet exemple, correspond au numéro d'hôte.

Chapitre 10 Présentation détaillée de TCP/IP et IPv4 (référence)

Nouveautés de TCP/IP et IPv4 - présentation détaillée

Fichiers de configuration TCP/IP

Fichier /etc/hostname.interface

Fichier /etc/nodename

Fichier /etc/defaultdomain

Fichier /etc/defaultrouter

Base de données hosts

Format de fichier /etc/inet/hosts

Fichier /etc/inet/hosts initial

Exemple 10–1 Fichier /etc/inet/hosts pour système tenere

Adresse loopback

Nom de l'hôte

Interfaces réseau multiples

Exemple 10–2 Fichier /etc/inet/hosts pour le système timbuktu

Impact des services de noms sur la base de données hosts

Service de nom assuré par les fichiers locaux

Figure 10–1 Fichier /etc/inet/hosts pour un système s'exécutant en mode fichiers locaux

Base de données ipnodes

Exemple 10–3 Fichier /etc/inet/ipnodes

Base de données netmasks

Qu'est-ce que la création de sous-réseaux ?

Création du masque de réseau des adresses IPv4

Fichier /etc/inet/netmasks

Exemple 10–4 Fichier /etc/inet/netmasks pour un réseau de classe B

Démon de services Internet inetd

Bases de données réseau et fichier nsswitch.conf

Impact des services de noms sur les bases de données réseau

Figure 10–2 Formes de base de données hosts utilisées par les services de noms

Fichier nsswitch.conf

Exemple 10–5 nsswitch.conf pour réseaux utilisant des fichiers pour le service de noms

Modification de nsswitch.conf

Exemple 10–6 nsswitch.conf pour un client d'un réseau exécutant NIS

Base de données bootparams

Exemple 10–7 Base de données bootparams

Entrée de caractère générique pour bootparams

Base de données ethers

Exemple 10–8 Entrées de la base de données ethers

Autres bases de données réseau

Base de données networks

Exemple 10–9 Fichier /etc/networks

Base de données protocols

Exemple 10–10 Fichier /etc/inet/protocols

Base de données services

Exemple 10–11 Fichier /etc/inet/services

Protocoles de routage dans Oracle Solaris

RIP (Routing Information Protocol)

Protocole RDISC (ICMP Router Discovery)

Classes de réseau

Numéros de réseau de la classe A

Figure 10–3 Allocation des octets dans une adresse de classe A

Numéros de réseau de la classe B

Figure 10–4 Allocation des octets dans une adresse de classe B

Numéros de réseau de la classe C

Figure 10–5 Allocation des octets dans une adresse de classe C

Fichier `/etc/hostname.interface`

Fichier `/etc/nodename`

Fichier `/etc/defaultdomain`

Fichier `/etc/defaultrouter`

Base de données `hosts`

Format de fichier `/etc/inet/hosts`

Fichier `/etc/inet/hosts` initial

Exemple 10–1 Fichier `/etc/inet/hosts` pour système `tenere`

Exemple 10–2 Fichier `/etc/inet/hosts` pour le système `timbuktu`

Impact des services de noms sur la base de données `hosts`

Figure 10–1 Fichier `/etc/inet/hosts` pour un système s'exécutant en mode fichiers locaux

Base de données `ipnodes`

Exemple 10–3 Fichier `/etc/inet/ipnodes`

Base de données `netmasks`

Fichier `/etc/inet/netmasks`

Exemple 10–4 Fichier `/etc/inet/netmasks` pour un réseau de classe B

Démon de services Internet `inetd`

Bases de données réseau et fichier `nsswitch.conf`

Figure 10–2 Formes de base de données `hosts` utilisées par les services de noms

Fichier `nsswitch.conf`

Exemple 10–5 `nsswitch.conf` pour réseaux utilisant des fichiers pour le service de noms

Modification de `nsswitch.conf`

Exemple 10–6 `nsswitch.conf` pour un client d'un réseau exécutant NIS

Base de données `bootparams`

Exemple 10–7 Base de données `bootparams`

Entrée de caractère générique pour `bootparams`

Base de données `ethers`

Exemple 10–8 Entrées de la base de données `ethers`

Base de données `networks`

Exemple 10–9 Fichier `/etc/networks`

Base de données `protocols`

Exemple 10–10 Fichier `/etc/inet/protocols`

Base de données `services`

Exemple 10–11 Fichier `/etc/inet/services`