Pruebe si un puerto en un sistema remoto es accesible (sin telnet)

En los viejos tiempos, solíamos telnetver si un puerto en un host remoto estaba abierto: telnet hostname portintentaría conectarse a cualquier puerto en cualquier host y le daría acceso a la transmisión TCP sin procesar.

En estos días, los sistemas en los que trabajo no tienen telnet instalado (por razones de seguridad), y todas las conexiones salientes a todos los hosts están bloqueadas de forma predeterminada. Con el tiempo, es fácil perder la noción de qué puertos están abiertos para qué hosts.

¿Hay otra forma de probar si un puerto en un sistema remoto está abierto, usando un sistema Linux con un número limitado de paquetes instalados y telnetno está disponible?

Bash ha podido acceder a los puertos TCP y UDP por un tiempo. Desde la página del manual:

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

Entonces podrías usar algo como esto:

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

Taa Daa!

Agradable y detallado! De las páginas del manual.
Puerto único:

nc -zv 127.0.0.1 80

Múltiples puertos:

nc -zv 127.0.0.1 22 80 8080

Rango de puertos:

nc -zv 127.0.0.1 20-30

Netcat es una herramienta útil:

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

Saldrá 0si el puerto 123 está abierto y 1si está cerrado.

El método más simple, sin utilizar otra herramienta, como socat, es como se describe en la respuesta de @ lornix anterior. Esto es solo para agregar un ejemplo real de cómo se haría uso del dispositivo psuedo /dev/tcp/...dentro de Bash si quisiera, por ejemplo, probar si otro servidor tenía un puerto determinado accesible a través de la línea de comando.

Ejemplos

Digamos que tengo un host en mi red llamado 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 razón por la que desea envolver el echo > /dev/...paréntesis de esta manera (echo > /dev/...)es porque si no lo hace, con las pruebas de conexiones inactivas, aparecerá este tipo de mensajes.

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

Estos no pueden simplemente ser redirigidos /dev/nullya que provienen del intento de escribir datos en el dispositivo /dev/tcp. Entonces capturamos toda esa salida dentro de un subcomando, es decir, (...cmds...)y redirigimos la salida del subcomando.

Descubrí que curlpuede hacer el trabajo de una manera similar telnete curlincluso le dirá qué protocolo espera el oyente.

Construya un URI HTTP a partir del nombre de host y el puerto como primer argumento para curl. Si curlpuede conectarse, informará una falta de coincidencia de protocolo y saldrá (si el oyente no es un servicio web). Si curlno puede conectarse, se agotará el tiempo de espera.

Por ejemplo, el puerto 5672 en el host 10.0.0.99 está cerrado o bloqueado por un firewall:

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

Sin embargo, desde un sistema diferente, se puede acceder al puerto 5672 en el host 10.0.0.99, y parece estar ejecutando un escucha AMQP.

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

Es importante distinguir entre los diferentes mensajes: el primer error fue porque curlno se pudo conectar al puerto. La segunda falla es una prueba de éxito, aunque se curlesperaba un escucha HTTP en lugar de un escucha AMQP.

[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!

Espero que resuelva tu problema :)

Aquí hay una frase:

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

usando la sintaxis de Bash explicada en @lornix answer .

Para obtener más información, consulte: Guía avanzada de secuencias de comandos Bash: Capítulo 29. /devy/proc .

Estuve luchando durante todo un día porque ninguna de estas respuestas parecía funcionar para mí. El problema es que la versión más reciente de ncya no tiene la -zbandera, mientras que el acceso directo a través de TCP (según @lornix y @slm) falla cuando no se puede acceder al host. Finalmente encontré esta página , donde finalmente encontré no uno sino dos ejemplos de trabajo:

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

   (la -wbandera se encarga del tiempo de espera y la </dev/nullreemplaza -z)

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

   (el timeoutcomando se encarga del tiempo de espera y el resto es de @slm)

Luego, simplemente use &&y / o ||(o incluso $?) para extraer el resultado. Con suerte, alguien encontrará útil esta información.

Combinando las respuestas de @kenorb y @Azukikuru, podría probar el puerto abierto / cerrado / cortafuegos.

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

Otro enfoque con rizo para llegar a cualquier puerto

curl telnet://127.0.0.1:22

Aquí hay una función que elegirá uno de los métodos dependiendo de lo que esté instalado en su sistema:

# 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

No debería estar disponible en su caja, pero intente con nmap.

como referencia, ampliando la respuesta de @peperunas:

La forma de usar nmap para probar es:

nmap -p 22 127.0.0.1

(el ejemplo anterior usa localhost para fines de demostración)

Si tiene que probar más que en el sistema, puede usar nuestra herramienta de prueba dda-serverpec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ) para tales tareas. Puedes definir tus expectativas

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

y pruebe estas expectativas ya sea contra localhost o contra hosts remotos (conectarse mediante ssh). Para las pruebas remotas, debe definir un objetivo:

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

Puede ejecutar la prueba con java -jar dda-serverspec.jar --targets targets.edn serverspec.edn

Debajo del capó estamos usando netcat como se propuso arriba ...