Après avoir identifié les ports servant à votre application, grâce à notre précédent dossier, vous êtes prêts à déterminer la cause de vos problèmes : le blocage du pare-feu ou le filtrage proxy.
Ce dossier est issu de notre publication System iNews (07/09). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.
Pour détecter les ports bloqués, la commande CWBPING fonctionne bien. Cette commande est livrée avec System i Access for Windows et vous permet d’envoyer un « ping » à n’importe quel port (pas seulement ceux qui sont spécifiques à System i Access for Windows). Un outil similaire appelé topping existe pour Windows.
Comme votre client est très probablement sous Windows, vous pouvez éclairer votre problème en déterminant le chemin que les paquets prennent du PC au serveur. L’outil pour cela est la commande DOS traceroute (TRACERT). Donnez-lui l’adresse IP du serveur et elle trace le chemin que les paquets prennent pour atteindre le serveur. A noter que le chemin de retour peut être différent parce que le routage symétrique n’est pas garanti dans IP. Pour avoir l’image complète du chemin des paquets, vous devez tracer la route à partir de votre IBM i en utilisant la commande TRACEROUTE, identique à l’outil Windows.
Traceroute utilise les paquets Ping et l’Internet Control Message Protocol (ICMP) pour scruter le chemin entre le client et le serveur, mais ne teste pas les règles de filtrage de pare-feu croisées en route. Et certains pare-feu peuvent simplement bloquer les Pings, et donc traceroute, au grand dam de ce dernier. Ping peut être remplacée par TCP Traceroute, qui a une implémentation Windows gratuite appelée tracetcp. Cet outil utilise des paquets TCP/IP sur un numéro de port que vous spécifiez et de cette façon peut imiter le trafic de votre application, vous permettant ainsi de détecter les éventuels blocages du pare-feu. Comme TCP Traceroute utilise des paquets TCP, il peut tracer au travers des pare-feu même quand Network Address Translation (NAT) est employé, révélant ainsi les adresses IP privées traversées pour atteindre un serveur qui pourrait se trouver derrière un pare-feu de mappage de port.
Avant de dire aux gars du réseau qu’un port est complètement bloqué, regardez donc quelques autres choses. Les règles du pare-feu peuvent stopper une partie du trafic sur un port, mais pas la totalité. Pour avoir des exemples du trafic à autoriser, voir « IBM iSeries Access for Windows and PC Firewall Products ».
Windows a son propre pare-feu, qui pourrait gêner le trafic avant qu’il n’entre ou ne sorte du PC (pour plus d’information, voir « iSeries Access and Microsoft Windows Firewall: Making It Work« ). Même les releases du système d’exploitation Windows peuvent avoir une influence (voir l’onglet Windows sur la page System i Access pour plus d’informations).
Même les produits que vous essayez d’utiliser sont peut-être en cause. System i Navigator vous permet de créer des règles de filtrage de paquets qui transforment le serveur IBM i lui-même en un pare-feu. La figure 2 montre où se trouvent ces règles. Ne jouez avec ces règles que si vous savez vraiment ce que vous faites. En effet, vous pourriez facilement bloquer tout l’accès réseau à votre système, y compris celui nécessaire pour utiliser la GUI chargée de désactiver les règles. Le HMC a aussi un pare-feu intégré et doit avoir remote virtual terminal explicitement validé pour permettre l’accès à la console système à distance.
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
