案例解析真实场景下 ssh 无法连接新加坡机房的修复记录

1.

问题概述与初始环境

（1）机房：新加坡某主流云提供商，机型：vCPU2/4GB/40GB SSD，OS：Ubuntu 20.04。
（2）公网IP：203.0.113.45（示例），服务：OpenSSH 8.2p1（sshd）。
（3）症状：外网SSH连接一直超时，浏览器、HTTP接口正常，仅22端口不可达。
（4）复现：在北京A机进行ssh root@203.0.113.45，表现为 "Connection timed out"。
（5）频率：10:00-12:30间持续，间歇性恢复后又失联，影响业务部署与监控报警。

2.

初步网络排查与数据采集

（1）Ping测试：从本地到目标IP平均丢包12%，平均RTT 210ms。
（2）Traceroute：怀疑链路中存在丢包/黑洞，于是截取traceroute数据如下：

Hop	IP	RTT(ms)
1	10.0.0.1	2
5	203.0.113.1	220
6	203.0.113.45	(no reply)

（3）结果：最终跳出现明显丢包并在到宿主机时无响应，指向机房或宿主网络问题。
（4）SSH本地日志：/var/log/auth.log 无连接记录，说明包未到达sshd层。
（5）监控：云平台面板未显示主机异常，仅安全组22端口规则允许所有来源。

3.

深入分析：MTU/防火墙/主机网络栈

（1）怀疑原因一：路径MTU导致大型握手包被丢弃（MSS/DF问题）。
（2）怀疑原因二：宿主或网络层ACL/防护（机房DDoS防护策略误判）丢弃22端口TCP SYN。
（3）检查本机sshd_config：PermitRootLogin yes, Port 22, ListenAddress 0.0.0.0。
（4）检查iptables：sudo iptables -L -n 显示默认接受，无22端显式DROP。
（5）检查内核：sysctl net.ipv4.ip_forward=0，net.ipv4.tcp_mtu_probing=0（默认），可能影响MSS协商。

4.

修复步骤一：主机端调整与验证

（1）开启MTU探测：sysctl -w net.ipv4.tcp_mtu_probing=1，保证TCP在受限路径能调整MSS。
（2）临时降低MTU尝试：ip link set dev eth0 mtu 1400（原1500），观察连通性改善。
（3）添加mangle规则强制MSS：sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu。
（4）重启sshd并查看日志：systemctl restart sshd && tail -n 50 /var/log/auth.log，确认出现 "Accepted publickey/password" 记录。
（5）效果：MTU 1400 后Ping丢包降至0-1%，SSH可连接建立，连接耗时约150-300ms。

5.

修复步骤二：与机房/运营商协作和永久方案

（1）提交工单给机房，附上traceroute与丢包数据，AS路径信息与时间窗口。
（2）机房回复：边界防护设备在高流量时对部分端口做了激进策略，已为目标IP下调防护灵敏度并排查链路。
（3）建议：在机房开启22端口白名单或使用跳板/代理IP（CDN/负载均衡）做接入缓冲。
（4）长期方案：将关键运维接口放到非标准端口或仅允许运营商公网/堡垒机访问，结合云端ACL限制。
（5）记录：工单ID #SG-20250601-023，响应时间2小时，完全恢复在提交后4小时内完成。

6.

最终验证与经验总结

（1）最终数据：Ping 35ms 丢包0%，SSH握手时间约0.18s，/var/log/auth.log 显示连接成功。
（2）配置快照：sshd_config 保持 Port 22；iptables mangle 保留；sysctl 将 tcp_mtu_probing 设置为1 写入 /etc/sysctl.conf。
（3）经验一：遇到SSH超时先做ping/traceroute与MTU排查，再看宿主防护；不应直接改sshd配置。
（4）经验二：与机房协作时提供完整测试数据（traceroute、pcap、时间点）能显著加速处理。
（5）结论：本案例为网络链路与防护策略交互导致的SSH不可达，通过MTU/MSS调整与机房干预得到最终修复，建议在SLA内保留运维备份入口与堡垒机策略。

来源：案例解析真实场景下 ssh 无法连接新加坡机房的修复记录