454 votes

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

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 ?

0 votes

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 .

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.

3voto

peperunas Points 1031

Il ne devrait pas être disponible sur votre boîte, mais essayez avec nmap .

4 votes

nmap est un bon outil, mais il n'est pas disponible sur ces systèmes. Plutôt que de télécharger nmap J'espérais trouver un moyen d'utiliser les outils existants disponibles dans la plupart des installations Linux.

2voto

groo Points 121

Si vous avez installé curl :

curl -v telnet://$host:$port/$path

0 votes

(1)Je présume que vous voulez dire que la curl -v telnet:// le : et le (dernier) / sont littérales, et $host y $port sont des caractères de substitution pour le nom/adresse de l'hôte en question et le numéro de port en question. Que doit utiliser l'utilisateur pour $path ? (2) Si le port est ouvert, mais qu'il ne met pas en œuvre HTTP, on peut s'attendre à ce que cette commande échoue. Comment faire la différence entre un échec parce que le port n'est pas ouvert et un échec parce que le port n'est pas HTTP ? (Suite)

0 votes

(suite) (3) curl http://host:port a déjà été donnée comme réponse (qui était claire sur le point#1 et discutée sur le point#2). Voulez-vous dire que curl -v telnet: est supérieur à curl http: Pourquoi ? (4)Et il y a un autre réponse qui suggère curl http://host:port et il y en a même un autre qui suggère que curl telnet://host:port . Qu'est-ce que votre réponse ajoute à celles qui l'ont précédée ? Plus de réponses incomplètes ; modifier votre réponse pour la rendre plus claire et plus complète.

1voto

user138278 Points 285

Pour référence, développant la réponse de @peperunas :

la façon d'utiliser nmap à tester, est :

nmap -p 22 127.0.0.1

(l'exemple ci-dessus utilise localhost à des fins de démonstration)

0voto

user306763 Points 23

Si vous devez tester plus d'un système, vous pouvez utiliser notre outil de test dda-serverspec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ) pour de telles tâches. Vous pouvez définir vos attentes

{:netcat [{:host "mywebserver.com" :port "443"}
          {:host "telnet mywebserver.com" :port "80"}
          {:host "telnet mywebserver.com" :port "8443"}]}

et testez ces attentes soit contre l'hôte local, soit contre des hôtes distants (connexion par ssh). Pour les tests à distance, vous devez définir une cible :

{:existing [{:node-name "test-vm1"
             :node-ip "35.157.19.218"}
            {:node-name "test-vm2"
             :node-ip "18.194.113.138"}]
 :provisioning-user {:login "ubuntu"}}

Vous pouvez exécuter le test avec java -jar dda-serverspec.jar --targets targets.edn serverspec.edn

Sous le capot, nous utilisons netcat comme proposé ci-dessus ...

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X