Comment vérifier si un port est ouvert

La méthode rapide : tester depuis l'extérieur de votre réseau

Saisissez le nom d'hôte ou l'adresse IP et le numéro de port dans un outil de vérification de port et laissez-le ouvrir une connexion depuis une machine ailleurs sur internet. Savoir si le service tourne est une autre question. Ce que vous devez savoir, c'est si quelqu'un là-dehors peut l'atteindre, et tester depuis le même serveur, ou depuis le même réseau de bureau, saute précisément les couches qui causent généralement le problème.

La méthode manuelle : nc, nmap et telnet

Depuis n'importe quelle autre machine sur un réseau différent, trois outils font le travail :

nc -zv example.com 443            # single port, zero-I/O scan, verbose
nmap -Pn -p 22,80,443 example.com # several ports, reports open/closed/filtered
telnet example.com 25             # old but universal; Ctrl+] then "quit" to exit

nc (netcat) est le plus simple : -z signifie se connecter puis se déconnecter immédiatement sans envoyer de données, -v affiche le résultat. Il répond « réussi » ou « refusé / délai dépassé » et rien de plus. Passez à nmap quand la distinction compte, car c'est le seul des trois outils qui sépare de façon fiable une connexion refusée d'une connexion abandonnée, et -Pn lui dit de sauter sa sonde ping et de tester le port même quand l'hôte ne répond pas aux pings. telnet est installé presque partout, et pour les protocoles texte comme SMTP ou HTTP, il vous montre aussi la bannière d'accueil que le service envoie.

Pour voir ce qui écoute sur la machine elle-même, ce qui est une question différente, utilisez ss -tulpn sous Linux ou netstat -ano sous Windows. Si un port écoute là mais est fermé depuis l'extérieur, le blocage se trouve entre les deux : un pare-feu de l'hôte, un groupe de sécurité cloud, ou le fournisseur.

Ouvert, fermé et filtré sont trois réponses différentes

• Ouvert. Quelque chose a terminé la poignée de main TCP. Un service écoute et a accepté la connexion.
• Fermé. L'hôte a répondu, mais par un refus (une réinitialisation TCP). La machine est joignable et rien n'écoute sur ce port. C'est une réponse rapide et définitive.
• Filtré. Rien n'est revenu du tout. Un pare-feu a abandonné le paquet sans répondre, donc la sonde expire. C'est la réponse lente, et elle signifie qu'un pare-feu fait obstacle plutôt que le service soit en panne.

Fermé oriente vers la configuration du service. Filtré oriente vers une règle de pare-feu, un groupe de sécurité, ou un fournisseur d'accès qui bloque le port. Beaucoup de fournisseurs bloquent le port 25 sortant par défaut, et quelques-uns bloquent le 445 et d'autres ports souvent exploités, ce qui produit un résultat filtré qu'aucune configuration côté serveur ne changera.

UDP est un cas particulier. UDP n'a pas de poignée de main, donc un scanner ne peut souvent pas distinguer un port ouvert d'un port filtré, et le silence est une réponse valide de la part d'un service UDP en bonne santé. Traitez les résultats UDP comme une preuve bien plus faible que les résultats TCP.

Pourquoi un port ouvert n'est pas un service qui fonctionne

Un port ouvert prouve qu'une connexion TCP peut être établie. Il ne dit rien de ce qui se passe ensuite. Voici tous des ports ouverts avec des services cassés :

• Un serveur web qui accepte les connexions sur le 443 tout en servant un 502 parce que l'application derrière lui a planté.
• Une base de données qui écoute sur son port mais refuse chaque connexion.
• Un serveur de messagerie qui termine la poignée de main puis coupe la session avant d'accepter un message.
• Un service dont le certificat TLS a expiré la nuit dernière. Le port s'ouvre, et chaque client rejette la connexion.
• Un port redirigé vers la mauvaise machine interne, qui accepte les connexions et ne répond rien d'utile.

Une vérification de port n'est donc que la première étape d'un diagnostic, pas tout le diagnostic. Une fois que le port répond, vérifiez le protocole : demandez une page et lisez le code de statut, faites une vraie connexion, ou envoyez un message de test. L'ordre compte, car une vérification de port élimine toute la couche réseau rapidement et vous permet d'arrêter de chercher de ce côté-là.

Une courte liste de vérifications quand un port ne s'ouvre pas

1. Confirmez que le service écoute sur la machine, et sur la bonne interface. Un service lié à 127.0.0.1 est injoignable depuis partout ailleurs, et c'est une cause très fréquente.
2. Vérifiez le pare-feu de l'hôte (ufw, firewalld, ou le pare-feu Windows).
3. Vérifiez le groupe de sécurité cloud ou l'ACL réseau, qui est une couche distincte du pare-feu de l'hôte et souvent oubliée.
4. Vérifiez toute redirection de port sur un routeur ou un NAT si la machine n'est pas directement sur une adresse publique.
5. Confirmez que le fournisseur ne bloque pas ce port, en particulier pour les ports de messagerie.
6. Retestez depuis un troisième réseau pour écarter votre propre filtrage sortant.

Revérifier selon un horaire régulier

Une vérification de port vous dit l'état à cet instant, depuis l'endroit où la sonde s'est exécutée. Les ports ne se ferment généralement pas d'eux-mêmes. Les règles de pare-feu sont modifiées, les groupes de sécurité sont resserrés, les certificats expirent et les services cessent de redémarrer après un reboot, et rien de tout cela ne s'annonce. La surveillance de port programmée se reconnecte à intervalle régulier depuis plusieurs emplacements et alerte quand la connexion cesse de réussir, ce qui détecte aussi le cas où le port est joignable depuis une région et filtré depuis une autre. Testez un port maintenant avec l'outil de vérification de port. Quand le port s'ouvre mais que TLS échoue, la suite logique à lire est comment vérifier l'expiration d'un certificat.