Test, ob ein Port auf einem Remote-System erreichbar ist (ohne Telnet)

Früher haben wir geprüft telnet, ob ein Port auf einem Remote-Host geöffnet war: Es wurde telnet hostname portversucht, eine Verbindung zu einem beliebigen Port auf einem beliebigen Host herzustellen, und Sie haben Zugriff auf den rohen TCP-Stream.

In diesen Tagen ist auf den Systemen, auf denen ich arbeite, aus Sicherheitsgründen kein Telnet installiert, und alle ausgehenden Verbindungen zu allen Hosts werden standardmäßig blockiert. Mit der Zeit ist es leicht, den Überblick zu verlieren, welche Ports für welche Hosts geöffnet sind.

Gibt es eine andere Möglichkeit zu testen, ob ein Port auf einem Remote-System offen ist - unter Verwendung eines Linux-Systems mit einer begrenzten Anzahl installierter Pakete, telnetdas nicht verfügbar ist?

Bash kann seit einiger Zeit auf TCP- und UDP- Ports zugreifen . Von der Manpage:

/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.

Sie könnten also so etwas verwenden:

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

Taa Daa!

Schön und ausführlich! Aus den Manpages.
Einzelner Port:

nc -zv 127.0.0.1 80

Mehrere Ports:

nc -zv 127.0.0.1 22 80 8080

Reihe von Häfen:

nc -zv 127.0.0.1 20-30

Netcat ist ein nützliches Werkzeug:

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

Wird ausgegeben, 0wenn Port 123 offen und 1geschlossen ist.

Die einfachste Methode, ohne ein anderes Tool wie z. B. zu verwenden socat, ist die in der obigen Antwort von @ lornix beschriebene. Dies ist nur ein Beispiel dafür, wie man das psuedo-Gerät /dev/tcp/...in Bash verwenden würde, wenn man beispielsweise testen möchte, ob ein anderer Server einen bestimmten Port hat, auf den über die Befehlszeile zugegriffen werden kann.

Beispiele

Angenommen, ich habe einen Host in meinem Netzwerk namens 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

Der Grund, warum Sie die echo > /dev/...Klammern wie (echo > /dev/...)folgt einschließen möchten , ist, dass Sie, wenn Sie dies nicht tun, bei Tests von Verbindungen, die inaktiv sind, diese Arten von Nachrichten angezeigt bekommen.

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

Diese können nicht einfach umgeleitet werden, /dev/nullda sie aus dem Versuch stammen, Daten auf das Gerät zu schreiben /dev/tcp. Wir erfassen also die gesamte Ausgabe innerhalb eines Unterbefehls (...cmds...)und leiten die Ausgabe des Unterbefehls um.

Ich habe festgestellt, dass curlder Job möglicherweise auf ähnliche Weise erledigt wird telnet, und curlIhnen sogar sagen wird, welches Protokoll der Hörer erwartet.

Erstellen Sie einen HTTP-URI aus dem Hostnamen und dem Port als erstes Argument für curl. Wenn curleine Verbindung hergestellt werden kann, wird ein Protokollkonflikt gemeldet und beendet (wenn der Listener kein Webdienst ist). Wenn curlkeine Verbindung hergestellt werden kann, tritt eine Zeitüberschreitung auf.

Beispielsweise ist Port 5672 auf Host 10.0.0.99 entweder geschlossen oder von einer Firewall blockiert:

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

Von einem anderen System aus kann jedoch Port 5672 auf Host 10.0.0.99 erreicht werden, auf dem anscheinend ein AMQP-Listener ausgeführt wird.

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

Es ist wichtig, zwischen den verschiedenen Nachrichten zu unterscheiden: Der erste Fehler war, dass curlkeine Verbindung zum Port hergestellt werden konnte. Der zweite Fehler ist ein Erfolgstest, obwohl curlein HTTP-Listener anstelle eines AMQP-Listeners erwartet wird.

[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused

[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!

Hoffe es löst dein Problem :)

Hier ist ein Einzeiler:

</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed

unter Verwendung der Bash-Syntax erklärt in @lornix Antwort .

Weitere Informationen finden Sie im Advanced Bash-Scripting Guide: Kapitel 29. /devund/proc .

Ich kämpfte einen ganzen Tag lang, weil keine dieser Antworten für mich zu funktionieren schien. Das Problem ist, dass die neueste Version von ncdas -zFlag nicht mehr hat , während der direkte Zugriff über TCP (wie bei @lornix und @slm) fehlschlägt, wenn der Host nicht erreichbar ist. Ich fand schließlich diese Seite , auf der ich endlich nicht nur ein, sondern zwei Arbeitsbeispiele fand:

1. nc -w1 127.0.0.1 22 </dev/null

   (Das -wFlag kümmert sich um das Timeout und </dev/nullersetzt das -zFlag.)

2. timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'

   (Der timeoutBefehl kümmert sich um das Timeout und der Rest kommt von @slm)

Verwenden Sie dann einfach &&und / oder ||(oder sogar $?), um das Ergebnis zu extrahieren. Hoffentlich findet jemand diese Informationen nützlich.

Wenn Sie die Antworten von @kenorb und @Azukikuru kombinieren, können Sie Port offen / geschlossen / Firewall testen.

timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout

Ein weiterer Ansatz mit Curl zum Erreichen eines beliebigen Ports

curl telnet://127.0.0.1:22

Hier ist eine Funktion, die eine der Methoden auswählt, je nachdem, was auf Ihrem System installiert ist:

# Check_port <address> <port> 
check_port() {
if [ "$(which nc)" != "" ]; then 
    tool=nc
elif [ "$(which curl)" != "" ]; then
     tool=curl
elif [ "$(which telnet)" != "" ]; then
     tool=telnet
elif [ -e /dev/tcp ]; then
      if [ "$(which gtimeout)" != "" ]; then  
       tool=gtimeout
      elif [ "$(which timeout)" != "" ]; then  
       tool=timeout
      else
       tool=devtcp
      fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout)  gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout)  timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp)  </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac

}
export check_port

Es sollte nicht auf Ihrer Box verfügbar sein, aber versuchen Sie es mit nmap.

als Referenz, um die Antwort von @peperunas zu erweitern:

Mit nmap können Sie Folgendes testen:

nmap -p 22 127.0.0.1

(Beispiel oben verwendet localhost zu Demonstrationszwecken)

Wenn Sie mehr als nur ein System testen müssen, können Sie für solche Aufgaben unser Testtool dda-serverspec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ) verwenden. Sie können Ihre Erwartungen definieren

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

und testen Sie diese Erwartung entweder gegen localhost oder gegen Remote-Hosts (Verbindung über ssh). Für Ferntests müssen Sie Ziele definieren:

{: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"}}

Sie können den Test mit ausführen java -jar dda-serverspec.jar --targets targets.edn serverspec.edn

Unter der Haube benutzen wir Netcat wie oben vorgeschlagen ...