Implementaremos una nueva aplicación en un servidor y la aplicación escuchará en el puerto 8443. Le 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 del servidor.
¿Hay alguna forma de asegurarme de que el firewall esté abierto para el puerto 8443?
Sistema operativo: Linux/Windows
Respuesta1
Si desea ver si puede formar una conexión TCP desde una máquina remota, instale OpenCSW en esa máquina y en la de destino, e instale netcat en ambas. Esta es la sintaxis para usar netcat para probar conexiones TCP:
nc -vz targetServer portNum
Por ejemplo, para comprobar SSH en "homeServer1":
nc -vz homeserver1 22
Eso le permite probar la conectividad a nivel de TCP desde el sistema remoto. Netcat también se puede configurar para escuchar en un puerto en lugar de actuar como 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
Respuesta2
Cortafuegosdeberíaresponder con unmensaje ICMPcuando bloquean una solicitud. Sin embargo, este no es necesariamente el caso (le interesaráeste bonito articulo).
Puede realizar pruebas desde el exterior para ver si se puede acceder a un puerto a través de un firewall y, de ser así, si hay algo escuchando en él. Aquí hay tres escenarios diferentes que involucran una solicitud TCP que puede observar con wireshark, o algún otro rastreador de paquetes, y lo que verá:
1) El firewall rechaza la solicitud
Recibirá un mensaje ICMP y la herramienta que realiza la solicitud debería informarle inmediatamente algo en este sentido ("inalcanzable, administrador prohibido", etc.). Por "herramienta" me refiero al cliente que está utilizando para enviar la solicitud (yo usé telnet). Los detalles del mensaje 1 dependen de cómo esté configurado el firewall, pero "puerto inalcanzable" es probablemente el más común.
"No hay ruta al host" puede indicar esto, pero también puede indicar problemas de enrutamiento más sutiles.
2) Paquete de caídas de firewall
No hay respuesta, por lo que la herramienta espera hasta que se agote el tiempo de espera o te aburras.
3) El firewall permite paquetes (o no hay firewall), pero no hay nada escuchando en el puerto.
Recibirá un mensaje TCP RST/ACK. Supongo que el protocolo TCP lo requiere. En otras palabras, si no hay nada escuchando en el puerto, el propio sistema operativo envía esta respuesta. Puede ser difícil distinguir esto del n.º 1 basándose únicamente en lo que informa una herramienta, porquepuedediga lo mismo en ambos casos (sin embargo, lo más probable es que distinga esto como "conexión rechazada" versus #1, "red inalcanzable"). Observado en un rastreador de paquetes en la máquina cliente, el escenario n.° 1 (mensaje de rechazo ICMP) y n.° 3 (mensaje TCP RST/ACK) son claramente distintos.
La única otra opción aquí es que el firewall permita el paso del paquete y que algo esté escuchando, por lo que obtendrá una conexión exitosa.
En otras palabras: suponiendo que su red en general funcione correctamente, si obtiene el número 1 o 2, significa que un firewall está impidiendo activamente el acceso al puerto. #3 sucederá si su servidor no está funcionando pero el puerto es accesible y, por supuesto (el implícito) #4 es una conexión exitosa.
- Por ejemplo, "puerto inalcanzable", "host prohibido", varias otras combinaciones dehost/puerto/administradoryinalcanzable/prohibido; Búsquelos en el mensaje, ya que son una indicación explícita de que hay un firewall IP en juego.
Respuesta3
Puede usar el comando netstatpara ver si un puerto está abierto y escuchando.
Ejemplo
$ 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
El resultado muestra los 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 muestranLocalyDirecciones extranjeras.Localsería su sistema mientrasExtranjeroserían cualquier dirección que se conecte a su puerto TCP o 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, ese esESCUCHANDOpara conexiones. Una vez que alguien intenta conectarse al sshdemonio, éste bifurca una copia de sí mismo y envía esa conexión a otro puerto, manteniendo el puerto TCP 22 abierto para conexiones adicionales a medida que ingresan.
Respuesta4
Recientemente recibí la misma solicitud y llegué al hilo. Pude escanear puertos abiertos en el FW con el comando nc, así mientras consulto su resultado:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Básicamente, si se agota el tiempo de espera, significa que el puerto no está abierto en el FW.