此服务器所属网络的组织正在更换其 ISP。当我将此服务器切换为新的 IP、网关等值时，我无法再通过 ssh 连接到它。我使用其中一个端口检查工具，当我检查端口 22 时，它返回“我无法在端口 22 上的 _new_IP_value_ 上看到您的服务”。
新 IP 是静态的。相关服务器上没有路由器，没有端口转发 - 网线直接进入服务器。
自然，我以为是该组织的网络或新的 ISP 阻止了端口 22，所以我打电话给网络管理员，要求打开它或告诉 ISP 打开它。他说他会的。但什么都没有改变。我第二天打电话给他问了同样的问题，但你可以看出他很忙——他说他按照我说的做了，然后基本上挂断了我的电话。
所以，现在我想也许服务器的设置有问题。但是所有 Linux 工具（如 lsof、netstat、nmap 等）都表明 sshd 已启动并正在运行，正在监听端口 22、端口 22 已打开等。当我将服务器切换回我们原来的 ISP 网络时，我仍然可以通过 ssh 进入服务器 - 我切换的只是 IP、网关、dns，仅此而已。
当服务器位于新 ISP 的网络上，但不位于旧 ISP 的网络上时，服务器上是否存在阻止 ssh 连接的东西？操作系统是 Linux Mint。
答案1
在客户端运行数据包捕获，在服务器上运行数据包捕获。最常用的工具是Wireshark和tcpdump：
tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"
如果您看到 TCP SYN 数据包离开客户端，但未到达服务器，则问题通常出在网络上 - 最有可能是服务器的 ISP，因为在线端口检查工具已经排除了客户端 ISP 出现问题的可能性。
（也许管理员根本没有打开端口，或者没有为正确的地址打开端口。端口 3389 在 ISP 级别关闭的情况也并不少见。）
我认为
tcptraceroute这可能有助于发现数据包在消失之前走了多远。如果你看到 TCP SYN 数据包到达服务器，但没有得到响应根本，问题出在服务器上。可能是服务器的内部防火墙（tcpdump 获取数据包前它们会进入防火墙），因此请检查是否有任何 iptables 规则和任何 nft 规则。
还要确保服务器有返回路线到客户端，并且它确实通过正确的接口到达正确的网关：
ip -4 route get <client_ip> ip -4 route show match <client_ip>还运行
systemctl cat sshd以检查是否有任何 cgroup 级 IP 地址白名单。还运行ip xfrm policy以检查是否有任何 IPsec 策略。如果你看到 TCP SYN 数据包到达，但它们生成 TCP RST 响应——这仍然可能是防火墙的问题，也可能是 SSH 守护程序配置为听错误的地址。（你没有提到什么本地地址lsof/netstat 显示在“端口 22”旁边。如果它显示 0.0.0.0:22 或 [::]:22，则很好，但如果它显示旧地址，则必须在 sshd_config 中更改。）
如果您看到 TCP SYN 数据包到达，SYN/ACK 响应从服务器发出，但客户端从未收到这些响应 - 这也是网络问题，而且最有可能是在服务器 ISP 端。