Implementaremos una nueva aplicación en un servidor y la aplicación escuchará en el puerto 8443. Hemos pedido al equipo de red que abra el firewall para el puerto 8443 en ese servidor antes de implementar la aplicación. Actualmente no hay ninguna aplicación escuchando en ese puerto en particular en el servidor.
¿Hay alguna forma de asegurarme de que el firewall esté abierto para el puerto 8443?
SO: Linux / Windows
Respuestas:
Si desea ver si puede formar una conexión TCP desde una máquina remota, instale OpenCSW en esa máquina y en la máquina de destino, e instale netcat en ambas. Esta es la sintaxis para usar netcat para probar las conexiones TCP:
nc -vz targetServer portNum
Por ejemplo, para comprobar SSH en "homeServer1":
nc -vz homeserver1 22
Eso le permite probar la conectividad de nivel TCP desde el sistema remoto. Netcat también se puede configurar para escuchar en un puerto en lugar de actuar como un cliente. Para que escuche en TCP / 8443:
En el servidor que albergará la aplicación: nc -l homeserver1 8443
En una máquina que se encuentra fuera del firewall: nc -vz homeserver.fqdn 8443
Este es un ejemplo de una ejecución exitosa:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Una ejecución fallida:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
Los firewalls deben responder con un mensaje ICMP cuando bloquean una solicitud. Sin embargo, este no es necesariamente el caso (le interesará este bonito artículo ).
Puede probar desde el exterior para ver si se puede acceder a un puerto a través de un firewall y, si es así, si hay algo escuchando en él. Aquí hay tres escenarios diferentes que involucran una solicitud de TCP que puede observar con wireshark, o algún otro sniffer de paquetes, y lo que verá:
1) Firewall rechaza la solicitud
Recibirá un mensaje ICMP, y la herramienta que realiza la solicitud debe decirle inmediatamente algo al respecto ("inalcanzable, prohibido por el administrador", etc.). Por "herramienta" me refiero al cliente que está utilizando para enviar la solicitud (que utilicé telnet). Los detalles del mensaje 1 dependen de cómo esté configurado el firewall, pero el "puerto inalcanzable" es probablemente el más común.
"Ninguna ruta al host" puede indicar esto, pero también puede indicar problemas de enrutamiento más sutiles.
2) Firewall descarta el paquete
No hay respuesta, por lo que la herramienta espera hasta que se agote el tiempo o se aburra.
3) Firewall permite paquetes (o no hay firewall), pero nada está escuchando en el puerto.
Recibirá un mensaje TCP RST / ACK. Supongo que el protocolo TCP requiere esto. En otras palabras, si nada está escuchando en el puerto, el sistema operativo envía esta respuesta. Puede ser difícil distinguir esto del # 1 solo en función de lo que informa una herramienta, porque puede decir lo mismo en ambos casos (sin embargo, lo más probable es que lo distinga como "conexión rechazada" vs. # 1, "red inalcanzable" ) Observado en un sniffer de paquetes en la máquina cliente, el escenario n. ° 1 (mensaje de rechazo ICMP) y el n. ° 3 (mensaje TCP RST / ACK) son claramente distintos.
La única otra opción aquí es que el firewall deja pasar el paquete y algo está escuchando, por lo que obtienes una conexión exitosa.
En otras palabras: suponiendo que su red en general funciona correctamente, si obtiene # 1 o # 2, significa que un firewall impide activamente el acceso al puerto. # 3 sucederá si su servidor no se está ejecutando pero el puerto es accesible, y por supuesto (el implícito) # 4 es una conexión exitosa.
Puede usar el comando netstatpara ver si un puerto está abierto y escuchando.
$ netstat -anp | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:41716 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 3034/dropbox
tcp 0 0 0.0.0.0:17501 0.0.0.0:* LISTEN 3033/dropbox
tcp 0 0 127.0.0.1:2143 0.0.0.0:* LISTEN 3191/ssh
tcp 0 0 127.0.0.1:2025 0.0.0.0:* LISTEN 3191/ssh
La salida muestra procesos (columna más a la derecha) que están escuchando en los puertos TCP. Los números de puerto son los números que siguen a los dos puntos después de las direcciones IP (0.0.0.0:111 sería el puerto 111, por ejemplo).
Las direcciones IP muestran direcciones locales y extranjeras . Local sería su sistema, mientras que Foreign sería cualquier dirección que se conecte a su puerto TCP o que usted se conecte a uno de sus puertos TCP.
Entonces, en el caso del puerto 22, ese es el demonio ssh que se ejecuta en mi sistema, eso es ESCUCHAR las conexiones. Una vez que alguien intenta conectarse al sshdemonio, bifurca una copia de sí mismo y empuja esa conexión a otro puerto, manteniendo el puerto TCP 22 abierto para conexiones adicionales a medida que ingresan.
netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}'
La configuración y el estado de la configuración del firewall son específicos del firewall / OS.
Lo que puedes hacer es probarlo desde el servidor2:
nmap server1
Recientemente recibí la misma solicitud y llegué al hilo. Pude escanear puertos abiertos en el FW con el comando nc, así cuando consulto su salida:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Básicamente, si me 'agota el tiempo de espera' significa que el puerto no está abierto en el FW.
ncinforma "Conexión rechazada" cuando el puerto es accesible, pero no hay escucha, y "La red no está disponible" cuando la solicitud ha sido rechazada por un firewall a través de icmp (lo que significa que puede o no haber un servicio en el puerto ) Si el cortafuegos deja caer el paquete en lugar de rechazarlo,ncse bloqueará por un tiempo.