Avant de modifier une règle de pare-feu, il faut déjà savoir où se situe le blocage. Le service écoute-t-il vraiment ? Le port est-il accessible depuis la machine cliente ? netcat, appelé avec la commande nc, permet de répondre rapidement à ces questions sans installer un outil de supervision complet.
Dans ce guide, vous allez tester un port TCP, poser un délai d’attente, lancer une écoute de laboratoire et comparer le résultat avec ss. N’utilisez pas netcat pour transférer des données sensibles : les échanges ne sont pas chiffrés.
Vérifier un port TCP avec nc
La forme la plus utile pour un premier test est la suivante :
nc -vz -w 3 serveur.exemple.net 443-vaffiche le détail de la connexion ;-zdemande une simple vérification, sans envoyer de données ;-w 3limite l’attente à trois secondes.
Remplacez le nom d’hôte et le port par vos valeurs. Un message du type succeeded ou open indique que la connexion TCP a été établie. Cela prouve que le chemin réseau et le filtrage autorisent ce port, mais pas que l’application répond correctement à toutes les requêtes.
À l’inverse, Connection refused signifie généralement que la machine est joignable mais qu’aucun service n’accepte la connexion sur ce port. Un délai qui expire peut correspondre à un pare-feu silencieux, à une route absente, à une mauvaise adresse IP ou à un service complètement inaccessible.
Comparer avec les ports réellement ouverts
Le test depuis un autre poste doit être complété par une vérification locale sur le serveur. Affichez les sockets en écoute avec :
sudo ss -ltnp
sudo ss -ltnp | grep ':443b'ss vous montre notamment l’adresse d’écoute, le port et, avec les droits nécessaires, le processus associé. Si le service écoute seulement sur 127.0.0.1, un test lancé depuis une autre machine échouera même si le programme fonctionne localement. Une écoute sur 0.0.0.0 ou sur l’adresse réseau du serveur change ce comportement, mais ne doit pas être activée sans vérifier le pare-feu et l’exposition réelle.
Vous pouvez donc procéder dans cet ordre : ss sur le serveur, puis nc depuis le client, puis seulement l’inspection des règles UFW, nftables ou iptables. Cela évite de modifier le filtrage alors que le service n’écoute tout simplement pas.
Tester une écoute dans un environnement de laboratoire
Pour vérifier un chemin TCP entre deux machines que vous contrôlez, démarrez une écoute temporaire sur la machine serveur :
nc -lv 127.0.0.1 9000Dans un second terminal, sur la même machine, lancez le client :
printf 'test netcatn' | nc -v -w 3 127.0.0.1 9000Le terminal qui écoute doit recevoir le texte. Utilisez une adresse et un port dédiés au test, puis arrêtez netcat avec Ctrl+C. Sur certaines distributions, les options varient entre OpenBSD netcat, GNU netcat et ncat fourni avec Nmap. Si -lv est refusé, consultez nc -h et adaptez la syntaxe. Ne lancez pas d’écoute sur une interface publique par habitude.
Et pour l’UDP ?
UDP ne crée pas de connexion persistante comme TCP. Vous pouvez envoyer un datagramme avec :
printf 'test udpn' | nc -u -w 2 serveur.exemple.net 5353L’absence d’erreur ne prouve pas que le serveur a reçu le paquet. Pour confirmer le résultat, observez le service destinataire ou capturez le trafic avec tcpdump. Un test UDP isolé est donc moins conclusif qu’un test TCP réussi.
Ce que le test permet vraiment de conclure
Netcat répond à une question précise : « ce chemin permet-il d’ouvrir ce port avec ce protocole ? » Il ne remplace ni les logs du service, ni ss, ni l’analyse complète du pare-feu. Pour poursuivre le diagnostic, vous pouvez comparer le résultat avec le guide sur les ports ouverts sous Linux et utiliser tcpdump pour observer les paquets.
Commencez par ce test simple avant de toucher à la configuration réseau. Vous saurez ainsi si le problème vient de l’écoute locale, du chemin réseau ou du filtrage.