La moitié des billets qui commencent par « le service n’est pas joignable » sont en réalité des questions de joignabilité depuis l’extérieur du réseau où l’utilisateur est assis. Son portable dit que le port est fermé ; votre bastion dit que le même port est ouvert ; la supervision du client dit que c’est intermittent. Tant que personne n’a lancé la sonde depuis un emplacement connu sur l’internet public, la conversation tourne en rond. C’est à cela que sert la Vérification de port TCP de PortJar — une sonde rapide depuis un point de vue neutre, avec une bannière jointe quand le service parle en premier.
Ce que fait l’outil
La Vérification de port TCP ouvre une connexion TCP depuis un serveur PortJar vers l’hôte et le port que vous indiquez, puis rapporte un de trois verdicts : ouvert, fermé ou filtré. Ouvert signifie que la poignée de main en trois temps s’est terminée et qu’un service écoute. Fermé signifie que l’hôte a répondu avec un RST TCP — il y a quelqu’un, mais rien n’est lié à ce port. Filtré signifie qu’aucune réponse n’est revenue avant l’expiration du délai, ce qui pointe presque toujours vers un pare-feu qui jette le paquet silencieusement plutôt que vers un hôte qui n’existe simplement pas.
Quand le service à l’autre bout envoie des données immédiatement après la poignée de main — SMTP, FTP, SSH, IRC, MySQL et quelques autres le font tous — la bannière est capturée et retournée à côté du verdict ouvert/fermé. Cette seule ligne de texte est souvent plus utile que le verdict lui-même, parce qu’elle confirme non seulement que quelque chose écoute sur le port, mais exactement quelle version de quel démon. UDP et le balayage brut sont hors portée.
Comment l’utiliser
Ouvrez portjar.com/tools/port-check, entrez le nom d’hôte ou l’IP, et le numéro de port. Lancez. La sonde se termine en quelques secondes pour les ports ouverts ou fermés ; les résultats filtrés prennent tout le délai, ce qui est le signal le plus fiable qu’un pare-feu est impliqué. L’URL est sans état — collez-la dans un billet pour que la prochaine personne voie la même sonde.
Quand vous y recourriez
- Confirmer qu’une règle de pare-feu a réellement pris effet. Une nouvelle règle entrante a été ajoutée dans la console infonuagique, mais vous voulez un verdict tiers depuis l’extérieur du VPC avant de dire au client que le port est ouvert. Demander à votre propre bastion ne prouve rien — votre bastion est probablement dans la même zone de confiance.
- Régler un débat « est-ce que le relais SMTP écoute sur 587 ? ». La capture de bannière vous montre le démon et la version exacts qui répondent sur le port 587, ce qui vous dit immédiatement si le mauvais service est lié ou si le bon est monté avec une configuration brisée.
- Diagnostiquer un rapport « le conteneur tourne mais est injoignable ». Lancez la sonde contre l’IP publique de l’hôte et le port publié. Si elle retourne filtré, le pare-feu hôte ou le groupe de sécurité est en cause. Si fermé, le port n’est pas lié là où vous le pensez — le plus souvent parce qu’on a confondu EXPOSE avec
-p. - Vérifier un DNAT ou une bascule d’équilibreur de charge. Après avoir repointé un point d’accès public vers un nouveau backend, sondez le port public pour confirmer que le nouveau chemin répond avant qu’un client n’essaie.
- Vérifier rapidement une affirmation « on vous a ouvert le port 443 » de l’équipe TI d’un client. La sonde prend cinq secondes et règle le différend sans partage d’écran.
Quoi faire de la sortie
Traitez ouvert comme un signal positif fort — quelque chose écoute et accepte des connexions depuis l’internet public. Si vous avez obtenu une bannière, encore mieux ; la bannière est la réponse définitive à « qu’est-ce qui tourne réellement là ». Une bannière de nginx/1.18.0 sur le port 25 est en soi un constat à investiguer.
Traitez fermé comme un signal négatif fort à la couche applicative — l’hôte est joignable, mais rien n’est lié à ce port. Regardez l’unité de service, le mappage de port du conteneur, ou le groupe cible de l’équilibreur de charge.
Traitez filtré comme un verdict de pare-feu, pas un verdict de service. Quelque part entre PortJar et la destination, le SYN a été jeté silencieusement. Coupables habituels : groupes de sécurité infonuagiques, pare-feu d’entrée d’un fournisseur en amont, règle iptables au niveau de l’hôte, ou la destination qui n’existe simplement pas. Combinez la sonde avec le guide PortJar sur connexion expirée vs. connexion refusée pour l’étape suivante.
Un résultat ouvert ou fermé surprenant sur un port que le client prétend pare-feu est en soi un constat — les groupes de sécurité dérivent, et « on a configuré ça il y a deux ans » n’équivaut pas à « c’est configuré aujourd’hui ».
Stack Harbor utilise la Vérification de port TCP comme étape de vérification routinière lors des bascules et des changements de pare-feu réalisés dans le cadre du soutien et de la supervision.