Estaremos implantando um novo aplicativo em um servidor e o aplicativo estará escutando na porta 8443. Pedimos à equipe de rede que abra o firewall da porta 8443 nesse servidor antes de implantar o aplicativo. No momento, não há nenhum aplicativo que esteja ouvindo nessa porta específica no servidor.
Existe alguma maneira de garantir que o firewall esteja aberto para a porta 8443
SO: Linux / Windows
Respostas:
Se você deseja ver se pode formar uma conexão TCP a partir de uma máquina remota, instale o OpenCSW nessa e na máquina de destino e instale o netcat nos dois. Esta é a sintaxe para usar o netcat para testar conexões TCP:
nc -vz targetServer portNum
Por exemplo, para verificar o SSH em "homeServer1":
nc -vz homeserver1 22
Isso permite testar a conectividade no nível TCP no sistema remoto. O Netcat também pode ser configurado para escutar uma porta em vez de atuar como um cliente. Para que ele escute no TCP / 8443:
No servidor que hospedará o aplicativo: nc -l homeserver1 8443
Em uma máquina que fica fora do firewall: nc -vz homeserver.fqdn 8443
Este é um exemplo de uma execução bem-sucedida:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Uma execução com falha:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
Os firewalls devem responder com uma mensagem ICMP quando bloquearem uma solicitação. No entanto, esse não é necessariamente o caso (você estará interessado neste belo artigo ).
Você pode testar de fora para ver se uma porta está acessível através de um firewall e, se houver, se alguma coisa está escutando nela. Aqui estão três cenários diferentes que envolvem uma solicitação tcp com a qual você pode observar wiresharkou algum outro sniffer de pacotes e o que você verá:
1) O firewall rejeita a solicitação
Você recebe uma mensagem de ICMP de volta e a ferramenta que faz a solicitação deve informar imediatamente algo sobre esse efeito ("inacessível, proibido pelo administrador" etc.). Por "ferramenta", quero dizer o cliente que você está usando para enviar a solicitação (eu usei telnet). Os detalhes da mensagem 1 dependem de como o firewall está configurado, mas "a porta inacessível" é provavelmente a mais comum.
"Nenhuma rota para hospedar" pode indicar isso, mas também pode indicar problemas de roteamento mais sutis.
2) Firewall deixa cair o pacote
Como não há resposta, a ferramenta aguarda o tempo limite ou você fica entediado.
3) O firewall permite pacotes (ou não há firewall), mas nada está escutando na porta.
Você recebe uma mensagem TCP RST / ACK de volta. Presumo que o protocolo TCP exija isso. Em outras palavras, se nada estiver escutando na porta, o próprio sistema operacional envia essa resposta. Pode ser difícil distinguir isso do número 1 apenas com base no que uma ferramenta relata, porque pode dizer o mesmo nos dois casos (no entanto, o mais provável é distinguir isso como "conexão recusada" vs. nº 1, "rede inacessível" ) Observado em um farejador de pacotes na máquina cliente, o cenário 1 (mensagem de rejeição do ICMP) e o 3 (mensagem TCP RST / ACK) são claramente distintos.
A única outra opção aqui é que o pacote é permitido pelo firewall e algo está escutando, para que você obtenha uma conexão bem-sucedida.
Em outras palavras: presumindo que sua rede em geral funcione corretamente, se você obtiver o número 1 ou o número 2, significa que um firewall está impedindo ativamente o acesso à porta. O nº 3 acontecerá se o servidor não estiver em execução, mas a porta estiver acessível e, é claro (o implícito) nº 4 é uma conexão bem-sucedida.
Você pode usar o comando netstatpara ver se uma porta está aberta e escutando.
$ 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
A saída mostra os processos (coluna mais à direita) que estão escutando nas portas TCP. Os números de porta são os números que seguem os dois pontos após os endereços IP (0.0.0.0:111 seria a porta 111, por exemplo).
Os endereços IP mostram endereços locais e estrangeiros . Local seria o seu sistema, enquanto Estrangeiro seria qualquer endereço conectado à sua porta TCP ou você a uma das portas TCP.
Portanto, no caso da porta 22, esse é o daemon ssh em execução no meu sistema, que está LISTENING para conexões. Uma vez que alguém tenta se conectar ao sshdaemon, ele faz uma cópia de si mesmo e envia essa conexão para outra porta, mantendo a porta TCP 22 aberta para conexões adicionais à medida que entram.
netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}'
A configuração e o status da configuração do firewall são específicos do firewall / SO.
O que você pode fazer é experimentá-lo no server2:
nmap server1
Recentemente, recebi o mesmo pedido e vim para o tópico. Consegui digitalizar portas abertas no FW com o comando nc, desta forma, ao consultar sua saída:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Basicamente, se eu atingir o tempo limite, significa que a porta não está aberta no FW.
ncrelatórios "Conexão recusada" quando a porta está acessível, mas não há ouvinte e "Rede inacessível" quando a solicitação foi devolvida por um firewall via icmp (o que significa que pode ou não haver um serviço na porta ) Se o firewall soltar o pacote em vez de realmente rejeitá-lo,ncficará travado por um tempo.