Quel est le fichier réseaux dans windows. Que doit contenir le fichier réseaux

Bon moment, chers lecteurs. Je poste la deuxième partie. La section actuelle se concentre sur implémentation réseau sous linux(comment configurer un réseau sous Linux, comment diagnostiquer un réseau sous Linux et maintenir le sous-système réseau sous Linux).

Configuration de TCP/IP sous Linux pour la mise en réseau Ethernet

Pour travailler avec les protocoles réseau TCP/IP sous Linux, il suffit d'avoir uniquement interface de bouclage, mais si vous devez combiner des hôtes entre eux, vous avez bien sûr besoin d'une interface réseau, de canaux de transmission de données (par exemple, une paire torsadée), éventuellement d'un type d'équipement réseau. De plus, il est nécessaire d'avoir installé (, etc.), généralement fourni au format . Il doit également avoir un réseau (par exemple /etc/hosts) et un support réseau.

Paramètres réseau

Commençons à comprendre les mécanismes de mise en réseau Linux en configurant manuellement le réseau, c'est-à-dire à partir du cas où adresse IP interface réseau statique. Ainsi, lors de la configuration d'un réseau, vous devez prendre en compte et configurer les paramètres suivants :

adresse IP- comme déjà mentionné dans la première partie de l'article - il s'agit d'une adresse unique de la machine, au format de quatre nombres décimaux séparés par des points. Habituellement, lorsque vous travaillez dans réseau local, sélectionné dans des plages privées, par exemple : 192.168.0.1

Masque de sous-réseau- également, 4 nombres décimaux qui déterminent quelle partie de l'adresse fait référence à l'adresse réseau/sous-réseau, et quelle partie à l'adresse hôte. Le masque de sous-réseau est un nombre qui est ajouté (sous forme binaire) à une adresse IP pour savoir à quel sous-réseau appartient l'adresse. Par exemple, l'adresse 192.168.0.2 avec le masque 255.255.255.0 appartient au sous-réseau 192.168.0.

Adresse de sous-réseau- déterminé par le masque de sous-réseau. En même temps, il n'y a pas de sous-réseaux pour les interfaces de bouclage.

Adresse de diffusion- l'adresse utilisée pour envoyer les paquets de diffusion qui seront reçus par tous les hôtes du sous-réseau. Habituellement, il est égal à l'adresse de sous-réseau avec une valeur d'hôte de 255, c'est-à-dire que pour le sous-réseau 192.168.0, la diffusion sera 192.168.0.255, de même, pour le sous-réseau 192.168, la diffusion sera 192.168.255.255. Il n'y a pas d'adresse de diffusion pour les interfaces de bouclage.

Adresse IP de la passerelle est l'adresse de la machine qui est la passerelle par défaut pour la communication avec le monde extérieur. Il peut y avoir plusieurs passerelles si l'ordinateur est connecté à plusieurs réseaux en même temps. L'adresse de la passerelle n'est pas utilisée sur les réseaux isolés (non connectés au WAN), car ces réseaux n'ont nulle part où envoyer des paquets en dehors du réseau, il en va de même pour les interfaces de bouclage.

Adresse IP du serveur de noms (serveur DNS)- adresse du serveur qui convertit les noms d'hôtes en adresses IP. Généralement fourni par le FAI.

Fichiers de paramètres réseau Linux (fichiers de configuration)

Pour comprendre la mise en réseau sous Linux, je vous conseillerais certainement de lire l'article "". En général, tout le travail Linux est basé sur, qui naît lorsque le système d'exploitation démarre et produit ses descendants, qui à leur tour effectuent tout le travail nécessaire, qu'il s'agisse d'exécuter bash ou d'un démon. Oui, et tout le démarrage de Linux est basé sur, qui énonce toute la séquence de lancement de petits utilitaires avec divers paramètres qui sont séquentiellement démarrés / arrêtés lorsque le système démarre / s'arrête. Le sous-système réseau Linux démarre de la même manière.

Chaque distribution Linux a un mécanisme d'initialisation du réseau légèrement différent, mais l'image globale, je pense, après lecture sera claire. Si vous regardez les scripts de démarrage du sous-système réseau de certains Répartition Linux, alors comment configurer la configuration réseau à l'aide des fichiers de configuration deviendra plus ou moins clair, par exemple, dans Debian (nous prendrons cette distribution comme base), le script est responsable de l'initialisation du réseau /etc/init.d/networking en visualisant lequel :

Net-server:~#cat /etc/init.d/networking #!/bin/sh -e ### BEGIN INIT INFO # Fournit : networking # Requis-Start : mountkernfs $local_fs # Requis-Stop : $local_fs # Devrait -Démarrer : ifupdown # Devrait-S'arrêter : ifupdown # Démarrage par défaut : S # Arrêter par défaut : 0 6 # Courte description : Augmenter les interfaces réseau. ### END INIT INFO PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" [ -x /sbin/ifup ] || sortie 0 . /lib/lsb/init-functions process_options() ( [ -e /etc/network/options ] || return 0 log_warning_msg "/etc/network/options existe toujours et il sera IGNORE ! Lisez README.Debian de netbase." ) check_network_file_systems() ( [ -e /proc/mounts ] || return 0 if [ -e /etc/iscsi/iscsi.initramfs ] ; then log_warning_msg "pas de déconfiguration des interfaces réseau : la racine iSCSI est montée." exit 0 fi exec 9<&0 < /proc/mounts while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network devices still mounted." exit 0 ;; esac case $FSTYPE in nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs) log_warning_msg "not deconfiguring network interfaces: network file systems still mounted." exit 0 ;; esac done exec 0<&9 9<&- } check_network_swap() { [ -e /proc/swaps ] || return 0 exec 9<&0 < /proc/swaps while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network swap still mounted." exit 0 ;; esac done exec 0<&9 9<&- } case "$1" in start) process_options log_action_begin_msg "Configuring network interfaces" if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi ;; stop) check_network_file_systems check_network_swap log_action_begin_msg "Deconfiguring network interfaces" if ifdown -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; force-reload|restart) process_options log_warning_msg "Running $0 $1 is deprecated because it may not enable again some interfaces" log_action_begin_msg "Reconfiguring network interfaces" ifdown -a --exclude=lo || true if ifup -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; *) echo "Usage: /etc/init.d/networking {start|stop}" exit 1 ;; esac exit 0

vous pouvez trouver plusieurs fonctions qui vérifient les systèmes de fichiers réseau montés ( check_network_file_systems(), check_network_swap()), ainsi que la vérification de l'existence de certaines configurations encore incompréhensibles /etc/network/options ( fonction processus_options()), et tout en bas, par la conception case "$1" dans et conformément au paramètre saisi (start/stop/force-reload|restart ou tout autre) effectue certaines actions. De ces très certaines actions", l'exemple de l'argument start montre que la fonction est démarrée en premier processus_options, puis la phrase est envoyée au journal Configuration des interfaces réseau, et exécutez la commande ifup -a. Si vous regardez man ifup , vous pouvez voir que cette commande lit la configuration à partir du fichier /etc/network/interfaces et selon la clé -un démarre toutes les interfaces qui ont le paramètre auto.

Les commandes ifup et ifdown peuvent être utilisées pour configurer (ou, respectivement, déconfigurer) les interfaces réseau en fonction des définitions d'interface dans le fichier /etc/network/interfaces.

-a, --all
Si donné à ifup, affecte toutes les interfaces marquées auto. Les interfaces sont affichées dans l'ordre dans lequel elles sont définies dans /etc/network/interfaces. Si donné à ifdown, affecte toutes les interfaces définies. Les interfaces sont descendues dans l'ordre dans lequel elles sont actuellement répertoriées dans le fichier d'état. Seules les interfaces définies dans /etc/network/interfaces seront supprimées.

ip-server:~# cat /etc/network/interfaces # Ce fichier décrit les interfaces réseau disponibles sur votre système # et comment les activer. Pour plus d'informations, consultez interfaces(5). # L'interface réseau de bouclage auto lo iface lo inet loopback # L'interface réseau principale allow-hotplug eth0 iface eth0 inet dhcp allow-hotplug eth2 iface eth2 inet adresse statique 192.168.1.1 masque de réseau 255.255.255.0 passerelle 192.168.1.254 diffusion 192.168.1.255

Dans cette ligne de configuration autoriser hotplug Et auto sont des synonymes et les interfaces seront affichées sur commande ifup -a. C'est en fait toute la chaîne de fonctionnement du sous-système réseau. De même, dans d'autres distributions : dans RedHat et SUSE, le réseau est démarré par un script /etc/init.d/network. Après l'avoir examiné, vous pouvez également trouver où se trouve la configuration du réseau.

/etc/hosts

Ce fichier contient une liste Adresses IP Et les noms d'hôtes qui leur correspondent (adresses).Le format du fichier n'est pas différent du fichier maître :

Serveur IP :~# cat /etc/hosts # ip host.in.domain host 127.0.0.1 localhost 127.0.1.1 ip-server.domain.local ip-server 192.168.1.1 ip-server.domain.local ip-server

Historiquement, ce fichier a été utilisé à la place du service DNS. Actuellement, le fichier peut également être utilisé à la place du service DNS, mais uniquement à condition que le nombre de machines sur votre réseau soit mesuré en unités, et non en dizaines ou en centaines, car dans ce cas, vous devrez contrôler le l'exactitude de ce fichier sur chaque machine.

/etc/nom_hôte

Ce fichier contient Nom d'hôte NetBIOS :

Serveur IP :~# cat /etc/hostname serveur IP

Ce fichier stocke les noms et adresses des réseaux locaux et autres. Exemple:

Serveur IP :~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 home-network 192.168.1.0

Lors de l'utilisation de ce fichier, les réseaux peuvent être gérés par leur nom. Par exemple, ajoutez un itinéraire non ajout d'itinéraire 192.168.1.12 , UN ajout d'itinéraire.

/etc/nsswitch.conf

Le dossier définit ordre de recherche de nom d'hôte/networks, les lignes suivantes sont responsables de ce paramètre :

Pour les hôtes : hôtes : fichiers dns Pour les réseaux : réseaux : fichiers

Paramètre des dossiers spécifie d'utiliser les fichiers spécifiés (/etc/hosts Et /etc/networks respectivement), paramètre DNS spécifie d'utiliser le service DNS.

/etc/host.conf

Le fichier spécifie les options de résolution de nom pour le résolveur

Serveur IP :~# cat /etc/host.conf multi on

Ce fichier indique à la bibliothèque resolv de renvoyer toutes les adresses d'hôtes valides trouvées dans le fichier /etc/hosts, pas seulement la première.

/etc/resolv.conf

Ce fichier définit les paramètres du mécanisme de traduction du nom de réseau en adresse IP. En langage clair définit les paramètres DNS. Exemple:

Serveur IP :~# cat /etc/resolv.conf nameserver 10.0.0.4 nameserver 10.0.0.1 search domain.local

2 premières lignes indiquer les serveurs DNS. La troisième ligne spécifie les domaines de recherche. Si, lors de la résolution d'un nom, le nom n'est pas un nom FQDN, alors ce domaine est remplacé par une "fin". Par exemple, lors de l'exécution de la commande ping host, l'adresse ping est convertie en host.domain.local. D'autres paramètres peuvent être lus dans man resolv.conf . Très souvent, Linux utilise la génération dynamique de ce fichier, en utilisant le soi-disant. programmes /sbin/resolvconf. Ce programme est un intermédiaire entre les services qui fournissent dynamiquement des serveurs de noms (par exemple, Client DHCP) et les services utilisant les données du serveur de noms. Pour utiliser un fichier généré dynamiquement /etc/resolv.conf, vous devez faire de ce fichier un lien symbolique vers /etc/resolvconf/run/resolv.conf. Dans certaines distributions, le chemin peut être différent, cela sera certainement écrit dans résolution homme.

Configuration du réseau

Après vous être familiarisé avec les principaux fichiers de configuration, vous pouvez consulter le fichier . La commande a déjà été mentionnée ci-dessus. si oui, en cas de panne, mais ces outils ne sont pas tout à fait universels, par exemple, dans les distributions RH, ces commandes ne sont pas disponibles par défaut. De plus, les nouvelles distributions disposent d'un nouvel outil de gestion de réseau de haut niveau - , qui appartient au package iproute. A lui (le paquet iproute) je dédierai . Et dans le post actuel, je ne le considérerai pas. Les commandes décrites ci-dessous appartiennent à .

Ainsi, pour être sûr que la commande fonctionnera dans n'importe quelle distribution Linux, vous devez utiliser deux commandes de base à l'ancienne. C'est , et arp. Première équipe (responsable de configuration des interfaces réseau(ip, masque, passerelle), deuxième () - configuration du routage, tierce (arp) - gestion des tables arp. Je voudrais noter que l'exécution de ces commandes sans désactiver le script de démarrage SystemV standard du sous-système réseau n'apportera des modifications que jusqu'au premier redémarrage / redémarrage du service réseau, car. si vous y réfléchissez avec votre cerveau, vous pouvez comprendre que le script /etc/init.d/networking au prochain démarrage, il relira les configurations ci-dessus et appliquera les anciens paramètres. En conséquence, la solution pour définir de manière permanente les paramètres est soit la commande ifconfig avec les paramètres appropriés - entrer dans, soit corriger manuellement les configurations d'interface réseau correspondantes.

De même, si la commande ifconfig avec des options manquantes(par exemple, uniquement l'adresse IP), le reste est complété automatiquement (par exemple, l'adresse de diffusion est ajoutée par défaut avec une adresse d'hôte se terminant par 255 et le masque de sous-réseau par défaut est 255.255.255.0).

Routage pour les interfaces disponibles dans les noyaux modernes est toujours déclenché automatiquement par le noyau. Ou plutôt, les routes directes vers le réseau en fonction des paramètres IP et du sous-réseau dans lequel l'interface surélevée regarde sont formées automatiquement par le noyau. La passerelle de champ (passerelle) pour de telles entrées indique l'adresse de l'interface de sortie ou *. Dans les anciennes versions du noyau (le numéro du noyau à partir duquel les routes ont commencé à monter automatiquement - je ne vous le dirai pas), il était nécessaire d'ajouter la route manuellement.

S'il est nécessaire d'organiser itinéraires, alors vous devez utiliser . Vous pouvez ajouter et supprimer des routes avec cette commande, mais encore une fois, cela ne vous aidera que jusqu'à ce que vous redémarriez /etc/init.d/networking (ou un autre script réseau de votre distribution). Pour que les routes soient ajoutées automatiquement, il est nécessaire, tout comme avec la commande ifconfig, d'ajouter des commandes pour ajouter des routes à rc.local, ou de corriger manuellement les configurations d'interface réseau correspondantes (par exemple, dans Deb - /etc/network/options).

Selon quelles règles les routes vers les réseaux sont formées, J'en suis

Diagnostic réseau Linux

Il existe un grand nombre d'outils de diagnostic réseau sous Linux, souvent très similaires à ceux de Microsoft. Je considérerai 3 principaux utilitaires de diagnostic réseau, sans lesquels il sera difficile d'identifier les problèmes.

Je pense que cet utilitaire est familier à presque tout le monde. Le travail de cet utilitaire est de Envoi en cours soi-disant Paquets ICMP serveur distant, qui sera spécifié dans les paramètres de la commande, le serveur renvoie les commandes envoyées, et pingcompter le temps requis pour que le paquet envoyé atteigne le serveur et revienne. Par exemple:

# ping ya.ru PING ya.ru (87.250.251.3) 56(84) octets de données. 64 octets de www.yandex.ru (87.250.251.3) : icmp_seq=1 ttl=57 time=42.7 ms de www.yandex.ru (87.250.251.3) : icmp_seq=3 ttl=57 time=42.5 ms 64 octets de www .yandex.ru (87.250.251.3): icmp_seq=4 ttl=57 time=42.5 ms 64 octets de www .yandex.ru (87.250.251.3): icmp_seq=5 ttl=57 time=41.9 ms ^C --- ya .ru ping statistiques --- 5 paquets transmis, 5 reçus, 0% de perte de paquets, temps 4012ms rtt min/avg/max/mdev = 41.922/42.588/43.255/0.500ms

Comme on peut le voir dans l'exemple ci-dessus, ping nous donne beaucoup d'informations utiles. Tout d'abord, nous avons découvert que nous pouvons établir une connexion avec l'hôte ya.ru(parfois ils disent que "l'hôte ya.ru est disponible pour nous"). Deuxièmement, on voit ça DNS fonctionne correctement, car le nom "pingé" a été correctement converti en adresse IP (PING ya.ru (87.250.251.3)). Plus loin, dans le champ icmp_seq= définir la numérotation des paquets envoyés. Chaque paquet envoyé se voit attribuer séquentiellement un numéro, et s'il y a des "lacunes" dans cette numérotation, cela nous indiquera que la connexion avec le "ping" est instable, et cela peut également signifier que le serveur auquel les paquets sont envoyés est surchargé. Par valeur temps= nous voyons, combien de temps le colis a-t-il voyagé au 87.250.251.3 et retour. Vous pouvez arrêter l'utilitaire ping en appuyant sur Ctrl+C.

Aussi, utilitaire de ping intéressant en ce sens qu'il peut vous permettre de voir exactement où les problèmes sont survenus. Disons utilitaire de ping affiche un message réseau inaccessible ou autre message similaire. Cela indique très probablement une configuration incorrecte de votre système. Dans ce cas, vous pouvez envoyer des paquets à l'adresse IP du FAI pour savoir où le problème se produit (entre le PC local ou "au-delà"). Si vous êtes connecté à Internet via un routeur, vous pouvez envoyer des paquets à son adresse IP. En conséquence, si le problème apparaît déjà à ce stade, cela indique une configuration incorrecte du système local, ou des dommages au câble, si le routeur répond et que le serveur du fournisseur ne répond pas, alors le problème se situe dans le canal de communication du fournisseur, etc. Enfin, si la conversion du nom en IP échoue, vous pouvez vérifier la connexion sur IP, si les réponses sont correctes, vous pouvez alors deviner que le problème vient du DNS.

Il convient de noter que cet utilitaire n'est pas toujours un outil de diagnostic fiable. Le serveur distant peut bloquer les réponses aux requêtes ICMP.

traceroute

En termes simples, l'équipe s'appelle trace d'itinéraire. Comme vous pouvez le comprendre d'après son nom, cet utilitaire montrera quelle route les paquets sont allés à l'hôte. utilitaire traceroute un peu semblable à ping, mais affiche des informations plus intéressantes. Exemple:

# traceroute ya.ru traceroute vers ya.ru (213.180.204.3), 30 sauts maximum, paquets de 60 octets .kubtelecom.ru (213.132.64.65) 2,761 ms 5,787 ms 5,777 ms 3 13 ms 5,701 ms 5,636 ms 4 (194.186.6.177) 81,430 ms 81,581 ms 81,687 ms 5 6 213.33.201.230 (213.33.201.230) 43.322 ms 41.783 ms 41 106 ms 7 rouge carmin-vlan602.yandex.net (87.250. 242.206) 41.199 ms 42.578 ms 42.610 ms 8 www.yandex.ru (213.180.204.3) 43.185 ms 42.126 ms 42.679 ms

Comme vous pouvez le voir, vous pouvez tracer l'itinéraire du routeur du fournisseur 243-083-free.kubtelecom.ru (213.132.83.243) (sud de la Russie) à l'hôte final sur www.yandex.ru (213.180.204.3) à Moscou.

creuser

Cet utilitaire envoie des requêtes aux serveurs DNS et renvoie des informations sur le domaine spécifié. Exemple:

# creuser @ns.kuban.ru roboti.ru ;<<>> DiG 9.3.6-P1<<>> @ns.kuban.ru roboti.ru ; (1 serveur trouvé) ;; options globales : print cmd ;; j'ai eu la réponse : ;; ->> EN-TÊTE<<- opcode: QUERY, status: NOERROR, id: 64412 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;roboti.ru. IN A ;; ANSWER SECTION: roboti.ru. 448 IN A 72.52.4.90 ;; AUTHORITY SECTION: roboti.ru. 345448 IN NS ns1.sedoparking.com. roboti.ru. 345448 IN NS ns2.sedoparking.com. ;; Query time: 102 msec ;; SERVER: 62.183.1.244#53(62.183.1.244) ;; WHEN: Thu Feb 17 19:44:59 2011 ;; MSG SIZE rcvd: 94

commande de creuser envoyé une demande Serveur dns - ns.kuban.ru (@ns.kuban.ru- ce paramètre est facultatif, dans ce cas la source des informations sur le DNS sera extraite du serveur depuis les paramètres de votre système) concernant le nom de domaine roboti.ru. En conséquence, j'ai reçu une réponse, dans laquelle on peut voir dans la section SECTION DE RÉPONSE informations sur les adresses IP du domaine, dans la section SECTION AUTORITÉ informations sur le soi-disant. serveurs DNS faisant autorité. La troisième ligne à partir du bas nous indique quel serveur a fourni la réponse.

Autres utilitaires de diagnostic

ping, dig et d'autres utilitaires de diagnostic avec des paramètres peuvent être trouvés dans le post.

Connexion d'une nouvelle carte réseau

La connexion et le lancement d'une nouvelle carte réseau se résument à quelques étapes :

1. Connexion physique de la carte

3. Affichez la sortie pour que le système détecte une nouvelle carte réseau :

Voyons la sortie AVANT de connecter une nouvelle carte:

Serveur :~# dmesg | grep eth [ 4.720550] e1000 : eth0 : e1000_probe : connexion réseau Intel(R) PRO/1000 [ 5.130191] e1000 : eth1 : e1000_probe : connexion réseau Intel(R) PRO/1000 [ 15.285527] e1000 : eth2 : e1000_ chien de garde : le lien NIC est Jusqu'à 1 000 Mbps en duplex intégral, contrôle de flux : RX

la sortie montre que le système a 2 cartes réseau eth1 et eth2. Nous connectons le troisième et regardons la sortie :

Serveur :~# dmesg | grep eth [ 4.720513] e1000 : eth0 : e1000_probe : connexion réseau Intel(R) PRO/1000 [ 5.132029] e1000 : eth1 : e1000_probe : connexion réseau Intel(R) PRO/1000 [ 5.534684] e1000 : eth2 : e1000_pro être : Intel(R ) Connexion réseau PRO/1000 [ 39.274875] udev : interface réseau renommée eth2 en eth3 [ 39.287661] udev : interface réseau renommée eth1_rename_ren en eth2 [ 45.670744] e1000 : eth2 : e1000_watchdog : la liaison NIC est active 1 000 Mbps en duplex intégral, contrôle de flux : RX [ 46.237232] e1000 : eth0 : e1000_watchdog : la liaison NIC est active à 1 000 Mbps en duplex intégral, contrôle de flux : RX [ 96.977468] e1000 : eth3 : e1000_watchdog : la liaison NIC est active à 1 000 Mbps en duplex intégral, contrôle de flux : RX

DANS dmesg nous voyons qu'une nouvelle carte réseau est apparue - eth3, qui est en fait eth2, mais a été renommé par le gestionnaire de périphériques udev en eth3, et eth2 est en fait un eth1 renommé (nous parlerons d'udev dans un article séparé). L'apparition de notre nouveau réseau dans dmesg nous dit que la carte réseau prise en charge essentiel et correct décidé. Il ne reste plus qu'à mettre en place une nouvelle interface dans /etc/network/interfaces(Debian) car la carte donnée n'a pas été initialisée par le script de démarrage /etc/init.d/network. ifconfig voit cette carte :

Serveur :~# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 08:00:27:5f:34:ad inet6 addr: fe80::a00:27ff:fe5f:34ad/64 Portée :Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrique : 1 Paquets RX : 311847 erreurs : 0 abandonnées : 0 dépassements : 0 trame : 0 paquets TX : 126 erreurs : 0 abandonnées : 0 dépassements : 0 porteuse : 0 collisions : 0 txqueuelen : 1 000 octets RX : 104670651 (99,8 Mio) 16184 (15,8 Kio)

mais d'ailleurs - ne configure pas. Comment configurer une carte réseau a été discuté ci-dessus.

Résumé

Je pense que c'est tout pour aujourd'hui. Quand j'ai commencé à écrire cet article, je pensais que je tiendrais dans un seul article, mais il s'est avéré énorme. Par conséquent, il a été décidé de diviser l'article en deux. Au total, j'ai essayé d'énoncer, non pas une étape par étape comment configurer le réseau, mais d'énoncer le principe et d'expliquer la compréhension de la façon dont le réseau démarre et fonctionne sous Linux. J'espère vraiment avoir réussi. Je serai heureux de vos commentaires et ajouts. Au fil du temps, je compléterai l'article.

Une fois que vous avez divisé votre réseau en sous-réseaux, vous devez vous préparer à une simple recherche d'adresse par nom à l'aide du fichier /etc/hosts. Si vous n'utilisez pas DNS ou NIS pour cela, vous devez mettre tous les hôtes dans fichier hôte.

Même si vous souhaitez utiliser DNS ou NIS, vous pouvez également avoir un sous-ensemble de noms dans /etc/hosts. Par exemple, si vous voulez avoir une sorte de recherche de nom même lorsque les interfaces réseau ne sont pas en cours d'exécution, comme au démarrage. Ce n'est pas seulement une question de commodité, mais cela vous permet également d'utiliser des noms d'hôte symboliques dans les scripts rc. Ainsi, lors de la modification des adresses IP, vous n'aurez qu'à copier le fichier hosts mis à jour sur toutes les machines au lieu d'éditer de nombreux fichiers rc. En règle générale, vous placerez tous les noms et adresses locaux dans les hôtes en les ajoutant à n'importe quelle passerelle et serveur NIS s'ils sont utilisés.

De plus, lors de la vérification, vous devez vous assurer que le serveur de noms utilise uniquement les informations du fichier hosts. Le logiciel DNS ou NIS peut avoir des exemples de fichiers qui peuvent donner des résultats étranges lorsqu'ils sont utilisés. Pour forcer toutes les applications à utiliser exclusivement /etc/hosts lors de la recherche de l'adresse IP d'un hôte, vous devez modifier le fichier /etc/host.conf. Commentez toutes les lignes commençant par l'ordre des mots clés et collez la ligne :

commander des hôtes

La configuration de la bibliothèque du serveur de noms sera décrite en détail au chapitre 6.

Le fichier hosts contient une entrée par ligne, composée d'une adresse IP, d'un nom d'hôte et d'une liste facultative d'alias. Les champs sont séparés par des espaces ou des tabulations, le champ adresse doit commencer dans la première colonne. Tout ce qui suit le symbole # est traité comme un commentaire et ignoré.

Le nom d'hôte peut être entièrement qualifié ou relatif au domaine local. Pour vale, vous devez entrer le nom complet, vale.vbrew.com , dans hosts , ainsi que vale lui-même, de sorte que le nom officiel et le nom local plus court soient connus.

Un exemple de fichier hosts pour Virtual Brewery est donné ci-dessous. Deux noms spéciaux, vlager-if1 et vlager-if2 , spécifient les adresses des deux interfaces utilisées sur vlager .

Quelle est l'utilisation pratique du fichier /etc/networks ? Autant que je sache, il est possible de spécifier des noms de réseau dans ce fichier. Par exemple:

[courriel protégé]:~# cat /etc/networks default 0.0.0.0 bouclage 127.0.0.0 lien-local 169.254.0.0 google-dns 8.8.4.4 [courriel protégé]:~#

Cependant, si j'essaie d'utiliser ce nom de réseau, par exemple dans l'utilitaire ip, cela ne fonctionne pas :

[courriel protégé]:~# ip route add google-dns via 104.236.63.1 dev eth0 Erreur : un préfixe inet est attendu plutôt que "google-dns". [courriel protégé]:~# route ip ajouter 8.8.4.4 via 104.236.64.1 dev eth0 [courriel protégé]:~#

Quelle est l'utilisation pratique du fichier /etc/networks ?

2 Les solutions collectent le formulaire Web pour "l'utilisation pratique du fichier /etc/networks"

Comme indiqué dans la page de manuel, le fichier /etc/networks doit décrire les noms symboliques des réseaux. Avec un réseau, cela signifie une adresse réseau avec un .0 à la fin. Seuls les réseaux simples de classe A, B ou C sont pris en charge.

Dans votre exemple, l'entrée google-dns est erronée. Ce n'est pas le réseau A, B ou C. C'est une relation adresse IP-nom d'hôte, donc il appartient à /etc/hosts . En fait, l'entrée par défaut ne correspond pas non plus.

Disons que vous avez une adresse IP de 192.168.1.5 de votre réseau d'entreprise. Une entrée dans /etc/network pourrait être :

Nom de l'entreprise 192.168.1.0

Lorsque vous utilisez des utilitaires tels que route ou netstat , ces réseaux sont traduits (sauf si vous supprimez l'autorisation avec l'indicateur -n). La table de routage pourrait ressembler à ceci :

Table de routage IP du noyau Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 corpname * 255.255.255.0 U 0 0 0 eth0

La commande ip n'utilise jamais le nom d'hôte pour l'entrée, donc votre exemple importe peu. De plus, vous mettez le nom d'hôte dans /etc/networks , pas le nom de réseau !

Les entrées dans /etc/networks sont utilisées par des outils qui tentent de convertir des nombres en noms, comme la commande route (obsolète). Sans une entrée appropriée, il affiche :

# route Table de routage IP du noyau Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.254.0 U 0 0 0 eth0

Si nous ajoutons maintenant la ligne mylocalnet 192.168.0.0 à /etc/networks :

# route Table de routage IP du noyau Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 mylocalnet * 255.255.254.0 U 0 0 0 eth0

En pratique, cela n'est jamais utilisé.

Aller!

Le protocole NFS (Network File Server) est une norme ouverte permettant à un utilisateur d'accéder à distance aux systèmes de fichiers. Sur cette base, les systèmes de fichiers centralisés facilitent l'exécution de tâches quotidiennes telles que les sauvegardes ou les vérifications de virus, et les partitions de disque concaténées sont plus faciles à entretenir que de nombreuses partitions petites et distribuées.

En plus de fournir un stockage centralisé, NFS s'est avéré très utile pour d'autres applications, notamment les clients légers et sans disque, le clustering réseau et le middleware collaboratif.

Une meilleure compréhension à la fois du protocole lui-même et des détails de sa mise en œuvre facilitera le traitement des problèmes pratiques. Cet article est consacré à NFS et se compose de deux parties logiques : d'abord, le protocole lui-même et les objectifs fixés lors de son développement sont décrits, puis l'implémentation de NFS sous Solaris et UNIX.

OÙ TOUT A COMMENCÉ...

Le protocole NFS a été développé par Sun Microsystems et est apparu sur Internet en 1989 sous le nom de RFC 1094 sous le titre suivant : Network File System Protocol Specification (NFS). Il est intéressant de noter que la stratégie de Novell à l'époque était d'améliorer encore les services de fichiers. Jusqu'à récemment, alors que le mouvement open source battait son plein, Sun ne voulait pas révéler les secrets de ses solutions réseau, mais même alors, l'entreprise avait compris l'importance de l'interopérabilité avec d'autres systèmes.

La RFC 1094 contenait deux spécifications originales. Au moment de sa publication, Sun développait la troisième version suivante de la spécification, qui est définie dans la RFC 1813 "NFS Protocol Specification, Version 3" (NFS Version 3 Protocol Specification). La version 4 de ce protocole est définie dans RFC 3010 NFS Protocol Specification Version 4 (NFS Version 4 Protocol).

NFS est largement utilisé sur tous les types d'hôtes UNIX, les réseaux Microsoft et Novell et les solutions IBM telles que AS400 et OS/390. Inconnu en dehors du domaine du réseau, NFS est sans doute le système de fichiers réseau indépendant de la plate-forme le plus largement utilisé.

UNIX ÉTAIT LE GÉNÉRATEUR

Bien que NFS soit un système indépendant de la plate-forme, UNIX en est l'ancêtre. En d'autres termes, l'architecture hiérarchique et les méthodes d'accès aux fichiers, y compris la structure du système de fichiers, la manière dont les utilisateurs et les groupes sont identifiés et la manière dont les fichiers sont traités, sont toutes très similaires au système de fichiers UNIX. Par exemple, le système de fichiers NFS, dont la structure est identique à système de fichiers UNIX est monté directement dessus. Lorsque vous travaillez avec NFS sur d'autres systèmes d'exploitation, les identités des utilisateurs et les autorisations de fichiers sont mappées.

NFS

Le système NFS est conçu pour être utilisé dans une architecture client-serveur. Le client accède au système de fichiers exporté par le serveur NFS via un point de montage sur le client. Un tel accès est généralement transparent pour l'application cliente.

Contrairement à de nombreux systèmes client/serveur, NFS utilise des appels de procédure à distance (RPC) pour échanger des informations. Typiquement, le client établit une connexion à un port connu puis, conformément au protocole, envoie une demande pour effectuer une certaine action. Dans le cas d'un appel de procédure distant, le client crée un appel de procédure puis l'envoie au serveur pour exécution. Une description détaillée de NFS sera présentée ci-dessous.

Par exemple, supposons qu'un client ait monté le répertoire usr2 sur le système de fichiers racine local :

/root/usr2/ -> distant :/root/usr/

Si une application cliente a besoin des ressources de ce répertoire, elle envoie simplement une demande au système d'exploitation pour celui-ci et pour le nom du fichier, qui permet l'accès via le client NFS. Par exemple, considérez la simple commande UNIX cd, qui "ne sait rien" des protocoles réseau. Équipe

Cd /racine/usr2/

placera le répertoire de travail sur le système de fichiers distant sans "même savoir" (l'utilisateur n'a pas besoin de savoir non plus) que le système de fichiers est distant.

Dès réception de la requête, le serveur NFS vérifiera si l'utilisateur donné a le droit d'effectuer l'action demandée et, si la réponse est positive, l'exécutera.

APPRENONS A MIEUX CONNAÎTRE

Du point de vue du client, le processus de montage local d'un système de fichiers distant à l'aide de NFS se compose de plusieurs étapes. Comme déjà mentionné, le client NFS soumettra un appel de procédure à distance pour l'exécuter sur le serveur. Notez que sous UNIX, le client est un programme unique (la commande mount), tandis que le serveur est en fait implémenté sous la forme de plusieurs programmes avec l'ensemble minimal suivant : port mapper service (port mapper), mount daemon (mount daemon) et NFS server .

La commande mount du client communique d'abord avec le service de traduction de port du serveur, qui écoute les demandes sur le port 111. La plupart des implémentations de la commande mount du client prennent en charge plusieurs versions de NFS, ce qui rend plus probable que le client et le serveur trouvent une version de protocole commune. La recherche est effectuée à partir de la version la plus ancienne, donc lorsqu'une version commune est trouvée, elle deviendra automatiquement la version la plus récente prise en charge par le client et le serveur.

(Ce matériel se concentre sur la troisième version de NFS, car c'est la plus courante pour le moment. La quatrième version n'est pas encore prise en charge par la plupart des implémentations.)

Le service de traduction du port du serveur répond aux requêtes en fonction du protocole pris en charge et du port sur lequel le démon de montage s'exécute. Le programme de montage du client établit d'abord une connexion avec le démon de montage du serveur, puis lui envoie la commande de montage via RPC. Si cette procédure réussit, l'application cliente se connecte au serveur NFS (port 2049) et, à l'aide de l'une des 20 procédures distantes définies dans la RFC 1813 et répertoriées dans le tableau 1, accède au système de fichiers distant.

La signification de la plupart des commandes est intuitive et ne pose aucune difficulté aux administrateurs système. La liste suivante, produite à l'aide de tcdump, illustre la commande read utilisée par la commande UNIX cat pour lire un fichier nommé test-file :

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049 : 144 recherche fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049 : 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3476097947 : réponse ok 128 lookup fh 32.0/22 4307 (DF) 10h30 : 16.012729 eth0 192.168.1.254.3476097947 : réponse ok 128 recherche fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049 : 140 lecture fh 32.0/ 224307 4096 octets @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049 : 140 lecture fh 32.0/ 224307 4096 octets @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163 : réponse ok 108 lecture (DF) 10 : 30:16.013650 eth0 192.168.1.254.3492875163 : réponse ok 108 lu (DF)

NFS a traditionnellement été implémenté sur UDP. Cependant, certaines versions de NFS prennent en charge TCP (la prise en charge de TCP est définie dans la spécification du protocole). Le principal avantage de TCP est un mécanisme de retransmission plus efficace dans les réseaux non fiables. (Dans le cas d'UDP, si une erreur se produit, alors le message RPC complet, composé de plusieurs paquets UDP, est retransmis. Avec TCP, seul le fragment corrompu est retransmis.)

ACCÈS AU NFS

Les implémentations NFS prennent généralement en charge quatre méthodes d'octroi d'accès : via les attributs utilisateur/fichier, au niveau du partage, au niveau du nœud maître et en tant que combinaison d'autres méthodes d'accès.

La première méthode est basée sur la fonction intégrée système UNIX autorisations de fichiers pour un utilisateur individuel ou un groupe. Pour simplifier la maintenance, l'identification des utilisateurs et des groupes doit être cohérente sur tous les clients et serveurs NFS. La sécurité doit être soigneusement prise en compte : NFS peut accorder par inadvertance un accès à des fichiers qui n'était pas prévu lors de leur création.

L'accès aux ressources partagées vous permet de limiter les droits à certaines actions uniquement, indépendamment de la propriété du fichier ou des privilèges UNIX. Par exemple, l'utilisation du système de fichiers NFS peut être limitée à la lecture seule. La plupart des implémentations de NFS vous permettent de restreindre davantage l'accès au niveau des ressources partagées à des utilisateurs et/ou groupes spécifiques. Par exemple, le groupe des ressources humaines est autorisé à afficher des informations et rien de plus.

L'accès au niveau maître vous permet de monter un système de fichiers uniquement sur des nœuds spécifiques, ce qui est généralement une bonne idée car les systèmes de fichiers peuvent facilement être créés sur n'importe quel nœud prenant en charge NFS.

L'accès combiné combine simplement les types ci-dessus (par exemple, l'accès au niveau du partage avec l'accès accordé à un utilisateur spécifique) ou permet aux utilisateurs d'accéder à NFS uniquement à partir d'un hôte spécifique.

STYLE PINGOUIN NFS

Le matériel lié à Linux présenté ici est basé sur un système Red Hat 6.2 avec la version 2.4.9 du noyau, qui est livré avec la version 0.1.6 du paquet nfs-utils. Des versions plus récentes existent également : au moment d'écrire ces lignes, la mise à jour la plus récente du paquet nfs-utils est la 0.3.1. Il est téléchargeable sur : .

Le package nfs-utils contient les éléments suivants fichiers exécutables: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount et statd.

Malheureusement, la prise en charge de NFS est parfois déroutante pour les administrateurs Linux, car la disponibilité d'une fonctionnalité particulière dépend directement des numéros de version du noyau et du package nfs-utils. Heureusement, les choses s'améliorent maintenant dans ce domaine : les derniers kits de distribution incluent les dernières versions des deux. Pour les versions précédentes, voir la section 2.4 du NFS-HOWTO pour une liste complète Fonctionnalité systèmes disponibles pour chaque combinaison de noyau et de package nfs-utils. Les développeurs maintiennent la rétrocompatibilité du package avec les versions antérieures, accordant une grande attention à la sécurité et à la correction des bogues logiciels.

La prise en charge de NFS doit être lancée au moment de la compilation du noyau. Si nécessaire, la possibilité de travailler avec la version 3 de NFS doit également être ajoutée au noyau.

Pour les distributions prenant en charge linuxconf, il est facile de configurer les services NFS pour les clients et les serveurs. Cependant, le moyen rapide de configurer NFS à l'aide de linuxconf ne fournit pas d'informations sur les fichiers qui ont été créés ou modifiés, ce qui est très important pour l'administrateur en cas de défaillance du système. L'architecture de NFS sur Linux est faiblement couplée à la version BSD, de sorte que les fichiers et programmes de support nécessaires sont faciles à trouver pour les administrateurs exécutant BSD, Sun OS 2.5 ou des versions antérieures de NFS.

Le fichier /etc/exports, comme dans les versions antérieures de BSD, spécifie les systèmes de fichiers auxquels les clients NFS sont autorisés à accéder. De plus, il contient un certain nombre caractéristiques supplémentaires liées aux problématiques de gestion et de sécurité, offrant à l'administrateur un outil de mise au point. Ce fichier texte, composé d'entrées, de lignes vides ou de lignes commentées (les commentaires commencent par #).

Disons que nous voulons donner aux clients un accès en lecture seule au répertoire /home sur l'hôte Lefty. Cela correspondrait à l'entrée suivante dans /etc/exports :

/maison (ro)

Ici, nous devons dire au système quels répertoires nous allons rendre disponibles en utilisant le démon de montage rpc.mountd :

# exportfs -r exportfs : aucun nom d'hôte spécifié dans /home (ro), tapez *(ro) pour éviter les avertissements #

Lorsqu'elle est exécutée, la commande exportfs avertit que /etc/exports ne limite pas l'accès à un nœud particulier et crée une entrée correspondante dans /var/lib/nfs/etab à partir de /etc/exports vous indiquant quelles ressources peuvent être visualisées avec cat :

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Les autres options répertoriées dans etab incluent les valeurs par défaut utilisées par NFS. Les détails seront décrits ci-dessous. Pour accorder l'accès au répertoire /home, les services NFS appropriés doivent être démarrés :

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

À tout moment après le démarrage du démon de montage (rpc.mountd), vous pouvez vous renseigner sur les fichiers individuels disponibles pour la sortie en affichant le contenu du fichier /proc/fs/nfs/exports :

# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

La même chose peut être visualisée à l'aide de la commande showmount avec l'option -e :

# showmount -e Exporter la liste pour gaucher : /home (tout le monde) #

En allant un peu plus loin, la commande showmount peut également être utilisée pour déterminer tous les systèmes de fichiers montés, ou en d'autres termes, pour savoir quels hôtes sont des clients NFS pour le système exécutant la commande showmount. La commande showmount -a répertorie tous les points de montage client :

# showmount -a Tous les points de montage sur lefty : 192.168.1.252:/home #

Comme indiqué ci-dessus, la plupart des implémentations NFS prennent en charge diverses versions de ce protocole. L'implémentation Linux vous permet de limiter la liste des versions NFS qui s'exécuteront en spécifiant l'option -N pour le démon de montage. Par exemple, pour démarrer NFS version 3, et uniquement la version 3, saisissez la commande suivante :

# rpc.mountd -N 1 -N 2

Les utilisateurs exigeants peuvent trouver gênant que sous Linux, le démon NFS (rpc.nfsd) attende les packages des versions 1 et 2, bien que cela ait l'effet souhaité de ne pas prendre en charge le protocole correspondant. Espérons que les développeurs des prochaines versions apporteront les corrections nécessaires et pourront parvenir à une plus grande cohérence entre les composants du package par rapport aux différentes versions du protocole.

"NAGER AVEC LES PINGOUINS"

L'accès au système de fichiers exportable NFS basé sur Linux Lefty configuré ci-dessus dépend du système d'exploitation client. Style de paramètres pour la plupart des systèmes d'exploitation Familles UNIX correspond au style des systèmes Sun OS et BSD d'origine ou du nouveau Solaris. Étant donné que cet article se concentre à la fois sur Linux et Solaris, examinons la configuration du client Solaris 2.6 du point de vue de l'établissement d'une connexion à la version Linux de NFS décrite ci-dessus.

Grâce aux fonctionnalités héritées de Solaris 2.6, il est facile de le configurer pour agir en tant que client NFS. Cela ne nécessite qu'une seule commande :

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

En supposant que la commande de montage précédente a réussi, la commande de montage sans option affichera ce qui suit :

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Lun 3 sept. 23:19:25 2001

Analysons la sortie tcpdump sur l'hôte Lefty après que l'utilisateur a saisi la commande ls /tmp/tmp2 sur l'hôte Sunny :

# tcpdump host lefty et host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs : 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny. 2191983953 : réponse ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs : 132 access fh Unknown/10001 (DF) 06:07:4 3.491463 gaucher . mcwrite.n.nfs > sunny.2191983954 : réponse ok 120 access c0001 (DF) 06:07:43.492296 00 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955 : réponse ok 1000 readdirplus ( DF)

Nous voyons que le nœud Sunny demande un descripteur de fichier (fh) pour ls, auquel le nœud Lefty envoie OK en réponse et renvoie la structure du répertoire. Sunny vérifie ensuite l'autorisation du contenu du répertoire (132 access fh) et reçoit une réponse d'autorisation de Lefty. Le Sunny Node lit ensuite le contenu complet du répertoire à l'aide de la procédure readdirplus. Les appels de procédure distante sont décrits dans la RFC 1813 et sont répertoriés au début de cet article.

Bien que la séquence de commandes pour accéder aux systèmes de fichiers distants soit très simple, un certain nombre de circonstances peuvent entraîner un montage incorrect du système. Avant de monter un répertoire, le point de montage doit déjà exister, sinon il doit être créé à l'aide de la commande mkdir. Généralement, la seule cause d'erreur côté client est l'absence d'un répertoire de montage local. La plupart des problèmes associés à NFS, cependant, doivent leur origine à une incompatibilité entre le client et le serveur, ou à une configuration serveur incorrecte.

Le moyen le plus simple de résoudre les problèmes sur un serveur consiste à partir de l'hôte sur lequel le serveur s'exécute. Cependant, lorsque quelqu'un d'autre administre le serveur à votre place, cela n'est pas toujours possible. Voie rapide assurez-vous que les services de serveur appropriés sont correctement configurés - utilisez la commande rpcinfo avec l'option -p. Depuis l'hôte Solaris Sunny, vous pouvez déterminer quels processus RPC sont enregistrés sur l'hôte Linux :

# rpcinfo -p 192.168.1.254 programme vers service de port proto 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 état udp 692 100024 1 état tcp 694 100005 3 udp 102 4 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Notez que les informations de version sont également fournies ici, ce qui est très utile lorsque le système nécessite la prise en charge de divers protocoles NFS. Si un service n'est pas en cours d'exécution sur le serveur, cette situation doit être corrigée. Si le montage échoue, la commande rpcinfo -p suivante vous indiquera que le service mountd sur le serveur est arrêté :

# rpcinfo -p 192.168.1.254 programme vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

La commande rpcinfo est très utile pour savoir si un processus distant particulier est actif. L'option -p est la plus importante des options. Voir la page de manuel pour toutes les fonctionnalités de rpcinfo.

Un autre outil utile est la commande nfsstat. Avec son aide, vous pouvez savoir si les clients accèdent réellement au système de fichiers exporté, ainsi qu'afficher des informations statistiques en fonction de la version du protocole.

Enfin, un autre outil assez utile pour déterminer les causes des pannes du système est tcpdump :

# hôte tcpdump lefty et hôte sunny -s512 tcpdump : écoute sur eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020 : réponse ok 116 recherche ERREUR : aucun fichier ou répertoire de ce type (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs : 128 getattr fh Inconnu/1 ( DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021 : réponse ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite .n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022 : réponse ok 116 lookup ERROR : No such file or directory (DF) 06:29 : 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs : 184 créer fh Inconnu/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023 : réponse ok 120 créer ERREUR : Autorisation refusée (DF)

La liste ci-dessus, obtenue après l'exécution de l'instruction touch test.c, montre la séquence d'actions suivante : d'abord, la commande touch tente d'accéder à un fichier nommé test.c, puis elle recherche un répertoire portant le même nom, et après un échec tentatives, il essaie de créer le fichier test.c , qui échoue également.

Si le système de fichiers est monté, la plupart des erreurs courantes sont liées aux autorisations UNIX normales. L'utilisation par Sun de uid ou NIS+ évite de définir des autorisations globalement sur tous les systèmes de fichiers. Certains administrateurs pratiquent des répertoires "ouverts", où les autorisations de les lire sont données au "monde entier". Cependant, cela devrait être évité pour des raisons de sécurité. Au-delà des problèmes de sécurité, cela reste une mauvaise pratique car les utilisateurs créent rarement des données dans le but de les rendre lisibles par tout le monde.

Les accès d'un utilisateur privilégié (root) aux systèmes de fichiers montés NFS sont traités différemment. Pour éviter d'accorder un accès illimité à un utilisateur privilégié, les demandes de l'utilisateur privilégié sont traitées comme si elles provenaient de l'utilisateur "personne". Ce mécanisme puissant limite l'accès des utilisateurs privilégiés aux fichiers accessibles en lecture et en écriture dans le monde entier.

SERVEUR NFS, VERSION SOLARIS

Configurer Solaris pour agir en tant que serveur NFS est aussi simple qu'avec Linux. Cependant, les commandes et les emplacements des fichiers sont légèrement différents. Lorsque Solaris démarre, lorsque le niveau de démarrage 3 est atteint, les services NFS sont automatiquement démarrés et tous les systèmes de fichiers sont exportés. Pour démarrer ces processus manuellement, saisissez la commande :

#/usr/lib/nfs/mountd

Pour démarrer le démon de montage et le serveur NFS, tapez :

#/usr/lib/nfs/nfsd

À partir de la version 2.6, Solaris n'utilise plus de fichier d'exportation pour spécifier les systèmes de fichiers à exporter. Les fichiers sont maintenant exportés à l'aide de la commande share. Supposons que nous voulions autoriser les hôtes distants à monter /export/home. Pour ce faire, saisissez la commande suivante :

Partager -F nfs /export/home

Mesures de sécurité

SÉCURITÉ SOUS LINUX

Certains services système NFS basés sur Linux disposent d'un mécanisme supplémentaire pour restreindre l'accès via des listes de contrôle ou des tables. Au niveau interne, ce mécanisme est implémenté à l'aide de la bibliothèque tcp_wrapper, qui utilise deux fichiers pour former des listes de contrôle d'accès : /etc/hosts.allow et /etc/hosts/deny. Un aperçu exhaustif des règles d'utilisation de tcp_wrapper dépasse le cadre de cet article, mais le principe de base est le suivant : la correspondance se fait d'abord avec etc/hosts.allow, puis avec /etc/hosts. refuser. Si la règle n'est pas trouvée, le service système demandé n'est pas présenté. Pour contourner la dernière exigence et fournir un très haut niveau de sécurité, vous pouvez ajouter l'entrée suivante à la fin de /etc/hosts.deny :

TOUS : tous

Après cela, /etc/hosts.allow peut être utilisé pour définir tel ou tel mode de fonctionnement. Par exemple, le fichier /etc/hosts. allow , que j'ai utilisé lors de la rédaction de cet article, contenait les lignes suivantes :

lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192 .168.1.0/255.255.255.0

Cela permet un certain type d'accès aux nœuds avant d'accorder l'accès au niveau de l'application. DANS Accès Linux au niveau de l'application, le fichier /etc/exports contrôle. Il se compose d'entrées au format suivant :

Répertoire d'exportation (espace) host|network(options)

Un "répertoire exporté" est un répertoire pour lequel le démon nfsd est autorisé à traiter une demande. "Host|Network" est l'hôte ou le réseau qui a accès au système de fichiers exporté, et "options" détermine les restrictions que le démon nfsd impose à l'utilisation de cette ressource partagée - accès en lecture seule ou mappage d'ID utilisateur.

L'exemple suivant accorde à l'ensemble du domaine mcwrite.net un accès en lecture seule à /home/mcwrite.net :

/home/mcwrite.net *.mcwrite.net(ro)

Plus d'exemples peuvent être trouvés dans la page de manuel des exportations.

SÉCURITÉ NFS DANS SOLARIS

Dans Solaris, la possibilité de fournir un accès NFS est similaire à Linux, mais dans ce cas, les restrictions sont définies à l'aide de certaines options de la commande share avec le commutateur -o. L'exemple suivant montre comment activer le montage en lecture seule de /export/mcwrite.net sur n'importe quel hôte du domaine mcwrite.net :

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

La page de manuel share_nfs détaille comment accorder l'accès à l'aide de listes de contrôle sur Solaris.

Ressources Internet

NFS et RPC n'étaient pas sans "trous". De manière générale, NFS ne doit pas être utilisé sur Internet. Vous ne pouvez pas "percer" les pare-feu en autorisant l'accès de n'importe quel type via NFS. Tous les correctifs RPC et NFS doivent être étroitement surveillés et de nombreuses sources d'informations sur la sécurité peuvent vous aider. Les deux sources les plus populaires sont Bugtraq et CERT :

Le premier peut être consulté régulièrement à la recherche des informations nécessaires ou utiliser un abonnement à une newsletter périodique. Le second fournit, peut-être, pas si rapidement, en comparaison avec d'autres, des informations, mais dans un volume assez complet et sans une once de sensationnalisme, caractéristique de certains sites dédiés à la sécurité de l'information.

Parfois, les réseaux et autres erreurs système Windows peuvent être liés à des problèmes dans le registre Windows. Plusieurs programmes peuvent utiliser le fichier réseaux, mais lorsque ces programmes sont supprimés ou modifiés, des entrées de registre Windows orphelines (non valides) sont parfois laissées.

En gros, cela signifie que bien que le chemin d'accès réel au fichier ait été modifié, son ancien emplacement incorrect est toujours enregistré dans le registre Windows. Lorsque Windows essaie de rechercher cette référence de fichier incorrecte (emplacements de fichiers sur votre PC), les réseaux. En outre, une infection par un logiciel malveillant peut avoir corrompu les entrées de registre associées à Microsoft Windows. Ainsi, ces entrées de registre Windows corrompues doivent être réparées afin de corriger la racine du problème.

La modification manuelle du registre Windows pour supprimer les clés réseau invalides n'est pas recommandée, sauf si vous êtes un professionnel de la maintenance informatique. Les erreurs commises lors de la modification du registre peuvent rendre votre PC inutilisable et causer des dommages irréparables à votre système d'exploitation. En fait, même une simple virgule au mauvais endroit peut empêcher votre ordinateur de démarrer !

En raison de ce risque, nous vous recommandons fortement d'utiliser un nettoyeur de registre fiable tel que WinThruster (développé par Microsoft Gold Certified Partner) pour analyser et réparer tous les réseaux. L'utilisation d'un nettoyeur de registre automatise le processus de recherche des entrées de registre non valides, des références de fichiers manquantes (comme celle qui cause l'erreur de votre réseau) et des liens rompus dans le registre. Avant chaque numérisation, une création automatique copie de sauvegarde, qui vous permet d'annuler toute modification d'un simple clic et vous protège contre d'éventuels dommages à votre ordinateur. La meilleure partie est que la correction des erreurs de registre peut considérablement améliorer la vitesse et les performances du système.

Avertissement: Si tu n'es pas utilisateur expérimenté PC, nous ne recommandons PAS de modifier manuellement le registre Windows. Une utilisation incorrecte de l'Éditeur du Registre peut entraîner de graves problèmes et vous obliger à réinstaller Windows. Nous ne garantissons pas que les problèmes résultant d'une mauvaise utilisation de l'Éditeur du Registre puissent être résolus. Vous utilisez l'Éditeur du Registre à vos risques et périls.

Avant de restaurer manuellement Registre Windows, vous devez sauvegarder en exportant la partie réseaux du registre (par exemple, Microsoft Windows) :

Cliquez sur le bouton Commencer.
Entrer " commande"V barre de recherche... N'APPUYEZ PAS ENCORE ENTRER!
Tenir les clés CTRL-Maj sur le clavier, appuyez sur ENTRER.
Une boîte de dialogue d'accès s'affiche.
Cliquez sur Oui.
La boîte noire s'ouvre avec un curseur clignotant.
Entrer " regedit" et appuyez sur ENTRER.
Dans l'Éditeur du registre, sélectionnez la clé associée aux réseaux que vous voulez sauvegarder (p ex. Microsoft Windows).
au menu Déposer sélectionner Exporter.
Listé Enregistrer dans sélectionnez le dossier dans lequel vous souhaitez enregistrer la sauvegarde de la clé Microsoft Windows.
Dans le champ Nom de fichier entrez un nom pour le fichier de sauvegarde, tel que "Microsoft Windows Backup".
Assurez-vous que le champ Gamme d'exportation valeur sélectionnée Branche sélectionnée.
Cliquez sur Sauvegarder.
Le fichier sera enregistré avec extension .reg.
Vous avez maintenant une sauvegarde de vos réseaux.

Les prochaines étapes de modification manuelle du registre ne seront pas couvertes dans cet article, car elles risquent d'endommager votre système. Si vous souhaitez plus d'informations sur la modification manuelle du registre, veuillez consulter les liens ci-dessous.