Un port est ouvert lorsqu'il n'est pas bloqué par le firewall.
Mais la connexion du programme telnet ne peut se faire que s'il y a effectivement un logiciel serveur telnet qui "écoute" les demandes de connexion sur ce port.
On peut très bien désactiver le serveur telnet tout en laissant le port ouvert.
Pour moi, la réponse de l'administrateur réseau a bien un sens, et... c'est toi le PEBKAC!

Captain Obvious pourrait-il éclairer ma lanterne ?

Pour moi, des paquets interceptés par un pare-feu étaient enterrés corps et âme, générant plutôt des timeout, alors qu'un connexion refused apparaissait plutôt quand aucun service n'écoutait ce port sur la machine distante et que l'OS coupait directement la communication ?

EDIT : ah ben en fait merci J-Lee

euh... t'as pas du comprendre le probleme. Le service smtp tourne sur le port 25, on peut très bien lancer un telnet sur ce port et entrer un scénario à la main (ex: http://technet.microsoft.com/fr-fr/library/bb123686%28v=exchg.141%29.a[...]). Si le port 25 est ouvert mais que le port 23 (telnet) est fermé, le port 25 est quand même accessible par telnet.

Il faut remplacer le service smtp et le port 25 par le service et le port utilisé par le logiciel.

Heu, où est-ce que tu vois que le telnet a été lancé sur le 25 ? Et où est-ce que tu vois qu'il y avait un quelconque service SMTP sur la machine visée ?

Dans ce cas, il manque la mention du numéro de port TCP concerné si ce n'est pas le 23 (Telnet).
Car le message "Connection refused" ne signifie pas qu'un pare-feu a bloqué le dit port mais bien qu'aucun service n'est disponible sur l'hôte distant. Bref, cela manque de précisions.

tu peux utiliser telnet pour tester un peut tout ce qui fonctionne avec des commandes texte, comme le http, le smtp .....

pour le port 25 de marcel, il doit sagir d'un exemple

Il a bien précisé <port> dans son pebkac.

Ca sent le gros mélangeationnage de vocabulaires. O_o'

Et tout est bon dans l'cochon ! :3

Qui veut du Gloubiboulga ?

@pTree : quand marcel parle de smtp et du port 25, c'est ce qu'on appelle un exemple...
Parce que si tu lis attentivement le PEBKAC, il est écrit « telnet <adresse IP> <port>».
Y'a même un indice dans ce que dit marcel pour tout comprendre (la dernière phrase, en fait, c'est vrai qu'il faut tout lire) : « Il faut remplacer le service smtp et le port 25 par le service et le port utilisé par le logiciel.»
Attention, le mot logiciel est encore une référence (il faut vraiment être super fort en analyse de texte, en fait !) : il s'agit donc du logiciel pour lequel globideuh assure le support (certainement un modèle client/serveur, ça n'est pas dit, il est vrai)

Il y a une chose supplémentaire, qui est implicite (attention, vocabulaire de fou) c'est que telnet est réduit à n'être qu'un outil pour tester les connexions à un serveur sur un réseau tcp/ip.
On se connecte rarement à un serveur telnet, de nos jours.

Désolé pour le ton condescendant, mais c'est exactement ce que tu as fait pour marcel, alors qu'il donnait une réponse correcte.

Avec de vrais morceaux de petits nenfants dedans, et tout ? :D

Ne t'excuse pas pour la condescendance elle est la norme sur ce site de toutes façons, puisque c'est la manière préférée des informaticiens d'affirmer leur supériorité ...

Ne le remercie pas trop vite, il a dit une connerie.

Par ailleurs, "Connection refused" n'est pas causé par l'absence de service sur la machine distante, mais par un paquet TCP RESET, qui peut avoir des origines très variées... Dont l'absence de service sur la machine distante, mais pas que.
Un firewall peut très bien filtrer non pas en supprimant le paquet, mais en réinitialisant lui-même la connexion.
Exemple le plus proche de moi : moi. De l'extérieur, je détruits les paquets (donc timeout), mais de l'intérieur, je retourne des RST pour m'épargner le temps d'attente avant timeout...

Pas faux mais ce cas de figure est malheureusement assez rare, la plupart des administrateurs de pare-feux préférant purement et simplement dropper le paquet...

De là à en déduire qu'il s'agit du port 25. En quoi la mention du port était-elle aussi confidentielle ?

Pour moi, ce qu'indique le gars est possible :
- on autorise les paquets à destination de la machine, sur le port ciblé, le port est donc ouvert.
- le service est configuré pour écouter seulement sur localhost, ou bien il y a la possibilité de filtrer les demandes de connexion au niveau du service, le service "bloque" la connexion.
En l'absence de plus d'infos, je ne me prononce pas.

Le vocabulaire de l'admin du réseau est juste un peu nébuleux.

On va dire que le gars ne fait pas du support pour un serveur telnet. Donc, je ne pense que ce c'est le port 23 qu'il teste.

Je pense aussi qu'il a demandé l'état du serveur (celui dont il fait le support) avant de demander de faire un telnet.

Mais la bonne question est pourquoi parle-t-il d'un serveur telnet sachant que ce n'est pas lui qu'on teste ?

Sinon, pour tester un serveur qui utilise un protocole texte, on utilise les outils adaptés. Genre, netcat.

C'est vrai qu'il est tellement plus simple de faire télécharger un soft + l'installer (en entreprise, c'est tellement courant d'avoir les droits admins sur son poste) + expliquer comment s'en servir... Tout ça par téléphone.
Alors qu'utiliser un utilitaire installé par défaut sur à peu près sur toutes les machines, c'est tellement moins efficace...

Kebukai : euh, non, il n'y en a pas dans la recette traditionnelle du gloubiboulga, qui comporte les ingrédients suivants :
- de la confiture de fraises,
- des bananes mûres à point bien écrasées,
- du chocolat râpé,
- de la moutarde de Dijon, très forte,
- de la saucisse de Toulouse, crue mais tiède.

Cela dit, c'est vrai qu'on peut y ajouter un ingrédient au choix…

Pour répondre à la question récurrente:
telnet sert juste à ouvrir une connexion, par défaut sur le port 23 où s'il y a un serveur telnet sur la machine, ça va ouvrir une session sur la machine. En précisant le port, c'est un outil super basique (ie disponible sur tous les OS -enfin presque, à vérifier-) pour savoir si une connexion est disponible ou non.

En gros si "telnet ip port" indique connexion refusée ou timeout, ça sert à rien de chercher plus loin que le réseau. Je m'étonne d'abord qu'un admin réseau ne sache pas ça, mais encore pus qu'il a bloqué la commande telnet sur ce port ... celle-ci ne faisant qu'ouvrir une connexion réseau (pour moi ça revient à tout bloquer, mais des admin réseau infirmeront peut être. Je vois pas comment on peut bloquer "la commande telnet").

Nan mais on est d'accord que la réponse de l'admin est bizarre.

Par contre, si on se prend un "connexion refusée", je ne vois pas pourquoi chercher uniquement côté réseau puisque dans un certain nombre de cas ça correspond à "l'application qui écoutait sur ce port est tombée"...

Après mûre réflexion, je me dis qu'il parlait *peut-être* d'un firewall sur le poste client qui filtre aussi par application (firewall windows, daubealarm, coreforce, ...).

Mais c'est vraiment juste pour laisser le bénéfice du doute à l'admin...

ah oui, j'avais pas précisé, mais port bien en écoute (vérif avec netstat) et par la bonne appli (vérif dans les logs)

@Tori : tu es de Toulouse toi, c'est ça ?

@Tori
Donc on ajoute des mômes ! /o/