Tester si un port sur un système distant est accessible (sans telnet)

Question

Tester si un port sur un système distant est accessible (sans telnet)

Demandé el 19 de Juillet, 2013: Quand la question a-t-elle été
985046 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

Dans le temps, on utilisait telnet pour voir si un port sur un hôte distant était ouvert : telnet hostname port tente de se connecter à n'importe quel port sur n'importe quel hôte et vous donne accès au flux TCP brut.

Aujourd'hui, les systèmes sur lesquels je travaille n'ont pas de telnet installé (pour des raisons de sécurité), et toutes les connexions sortantes vers tous les hôtes sont bloquées par défaut. Avec le temps, il est facile de ne plus savoir quels ports sont ouverts vers quels hôtes.

Existe-t-il un autre moyen de tester si un port sur un système distant est ouvert - en utilisant un système Linux avec un nombre limité de paquets installés, et telnet n'est pas disponible ?

Demandé el 19 de Juillet, 2013 par Pants

0 votes

En rapport : vérifier l'état d'un port sur un hôte distant à SO

Commenté el 30 de Décembre, 2015 par kenorb

0 votes

J'avais le même problème. La réponse de @Subhranath Chunder ci-dessous m'a aidé. Cependant, j'ai ensuite découvert que pour installer Telnet, il suffisait d'exécuter brew install telnet . Je pense donc que les utilisateurs de Linux peuvent faire de même avec yum y apt-get .

Commenté el 26 de Septembre, 2019 par Mig82

0 votes

Lorsque "toutes les connexions sortantes vers tous les hôtes sont bloquées par défaut", il sera impossible d'effectuer un tel test - vous êtes hors ligne.

Commenté el 27 de Novembre, 2020 par Jaap Joris Vens

Answer 1

5 Réponses

Answer 2

495voto

Subhranath Chunder Points 5021

Joli et verbeux ! Dans les pages du manuel.
Port unique :

nc -zv 127.0.0.1 80

Ports multiples :

nc -zv 127.0.0.1 22 80 8080

Gamme de ports :

nc -zv 127.0.0.1 20-30

Répondu el 3 de Décembre, 2013 par Subhranath Chunder (5021 Points )

2 votes

Parfait ! Cela produit un message clair de connexion réussie/échec avec une seule ligne. Notez que les plages multiples ne semblent pas fonctionner pour mon programme nc version ; seule la première gamme est testée.

Commenté el 18 de Mai, 2015 par Dan Sam

7 votes

Il a été pendu lors du procès Ubuntu 14.04 (Trusty Tahr) pour un serveur distant (même réseau local) pour des ports fermés (il s'est arrêté après 127 secondes) - donc pas très adapté dans les scripts. Il a cependant fonctionné pour un service qui avait un port ouvert. L'utilisation de l'option "-w2" pourrait être la solution.

Commenté el 21 de Juillet, 2015 par Adam V

8 votes

Utilisez l'option -u pour les ports UDP.

Commenté el 21 de Septembre, 2016 par Sulisu

Afficher 8 autres commentaires

Answer 3

368voto

lornix Points 10746

Bash a pu accéder TCP y UDP ports pendant un certain temps. De la page de manuel :

/dev/tcp/host/port
    If host is a valid hostname or Internet address, and port is an integer port number
    or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
    If host is a valid hostname or Internet address, and port is an integer port number
    or service name, bash attempts to open a UDP connection to the corresponding socket.

Vous pourriez donc utiliser quelque chose comme ça :

xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here

Taa Daa !

Répondu el 22 de Juillet, 2013 par lornix (10746 Points )

0 votes

Cela semble également fonctionner dans MinGW . Par exemple, un VNC sur 192.168.2.100 répond avec "RFB 003.008" en utilisant "cat < /dev/tcp/192.168.2.100/5900".

Commenté el 21 de Juillet, 2015 par Adam V

1 votes

Cependant, sur les ports qui n'étaient pas ouverts, il s'est arrêté au bout de 22 secondes (essai sur les ports suivants Ubuntu 14.04 (Trusty Tahr) pour un serveur distant). Il est intéressant de noter que le délai d'attente est beaucoup plus court que celui de nc (cf. La réponse de Thnee ).

Commenté el 21 de Juillet, 2015 par Adam V

0 votes

// Oh, c'est un de ces jours où j'adore ce site. Voici la partie du manuel de bash pour cette réponse : gnu.org/software/bash/manual/bashref.html#Redirections

Commenté el 23 de Janvier, 2016 par Nathan Basanese

Afficher 14 autres commentaires

Answer 4

119voto

Fedor Points 29890

Netcat est un outil utile :

nc 127.0.0.1 123 &> /dev/null; echo $?

La sortie sera 0 si le port 123 est ouvert, et 1 si elle est fermée.

Répondu el 19 de Juillet, 2013 par Fedor (29890 Points )

3 votes

C'est une réponse beaucoup plus élégante et scriptable que la mienne. Il est malheureux pour moi que les sysadmins conscients de la sécurité qui ont retenu telnet également retenu nc (bien que - étrangement - pas curl o wget ).

Commenté el 19 de Juillet, 2013 par Pants

1 votes

Oui, c'est complètement arbitraire et stupide.

Commenté el 19 de Juillet, 2013 par Fedor

3 votes

Laissez le FOR les déclarations commencent !

Commenté el 19 de Juillet, 2013 par Christian Hang

Afficher 7 autres commentaires

Answer 5

74voto

Batur Points 11

La méthode la plus simple, sans faire appel à un autre outil, tel que socat La réponse de @lornix est la même que celle donnée dans la réponse ci-dessus. Ceci est juste pour ajouter un exemple réel de la façon dont on pourrait utiliser le psuedo-appareil. /dev/tcp/... dans Bash si vous voulez, par exemple, tester si un autre serveur a un port donné accessible via la ligne de commande.

Exemples

Disons que j'ai un hôte sur mon réseau nommé skinner .

$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1 \
    && echo "It's up" || echo "It's down"
It's up

$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 && \
    echo "It's up" || echo "It's down"
It's down

La raison pour laquelle vous voulez envelopper le echo > /dev/... entre parenthèses comme ceci, (echo > /dev/...) car si vous ne le faites pas, vous obtiendrez ce type de messages lors des tests de connexions interrompues.

$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused

Ceux-ci ne peuvent pas simplement être redirigés vers /dev/null puisqu'ils proviennent de la tentative d'écrire des données sur le dispositif. /dev/tcp . Nous capturons donc toute cette sortie dans une sous-commande, c'est-à-dire (...cmds...) et rediriger la sortie de la sous-commande.

Répondu el 2 de Septembre, 2014 par Batur (11 Points )

2 votes

C'est excellent. J'aimerais qu'il soit voté en haut de la page. Je n'ai lu que cette partie de la page parce que j'ai accidentellement fait défiler la page avant de la fermer.

Commenté el 12 de Février, 2015 par Still.Tony

0 votes

@Okuma.Tony - oui, c'est toujours un problème avec les questions qui ont plusieurs réponses 8-). Merci pour le feedback, c'est apprécié.

Commenté el 12 de Février, 2015 par Batur

1 votes

Je l'aime bien. J'en ai fait un script pour mon propre usage !

Commenté el 9 de Novembre, 2021 par Marinaio

Afficher 5 autres commentaires

Answer 6

60voto

Pants Points 321

J'ai trouvé que curl peut faire le travail de la même manière que telnet et curl vous dira même quel protocole l'auditeur attend.

Construit un URI HTTP à partir du nom d'hôte et du port en tant que premier argument de la fonction curl . Si curl peut se connecter, il signalera une erreur de protocole et quittera (si l'écouteur n'est pas un service web). Si curl ne peut pas se connecter, la connexion sera interrompue.

Par exemple, le port 5672 de l'hôte 10.0.0.99 est soit fermé, soit bloqué par un pare-feu :

$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host

Cependant, à partir d'un autre système, le port 5672 sur l'hôte 10.0.0.99 peut être atteint et semble exécuter un listener AMQP.

$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP

Il est important de distinguer les différents messages : le premier échec était dû au fait que curl n'a pas pu se connecter au port. Le deuxième échec est un test de réussite, bien que curl attend un listener HTTP au lieu d'un listener AMQP.

Répondu el 19 de Juillet, 2013 par Pants (321 Points )

8 votes

Si curl n'est pas disponible, wget peut l'être. wget -qS -O- http://ip.add.re.ss:port devrait effectivement faire la même chose.

Commenté el 19 de Juillet, 2013 par user

4 votes

Cela fonctionne même avec un nom d'hôte, ex. curl myhost:22 .

Commenté el 25 de Février, 2014 par Chronocidal

0 votes

Voir mon poste avec une approche similaire.

Commenté el 30 de Décembre, 2015 par kenorb

Tester si un port sur un système distant est accessible (sans telnet)

Réponses

Exemples

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

Tester si un port sur un système distant est accessible (sans telnet)

Réponses

Exemples

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: