Déterminer la cause de la connection refusée sur l'unité de videosurveillance

Nous avons 3 unités de videos de surveillance similaires. Chacun dispose d'un server qui devrait être disponible sur les ports 80 et 443. Une unité est soudainement indisponible sur le port 80, et je travaille à déterminer quelle pourrait être la cause. Il fonctionnait correctement à 8h00 et était mort juste avant midi. Je suis un logiciel dev, pas un administrateur de réseau, donc si je manque quelque chose ou j'utilise les mauvais termes, c'est pourquoi.

Je soupçonne que quelque chose a été modifié dans la configuration du routeur du LAN, mais je n'ai pas eu access à cela et je voulais faire autant de tests que possible avant de blâmer cette équipe.

Je search toute méthode que je peux utiliser pour détecter le blocage des ports en raison de la configuration du routing ou d'autres parameters du routeur / pare-feu.

La première chose que j'ai vérifiée était pour les adresses MAC ou IP en double, en utilisant sudo arp-scan --interface=eth1 --localnet . Cela s'est bien passé.

Ensuite, je l'ai frappé avec 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! 

Une parsing de port avec 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! ... 

Ping est bien:

 $ 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 

Quelques tests de curl:

 $ 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 

J'ai essayé quelques autres commands de curl avec des résultats identiques: rien sur: 80, tout bon sur: 443.

Quelqu'un peut-il reorder d'autres outils pour détecter les configurations des ports sur une adresse IP LAN, sans l'access administrateur au routeur?


MISE À JOUR: après avoir affiché ceci, j'ai continué à explorer. Comme j'avais un access normal sur: 443, j'ai accédé à son panneau de contrôle et configuré le server non sécurisé pour écouter: 10000 de la même IP. J'ai eu un access et une performance normaux au http://192.168.1.170:10000 . Il apparaît que le port 80 n'est pas affecté.

Je ne pense vraiment pas qu'il y ait beaucoup de choses que nous pouvons faire pour vous aider. Le message de connection refused signifie généralement que rien n'écoute sur le port plutôt que d'être bloqué. Pour diagnostiquer cela, vous devez vraiment pouvoir "voir" sur la boîte en question s'il y a quelque chose qui écoute sur le port.

  • Vérifiez tous les journaux auxquels vous avez access, pour voir s'il y a des messages pertinents.
  • Découvrez comment get l'access à la console et vérifier les journaux / ports, etc.
  • Parlez bien aux administrateurs du réseau et requestz-leur s'ils peuvent les aider – les blâmer ne le fait pas.
  • Planifiez une window de maintenance et redémarrez la boîte.

Les diagnostics de base vraiment mais vous ne pouvez pas le faire sans un access approprié et sans access, il y a peu de choses que vous pouvez faire au-delà de ce que vous avez déjà.