Non, ping n’utilise aucun port TCP ou UDP. Cette commande repose sur le protocole ICMP (Internet Control Message Protocol), qui fonctionne sans numéro de port. C’est une différence fondamentale avec TCP et UDP, les protocoles utilisés par les services web, les connexions SSH ou RDP.
Cette confusion est fréquente : beaucoup d’utilisateurs cherchent « port ping » en pensant à un port spécifique, ou confondent la joignabilité d’une machine avec la disponibilité d’un service. Voici comment distinguer ping, ICMP et test de port, et surtout comment vérifier si un port est réellement ouvert.
Ping et ICMP : un protocole sans numéro de port
Le ping envoie des paquets ICMP de type « echo request » à une machine cible, qui répond par un « echo reply ». ICMP n’a pas de notion de port : il n’y a donc pas de « port ping » au sens où TCP a le port 443 pour HTTPS ou le port 22 pour SSH.
Ping sert uniquement à vérifier qu’une machine est joignable sur le réseau et à mesurer le temps de réponse (latence). Il ne dit rien sur les services qui tournent sur cette machine, ni sur l’état de leurs ports.
Pourquoi parle-t-on parfois de « port 7 » pour ping ?
Historiquement, le service « echo » associé au port 7 (TCP/UDP) existait sur d’anciens systèmes Unix, mais il n’a aucun rapport avec la commande ping moderne. Cette confusion vient d’une similarité de nom, pas d’un lien technique réel. Dans l’usage actuel, ping = ICMP, point final. Le port 7 est aujourd’hui obsolète et rarement activé.
ICMP, TCP et UDP : trois protocoles, trois usages
- ICMP : protocole de contrôle réseau, utilisé par ping et traceroute. Pas de port. Sert à diagnostiquer la connectivité.
- TCP : protocole avec connexion, utilise des ports (80, 443, 22…). Sert aux services fiables : web, mail, SSH.
- UDP : protocole sans connexion, utilise aussi des ports. Sert au streaming, DNS, jeux en ligne.
Tester la connectivité réseau (ping) et tester un port ouvert sont donc deux opérations totalement différentes, qui ne mobilisent pas les mêmes protocoles. Confondre les deux conduit souvent à un mauvais diagnostic : on croit qu’un service est en panne alors que c’est simplement ICMP qui est filtré, ou inversement on pense la machine injoignable alors qu’un pare-feu bloque uniquement le ping.
C’est pourquoi il est utile de toujours préciser, lors d’un diagnostic réseau, si l’on teste la connectivité générale (ping, ICMP) ou la disponibilité d’un service précis (port TCP ou UDP). Les deux informations sont complémentaires mais ne répondent pas à la même question.
Comment tester si un port est ouvert (PowerShell) 🔧
Sous Windows, la commande la plus simple est Test-NetConnection. Elle permet de tester un port TCP précis, contrairement à ping :
Test-NetConnection hôte -Port 443
Le résultat indique si la connexion TCP vers ce port a réussi ou échoué. Quelques exemples de ports courants à tester :
- Port 80 : HTTP (site web non sécurisé)
- Port 443 : HTTPS (site web sécurisé)
- Port 22 : SSH (administration à distance)
- Port 3389 : RDP (bureau à distance Windows)
- Port 25 : SMTP (envoi d’e-mails)
Ping, Telnet, Netcat, Nmap : quel outil pour quel usage ?
| Outil | Protocole | Usage |
|---|---|---|
| Ping | ICMP | Vérifier la joignabilité d’une machine |
| Test-NetConnection | TCP | Tester un port précis sous Windows |
| Telnet | TCP | Se connecter à un port pour tester manuellement |
| Nmap | TCP/UDP | Scanner plusieurs ports et détecter les services |
Telnet reste utile pour un test rapide en ligne de commande (telnet hôte port), tandis que Netcat (nc -zv hôte port) et Nmap offrent plus de flexibilité, notamment pour scanner une plage de ports. Sous Linux et macOS, curl permet aussi de tester rapidement un port HTTP ou HTTPS.
Nmap va plus loin que les autres outils : il peut identifier le service qui tourne réellement derrière un port, détecter sa version, ou scanner plusieurs centaines de ports en une seule commande (nmap -p 1-1000 hôte). C’est l’outil de référence pour un audit réseau complet, tandis que Test-NetConnection et Telnet suffisent largement pour un diagnostic ponctuel sur un port unique.
Port ouvert, fermé ou filtré : comprendre les résultats
Un test de port renvoie généralement l’un de ces trois états :
- Port ouvert : un service écoute et répond à la connexion.
- Port fermé : la machine répond, mais aucun service n’écoute sur ce port.
- Port filtré : aucune réponse n’est reçue, généralement à cause d’un pare-feu qui bloque la requête.
Ces trois états sont différents d’un hôte injoignable, où même le ping échoue. Un port filtré et un port fermé peuvent d’ailleurs se ressembler dans certains résultats de test : seul un scan plus approfondi, comme celui proposé par Nmap, permet de distinguer précisément les deux situations en observant la manière dont la machine répond (ou ne répond pas) à la requête.
Pourquoi ping répond mais le site ne fonctionne pas ?
Si le ping fonctionne mais qu’un site ou service reste inaccessible, cela signifie que la machine est joignable en ICMP, mais que le port TCP visé pose problème. Plusieurs causes possibles :
- Le service (serveur web, base de données) est arrêté.
- Le port est fermé côté application.
- Un pare-feu bloque spécifiquement ce port, sans bloquer ICMP.
Un ping réussi ne garantit donc jamais qu’un service est disponible.
Pourquoi le port répond mais ping ne fonctionne pas ?
Le cas inverse est tout aussi fréquent : un port TCP peut répondre correctement (site accessible, connexion SSH fonctionnelle) alors que le ping échoue. Cela arrive quand le pare-feu bloque spécifiquement ICMP tout en laissant passer le trafic TCP légitime. C’est une configuration courante sur les serveurs web, pour limiter l’exposition aux scans réseau tout en gardant les services actifs.
Le rôle du pare-feu dans les tests réseau
Les pare-feu filtrent souvent ICMP par défaut, en particulier sur les serveurs exposés à Internet. Cela explique pourquoi de nombreux sites ne répondent pas au ping, sans que cela signifie un problème de disponibilité. À l’inverse, un pare-feu peut aussi filtrer certains ports TCP ou UDP tout en laissant passer ICMP. Chaque protocole peut donc être filtré indépendamment des autres.
Bonnes pratiques avant de tester un port
Tester un port ou scanner une plage de ports doit toujours se faire sur ses propres machines ou avec une autorisation explicite. Scanner des serveurs tiers sans accord peut être assimilé à une tentative d’intrusion et poser des problèmes légaux. Sur son propre réseau ou dans un cadre professionnel autorisé, ces outils restent précieux pour diagnostiquer une panne, vérifier une configuration ou auditer la sécurité d’une infrastructure.
Diagnostiquer un problème réseau efficacement
Pour résumer la démarche : commencez par un ping pour vérifier la joignabilité de la machine, puis utilisez Test-NetConnection, Telnet, Netcat ou Nmap pour tester l’ouverture réelle d’un port. Ces deux étapes sont complémentaires et permettent d’isoler rapidement l’origine d’un problème de connectivité, qu’il s’agisse d’un pare-feu, d’un service arrêté ou d’une machine réellement injoignable.
