Linux / Commande nc : tester TCP et interpréter les limites UDP

nc, ou Netcat, ouvre des communications TCP ou UDP et peut aussi attendre des connexions. Pour un contrôle TCP ponctuel, -z demande un test sans échange de données applicatives et -v rend le résultat plus visible. Une connexion réussie prouve seulement que cette tentative TCP a été acceptée ; elle ne valide ni la réponse de l’application ni sa sécurité.

Identifier la version avant de choisir les options

TCP signifie Transmission Control Protocol et établit une connexion ; UDP, User Datagram Protocol, transporte des datagrammes sans la même poignée de main. Plusieurs outils de cette famille existent : netcat OpenBSD, d’autres variantes netcat et Nmap Ncat. Le nom nc peut désigner une variante différente selon le paquet installé.

nc -h

Lisez cette aide et man nc sur la machine concernée. Si le programme s’appelle ncat, consultez ncat --help et sa propre documentation. Les exemples de connexion ci-dessous utilisent des options courantes ; la syntaxe d’écoute et la fin de flux doivent être vérifiées pour chaque implémentation.

nc [OPTIONS] HOTE PORT

-z ne signifie pas « aucun paquet réseau » : vérifier TCP nécessite un échange de connexion et peut laisser une trace dans les journaux. Choisissez un hôte et un port dont le contrôle est autorisé ; un test local ne garantit pas la même accessibilité depuis une autre machine.

Vérifier un port TCP et lire le résultat

nc -vz 127.0.0.1 22
nc -w 3 -vz 127.0.0.1 80

127.0.0.1 désigne la boucle locale IPv4. Les ports 22 et 80 sont des exemples : aucun service n’y est garanti. Le premier test demande si le port TCP 22 accepte une connexion ; le second applique aussi -w 3, dont le rôle exact dépend de la version. Dans nc OpenBSD, cette option limite l’attente de connexion et l’inactivité, pas toute opération possible de nc.

Pour un hôte distant autorisé, remplacez le nom et le port selon le service recherché :

nc -w 3 -vz example.com 443

Une sortie possible lorsque la connexion réussit, avec une formulation dépendant de la version :

Connection to example.com 443 port [tcp/https] succeeded!

Le mot https associé au port n’est pas une vérification du certificat. Le test ne négocie pas nécessairement TLS, Transport Layer Security, et ne lit pas une réponse HTTP. Pour examiner cette étape, utilisez la commande curl pour les requêtes et réponses HTTP.

• Connexion réussie : le chemin utilisé a permis cette connexion TCP à cet instant.
• Refus immédiat : aucun service n’accepte peut-être la connexion à cette adresse et ce port, ou une politique répond par un rejet. Le message seul ne désigne pas automatiquement un processus précis.
• Délai expiré : filtrage silencieux, chemin défaillant ou cible sans réponse font partie des causes possibles ; ce n’est pas une preuve unique de panne du serveur.

Si le nom possède plusieurs adresses, relevez l’adresse effectivement utilisée avant de comparer. Une écoute sur la boucle locale, IPv4 ou IPv6 peut donner un résultat différent d’une connexion à l’adresse externe.

Ouvrir une connexion directe et comprendre UDP

nc -v 127.0.0.1 22

Sans -z, nc permet normalement d’envoyer des octets saisis au clavier et d’afficher ceux du service. Un serveur SSH peut envoyer une bannière, mais ce n’est pas une session SSH authentifiée. N’envoyez pas de commandes arbitraires à un service ; Ctrl+C termine ce test interactif.

nc ne fournit pas automatiquement un chiffrement ou une authentification dans cette forme. Certaines variantes ont des fonctions supplémentaires, mais leurs options ne sont pas interchangeables. Un indicateur de TLS présent dans le manuel OpenBSD ne garantit pas sa présence dans le paquet netcat d’une distribution Linux.

Avec -u, la communication utilise UDP. Un socket UDP peut être préparé sans qu’un serveur distant confirme une connexion, contrairement à TCP. Le manuel OpenBSD avertit même que sa combinaison -uz rapporte un succès indépendamment de l’état de la cible. Ne transformez donc pas un succès de ce type en affirmation « port UDP ouvert ».

Pour confirmer un service UDP, utilisez une requête valide du protocole concerné et examinez sa réponse ou les observations réseau autorisées. Le silence seul ne distingue pas un service ouvert, une réponse filtrée et un paquet perdu.

Distinguer écoute locale et diagnostic de service

L’écoute crée réellement un point d’entrée. Choisissez explicitement l’adresse de boucle locale pour un essai local lorsque la syntaxe de votre outil le permet, et terminez le processus d’essai après usage. Dans nc OpenBSD, -w n’impose pas de limite à l’attente d’une connexion en mode -l ; ne comptez pas sur -w 3 pour fermer automatiquement un tel serveur.

Pour une panne, contrôlez d’abord sur le serveur l’adresse et le port d’écoute avec la commande ss pour les sockets et processus. Comparez ensuite le test depuis le point d’accès qui rencontre le problème, puis validez le protocole applicatif. Ces vérifications répondent à des questions distinctes.

Le manuel nc OpenBSD décrit sa syntaxe et ses limites UDP. Le guide officiel des modes de Nmap Ncat présente une autre implémentation : comparez les aides locales avant de transposer une commande.