Определить причину отказа в подключении на видеонаблюдении

У нас есть 3 одинаковых блока видеонаблюдения. У каждого есть сервер, который должен быть доступен на портах 80 и 443. Одно устройство внезапно стало недоступным на порте 80, и я работаю над тем, чтобы определить, в чем может быть причина. Он работал нормально в 8:00 и умер незадолго до полудня. Я разработчик программного обеспечения, а не сетевой администратор, поэтому, если я что-то пропускаю или использую неправильные термины, вот почему.

Я подозреваю, что что-то было изменено в конфигурации маршрутизатора LAN, но у меня нет доступа к этому, и я хотел провести как можно больше тестов, прежде чем обвинять эту команду.

Я ищу любой метод, который я могу использовать для обнаружения блокировки порта из-за конфигурации маршрутизации или других настроек маршрутизатора / брандмауэра.

Первое, что я проверил, это наличие повторяющихся MAC- или IP-адресов, используя sudo arp-scan --interface=eth1 --localnet. Это подошло чисто.

Затем я ударил его с помощью 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!

Сканирование портов с помощью 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 -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

Некоторые тесты на завиток:

$ 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

Я попробовал несколько других команд curl с идентичными результатами: ничего на: 80, все хорошо: на: 443.

Может ли кто-нибудь порекомендовать какие-либо другие инструменты для проверки конфигураций портов на IP-адресе LAN без доступа администратора к маршрутизатору?

ОБНОВЛЕНИЕ: после публикации я продолжил изучение. Поскольку у меня был нормальный доступ к: 443, я получил доступ к его панели управления и настроил незащищенный сервер для прослушивания: 10000 того же IP. У меня был нормальный доступ и производительность на http://192.168.1.170:10000. Похоже, что затронут только порт 80.