Chapitre 9 Dépannage des problèmes de réseau (tâches)

Ce chapitre apporte des solutions aux problèmes se produisant couramment sur les réseaux. Il aborde les sujets suivants :

• Conseils d'ordre général pour le dépannage réseau

• Problèmes courants lors du déploiement de IPv6

Nouveaux dépannages de problèmes de réseau

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.

Conseils d'ordre général pour le dépannage réseau

La non-communication entre des hôtes d'un réseau constitue l'un des signes annonciateurs d'un problème de réseau. S'il est impossible de communiquer avec un hôte qui vient d'être ajouté au réseau, le problème provient probablement des fichiers de configuration. La carte d'interface réseau peut également être en cause. En effet, si un seul hôte pose problème, la carte d'interface réseau est peut-être défectueuse. Si plusieurs hôtes du réseau peuvent communiquer entre eux, mais pas avec d'autres réseaux, le routeur ou un autre réseau peut être à l'origine du problème.

La commande ifconfig vous permet d'obtenir des informations sur les interfaces réseau. Exécutez la commande netstat pour afficher les tables de routage et les statistiques de protocoles. Les programmes tiers de diagnostic de réseau fournissent divers outils de dépannage. Pour plus d'informations, reportez-vous à la documentation de ces produits.

D'autres causes moins évidentes peuvent réduire les performances du réseau. Par exemple, l'outil ping permet de quantifier des problèmes tels que la perte de paquets par un hôte.

Réalisation de diagnostics de base

Pour résoudre un problème de réseau, vous pouvez réaliser un certain nombre de vérifications logicielles et dépanner les problèmes élémentaires liés aux logiciels.

Vérification logicielle de base sur un réseau

1. Sur le système local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.

   Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.

2. Pour obtenir des informations sur le réseau, exécutez la commande netstat.

   Pour obtenir de plus amples informations sur la commande netstat et sur sa syntaxe, reportez-vous à la section Contrôle du statut du réseau à l'aide de la commande netstat ainsi qu'à la page de manuel netstat(1M).

3. Vérifiez la base de données hosts (ainsi que la base de données ipnodes si vous exécutez Solaris 10 11/06 ou une version précédente avec IPv6) et assurez-vous que les entrées sont correctes et actuelles.

   Pour plus d'informations sur la base de données /etc/inet/hosts, reportez-vous à la section Base de données hosts ainsi qu'à la page de manuel hosts(4) Pour plus d'informations sur la base de données /etc/inet/ipnodes, reportez-vous à la section Base de données ipnodes ainsi qu'à la page de manuel ipnodes(4).

4. Si vous exécutez le protocole RARP (Reverse Address Resolution Protocol), vérifiez les adresses Ethernet de la base de données ethers et assurez-vous que les entrées sont correctes et actuelles.

5. Essayez de vous connecter à l'hôte local au moyen de la commande telnet.

   Pour obtenir de plus amples informations sur la commande telnet et sur sa syntaxe, reportez-vous à la page de manuel telnet(1).

6. Assurez-vous que le démon réseau inetd est en cours d'exécution.

   # ps -ef | grep inetd

   La sortie suivante permet de vérifier que le démon inetd est en cours d'exécution :

   root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s

7. Si le protocole IPv6 est activé sur le réseau, assurez-vous que le démon in.ndpd est en cours d'exécution :

   # ps -ef | grep in.ndpd

   La sortie suivante permet de vérifier que le démon in.ndpd est en cours d'exécution :

   root 123 1 0 Oct 27 ? 0:03 /usr/lib/inet/in.ndpd

Problèmes courants lors du déploiement de IPv6

Cette section décrit les problèmes que vous pouvez rencontrer lors du déploiement de IPv6 sur votre site. Pour toute question liée aux tâches de planification réelles, reportez-vous au Chapitre 4Planification d'un réseau IPv6 (tâches).

Impossible de mettre à niveau un routeur IPv4 vers IPv6

Si votre équipement ne peut pas être mis à niveau, vous devrez vous procurer un équipement compatible avec IPv6. Lisez attentivement la documentation du fabricant afin de connaître les procédures de prise en charge spécifiques à l'équipement.

Certains routeurs IPv4 ne peuvent pas être mis à niveau vers IPv6. Si votre topologie se trouve dans cette situation, raccordez un routeur IPv6 au routeur IPv4. Vous pourrez alors créer un tunnel sur le routeur IPv4 partant du routeur IPv6. Pour une description des tâches de configuration des tunnels, reportez-vous à la section Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches).

Problèmes survenant après la mise à niveau de services vers IPv6

Vous pouvez rencontrer les problèmes suivants lors de la préparation des services au protocole IPv6 :

• Certaines applications préparées pour IPv6 ne prennent pas en charge IPv6 par défaut. Vous devez activer IPv6 sur ces applications pour que la prise en charge soit effective.

• Des problèmes peuvent survenir sur un serveur exécutant plusieurs types de services (certains ne prenant en charge qu'IPv4, d'autres prenant en charge IPv4 et IPv6). En effet, certains clients nécessitent l'utilisation de ces deux types de services, ce qui peut semer la confusion au niveau du serveur.

Le FAI actuel ne prend pas en charge IPv6

Si vous envisagez de déployer IPv6 sur votre réseau alors que votre FAI actuel ne prend pas en charge l'adressage IPv6, vous pouvez remplacer votre FAI actuel ou opter pour l'un des choix suivants :

• Louer un FAI fournissant au site une seconde ligne dédiée aux communications IPv6. Cette solution est onéreuse.

• Acquérir un FAI virtuel. Les FAI virtuels fournissent un accès IPv6 sans connexion physique. La connexion s'effectue de fait par le biais d'un tunnel reliant le FAI virtuel et le site à travers le FAI IPv4.

• Créer un tunnel 6to4 vers d'autres sites IPv6 à travers le FAI actuel. Configurez l'adresse IPv4 enregistrée du routeur 6to4 en tant qu'entité topologique publique de l'adresse IPv6.

Problèmes de sécurité lors de la création d'un tunnel vers un routeur relais 6to4

De par sa nature, un tunnel reliant un routeur 6to4 à un routeur relais 6to4 ne constitue pas une connexion sécurisée. Les problèmes de sécurité suivants sont inhérents à ce type de tunnel :

• Les routeurs relais 6to4 encapsulent et décapsulent des paquets, mais ne vérifient pas leur contenu.

• La mystification d'adresses est l'un des problèmes majeurs des tunnels sur routeurs relais 6to4. En effet, lorsque le routeur 6to4 reçoit des données du trafic entrant, il est incapable de faire correspondre l'adresse IPv4 du routeur relais et l'adresse IPv6 de la source. L'adresse de l'hôte IPv6 peut alors être facilement mystifiée. Il en va de même pour l'adresse du routeur relais 6to4.

• Par défaut, il n'existe aucun mécanisme de validation entre le routeur 6to4 et le routeur relais 6to4. Un routeur 6to4 ne peut donc pas déterminer si le routeur relais 6to4 est digne de confiance ou s'il est légitime. Une relation de confiance doit exister entre la source 6to4 et la destination IPv6 pour que ces deux sites ne s'exposent pas à d'éventuelles attaques.

Tous les problèmes de sécurité inhérents aux routeurs relais 6to4, y compris ceux cités précédemment, sont expliqués dans le brouillon Internet intitulé Security Considerations for 6to4. D'une manière générale, n'activez la prise en charge des routeurs relais 6to4 que dans l'un des cas suivants :

• Votre site 6to4 tente de communiquer avec un réseau IPv6 de confiance privé. Par exemple, activez la prise en charge du routeur relais 6to4 sur un réseau universitaire constitué de sites 6to4 isolés et de sites IPv6 natifs.

• Il est essentiel que votre site 6to4 communique avec certains hôtes IPv6 natifs.

• Vous avez implémenté les modèles de vérification et de validation suggérés dans le brouillon Internet intitulé Security Considerations for 6to4.

Problèmes connus du routeur 6to4

Les bogues suivants concernent la configuration 6to4 :

• 4709338 – Implémentation RIPng nécessaire à la reconnaissance des routes statiques

• 4152864 – Fonctionnement de la configuration de deux tunnels avec la même paire tsrc/tdst

Implémentation de routes statiques sur le site 6to4 (ID 4709338)

Le problème suivant se produit sur les sites 6to4 équipés de routeurs internes au routeur de bordure 6to4. Lors de la configuration de la pseudointerface 6to4, la route statique 2002::/16 est automatiquement ajoutée à la table de routage du routeur 6to4. Ce bogue (ID 4709338) indique que le protocole de routage Oracle Solaris RIPng empêche la publication de la route statique sur le site 6to4.

Deux opérations permettent de résoudre ce problème.

• L'une consiste à ajouter la route statique 2002::/16 aux tables de routage de tous les routeurs intrasites du site 6to4.

• L'autre consiste à utiliser un autre protocole de routage que RIPng sur le routeur interne au site 6to4.

Tunnels configurés avec la même adresse source (ID 4152864)

Ce bogue (ID 4152864) décrit les problèmes liés à la configuration de deux tunnels avec la même adresse source de tunnel qui peuvent gravement affecter la configuration des tunnels 6to4.

Vous ne devez pas configurer un tunnel 6to4 et un tunnel automatique (atun) avec la même adresse source de tunnel. Pour plus d'informations sur les tunnels automatiques et la commande atun, reportez-vous à la page de manuel tun(7M).