> Tech > Scénario 2 : Serveurs Exchange sur des sous-réseaux distants

Scénario 2 : Serveurs Exchange sur des sous-réseaux distants

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Lorsque les serveurs résident sur des sous-réseaux distincts, le dépannage devient plus complexe. En fait, la rubrique Passerelle invalide du tableau 2 ouvre un certain nombre de possibilités. En utilisant ce tableau comme point de départ, vous pouvez commencer par déterminer l’étendue de votre résolution du problème : sous-réseau local

ou distant. Si votre serveur DNS se trouve sur le même sous-réseau que le client DNS (par ex., un serveur Exchange) semblant avoir des problèmes DNS, vous allez employer, par exemple, l’étendue de sous-réseau local indiquée au tableau 2.

Après avoir restreint votre champ d’investigation, vous pouvez mettre l’accent sur le composant concerné de votre réseau. La passerelle peut être non valide, autrement dit il est inappropriée pour la route utilisée ou la passerelle, les tables de routage et d’autres composants sont incorrects. Il est possible d’utiliser une trace (commande trace route [tracert]) vers l’hôte distant, une approche très utile pour identifier le problème. La fonction de trace vous indiquera si un serveur Exchange peut se connecter au réseau de destination ou à une passerelle reconnaissant celui-ci.

Lors du dépannage d’un hôte distant, il faut commencer par des tests ciblant le routage entre votre sous-réseau et le sousréseau distant (nous allons supposer que le masque de sousréseau est correct). Le serveur Exchange peut se connecter à d’autres systèmes hôtes. Si le client DNS (serveur Exchange) à dépanner peut se connecter à d’autres hôtes sur le réseau distant contenant le serveur DNS, le masque de sous-réseau ou les paramètres de passerelle de l’ordinateur distant ne sont peut-être pas valides. L’hôte et/ou les ports distants peuvent également comporter des paramètres de sécurité spécifiques empêchant la connexion.

Si toute connexion à d’autres systèmes hôtes du réseau distant est impossible, utilisez une trace (si cette fonction est activée sur votre réseau) pour vérifier à « quelle distance » de l’hôte distant vous vous arrêtez. Par exemple, si votre réseau comporte cinq routeurs entre deux sous-réseaux, une trace peut signaler une interruption de la connexion au niveau du troisième saut. Cette information indique un problème de routage vraisemblable sur le routeur du troisième saut. Il peut s’agir d’une route manquante vers le réseau suivant, d’un problème technique lié à la liste ACL ou d’autres problèmes empêchant le trafic de parvenir à destination. Le serveur Exchange peut se connecter au réseau, mais pas aux hôtes. Si le réseau distant est joignable, mais pas les systèmes hôtes, le problème est probablement lié à la sécurité.

Des ports spécifiques sont vraisemblablement bloqués. Il est également possible (mais improbable) que des masques de sous-réseau ou des passerelles invalides soient paramétrés sur tous les hôtes. La passerelle peut aussi avoir un masque de sous-réseau incorrect. En cas d’échec de la connexion au réseau de l’hôte distant, commencez par une investigation locale. Le logigramme de la figure 1 présente toutes les étapes du processus. Examinez votre table de routage locale pour voir si elle inclut des routes vers le réseau de destination.

Si c’est le cas, votre passerelle est-elle joignable par un ping ou une trace ? S’agit-il de la passerelle correcte ? Les masques de sousréseau sont-ils valides ? En l’absence de routes vers le réseau de destination, vous allez employer votre passerelle par défaut. Est-elle joignable ? S’agit-il de la passerelle correcte ? Les masques de sous-réseau sont-ils valides ? Si votre passerelle par défaut est joignable et correcte mais que vous n’accédez pas au réseau distant, exécutez une commande tracert pour identifier la passerelle problématique. Celle pour laquelle la trace échoue peut présenter un problème de route manquante, être non valide ou comporter un masque de sous-réseau incorrect.

Si vous avez validé l’intégralité du routage jusqu’au réseau distant, mais que la connexion à l’hôte distant demeure impossible, le problème est peut-être lié à la sécurité. Dans la mesure du possible, essayez de vous connecter au système hôte sur différents ports ou via différentes méthodes. La commande ping constitue la méthode la plus évidente et la plus courante pour tester la connectivité de base, mais votre réseau peut la bloquer (comme pour tracert). Cela peut vous inciter à employer une autre méthode, notamment Telnet, pour tester la connexion. Par exemple, si vous savez que la machine exécute les services Terminal Server, essayez une commande Telnet sur le port 3389.

Si elle aboutit sans encombre jusqu’à l’hôte alors que la commande ping échoue, vous savez que le blocage se limite à DNS. Par conséquent, si le routage global jusqu’au système hôte se présente bien et que la connexion demeure impossible, vous pouvez tabler sur un problème de paramétrage de la sécurité. Malheureusement, l’identification précise de celui-ci vous imposera d’examiner les configurations spécifiques sur votre matériel, lequel peut être un pare-feu ou un routeur auquel vous n’avez pas accès.

Téléchargez cette ressource

Préparer l’entreprise à l’IA et aux technologies interconnectées

Préparer l’entreprise à l’IA et aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010