TCP/IP, Trouver les ports de votre application

Mais seule la configuration du serveur détermine quels ports un client et un serveur utilisent pour communiquer.

L’Internet Assigned Numbers Authority (IANA) tient une liste de numéros de ports couramment acceptés à iana.org/assignments/port-numbers, mais ces assignations ne sont pas obligatoires et de nombreuses applications utilisent d’autres valeurs connues seulement d’un couple client/serveur communiquant. Par conséquent, la seconde information à détenir avant de commencer le diagnostic d’un problème, est les numéros de ports employés par le client et le serveur concernés.

Rien n’empêche un serveur d’utiliser un port donné et les mêmes ports peuvent, bien sûr, servir à de multiples applications. Et, bien entendu, même d’importants acteurs ne se donnent pas forcément la peine d’enregistrer un port auprès de IANA. Aussi choquant que cela puisse paraître, IBM en fait partie !

Prenez par exemple les ports 2300 ou 2301. Si vous utilisez un HMC (Hardware Management Console) pour gérer votre i, vous savez probablement que vous pouvez établir une connexion Telnet vers le HMC et accéder à distance à la session console système (généralement DSP01). Pour cela, vous devez définir votre émulation 5250 pour qu’elle aille vers le port 2300 (ou 2301 pour des connexions protégées par SSL). Malheureusement, ce port n’est pas négociable : vous ne pouvez pas supplanter la préférence de HMC le concernant (mais nous verrons un contournement un peu plus loin). Si vous examinez le registre des ports IANA, vous trouvez ceci :

cvmmon 2300/tcp CVMMON
cvmmon 2300/udp CVMMON
# Roger Kumpf <kumpf&cup.hp.com>
cpq-wbem 2301/tcp Compaq HTTP
cpq-wbem 2301/udp Compaq HTTP
# Scott Shaffer <scott.shaffer&hp.com></scott.shaffer&hp.com></kumpf&cup.hp.com>

Surprise : IBM utilise des ports que HP a enregistrés aux applications HP ! Les assignations de ports IANA ne sont que des recommandations et pas des obligations. L’enregistrement formel des ports n’est là que pour aider les applications à éviter les conflits de numéros de ports, mais un serveur donné n’est pas obligé de les utiliser.

N’allez pas croire qu’IBM ignore complètement ce processus. Prenez par exemple le port 9090, que le logiciel WebSM utilise pour se connecter aux anciennes versions du HMC. Ce port est enregistré :

websm 9090/tcp WebSM
websm 9090/udp WebSM
# I-Hsing Tsao <itsao&austin.ibm.com></itsao&austin.ibm.com>

Mais notez que l’information dans le registre est médiocrement maintenue. I-Hsing Tsao a quitté IBM depuis plusieurs années ! De plus, ne supposez jamais que tous les ports associés à une application sont enregistrés. Bien que 9090 soit enregistré auprès de WebSM, les ports 30000-30009, dont WebSM a besoin pour communiquer en retour avec le PC demandeur, ne sont pas enregistrés.

Alors, malgré tous ses défauts, pourquoi ce registre est-il important ? Entre autres, il donne aux fabricants de pare-feu une idée générale de ce qui pourrait arriver sur un port donné et crée des règles qui s’assurent que les données sont ce qu’elles devraient être. Par exemple, le numéro de port standard pour FTP est 22, mais ce port n’est utilisé que pour échanger des commandes et des réponses, entre client et serveur. FTP négocie dynamiquement les numéros de ports lors du transfert proprement dit des données, et un pare-feu doit inspecter le contenu des paquets du port 22 pour détecter ces numéros de ports négociés et créer des règles de pare-feu temporaires pour les permettre.

Sachant ce que sont les ports et pourquoi ils pourraient être bloqués, il est clair que le registre n’est pas la meilleure source pour cette information, parce que les applications ne sont pas forcées d’obéir à ses recommandations. Vous devez identifier positivement les ports que votre instance de l’application fautive utilise.

La première source d’information est la documentation de l’application, qui pourrait se trouver dans des documents d’installation ou de type « read me », mais dont la recherche sera parfois un peu plus difficile. A titre d’exemple, prenons l’une des applications les plus couramment utilisées pour IBM i : System i Access et la suite d’applications qu’il inclut, comme Navigator for i. Ce puissant ensemble d’outils GUI non seulement facilite beaucoup de tâches mais procure des fonctions dont l’écran vert est dépourvu. Malheureusement, il est exigeant en matière de ports. Le meilleur endroit pour trouver ces ports est probablement APAR II12227, peut-être un peu ancien mais encore exact.

Vous y trouverez les ports nécessaires pour diverses fonctions de ce produit. Il y en a environ 20 en tout, avec quelques ports secondaires supplémentaires nécessaires seulement si l’on utilise la communication sécurisée par SSL. Si l’un de ces ports est bloqué par un pare-feu, la fonction correspondante de System i Access ne fonctionnera pas. Peut-être qu’une présentation plus élégante de ces mêmes données est contenue dans un message d’erreur. Dans System i Access, allez à Start|Programs|System i Access (ou répertoire install équivalent)|Service|Error and Trace Message Help. A partir de là, recherchez le message CWBCO1003, qui contient une belle liste de ces ports.

On peut aussi trouver l’information sur le numéro de port dans la configuration de l’application, qui peut permettre la personnalisation du numéro de port de destination. Un bon exemple en est le serveur web Apache, qui utilise les directives dans le fichier de configuration httpd.conf pour déterminer sur quels ports il faut accepter les requêtes web. Même si le port 80 par défaut est utilisé, il est configuré spécifiquement en tant que tel dans ce fichier.

Si vous ne pouvez pas trouver les détails de port à partir des sources de documentation ou de configuration, vous pouvez employer la méthode forte, en capturant et en analysant les paquets échangés entre le PC client et le serveur. Au niveau de base, vous pouvez capturer des paquets sur le PC en utilisant des outils intégrés tels que Windows Network Monitor, en filtrant le trafic envoyé ou reçu de l’adresse IP du serveur. Cette méthode ne vous donnera peut-être pas toute l’information nécessaire, mais vous pourrez facilement identifier les ports de destination pour les requêtes adressées par le PC au serveur. Si elles sont bloquées, vous ne pourrez pas capturer les réponses.

Vous pouvez aussi tracer le trafic vers et à partir d’un serveur i avec la commande Start Communications Trace (STRCMNTRC). Ces données peuvent être volumineuses, selon le nombre de machines communiquant sur une ligne Ethernet donnée. Il est bon de démarrer et d’arrêter la trace au moment où la communication est tentée. Puis, terminez et imprimez la trace avec les commandes End Communications Trace (ENDCMNTRC) et Print Communications Trace (PRTCMNTRC) (elles requièrent l’autorité spéciale *SERVICE). Recherchez dans le fichier spool résultant les adresses IP source et destination (exécutez IPCONFIG sur votre PC si vous ne connaissez pas son adresse. Mais si vous vous connectez sur un VPN, cela pourrait bien ne pas donner l’adresse telle que le système IBM i la voit). Vous pouvez suivre une conversation entre un client et un serveur en faisant correspondre le numéro de séquence (SEQ) d’un paquet avec le numéro d’accusé de réception (ACK) d’un autre (Figure 1). Dans le paquet, vous trouverez des adresses source et destination ainsi que les ports source et destination. Comme pour la capture de paquets basée sur PC, si un port est bloqué par un pare-feu intervenant, vous ne verrez qu’un côté de la conversation avec, à un certain stade, pas de réponse en provenance de l’autre bout.

Un troisième moyen de capture des paquets est un renifleur (« sniffer ») externe, une unité de réseau physique qui supervise le flux de données et le présente dans un rapport. Il faudra peut-être « renifler » les deux côtés d’un pare-feu soupçonné de bloquer le trafic, et il est très probable que vous devrez coopérer avec l’équipe du réseau pour la mise en place et l’analyse de ce dispositif. Un renifleur peut être tout simplement un petit ordinateur exécutant l’une des nombreuses applications d’analyse de paquets, glissé dans votre réseau via un port « superviseur » sur un commutateur Ethernet géré, ou via une interception de réseau physique. L’un des analyseurs de paquets les plus connus est le WireShark (wireshark.org). Votre entreprise a peut-être des règles qui s’opposent à la supervision du trafic, aussi il vaut mieux vérifier d’abord. De plus, l’installation de produits de ce genre peut demander des drivers supplémentaires ou des privilèges d’administrateur (admin) sur le PC renifleur. Lisez soigneusement la documentation à ce sujet.

A noter que certaines offres de type web d’IBM peuvent nécessiter des ports entrants et sortants spécifiques ouverts sur un pare-feu. Par exemple, Fix Central d’IBM (un site pour la commande et la livraison de PTF sur le web) demande des ports ouverts.

Vous pouvez exécuter l’option 3 NETSTAT à partie de votre système IBM i pour voir les applications actives et les ports sur lesquels elles sont à l’écoute, ainsi que des détails sur toutes les connexions en cours. En outre, regardez Work with Service Table Entry (WRKSRVTBLE). Cette commande montre les entrées de la table de service qui définissent les ports que certains services utilisent. Un bon exemple est le Service Tools Server, qui vous permet d’accéder à la configuration au niveau Service Tool par l’intermédiaire de System i Navigator.