Determine a causa da conexão recusada na unidade de vídeo de vigilância

1

Temos 3 unidades de vídeo de vigilância semelhantes. Cada um tem um servidor que deve estar disponível nas portas 80 e 443. Uma unidade tornou-se subitamente indisponível na porta 80, e estou trabalhando para determinar qual poderia ser a causa. Ele estava funcionando corretamente às 8:00 e estava morto pouco antes do meio dia. Eu sou um desenvolvedor de software, não um administrador de rede, então se eu sinto falta de algo ou uso os termos errados, é por isso.

Suspeito que algo tenha sido alterado na configuração do roteador da LAN, mas não tenho acesso a isso e quis fazer o máximo possível de testes antes de culpar a equipe.

Estou procurando qualquer método que eu possa usar para detectar o bloqueio de porta devido à configuração de roteamento ou outras configurações de roteador / firewall.

A primeira coisa que verifiquei foi sobre endereços MAC ou IP duplicados, usando sudo arp-scan --interface=eth1 --localnet . Isso surgiu limpo.

Então eu acertei com nc:

~$ nc -v -w 5 -z 192.168.1.170 80
nc: connect to 192.168.1.170 port 80 (tcp) failed: Connection refused
~$ nc -v -w 5 -z 192.168.1.170 443
Connection to 192.168.1.170 443 port [tcp/https] succeeded!

Uma varredura de porta com nc:

nc -v -w 5 -z 192.168.1.170 70-500
...
nc: connect to 192.168.1.170 port 80 (tcp) failed: Connection refused
...
Connection to 192.168.1.170 443 port [tcp/https] succeeded!
...

O ping está bem:

$ ping -c 5 192.168.1.170
PING 192.168.1.170 (192.168.1.170) 56(84) bytes of data.
64 bytes from 192.168.1.170: icmp_req=1 ttl=64 time=2.13 ms
64 bytes from 192.168.1.170: icmp_req=2 ttl=64 time=0.615 ms
64 bytes from 192.168.1.170: icmp_req=3 ttl=64 time=0.513 ms
64 bytes from 192.168.1.170: icmp_req=4 ttl=64 time=0.618 ms
64 bytes from 192.168.1.170: icmp_req=5 ttl=64 time=0.441 ms

--- 192.168.1.170 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.441/0.864/2.135/0.639 ms

Alguns testes de ondulação:

$ curl -k -s -S -u USER:PASS -w "%{http_code}\n" "http://192.168.1.170" -o /dev/null
000
curl: (7) couldn't connect to host
$ curl -k -s -S -u USER:PASS -w "%{http_code}\n" "https://192.168.1.170" -o /dev/null
200

Eu tentei alguns outros comandos de curvas com resultados idênticos: Nada em: 80, tudo bem em: 443.

Alguém pode recomendar outras ferramentas para sondar configurações de porta em um IP de LAN, sem acesso de administrador ao roteador?

UPDATE: depois de postar isso, continuei explorando. Como eu tinha acesso normal em: 443 eu acessei o painel de controle e configurei o servidor não seguro para escutar: 10000 do mesmo IP. Eu tive acesso e desempenho normais em http://192.168.1.170:10000 . Parece que apenas a porta 80 está afetada.

    
por Paul S. 28.03.2014 / 09:51

1 resposta

2

Eu realmente não acho que há muito que possamos fazer para ajudar você. A mensagem connection refused geralmente significa que nada está escutando na porta em vez de ser bloqueada. Para diagnosticar isso você realmente precisa ser capaz de 'ver' na caixa em questão se houver algo escutando na porta.

  • Verifique todos os registros aos quais você tem acesso para ver se há alguma mensagem relevante.
  • Saiba como obter acesso ao console e verificar registros / portas, etc.
  • Fale bem com os administradores de rede e pergunte se eles podem ajudar - culpá-los não ajuda.
  • Agende uma janela de manutenção e reinicie a caixa.

Diagnóstico básico realmente, mas você não pode fazer isso sem acesso adequado e sem acesso, há pouco que você pode fazer além do que você já tem.

    
por 28.03.2014 / 10:27