我们有 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 正常：
$ 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 上一切正常。
有人可以推荐其他工具来探测 LAN IP 上的端口配置，而无需路由器管理员访问权限吗？
更新：发布此帖后，我继续探索。由于我能够正常访问 :443，因此我访问了其控制面板，并将非安全服务器设置为监听同一 IP 的 :10000。我能够正常访问 并正常运行http://192.168.1.170:10000。看来只有端口 80 受到影响。
答案1
我真的不认为我们能帮你做很多事情。该connection refused消息通常意味着端口上没有任何东西在监听，而不是端口被阻止。要诊断这个问题，你真的需要能够在有问题的盒子上“看到”是否有任何东西在监听端口。
- 检查您有权访问的所有日志，查看是否有任何相关消息。
- 了解如何获取控制台访问权限并检查日志/端口等。
- 与网络管理员好好交谈并询问他们是否可以提供帮助——责怪他们是没有用的。
- 安排维护窗口并重新启动该盒子。
这确实是一项基本的诊断，但是如果没有适当的访问权限就无法做到这一点，而如果没有访问权限，您几乎无法做超出现有范围的事情。