Solution 1 :
Vous pouvez vérifier si un processus écoute sur un port TCP ou UDP avec netstat -tuplen .
Pour vérifier si certains ports sont accessibles de l'extérieur (c'est probablement ce que vous voulez) vous pouvez utiliser un scanner de ports comme Nmap d'un autre système. Exécuter Nmap sur le même hôte que vous souhaitez vérifier est tout à fait inutile pour votre objectif.
Solution 2 :
Le moyen le plus rapide de tester si un port TCP est ouvert (y compris les pare-feu matériels que vous pourriez avoir) consiste à taper, depuis un ordinateur distant (par exemple, votre bureau) :
telnet myserver.com 80
Qui essaiera d'ouvrir une connexion au port 80 sur ce serveur. Si vous obtenez un délai d'attente ou un refus, le port n'est pas ouvert :)
Solution 3 :
OK, en résumé, vous avez un serveur auquel vous pouvez vous connecter. Vous voulez voir si quelque chose écoute sur un port. En tant que root, exécutez :
netstat -nlp
cela affichera une liste des processus écoutant sur les ports TCP et UDP. Vous pouvez le scanner (ou le grep) pour le processus qui vous intéresse et/ou les numéros de port que vous vous attendez à voir.
Si le processus que vous attendez n'est pas là, vous devez démarrer ce processus et vérifier à nouveau netstat. Si le processus est là, mais qu'il écoute sur une interface et un port auxquels vous ne vous attendiez pas, il y a un problème de configuration (par exemple, il pourrait être à l'écoute, mais uniquement sur l'interface de bouclage, vous verriez donc 127.0.0.1:3306 et pas d'autres lignes pour le port 3306, dans le cas de la configuration par défaut pour MySQL).
Si le processus est en place et qu'il écoute sur le port que vous attendez, vous pouvez essayer d'exécuter un "telnet" sur ce port depuis votre Macbook dans votre bureau/maison, par exemple,
telnet xxxxxxxxxxxx.co.uk 443
Cela testera si (en supposant des ports standard) qu'il existe un serveur Web configuré pour SSL. Notez que ce test utilisant telnet ne fonctionnera que si le processus écoute sur un port TCP. S'il s'agit d'un port UDP, vous pouvez également essayer avec n'importe quel client que vous alliez utiliser pour vous y connecter. (Je vois que vous avez utilisé le port 224. C'est masqdialer, et je n'ai aucune idée de ce que c'est).
Si le service est là, mais que vous ne pouvez pas y accéder de l'extérieur, c'est qu'un pare-feu vous bloque. Dans ce cas, exécutez :
iptables -L -n
Cela affichera toutes les règles de pare-feu telles que définies sur votre système. Vous pouvez publier cela, mais, en général, si vous n'autorisez pas tout sur la chaîne INPUT, vous devrez probablement autoriser explicitement le trafic sur le port en question :
iptables -I INPUT -p tcp --dport 224 -j ACCEPT
Ou quelque chose de ce genre. N'exécutez pas vos commandes de pare-feu aveuglément en vous basant sur ce qu'un inconnu vous a dit sur Internet. Pensez à ce que vous faites.
Si votre pare-feu sur la boîte autorise le trafic que vous voulez, alors votre société d'hébergement exécute peut-être un pare-feu (par exemple, ils n'autorisent que SSH (22/tcp), HTTP (80/tcp) et HTTPS (443/tcp) et refusant tout autre trafic entrant). Dans ce cas, vous devrez ouvrir un ticket d'assistance avec eux pour résoudre ce problème, bien que je suppose qu'il pourrait y avoir quelque chose dans votre cPanel qui pourrait le permettre.
Solution 4 :
J'utilise le combo de netstat et lsof :
netstat -an | grep <portnumber>
lsof -i:<portnumber>
Pour voir si le port est utilisé et ce qui l'utilise.
Solution 5 :
Si vous êtes connecté au système et que vous pouvez exécuter une commande en tant que root, vous pouvez vérifier la sortie d'iptables
iptables -L -vn
cela listera les règles de pare-feu et quels ports sont la cible ouverte ACCEPT et tous les ports explicitement fermés ciblent REJECT .